The Theory of Constraints (TOC) gives you five focusing steps. Identify the constraint, exploit it, subordinate everything else to it, elevate it, then repeat. Most teams get the first two right. Step 3, subordination, is where most implementations fail, and it's the step people talk about least.
Subordination means every resource that isn't the constraint changes how it behaves to serve the constraint. It does that even when it makes the resource look inefficient by traditional measures. That last part is the problem.
A non-constraint that runs at 70% utilisation to keep the constraint perfectly fed is doing its job correctly. Measure it on its own utilisation and you'll conclude the opposite.
Local inefficiency is often the right answer
This is the idea managers find hardest to accept, and I understand why. It runs against decades of management accounting and the way most performance metrics are designed. Every machine has a number, and every manager wants their number to go up.
But a non-constraint running below full capacity isn't waste. It may be exactly what the system needs. Push it to run harder and one of three things happens:
- It builds piles of work in progress (WIP) in front of the constraint. That adds lead time and ties up working capital.
- It starves the constraint of what it needs next, if it sits upstream.
- It overproduces, and the extra output hides how the constraint is really performing.
Once the constraint is fully fed, extra utilisation anywhere else adds zero throughput. It only adds operating expense and WIP. You can write that as calculus: throughput doesn't change with non-constraint utilisation. You don't need the maths to see it, though. The site can only make what its constraint makes.
Subordination asks something different of each function
Subordination isn't one decision. It's a set of standing rules, and each part of the site gets its own.
- Upstream processes keep the buffer in front of the constraint full without overproducing. They release work to the schedule, not to their own capacity.
- Downstream processes keep buffers and some sprint capacity. They absorb swings in the constraint's output without losing throughput.
- Maintenance puts constraint availability above everything else. A non-constraint machine waiting is a minor inconvenience. A constraint machine waiting is a loss for the whole system.
- Quality inspects before the constraint and protects after it. A defect should never use up constraint capacity.
- Scheduling keeps constraint changeovers to a minimum. It sequences production to give the constraint as much productive time as possible.
None of that is complicated on paper. The difficulty is that each rule asks someone to accept a worse local number.
Four things break subordination, and none of them is technical
- Local performance metrics. Measure non-constraint managers on their own utilisation or efficiency and they will optimise for it. They'll do it even at the expense of the constraint, and they're behaving rationally.
- Cultural resistance. Asking a department to run slower so the bottleneck looks good feels deeply unfair. It only makes sense once everyone shares an understanding of how the whole system works.
- Nobody knows which machine is the constraint. Operators can't make subordination decisions in real time if they don't know which resource matters most.
- Metric confusion. OEE scores, efficiency reports and utilisation dashboards that treat every machine the same actively undermine subordination.
That last one is close to my heart. I wrote about it in the OEE article: an efficiency screen on every machine invites every manager to chase their own number. Measure at the constraint, and treat waiting time there as Lost Time for the whole site.
Drum-Buffer-Rope makes subordination routine
Drum-Buffer-Rope (DBR) is the mechanism that puts subordination into practice. We've implemented TOC and DBR in manufacturing businesses across the UK. The three parts are simple to describe.
- The drum is the constraint. It sets the pace for the whole system, and its schedule is the master schedule. Everything else aligns to it.
- The buffer protects the constraint from upstream variation. It's a time target, not a stock target. If material isn't at the constraint by a set time, that triggers an expediting signal.
- The rope ties the release of material into the system to what the constraint consumes. It stops the site putting in more than the constraint can process within the buffer horizon.
The buffer is the part people most often get wrong. A time buffer tells you when to chase material, before the constraint runs out of work. A stock target only tells you how much to hold.
Protect the constraint before you spend money elsewhere
There's a corollary that should change how you approve capital and improvement projects. If the constraint is already fully fed, improving a non-constraint adds no throughput. It may still save some local cost, but it won't let the site make more.
So the order matters. Protect the constraint first, with buffers, maintenance priority and scheduling. Then decide where else money will genuinely raise throughput.
What to check on your own lines
- Do your operators know which machine is the constraint today? Ask a few of them.
- How do you measure the managers of non-constraint areas? If it's their own utilisation, expect them to resist subordination.
- When two machines are down at once, which one does maintenance go to first?
- Is there a buffer in front of the constraint? Is it set in time or in units?
- Do you inspect before the constraint, or do defects reach it and use up its capacity?
- Is there a project in your plan to improve a non-constraint? Check first that the constraint is fully fed and protected.
Subordination asks people to accept that their own number will look worse so the site's number gets better. That's a hard thing to ask without the right measures behind it. If you'd like help setting it up, please get in touch at makeitpossible@majaco.co.