Can you trust your OEE data, or is it just being reported?

There are two kinds of OEE number. One gets reported. The other gets trusted. Most production teams have the first and assume they have the second.

You know the pattern if you live it. The figure is there every morning. It goes up to group. The stand-up happens, and the same losses come back next week, untouched. It's easy to read that as a people problem. It almost never is. The real issue is quieter: the number on the board has drifted away from what is actually happening on the line, and nobody trusts it enough to act on it.

This post is about that trust gap. Not how to calculate OEE, and not where your capacity disappears, we've covered the capacity gap and how to improve OEE elsewhere. This is the narrower question: can you believe your own number, and what happens when you can't?

Reported is not the same as trusted

A reported number satisfies someone above you. A trusted number changes what you do next. The difference matters because a reported-only number does real damage. It feels like management information, so people plan around it, commit to orders against it, and defend it in meetings, even when the number is too incomplete to support those decisions.

We hear the symptom constantly. One manufacturer put it almost perfectly: we already know we have losses, but we can't explain why. They had a figure for availability, performance and quality. What they didn't have was the traceability to turn any of it into an owned action. Measuring OEE and trusting OEE are two different maturity levels, and improvement lives in the gap between them.

A 10-minute test: is your OEE trustworthy?

Before any project, you can find out where you stand this week. Pull a recent OEE report and run these five checks. They're designed to expose drift, not to flatter the line.

1. Hunt for short stops. Look for stops under five minutes. If there are almost none, that is not a clean line, it's a capture gap. Short stops always happen; a report that shows none is hiding them.

2. Scan your stop durations. If your downtime entries are mostly tidy round numbers, lots of 10s, 20s and 30s, you're seeing human rounding, not real timing.

3. Read ten downtime reasons. For each, ask: can I tell who owns the fix from this line alone? If the answer is “material issue” or “engineering” with nothing more, the category is not specific enough to assign ownership.

4. Cross-check engineering against the line. If a machine shows 90 minutes down but engineering logged 30, the missing hour is loss that nobody is accounting for.

5. Time your feedback loop. If you only see a loss an hour later, or the next morning, you can't act inside the shift where it still counts.

Two or more flags and your OEE is being reported, not trusted. That's not a failing, it's the normal starting point, and the causes are few and the fixes are practical.

Why manual and spreadsheet OEE always reads high

When OEE is captured by hand or in Excel, it drifts upward for reasons that are entirely human and entirely predictable.

The first is the vanishing short stop. Across a twelve-hour shift, nobody remembers every two-minute jam, every quick blade swap, every filter clean, and nobody wants to log them on the way out the door. Ten or fifteen small stops a shift simply evaporate, and only the big stops survive into the report.

The second is rounding. Asked how long a machine was down, people reach for a clean number. A 22-minute stop becomes 20 or 30. A 13-minute stop becomes 10. Each rounding feels trivial; summed across a week they erase real hours.

The third is vagueness. A note that reads "material issue" doesn't say whether it was the operator who missed a level check, the handler who loaded the wrong material, QA signing off late, or the previous shift. Without the owner, the loss can't be assigned, so it can't be fixed.

The fourth is lag. A manual or hourly process tells you about a loss after the window to influence it has closed.

Add these up and the number looks healthier than the line. It also explains something that surprises teams switching to real-time capture: the OEE score often drops at first. The line didn't get worse. The measurement got honest. You were making the same volume all along; now you can see what it cost you to make it.

A worked example: what happens when the number becomes trustworthy

The clearest proof of the trust gap is what happens when you close it. A high-speed manufacturer in the packaging and labelling sector already had OEE software running on three work centres, but it had never become part of the daily improvement process. The data was being collected, but it was not yet structured, reviewed, or used in a way that helped teams act on losses. When a new operations director joined, they wanted to know what it would take to get real value from it.

