One number, three factors, and a lot of places to hide.
Overall Equipment Effectiveness is the share of scheduled production time that produced good parts at full rate: availability × performance × quality. Each factor is a ratio between what an asset actually delivered and what it could have delivered had it never stopped, never slowed, and never made a bad part. The arithmetic is trivial; everything that makes an OEE number trustworthy or worthless happens in the definitions and in the data underneath it.
Three ratios, one product, no rounding of the awkward parts.
Realistic numbers
The familiar 85% “world class” figure is the product of 90% availability, 95% performance and 99.9% quality — a discrete-manufacturing aspiration, not a universal pass mark. Typical discrete plants that measure honestly land nearer 60%. TEEP, which uses all calendar time as the denominator, is always lower and is the number to use when you are arguing about buying another machine.
The six big losses
Breakdowns, setup and adjustment, idling and minor stops, reduced speed, defects and rework, and startup or yield loss. OEE is only useful when it is reported as this breakdown; the single percentage tells you the size of the problem and nothing about its shape.
What the data layer must supply
An equipment state model with reason codes captured at the source, counts from the same source as the state, a versioned ideal cycle time per product-machine pair, an agreed shift calendar, timestamps within about a second of each other across systems, and retained raw events so any published number can be reopened months later.
How OEE gets gamed — usually without anyone lying.
- Planned-downtime creep: reclassifying more and more lost time as “planned” so it leaves the denominator. The score climbs while the plant ships the same volume.
- Ideal cycle time set to the current achievable rate. Performance pins near 100% and the largest single loss on most lines becomes invisible.
- Counting reworked parts as good. Quality looks fine; the second pass through the line is simply unaccounted for.
- Micro-stops below the sampling resolution. If equipment state is only sampled every 30 seconds, a shift full of 10-second stops is recorded as uninterrupted running.
- Bucket shopping: quoting the best line, the best shift, or the best week as though it were the plant.
- Manual entry at end of shift. Reason codes chosen from memory under time pressure produce a Pareto chart of what people remember, not of what happened.
- Comparing OEE across different processes or products. It is a self-comparison metric; the trend and the loss split are the signal, the ranking is noise.
What has to be true underneath the number.
OEE is a downstream metric: it inherits every weakness of the data layer beneath it. State, counts and reason codes only join into a defensible number once they carry asset and product context, which is what contextualization adds and what a Unified Namespace makes reusable instead of rebuilding it per line. ISA-95 supplies the equipment hierarchy the losses roll up through, and how you get state and counts off the machine in the first place is the MQTT versus OPC UA question. Downstream, minor stops and speed losses are the raw material for root cause analysis, availability loss is what maintenance work is trying to prevent, and the loss story is what a crew should be handing over at the shift change.
An OEE percentage nobody can explain changes nothing.
OEE Narrator reads an OEE data bundle you supply — states, counts, reason codes, calendar — and writes the plain-language account a supervisor can act on: which losses moved, by how much, and against which reference period. It reasons over the export you give it; it does not connect to your machines. Five free runs, then it is part of the agents plan.
See OEE Narrator