Ask a room of plant people what a good OEE is and someone says 85%, confidently. The number is real — it's the world-class convention from Seiichi Nakajima's original framework — but it's also the most misused benchmark in manufacturing. Most plants measuring honestly for the first time land near 60%, and that's normal. Here's where the bands come from and how to read your own score.
OEE = Availability × Performance × Quality, and Nakajima's world-class reference values multiply out to roughly 85%: 90% availability, 95% performance, 99.9% quality gives 90 × 95 × 99.9 = 85.4%. Note what that mix implies. World class isn't 95% of everything — it's near-perfect quality, very good speed, and one shift in ten still lost to stops. The bands in circulation descend from there:
| OEE | Reading |
|---|---|
| 100% | Perfect production — theoretical only |
| 85%+ | World class (OEE.com convention) |
| ~60% | Typical first honest measurement |
| ~40% | Low; usually data problems or unmeasured stops |
Because losses compound, the three factors multiply rather than average. A plant at 90% availability, 90% performance, and 90% quality is not at 90% OEE — it's at 72.9%. Three separate 10% leaks drain 27% of output. That's the entire argument for OEE as a metric: it refuses to let three individually-tolerable losses hide behind an average.
Because measurement replaces assumptions. Before OEE, minor stops were absorbed by the schedule, slow cycles were invisible inside the standard rate, and startup scrap never hit the yield report. The first month of real data drags all three into the light, and the score drops 20 points from what the whiteboard claimed. The plant didn't get worse; it got visible. Baseline after the data stabilizes, then trend — the trend is the management tool, not the absolute.
No, and the difference is the denominator. OEE divides by planned production time: the hours the schedule says the line runs. TEEP — total effective equipment performance — divides by all calendar time, which exposes the capacity you're choosing not to schedule. A line running 85% OEE across two shifts shows about 57% TEEP (16 ÷ 24 hours scheduled × 85%), because 16 hours a day are unscheduled. OEE answers "how well do we run what we scheduled?" TEEP answers "how much of the asset are we using?" Plants chasing demand growth want TEEP; plants fixing execution want OEE.
No, and applying it everywhere wastes money. OEE improvements on the bottleneck convert directly into sellable output; on non-bottlenecks they mostly build inventory. The theory of constraints logic is blunt: measure broadly if you want visibility, but spend improvement capital where the constraint is. A 60% OEE on the constraint line deserves a war room; 60% on a redundant backup press might deserve nothing.
Take one shift of real data: 480 planned minutes, 47 minutes down, 260 parts at a 1.5-minute ideal cycle, 248 good. Availability 433/480 = 90.2%, performance 390/433 = 90.1%, quality 248/260 = 95.4%, OEE 77.5%. At 100% the shift makes 320 good parts, so the three losses cost 72. That's a solid but unspectacular shift, and its weakest factor — quality, dragged by 12 rejects — is where the next point of OEE is cheapest if the rejects share a cause like first-piece setup.
Climbing from 77.5% toward 85% is worth about 9.7% more good output at the same staffing (85 ÷ 77.5), which usually beats buying capacity. To price that climb in dollars rather than points, pair the metric with downtime cost; to attack the failure side of availability, start with MTBF.
Enter planned time, downtime, cycle time, and counts — get OEE with all three factors and the perfect-shift ceiling.
OEE Calculator →85% is a world-class reference point, not a mandate. Benchmark honestly against your own baseline, watch the factor mix rather than the headline, reserve aggressive targets for constraints, and use TEEP when the question is asset utilization. For the neighboring metrics, our guides on MTBF and availability and the cost of downtime cover the maintenance side of the same story.
Any factor over 100% means a data error, and performance is the usual suspect: the ideal cycle time in the system is slower than the machine's real demonstrated rate, so actual output outruns "perfect." Fix the ideal cycle time rather than capping the number, because a wrong denominator corrupts every trend built on it.
The classic taxonomy OEE was built to track: breakdowns and setup/adjustments (which hit availability), minor stops and reduced speed (which hit performance), and startup rejects plus production rejects (which hit quality). Naming the loss before fixing it matters, because each category has different owners: maintenance owns breakdowns, engineering owns speed, quality owns rejects.
No. OEE earns its keep on constraints and bottleneck assets, where every recovered percentage turns directly into sold output. On non-bottlenecks, higher OEE just builds inventory. Measure broadly if you like, but set improvement targets where the theory of constraints says the hour is worth the most.