What shop floor data collection has to reconcile
OEE looks like one percentage. It is assembled from measurements that several systems define independently.
- Planned production time: the shift calendar, which the ERP holds and the machine does not know about
- Downtime and its reason: the machine records that it stopped, and only an operator or the manufacturing execution system (MES) knows whether that was a breakdown, a changeover, or a break
- Ideal cycle time: the rate the part should run at, usually held in the routing in the ERP rather than at the machine
- Good count versus total count: the machine counts cycles, and quality decides which of those were sellable
- The order the output belongs to: which work order was running at the time, which the machine has no reason to know
Only one of those five originates at the machine. The rest come from business systems, which is why a collection project that stops at the machine produces a number nobody can defend.
Why does shop floor data collection produce two OEE figures?
Definitions diverge before anything else does. If planned production time excludes scheduled maintenance in one system and includes it in the other, availability differs by several points without either system being wrong. The same applies to whether a five-minute stop counts as downtime or as a micro-stop absorbed into performance.
Timing widens the gap further. Machine data arrives continuously while ERP postings arrive when somebody confirms a production order, often at the end of a shift. Comparing a live figure to a confirmed one measures the reporting lag as much as the performance. That lag is the problem real-time production monitoring sets out to solve on the architecture side.
Attribution is the quietest of the three and the most expensive. Output recorded against the wrong work order still totals correctly at plant level while misstating the cost of every job it touched. That is what makes plant-level numbers look reasonable while job costing stays unreliable.
None of those three is a sensor problem, which is why buying more of them does not help.
Where a discounted OEE figure costs money
The dashboard does not fail loudly. It gets quietly discounted, and the costs accumulate behind that.
- Meetings that argue about the number: time spent debating whose figure is right rather than what to do about it
- Improvement work aimed at the wrong loss: if changeovers are miscategorized as breakdowns, the maintenance budget gets spent where the setup process was the problem
- Job costing that cannot be trusted: output attributed to the wrong order distorts the margin on both
- Capacity planning on inflated rates: planning against a theoretical cycle time nobody has achieved produces promises the plant cannot keep
- Investment cases that stall: a machine replacement justified on OEE evidence stops moving when finance cannot verify the baseline
The instinct when the number looks wrong is to collect more of it.
Why shop floor data collection has to run both ways
Collecting more from the floor means more sensors, finer granularity, shorter intervals. That improves the resolution of the half already working and leaves the disagreement exactly where it was.
The other half is context. A stop event becomes downtime with a reason only when somebody or something classifies it. A cycle count becomes good count only after quality has passed it. A production quantity becomes meaningful only when tied to the work order it belonged to.
So the real requirement runs in both directions. The work order, routing, and shift calendar have to reach the floor so machine data can be tagged as it is produced. The tagged result then has to return to the ERP as confirmation. A project that only moves data upward will always produce a number that has to be argued about.
Closing that loop is attempted in three ways, and each one falls short differently. A machine monitoring platform visualizes OEE well and generally holds its own definitions rather than the ERP's. An MES sits properly between the floor and the business systems and is a substantial implementation, which is why many plants defer it. Manual entry into the ERP at shift end is what most plants still do, and it produces exactly the lag that makes reconciliation impossible.
How does an integration platform make shop floor data reconcile?
An integration platform-as-a-service (iPaaS) connects the machine layer to the systems holding the definitions, which are the ERP for the calendar and the routing, and quality for the good count. Both directions run through the same layer, so context reaches the floor and confirmations return.
Direction is what makes this more than a feed. Sending the active work order down to the machine means output is tagged at the moment it happens rather than reconstructed at shift end. Mapping machine states onto the ERP's own downtime categories means availability rests on the same definition on both sides. Carrying data one way only is what produces two numbers.
Alumio is an integration platform built to run in both directions, carrying context down and confirmations back. The Alumio integration platform handles that in four ways.
- Context sent down to the floor: an event-driven data Route within Alumio pushes the active work order, routing, and shift calendar to the machine layer, so output is tagged as it happens rather than reconstructed afterwards
- One definition applied to both sides: a data Transformer maps machine states onto the same downtime categories the ERP uses, so availability means the same thing in both systems
- Confirmations returned continuously: a data Route carries produced and scrapped quantities into the ERP against the correct order as they occur, which removes the end-of-shift lag
- Every value traceable to its source: detailed Logs record which reading produced which figure, so a disputed number is a lookup rather than a meeting
Configuration handles the state mapping and the return flows, with the Alumio Code Transformer enabling developers to code where they prefer it to configuration. A second line comes online against mappings that already exist, which is what turns machine data reaching enterprise systems into a figure rather than a feed.
What reconciled shop floor data collection changes
The measure of a collection program is not how many machines report. It is whether the plant manager and the finance director open the same number and neither disputes it.
Three roles hold different halves of that. The plant manager owns the OEE figure and the improvement plan built on it. The production planner schedules against cycle times the routing claims rather than ones the line has demonstrated. The finance controller has to cost each job from output that may have been attributed to the wrong order.
Reaching one number changes what the data is for. OEE stops being a factory metric shown in factory meetings and becomes an input to costing, capacity planning, and investment cases. An integration platform running in both directions is what produces that single figure, because both sides end up calculating it from the same definitions. That is a different thing from a better dashboard.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
