Integrating MES and ERP for a unified data backbone

2. MES executes it

MES takes over on the floor. It splits the order into operations (machining, deburring, assembly, test), dispatches each to a work center, and tracks progress. Operators scan in. Machines report counts. Quality logs pass/fail.

This is where reality intrudes. A tool breaks. A batch of raw stock is out of spec. The order that ERP scheduled as a clean four-day run becomes 4,650 good parts, 350 scrap, and six hours of unplanned downtime.

3. MES sends actuals back

When operations complete, MES reports actuals back to ERP: quantities produced, scrap, labor hours, material consumed, completion time. This is called a confirmation or goods receipt in ERP terms.

ERP uses these actuals to relieve inventory, post costs, update the financials, and tell the planner the order is done.

That round trip (ERP down, MES up) is the unified data backbone working as intended. Now let's look at why it breaks.

Where it breaks: master-data mismatch

Master data is the shared reference data both systems depend on: material numbers, units of measure, bill of materials (BOM), work centers, routings. When ERP and MES hold different versions, integration fails quietly.

Common mismatches:

Unit of measure conflicts. ERP tracks a coating in liters. MES meters it in kilograms. Without a conversion factor maintained in both systems, consumption postings are wrong and inventory drifts.

Material number granularity. ERP has one part number for a caliper. MES tracks three sub-variants by cavity or line. The mapping has to exist somewhere, or actuals cannot post back cleanly.

Work center definitions. ERP models a "machining department" as one capacity bucket. MES tracks eight individual CNC machines. Scheduling in ERP looks feasible while a specific bottleneck machine is overbooked.

Routing drift. An engineer updates the routing in MES to add an inspection step but never syncs it to ERP. Standard costs and cycle-time estimates in ERP are now stale.

The fix is governance, not more software. One system must own each master-data element, and changes must propagate. Most mature plants make ERP the master for material and BOM data, and MES the master for detailed execution parameters. What matters is that the ownership is explicit and enforced.

Where it breaks: latency

The second failure mode is timing.

MES data is real-time or near real-time. It updates every few seconds. ERP typically posts in batches, sometimes hourly, sometimes only at shift end or overnight.

That gap creates a decision trap. A planner looking at ERP at 2 PM sees an order 40 percent complete because that was the last confirmation. On the floor, MES shows it is actually 70 percent done and running ahead. The planner reschedules based on stale data and disrupts a line that was fine.

Latency also distorts analytics. If you calculate OEE (Overall Equipment Effectiveness, a standard metric combining availability, performance, and quality) from a mix of real-time MES counts and delayed ERP order status, your numbers will not reconcile. Analysts spend more time explaining why two dashboards disagree than acting on either.

There is no universal right latency. High-mix, fast-cycle plants push toward event-driven, real-time confirmation. Slower process plants may accept shift-level batches. Decide deliberately, and make the latency visible on every dashboard so no one mistakes a snapshot for live truth.

The integration layer

Point-to-point connections (ERP wired directly to MES) work until you have three systems, then five, then a warehouse system and a quality system too. Then the wiring becomes unmanageable.

The reference model most manufacturers use is the ISA-95 standard, which defines the layers between enterprise systems (ERP) and control systems (the plant floor), and a common vocabulary for the data that moves between them. You do not need to memorize it, but knowing it exists helps you ask vendors the right questions.

In practice, integration runs through middleware: a message broker or integration platform that translates and routes data. A modern pattern is event-driven messaging, where MES publishes an event the moment something happens, and any subscribed system reacts.

A simplified confirmation event, the message MES sends when an operation completes, might look like this:

Clean, structured, timestamped, with an explicit unit of measure. ERP consumes it and posts the confirmation. This is the atomic unit of the round trip. Get this message right and most integration problems shrink.

🎬 [VIDEO: "MES and ERP Integration Explained" — youtube.com — a clear walkthrough of how execution and planning systems exchange data on the shop floor]

Why this powers analytics

When the backbone is clean, you can answer questions that neither system answers alone.

Cost per good unit, by machine. ERP holds cost. MES holds which machine made which units and the scrap. Joined, you see that CNC-07 quietly runs 3 percent more scrap than the others, which no financial report would surface on its own.

Schedule adherence versus actual constraints. Compare ERP's planned finish to MES completion timestamps across hundreds of orders. Patterns emerge: a specific product family always slips because a shared fixture is the real bottleneck.

Genealogy and traceability. In regulated sectors (medical devices, aerospace, food), you must trace which raw material lot went into which finished unit. That thread runs through MES, but recalls and customer records live in ERP. Only an integrated backbone lets you trace a defect from a customer complaint back to a supplier lot.

None of this works if material numbers do not match or if the actuals arrive a shift late.

Getting the sequence right

A common mistake is buying an analytics platform before fixing the backbone. The dashboard is only as trustworthy as the data feeding it.

A workable order of operations:

1. Reconcile master data first. Agree who owns each element. Clean up units, materials, work centers, routings. This is unglamorous and it is where most of the value comes from.

2. Define the events and their latency. Which shop-floor events post back, how fast, and in what format. Make the confirmation message a contract.

3. Route through middleware, not point-to-point. Use ISA-95 vocabulary so future systems plug in cleanly.

4. Then build analytics on the reconciled, timestamped data.

Skip step one and you build sophisticated analytics on a foundation that lies to you.

Key Takeaways

• A production order lives in ERP (plan and cost) and MES (execution and actuals). The unified backbone is the round trip: ERP releases the order down, MES sends actuals back up.
• Master-data mismatches (units of measure, material granularity, work center definitions, routing drift) break integration quietly. Fix them with explicit ownership and governance, not more software.
• Latency matters: MES is real-time, ERP is often batch. Decide the confirmation cadence deliberately and label every dashboard so no one mistakes a snapshot for live truth.
• Use middleware and the ISA-95 reference model instead of point-to-point wiring, and treat the confirmation event as a strict data contract.
• Reconcile the backbone before building analytics. Cost per good unit by machine, true bottleneck analysis, and full traceability are only possible when both systems agree on the same clean data.