Field guide / Data architecture

ERP vs. MES: which status should your team trust?

It depends on the field. Define authority for the customer promise, order record, and execution events, then compare their timestamps.

Assign authority to fields rather than whole systems

A business order and an operation event describe different parts of a job. The customer promise can remain unchanged while an operation is held. Begin by asking the responsible people where each field is maintained, what it means, and how it is corrected. Treat the matrix below as a worksheet to adapt to your deployment.

An ERP may own due dates and order quantities while MES records carry execution events. Custom modules and manual processes can change that arrangement. Confirm the mapping with the planner and system owners. Where two records cover the same field, define precedence and the circumstances that require confirmation instead of automatically selecting whichever arrived last.

FieldCandidate authority to confirmValidation question
Customer due dateBusiness order recordDoes this reflect the approved promise?
Released quantityProduction orderHow are splits and revisions handled?
Operation completionExecution recordPartial, accepted, or final completion?
Machine stateMachine or execution eventIs it attributable to this job?

Illustrative sample: two accurate but different states

In a fictional review, WO-9055 is released in the ERP as of 07:00 shop time. A MES event records a quality hold on operation 40 at 08:10. Neither value needs to be erased. A useful answer says that the business order is open and the execution operation has a recorded quality hold.

The supervisor or quality owner confirms the hold’s current disposition. The planner considers its effect on the due date. If the ERP also carries an operation-complete flag from the previous day, inspect whether it refers to the same operation, quantity, and revision. A later timestamp cannot resolve a mismatch caused by different identifiers or meanings.

Use source time and retrieval time together

Event time describes when production activity occurred. Source update time describes when a record changed, if the system exposes it. Retrieval time describes when your view last read that source. Preserve these differences and define timezone handling before comparing events across systems or shifts.

A recently retrieved export can contain old production information. A delayed event can be valid even though it arrived after newer records. Set freshness rules for the decision and show the source that breached them. When a feed fails, keep the last known state with its age and ask the appropriate owner to confirm it.

Resolve disagreements with the people who own the records

Before building a combined view, ask how partial completion, rework, scrap, cancellations, and reopened operations are represented. Confirm which keys join the order to its operations, what identifies a corrected event, and whether there is a permitted way to trace the answer back to its source record.

Write down the rule for each unresolved state and the role that confirms it. Test the rules on jobs the team knows well, including a held job and a completed job with late postings. An architecture review should validate permissions and field meaning together. SPOF’s ERP/MES page explains the proposed mapping and approval boundaries for a scoped workflow.

Start with one operational question.

Tell us what your team keeps looking up. We will talk through the workflow and the systems behind it.

Book a 15-minute call