If your OEE score has been steady at a certain level and nobody can explain why, the score is almost certainly wrong. Here are the five things most plants get backwards, and how to fix each one before your next shift report goes out.
Introduction
OEE, or Overall Equipment Effectiveness, is calculated by multiplying quality, availability and performance. While the math takes around ten seconds, getting the inputs right costs most plants numerous years, and a lot of arguments on the shop floor. And in case the inputs are wrong, the final number could lie in either direction. It may look better than reality, or it may also look worse, but it’ll almost never match what is actually happening at the machine.
This article addresses that gap. Not the formula. We’ll go over the five areas where the inputs go wrong, why they go wrong, what changes when you fix them, and how.
Why this matters before we get into the mistakes
A wrong OEE number is worse than no OEE number at all. With no number, a plant manager knows they are working blind, and they have to act accordingly. They walk the floor, ask questions, and have to place major trust in their operators. On the other hand, with a wrong number that looks plausible, the same plant manager makes confident decisions based on bad data. Those decisions are harder to unwind.
So, before talking about improving OEE, the more important conversation is whether the OEE you are tracking reflects reality. In our experience working with plants across FMCG, Food and Beverage, Chemical, and process industries, the answer is usually no. Not because anyone is trying to cheat the number. Because the inputs are harder to define than they look.
Here are the five mistakes we see most often
Mistake 1: Treating planned downtime as if it were free
This is a more common one, and in turn, the most consequential. Every plant has to determine what constitutes as Planned Production Time. Planned changeovers, scheduled maintenance, training, breaks, no production scheduled, etc. The question is which of these come out of the denominator and which stay in.
If you remove everything, your availability number gets very kind to you. A line that ran for six hours during an eight hour shift, with two hours of planned changeover, gets credited with 100% availability. The number is technically correct under that definition. It is also useless, because nobody is going to take action on a line that already says it is perfect.
The fix is to be honest about what is genuinely outside operational control and what is not. Plant-wide holidays are outside control. However, what’s absolutely inside control is a scheduled changeover that’s taking 90 minutes when the engineered standard is 30 minutes, and pulling it out of the denominator is how plants accidentally hide their biggest losses. One of our FMCG customers found that their real availability was 11 percentage points below their reported number, simply because changeover overruns were being classified as planned time.
Mistake 2: Using a 'design speed' that nobody actually believes
Performance is calculated by comparing the throughput a machine could have achieved at ideal cycle time against what it actually produced. The real trap lies in the word ‘ideal’.
For any given machine most plants have three numbers:
- The speed the engineering team thinks is realistic for current product mix and material conditions
- The OEM design speed printed on the spec sheet
- The speed the line has actually achieved on a good day in the last six months.
These three numbers usually differ. And whichever one you pick, you may come to regret it. If you pick the OEM design speed, your performance looks broken. Pick your best day ever and your performance looks great. But what is it being compared to at this point? Suddenly, you’ve stopped measuring improvement.
The real problem is picking one and sticking with it so your numbers actually mean something. What you should do is pick one definition, document it, and apply it steadily across machines that are doing similar work. The wrong method would be to let every line, every shift, and every product use a different reference speed, because at that point your OEE numbers are not comparable to each other. The analytics layer on top of them is making decisions on incomparable data.
Mistake 3: Counting rework as good production
Quality stands as the simplest of the three pillars to define and also, the easiest to fudge. It is the count of good units divided by the total count produced. Defective units come out of the numerator.
The error happens when nobody is sure what counts as defective. A unit that came off the line, failed a quality check, went back through a rework station, and eventually shipped to a customer. Was that a good unit or a defective one? Operationally it was both. From a quality perspective the line produced it incorrectly the first time. From an inventory perspective the customer got their product.
If you count it as good, you lose the signal that something is going wrong at that station. The performance pillar will show the line running at speed. The availability pillar will show it running through the shift. The quality pillar will say 99%. And the next week, you will find yourself wondering why your overtime budget is so high. The answer is sitting in the rework log that the OEE calculation never looked at.
In our work with Emirates Macaroni Factory, the General Manager Roberto Traversay made this point directly. The team installed sensors on every machine so they could analyze production down to the minute, across machines, items, and shifts. The visibility he was looking for was not the rolled-up OEE number. It was the granularity to see when a specific machine, on a specific shift, was quietly producing units that would need rework later. That is the level you need to be at if quality is going to mean anything in your OEE.
Mistake 4: Aggregating to a daily number and stopping there
The daily OEE report is a comfortable artifact. It comes out the next morning, somebody looks at it, somebody pastes it into a slide for the weekly review, and the number gets tracked over time. The line graph is satisfying. There is a trend. There is even sometimes an explanation for the trend.
The problem is that a daily OEE number cannot tell you anything actionable about the production KPIs you actually need. It tells you yesterday happened. It cannot tell you that the third shift on Tuesday was running at 62% because of a recurring micro stoppage on the filler that the day shift never sees. It cannot tell you that one operator on Line 4 consistently runs the equipment at 8% below the line average. It cannot tell you anything that helps a supervisor make a different decision tomorrow.
Shabbir Muhammad, who runs supply chain operations at Tapal Tea, put this very clearly. Before they had real-time visibility, it took two to three days to resolve issues. After, it takes two to three hours. The change was not that the OEE calculation got better. The change was that the OEE data became available at the time scale where someone could act on it. Yesterday’s number is a report. This shift’s number, broken down by machine and stoppage reason, is a decision.
If your OEE tracking system gives you a daily roll-up and nothing finer, you are running a reporting tool, not an operational one.
Mistake 5: Trusting manual data entry on a busy line
This is the one nobody likes to talk about. Most OEE systems in mid-sized plants still rely on operators or supervisors to log downtime events and reason codes by hand, usually on a clipboard or a tablet at the line. The data feeds into the calculation. The calculation feeds into the report. The report goes to leadership.
The breakage point is the first step. When a line goes down at 2 AM during a difficult shift, the operator on duty is solving the problem, not logging it. By the time the line is back up, the reason for the stoppage is fuzzy, the duration is approximate, and the reason code that gets entered is whatever was easiest to remember. Sometimes the event is not logged at all. Multiply this across thousands of stoppages a year and you have an availability number that is technically based on real data but does not reflect what actually happened on the floor.
Plants that have moved to automatic data capture, where the machine itself reports its state and the operator only adds context to events the system has already detected, see two changes in their OEE numbers. The first is a drop. Reported availability usually falls by 5 to 12 percentage points in the first month, because the system is now catching micro stoppages that were getting lost in manual logging. The second change is more useful. Now the operator’s job is to explain the stoppages, not to remember them, and the explanations get better because the system tells them exactly when and how long each event was. That is the input quality you need before any kind of analytics on top of OEE will produce trustworthy insights.
What an accurate OEE calculation looks like, side by side with an inflated one
This table is from a real engagement, with the customer name removed. Both columns describe the same shift on the same line. The left column is what the plant was reporting before we worked with them. The right column is what the actual data showed once changeovers were properly classified, ideal cycle time was set against a current engineering standard, rework was excluded from good count, and downtime was captured automatically rather than logged manually.
| Input | Inflated number (before) | Accurate number (after) |
|---|---|---|
| Availability | 92% (changeover overruns classified as planned) | 81% (only true plant-wide planned time excluded) |
| Performance | 94% (real-world good-day speed used as ideal) | 87% (engineering standard speed used as ideal) |
| Quality | 99% (rework counted as good) | 96% (rework excluded from good count) |
| Reported OEE | 86% | 68% |
The 18-point gap between 86% and 68% is the gap between what the plant thought it was running and what it was actually running. Until they closed it, every conversation about improvement was happening on top of the wrong number, and the highest-leverage interventions were going unrecognized. After the gap was closed, the plant moved their real OEE from 68% to 79% in seven months, because they could see for the first time where the losses actually were.
What this means for your plant
If you have an OEE number you are tracking today, the most useful thing you can do this week is not to try to improve it. It is to audit how it is being calculated. Walk through the five mistakes above. For each one, ask the operations team how that input is being defined and captured. If the answers feel uncertain, that is the gap. Once the inputs are honest, the path to improvement gets much shorter. You see what is actually happening, the team trusts the number enough to act on it, and the decisions you make on top of the data start producing the results the data was promising.
You see what is actually happening, the team trusts the number enough to act on it, and the decisions you make on top of the data start producing the results the data was promising. OmniOEE was built around this. The system captures availability, performance, and quality data automatically from the machines themselves, applies consistent definitions across lines and sites, and shows the operations team what is happening in time to do something about it.
If you are not sure whether your current OEE numbers reflect reality, we are happy to help you find out. Talk to our team and we will walk through your current setup together.
