An OEE number that never matches the shop floor, alerts nobody reacts to anymore, endless debates over "which number is right" in the production meeting : these are the signs of a KPI system that's gone off track. This isn't a guide for setting up an OEE system from scratch — that ground is already covered in our pre-deployment data readiness audit. This guide is for a system that was working fine and has since started drifting : how to find the exact cause of the drift, and fix it without introducing a new set of problems.
TL;DR:
An OEE mismatch between system and shop floor almost always comes down to three causes : unsynchronized timestamps, incorrect order mapping, or planned stops that aren't properly excluded.
Never fix a KPI by loosening its alert thresholds : find and correct the source, then validate on one pilot machine before rolling out.
A reproducible 24-hour audit (system vs. manual log side by side) is enough to locate most sources of drift.
Before diving into the technical diagnosis, here are the symptoms worth watching for :
If you recognize 2 or more of these signs, the problem probably isn't your shop floor — it's your measurement system.
Want to see live where your production data starts to diverge? JITbase captures machine events automatically and removes the errors that come from manual logging.
See production monitoringThe most common cause of a gap between system OEE and shop-floor OEE is technical, not organizational : unsynchronized clocks between machines, controllers and the SaaS server, or an incorrect order mapping (a work-order ID attached to the wrong machine or the wrong station).
Checklist:
A clock drift of just a few minutes can be enough to shift events into the wrong shift and distort KPIs calculated by time window. If the root cause traces back to how shop-floor data is passed to your ERP, our guide on integrating shop-floor data with ERP covers how to make that flow reliable upstream.
Second common cause : multiple sources reporting the same event (for example, a PLC and an additional sensor both counting the same cycle), which artificially inflates part count or run time. Conversely, planned stops (scheduled tool change, preventive maintenance) that are misclassified end up penalizing OEE even though they shouldn't count against availability at all.
To diagnose:
OEE calculated differently from one department to another — different exclusion rules for stops, production counts that include parts still in inspection — makes the numbers impossible to compare from one shop to another, or from one review to the next. It's rarely a bug : it's a definition that was never formalized and documented in a single, shared reference.
Another common trap : too many KPIs tracked at once drown out the useful signal. A team receiving 15 alerts a day eventually ignores all of them, including the ones that matter.
The fix : standardize every KPI definition in a single reference document, with exact formula, unit and time window, and limit active alerts to the 3 to 5 indicators that genuinely trigger action.
Need to reconcile OEE calculations across machines or sites? We can look at where the gap sits and how to fix it for good.
See machine monitoringOnce you've found the cause, the temptation is to "fix" the number instead of the data. Three rules to follow :
This approach avoids the most common side effect : a quick fix that repairs the KPI on one machine but breaks it somewhere else in the shop.
Here's the procedure to follow as soon as a mismatch is reported :
This reproducible checklist handles most mismatches in a single audit session, without tying up your entire methods team for days.
Sometimes the data is perfectly reliable and the KPI is still useless : nobody looks at it in meetings, no routine relies on it to decide anything. In that case, the technical diagnosis isn't enough — you need to revisit the visual management routine around the KPI (review frequency, a designated owner, a direct link between the indicator and a concrete decision). Our guide on visual management for CNC shops covers how to structure that routine around a dashboard people actually use.
A reliable OEE number that drives no action is just a decorative figure. We can help you assess the real impact of a corrected KPI system on your productivity.
Calculate your ROIA drifting KPI system is rarely fixed by switching software or adding more indicators. Most drift comes down to three specific causes — timestamps, mapping, ambiguous definitions — identifiable with a 24-hour audit. The most important discipline isn't technical : it's fixing the source rather than the number, and validating every fix on one pilot machine before rolling it out to the whole shop. Once your data is clean, you can build on solid ground to actually improve your OEE.
Check timestamps and order mapping first : unsynchronized clocks or a mismapped order ID cause most of the gaps you'll see. Then check whether planned stops are properly excluded from the calculation, and whether multiple sources are double-counting the same events.
A parallel 24-hour audit, system vs. manual log, will show you the exact pattern and let you fix the mapping or exclusion rule at fault.
No. Loosening a threshold to silence an alert hides the problem instead of solving it. Find the source of the drift — timestamps, mapping, an ambiguous definition — and fix it directly, documenting any change to historical data.
Test every fix on a single pilot machine for a defined period, for example one week, comparing the result against the manual log before rolling it out. This keeps a fix designed for one machine from throwing off the calculation elsewhere in the shop.
No, it's a management routine problem. If a reliable indicator drives no action, the technical diagnosis isn't enough : you need to revisit the review frequency, assign an owner to the KPI, and explicitly connect each indicator to a concrete operational decision.