MRP appeared with the advent of computers capable of producing production and inventory plans. Previously manufacturing plans and the supply of raw materials and purchased components were managed by one of two approaches:
The wide availability of computer processing eliminated the need to manually 'explode' the top level programme. The clerical effort was replaced by Bill of Material Processing (BOMP). As further sophistication (for safety levels, batching rules and scrap allowances) was introduced the phrase Material Requirements Planning was coined. The general willingness to seize and propound acronyms soon brought "MRP" to everyone's lips. The definitive textbook on the subject was Joe Orlicky's offering under this name published by McGraw Hill in 1974.
Recently George Plossl has updated this and it is now available under the title "Orlicky's MRP" from good booksellers or from the UK's Institute of Operations Management (www.iomnet.org.uk, 44 (0)2476 692266).
In the book Orlicky gave what remains a excellent definition for MRP.
"The technique of planned component orders based on the time phased explosion of higher level requirements"
This title explains MRP accurately and concisely. It also explains its attraction - companies adopting this approach no longer had to plan component production and procurement. From now on, if they established the top level plan and bills of material for their products the computer would do everything else for them!
Two key elements in MRP, of course, are the way in which demand is passed down from the top level plan to all constituent levels, and the management of supply at each level. For each item the system develops forward requirements and calculates the stock projection of the item based on the existing supply position, as shown below.
|Date||Planned Receipts||Planned Issues||Projected Stock|
Having established the projected stock for the item over the planning horizon, the system will then prompt actions to maintain the level of stock within that defined. In this case, for example, if we had established a safety level for the item of 5, then it would suggest to the planner that the receipt currently planned for 1st June should be re-scheduled for 25th May. If we had no safety defined then the next procurement action is simply an additional receipt for 12th June. We may have set the system up to warn us of receipts earlier than required so in this case the delivery on 1st May would be prompted for delaying to the 22nd and that on 1st June to the 6th.
In keeping with the search for three-letter acronyms the top level plan to be used by MRP became the Master Production Schedule, or MPS, and this is where many of the early implementations came unstuck. Establishing a production plan for finished products is not easy. We have to assess likely demand over a range of products with many variables coming into play - for example, which product options will be most in demand in the current market, what are our competitors doing and what economic factors may change our market? We then have to establish an achievable plan. If we set an overall output level greater than our capacity, or in excess of what our key suppliers can support, then we will end in chaos.
Another limiting factor in the use of MRP was the management of change, or rather the establishment of some level of plan stability. If we recognise that our plan was wrong, that model A sales are far outstripping our forecast at the expense of model B, then it is simple to change the finished product plan and re-run MRP to establish new material and component plans. But can we react to change this quickly? Can our suppliers? If we decide to increase the proportion of cast steel housings and reduce the volume of cast iron with effect from three weeks on Tuesday, can our foundries react in time? If they can't what will happen? Well, our machine shop will have production orders they cannot commence as they have no raw material, and shortly afterwards our assembly department too will run out of work. All this, of course, at a time when we may have high customer demand! In short, more chaos!
The early implementations also suffered from a failure to recognise that there is more to making systems work than the installation of hardware and software. The systems could generate hundreds of action messages and if the people faced with these messages did not react then the plan within the system was meaningless. Where MRP prompts for an order on an item with no safety stock to be pulled forward then if we do not follow the recommendation then the higher level requirement will not be fulfilled. For example, if we cannot get that batch of motors delivered earlier then our production line will not be able to build the washing machines we had planned. Or, possibly, the machines would be built and put to one side for 'snagging' - that is, fitting the motors later and getting these units back into the process of testing and packing at a later date. Once more, chaos.
Finally, MRP in the early days was quite a long process. On a large mainframe it could take 36 hours to run through from top level plan to a complete re-statement of requirements at all levels. Typically, this run would be scheduled for once or twice a month. What would happen when something changed between runs? We would have a plan for our assembly shop, for all our component manufacturing units and for our suppliers, but what if one area suddenly hit problems and started falling into arrears? To keep a valid plan requires immediate reaction to change - for example, we may have a problem on 24-inch cathode ray tubes coming into a television plant. We can, perhaps, survive this by an immediate switch to making 22-inch and 26-inch models but this requires that we change not only our own assembly programme but the delivery plans for moulded housings, PCBs, power supplies, and so on. If we cannot do this then we end up with a mismatch - kits of components which do not go together, yet again, chaos.
Sadly, these pitfalls from the early implementations of MRP are still being stumbled over today. Many companies introduce planning systems from reputable suppliers and through failure to commit to maintaining valid plans at all times the systems quickly get wholly out of control. What happens then is a familiar, if depressing, tale:
And this, quite often, is what happened. MRP, the solution to all our problems, was suddenly a nightmare. So, back to the drawing board.
PHS Management Training - Copyright © 2017
For training or a consultant call