Making MRP Work
Picture source: http://www.referenceforbusiness.com
INDUSTRIAL ENGINEER – VOLUME 43: NUMBER 11
The idea of Material Requirement Planning (MRP 1) that were developed in 1960s and 1970s was to ensure that enough of the correct components were on hand to build assemblies. Recognizing that labor and machines were key requirements, Manufacturing Resource Planning (MRP 2) extended the idea of production requirement to include the number of labor hours and machine hours needed at each work center in a plant.
MRP 2 and Enterprises Resources Planning (ERP) system cannot account for how capacity, lot sizes, and lead-times interact because these system had no mathematical foundation to describe the numerical relationship. Contrast this with MRP 1, which has mathematical foundation that calculates the number of components an assembly needs.
In all product situation, someone or something should make the decision about the lot size. However, it is an extremely number to optimize using MRP/ERP or other traditional manufacturing practices. The fact that no current MRP/ERP system in use today can manage lot sizes in a dynamic and coordinated way is a significant deficit in their functionality, which
Scrapping the MRP system still leaves the basic problems of deciding lot sizes and lead-times. A manufacturer should decide the lot size and time to start (due date minus the manufacturing critical path time/MCT) no matter what you decide to manufacture. After doing lean, theory of constraints, Six Sigma, just in time, or any other buzzword-based methodology, and after any kaizen events, consultants, set up reduction and engineering tune-ups, you ultimately return to MRP and are hamstrung by its inability to manage lot sizes and MCTs effectively. None of the methodologies can provide actual numbers to use for these parameters as inputs for MRP. No current MRP system or add-on will provide actual answer.
Another major problem with MRP systems is the requirement that the user specify how long it will take a factory to make products from its component parts. 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.
MRP problems include a number of distinct issue that must be addressed if MRP is going to work the way it needs to. For example, users cannot presume that capacity is infinite. The second issue is that any decent foreperson with simple observation skills know that the following the observations to be true. The use of bottleneck affects the estimated waiting times. In addition, using the bottleneck should affect the choice of the lot sizes. Finally, the lot size of one part affect the waiting times of other parts. None of these facts of life are considered adequately within current MRP systems. They all assume that utilization, lot sizes and waiting times are independent of each other, and you can change one without affecting others. The next issue is a set of system-wide concerns.
In Principles of Operations Research, published in 1975, Hervey Wagner states that Economic Order Quantity (EOQ) should not be used for production lot sizing because there is no finite capacity constraint within EOQ and that within EOQ, the lot size choice of one part does not affect the waiting time of any part, not even for the part we are choosing the lot size for.
The main time to repair (MTTR) also is critical number for computing MCT and Work in Process (WIP). The MTTR determines the size of backlog that builds at the machine, which directly affects the WIP and MCT. Utilization obviously determines how long it will take to clear the backlog. Resolving the backlog requires a lot of rescheduling, which can be difficult particularly if the length of the down time is highly variable.
Down time percentage alone does not tell us how much backlog will develop, how long it will take to dissipate and how much this adds to the average WIP and lead-time. MTTR and utilization determines these numbers. A simple approach can calculate these effects. If U is equals utilization, then U multiplied by MTTR is the amount of backlog generated by a failure, which determines the number of hours of extra work at the end of the equipment repair. In additions, 1-U tells us the rate at which the backlog is removed. Putting it together, MTTR x U/(1-U) equals the number of hours needed to clear the backlog from equipment failure.
The equation above show how critical MTTR is. The MTTR determines the size of the initial backlog, and the slack or idle time determines the rate at which the backlog is worked off. At their best, current MRP systems handle equipment failures by subtracting down time from available hours. This MTTR analysis can be used as an analogy to understand another issue. Viewed from a different perspective, a failure is just another lot arrival. The MTTR represents the setup and run time for a lot instead of down time. Current MRP/ ERP software fails basic reality test because they all assume that the lot size of one part has no effect on any other part’s waiting time.
Although manufacturers complain about their ERP systems, they can be indispensable for planning production. Mfrtech.com has a few tips to help you decide on your next ERP purchase.
- Platform: Don’t base your selection on platform alone because high-caliber functionality might compensate for the platform difference.
- Technology: Vendor should be on the leading edge to keep your system up to date.
- Numbers of Vendors: Preferably one vendor will design, develop, supply and support the package. Multiple vendors could cause system incompatibilities.
- Product Demonstration: Take charge and try the product and enter a specific bill of material or other data to see how the system reacts.
- Buzz Words: Don’t focus on catch phrases
- Implementation Time: Time is money, check estimates with previous customer.
- Customer Referrals: A software vendor that can offer a variety of customer referrals is more likely to have many happier customer than those who cannot.
- Customer Retention: Anything less than 80 percent should raise a flag to ask a question
- Understand Yourself: While it is always good to think where you want to be in five or more years, ensure that system can handle where you are now.
Solution requirements.
To solve the problem, the company should specify the solution to the problem of estimating lead-times and setting lot requirements. First, it must include finite capacity and second, it must allow random events. The scheduling tools which ignore the fundamental problem of random events will not work. Adding random times for arrivals and times for lots let us determine how to change lot sizes as well as estimation of waiting times as utilization changes. Including randomness actually makes the mathematics easier and more accurate. The eventual solution should be extendible to include other factors such as equipment failure and labor sharing issues. The solution should be understandable by the average industrial engineer. It must connect demand, capacity, lot sizes, set up and run times to utilization and match real behavior so that a decrease utilization at a critical machine is reflected by a decrease in the waiting time at that machine.
It’s not a myth
Requirements and problems with the MRP can and have been addressed. The issues with MRP regarding lead-times and lot sizing only can be solved by MRP vendors, not MRP users. Making a wider audience aware of the problems and limitations of current MRP software, along with the fact that solutions are available to vendors, could have a salutary effect. When users ask for better solutions, the MRP vendors will add them to the products they sell.