In most manufacturing businesses of this period there were two versions of production reality, and they did not match. One lived in ERP: planned orders, standard routings, standard costs, and completion confirmations entered in batches by a supervisor at the end of a shift or the end of a week. The other lived on the shop floor: actual machine states, actual cycle times, actual scrap, actual downtime, and the informal adjustments operators made to keep output moving. Finance closed the month using the first version. Operations ran the plant using the second. The gap between them was called variance, and explaining it consumed a substantial part of every month-end. Manufacturing execution systems were the attempt to close that gap by connecting the plant floor to the planning layer — and the integration between MES and ERP became one of the defining enterprise architecture problems of the decade.
Why the Data Diverged
ERP was designed around transactions and periods. It knows that a works order was released, that materials were issued, and that a quantity was reported complete. It does not know that the line stopped for forty minutes because a fixture failed, that the operator ran the second shift at reduced speed to avoid scrap, or that the first eleven units were reworked before anyone recorded a good part. MES sat at the layer where those events actually occur — collecting machine signals, operator inputs, quality checks and material movements in something close to real time. That gave it the data ERP lacked, and created the obvious question: which system owns what? The answer that emerged, and that still holds, is a layered division of responsibility. ERP owns the commercial and financial view: demand, planning, costing, procurement, inventory valuation. MES owns execution: scheduling to the machine, dispatch, data collection, quality, genealogy and traceability. The interface between them carries order release downward and confirmation, consumption and quality results upward. Getting that boundary wrong is the root of most failed implementations. Organizations that tried to schedule the shop floor in ERP found the model too coarse to be usable. Organizations that tried to run costing in MES found themselves maintaining a second, diverging financial system.
What Changed When It Worked
The first visible benefit was not cost. It was time. Before integration, a production figure was a monthly artefact assembled after the fact. After it, the same figure was available continuously, which changed what management could actually do. A yield problem discovered on day three of a production run can be corrected. The same problem discovered at month-end is a post-mortem. The second benefit was accuracy of standards. Standard costs and routings in ERP were frequently based on engineering estimates that had drifted years out of date. Real cycle time data exposed the difference, and correcting it changed product profitability analysis materially — sometimes revealing that the product line everyone believed was the most profitable was not. The third was traceability. Regulated manufacturing — food, pharmaceutical, aerospace, automotive — needs to identify which batch of which input went into which finished unit. Building that record by hand is impractical at volume. MES made genealogy a by-product of normal operation rather than a separate compliance exercise.
Why the Integrations Failed
The pattern of failure was consistent enough to be predictable. Master data was not aligned. Item codes, units of measure, work centre definitions and bills of material had to mean the same thing in both systems. They usually did not, and reconciling them was the largest and most underestimated task in every project. The interface was built point-to-point and left undocumented. Two systems, a set of scheduled file transfers, and one person who understood it. When that person left or either system was upgraded, the integration became a liability. Data volume overwhelmed the design. Shop floor systems generate events continuously. Pushing every event into ERP produced performance problems and no analytical benefit. Successful designs aggregated at the boundary and kept high-frequency detail in the execution layer. Operators were treated as data entry. Where MES added keystrokes without giving anything back, data quality collapsed. Where it removed paperwork and surfaced information operators found useful, it was maintained willingly. Nobody owned the reconciliation. The two systems will disagree. Without a defined process for investigating and resolving differences, the mismatch simply becomes a new source of monthly argument.
| Direction | Purpose | Article examples |
|---|---|---|
| Planning to execution | Release work to the operating layer | Orders, item references and shared master data |
| Execution to planning | Return data needed for commercial reconciliation | Completion, consumption and quality results |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Making MES and ERP Work Together
- Fix master data before integrating. Common item codes, units, work centres and routings. Every hour spent here saves several during implementation.
- Draw the boundary explicitly and write it down. Which system is authoritative for scheduling, inventory, quality disposition and cost. Ambiguity here produces duplicate logic in both.
- Aggregate at the interface. Send ERP what it needs for planning and costing; keep event-level detail in the execution layer where it belongs.
- Design the operator experience first. If the shop floor interface is slower than the clipboard it replaces, the data will be entered late, in bulk, and inaccurately.
- Instrument what you can automatically. Machine signals are more reliable than manual confirmation. Every manual entry you can eliminate improves both accuracy and adoption.
- Define the reconciliation process. Who investigates differences between planned and actual, how often, and with what authority to correct standards.
- Version the interface. Both systems will be upgraded. A versioned, documented contract between them is the difference between a routine upgrade and an outage.
- Use the data to change decisions, not just reports. Real-time visibility has no value if the operating rhythm still waits for month-end.
Where This Leads
The MES-ERP interface turned out to be the foundation for everything that followed in industrial digitisation. Connected sensors, predictive maintenance, overall equipment effectiveness analytics and digital twins all depend on a reliable stream of execution data joined to commercial context. Organizations that built the data layer properly in this period were able to add those capabilities incrementally. Those that ran manufacturing on spreadsheets and monthly confirmations had to start at the beginning. The same dependency now governs AI in operations. Models that predict downtime, optimise scheduling or detect quality drift need dense, accurate, timestamped execution data. An organization whose production record is a weekly confirmation typed into ERP has nothing to train on and nothing to act on. The unglamorous conclusion from 2010 holds: the value is not in the reporting layer. It is in whether the event was captured accurately at the moment it happened.
Common Questions
What is the difference between MES and ERP?
ERP manages the commercial and financial view — demand, planning, procurement, costing and inventory valuation. MES manages execution on the plant floor — detailed scheduling, dispatch, data collection, quality and traceability. They exchange order releases downward and confirmations upward.
Why do MES-ERP integrations fail?
Most commonly because master data is not aligned between the systems, the interface is built point-to-point without documentation or versioning, event volume is pushed into ERP unaggregated, and no one owns reconciliation of the inevitable differences.
What is the main benefit of integrating shop floor data with ERP?
Timeliness and accuracy. Production, yield and cost data becomes available while problems can still be corrected, and standard costs and routings can be validated against real cycle times rather than aging engineering estimates.
Do you need MES to get traceability?
Not strictly, but manual genealogy records are impractical at volume. MES makes batch and component traceability a by-product of normal operation, which is why regulated manufacturers adopted it first.
Manufacturing Systems Review — Outpace maps where your production data actually comes from, aligns the master data between your shop floor and ERP, and builds an interface that survives the next upgrade of either system.