Since the bottlenecks dictate throughput, other processes in the factory should be run to complement the bottleneck’s output.
What does that mean, you ask? It means that running a machine just for the sake of running it does not actually add value in most cases. Here is a quick example to illustrate this point:
Let’s say there are two machines running in parallel. One machine is a bottleneck machine and the other is a parallel process. Maybe the parallel process makes part P and the bottleneck makes part B, and the final assembled part F is the assembly of P + B.
If you just run the P machine at full capacity, you’re going to have a shit-ton of P parts for every B part. That’s excess inventory. Excess inventory costs money.
It might feel “inefficient,” but you should not run P for maximum efficiency. You should run P at a pace which matches demand. In this case, that would be to create the same number of P parts as B parts. This approach creates “factory-wide efficiency” as opposed to “local efficiency.”
The problem is that many people in a project or a factory or a single file boy-scout line see only their little world. The folks running process P might find it highly inefficient to have downtime for no good reason, so it makes sense to them to just continue to produce part P.
They are trying to locally optimize.
Many metrics used in manufacturing (or within a team working on a project) reinforce this push to locally optimize. The Goal says this is nonsense; activating a resource just to activate is not the same as utilizing a resource to add value.
Optimize the entire system, not sub-components of the system. If you don’t believe me, just imagine Jonah saying that in a professorial accent and it will sound much more credible.