The MRP II HierarchyFigure 3.3 depicts an instance of the MRP II hierarchy. We use the word instance because there are probably as many different hierarchies for MRP II as there are MRP II software vendors (and there are many such vendors, although most call themselves ERP on "enterprise" software vendors now).

Long-Range PlanningAt the top of the hierarchy we have long-range planning. This involves three functions: resource planning, aggregate planning, and forecasting. The length of the time horizon for long-range planning ranges from around six months to five years. The frequency for replanning varies from once per month, to once per year, with two to four times per year being typical. The degree of detail is typically at the part family level (i.e., a grouping of end items having similar demand and production characteristics).

The forecasting function seeks to predict demands in the future. Long-range fore-casting is important to determining the capacity, tooling, and personnel requirements. Short-term forecasting converts a long-range forecast of part families to short-term forecasts of individual end items. Both kinds of forecasts are input to-the intermediate-level function of demand management. Resource planning is the process of determining capacity requirements over the long term. Decisions such as whether to build a new plant or to expand an existing one are

part of the capacity planning function. An important output of resource planning is projected available capacity over the long-term planning horizon. This information is fed as a parameter to the aggregate planning function.Aggregate planning is used to determine levels of production, staffing, inventory, overtime, and so on over the long term. The level of detail is typically by month and for part families. For instance, the aggregate planning function will determine whether we build up inventories in anticipation of increased demand (from the forecasting function), "chase" the demand by varying capacity using overtime, or do some combination of both. Optimization techniques such as linear programming are often used to assist the aggregate planning process. Intermediate PlanningAt the intermediate level, we have the bulk of the production planning functions. These include demand management, rough-cut capacity planning, master production scheduling, material requirements planning, and capacity requirements planning.The process of converting the long-term aggregate forecast to a detailed forecast while tracking individual customer orders is the function of demand management. The output of the demand management module is a set of actual customer orders plus a forecast of anticipated orders. As time progresses, the anticipated orders should be "consumed" by actual orders.This is accomplished with a technique known as available to promise (ATP). This feature allows the planner to know which orders on the MPS are already committed and which are available to promise to new customers. ATP combined with a capacity-feasible MPS facilitates negotiation of realistic due dates. If more orders than expected are received, so that quoted lead times become excessive, additional capacity (e.g., overtime) might be required. On the other hand, if fewer than expected orders arrive, sales might want to offer discounts or some other incentives to increase demand. In either case, the forecast and possibly the aggregate plan should be revised.Master production scheduling takes the demand forecast along with the firm orders from the demand management module and, using aggregate capacity limits, generates an anticipated build schedule at the highest level of planning detail. These are the "demands" (i.e., part number, quantity, and due date) used by MRP. Thus, the master production schedule contains an order quantity in each time bucket for every item with independent demand, for every planning date. For most industries, these are given at the end item level. However, in some cases, it makes more sense to plan for groups of items or models instead of end items. An example of this is seen in the automobile industry where the exact make and specification of a car are not determined until the last minute on the assembly line. In these situations, a final assembly schedule determines when the exact end items are produced while the master production schedule is used to schedule models. A key input to this type of planning is the superbill of material that contains forecast percentages for the different options of each particular model. For acomplete discussion of superbills in final assembly scheduling, the reader is referred to Vollman et al. (1992).Rough-cut capacity planning (RCCP) is used to provide a quick capacity check of a few critical resources to ensure the feasibility of the master production schedule. Although more detailed than aggregate planning, RCCP is less detailed than capacity requirements planning (CRP), which is another tool for performing capacity checks after the MRP processing. RCCP makes use of a bill of resources for each end item on the MPS. The bill of resources gives the number of hours required at each critical resource to build a particular end item. These times include not only the end item

itself but all the exploded requirements as well. For instance, suppose part A is made up of components Ai and A2. Part A requires one hour of process time in process center 21 while components Ai and A2 require one-half hour and one hour, respectively. Thus the bill of resource for part A would show two and one-half hours for process center 21 for each unit of A. Suppose we also have part B with no components that requires two hours in process center 21.To continue the example, suppose we have the following information regarding the master production schedule for parts A and B:Week 1 2 3 4 5 6 7 8

Part A 10 10 10 20 20 20 20 10

PartB 5 25 5 15 10 25 15 10

The bills of resources for parts A and B are given byProcess Center

Part A Part B

21 2.5 2.0

Then the RCCP calculations for parts A and B at process center 21 are as follows:Week 1 2 3 4 5 6 7 8

