How to Make DRP Software Better

Executive Summary

  • 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.[1]

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.

The Consequences

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.

Deployment Parameters

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:

  1. 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.
  2. 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:
    1. Previous Demand: This allocates the stock to be deployed based upon the previous demand allocation.
    2. 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.
    3. 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.
  3. 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.[2]

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.

[1] Even a single application can have too much maintenance if the application is naturally higher in maintenance.

[2] 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

Supply Planning Research Contact

  • Interested in Our Supply Planning Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.


Brightwork MRP & S&OP Explorer

Improving Your Supply Planning, MRP & S&OP Software

Brightwork Research & Analysis offers the following supply planning tuning software, which is free to use in the beginning. See by clicking the image below:

Supply Planning Book


Supply Planning with MRP, DRP and APS Software

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?

This book as a practical primer for anyone looking to perform a supply planning software selection, any person beginning a supply planning project, or anyone who just wants to understand supply planning software simply better.


  • 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


Software Ratings: Supply Planning

Software Ratings

Brightwork Research & Analysis offers the following free supply planning software analysis and ratings. See by clicking the image below:


How to Appreciate The Four Supply Planning Threads and Their Timing

Executive Summary

  • There are four major supply planning threads which are distinct from planning runs.
  • In this article, we explain using an MRP example. We also cover how a rough schedule or rough plan differs from a detailed schedule and S&OP, as well as the deployment plan, redeployment plan and the timing of various supply planning threads as well as the differences between the threads.


There is often a good deal of confusion as to what are the primary planning threads for supply planning. Therefore, I have spelled them out in this article.

Different threads make up the supply planning portion of the supply chain process. The supply chain process would include demand planning, supply planning, production planning, etc..

Planning Runs or Planning Threads?

These are often referred to as “planning runs.” However, this is a less accurate way of defining them.

This is because, in system terms, there are often multiple jobs or runs scheduled within each thread. For instance, one may schedule one grouping of product location combinations to be placed into one run, and then another group to be placed in a second run and so on. For instance, one may hear someone say that after the “MRP run” the results were XYZ.

However, the MRP run that is referred to may, in fact, be comprised of one MRP run for a particular product group, another MRP run for another product group and so on. But when the person is using the term, MRP run they are in fact describing all of the MRP runs.

Therefore, I use the term threads instead of the more common “run” because there can be multiple planning runs within any one thread as part of that supply chain process.

Understanding the Threads of Supply Planning

These planning threads are most typically discussed independently from one another. However, they, in fact, have an everyday basis. They are the following:

  1. S&OP & Rough Cut Capacity Plan
  2. The Network/Initial Supply Plan
  3. The Deployment Plan
  4. The Redeployment Plan

S&OP & Rough Cut Capacity Plan

These are used for long-range planning and in most cases are off-line analyses and is not part of the live environment. The term rough schedule or rough plan or rough capacity schedule is used to differentiate it from a detailed schedule. A rough plan is aggregated and will have only high-level resources information if it uses any resource information at all.

A rough plan, schedule or capacity plan is intended to allow higher-ups to gain an overview, but the rough plan, schedule or rough-cut capacity plan is only a high-level representation of what will actually occur. A rough plan or rough schedule or rough cut schedule is the starting point.

The Network/Initial Supply Plan: (performed by MRP in ERP systems)

Produces initial production and procurement plan. Is focused on bringing stock into the supply network, and in creating stock with planned production orders. Can also be called the master production schedule (MPS), if the initial supply plan is run under certain criteria. This is covered in this article.

The Deployment Plan: (performed by DRP in ERP systems)

Focused on pushing stock from locations at the beginning of the supply network to the end of the supply network.

The Redeployment Plan: (performed by specialized applications with redeployment functionality or with a custom report)

Focused on repositioning stock, which is already in the supply network to locations where it has a higher probability of consumption. More on this in this article.

Timings of the Supply Chain Process Planning Threads

The following are the general frequency of the different supply planning processes.

  1. Rough Cut Capacity Plan / S&OP Run / MPS Run / Unconstrained Capacity Run: Weekly to Monthly
  2. Initial Supply Plan: Daily to Weekly
  3. Deployment Plan: Daily to Weekly
  4. Redeployment Plan: Weekly to Quarterly

Similarities Between the Supply Chain Process Planning Threads


The Differences Between the Supply Chain Planning Threads


More Details on the Supply Planning Threads