The answer started with trust. Working together, we focused on one workcentre, the bottleneck of the whole process, running at around 22% OEE, and rebuilt it properly: we revisited the downtime structure rather than taking it as given, aligned the production calendar with how the line actually ran, configured the right views for operators, shift leaders, and management, configured reporting dashboards around the KPIs that mattered most for that work centre, and set clear OEE targets. All this coupled with regular check-ins helped turn their data into action.

With a number people now believed, the line itself started to change. The changeover process was revamped, consumables were staged at the line instead of fetched mid-change, and equipment setpoints were fixed to remove setup variation. Quarter on quarter, OEE rose from 23.2% to 34.2%. Output climbed from around 223,000 to 287,000 units, an increase of almost 29%. Unassigned downtime on that line fell from about 20% to 5% or less.

None of that was unlocked by software alone. It came from trustworthy data, clear ownership, and a team willing to act on what the numbers showed.

The fix that pays back fastest: redesign your downtime categorisation

If you do one thing after the test above, make it this. The highest-leverage change for most teams isn't more sensors, it's rethinking how downtime is captured and labelled.

Start small and earn the detail.
A common failure is launching with 40 categories and 40 reasons beneath each. Faced with that, operators pick the first option and your data quality collapses on day one. Begin with a short, unambiguous list. Add granularity only once the basics are reliable.

Make logging effortless.
A short, clear list gets used well; a long, detailed one gets rushed. Remember what's useful to the person logging: an operator is focused on whether they're on target this shift, not on an OEE percentage. Give them that on screen, and capture the reason cleanly in the background.

Configure for action, not for a flattering score.
There's a real difference between configuring software and configuring it to drive value.
Changeovers are the classic case. If a changeover is planned at 30 minutes, set anything beyond that to count as an availability loss. Now the overrun is visible and owned instead of hiding inside "planned" time. Two lines can post an identical OEE while the story underneath, availability loss versus performance loss, points to completely different fixes. The categorisation is what surfaces that story.

Route the right view to the right person.

Operators need a target. Shift leaders need a line-side red or green, units made and current rate, readable on a walk past. Plant managers need a high-level view of which lines are falling behind, where losses are building, and where support or escalation is needed. Send the wrong data to the wrong person and they stop believing all of it. That principle is the heart of turning OEE into visual performance data teams actually use.

If you run a batch or process line, the same principle applies in a different shape. A batch is a sequence of timed phases, and the honest measurement is the overrun on each phase against its target cycle time, not a single batch number. Capture those phase overruns consistently and a trend builds that a headline OEE would have buried. We go deeper on this in our batch process OEE use case.

What changes when the number can be believed

Trustworthy OEE changes the conversation on the floor, and the surprises do the convincing. A fast line reveals hours lost to speed alone before you add a single downtime reason. A discrete operation discovers how much of its "downtime" has nothing to do with the equipment at all, it's waiting for parts, labour or quality sign-off.

There's a quieter effect too. People take pride in their line, and nobody wants theirs showing red while the next one runs green, so performance lifts on its own. Ask teams who have closed the gap what they'd never go back to, and the answer is always the same single word: paper.

That is where real-time OEE data matters: not as another report, but as a shared view of losses, with the downtime trends and actionable detail that teams can act on during the shift. It's what Maintmaster OEE is built to give you.

See the gap, with real numbers

If your OEE is good enough for reporting but you're not certain it's good enough to run your factory, come and pressure-test it with us.

On 25 June at 10am London time, Rob Brannan and Thomas McAlindon are hosting a live session: "Why most OEE numbers don't drive action."

We'll show you why spreadsheet-based OEE typically reads higher than reality, what that gap costs, and how to redesign downtime categorisation in a way you can apply the following week.

You'll leave with three things:

• A quick test for whether your own OEE data can be trusted

• The most common reasons figures drift from reality

• The categorisation approach itself.

It's built for operations directors, plant managers, Continuous Improvement and engineering managers who already track OEE but want to be sure it's telling the full story. Can't make the time? Register anyway and we'll send you the recording.