In any connected flow, one stage sets the pace. Improving any other stage changes nothing except the size of the queue.
Finding it
Look for where work accumulates. The stage with a persistent queue in front of it is the constraint.
Look for the stage that is never starved. Everything else waits sometimes; the constraint always has work.
Look for the highest utilisation against available capacity.
Check the queue over time, not at a moment. A queue that appears at ten and clears by noon indicates a temporary constraint rather than a structural one.
Three sources of data: queue length by stage, waiting time by stage, and utilisation by stage. They should agree, and where they disagree the data quality is the first suspect.
The counter-intuitive part
Improving a non-constraint stage produces no additional output.
It produces a larger queue in front of the constraint, more work in progress, and longer cycle times.
This is why local efficiency measures mislead. A stage running at high efficiency ahead of the constraint is actively harmful.
Which means idle time at non-constraint stages is correct, and measuring people at those stages on utilisation will produce exactly the wrong behaviour.
Exploiting it before expanding it
Cheaper interventions, in order.
Never let it starve. A buffer in front of the constraint so it never waits for work.
Remove non-essential work from it. Anything the constraint does that another stage could do.
Move quality checks upstream, so the constraint never processes something that will be scrapped.
Run it through breaks and shift changes, with staggered relief.
Reduce its changeover or setup time.
Only then add capacity, which is the expensive answer.
Subordinating the rest
Release work at the constraint's pace, not at the pace of the first stage.
This shortens cycle time immediately and costs nothing.
It looks like slowing down, and the upstream stages will appear less busy, which requires explaining before it is implemented.
Measure the output, not the busyness, during the transition, or the change will be reversed by someone reading a utilisation report.
The constraint moves
Always, after a successful intervention.
Which is progress, and should be stated in advance so that the reappearance of a bottleneck elsewhere is not read as failure.
Re-measure after every change. The previous analysis is stale the moment the constraint shifts.
Keep the queue chart running permanently, so the next constraint is visible rather than discovered by complaint.
Where it is not a single stage
Sometimes the constraint is not a stage at all: it is equipment shared across stages, a document approval, a system batch job, or dock capacity.
Shared resources are a common hidden constraint because they do not appear in any stage-level analysis.
Look for waiting that correlates across unrelated stages, which is the signature of a shared resource being the limit.
Dock and yard capacity is the constraint in more operations than realise it, and it is invisible inside the building.
The shared resource
The constraint that no stage-level analysis finds.
Sometimes the limit is not a stage: equipment shared across stages, a document approval, a system batch job, dock capacity.
Look for waiting that correlates across unrelated stages, which is the signature.
Dock and yard capacity is the constraint in more operations than realise it, and it is invisible inside the building.
Include the yard in the analysis, with arrival and departure timestamps, or the constraint will be attributed to whichever internal stage queues first.
Buffering the constraint
The cheapest exploitation step and the one that feels wrong.
A buffer in front of the constraint so it never waits for work.
This deliberately creates a queue, which looks like the thing you are trying to remove.
It is the right queue. Every minute the constraint is starved is output lost permanently.
Size it to cover the normal variation in upstream supply, no larger.
Keep every other queue small, which is what distinguishes this from simply flooding the floor.