Measuring OEE correctly: what gets lost between the counter and the report

OEE is a product of three definitions, not three numbers

The formula is simple: OEE = Availability × Performance × Quality. Three ratios collapse into one dashboard percentage. But each factor hides a definitional decision nobody wrote down, and the same line, the same shift, the same output can read 74% under one definition set and 86% under another. That gap is not measurement error; it is a choice about which minutes count as “planned”.

Availability: the argument is in the denominator

Availability = run time / planned production time. The numerator is rarely disputed; the trap is the denominator. Take a 480-minute shift with 30 minutes of breaks, 15 of handover, 20 of planned cleaning and 60 of unplanned downtime: run time is 355 minutes.

Nothing changed on the floor and 11.5 points were gained. Two safeguards:

• Do not let excluded time disappear. Breaks, handover, planned maintenance and no-demand minutes belong in a separate planned-downtime figure, or exclusion becomes a hiding place.
• Keep a calendar-based second figure. With no-demand time excluded, a line at half load scores high; TEEP (Total Effective Equipment Performance) divides by calendar time and closes that illusion.

Deferred maintenance returning as a breakdown moves to unplanned downtime — often the only signal that the plan is not working.

Performance: where the ideal cycle time comes from

Performance = (ideal cycle time × units produced) / run time. The only unknown is the ideal cycle time, and most plants take it from the wrong place.

The nameplate value is what the supplier measured with one product, nominal material and new tooling under laboratory conditions; it does not hold for a real product mix. Establish it instead:

1. For one machine and one product, histogram the cycle times over at least two weeks.
2. Do not take the absolute minimum — usually a sensor glitch or double count. Take the stable band at the fast end, in practice the 5th percentile (P5).
3. Store it per product and per tooling set. One ideal cycle for a machine running two products makes performance swing as the mix changes.

Performance above 100% is an error signal: wrong ideal cycle, double counting, or a counter placed before inspection.

The speed override is a hidden loss too — at a 90% setpoint cycles stretch and surface as a performance loss with no visible cause; without that signal the cause is never found.

Quality: where you put the counter

Quality = good units / total units. The traps:

• Rework. Booked as good at the end of the line, the quality loss disappears while the time spent surfaces as a performance loss.
• Late detection. A lab result arriving three hours later charges scrap to the shift that entered it, not the one that produced it. Writing it back into the production window is a timestamp problem.
• Start-up scrap. The first parts after a changeover usually go uncounted, yet they measure changeover loss most concretely.

Good and bad counts belong on separate counters at the machine, the bad one carrying a defect code; quality cannot come from a single “units produced” total.

Where micro stops disappear

Micro stops — jams, misfeeds, 5 to 20 second stoppages — are OEE’s most systematic blind spot. If your source is a “machine stopped” bit polled once a minute, or a record only opens above five minutes, micro stops vanish from availability. Not from output: they reappear as a performance loss, or nowhere at all if the ideal cycle is also wrong.

In short: log everything, prompt for little. Charging micro stops to availability or performance is a choice; what matters is that it is written down and that the losses add to 100%.

Who classifies the downtime reason

Automatic classification knows only what the machine knows: a material-empty sensor, an open guard door, an alarm code. “The operator was waiting for a forklift” is not in that set. Operator entry closes the gap at a cost: as the burden grows, either the first reason gets picked or “no reason entered” grows. Track that category as a first-class metric — above 10–15% of downtime minutes the problem is the reason tree or the entry screen, not the operator. A tree that works:

• Two levels at most, 8–12 items at the top level.
• Per machine — not one plant-wide list of 120 items.
• Sorted by frequency, not alphabetically.
• “Other” never first; it sits at the bottom and its share is monitored.
• Corrections allowed within the shift, with an audit trail — otherwise arbitrary reasons get entered under pressure.

No clock sync, no correlation

The PLC, the SCADA server, the MES, the lab system and the ERP each carry their own time. Quartz drift in a PLC runs to seconds per day, becoming minutes over months. Four minutes of offset puts a three-minute stop on the wrong order, wrong product, possibly wrong shift, and any alarm-to-defect link turns into noise. The minimum setup:

• NTP on every device that can take it, and a single time source per plant.
• Timestamps stored in UTC; local time produced in the presentation layer.
• The timestamp applied at the source. Stamping when the collector writes bakes queueing delay into the data, unrecoverably.
• PLC-to-server offset measured continuously, alarming above 2 seconds.
• Mode and counter signals written on change (event based), not polled — sampling a boolean once a second shifts the edges.

Why cross-plant comparison misleads

Two plants at 71% and 78% are comparable only if four things match: planned production time definition, ideal cycle source, micro stop threshold, product mix. Long batches of one product structurally outscore six changeovers a day — not better management.

What is comparable: a line’s own time series and the loss breakdown. A Pareto of downtime minutes by reason is actionable when the headline percentage is not. Across sites, compare loss category shares, never the OEE figure.

Signals to collect, and at what rate

Nothing feeding the OEE arithmetic should be polled once a minute. Building that layer is data acquisition and analytics work, but whether the signals exist at all is settled on the industrial automation side, when the tag dictionary is written.

The definitions that must be written down

One page, signed by production, maintenance and quality:

• Planned production time, item by item: breaks, handover, planned maintenance, no demand, training, trial runs.
• The micro stop detection threshold and the reason-entry threshold.
• The ideal cycle time source, its value per product, its last revision date.
• The good/bad counting point; how rework and start-up scrap are counted.
• Shift boundaries, and how a stop crossing one is split.
• Who may correct a record, within what window.
• The time source and the accepted drift tolerance.

When the document changes, its version increments and charts show which version produced them — otherwise a definition change reads as improvement.

What you can do tomorrow

1. Pull last month’s downtime records and calculate the share of “no reason entered” minutes. One number tells you your data quality.
2. Histogram cycle times for one machine and one product; compare P5 with the nameplate.
3. Compare the PLC clock on three machines against the time server; note the offset.
4. Recalculate last month’s OEE under two planned production time definitions and look at the gap in points.
5. Start the definition document. Every item you cannot answer is your first data gap.