Bottleneck Analysis and the Theory of Constraints

A bottleneck is the resource that limits the output of an entire plant: the machine, line or process step with the least capacity relative to the demand placed on it. Because every product must pass through this constraint, the plant can never ship more than the constraint can process, however hard everything else runs. The Theory of Constraints gives you a repeatable method for dealing with it, the five focusing steps: identify the constraint, exploit it, subordinate everything else to it, elevate it, and repeat.

What a bottleneck is and why it sets plant output

Think of your plant as a chain. Pull on it and it breaks at the weakest link, never anywhere else, and strengthening any other link changes nothing. Production works the same way. If your moulding line can produce a part every 30 seconds but the assembly cell behind it needs 45, the plant ships a part every 45 seconds. The moulding line's extra speed is irrelevant beyond that point. The slowest step relative to demand is the constraint, and in most plants there is exactly one at any given time.

This is the core insight of the Theory of Constraints, set out by Eliyahu Goldratt in his 1984 book The Goal: system output is governed by the constraint alone. It follows that most improvement effort in a typical plant is wasted, because it is aimed at resources that already have spare capacity. Making a non-constraint faster does not make the plant faster; it just makes the queue in front of the bottleneck grow more quickly. Once you accept this, improvement stops being a plant-wide scatter of projects and becomes a focused attack on one resource.

How to find the constraint on a real floor

You rarely need simulation software to find a stable constraint; the floor gives it away. Walk the line end to end and look for a handful of reliable signs.

Whatever the walk suggests, confirm it with data before acting. Compare demonstrated cycle times and utilised hours per station against demand, not against nameplate ratings: a machine that is fast on paper but down half the time can still be the constraint. Watch for wandering bottlenecks too. In high-mix plants the constraint can shift with the product mix, so identify it per product family, or use value stream mapping to see the whole flow at once.

• WIP piles up in front of it. Inventory queues wherever capacity drops. The biggest, most permanent pile of pallets or bins in the plant usually sits directly upstream of the constraint.
• It is always busy. Non-constraints wait for work at some point in the day. The constraint never does: it runs every available minute and the schedule bends around it.
• Downstream stations are starved. Operators after the bottleneck stand idle waiting for parts, not because they are slow but because nothing is arriving.
• Expedites fight over it. When a hot order lands, the argument is always about getting time on the same machine. Ask supervisors which resource they battle for.
• The operators already know. Ask anyone on the floor which machine the plant lives and dies by. The answer is usually right.

The five focusing steps

Goldratt's five focusing steps turn constraint thinking into a routine your organisation can actually run, in a fixed order. The order matters: the cheap steps come before the expensive one.

• 1. Identify the constraint. Name the single resource that limits throughput, using the signals above. Write it down and make it public; the whole plant should know where the constraint is.
• 2. Exploit the constraint. Get the most out of it without spending money. Run it through breaks and shift handovers, move quality checks upstream so it never processes scrap, stage material and tooling so changeovers are short, and give it your best operators. This step alone often uncovers real hidden capacity.
• 3. Subordinate everything else. Pace every other resource to the constraint. Non-constraints release work at the constraint's rate, a protective buffer of WIP sits in front of it so it never starves, and nobody chases local efficiency numbers elsewhere.
• 4. Elevate the constraint. Only now do you spend: add a shift, buy a second machine, outsource overflow, invest in tooling. Elevation is expensive, which is exactly why exploit and subordinate come first.
• 5. Repeat, and fight inertia. Once the constraint is broken, some other resource becomes the new constraint. Go back to step one, and dismantle any batch rules or buffers that only made sense for the old bottleneck.

An hour lost on the bottleneck is an hour lost for the whole plant

This is the most quoted line in The Goal, and it is arithmetic, not a slogan. A non-constraint has spare capacity by definition, so if it goes down for an hour it catches up later and the plant ships the same amount. The constraint has no spare capacity. An hour of downtime, a slow cycle or a batch of scrap at the constraint is output the plant never gets back, and no amount of overtime elsewhere can recover it. The mirror image is also true: an hour saved on a non-constraint is a mirage. It improves a utilisation figure on a report and changes nothing at the shipping dock.

This is why OEE on the constraint matters more than OEE anywhere else. A plant-wide OEE average blends machines whose losses cost you nothing with the one machine whose losses cost you everything. Measure availability, performance and quality on the constraint first, and treat every point of loss there as a plant-level loss; the commonly cited world-class benchmark of 85% OEE is most meaningful applied here. In practice that means the constraint gets first call on preventive maintenance slots, spare parts, changeover reduction work such as SMED, and micro-stop hunting, because a two-minute stop there is two minutes off the whole plant's output.

Common mistakes: improving everything except the constraint

The classic failure is spreading improvement effort evenly, or worse, aiming it where it is easiest. Raising OEE on a non-constraint feels productive, but it produces parts the constraint cannot absorb, so the only result is a bigger WIP pile and a better-looking local report. The related traps are familiar: chasing utilisation on every machine because idle equipment looks bad (subordination means non-constraints should sometimes wait), jumping to step four spending before exploiting at step two, letting the constraint sit idle through lunch breaks and handovers, running low-priority parts across it, and treating the whole exercise as a one-off project instead of repeating step one when the constraint moves. It also pays to standardise how throughput is reported, so nobody optimises a local number at the plant's expense.

You can start all of this with a clipboard, a stopwatch and a walk down the line, and for a stable constraint that is genuinely enough. The gap appears afterwards, in keeping watch: knowing every shift whether the constraint ran, why it stopped, and who is fixing it, so losses are logged rather than argued about at the morning meeting. That is a data collection problem, and it is worth solving properly for one machine even if you never instrument the rest. The partner we recommend, Fabrico, reads stops straight from the machines and shows the true cause of each stop on video. Fabrico is a partner we recommend; the tools here are free regardless.

FAQ

Related: how to calculate OEE · the six big losses · SMED & changeover · value stream mapping