Part A (hour) 25Part B (hour) 10Total (hour) 35Available 65 65 65 65 65 65 65 65

Over(+)/under(-) +30

If we had considered only the sum of the eight periods in aggregate, we would have concluded that there was sufficient capacity—520 hours versus a requirement of 510 hours. However, after performing RCCP, we see that several periods have insufficient capacity while others have an excess. It is now up to the planner to determine what can be done to remedy the situation. Her options are to (1) adjust the MPS by changing due dates or (2) adjust capacity by adding or taking away resources, using overtime, or subcontracting some of the work.Notice that RCCP does not perform any offsetting. Thus, the periods used must be long enough that the part, its subassemblies, and its components can all be completed within a single period. RCCP also assumes that the demand can be met without regard to how the work is scheduled within the process center (i.e., without any induced idle time). In this way, RCCP provides an optimistic estimate of what can be done.On the other hand, RCCP does not perform any netting. While this may be acceptable for end items (demand for these can be netted against finished goods inventory relatively easily), it is less acceptable for subassemblies and components, particularly when there are many shared components and WIP levels are large. This aspect of RCCP tends to make it conservative.

These two effects make the behavior of RCCP difficult to gauge. Usually the first approximation tends to dominate the second, making RCCP an optimistic estimation of what can be done, but not always. Consequently, rough-cut capacity planning can be very rough indeed.Capacity requirements planning (CRP) provides a more detailed capacity check on MRP-generated production plans than RCCP. Necessary inputs include all planned order releases, existing WIP positions, routing data, as well as capacity and lead times for all process centers. In spite of its name, capacity requirements planning does not generate finite capacity analysis. Instead, CRP performs what is called infinite forward loading. CRP predicts job completion times for each process center, using given fixed lead times, and then computes a predicted loading over time. These loadings are then compared against the available capacity, but no correction is made for an overloaded situation.6

To illustrate how CRP works, consider a simple example for a process center that has a three-day lead time and a capacity of 400 parts per day. At the start of the current day, 400 units have just been released into the process center, 500 units have been there for one day, and 300 have been there for two days. The planned order releases for the next five days are as follows:Day 1 2 3 4 5

Planned order releases 300 350 400 350 300

Using the three-day lead time, we can compute when the parts will depart the process center. If we ever predict more than 400 units departing in a day, the process center is considered to be overloaded. The resulting load profile is shown in Figure 3.4. The first day shows the load to be 300 (these are the same 300 units that have been in the process center for two days and depart at the end of day one). The second day shows 500; again these are the same 500 that were in for one day at the start of the procedure. Since 500 is greater than the capacity of 400 per day, this represents an overloaded condition.

6Unlike MRP and CRP, true finite capacity analysis does not assume a fixed lead time. Instead the time to go through a manufacturing operations depends on how many other jobs are already there and their relative priority. Most finite capacity analysis packages do some sort of deterministic simulation of the flow of the jobs through the facility. As a result, finite capacity analysis is much more complex than CRP.

FIGURE 3.4 CRP load profile

Note that even when load exceeds capacity, CRP assumes that the time to go through the process center does not change. Of course, we know that it will take longer to get through a heavily loaded process center than a lightly loaded one. Hence, all the estimates of CRP beyond such an overloaded condition will be in error. Therefore, CRP is typically not a good predictor of load conditions except in the very near term. Another problem with CRP is that it only tells the planner that there is a problem; it offers nothing about what caused the problem or what can be done to alleviate it. To determine this, the planner must first obtain a report that disaggregates the load to determine which jobs are causing the problem, and then must use pegging to track the cause back to demand on the MPS. This can be quite tedious.A fundamental flaw with CRP is that, like MRP itself, it implicitly assumes an infinite capacity. This assumption comes from the assumption of fixed lead times that do not depend on the load of the process center. Consider the same process center having no work in it at the start and the following planned order releases, produced with a lot-sizing rule that tends to group demand to avoid setups:Day 1 2 3 4 5

Planned order releases 1,200 0 0 1,200 0

