The Goal: A Process of Ongoing Improvement - by Eliyahu M. Goldratt
Date read: 2021-11-06How strongly I recommend it: 8/10
(See my list of 150+ books, for more.)
Go to the Amazon page for details and reviews.
Pulling from Lean-Six Sigma methodologies, The Goal walks you through a fictitious story of a plant manager trying to save his plant by identifying bottlenecks. Good lessons to apply to any type of business model and worth using when trying to improve processes.
My Notes
If the goal is to make money, then an action that moves us toward making money is productive. And an action that takes away from making money is non-productive.
So this is the goal: To make money by increasing net profit, while simultaneously increasing return on investment, and simultaneously increasing cash flow.
They’re measurements which express the goal of making money perfectly well, but which also permit you to develop operational rules for running your plant. There are three of them. Their names are throughput, inventory and operational expense.
Throughput is the rate at which the system generates money through sales.
Inventory is all the money that the system has invested in purchasing things which it intends to sell.
Operational expense is all the money the system spends in order to turn inventory into throughput.
Increase throughput while simultaneously reducing both inventory and operating expense.
Throughput is the money coming in. Inventory is the money currently inside the system. And operational expense is the money we have to pay out to make throughput happen. One measurement for the incoming money, one for the money still stuck inside, and one for the money going out.
A bottleneck is any resource whose capacity is equal to or less than the demand placed upon it. And a non-bottleneck is any resource whose capacity is greater than the demand placed on it.
Balance flow, not capacity.
I ask, “You mean we should put Q.C. in front of the bottlenecks?” Jonah raises a finger and says, “Very perceptive of you. Make sure the bottleneck works only on good parts by weeding out the ones that are defective. If you scrap a part before it reaches the bottleneck, all you have lost is a scrapped part. But if you scrap the part after it’s passed the bottleneck, you have lost time that cannot be recovered.”
The actual cost of a bottleneck is the total expense of the system divided by the number of hours the bottleneck produces.
The level of utilization of a non-bottleneck is not determined by its own potential, but by some other constraint in the system.
If you consider the total time from the moment the material comes into the plant to the minute it goes out the door as part of a finished product, you can divide that time into four elements:
- Setup - the time the part spends waiting for a resource, while the resource is preparing itself to work on the part.
- Process time - the amount of time the part spends being modified into a new, more valuable form.
- Queue time - the time the part spends in line for a resource while the resource is busy working on something else ahead of it.
- Wait time - the time the part waits, not for a resource, but for another part so they can be assembled together.
If we reduce batch sizes by half, we also reduce by half the time it will take to process a batch. That means we reduce queue and wait by half as well. Reduce those by half, and we reduce by about half the total time parts spend in the plant. Reduce the time parts spend in the plant, and. . . . “Our total lead time condenses,” I explain. “And with less time spent sitting in a pile, the speed of the flow of parts increases.”
An hour lost at a bottleneck is an hour lost for the entire system. An hour saved at a non-bottleneck is a mirage.
According to the cost-accounting rules that everybody has used in the past, we’re supposed to balance capacity with demand first, then try to maintain the flow. But instead we shouldn’t be trying to balance capacity at all; we need excess capacity. The rule we should be following is to balance the flow with demand, not the capacity.
The incentives we usually offer are based on the assumption that the level of utilization of any worker is determined by his own potential. That’s totally false because of dependency. For any resource that is not a bottleneck, the level of activity from which the system is able to profit is not determined by its individual potential but by some other constraint within the system.
What my people and I have done is to examine daily the queues in front of the assembly and in front of the bottlenecks— we call them ‘buffers.’ We check just to be sure that everything that’s scheduled to be worked on is there—that there are no ‘holes.’ We thought that if a new bottleneck pops up it would immediately show up as a hole in at least one of these buffers.
And it became even more interesting when we realized that we were visiting the same six or seven work centers every time. They’re not bottlenecks, but the sequence in which they perform their jobs became very important. We call them ‘capacity constraint resources,’ CCR for short.
We tried so hard to improve our bottlenecks, when what we should do is improve the CCRs as well. Otherwise we’ll run into an ‘inter-active’ bottleneck situation.
The key is in the hands of production. These techniques to manage the buffers should not be used just to track missing parts while there is still time, they should be used mainly to focus our local improvement efforts. We must guarantee that the improvements on the CCRs will always be sufficient to prevent them from becoming bottlenecks.
But the important thing is that we, in our plant, have switched to regard throughput as the most important measurement. Improvement for us is not so much to reduce costs but to increase throughput.
STEP 1. Identify the system’s bottlenecks. (After all it wasn’t too difficult to identify the oven and the NCX10 as the bottlenecks of the plant.)
STEP 2. Decide how to exploit the bottlenecks. (That was fun. Realizing that those machines should not take a lunch break, etc.)
STEP 3. Subordinate everything else to the above decision. (Making sure that everything marches to the tune of the constraints. The red and green tags.)
STEP 4. Elevate the system’s bottlenecks. (Bringing back the old Zmegma, switching back to old, less “effective” routings. . . .)
STEP 5. If, in a previous step, a bottleneck has been broken go back to step 1.
In other words...
- IDENTIFY the system’s constraint(s).
- Decide how to EXPLOIT the system’s constraint(s).
- SUBORDINATE everything else to the above decision.
- ELEVATE the system’s constraint(s).
- WARNING!!!! If in the previous steps a constraint has been broken, go back to step 1, but do not allow INERTIA to cause a system’s constraint.
“What they actually do is to derive the unavoidable results logically from their hypothesis. They say: IF the hypothesis is right THEN logically another fact must also exist. With these logical derivations they open up a whole spectrum of other effects. Of course the major effort is to verify whether or not the predicted effects do exist. As more and more predictions are verified, it becomes more obvious that the underlying hypothesis is correct.
Things start to be connected to each other. Things that we never thought were related start to be strongly connected to each other. One single common cause is the reason for a very large spectrum of different effects.
What are we asking for? For the ability to answer three simple questions: ‘what to change?’, ‘what to change to?’, and ‘how to cause the change?’ Basically what we are asking for is the most fundamental abilities one would expect from a manager. Think about it. If a manager doesn’t know how to answer those three questions, is he or she entitled to be called manager?