Making MRP work - Institute of Industrial and Systems ...MRP 2 systems cannot estimate wait-ing...

6
November 2011 35 November 2011 35 MRP work Vendors must address long-standing problems with capacity planning, lot sizes and lead-times By Gregory W. Diehl & Aaron J. Armstrong Making

Transcript of Making MRP work - Institute of Industrial and Systems ...MRP 2 systems cannot estimate wait-ing...

Page 1: Making MRP work - Institute of Industrial and Systems ...MRP 2 systems cannot estimate wait-ing times or provide a coherent and satisfactory method for dynamically generating lot sizes.

November 2011 35November 2011 35

MRP workVendors must address long-standing problems with capacity planning, lot sizes and lead-timesBy Gregory W. Diehl & Aaron J. Armstrong

Making

Page 2: Making MRP work - Institute of Industrial and Systems ...MRP 2 systems cannot estimate wait-ing times or provide a coherent and satisfactory method for dynamically generating lot sizes.

36 Industrial Engineer36 Industrial Engineer

making mrp work

Materials requirements planning (MRP 1), developed in the 1960s and 1970s, offered an important break-through for shop floor managers by linking production plans for finished goods with the supply of the compo-nent 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 plan-ning, lot sizing and their implications for lead-times, often assumed to be static in MRP 2 systems regardless of sched-uled 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 wait-ing times or provide a coherent and satisfactory method for dynamically generating lot sizes. Contrast this with MRP 1, which has a mathematical foun-dation 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

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-in-process (WIP) carrying cost. Several problems are inherent in using EOQ in manufacturing because it ignores some fundamental issues, such as finite capac-ity. 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 ignoredThe internal portion of the manufac-turing 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 ignor-ing 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, some-one 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-utiliz-

ing the machine. Once this happens, the machine will become a bottleneck and build up a backlog. This will require over-time 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 fixedScrapping 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

Page 3: Making MRP work - Institute of Industrial and Systems ...MRP 2 systems cannot estimate wait-ing times or provide a coherent and satisfactory method for dynamically generating lot sizes.

November 2011 37

directions, none can provide actual numbers to use for these parameters as inputs for MRP. Take the short ques-tion, “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 woesA simple Internet search of “problems with MRP” reveals that the second most common issue is MCT, just behind data-related 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 prod-uct 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

Page 4: Making MRP work - Institute of Industrial and Systems ...MRP 2 systems cannot estimate wait-ing times or provide a coherent and satisfactory method for dynamically generating lot sizes.

38 Industrial Engineer

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 ship-ping 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 consid-ered adequately within current MRP systems. They all assume that utilization, lot sizes and waiting times are indepen-dent of each other, and you can change one without affecting the others. This is exactly where MRP needs to start work-ing 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 recommenda-tions 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 differ-ent 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 produc-tion 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 repairDo you know what the mean time to repair (MTTR) is for your machines? Does your MRP ask for this informa-tion? 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 equip-ment 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 utili-zation 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 fail-ure (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 utiliza-tion. 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 back-log. 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 impor-tant. 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 effortsDown 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 one-fourth 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 analy-sis include that work arrives at the same rate whether the equipment is running or not and that the level of backlog at a

making mrp work

Page 5: Making MRP work - Institute of Industrial and Systems ...MRP 2 systems cannot estimate wait-ing times or provide a coherent and satisfactory method for dynamically generating lot sizes.

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 aver-age 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 deter-mines 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

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 prob-lems. 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

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 with equipment failures

Time

WIP

+ b

ackl

og

MTTR 10

MTTR 3

MTTR 1

Baseline WIP

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.

erp necessities

November 2011 39

Page 6: Making MRP work - Institute of Industrial and Systems ...MRP 2 systems cannot estimate wait-ing times or provide a coherent and satisfactory method for dynamically generating lot sizes.

40 Industrial Engineer

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 requirementsNext, specify what a solution to the prob-lem 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 exam-ple) 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.

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 prob-ability 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-or-minus 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 aver-age 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 mythThis 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 anal-ysis 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 lead-times 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 limi-tations 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 consult-ing 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 develop-ment engineer and engineering manager with John Deere, where he worked in supply chain optimization and the improvement of supplier manufacturing operations.

making mrp work

Prob

abili

tyFigure 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.

probable success

Time