Theory of Constraints is an approach to continuous system improvement to reduce operating expenses and inventory, while increasing throughput. To use another powerful analogy: just as the strength of a chain is dictated by its weakest link, the performance of any value-chain is dictated by its constraint.
Recognize that every system was built for a purpose, we didn’t create our organizations just for the sake of their existence. Thus, every action taken by any organ – any part of the organization – should be judged by its impact on the overall purpose. This immediately implies that, before we can deal with the improvement of any section of a system, we must first define the system’s global goal; and the measurements that will enable us to judge the impact of any subsystem and any local decision, on the global goal.
Once these are defined, we can describe the next steps in two different ways. One, in which we are using the terminology of the system that we are trying to improve. The other using the terminology of the improvement process itself. We find that both descriptions are very helpful and only when both are considered together, does a non-distorted picture emerge.
How to sort out the important few from the trivial many? The key lies in the recognition of the important role of the system’s constraints. A system’s constraint is nothing more than what we all feel to be expressed by these words: anything that limits a system from achieving higher performance versus its goal. To turn this into a workable procedure, we just have to come to terms with the way in which our reality is constructed. In our reality any system has very few constraints and at the same time any system in reality must have at least one constraint. Now the first step is intuitively obvious:
1. Identify the system’s constraints
Once this is accomplished – remember that to identify the constraints also means to prioritize them
according to their impact on the goal, otherwise many trivialities will sneak in –
2. Decide how to exploit the system’s constraints
Now that we decide how we are going to manage the constraints, how should we manage the vast majority of the system’s resources, which are not constraints? Intuitively it’s obvious. We should manage them so that everything that the constraints are going to consume will be supplied by the non-constraints. Is there any point in managing the non-constraints to supply more than that? This of course will not help, since the overall system’s performance is sealed – dictated by the constraints.
3. Subordinate everything else to the above decision
But let’s not stop here, it’s obvious we still have room for much more improvement. Constraints are not acts of God, there is much that we can do about them. Whatever the constraints are, there must be a way to reduce their limiting impact and thus the next step to concentrate on, is quite evident.
4. Elevate the system’s constraints
If we elevate and continue to elevate a constraint, then there will come a time when we break it. This thing that we have elevated will no longer be limiting the system. Will the system’s performance now go to infinity? Certainly not. Another constraint will limit its performance and thus the fifth step must be:
5. If in the previous steps a constraint has been broken, go back to Step 1
What is this thing called Theory of Constraints and how should it be implemented?
Eliyahu M. Goldratt
(Back) |
