The MRP II Hierarchy
Figure 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 Planning
At 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 forecasting 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 Planning
At 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 capacityfeasible 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 a
complete 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 by
Process
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
Part A (hour)
25
Part B (hour)
10
Total (hour)
35
Available
65
Over(+)/under(-)
+30
2
3
4
5
6
7
8
65
65
65
65
65
65
65
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.
6
Unlike 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 lotsizing 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 Control
The plans generated in the long- and intermediate-term planning functions are implemented in the short-term control modules, of job release, job dispatching, and input/output control.
Job release converts planned order releases to scheduled receipts. One of the important 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 the
lowest slack value.
Least slack per remaining operation: This is similar to the least slack rule
except we take the slack and divide it by the number of operations remaining on
the routing. Again, the highest-priority job has the smallest value.
Critical ratio: Jobs are sorted according to an index computed by dividing the
time remaining (i.e., due date minus the current time) by the number of hours of
work remaining. If the index is greater than one, the job should finish early. If it is
less than one, the job will be late; and if it is negative, it is already late. Again, the
highest-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 schedules 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. However, 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 Planning
In 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 include
1. Integrated functionality
2. Consistent user interfaces
3. Integrated database
4. Single vendor and contract
5. Unified architecture and tool set
6. Unified product support
But there are also disadvantages, including
*
1. Incompatibility with existing systems
2. Long and expensive implementation
3. Incompatibility with existing management practices
4. Loss of flexibility to use tactical point systems
5. Long product development and implementation cycles
6. Long payback period
7. Lack of technological innovation
In spite of any of these perceived drawbacks, ERP has enjoyed remarkable success in
the marketplace, as we discuss below.
History and Success of ERP
The 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).