APICS - The Performance Advantage
March 1998 • Volume 8 • Number 3


JIT vs. MRP
Unmasking the Great Push-Pull Myth


Many in industry are now of the opinion that the pull process is good and a push system is bad. But is this really true? To settle this debate it is useful to explore the origins of both systems and then look at them in light of today�s computer system technology.

By Bob Millard

Taiichi Ohno, the former executive vice president of Toyota, developed an innovative manufacturing planning, scheduling and execution system called the Toyota Production System. However, most people know this process by other names such as kanban or Just-in-Time. Kanban is a Japanese word for the cards that were used in Toyota automobile fabrication and assembly operations to authorize (1) delivery of a lot of material from the producing work center to the using work center and (2) the manufacture of a specified quantity of material by the producing work center.


Push Versus Pull
The concept of the using work center authorizing product movement and production was the genesis for the "pull" concept. In other words, the final assembly work center was the driving force since it had the best information about demand that was to be shipped. Its objective was to satisfy actual demand. Consequently, it issued kanbans to its supplying work centers only for items it needed. Likewise, the supplying work centers issued kanbans to their supplying work centers only for the items they needed. This process reduced the probability of producing either too many items or producing items for which there was no current demand.

The using work center had to authorize both material movement and production before a supplying work center or supplier could take action. Toyota's "pull" process has been contrasted with what is now commonly defined as the "push" system. Pushing production is the process of making schedules for production that may or not be feasible and then trying to "push" (i.e., expedite, split orders, etc.) the orders through the shop to meet the system specified due date.

Push systems are typically associated with MRP systems which employ a process known as infinite loading. Infinite loading makes the assumption that the requirements that begin the MRP process (i.e., either a master production schedule, open sales orders or repetitive schedule) can be satisfied by a combination of existing inventory and work-in-process plus open work orders, planned work orders and purchase orders suggested as a result of running MRP.

APICS defines the terms push and pull in the following manner:

  • Pull (system) — 1) In production, the production of items only as demanded for use or to replace those taken for use. 2) In material control, the withdrawal of inventory as demanded by the using operations. Material is not issued until a signal comes from the user.

  • Push (system) — 1) In production, the production of items at times required by a given schedule planned in advance. 2) In material control, the issuing of material according to a given schedule or issuing material to a job order at its start time.

It is interesting to see what has happened over time. A pull process is now regarded as "good," and a push system is regarded as "bad." Is this really true? It is useful to look at the origins of both systems and then look at them considering today's computer system technology.


The Genesis of the Pull System
Taiichi Ohno recognized some important truths in 1950 when Toyota was beginning to try to exploit the U.S. automobile market:
  • Toyota did not have the capital to invest in large factories and large inventories.

  • Toyota did not have the capital or the expertise to invest in expensive computer systems for planning and scheduling production.

At the end of World War II, Toyoda Kiichiro, president of Toyoda Motor Company presented Ohno with a daunting challenge, "Catch up with America in three years. Otherwise the automobile industry of Japan will not survive."1 Ohno knew that American mass production methods at the time were not efficient or cost effective, so he chose another route. He devised and first implemented a manual system in 1952 that employed two cards — kanbans — to control the rate of production based upon demand. He realized an important fact. Demand should control production. Building inventory that will not be shipped to customers is not an effective use of resources. What a concept!

Ohno defined the functions of kanban in the following way — It:

  1. provides pick-up or transport information
  2. provides production information
  3. prevents over-production and excessive transport
  4. serves as a work order attached to goods
  5. prevents defective products by identifying the process making the defectives
  6. reveals existing problems and maintains inventory control

However, the Toyota Production System was not only restricted to the use of kanbans. It was also concerned with the manufacturing process itself.

"To improve process flow, Ohno decided that instead of putting the machines of one process together (i.e., all the lathes together, all the presses together, etc.) and having to carry parts back and forth between processes, he would lay out the plant according to the operation flow. He then assigned one worker to more than one machine."

