Book cover art for The Goal

The Goal

Eliyahu M. Goldratt and Jeff Cox

It's written like a thriller or a drama... but it's about manufacturing processes. Sounds bananas, but it's surprisingly effective at explaining the principles of Lean manufacturing using the Socratic method. This is worth a read by anyone who works with, in, or has a passing interest in processes and systems.

C.R.E.A.M.

Productivity without a clear goal is meaningless.

'I watch as a truck backs between two others sitting at the unloading docks. The trucks bring the materials which the machines and people inside will use to make something. On the opposite side, more trucks are being filled with what they have produced. In simplest terms, that's what's happening.'

What people often think 'the goal' is, but isn't:

  • Quality Products
  • Efficiency
  • Jobs
  • Cost-effectiveness
  • Technology
  • Sales

All of the above are all well and good in their own right, but they are not the goal. They are available means towards the end of the goal, but not the goal itself.

The goal is to make money.

Just 'working' does not equate to productivity. There is a big difference between activation and utilisation. Inefficient plants tend to have people working all the time and they make inventory whether you need it or not.

Measures and Meanings

There are three key measures to understand whether or not you are making progress towards the goal:

  1. Net Profit
  2. Return on Investment (ROI)
  3. Cashflow

In terms of operations, we must be focused on the following three things:

  1. Throughput - rate at which the system generates money through sales
  2. Inventory - all the money invested in the system buying things it intends to sell
  3. OpEx - all the money the system spends in order to turn inventory into throughput

Putting them all together, we want to '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."

Dependent Events and Statistical Fluctuations

The rate of a process is constrained by the slowest step. If we try to set the rate at the front of the process any fluctuations that happen along the way will only lengthen the process.

In the book, Goldratt paints the picture of a troop of boy scouts walking in single file and shows how the progress of the entire system (that is, the entire troop) is constrained by the slowest walker.

'Once I've closed the gap between us, I can't go any faster than the rate at which the kid in front of me is going. And he ultimately can't go any faster than the kid in front of him. And so on up the line to Ron. Which means that, except for Ron, each of our speeds depends upon the speeds of those in front of us in the line.'

'What's happening isn't an averaging out of the fluctuations  in our various speeds, but an accumulation of the fluctuations. And mostly it's an accumulation of slowness—because dependency limits the opportunities for higher fluctuations.'

Bottlenecks and Non-Bottlenecks

A bottleneck is any part in a process where the capacity is equal to or less than the demand placed upon it.

A non-bottleneck is any part in a process where the capacity is greater than the demand placed upon it.

We cannot just improve parts of a process, we have to improve the whole thing at the same time with the bottlenecks at the front of our minds.

To that end, bottleneck flow should be on par with demand. If demand exceeds the maximum capacity of the bottleneck you will need to find a way to increase bottleneck flow or fall behind.

The first thing you have to do is actually find the bottlenecks before you can improve them.

Finding and Fixing Bottlenecks

If there's a step in the process where there is always a chronic shortage of supply of the parts/material it needs, look for where they are supposed to be coming from. This may well be your bottleneck.

When you find your bottleneck, you may also find that there is a large amount of WIP held up in the steps in front of it, too.

Bottleneck hourly cost is the cost of the entire system divided by the total number of hours that bottleneck produces/is operating. Any hours lost pushes the hourly cost up.

There are three ways to lose hours:

  1. Not running
  2. Working on parts you don't need
  3. Working on parts that later turn out to be defective

This means that you need to do roughly three things to keep as many hours as possible:

  1. Keep it running as many hours as possible
  2. Remove unnecessary parts from being processed
  3. Remove defective parts before they enter the bottleneck

Just Working on Bottlenecks is Not Enough

When you work on bottlenecks, unusual things can happen in the rest of the process. Where before there was a build up of WIP before the bottleneck, now there might be a delay in getting materials from prior machines that, in theory, should have ample capacity to keep up.

This becomes a question of how you manage inventory throughout the system.

When and how you release materials into the system should be determined by the bottlenecks themselves. Everything should be released to the beat of the drum of the bottleneck itself, no other. This way, there's no way that inventory should build into large piles of WIP.

Time in the Context of Systems

There are four types of time throughout a process:

  • Setup Time - prepping for the process to begin
  • Queue Time - once prepped, waiting for the process to begin
  • Process Time - the time it takes to process the part
  • Wait Time - the time a part must wait before being assembled

Smaller batches released and worked on lead to lower WIP in the system and better cashflow and, also, better lead times because they spend less time in the system.

The Theory of Constraints

Replace the word 'bottleneck' with the word 'constraint' and think about all of this in terms of a process that we might follow:

  1. IDENTIFY the system's constraint(s).
  2. Decide how to EXPLOIT the system's constraint(s).
  3. SUBORDINATE everything else to the above decision.
  4. ELEVATE the system's constraint(s).
  5. WARNING!!!! If in the previous steps a constraint has been broken, back to step 1, but do not allow INERTIA to cause a system's constraint.

All of this is concerned with finding and then solving the core problem at the heart of a system.

What do we need to change?

What do we need to change it to?

How do we cause the change to happen?

More of this, but in your inbox

I send updates to a few hundred people anytime I've got something worth sharing. New articles, new book notes, new commentary.

Let me read it first