FIVE STEPS OF TOC

STEP #1: IDENTIFY THE CONSTRAINT. Find the one element of your system which, like the weakest link in a chain, limits the system's ability to perform its function in pursuit of its goal. The Pareto principle says its an 80-20 relationship. But it's probably more like 99-1. There's a variety of ways to find the constraint, whether it's a physical object or a policy. Some very effective methods have been proposed by Dr. Goldratt, but there are others unrelated to TOC that can be used, too.

STEP #2: DECIDE HOW TO EXPLOIT THE CONSTRAINT. Once you've identified the element of the system-- physical or policy-- that's constraining the system's performance, you "exploit" it by deciding how best to wring the maximum performance out of the constraining element as it currently exists (i.e., without major system changes or capital improvements). This is more of a "thinking" step than a "doing" step.

STEP #3: SUBORDINATE EVERYTHING ELSE TO THE DECISION IN STEP #2. Take whatever steps are necessary to synchronize, or align, the performance of all other elements of the system with the "exploited" constraining element. This may mean slowing down "faster" parts and speeding up "slower" ones. This is the "action" step. Step-2 was a "thinking" step. If you're constraint is broken at this point, you go back to Step-1 and start looking for the next constraint (next weakest link in the chain). If not, go on to Step-4.

STEP #4: ELEVATE THE CONSTRAINT. If the constraining element still remains the reason why the system's performance "tops out" AFTER you've completed Step-3, you have to do more. "Elevate" ususally means doing something to increase the capacity of the constraining element. Obviously, if your constraining element is chugging along at maximum efficiency (which it should be after Steps-2 & 3), the only way to improve overall system performance is to obtain more of the constraining element. In a manufacturing environment, this may mean a capital investment in more equipment, or hiring more people, or perhaps subcontracting out some of your backlog. This step will invariably break the constraint, because it isn't considered completed until the capacity problem of the constraining element is finally eliminated--i.e., the constraint is broken.

STEP #5: GO BACK TO STEP-1, BUT AVOID "INERTIA". This is the "repeat Steps 1-4" step. But the warning about "inertia" is important. It's designed to discourage complacency, which comes in two flavors: 1) "We've solved THAT problem already; we don't need to re-visit it again", and 2) "The environment doesn't ever change much."

The first of these is related to the interactive nature of systems and how changes to one part inevitably affect some other part. When you go back to work on the second constraint (i.e., the second pass through the five steps), any system change you might make at Steps 3 and 4 are likely to affect your constraint-breaking solution from the first pass. You may have to either adjust the first solution, or-- worst case-- re-visit the first solution entirely.

The second complacency caution relates to the fact that the environment DOES change, and, in so doing, perfectly good solutions can obsolesce naturally. So even if subsequent constraint-breaking efforts don't affect earlier solutions, those solutions will inevitably die of old age anyway-- and need to be re-visited eventually to keep the improvement process ongoing.

By H. William Dettmer

University of Southern California

Email Questions/comments to Tu Dinh Nguyen at nguyentd@ix.netcom.com