Ohno recognized that elimination of waste was essential for the Toyota Production System to be successful. He felt that one of the primary objectives of his system was to identify the:

  • waste of overproduction
  • waste of waiting
  • waste of transportation
  • waste of processing
  • waste of inventory
  • waste of making defective products

    Ohno further observed:

    "It requires talent and courage to �rethink common sense' when implementing kanban. Top management must commit to reversing its way of thinking about the conventional flow of production, transfer and delivery. The process basically must be looked at backwards, since later processes are picking up material from earlier ones.

    "This requires committing to no longer producing as much as possible, either. Production is now driven by demand, not by capacity. The multi-process system can now be used because workers are not needed to tend one machine all day, making as much product as possible. Instead, they are required to make only as much as needed. The machine can be idle the rest of the time."

    It took Ohno 10 years to implement the Toyota Production System in all of Toyota's facilities, but the results were certainly impressive by anyone's standards. Furthermore, it was not just a scheduling and shop floor control tool. The Toyota Production system included what we now term business process reengineering. However, it must be kept in mind that Toyota was building cars, and there were not as many models with as many options as there are today. You can imagine how difficult it might have been to have operated a kanban system if there had been more customers having different needs.

    One of the virtues of MRP is the periodic explosion of the bills of material so that changes in demand quantities or demand requiring different parts will result in planned orders for items needed for work orders or purchase orders that do not yet exist. The initial kanban system depended on information flowing backward from final assembly. Consequently, to the extent that change was not recognized promptly for parts at the bottom of the assembly tree, the final assembly schedule would have been adversely affected because of the delay in getting the latest demand information.


    A Short History of Production Planning & Scheduling
    Before MRP, companies used fixed order point and order quantity systems to control inventory. When inventory reached the order point, planners would create work orders or purchase orders according to the quantities dictated by the order point system. Of course, in an order point system, orders might be created when there was insufficient demand to justify the quantity of the supply orders, or orders might be generated for quantities that were inadequate to satisfy the demand. These two problems prompted the birth of MRP. It was a truly innovative idea. Balance supply with demand and provide the user with suggested time-phased work orders and purchase orders as well as suggestions to cancel or delay firm orders not released or orders already released.

    Although the initial MRP systems were a significant improvement over order point replenishment systems, they shared a significant weakness that wasn't to be addressed for a number of years. The MRP system planning model assumes that the time-phased supply (on-hand inventory, work-in-process, planned work orders, open purchase orders and planned purchase orders) will equal time-phased demand (firm orders and forecast orders or master scheduled orders). However, MRP users soon found that there was no way of determining whether the planned orders could be completed by their scheduled due date or not. It was one thing to issue planned work orders, but what if the "plan" was not feasible for some work centers? Simply issuing work orders to the shop was not satisfactory if there was no reasonable expectation that they would be completed by their scheduled completion dates. If that quandary were not enough, it became quite apparent that MRP permitted the creation of planned orders that had start dates for work orders before the current date.

    The answer to this dilemma was the eventual addition of four new modules to the MRP systems and a revision to the MRP module:

    • A process and routing module which permitted the maintenance of setup and run time standard information so that it was possible to know how long it would take to make a specified order quantity in terms of standard hours.

    • A work center module that described the number of hours per day a work center was available and how many machines/workers were normally available by shift.

    • A work-in-process module that showed the location of work orders in the shop and their status in terms of quantities completed at each operation.

    • A capacity requirements planning (CRP) module that took data from the three foregoing MRP modules and the MRP plans and provided reports showing the load versus capacity for all of the work centers so that bottlenecks could be identified.

    • A revision to the MRP module that enabled users to create repetitive schedules by date range. For example, with a repetitive schedule option you can assign a part as repetitively planned, and no individual work orders need to be issued. It is only necessary to specify the quantity per day to be produced for the part and the start and completion date for that rate. MRP treats a repetitive schedule as a supply in the same way as work orders. In fact, the system actually creates and closes internal work orders, but the users need only control the rate quantity and its horizon.

    How Do Kanban and MRP Currently Compare?
    As with any system, performance is largely dependent upon the skill of the user. Some kanban systems may work very well, and others may not. Some MRP systems may work very well, and others may not. The virtue of kanban was that it was supposedly driven by demand, but MRP is presumably driven by demand as well. Kanban is thought to have smaller lot sizes than MRP, but users determine lot sizes in both systems. In theory, the ultimate kanban quantity is one or, at least, a very small quantity. Many companies have created cells to minimize the work-in-process, so it is possible for both kanban and MRP systems to minimize the amount of work on the shop floor.

    MRP still has some design limitations that limit its effectiveness for planning and controlling work. For example, the MRP module is run before CRP; consequently, you wouldn't know that the MRP plan may suggest completion dates for work orders that CRP subsequently determines are not achievable. Kanban systems also may have some limitations depending on the extent to which demand changes are made known to work centers down the assembly tree from the final assembly areas.


    Are the Terms Push and Pull Still Relevant?
    It is too simplistic to label systems as either push or pull with their respective "bad" and "good" connotations. How would one label a well-run MRP system that has realistic due dates and low work-in-process and which doesn't run machines just to keep them busy? Similarly, how would you label a kanban operation that isn't driven by an accurate demand forecast or which doesn't have a means for adapting rapidly to changes in demand or which doesn't synchronize work to its bottlenecks?

    What is very relevant is Ohno's statement, "Production is now driven by demand." To be competitive, companies must clearly understand their customer demand and possess a planning and control system that will respond to that demand to the customer's satisfaction. In other words, the domain where the term "pull" is really appropriate is the marketplace. What companies need to understand better is that there are two processes that need to be in sharper focus, namely:

    1. demand forecasting
    2. selection and effective use of the best possible tool to respond to that demand.

    FRP Coupled with Better Demand Forecasting Equals Lean Manufacturing
    Fortunately, there are planning and control processes now available that make the push/pull issue essentially irrelevant. There are demand forecasting systems that make it easier to know what customers will be needing in the planning horizon, and there are finite resources planning (FRP) engines now available that replace the MRP2 or kanban planning engine of manufacturing computer systems and provide the capability to produce Just-in-Time schedules. Significantly, these engines have the capability to perform finite scheduling both backwards and forward while MRP engines can only schedule backwards.

    FRP engines focus on bottlenecks and enable users to perform "what if" scenarios to resolve scheduling problems and also to provide reliable commitments to new orders or accurate estimates for customer quotations. By concentrating on bottlenecks, FRP systems enable users to synchronize the activities of work centers feeding the bottlenecks so that only enough material is produced to satisfy actual and forecasted demand. FRP is designed to maximize factory throughput.

    Who would have guessed in 1970 the extent to which computers would become a part of our lives at work and at home? MRP systems have changed significantly since the birth of the first system in the late 1950s. Ollie Wight later coined the term MRP II to show the significance of innovative systems at the time compared with more basic versions; and John Kanet, a professor at Clemson University wrote (with tongue in cheek) of MRP-963 to show how far MRP had come since MRP II.

    Similarly, FRP systems are really still in their infancy, and users can expect continued improvement, but these systems have already proven that they are worthy of consideration. Replacing kanban or the MRP engine with an FRP engine is a good first step to obtaining better control of the manufacturing planning process, but companies need to look outside the production planning arena to get the maximum improvement possible. Demand forecasting is an arena that warrants much more attention than it now gets. If a company really understands the nature of its customer demand and learns to forecast it with reasonable accuracy, FRP systems operated by skilled users will provide the schedules that will make any company a lean manufacturer.

    Forget about push and pull. Think about FRP and demand forecasting. These are the processes that companies need to have in place and working at peak performance to improve the bottom line and keep customers happy.

    References
    1. Ohno, Taiichi, "Toyota Production System: Beyond Large-Scale Production," 1978; http://150.135.13.100/am3/beyond.html

    2. Millard, Bob, "Good Bye MRP, Hello FRP," APICS — The Performance Advantage, August 1996.

    3. Kanet, John J., "MRP-96: Time to Rethink Manufacturing Logistcs," (Undated).


    Bob Millard is a principal at Resource Management Associates, Encinitas, Calif.

    For more information about this article, input the number 2 in the appropriate place on the March Reader Service Form

    Copyright © 1998 by APICS — The Educational Society for Resource Management. All rights reserved.

    Web Site © Copyright 2020 by Lionheart Publishing, Inc.
    All rights reserved.


    Lionheart Publishing, Inc.
    2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
    Phone: +44 23 8110 3411 |
    E-mail:
    Web: www.lionheartpub.com


    Web Design by Premier Web Designs
    E-mail: [email protected]