Why should I measure OEE at the bottleneck instead of every machine?

Because the bottleneck sets plant output. An hour recovered at the constraint is an hour more product shipped, while an hour recovered at a buffered non-constraint usually ships nothing extra. Measuring every machine produces a wall of percentages you cannot act on, so the discipline is rigorous OEE at the constraint and simple downtime tracking everywhere else.

How do I find the bottleneck machine?

Watch where work piles up and where it starves. The constraint has product accumulating in front of it and machines downstream frequently waiting. Confirm with three signals: the longest per-unit cycle time at nameplate, the fullest upstream buffer, and a stop-test, since when the true constraint stops the whole line stops shortly after as buffers drain.

Why is my non-bottleneck machine's OEE low?

Usually because it is starved or blocked by the constraint, not because it is failing. A machine faster than the constraint must idle so it does not overflow the buffer, and a downstream machine must wait to be fed. That idle time lowers its OEE, but it is the line working as designed. Chasing that number builds work-in-process without shipping more.

Does an hour of downtime at a non-bottleneck matter?

Only if it starves the constraint. If a buffer covers the outage and the constraint keeps running, the plant ships the same amount and the hour cost nothing. If the buffer drains and the constraint stops, that hour became lost plant output. So for non-constraints the real question is whether they ever starved the constraint, not their standalone OEE.

How do you calculate OEE for a constraint machine specifically?

Use the standard Availability times Performance times Quality, but attribute every lost constraint minute to a cause, including the minutes it sat starved or blocked by other machines. Record those starve and block minutes against their upstream cause, because that is where the plant actually lost output, and that attribution is what makes constraint OEE actionable rather than just descriptive.

Should I roll bottleneck OEE into a plant-wide number?

No. A plant average blends the constraint that limits sales with fast non-constraints and hides the only number that matters, often inviting effort on machines that change nothing on the shipping dock. Keep the constraint's OEE as its own figure, track its trend, and treat non-constraints as downtime logs rather than folding everything into one percentage.

OEE for Bottleneck Machines

Q: What happens to OEE tracking when the bottleneck moves?

Identify the two or three machines that take turns being the constraint as product mix changes, and measure OEE on that small set, reading whichever is the active constraint for the current run. Do not hard-code OEE to one machine, or you will optimize the wrong one half the time, and do not roll the set into a plant average nobody can act on.

An hour lost at the constraint is an hour lost for the whole plant, why you measure OEE at the bottleneck first, and read every other machine differently.

OEE for a bottleneck machine is the OEE that matters most, because an hour lost at the constraint is an hour of output lost for the whole line. An hour lost at a non-constraint machine is frequently absorbed by a buffer and costs nothing. So you measure OEE rigorously at the bottleneck first, and read every other machine's number in that light.

Most plants measure OEE everywhere and act nowhere, drowning in a wall of percentages. The constraint-first approach is the opposite: find the one machine that governs output, make its OEE honest, and improve it. This guide shows why bottleneck OEE dominates, how to find the constraint, why non-bottleneck numbers mislead, and what to do when the bottleneck moves. For the base method, see the OEE calculation; for the theory, theory of constraints.

Why does bottleneck OEE matter more than plant-average OEE?

Bottleneck OEE matters more because the constraint sets the plant's output, and nothing else does. Improve the constraint by an hour and the plant ships an hour more product. Improve a non-constraint machine by an hour and, unless that machine was starving the constraint, the plant ships exactly the same amount, you have only built inventory or created idle time somewhere else. This is the core insight of the theory of constraints: the system's throughput equals the constraint's throughput.

A plant-average OEE blurs this. Averaging a constraint at 65% with four non-constraints at 90% produces a comfortable 85% that hides the only number that limits sales. Worse, it invites the plant to “improve the average” by squeezing already-fast non-constraint machines, which changes nothing on the shipping dock. The constraint's OEE is the plant's real effectiveness; the average is decoration.

An hour lost at the constraint is an hour of plant output gone. An hour lost at a buffered non-constraint is often absorbed with no output impact. This is why the constraint's OEE is the one to defend.

How do you find the bottleneck to measure?

Find the bottleneck by watching where work piles up and where it starves. The constraint is the machine with product accumulating in front of it and the machines downstream of it frequently waiting. Three practical signals point to it: the longest per-unit cycle time at nameplate, the fullest upstream buffer, and the machine other people already blame when the line misses its number. Formal bottleneck analysis confirms it with data.

