What Is OEE and How Is It Calculated?

OEE is the most widely used — and probably the most widely misread — metric on the shop floor. It appears as one percentage, but three separate questions sit behind it.

The formula

OEE = Availability × Performance × Quality

Each component captures a different kind of loss:

Availability — did the machine run when it was supposed to? Run time ÷ Planned production time Breakdowns, setups and changeovers come off here.

Performance — did it run at the speed it should have? Actual output ÷ Theoretical maximum output Slow cycles, micro-stops and idling come off here.

Quality — were the parts it made good? Good units ÷ Total units produced Scrap and rework come off here.

A worked example

Take an 8-hour shift (480 minutes):

• Planned stops (breaks, planned maintenance): 30 min → planned production time 450 min
• Unplanned downtime (breakdown + changeover): 60 min → run time 390 min
• Theoretical rate: 10 parts per minute → 3,900 parts expected in 390 min
• Actual output: 3,200 parts
• 96 of them scrap → 3,104 good parts

The calculation:

• Availability = 390 ÷ 450 = 86.7%
• Performance = 3,200 ÷ 3,900 = 82.1%
• Quality = 3,104 ÷ 3,200 = 97.0%
• OEE = 0.867 × 0.821 × 0.970 = 69.0%

Note what happened: all three components look respectable, yet the product falls to 69%. That’s the instructive part of OEE — losses don’t add up, they multiply.

What counts as a good score?

The commonly cited world-class benchmark for discrete manufacturing is 85% (roughly 90% availability × 95% performance × 99.9% quality). Most plants, when they first measure honestly, land somewhere below 60%.

But chasing the headline number alone invites mistakes. The useful question isn’t “what’s our OEE?” but “which component is low, and why?” Two lines both at 69% can have completely different problems: one losing to breakdowns, the other to slow cycles. Same number, different work.

Common mistakes

Counting planned stops as unplanned. Breaks and planned maintenance belong outside the denominator. Leave them in and OEE reads unfairly low.

Confusing it with capacity utilisation. A line stopped because there are no orders lowers utilisation, not OEE. OEE answers “how well did we run while we were running?”

Trusting hand-collected data. When downtime reasons are recalled at the end of a shift and written on a form, the frequent micro-stops disappear systematically. Automatically collected data shows them for the first time — and they’re often the largest single category.

Turning one number into a target. OEE is a diagnostic, not a bonus table. The moment it becomes a target, the easiest way to improve it is to corrupt the measurement.

Where the data comes from

OEE is only as good as the data underneath it. Cycle counters, state signals and downtime reasons already exist in most PLC/SCADA infrastructure; the work is collecting them in one place and computing them against the right denominators.

OnoTwin Studio does this per machine in real time — breaking OEE into its components and showing which downtime reason recurs how often. You can try the live demo in your browser.