Making MRP work Vendors must address long-standing problems with capacity planning, lot sizes and lead-times By Gregory W. Diehl & Aaron J. Armstrong November 2011 35
making mrp work Materials requirements planning (MRP 1), developed in the 1960s and 1970s, offered an important breakthrough for shop floor managers by linking production plans for finished goods with the supply of the component parts required to achieve those plans. The idea was to ensure that enough of the correct components were on hand to build assemblies, such as cars, before the parts were needed. Recognizing that labor and machines were key requirements, manufacturing resource planning (MRP 2) extended the idea of production requirements to include the number of labor-hours and machine-hours needed at each work center in a plant. However, as is so often the case, providing insight and structure to address one set of issues often reveals deeper and more complex challenges that managers must address. Initial stopping point Such is the case with MRP 2 and the fundamental questions of capacity planning, lot sizing and their implications for lead-times, often assumed to be static in MRP 2 systems regardless of scheduled labor or machine utilization. These systems had no mathematical foundation to describe the numerical relationship between capacity, lot sizes and lead-times. Thus, MRP 2 and enterprise resource planning (ERP) systems cannot account for how these three measures interact. MRP 2 systems cannot estimate waiting times or provide a coherent and satisfactory method for dynamically generating lot sizes. Contrast this with MRP 1, which has a mathematical foundation that calculates the number of components an assembly needs. Even scrap in production and in assembly is included as a more complex calculation. MRP 2 systems turned the responsibility of estimating waiting times over to the user as an input rather than managing or 36 Industrial Engineer even calculating this critically important output. MRP 2 provided many different ways to set lot sizes, the most sophisticated one being economic order quantity. EOQ is used in retail situations to trade off order costs with stock carrying costs. In manufacturing, however, one is trading off the setup costs with the work-inprocess (WIP) carrying cost. Several problems are inherent in using EOQ in manufacturing because it ignores some fundamental issues, such as finite capacity. As a result, the lot sizes it generates can have a negative impact on waiting times. Furthermore, other common lot sizing methods have even more failings. Critical information ignored The internal portion of the manufacturing critical-path time (MCT) is the amount of time needed to get a part from raw materials to finished goods. MCT determines how far in advance customers must call to get reorders. Even if you have a warehouse and are making to stock, the problem remains. It s just buried within your internal operations, and this delay emerges when your warehouse calls for a reorder. If the quoted MCT is too short, you have late starts and late deliveries. If it is too long, you have too much WIP on the floor, too much capital tied up in WIP, and too much material and money in finished goods. If your company decides via MRP/ERP when to start production to meet demands, it most likely is ignoring the true MCT that determines when production should start. The lot size is the number of pieces made in one run before a machine is changed over or set up to run a different part. In all production situations, someone or something will have to make this decision. If the lot size is set too small, the number of setups required will be so large that eventually all of the machine s available time will be used up, over-utilizing the machine. Once this happens, the machine will become a bottleneck and build up a backlog. This will require overtime or transferring some work to other machines. If lot sizes are too large, MCT will grow longer needlessly, and too much inventory will build up in all the parts produced by the machine as everything will have to wait for the expanded lot size to be completed. Lot size is one of the most powerful tools you can use to reduce MCT and become leaner and more responsive to customer demand. The lot size also affects MCTs indirectly by changing machine utilization and the coordination of work between different work centers. It is an easy operational parameter to change, far easier than changing setup and run times or capacity. However, it is an extremely difficult 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 hampers the profitability of their customers. Why this must be fixed Scrapping the MRP system still leaves the basic problems of deciding lot sizes and lead-times. If you manufacture, you decide the amount (the lot size) and the time to start (due date minus the MCT). If you eat, you decide the amount and the time to start. No matter what you decide to manufacture (or eat), decisions must and will be made. After doing lean, theory of constraints, Six Sigma, just in time, or any other buzzword-based methodology, and after any kaizen events, consultants, setup reductions and engineering tuneups, you ultimately return to MRP and are hamstrung by its inability to manage lot sizes and MCTs effectively. Although some methodologies can provide rough
directions, none can provide actual numbers to use for these parameters as inputs for MRP. Take the short question, To get a 25 percent cut in MCTs, how much overtime must I add, and how much should I change my lot sizes? No current MRP system or add-on will provide an accurate answer. Advanced production scheduling (APS) won t provide an accurate answer either, as will be detailed later. It is precisely after using lean, theory of constraints and whatever else that you are most in need of a change in lot sizes and MCT estimates. You have done the hard work of improving the manufactur- ing system, but you need new lot sizes and MCTs to realize the value of these changes. MRP woes A simple Internet search of problems with MRP reveals that the second most common issue is MCT, just behind datarelated issues. A reasonably experienced MRP user usually can deal with the first problem sufficiently, but even then there remains the underlying issue that a user cannot hope to address directly. One Wikipedia writer sees the issue with as much clarity as possible: Another major problem with MRP systems is the requirement that the user specify how long it will take 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. This is not merely operator error; it is a systemic and structural problem with the current MRP framework. Setting MCTs is what defines MRP 2. If the MRP system does not suggest MCTs, it is simply MRP 1 with holes or places where a user enters November 2011 37
making mrp work the MCT estimates. MRP problems include a number of distinct issues that must be addressed if MRP is going to work the way it needs to. For example, users cannot presume that capacity is infinite. For shipping via UPS or FedEx, you can assume infinite shipping capacity. Their shipping capacity is their problem, not yours. Your problem is managing shop capacity. You can assume that your shop has infinite capacity if pigs can fly and mules can foal. It is better to work in the real world. The second issue is that any decent foreperson with simple observation skills knows the following three observations to be true. First, the use of the bottleneck affects the estimated waiting times. In addition, using the bottleneck should affect the choice of lot sizes. Finally, the lot size of one part affects 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 the others. This is exactly where MRP needs to start working and not go AWOL. It needs to tell the user what a change in utilization or lot sizes does to lead-times. The third issue is a set of systemwide concerns. Do the lot size recommendations even guarantee a feasible schedule? For example, is utilization less than 100 percent? How do you calculate waiting times? Asking the user for an estimated waiting time at a workstation is no different than a consultant asking for your watch and telling you that in two hours it will be 3 o clock. In Principles of Operations Research, published in 1975, Harvey Wagner states that 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 for one part does not affect the waiting time of any part, not even for the part we are choosing the lot size for. Mean time to repair Do you know what the mean time to repair (MTTR) is for your machines? Does your MRP ask for this information? Unless repair times are tiny, they will have a big impact on lead-times since the repair time determines the size of the backlog that develops during an equipment failure. We now turn aside for a moment to see the effects of MTTR and the backlog. We also will see how the equipment failure and repair can be used as an analogy for other phenomena within manufacturing systems. Down time will affect the utilization of an equipment group. The mean time to repair also is a critical number for computing MCT and WIP. The MTTR determines the size of the backlog that builds at the machine, which directly affects the WIP and MCT. Estimating these numbers is quite easy. Now suppose a user specifies any two of three values: mean time to failure (MTTF), mean time to repair and percentage down time. Any two of these numbers determines the third, but they do not affect setup and run time utilization. The effect on lead-time depends on MTTR and the utilization. A machine with low utilization will not generate much backlog, whereas a machine with high utilization will have a bigger backlog. The length of the breakdown or MTTR determines the size of the backlog that will develop. Utilization obviously determines how long it will take to clear the backlog. This illustrates why MTTR is so important. Consider an office with 10 percent down time. Losing six minutes on the hour every hour isn t too hard to handle. Missing a day every other week is a bit trickier, but losing a whole week every two and a half months puts a wrench in the works. Scheduling the lost week would make the problem simpler, but you can t schedule when equipment will fail. In a busy office a lot of work will not get done, creating backups during down time. Resolving the backlog requires a lot of rescheduling, which can be difficult, particularly if the length of the down time is highly variable. Calculating these efforts 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 the utilization determine these numbers. A simple approach can calculate these effects. If U 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. For example, 80 percent utilization (U) multiplied by a 10-hour MTTR creates an eight-hour backlog during 10 hours of down time (0.8 x 10 = 8). In addition, 1-U tells us the rate at which the backlog is removed. So a machine with 75 percent utilization removed one-fourth of an hour of backlog per one hour of clock time (1-0.75 = 0.25). Inverting 1-U calculates the time needed to clear the backlog. A machine with a 75 percent utilization clears onefourth of an hour of backlog per hour (1/ (1-0.75) = 1/(0.25) = 4). This machine, once repaired, will take four hours of clock time to clear one hour of backlog. Putting it all together, MTTR x U/ (1-U) equals the number of hours needed to clear the backlog from the equipment failure. Reasonable assumptions in this analysis include that work arrives at the same rate whether the equipment is running or not and that the level of backlog at a 38 Industrial Engineer
wip with equipment failures Figure 1. This chart shows WIP backlog caused by equipment failures for different mean time to repair (MTTR) values. The percentage down time is 10 percent in all cases. WIP + backlog machine does not affect repair time. The third assumption is that the machine runs at the same speed regardless of the backlog s size. The analysis looks only at the average arrival of work and the average rate at which the backlog is cleared. The equation above and Figure 1 show how critical MTTR is. Figure 1 presents results from three situations where the only difference is MTTR. The MTTR values are one, three and 10 hours, with the same equipment utilization (80 percent) and down time percentage (10 percent). The average extra WIP or backlog is 12, three and one respectively. There is a matching lead-time effect as well. 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. In Figure 1, the green peaks stacked on top of each other create a yellow peak, while the yellow peaks stacked on top of each other equal the red peak. At their best, current MRP systems handle equipment failures by subtracting Time MTTR 10 MTTR 3 MTTR 1 Baseline WIP down time from available hours. Taking the percentage down time off the top assumes that repairs are frequent but short. You just expand the time to set up and run a lot. But this assumes that a long down time never occurs, and the random large backlog causes the lead-time problems. Failure to admit a possible problem is a failure to plan, which often turns into a plan to fail. If an APS ignores equipment failures, the entire red, yellow and green areas in Figure 1 will be ignored. If the APS includes a downtime set-aside, it assumes that the MTTR is small, with a worst-case scenario far better than the green area. But reality may be closer to the yellow or red areas in Figure 1. This problem often is addressed by scheduling equipment failures. Alas, that will happen only when you pick up a guinea pig by its tail. Note that guinea pigs don t have tails. 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 erp necessities Although many 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: While important, don t base your selection on platform alone because high-caliber functionality might compensate for the platform difference. Technology: The vendor should be on the leading edge to keep your system up to date. Number 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. Don t be afraid to 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 customers. Customer referrals: A software vendor that can offer a variety of customer referrals is more likely to have many happier customers 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 the system can handle where you are now. November 2011 39
making mrp work probable success Figure 2. This probability of setup plus run time for a lot at a work center shows a realistic view of the time needed to complete manufacturing a lot. Probability for a lot instead of the down time. A larger lot size requires fewer lots to arrive, but each lot creates a bigger backlog of work. Increasing the lot size changes us from green to yellow to red areas in Figure 1. The figure simply displays the effect the lot size of one part has on the waiting time and WIP level of the other parts. Or stating it most clearly, the lot size of one part affects the waiting time of all the other parts. Current MRP/ERP software fails this basic reality test because they all assume that the lot size of one part has no effect on any other part s waiting time. Solution requirements Next, specify what a solution to the problem of estimating lead-times and setting lot sizes requires. First, it must include finite capacity, discussed above, and second, it must allow for random events. Better scheduling tools (APS, for example) will not work because they ignore the fundamental problem of random events (i.e., life happening). Although life would be easier to control without random events, it is better not to pretend they don t exist. As it turns out, including random events allows a solution to most of the problems outlined above. Adding random times for arrivals and times for lots let us determine how to change lot sizes as well as estimates of waiting times as utilization changes. Time Figure 2 shows a more realistic view of the time needed to complete a lot. The spread or width to the bell-shaped curve is added around the average or mean value. The figure displays the probability distribution for the time needed to complete a lot (i.e., setup time + run time per piece x lot size). The X-axis is the time, and the Y-axis is the probability that the X value is the actual time. You can see the standard bell-shaped curve with a mean in the middle and the sides spread out. The amount of spread is the standard deviation, or the plus-orminus term. If the time is assumed to be always and exactly the mean, the sides of the bell are collapsed into the mean, and it has a standard deviation of zero, which is unrealistic. The assumption of APS that the standard deviation is zero denies the second law of thermodynamics the existence of entropy. Including randomness in the analysis actually makes the mathematics easier and more accurate. The eventual solution should be extendible to include other factors such as equipment failures and labor sharing issues (i.e., three people running five machines). The solution should be understandable by the average industrial engineer. It must connect demand, capacity, lot sizes, setup and run times to utilization, WIP, and lead-time estimates. It must match real behavior so that a decrease in utilization at a critical machine is reflected by a decrease in the waiting time at that machine. It s not a myth This may sound like a search for the Holy Grail. But the requirements and problems with MRP can and have been addressed. The appropriate mathematics has been known for more than 100 years. For more than 30 years industrial engineering professors have been using it in the analysis of manufacturing systems. Software has been available in the marketplace for about 25 years, but it has not been widely adopted. The most important reason, as far as can be seen, is the lack of a tight connection to MRP/ERP systems. The issues with MRP regarding leadtimes and lot sizing only can be solved by MRP vendors, not MRP users. And the solutions have been available to MRP companies for years. 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. But this will happen only if the reader completes the circle. When users ask or demand better solutions, the MRP vendors will add them to the products they sell. d Since earning his Ph.D. at Harvard University, Gregory W. Diehl has spent his career consulting about the performance of manufacturing systems. He has designed and built software for consultants and analysts to use in the field of dynamics of manufacturing systems. Aaron J. Armstrong is an assistant professor of industrial engineering at the Milwaukee School of Engineering. He is a former supplier development engineer and engineering manager with John Deere, where he worked in supply chain optimization and the improvement of supplier manufacturing operations. 40 Industrial Engineer