This article will be very different from what you may have read on this topic. This is because I see S&OP, MPS, and RCCP as all different cuts or derivations of the initial supply plan (all of which also contain the forecast and at least production, but in some cases supply planning constraints).

They are also defined by their level of granularity, whether they are a rough plan or a detailed plan.

  • A series of supply planning method and method modifiers were developed over time to create the initial supply plan.
  • The MPS and RCCP are direct copies of the initial supply plan, with changes to their thread characteristics. For instance, a copy of the initial supply plan configuration may be put into a simulation version.
  • The planning time the horizon may be lengthened, and its resources made unconstrained. (This will be demonstrated in just a few paragraphs.)

The S&OP thread is not a complete copy of the initial supply plan, as extra information is required, for instance from finance. There are just a few adjustments and additions necessary to convert an initial supply plan into an S&OP plan and to fit within the supply chain process of planning.

The vast majority of supply planning applications are not designed to support S&OP within their applications natively. And the penetration of specialized S&OP applications is low. In most cases, supply planning applications support S&OP by providing extracts.

Search Our Supply Planning Articles

Supply Planning Research Contact

  • Interested in Our Supply Planning Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.

Brightwork MRP & S&OP Explorer for Constraining

Improving Your Constraint Planning

Brightwork Research & Analysis offers the following supply planning tuning software with a new approach to managing capacity constraints, which is free to use in the beginning. See by clicking the image below:


The various supply planning threads are covered in the following books.

Capacity Planning Book

Combining Two Types of Capacity Planning

This book is called capacity management because it encompasses two areas of planning that are usually discussed independently. Short-term capacity leveling or capacity constraining, which is the movement of demand to fit within the available supply, and long-term capacity planning. This is the planning of long-term market demand to determine if the capacity should be changed.

Using Comparative Applications

In this book, both topics are covered, and they are included using multiple software applications to explain the concepts of capacity management. These are two closely related processes. However, they are often discussed separately. This book combines their explanation as well as their relationship to one another.

By reading this book you will learn:

  • How resources are modeled in capacity management systems.
  • How the structured nature of capabilities leveling and constraining differs from capacity planning.
  • How the various planning processes fit into one another, and where the gaps can be found.
  • The time horizons of the capacity management process.
  • How to improve capacity management at your company.


  • Chapter 1: Introduction
  • Chapter 2: Capacity Leveling
  • Chapter 3: Constraint Based Planning
  • Chapter 4: Resources
  • Chapter 5: Forecast Consumption, Allocation, Scheduling Direction and Timing
  • Chapter 6: Capacity Planning with S&OP and the MPS
  • Chapter 7: The Relationship Between Planning Systems and S&OP System
  • Conclusion

Sales and Operations Planning Book


Sales and Operations Planning in Software

Getting Clear on S&OP

S&OP is a commonly discussed, yet infrequently mastered area of planning. S&OP continues to be one of the most misused and overused terms in business.

S&OP is a type of long-term planning that attempts to match supply and demand and provides input to a financial plan to support the firm’s overall strategy. S&OP is in part a subcategory of consensus-based forecasting. It means driving to a consensus on what are branches within the company or entity that are often more competitive with one another than actually collaborative.

No Problem on Getting Consensus?

Obtaining this consensus is no easy task, and beyond the political aspects of S&OP, S&OP comes with its unique software challenges because it means both planning at a higher level of aggregation than other planning processes, while also exposing the specific constraints so that those constraints can be evaluated for possible alteration.

All of these issues and more are addressed in specific detail in this book. By reading this book you will learn:

  • What is the difference between S&OP and IBP, and how does this relate to the difference that is often described in the marketplace?
  • What are important features of S&OP applications and how do some standard S&OP applications differ in their design?
  • What are the implications of aggregation to S&OP application and process?
  • What are the political considerations that are required to be understood to be successful with S&OP?
  • What are the natural domains for executive adjustment versus lower level planning adjustment?


  • Chapter 1: Introduction
  • Chapter 2: The Relationship Between Planning Systems and S&OP Systems
  • Chapter 3: S&OP Versus Integrated Business Planning
  • Chapter 4: SAP IBP, ANAPLAN & SAP Cash Management
  • Chapter 5: The Impact for SAP IBP with HANA
  • Chapter 6: S&OP, Aggregation, and Forecast Hierarchies
  • Chapter 7: Challenges in S&OP Implementation
  • Chapter 8: How Misunderstanding Service Level Undermines Effective S&OP
  • Chapter 9: Conclusion