Throughput is how much passes through per period. Cycle time is how long one unit takes end to end. Improving one can worsen the other.
The distinction
Throughput answers capacity questions: can we handle the volume.
Cycle time answers responsiveness questions: how long from order to despatch.
They are related by work in progress. For a stable system, work in progress equals throughput multiplied by cycle time — which means that adding work in progress increases cycle time without increasing throughput once the bottleneck is saturated.
This is the most useful relationship in the field and it explains why releasing more work to the floor makes things slower rather than faster.
Measuring throughput
Count completions per period at a defined point, consistently.
Choose the point deliberately. Units picked, orders packed and pallets despatched are different measures and will disagree.
Normalise for work content. Units per hour is meaningless across a mixed product range; use a weighted measure or report by category.
Report the distribution, not just the total. Throughput by hour of day localises the constraint.
Measuring cycle time
From a defined start to a defined end, stated explicitly.
Order to despatch is the customer-relevant version.
Task issue to task completion is the operational version.
Report percentiles, not the mean. The median tells you the normal case; the ninetieth percentile tells you what customers complain about, and the two frequently move in opposite directions.
Decompose it, which is where the findings are: waiting, travel, handling, checking, rework.
Work in progress as the control
The lever most operations do not use.
Excess work released to the floor increases cycle time and not throughput.
It also increases congestion, searching and errors, so it can reduce throughput.
Limiting release to what the constraint can absorb shortens cycle time immediately and costs nothing.
Measure work in progress by stage and look for the stage where it accumulates. That is the constraint.
Where the numbers mislead
Averaging across shifts with different mixes.
Counting completions at the wrong point, which double-counts rework.
Excluding exceptions, which are where the time goes.
Measuring a period that contains a peak and treating it as normal.
Comparing to a benchmark from a different operation, which differs in mix, layout and volume in ways that dominate any comparison.
Reporting them together
Throughput, cycle time percentiles and work in progress, on one chart, by day.
The three together explain each other. Rising cycle time with flat throughput and rising work in progress is a constraint saturating, which is a specific and actionable diagnosis.
Add the demand curve, so that a drop in throughput can be distinguished from a drop in demand — which is the most common misreading of a throughput chart.
Limiting work release
The cheapest intervention available and the one most operations have never tried.
Measure work in progress by stage and find where it accumulates.
Release work at the constraint's pace, not at the pace of the first stage.
Cycle time falls immediately, because units stop queueing.
Throughput does not fall, because the constraint was already saturated.
Upstream stages will look less busy, which needs explaining before implementation or the change will be reversed by someone reading a utilisation report.
Measure output, not busyness, during the transition.
Choosing the counting point
Throughput figures disagree because they are counted at different places, and the disagreement is usually blamed on the data.
Pick one point and state it.
Count completions there, consistently.
Decide how rework is counted, since a unit passing twice can be counted once or twice and both are defensible if stated.
Decide the unit: lines, units, orders, pallets. They give different answers and different pictures.
Publish the definition alongside the figure, because it will be compared against another team's figure counted differently.