Using CRP, the load profile will show an overloaded condition on day three and day six. If we were to perform finite capacity loading, we would see a very different picture. There would be no output for two days (the first release needs to work its way through), and then we would see 400 units output each day for the next six days. The second release on day four would arrive just as the last of the first release was being pulled into the process center. The basic relations between capacity, work in process, and the time to traverse a process center are the subject of Chapter 7.Thus, in spite of its hopeful introduction and worthy goals, there are fundamental problems with CRP. First, there are enormous data requirements, and the output is voluminous and tedious. Second is the fact that it offers no remedy to an overloaded situation. Finally, since the procedure uses infinite loading and many modern systems can perform true finite capacity loading, fewer and fewer companies are seriously using CRP.The material requirements planning module of all early versions of MRP II and many modern ERP systems is identical to the MRP procedure described earlier. The output of MRP is the job pool, consisting of planned order releases. These are released onto the shop floor by the job release function.3.2.4 Short-Term ControlThe plans generated in the long- and intermediate-term planning functions are imple-mented in the short-term control modules, of job release, job dispatching, and in-put/output control.Job release converts planned order releases to scheduled receipts. One of the impor-tant functions of job release is allocation. When there are several high-level items that use the same lower-level part, a conflict can arise when there is an insufficient quantity on hand. By allocating parts to one job or another, the job release function can rationalize these conflicts. Suppose there are two planned order releases that require component A. Suppose further that there is enough stock on hand of component A for either job to be released but not for both. The first POR also requires component B for which there is plenty of stock, while the other POR requires component C for which there is insufficient stock. The job release function will allocate the available stock to the first POR since there is enough stock of both

components A and B to start the job. A shortage notice would be generated for the second POR, which would remain in the job pool until it could be released.Once a job or purchase order is released, some control must be maintained to make sure it is completed on time with the correct quantity and specification. If the job is for purchased components, the purchase order must be tracked. This is a straightforward practice of monitoring when orders arrive and tracking outstanding orders. If the job is for internal manufacture, this falls under the function known as shop floor control (SFC) or production activity control (PAC). Throughout this book we use the term SFC, as it is more traditional and more widely used. Within SFC are two main functions: job dispatching and input/output control.Job Dispatching. The basic idea behind job dispatching is simple: Develop a rule for arranging the queue in front of each workstation that will maintain due date integrity while keeping machine utilization high and manufacturing times low. Many rules have been proposed for doing this.One of the simplest dispatching rules is known as shortest process time, or SPT. Under SPT, jobs at the process center queue are sorted with the shortest jobs first in line. Thus, the job in the queue having the shortest processing time will always be performed next. The effect is to clear out small jobs and get them through the plant quickly. Use of SPT typically decreases average manufacturing times and increases machine utilization. Average due date performance is also generally quite good, even though due dates are not considered in the ordering.Problems with SPT occur whenever there are particularly long jobs. In such cases, jobs can sit for a long time without ever being started. Thus, while average due date performance of SPT is good, the variance of the lateness can be quite high. One way to avoid this is to use a rule known as SPT*, where x is a parameter. By this rule, the next job to be worked will be the one with the shortest processing time unless a job has been waiting x time units or longer, in which case it becomes the next job. This rule seems to yield reasonably good performance in many situations.If jobs are all approximately the same size and routings are fairly consistent, a good dispatching rule is earliest due date, or EDD. Under EDD, the job closest to its due date is worked on next. EDD exhibits reasonably good performance under the above conditions, but typically does not work better than SPT under more general conditions.Here are three other common rules.Least slack: The slack for a job is its due date minus the remaining process time(including setups) minus the current time. The highest priority is the job with thelowest slack value.Least slack per remaining operation: This is similar to the least slack ruleexcept we take the slack and divide it by the number of operations remaining onthe routing. Again, the highest-priority job has the smallest value.Critical ratio: Jobs are sorted according to an index computed by dividing thetime remaining (i.e., due date minus the current time) by the number of hours ofwork remaining. If the index is greater than one, the job should finish early. If it isless than one, the job will be late; and if it is negative, it is already late. Again, thehighest-priority job has the smallest value of the critical ratio.There are at least 100 different dispatching rules that have been offered in the operations management literature. A good survey of many of these is found in Blackstone et al. (1982), where the authors test various rules by using a simulated factory under a broad range of conditions.

