MES and ERP: drawing the line between planning and execution

Settle ownership per object before anyone writes an interface

Work through the list explicitly: items, product structures, routings, work orders, inventory balances, labour, scrap, batch identity, equipment. For each one, name the system that may create it, the system that may change it, and the direction data flows. Ambiguity here is what produces the classic argument in which planning has closed an order that execution still shows as running. Writing the answers into a short ownership document, agreed by both sets of users rather than by the integration developer alone, does more to prevent later disputes than any amount of technical design work.

Order release and the granularity mismatch

Planning issues an order for a quantity to be made by a date. The floor frequently splits it across machines, runs part of it on a different shift, combines it with another order to save a setup, or starts a portion while the rest waits for material. If the execution system models those splits and planning does not, confirmations return in shapes the planning system cannot accept, and somebody starts adjusting quantities manually. Deciding in advance whether splits are visible upstream, and how partial completion is reported, avoids a reconciliation task that otherwise consumes a planner every afternoon.

Confirmations, consumption and the intraday gap

During a shift the two systems will diverge, because execution knows material has been consumed and product built while planning has not yet received the transaction. That gap is acceptable if everyone understands it and unacceptable if a buyer is making a purchasing decision from a balance that is hours stale. Deciding the frequency of transfer is therefore an operational choice rather than a technical one, and it differs by data type: consumption of expensive material may warrant immediate posting while labour can wait until end of shift. Where consumption is derived from output rather than reported directly, the accuracy of the structure becomes the accuracy of your stock.

Interfaces fail quietly, so design for the failure

The dangerous outcome is not an interface that stops, which somebody notices, but one that rejects a small proportion of messages into a queue nobody watches. Weeks later the plant discovers a set of orders never confirmed and stock that has been wrong since. Every integration needs a named owner for its error queue, an alert when a message fails rather than a log entry, a defined action for a rejected transaction, and a way to reprocess without creating duplicates. Testing should include deliberately breaking the link and confirming both that nothing is lost and that somebody is told.

Reconciliation is an operating routine, not a project task

Even a well-built interface needs a periodic comparison: open orders in one system against the other, inventory balances at defined points, quantities confirmed against quantities received. Running that comparison automatically and reviewing the exceptions is a standing task belonging to someone in operations or finance, not a check performed once during commissioning. Plants that establish it early catch small drifts while the cause is still traceable. Plants that do not usually discover the accumulated discrepancy at a stock count, when reconstructing what happened is no longer possible and the write-off is the only available answer.

Frequently asked questions

Should the execution system hold stock, or only the planning system?

The common arrangement gives planning the authoritative balance and lets execution track material within the production area between the point of issue and the point of receipt. That keeps one place for financial inventory while allowing the floor to know what is at each station. Problems appear when both maintain balances for the same locations with independent adjustments, since two sets of corrections will not agree and neither can be shown to be right at a count.

How real-time does the connection need to be?

Different data types deserve different answers. Order release and status generally benefit from being prompt, since a supervisor working from stale priorities makes poor sequencing choices. Financial postings can be batched without harm. Material consumption sits between, depending on whether anyone makes purchasing or promise decisions from the balance during the day. Specifying a required latency per interface, rather than defaulting everything to immediate, keeps the integration simpler and cheaper to operate.

Can one system do both jobs?

Some planning suites include execution capability and some execution products carry planning features, and for a single plant with straightforward processes that can be entirely sufficient. The trade-off is depth: combined products are typically stronger on one side than the other, and the weaker side is where you will feel the constraint. The evaluation question is which capability your plant genuinely depends on, and whether the combined offering handles that side well enough to justify avoiding an interface.