ERP and MES Integration Best Practices

Ask a plant why their ERP doesn’t reflect what’s actually happening on the floor, and the honest answer is usually a nightly batch job — production data gets exported at the end of the day, imported into the ERP overnight, and every decision made during the next shift is made against numbers that are already up to a full day old. That’s not integration. It’s a delayed mirror, and the delay is exactly long enough to make inventory counts, production order status, and cost data all slightly, silently wrong for the entire following shift.

What “Integrated” Actually Means Here

Real ERP-shop-floor integration means production events — an order starting, a batch completing, a quality hold being placed, inventory being consumed — flow into the ERP close to when they happen, not on a batch schedule measured in hours. It also means the flow runs in both directions: production planning and priority changes made in the ERP need to reach the floor promptly too, not just the reverse. A one-way integration that only pushes shop-floor data upward is solving half the problem.

The Core Data Flows Worth Getting Right

Production orders — released from the ERP to the floor, with status (started, in progress, completed, on hold) flowing back as it actually changes, not batched at shift end.

Inventory consumption — raw material and component usage recorded against the ERP in near-real-time, so procurement and planning are working from an accurate on-hand count rather than a snapshot from yesterday’s batch sync.

Quality holds and results — a quality hold placed on the floor needs to reach the ERP immediately if it affects whether finished goods can ship, not after a nightly reconciliation that might run hours after the hold was placed.

Finished goods and warehouse updates — completed production flowing into inventory and warehouse systems as it happens, so a sales order can be confirmed against stock that actually exists, not stock the ERP believes existed as of last night.

Each of these has a different urgency requirement — quality holds are typically the most time-sensitive, cost-accounting reconciliation the least — which is why a well-designed integration architecture treats them differently rather than batching everything on the same schedule for simplicity.

Middleware, Not a Rip-and-Replace

The integration layer between shop floor and ERP is middleware — API connections, message queues, or an integration platform — not a reason to replace either system. SAP, Oracle, Microsoft Dynamics, ERPNext, and custom ERPs all support this pattern through their own API layers or established integration tooling. The manufacturing platform handles the shop-floor side (connectivity, event capture, MES-level execution); the middleware translates those events into the specific transactions the ERP already knows how to process. This is a meaningfully lower-risk, lower-cost path than any project that starts by proposing to replace the ERP.

Designing for Both Directions From the Start

Even when the first phase of an integration only tackles the upward flow — production data into the ERP — the architecture should be designed to support the downward flow (orders, priorities, and material allocation reaching the floor) from the beginning, rather than bolted on as an afterthought once the upward flow is working. Retrofitting bidirectional flow onto an architecture only ever designed for one direction is a meaningfully bigger project than building it in from the start, even if the second direction isn’t implemented until a later phase.

What This Looks Like Working

In a real deployment, production orders, batch completion, finished goods, inventory, and warehouse updates all synchronised automatically between the shop floor and the ERP — replacing what had previously been a manual, end-of-shift Excel consolidation process. Full reference implementation →

Integration as Infrastructure, Not a One-Time Project

ERP-shop-floor integration done well isn’t a single data migration project — it’s ongoing infrastructure that has to keep working as production orders, product mixes, and ERP configurations change over time. SG2’s Manufacturing & Industry 4.0 practice builds this integration layer to sit alongside whatever ERP a plant already runs, prioritised by which data flows are actually time-sensitive rather than synchronising everything on the same batch schedule by default.