Of course, no dispatching rule can work well all the time, because, by their very nature, dispatching rules are myopic. The only consistent way to achieve good sched-ules is to consider the shop as a whole. The problem with doing this is that (1) the shop scheduling problem is extremely complex and can require an enormous amount of computational time and (2) the resulting schedules are often not intuitive. Input/Output Control. Input/output (I/O) control was first suggested by Wight (1970) as a way to keep lead times under control. I/O control works in the following way:1. Monitor the WIP level in each process center.2. If the WIP goes above a certain level, then the current release rate is too high, so reduce it.3. If it goes below a specified lower level, then the current release rate is too low, so increase it.4. If it stays between these control levels, the release rate is correct for the current conditions.The actions—reduce and increase—must be done by changing the MPS.I/O control provides an easy way to check releases against available capacity. How-ever, by waiting until WIP levels have become excessive, the system has, in many respects, already gone out of control. This may be one reason that so-called pull systems (e.g., Toyota's kanban system) may work better than push systems such as MRP, MRP II, and ERP. While these systems control releases (via the MPS) and measure WIP levels (via I/O control), kanban systems control WIP directly and measure output rates daily. Thus, kanban does not allow WIP levels to become excessive and detects problems (i.e., production shortfalls) quickly.

Beyond MRP II—Enterprise Resources PlanningIn the years following the development of MRP II, a number of would-be successors were offered by vendors and consultants. MRP III never quite caught on, nor did the indigestibly acronymed BRP (business requirements planning). Finally, in spite of its gastronomically unpleasant acronym, enterprise resources planning (ERP) has emerged victorious.This is due largely to the success of a few vendors, notably SAP, who have targeted not only manufacturing operations but all operations (e.g., manufacturing, distribution, accounting, financial, and personnel) of a company. Hence, the system offered is designed to control the entire enterprise.SAP's R/3 software is typical of an interwoven comprehensive ERP system. The system can "act as a powerful network that can speed decision-making, slash costs, and give managers control over global empires at the click of a mouse," according to Business Week (Edmonson 1997). Within such "trade hype" is a kernel of truth. ERP systems are linking information together in ways that make it much easier for upper management to have a more global picture of operations in almost real time.Advantages of this integrated approach include1. Integrated functionality2. Consistent user interfaces3. Integrated database4. Single vendor and contract5. Unified architecture and tool set6. Unified product supportBut there are also disadvantages, including* 1. Incompatibility with existing systems

2. Long and expensive implementation3. Incompatibility with existing management practices4. Loss of flexibility to use tactical point systems5. Long product development and implementation cycles6. Long payback period7. Lack of technological innovationIn spite of any of these perceived drawbacks, ERP has enjoyed remarkable success in the marketplace, as we discuss below.

History and Success of ERPThe success of ERP is at least partly due to three coincident undercurrents preceding its development. The first is recognition of a field that has come to be called supply-chain management (SCM). In many ways, SCM extends traditional inventory control methods over a broader scope to include distribution, warehousing, and multiple production locations. Importantly, defining a function called supply-chain management has led to an appreciation of the importance of logistical issues. We see the importance of this area reflected in the growth of trade organizations such as the Council of Logistics Management, which grew from 6,256 members in 1990 to almost 14,000 in 1997.The second trend that spurred acceptance of ERP was the business process reengineering (BPR) movement (see Hammer and Champy 1993). Prior to the 1990s, few companies would have been willing to radically change their management structures to support a new software package. But BPR has taught managers to think in terms of radical change. Today, many managers feel that one of the benefits of ERP implementation is the chance to reengineer their operations.The third trend is the explosive growth in distributed processing and the power of smaller computers. An MRP run that took a weekend to run on a million-dollar computer in the 1960s can now be done on a laptop in a few seconds. Instead of a central repository for all corporate data, information is now stored where used on a personal computer or a workstation. These are linked via an intracompany network, and the data are shared by all functions. The latest offerings of ERP vendors are designed with exactly this architecture in mind (Parker 1997).The growth of ERP sales indicates the degree of its acceptance. In 1989 total sales for MRP II at $ 1.2 billion accounted for just under one-third of the total software sales in the United States (Industrial Engineering 1991). Worldwide sales for the top 10 vendors of ERP alone were $2.8 billion in 1995, $4.2 billion in 1996, and $5.8 billion in 1997 (Michel 1997). One company, SAP, alone sold more than $3.2 billion in ERP software in 1997 (Edmonson 1997).However, large sales of software are not the whole picture. Many companies are disenchanted at the sometimes staggering cost of implementation. In a survey of Fortune 1000 firms that had implemented ERP, 44 percent reported they spent at least four times as much on implementation help (e.g., consultants) as on the software itself. We are aware of several companies that have canceled projects after sepending millions, not wanting to "throw good money after bad."Nonetheless, in spite of the high cost, some companies report enormous productivity improvements. Bob Barett, vice-president at Monsanto Co., finished installing the accounting module of SAP in July 1996. He cited the software as responsible for a reduction in the planning cycle from six weeks to three, lower inventories, less working capital, an increase in its bargaining power with suppliers, all of which led to an estimated savings of $200 million per year to the company (Edmonson 1997).