We now know how to control manufacturing. We have long known the definition of "control" - making a plan, getting timely and accurate measures of progress in meeting the plan and reporting significant deviations promptly to those respons1ble for taking corrective action. We also know that one prime requirement for control is a system capable of developing a sound formal plan of action. The system must embody the right techniques to plan and control both capacity and priority. It must be a closed-loop system with timely feedback; sensitive, responsive and capable of replanning.

A lot of noise is being generated now on the need for more frequent replanning. Updating the old plan weekly, called regeneration, is "no longer good enough". We hear that companies must replan much more often. "You must go to net change", is now the popular phrase. Strong voices are heard advocating "transaction-driven, real-time, on-line net change", literally replanning every minute on the minute to react to every conceivable action or disturbance.

Such systems would receive data and generate information any time there was a forecast error or a customer changed his mind on delivery of his order, any time an error was found or an adjustment needed in important records including bills of material, on-hand balances, open manufacturing and purchase orders or other vital statistics. The system would respond immediately with action notices every time order quantities were recalculated, safety stocks adjusted or lead-time corrections made. It would also react promptly with revised instructions when shop interruptions occurred or vendor deliveries were delayed, materials held up by transportation strikes or destroyed by fires, floods, civil insurrections or other acts of God.

There can be no valid argument against the need to keep systems informed of what is happening so that they stay in step with the real world. Every company needs valid up-to-date priorities in order to work on the right items. Unfortunately, all this noise about up-to-the minute systems is drowning out the cries of distress of over-burdened system's users. These poor devils, working hard to keep the system informed and already deluged with too many action notices, reports, tracking signals and special instructions, are not able to do the one really necessary job effectively - execute the plan, to carry it out, implement it, make it happen.

J. L. Frain defined a completely planned economy as "one which insures that when no bacon is delivered, no eggs are delivered at the same time." The modern lore of MRP requires too much effort and puts too much attention on delaying breakfast when some problem indicates that the bacon is likely to be late. According to today's thinkers, "perfect" MRP-system operation would reschedule the eggs to match the new due date for the bacon. If you're hungry, this is the wrong way to go. Why can't someone get out and get that bacon (or get some ham) on time? It's too easy to replan and reschedule more often. One manager told us recently, "We seem to spend all our time pushing back all the things we can get because of those we can't."

Maybe we're going at this all wrong. It's been suggested that programs to improve automobile safety are headed in the wrong direction. Instead of protecting the idiot driver and his passengers from harm by surrounding them with an impregnable vehicle maybe we ought to make cars more fragile so people would drive them more carefully. Maybe we should make it harder to reschedule so people would rather execute the original plan than change it.

But the choice must be clear. It is not "to reschedule or not as people's time permits" but to execute the plan and, only as a last resort, reschedule. Rescheduling capability may be a virtue in the system but it is a vice in the user. It's a cop-out to reschedule instead of solving the manufacturing and procurement problems. Management should make use of this system capability a heinous crime with severe penalties.

Going from a weekly replanning cycle to a daily one certainly might seem to many people to be much more desirable as well as far more precise. The "illusion of precision", however, leads to the "illusion of progress". The same people who are urging more frequent replanning are also suggesting "dampening rules" and "fences", more sophistication in the system programs, to keep the volume of messages under control. Is this progress? In our opinion, changing plans faster is not progress. We don't need faster systems updated more frequently with more output signals. We're already inundated with too much data. We need better information identifying the important problems which should be attacked now. We don't think, either, that it's helpful to users of systems to make them more complicated. "Make the logic obvious" is one of the soundest principles of systems design. Building more suppressors, fences and dampeners into systems will only make the user more of a slave rather than the master of his tools.

In our courses in Atlanta utilizing our "real-time, on-line" computer we've had lots of experience with people trying to solve real-life problems with a complete system. Take the machine-breakdown problem. One of two available machines in a key work center will be out of service for two weeks. The question is, "What effect will this have on the plant's ability to make the products to support the master production schedule?" Both capacity and priority are involved. The loss of capacity must be made up somehow, sometime, by overtime, alternate operations, sub-contracting, another temporary shift, etc. Until it is, however, available capacity must be utilized to the best advantage by working on the highest priority orders, some of which can be late coming out of this work center and still get back on schedule if capacity is adequate in downstream centers. The solutions to this problem (there are obviously more than one) take time - about 15 minutes is the record, the average team takes an hour. In transaction-driven net-change systems, priority on many orders involved could change while the problem is being solved. What possible real difference would it make? The problem will have effects lasting well over two weeks. The same orders will probably change again in priority some time in that interval.

Consider the effect on people working on such problems using CRT's, studying a specific situation and having the data change before their eyes just as they get near the solution! The alternative suggested to avoid this is hilarious - use a work file not updated during the solution. What's different in this from a system updated periodically - say daily or twice a week? This would be identical to a batch-updated system.

The real fallacy in the thinking of the real-time, on-liners is that precision is necessary and useful. Those of us who have really lived in manufacturing plants, however, know that it is a very imprecise environment. It cannot be represented by numerical "models" in computers, except very approximately. It defies rigid constraints and refuses to perform as predicted. A production schedule, a profile of planned orders in MRP and a capacity requirements plan are "forecasts" just as are predictions of customer demand. And there are at least as many factors influencing them unpredictably as affect customer order forecasts.

People need time to execute a plan; sound plans must have tolerance ranges within which execution is acceptable. Changing the plan must be the last resort when all else has failed.