OEE — Overall Equipment Effectiveness — is the most widely cited number in manufacturing. Every plant manager knows their OEE figure. Most can quote it to a decimal point. It sits on dashboards, it goes in board reports, it gets compared between sites and used to justify capital spend.
It’s also one of the easiest numbers in the factory to game, and a lot of the time the figure on the screen has very little to do with what’s actually happening on the floor. Overall Equipment Effectiveness is only ever as honest as the data feeding it.
I want to be fair about this. OEE is a good metric. The thinking behind it is sound, and when it’s measured honestly it tells you something real. The problem isn’t the formula. The problem is where the numbers come from.
What OEE actually measures
OEE is three numbers multiplied together:
Availability × Performance × Quality.
- Availability is the percentage of planned production time the machine was actually running. Breakdowns, changeovers and unplanned stops all pull it down.
- Performance is how fast it ran versus how fast it should run. Slow cycles, micro-stops and minor stoppages live here.
- Quality is the percentage of parts that came out good first time. Scrap and rework pull it down.
Multiply the three and you get a single figure between 0 and 100%. A line running at 90% availability, 95% performance and 99% quality gives you 85% OEE — which is the number you’ll often see cited as the “world-class” benchmark, though how far it applies depends heavily on your production type.
That 85% benchmark comes from Seiichi Nakajima, who built it into Total Productive Maintenance in 1980s Japan. It’s been the reference point ever since. The average plant sits closer to 60%.
So far, so textbook. There are two reasons the OEE figure on your board may not mean what you think it does — and they’re separate problems. The first is comparison: a bare number tells you nothing about whether it’s actually good. The second is data: even a fair target is worthless if the inputs feeding it are entered by hand. Take them in order.
The comparison problem
A bare OEE figure tells you nothing about whether it’s good.
A CNC job shop running forty different part types with constant setups might be doing genuinely excellent work at 70% OEE. A high-volume line stamping the same part all day might be underperforming badly at 80%. The 85% world-class figure was built around discrete, repetitive, high-volume production. Apply it to a high-mix shop and it’s meaningless — you’ll be chasing a target that was never designed for your process.
So when someone tells you their OEE, the first question is: compared to what? And the second, which is the harder one: measured how?
Why multiplying matters
The thing people miss about OEE is what multiplication does to it.
If you score 90% on all three — availability, performance and quality — you don’t get 90% OEE. You get 73%. Three respectable numbers combine into one mediocre one, because each loss compounds the others.
That’s actually the metric’s best feature. It stops you hiding behind one good number. You can’t wave away a 70% availability by pointing at 99% quality — the OEE drags it all back into one honest figure. A machine that’s available, fast and accurate is the only way to score well.
So the formula is doing its job. The question is whether the three inputs going into it are true.
Where the number starts to lie
Here’s the part most OEE software struggles to solve.
In most factories, those three numbers aren’t measured. They’re entered.
An operator writes down when the line stopped and when it started again. Someone keys in a reason code from a dropdown. Someone decides whether a 20-minute stoppage counts as planned or unplanned. The “performance” figure depends on a stated ideal cycle time that may have been set years ago and never revisited.
Every one of those is a human decision, and every one of them has a thumb on the scale:
- A stop gets logged as a changeover instead of a breakdown, because changeovers are planned and don’t hurt availability as badly.
- A reason code gets picked because it’s the least bad option in the dropdown, not because it’s accurate.
- Short stops under a few minutes never get recorded at all, because nobody’s standing there with a clipboard for a 90-second jam.
- The ideal cycle time gets quietly softened so performance always looks healthy.
None of this is necessarily dishonest. A lot of it is just people being busy. But the result is the same: the OEE number on the board is a story about the factory, not a measurement of it. And when that number is used to compare sites or chase a bonus, the incentive runs entirely the wrong way — the easiest way to improve OEE is to record it more kindly, not to run the machine better.
The micro-stop problem
The single biggest gap is the small stuff.
A line that stops for 90 seconds, forty times a shift, has lost an hour. But those stops are below the threshold anyone bothers to log, so they vanish from the availability figure entirely. The OEE looks fine. The machine has been bleeding for the whole shift.
This is exactly the kind of loss that manual data collection is structurally incapable of catching. You cannot ask an operator to record every micro-stop by hand — there are too many, they’re too short, and the act of recording them would itself stop the work. So they go unrecorded, and the OEE number gets quietly inflated by the very losses it’s supposed to expose. This is the same blind spot I wrote about in The Missing Piece of the Jigsaw — the gap between what’s happening on the floor and what anyone actually knows about it.
Where honest data comes in
None of this means OEE is worthless. It means OEE is only as good as the data underneath it — and the fix is to take the human thumb off the scale.
The availability half of OEE is the part that doesn’t have to be entered by hand. A machine knows when it’s running and when it’s stopped. The controller knows. The fault log knows. That information already exists inside the machine — the only question is whether anyone is reading it.
What RoboVigil fixes
It fixes availability — the component that gets gamed hardest, and the one that’s pure machine fact in the first place. RoboVigil connects to the machine’s own controller — ABB, FANUC, Universal Robots, or anything speaking OPC-UA or MQTT — and reads run state, stops and faults straight from the source. No clipboard, no dropdown, no operator deciding after the fact whether a stop was planned. When the machine stops, that’s recorded because the machine said so, not because someone remembered to write it down. The micro-stops that manual logging can’t catch are exactly the events a direct controller connection sees without effort.
What it doesn’t fix
It does not fix quality. Hidden first-off rejects, unlogged rework, a scrap count that gets rounded down at the end of the shift — those are still human inputs, and a controller connection can’t see them. Quality data is just as easily massaged as availability ever was. We don’t pretend to solve that here; it still needs visual inspection and operator honesty. What a direct connection does is take the single most-gamed component off the table entirely, so the part of OEE that should never have been a matter of opinion stops being one.
Why availability comes first
Does that leave a gap? Yes. But look at the order it has to be fixed in. If your availability is really 75% while you’ve been logging 90%, then the “85% OEE” on the board has been flattering you all along:
| Metric | Reported | Actual |
|---|---|---|
| Availability | 90% | 75% |
| Performance | 95% | 95% |
| Quality | 99% | 99% |
| OEE | 85% | 70% |
The difference between reported and actual availability is enough to turn an apparently world-class line into a merely average one — same machine, same shift, just honest numbers. And every quality decision you’ve made has been built on a phantom amount of running time. You can’t sensibly chase quality losses until you know how much time you actually had to make parts in the first place. Fixing availability first exposes the real capacity of the line. Once that foundation is solid and trustworthy, the gap that’s left is genuinely a quality gap — and that’s where you point your improvement effort. One problem at a time, starting with the one the machine already knows the answer to.
The point isn’t surveillance — and it never is with RoboVigil. It’s that the continuous-improvement lead or maintenance manager walks into the Monday shift meeting with availability data the floor can’t argue with — because the robot reported it, not the shift lead’s memory. That changes the conversation from “I think we lost about half an hour” to “we lost fifty-one minutes across thirty-eight stops, here they are.” You can’t run an improvement programme on numbers everyone quietly knows are soft.
RoboVigil isn’t an OEE platform, and it doesn’t pretend to be. It’s the layer underneath — the thing that tells you what the machine actually did, so that whatever OEE figure you build on top of it is standing on measured reality rather than a tidied-up story.
The honest version
OEE is a good metric measured badly almost everywhere it’s used. The formula is sound. The 85% benchmark is real, even if it’s misapplied constantly. The maths does exactly what it’s meant to do.
What lets it down is the data — hand-entered, threshold-blind, and quietly optimistic. Fix that, and OEE becomes what it was always supposed to be: an honest measure of how well your equipment is actually working. Leave it as it is, and it’s a number that makes everyone feel better while the machine quietly loses an hour a shift to stops nobody wrote down.
Here’s a test you can run this week, no software required. Walk your floor and look at the last ten recorded stops on your highest-volume line. Then ask the operator how many short stops they’ve had today that didn’t make it onto the log. If the honest answer is “loads, I don’t write those down” — you’ve just found capacity that isn’t on anyone’s OEE figure. That gap is exactly what a direct controller connection captures automatically, and it’s usually bigger than anyone wants to admit.
The next time someone quotes their OEE figure at you, don’t ask about the formula — ask them how they got the numbers. If the answer involves a clipboard, you already know the real number is lower.
Measure the machine, not the paperwork.
The 85% world-class benchmark and its component targets (90% availability, 95% performance, 99% quality) originate with Seiichi Nakajima’s foundational work on Total Productive Maintenance in 1980s Japan, set out in his 1984 book Introduction to TPM. The ~60% all-industry average figure is consistent with published benchmark data from OEE software vendors including Evocon and Fabrico, whose analyses draw on thousands of connected machines across dozens of countries.
