What if we chose our bottleneck on purpose?

A factory is a dependent system. Local efficiency is not the same as factory efficiency. Hourly rates encourage us to eliminate idle capacity. A perfectly balanced factory has no room to recover from ordinary variation. Some spare capacity is therefore not waste. It is what allows the system to recover.

If we need spare capacity, how should we design the factory?

Every factory has something limiting how much it can produce. If it isn't Printing, perhaps it is Cutting. If it isn't Cutting, perhaps it is Finishing. If production has enormous capacity, perhaps the bottleneck is sales.

Something, somewhere, ultimately limits the rate at which the whole system can produce and sell. That is not necessarily a problem. It is a consequence of dependency.

You cannot eliminate the bottleneck from the system. You can only move it.

If we double the capacity of the current bottleneck, something else eventually becomes the bottleneck. So constantly asking how we get rid of it is the wrong question.

Where would we like the bottleneck to be?

If something must ultimately limit the system, perhaps we should design around a resource that makes sense as the pace-setter. A machine or process that is predictable. Reliable. Expensive or difficult to duplicate. Relatively easy to schedule around. Strategically sensible as the thing the rest of the factory takes its beat from.

That is not a rigid checklist. The point is conceptual.

Don't let the bottleneck wander around the factory if you can avoid it.

Choose a sensible place for it. Then design the rest of the system around that fact.

Back to the simple factory. Instead of Cutting 100, Printing 100, Finishing 100, Packing 100, perhaps we deliberately design Cutting 120, Printing 100, Finishing 120, Packing 120.

Printing is deliberately our limiting resource.

At first glance this looks inefficient. Cutting has spare capacity. Finishing has spare capacity. Packing has spare capacity. They cannot all run at 100% utilisation all day.

Suppose Cutting loses some time in the morning. It has capacity above the normal required flow. Once the problem is resolved, Cutting can run faster than the pace Printing needs and catch up.

Suppose Finishing has a small problem. Once it recovers, it has enough capacity to catch back up with Printing's output. Suppose Packing falls behind. Again, it has some recovery capacity.

The other resources have room to breathe. That spare capacity is resilience.

Printing is different. An hour lost there is much more serious, because the rest of the factory cannot recover output that Printing never produced.

So we manage Printing differently.

Once we know where the bottleneck is, production management becomes much clearer. We want to make sure Printing has work available when it needs it. That it isn't waiting unnecessarily for materials, or for avoidable decisions. That it isn't spending time on work that could happen somewhere else. That it isn't losing capacity to problems we could have prevented.

Protect the resource that determines the pace of the factory. Let the rest of the factory support that pace.

Suppose Cutting has supplied everything Printing currently needs. Cutting stops.

From a local-efficiency perspective, Cutting is underutilised. From the perspective of the whole factory, nothing is wrong. It has done its job.

A machine that is not setting the pace, standing still, is not necessarily wasting capacity. Sometimes it is simply waiting because the system doesn't need anything from it.

The objective is not to keep Cutting busy. The objective is to keep finished work flowing through the factory. That is where the earlier notes should now click into place.

We should not describe that extra capacity as unused, as though it had no purpose. It has a job. Its job is to protect flow.

It allows the rest of the factory to recover after interruptions, absorb ordinary variation, catch up when it falls behind, and support the pace of the bottleneck.

Spare capacity isn't necessarily wasted capacity. It can be protective capacity.

We now have a deliberately unbalanced factory. Some resources have more capacity than others. Not everybody is busy all the time. That is okay.

Work should move according to what the system can actually absorb. We do not release work merely to keep machines busy. We do not celebrate piles of unfinished work as productivity. We do not judge every department as though it were an independent little factory.

Is work flowing? Is the bottleneck protected? Are we producing what the customer actually needs? Can the system recover when ordinary variation happens?

I am not suggesting that every factory should immediately buy bigger machines and create huge amounts of spare capacity. Capacity costs money.

Sometimes the correct answer is better scheduling. Sometimes it is cross-training. Sometimes it is changing how work is released. Sometimes a small amount of overtime provides enough recovery capacity. Sometimes we genuinely do need another machine or person.

Do not eliminate that spare capacity merely because local measurements make it look inefficient.

At the beginning of this series, efficiency seemed obvious. An efficient factory should have efficient departments. Efficient departments should have busy machines. Busy machines should produce lots of work. And idle capacity looked like waste.

Once we accepted dependency, the picture changed. A resource can be locally efficient while damaging flow. A resource can look locally inefficient while doing exactly what the system needs.

So perhaps efficiency needs a different definition.

This deliberately unbalanced factory will look uncomfortable through a local cost-accounting lens. Some resources will have unused hours. Their calculated utilisation may be lower. Their apparent cost per unit may look worse.

But the factory can have less unnecessary work waiting, shorter queues, clearer priorities, better recovery from problems, more predictable flow, and more reliable delivery.

We deliberately accept some local inefficiency in order to improve the behaviour of the whole system.

Once we have decided how the factory should behave, software becomes useful. It can help us see the flow. It can show us what should be worked on next. It can help protect the bottleneck. It can stop too much work being released. It can help us understand capacity. It can make the method easier to follow.

Software takes your methods and helps you execute them faster.

If the method creates chaos, software can accelerate the chaos. If the method creates flow, software can help make that flow visible and easier to manage. Software comes after the method.

We started with the Law of Dependencies. That is really all we have done throughout this series. We have just followed that simple idea wherever it led.

And it led somewhere quite different from the factory many of us were taught to aim for. Not a perfectly balanced factory. Not a factory where every machine is busy. Not a factory where every department maximises its own efficiency.

A deliberately unbalanced factory. One where we know what sets the pace. One where we protect it. And one where everything else has enough room to deal with the fact that real life never runs according to the spreadsheet.

That might look inefficient. I think it's a much more sensible way to run a factory.