- DRP has common problems in software.
- In this article, we cover important ways of improving DRP.
DRP implementations have common areas where they can be improved. I have run into quite a few companies that were unhappy with their DRP systems. But on the other hand, I rarely run into many companies that put enough into their DRP systems. One of the great misunderstandings in this area is that migrating to a new system with a new more advanced supply and production planning method (i.e., cost optimization, prioritization, etc..) will solve the issue of DRP dissatisfaction.
Most companies that think this way have not properly maintained their DRP systems, so they don’t know what they could get out of them.
Observations from Companies that Run DRP
The evidence that I have seen is that companies that have a problem maintaining DRP systems have even a greater problem maintaining more advanced methods. The reason for this is that DRP systems have comparatively less maintenance and are easier to understand and troubleshoot than the more complex methods within advanced supply planning systems. For instance, compared with other supply and production planning methods, such as prioritization or cost optimization DRP is far easier to understand. There is also an enormous processing time difference between DRP and say cost optimization or cost optimization.
Secondly, the more advanced methods all use some of the same data as DRP systems. So lead times, deployment parameters, sales orders, forecasts are all the same. The areas, which are different, include the user interface and the calculation method and the way that the problem is calculated. C0ntrary to what many think, there is no waste in doing this because after the inputs are improved within DRP, they are simply ported to the new supply planning system whenever it comes online.
Therefore whether improving the DRP system to continue to use the DRP system or improving the DRP system in preparation for migrating to a more sophisticated supply and production planning method, I have found the following to be consistent areas of opportunity.
DRP System Comparison
A major problem with the DRP systems by companies is that they have no means of comparing the DRP planning output to another system. This is a problem because it makes diagnosing the system far more challenging. Companies can run their live or production DRP system in simulation mode – which is where a separate copy of the data is created, but the same hardware is used to process the procedure – and the simulation results do not impact the live version. The benefits of this are explained in the following quotation:
“In the demo version of the system you can try and work out what the limits of your system are. If you have a question and you can configure your system to accept the change you can test it. If the test goes wrong when you operate the system then you will know how the system reacts and can avoid doing that on the real system. From doing this experiment you can gain insight into how you can further improve the system.” – Making MRP Work: A Practical Guide to Improving Your System’s Performance
Testing With an External System
I am proposing going a step beyond simply creating a simulation version and testing every change in one DRP system. For a number of years now, I have advised clients to stop thinking in terms of a single solution for supply planning and to entertain more than one supply planning solution. This includes external simulation tools and general optimization solvers— that can enhance their company’s capabilities and meet more requirements that any one tool can, even with expensive enhancements.
How The Large Consulting Companies Stand in the Way
Doing this is an uphill battle because the large consulting companies promote the mindset that all of the supply planning needs of a company can, and should, be met by a single application model. Financial incentives blind large consulting companies to better ways of doing things. And while this is the official position of the large consulting companies, it is also the position of IT that want as few applications to maintain as possible.
In most cases, DRP is run from an ERP system.
The problem with this is that ERP systems are in most cases difficult to diagnose and troubleshoot. ERP systems excel at enforcing an enormous number of rigid rules and processes on business.
This has positive and negative consequences, although the ERP vendors and the major consulting companies tend to emphasize the positive consequences if for no other reason that they make money selling and implementing these systems. In some cases vendors and consulting companies will discuss the “best practices,” but in many cases what is offered in the software is simply a generic practice, or specifically a logical sequence. It is a logical sequence that one would post a goods issue before a goods movement, and very difficult to see how this is innovative, requires special thought or a best practice. In fact, many countries have accounting rules that state this must occur in this sequence. There are also many cases where a generic practice is to create the forecast before creating a supply order, at least for make to the stock environment.
The Intelligence of This Sequence
There is nothing particularly intelligent or insightful about this sequence; it is just how it should naturally be performed. This is a natural course in the same way that is opening a car door should precede starting the car. One can instead choose to start the car by rolling down the window, starting the car from outside and then opening the door to get in, but it would make little sense to follow this alternative sequence.
Therefore, ERP systems in my estimation did not do anything to enable DRP to be run better than it had before ERP systems – although this was promised to be the case because ERP systems were so integrated. Integration does not improve the actual functionality, and most ERP vendors stopped developing their DRP functionality years ago – building it to an elementary state, and then choosing to focus on other things.
Diagnosing DRP Issues
Most ERP systems are not the best systems in which to troubleshoot and diagnose DRP problems. What can be useful is to run DRP for just a small number of products and review and document the results, make a change to the system, and then rerun DRP and re-review and document the results. Changing inventory parameters in many ERP systems is often a tedious process. There are smaller and nimbler DRP systems that can be purchased to allow a person to run DRP much more quickly. Then the output from this external system can be used to check the results within the ERP system. Some of these applications are inexpensive, and in my experience, the improvement in efficiency quickly makes up for the costs of the software. I believe this so firmly that I purchased this software myself, as many companies prefer to not buy a DRP application for a month or two of analysis – and this allows me to use a DRP application, which can run circles any ERP based DRP functionality.
Lead Time Accuracy
For the DRP system to provide correctly timed stock transfer requisitions, lead times, which for DRP are the lead times between the locations in the supply network, need to be as accurate as they can be reasonably made. The objective here should be to tell the planning system the “truth.” Comments about reducing lead times should be subordinated to what the lead times are. As soon as the lead times decline, this master data can be updated.
This is rather obvious, but deployment is typically controlled by deployment parameters. Not all systems will have the same parameters, but some of the common parameters are the following:
- Push or Pull Distribution: The deployment system can either wait for a demand signal from the receiving location or push ahead of demand. There are different degrees of push or pull. One can only consider sales orders as a replenishment trigger. Or both sales orders and forecasts can be found as demand. Of course, if forecasts are considered (which is more often the case), then the system becomes more push based. In a push distribution configuration, a material will be pushed through the supply chain in advanced of any forecast as well. Therefore, it is not simply a question of the following push or pulls, but of choosing a strategy, which is along a continuum between push and pulls. This would ordinarily be set in in the product location master.
- Fair Share Allocation: Fair share allocation is a method of allocating demand under conditions of shortage. How fair share deployment allocation works very much depends upon whether a push or pull strategy is configured. When a pull deployment is used, and when there is less demand than supply (also known as the available to deploy), fair share is not used. If demand exceeds supply, then some mechanism must determine which receiving location will receive which allocation. Conversely, if push deployment is used and there is Excel available to deploy versus the target stocking level, then fair share would not be used. If the combined requirements from the target stock level in the receiving locations are higher than the available to deploy, then again fair share allocation would be used. Some deployment systems can allocate stock depending upon different rules. This would ordinarily be set in in the product location master. A few examples of this are the following:
- Previous Demand: This allocates the stock to be deployed based upon the previous demand allocation.
- Target Stock Level: This requires a target stocking level to be set at every location. The target stocking level is the stock level that should be carried. This typically requires an inventory analysis to determine.
- Quota Arrangements: A quota can be set between the locations and the deployment between two or more locations will respect the configuration of this quota.
- The Horizon: An important are of configuration is how far out to make the deployment decision. This is the deployment horizon. The deployment horizon is a planning horizon and the duration over which the stock transfers recommendations are created. Outside of the horizon, any forecast, sales order, planned inventory level could exist, but it will not drive a deployment recommendation. This would ordinarily be set in the procedure setting. Therefore, one DRP planning run could be set for one week, while another could be set for two weeks. This deployment planning horizon may change depending on the time of year. Also, one can choose to run the deployment for any sub-segment of the product location database.
The Importance of Deployment Parameters
As the deployment parameters are so important to how the deployment is run, it’s important to evaluate all of the parameters and ensure that they match the business requirements. There are all types of decisions that must be made that go to the policy of the company’s deployment. For instance, does the company want to deploy based on sales orders or sales order and forecasts? Is a push or pull deployment desired? How far out should the stock transfers be created? Secondly, it’s important to look at all of these parameters about on another. Looking at any parameter in isolation, which is the most common way that deployment functionality tend to implemented will result in suboptimal outcomes.
This means that a company that wants to get the right answers needs to create a series of deployment scenarios and then track the situation through all of the deployment implications. This should be done for a variety of deployment parameters to ensure that the way the deployment parameters are set will work as much of the time for the common scenarios that the company faces.
Deployment Parameters Flexibility
Because in many systems the deployment parameters (depending on the parameter) change changed either per product location combination or the deployment planning run, the company has a great deal of flexibility in deployment parameters. It can, therefore, customize the parameters for certain products. As an example, it can choose a one-week deployment planning horizon for one region, or for some products within that region, but a two-week deployment horizon for other products or other regions. The best way to keep all of this straight is to create a deployment parameter spreadsheet which declares the coding for each product location combination.
In the example above, the product locations that had the one-week deployment planning horizon applied to them would have this called out in the spreadsheet. This also makes reviewing the settings much easier than having to cycle through all of the product locations combinations within the system or trying to find or create a report that will present the information in an optimized way for the evaluation.
Determining the State of a DRP Implementation
Before beginning DRP improvement project, it is important to understand the usage level of the DRP system. It’s not sufficient to ask executives this question as they receive most of their information about the system second-hand and are not in the system dealing with its output.
An understanding can be typically be determined from just a few interactions with those that use the system. I have also found it important to list the statements that are collected from these interactions. This is because when combined, the statements can be triangulated and can provide insight into the system’s usage.
There are variances regarding what are the largest areas of opportunity for improving DRP systems. A significant opportunity exists for every company I have encountered to make a small project focused on improving DRP worth the effort. It should be understood that any DRP improvement project should be undertaken with an open mind regarding the areas of opportunity because in many cases the company itself is not only unaware of where the opportunities lie, but also how large the opportunities are.
However, a DRP system can be diagnosed, and from there a prioritized list of what to focus on can be created. Typically there will be a funding limitation – even though DRP improvement projects don’t take very long – there tends to be much less appetite for spending money on fixing a DRP system than there was for funding the initial DRP/ERP system implementation. I am not sure why this is the case, but it may have something to do with not wanting to pay for something twice.
Most large consulting companies – along with vendors make quite unrealistic promises of the improvement that will occur from implementing a new application. So implementing companies are most often lead to believe that no further tuning of the system is necessary. This need to allocate money for future tuning and improvements, something that extremely few software vendors will agree to include into the total cost of ownership TCO calculation is something that I set as a default value when calculating TCO.
All of these adjustments take money and time. It typically makes sense to improve DRP for the most important (largest, most profitable products) before moving on to less critical products. Most companies have some very high volume products where improving DRP makes a big impact on the bottom line. Marketing, through product proliferation, tends to grow the product database so that most companies now have scores of products that it would be better for the company to discontinue, but marketing will not allow it. Under optimal circumstances and unlimited funding all product location combinations would be analyzed for improvement, but in most cases, this will not be feasible.
Therefore identifying the most relevant product location combinations is typically an important first step which can reduce the overall work effort and bring it down to a manageable level which matches the available funding.
 Even a single application can have too much maintenance if the application is naturally higher in maintenance.
 TCO is strangely under calculated, and it is frequently proposed that neither software vendors, nor consulting companies nor analysts like Gartner want TCO calculated. Instead, it is far better to suggest the importance of TCO as a general concept but never to calculate TCO. This is explained in great detail in this SCM Focus Press book.