Once you have a candidate, verify by asking what happens when it stops: if the whole line stops shortly after (buffers drain), it is the constraint. If the line keeps shipping from buffer for a long while, it is not. Then check constraint utilization a true constraint runs close to fully loaded whenever the line runs, because everything is waiting on it.

The constraint is where work accumulates in front and machines downstream sit starved. A stop-test confirms it: when the true constraint stops, the line stops shortly after as buffers drain.

Why do non-bottleneck machines show misleading OEE?

Non-bottleneck machines show low Availability and Performance for a reason that has nothing to do with their condition: they are starved or blocked by the constraint. An upstream machine faster than the constraint must idle so it does not overflow the buffer; a downstream machine must wait for the constraint to feed it. That idle time drags their OEE down, but it is the line working as designed, not the machine failing.

If you chase those low numbers, buying a faster upstream machine, running it harder, you produce more work-in-process the constraint cannot absorb, and the plant ships no more. This is why the pattern is rigorous OEE at the constraint and simple downtime tracking everywhere else. The non-constraint question is not “what is its OEE” but “did it ever starve the constraint”, and that is a downtime-and-buffer question, not an OEE one. Balancing the flow around the constraint is a line balancing exercise, not an OEE-maximizing one.

How do you calculate OEE at the constraint?

Calculate it the standard way, with one guardrail: count only stops that actually cost the constraint time. A hypothetical example on a constraint machine: 450 minutes planned production time; 63 minutes of its own downtime and changeovers; 22 minutes it sat starved because an upstream machine failed. Run time for Availability is 450 − 63 = 387 minutes, but the 22 starved minutes are a real loss of constraint time and must be recorded, tagged to their upstream cause, because that is where the plant lost output.

With a 60-unit-per-minute ideal rate, 19,800 total units, and 19,206 good: Availability = 387 ÷ 450 = 86.0%, Performance = 19,800 ÷ (387 × 60) = 85.3%, Quality = 19,206 ÷ 19,800 = 97.0%, OEE = 71.1%. The discipline unique to constraint OEE is attribution: every lost constraint minute gets a cause, including the minutes stolen by other machines, so improvement effort lands where the plant actually bleeds. That attribution is also the honest way to read throughput against OEE.

What happens when the bottleneck moves?

The bottleneck moves when product mix changes, and a constraint-first program has to move with it. A line running a simple SKU may be constrained by the filler; the same line running a complex, label-heavy SKU may be constrained by the labeler. If you hard-code OEE to one machine, you will optimize the wrong one half the time.

The fix is to identify the two or three machines that take turns being the constraint and measure OEE on all of them, then read whichever is the active constraint for the current run. This is a small, stable set, not the whole line, so it keeps the constraint-first discipline without collapsing into measure-everything. Resist rolling them into a plant average; a single blended number across shifting constraints is exactly the figure nobody can act on.

How do you run a constraint-first OEE program?

Stand it up in this order and keep it small:

Identify the constraint. Use accumulation, cycle time, and a stop-test to confirm which machine governs output right now.
Instrument the constraint for real OEE. Machine-signal counts and logged stops, not end-of-shift estimates.
Attribute every lost constraint minute. Tag its own downtime, its speed loss, its scrap, and the minutes it was starved or blocked by others.
Track non-constraints as downtime only. The question there is whether they ever starved the constraint, not their standalone OEE.
Map the shifting constraints. List the two or three machines that trade the title with product mix, and measure OEE on that set.
Protect the constraint's time. Staff breaks and changeovers so the constraint never stops for want of a person; use SMED to shrink its setups first.
Review the constraint's trend, not the average. One honest number, trending, beats a wall of percentages.

What should you benchmark the constraint against?

Benchmark the constraint against its own history, with two context numbers stated plainly for what they are:

ISO 22400-2:2014 defines OEE and its input time-states precisely, which makes a constraint's number comparable shift to shift and site to site (ISO 22400-2).
The 85% world-class figure is Nakajima's 1980s TPM reference point, not a certified benchmark, useful context, especially read alongside what a good OEE score is. Remember that a constraint often scores lower than pampered non-constraints precisely because it never gets to idle.
U.S. manufacturing capacity utilization was 75.7% in May 2026 per the Federal Reserve's G.17 release (Federal Reserve G.17), a reminder that whole economies run below theoretical maximums, constrained plant by plant.

The payoff of constraint-first OEE is focus: one machine, one honest number, one place to improve that actually moves shipments. Harmony computes OEE from the constraint's own PLC and sensor signals, and attributes starve/block minutes to their upstream cause, rather than relying on estimates (see the platform and the CLS case study). Put your constraint's numbers through the OEE calculator and watch the trend, not the average.