's first presentation of his insight into ProcessManagement
. The five steps are:
- Identify the bottleneck (constraint).
- Exploit the constraint by making sure no SOP, formal or informal rules, or policies prevent it from operating at its capacity.
- Subordinate other resources to the constraint by not allowing their SOP, ... to interfere with or cause problems for the constraint.
- So far, we didn't spend any (serious) money -- just changed our thinking and practices.
- Elevate the constraint (if the first three steps have not broken it) by adding resources. Even here, the amount of money involved may be small. The constraint in TheGoal was elevated by buying a used machine of the type that the constraint replaced and by sending work to a subcontractor.
- If the constraint you identified is broken, go back to #1.
This sounds like it could be generalized to:
- Identify problem node in a system
- Delete/Modify any nodes that are direct causes of problem
- Delete/Modify any nodes that are indirect causes of problem
- If problem still exists, add nodes to system to try to improve things
- If problem still exists, repeat
When rephrased like this it becomes clear that there is no termination proof.
- The representation of the system may not be one that includes the true issues.
- the delete/modify steps are vague; how do you identify direct or indirect causes? Often that's the really hard part
- the add step is ultimately vague; how do you identify what to add and where?
To terminate, there must be some assurance that progress is being made in each loop.
Sure, this is just a heuristic, but that doesn't mean it can't be tightened up.
Every process has at least one bottleneck; every schedule has at least one critical path. A well-balanced process or schedule is one that has several parallel bottlenecks; not one which has zero (as the latter doesn't exist). The termination condition might be that when two or more bottlenecks exist. Or, a better condition for termination is when productivity/completion date is acceptable.
Of course, the problem with a well-balanced schedule with multiple critical paths is that it becomes more fragile.
It doesn't really increase the fragility. The things that go wrong with short schedule would go wrong with the long one as well; you just wouldn't notice it because the long schedule is padded out, inefficient. That is, the short schedule can grow to be no longer than the long one would have been.
Thanks for your replies. The analogy between management on one side and programming on the other is at best inexact.
I think of programming as an activity that seeks something like a mathematical function -- a planned response for any event in its domain. In principal, only random events like cosmic rays changing the value of a bit are ignored. That's too strong, but it goes in the right direction. There may be many ways for a program to work correctly, but successful implementations must satisfy the same criteria. In practice though, even in the most regular case programs suffer unpredicted failures -- the Windows BlueScreenOfDeath
is probably the best known.
Management problems are barely specified at all in comparison to those programmers work on. Rather than polished solutions, managers must rely on heuristics and the ability to respond on the fly to unexpected challenges. That doesn't mean their procedures and heuristics can't be improved. Goldratt's FiveFocusingSteps
, for example, is based on the DemingCycle
, all of them applications of the ScientificMethod
. In that sense, actions based on the FiveFocusingSteps
are experiments capable of falsifying the hypotheses identified in step 1. We're far past physics 1.0, let alone mathematics 1.0, and those fields still use such heuristics to guide their search for understanding and better tools.
Goldratt's biggest contribution (IMO) is to tell manager's how to concentrate their energy where it will have the most effect on their processes rather than trying to optimize all of them equally.
Multiple bottlenecks in a single facility often indicate the presence of multiple processes that share some resources. In that case, the problem is to identify the bottleneck that affects the largest share of throughput*, work on it, and then work on the others in turn.
Improvement is measured by comparing throughput* before and after any changes (experiments) Since management (manufacturing or any other kind) has no stable state, there can be no termination condition.
In Goldratt's defense, he's a physicist, not a literary novelist. I suspect that inelegence is a common fault of any first attempt to present a new idea to an unprepared audience, as TheGoal
did. His later novels are better written and good introductions to their topics, but his nonfiction is . . . dense. H. William Dettmer's books from ASQ's Quality Press are the best way to learn Goldratt's ideas; his Breaking the Constraints...
is the best textbook.
- "Throughput" is output that is sold without recourse, a distinction that reveals the effects of inventory changes intended to improve a company's financial (public) accounting reports and stock price rather than to reflect its actual condition. Politics trumps economics, as anyone who pays attention to any public policy debate knows.
See also: SystemsAnalysis