How to Solve MRP Problems

Executive Summary

  • MRP has a well-known list of problems or limitations.
  • In this article, we analyze the problems to see what can be done about them.


The list of commonly listed problems with MRP is analyzed in this article and our analysis of how to solve MRP problems.

Our References for This Article

If you want to see our references for this article and related Brightwork articles, visit this link.

Wikipedia’s Listing of Problems with MRP Software

Oliver Wight and other companies complain that the MRP software functionality within their ERP system is challenging to implement. There are articles written on why MRP is a problem for many businesses, and Wikipedia has a section on its MRP software entry, a synopsis of which is provided below.

While they are not listed this way in Wikipedia — I have added a “name” in parentheses for each problem.

How to Solve MRP Problems

Below the listed problem is my analysis.

Problem 1: Data Integration

“First problem with MRP software – the integrity of the data. If there are any errors in the inventory data, the bill of materials (commonly referred to as ‘BOM’) data, or the master production schedule, then the output data will also be incorrect (“GIGO”: Garbage In, Garbage Out).”

Analysis: (Data Integrity)

Wikipedia lists this as an issue for MRP, but in fact, it’s an issue for any method of planning — either computerized or even if planning is performed manually. Most companies reduce their ability to plan as accurately as possible because they are unaware that software exists to help them manage the BOM and think that a combination of Excel & ERP is a BOM (or recipe if in the process industry) solution. I have yet to see a consulting company understand this. They are hired to bring knowledge; that is too often not evident.

Problem 2: Lead Time Estimation

“Systems is the requirement that the user specify how long it will take for a factory to make a product from its component parts (assuming they are all available). Additionally, the system design also assumes that this “lead time” in manufacturing will be the same each time the item is made, without regard to quantity being made, or other items being made simultaneously in the factory.”

Analysis: (Lead Time Estimation)

Inaccuracy exists both for suppliers and for production lead times. Production lead times can auto-adjust in constraint-based methods such as cost optimization; however unless the supplier is modeled as an internal plant, lead times will not change for vendors’ volume.

The synopsis on this is that the most sophisticated supply planning systems have very similar MRP issues on lead time inaccuracy. Few companies are meticulous about reviewing their lead times and adjusting them to the current reality.

Problem 3: Multi-Plant Planning

“A manufacturer may have factories in different cities or even countries. It is not good for an MRP system to say that we do not need to order some material, because we have plenty thousands of miles away. The overall ERP system needs to be able to organize inventory and needs by individual factory, and inter-communicate the needs in order to enable each factory to redistribute components, so as to serve the overall enterprise.”

Analysis: (Multi-Plant Planning)

This is a true limitation of MRP. However, to do this, it is necessary to use a method that “can see the entire supply network.” MRP cannot see outside of a single location — that is its design. Multi-plant planning is rated by Brightwork Research & Analysis as one of the two most sophisticated functionalities in supply planning. The only known application which performs multi-plant planning is PlanetTogether, and this is one of the three Superplant functionalities. Turning on multi-plant planning is a desirable goal, but it is more involved than merely using MRP functionality.

Problem 4: Other Systems

“This means that other systems in the enterprise need to work properly, both before implementing an MRP system and in the future. For example, systems like variety reduction and engineering, which makes sure that product comes out right first time (without defects), must be in place.”

Analysis: (Other Systems)

Yes, MRP relies upon other systems, as do all other supply planning methods.

Problem 5: Alternate BOMs

“Production may be in progress for some part, whose design gets changed, with customer orders in the system for both the old design, and the new one, concurrently. The overall ERP system needs to have a system of coding parts such that the MRP will correctly calculate needs and tracking for both versions. Parts must be booked into and out of stores more regularly than the MRP calculations take place. Note, these other systems can well be manual systems, but must interface to the MRP. For example, a ‘walk around’ stock intake done just prior to the MRP calculations can be a practical solution for a small inventory (especially if it is an “open store”).”

Analysis: (Alternate BOMs)

This is performed by having alternate BOMs or recipes in the application with different effectivity dates — something most vendors that offer MRP have mastered. Although there are considerable differences in this functionality’s usability and maintainability, which changes the real-life capability that companies have with this functionality. Furthermore, a true BOM or recipe management solution should feed the new BOM or recipe information, as was discussed in the first bullet point. This takes BOM/recipe management’s recursive complexity both away from the ERP system and the external planning system. These systems are designed to represent BOMs and recipes, not to manage this master data actively.

New BOMs/receipts are brought over in an interface when released from the BOM/recipe management system when they are production-ready. They should be coded with their priorities at this time. The highest-rated BOM solution by Brightwork Research & Analysis is Arena Solutions. For process industries where recipes are used, our recommended solution is Hamilton Grant. This overall topic will be discussed in the next section.

Problem 6: Lack of Constraints

“The other major drawback of MRP is that takes no account of capacity in its calculations.”

Analysis: (Lack of Constraints)

Yes, MRP is unconstrained.

This means that planners must meet the plan’s capacity level either manually (by moving orders around by hand) or by using a capacity leveling method. Many vendors provide a procedure for capacity leveling, which can be configured. This brings up the related issue of the accuracy of resource capacity information. But while this issue is often directed at methods that perform capacity constraining, it affects all supply/production planning methods. Here again, not all applications are created equal — because the existence of constraining functionality says nothing about how easy or difficult it is to maintain resources. SAP APO has an extraordinarily ineffective and time-consuming resource management functionality, which results in data not being updated as frequently, and a heavy maintenance load. Overall, constrained planning techniques have had a high failure rate on projects, something that promoters of things like cost optimization frequently leave out of their presentations to customers and at conferences.

Executive decision-makers generally cannot see the distinctions between applications in this area. They will often end up with a heavy maintenance application that cannot effectively keep capacity information updated, even though the application can perform capacity constraining within the procedure. This has given capacity constraining a black eye generally when, in reality, it is just as much a function of the application selected.


How to solve MRP problems was the topic we focused on. However, how to solve MRP problems cannot be accomplished entirely within the MRP system.

One of the best ways to answer how to solve MRP problems is by understanding its parameters. We have developed a Brightwork Explorer system that is both designed to improve parameters and how MRP runs and can be used to understand MRP better.