Having opened this article with the cynical claim that the term Supply Chain was in effect stolen by software providers when they had come up with nothing new, we should perhaps consider whether anything new has been developed. And, in fact, something very different has evolved in recent years.
The management of capacity has always been a matter of some debate. In the early days of MRPII many people would argue that the CRP approach was fundamentally flawed. CRP simply looked at all production orders (and planned orders) to identify which work centres (or load centres) were required for each. The system then accumulated the load in the appropriate unit of measure (usually hours or minutes) and reported load v capacity numerically and graphically.
Because the system took no action other than to report overloads it was often quoted as being based on infinite capacity. Its detractors claimed that MRPII systems were based around infinite capacity and the approach was therefore wholly invalid. Its proponents argued that MRPII was in no way based on anything as ludicrous as infinite capacity. They said that CRP systems warned of overloads specifically so that planners would take steps to maintain a valid plan - that is, one which recognises the finite capacity of manufacturing resources. They also argued that presenting information to planners who could use judgement was better practice than trying to define rules within a system and effectively trusting our futures to some clever 'black box.'
The finite camp came back and argued that MRP is based around fixed lead times for items when in fact lead times are anything but fixed. They are wholly dependent upon the workload of the plant and the nature of the work at any particular time. To avoid too much contention planners had to build excessive queuing allowances into the lead times used by MRP. This in turn extended lead times to market and increased the level of work-in-progress, which in turn led to even more contention. Lead times, they said, are self-fulfilling prophecies. (And, of course, in this they were absolutely correct!)
Some software companies began to develop capacity management systems based around finite capacity. This, of course, required a fundamentally different approach. Infinite CRP simply took the start and finished dates for each production order and calculated start and finish dates for each operation based on the various time elements in the routing - move, queue, set-up, run and possibly some waiting allowance after completion of an operation (to allow, for example, for cooling). The process times for each piece of plant were then simply accumulated against a work centre record in the appropriate period. With a finite approach this would not work - the system had to identify when a particular order would be using each work centre and this required some logic to determine which order took priority in the event of contention.
Finite planning thus required some form of 'forward pass' scheduling whereby for each work centre the system looked at the orders waiting for this resource and decided which should be processed first. The system then performed this task for all the other work centres and looked ahead to the next time any of these work centres would be available. It then identified which orders would be in the queue at that work centre at that time and decided which should be the next to be worked on. It ran through this process for all the work to be carried out and generated schedules ('dispatch lists' or 'work-to' lists) for each work centre.
Some system providers fell into one camp or the other whilst others offered both approaches. IBM, whose COPICS product had been the forerunner of the standard MRPII approach, offered CAPOSS (Capacity Management and Operation Sequencing System) as an alternative to the capacity module in their own package, or a as a 'bolt-on' to other business systems.
Of course, the difference at the end of all this was that where we had an unachievable plan and CRP produced graphs showing overloads, the finite systems showed no overloads, but reported that unfortunately some orders were inevitably going to be completed late. Textbook MRPII followers argued that both systems lead, in reality, to the same thing - an action on a human planner to go away and sort out the problem. This could involve a complete change in the manufacturing plan or may simply involve a few extra hours capacity which can be achieved through overtime. (Or may necessitate some movement of work from one piece of plant to another, or perhaps to a sub-contractor.)
Thus, they argued, CRP was the better approach in that the cause of the problem (the overloaded resource) was immediately visible. In a finite scheduling system further detective work is required to move from a list of orders which are going to be late to the identification of the overloaded piece of plant. They also pointed out that we could define priority rules for a scheduling system to follow blindly but sometimes a problem could easily be averted by a simple piece of judgement on the part of a planner. One thing computers systems don't have, they argued, is judgement. This argument prevailed within the MRPII community and CRP became the established capacity management technique within MRPII, and hence later in ERP and standard Supply Chain approaches - though the debate went on for many years and sold many books as well as filling seats at numerous conferences.
In the early 1980s, however, Eliyahu Goldratt challenged all the accepted wisdom of planning and control. He argued that there are some fundamental rules that were being ignored. This subject in itself is worthy of considerable exploration but for the purposes of assessing Supply Chain systems I will focus on one of the major points of Goldratt's teaching. Within Optimised Production Technology and the subsequent Theory of Constraints Goldratt argued that the MRP and MRPII approaches were inherently wrong in that they scheduled materials and capacity independently. MRP calculated the requirement dates for in-house components and their raw materials; CRP then looked at the manufacturing resources needed to make these components. In many cases a potential overload would be reported and the cure may be to pull the order forward into a period when capacity is available. However, by this time MRP had ordered the raw materials so when we have changed the production plan the next MRP run will generate re-schedule messages for the materials plan.
Goldratt's OPT package looked at materials and resources together to establish a plan which took account of all constraints - in other words, an optimised solution. It identified the bottlenecks in our plant (which, Goldratt taught us, govern our throughput) and set our production and material plans simultaneously around best use of these resources. It was never quite apparent exactly how Goldratt's system performed this optimisation and in fact this secret always appeared to be closely guarded.
This package, despite its obvious attractions, did not actually sell as well as it might have, but it laid the foundations for other companies to build upon as computers became capable of ever-increasing levels of complexity in their scheduling algorithms. As more packages came into the market following these principles of optimising production schedules, making best use of bottlenecks, planning materials and resources simultaneously and allowing users to set up their own rules as to what mattered most in their environment these packages became known generically as Advanced Planning and Scheduling, or APS sometime in the mid 1990s.
As ever in such matters the world appeared to divide into the MRP and APS camps. The arguments against MRP are well known but its defenders raise concerns about APS, primarily that it works around pre-defined rules, which may not always give the optimum solution in all circumstances, and that people will never fully understand what they are doing. They argue that it encourages planners to discard judgement. (In this they have a point. If we use any optimised planning system then we need each area to follow the plan religiously; if one work centre cuts across the recommended sequence then all subsequent areas will not receive orders as planned and the whole plan is meaningless.)
The attractions of APS are obvious. We cannot assess every possible permutation of all the orders to be processed through even a small production facility. Some advanced means of harnessing computing power to generate the 'best' schedules given our resources and objectives has to be worthy of serious consideration. Within the confines of an article providing an overview of ERP or Supply Chain software I will confine myself to two further questions:
1. If we replace the MRP / CRP logic of a planning system with that of APS is it still ERP? (or Supply Chain?)
2. Who cares?
PHS Management Training - Copyright © 2019
For training or consultancy call