ERP-MES integration is the two-way link between the business system that plans work and the execution system that runs it. Orders, schedules, and recipes flow down from the ERP to the MES; production actuals, consumption, and status flow back up. Done right, neither system asks a human to re-key what the other already knows.
The reason this matters: the ERP and MES answer different questions on different clocks, and the gap between them is where most plants lose data quality. When the link is manual, operators typing shift totals into the ERP hours late, the business's picture of the floor is both a burden to maintain and wrong. Integration is how you close that gap.
Why do ERP and MES need to talk at all?
Because they own different halves of the same job. The ERP is the business system of record: orders, inventory, purchasing, finance, and high-level planning on a horizon of days and weeks. The MES is the execution system: it takes released orders and runs them on the floor, tracking material, labor, machines, quality, and genealogy on a horizon of minutes. One plans; the other does. Neither is complete without the other.
Left disconnected, they become two of the most expensive data silos in the plant. The ERP schedules against inventory it thinks it has; the MES consumes material the ERP never hears about; the numbers drift apart until someone spends a shift reconciling them. Integration replaces that reconciliation with a flow.
The cost of leaving them disconnected is easy to underestimate because it hides in labor. Someone keys shift totals into the ERP. Someone else chases down why the ERP says a job is open that the floor finished yesterday. A planner pads lead times because the ERP's inventory is never quite trusted. None of these show up as a line item called "integration gap," but together they are a standing tax on the plant, paid every shift. Integration is worth doing when that tax is bigger than the project.
What actually flows down, and what flows up?
The exchange is directional and specific. Understanding exactly what crosses the boundary is most of the design work.
Down from ERP to MES: released production orders, the schedule, bills of material and recipes, item and customer master data, and sometimes quality specifications. This tells the floor what to make, in what order, from what.
Up from MES to ERP: production counts and completions, material consumption, labor and machine time, scrap and yield, quality results, and lot genealogy. This tells the business what actually happened, so inventory, costing, and order status stay true to the floor.
Notice that the upward flow is the harder and more valuable half. Pushing an order down is a mostly one-time, low-frequency event; reporting actuals back up happens continuously and is where accuracy is won or lost. It is also where manual re-entry most often lives, because the floor's reality is messy, partial completions, reworks, unplanned scrap, and someone has to translate that mess into clean transactions the ERP will accept. The quality of your ERP-MES integration is really the quality of that upward path.
What is ISA-95, and where does B2MML fit?
You do not have to invent this exchange from scratch. ISA-95 published internationally as IEC 62264, is the standard for integrating enterprise and control systems. It defines a common vocabulary and data models for exactly the ERP-to-MES conversation: what an order is, what a material definition is, what a production response looks like. Most of what ISA-95 standardizes is the boundary between Level 4 (ERP) and Level 3 (MES).
B2MML (Business To Manufacturing Markup Language) is the practical, machine-readable form of that standard: a set of XML schemas that implement the ISA-95 data models. It is maintained by MESA International and is free to use provided you credit MESA. In plain terms, ISA-95 is the shared vocabulary and B2MML is the file format that speaks it, so a scheduling response from one system means the same thing to another without a custom translation for every pair. Modern integrations often pair B2MML for the ERP-MES data model with OPC UA for real-time OT connectivity underneath.
The value of leaning on the standard is not academic tidiness; it is what happens later. When you eventually swap an MES vendor, add a second plant, or bring on a new line, an interface built on ISA-95 concepts is far more likely to be reusable than one where "order" and "completion" mean whatever a contractor decided five years ago. You are buying portability. That said, the standard is a starting point, not a shrink-wrap: real integrations still have to map your specific item numbers, units, and workflow states into the ISA-95 shapes, and that mapping is where the careful work lives.
How do you connect them? Common integration patterns
There is no single right architecture, but there are recognizable patterns with known trade-offs.
| Pattern | How it works | Watch out for |
|---|---|---|
| Point-to-point | Direct custom link between the two systems | Simple for one pair; sprawls into spaghetti as systems multiply |
| Middleware / integration bus | A hub both systems connect to | Cleaner at scale; the hub becomes critical infrastructure |
| Standard schema (B2MML) | Both sides exchange ISA-95-shaped messages | Portable and vendor-neutral; requires discipline to map correctly |
| Operational layer | A real-time layer connects ERP, MES, machines, and paper | Reduces integration sprawl; only as good as the sources it reads |
The API integration details matter, but the architectural choice matters more: every place two systems hand off is a place silos and re-entry creep back in, so fewer, cleaner seams beat many custom ones.
Where does ERP-MES integration go wrong? A five-point checklist
The failures are predictable, which means they are avoidable. Almost every ERP-MES integration that goes sideways traces back to one of these five, and none of them is a coding problem, they are decisions you can make before a single message is exchanged. Work through them before you build.
- Undefined boundary. Decide up front what the ERP owns and what the MES owns. Ambiguity here creates duplicate data entry forever, the exact problem integration was meant to kill.
- Timing and sync mismatches. The ERP thinks in batches and nightly runs; the floor moves in minutes. If actuals post too slowly, the ERP schedules against a floor that no longer exists. Define how fresh each direction must be.
- Master-data drift. If item numbers, units of measure, or BOMs differ between systems, the integration faithfully passes garbage. Reconcile master data before you connect, then govern it.
- No error handling. Messages fail. Without a queue, retries, and an alert when something is stuck, a silent integration failure looks exactly like a quiet plant, until inventory is wrong by a week.
- Ownership after go-live. Every routing change, new product, or ERP upgrade touches the interface. Name who maintains it, or it freezes your process the day it ships.
By the numbers
The good news is that the hard part is standardized. ISA-95 is an internationally adopted standard (ANSI/ISA-95 and IEC 62264) precisely because the ERP-MES boundary is common to nearly every manufacturer (ISA). Its XML implementation, B2MML, is maintained by MESA International and is available royalty-free with attribution, so you are not inventing a data model or paying a license to exchange an order (MESA International). The engineering effort in a modern integration is less about the format and more about the discipline: clean master data, a defined boundary, and honest error handling.
How does a real-time operational layer change the picture?
Classic ERP-MES integration connects two systems. But a plant is not two systems, it is an ERP, an MES, a QMS, a stack of PLCs, and a pile of paperwork, and integrating each pair produces the spaghetti in the table above. A real-time operational layer flips the model: instead of N systems wired to each other, each connects once to a shared layer that reads and reconciles across all of them. Orders still flow down, actuals still flow up, but the floor's reality lands in one place and propagates without operators re-keying it into three screens. The math is the reason: point-to-point links grow roughly with the square of the number of systems, while a shared layer grows linearly. That difference is invisible with two systems and crushing with seven.
That is where Harmony fits. It does not replace your ERP or your MES; it connects to them, and to the machines and the paper, as one real-time layer, so the actuals your ERP needs arrive accurately and on time instead of being typed in late. It is the same foundation described in smart factory technology applied to the specific problem of making your business and execution layers agree. See how CLS connected its floor to its systems without a rip-and-replace.