Search Our Supply Planning Articles
Brightwork MRP & S&OP Explorer
Supply Planning Book
Showing the Pathway for Improvement
Supply planning software, and by extension supply planning itself, could be used much more efficiently than it currently is. Why aren’t things better?
Providing an Overall Understanding of Supply Planning in Software
Unlike most books about software, this book showcases more than one vendor. Focusing an entire book on a single software application is beneficial for those that want to use the application in question solely. However, this book is designed for people that want to understand supply planning in systems.
- What methods fall into APS?
- How do the different methods work and how do they differ in how they generate output?
- What is the sequence of supply planning runs?
These types of questions are answered for readers in this book.
This book explains the primary methods that are used for supply planning, the supply planning parameters that control the planning output as well as how they relate to one another.
Who is This Book For?
- Chapter 1: Introduction
- Chapter 2: Where Supply Planning Fits Within the Supply Chain Planning Footprint
- Chapter 3: MRP Explained
- Chapter 4: DRP Explained
- Chapter 5: APS Supply Planning Methods
- Chapter 6: APS for Deployment
- Chapter 7: Constraint-based Planning
- Chapter 8: Reorder Point Planning
- Chapter 9: Planning Parameters
- Chapter 10: How MRP, DRP, and APS Relate to One Another
- Chapter 11: Supply Planning Visibility and Master Data Management
- Chapter 12: Understanding the Difference Between Production Versus Simulation