Where definition stops and execution begins
The PLM–MES boundary is easier to draw than the PLM–ERP one and gets blurred more often, because both systems talk about parts, processes and quality using the same words for different things.
The line, and why it sits where it does
Manufacturing PLM defines what should be built. Your MES records what was. Everything else follows from that sentence, including the cases that feel ambiguous.
An inspection plan is definition: these characteristics, these acceptance criteria, this sampling. An inspection result is execution: this operator measured this characteristic on this unit at this station and got this number. The plan is revision-controlled and changes through change control; the result is a transaction that happened.
A work instruction is definition, generated from the MBOM and revision-controlled. A record that an operator completed step four on unit 1420 is execution. Same for routings versus run logs, tooling definitions versus cycle counts, and lot definitions versus lot genealogy.
The test for an ambiguous case is whether the thing can be *revised*. A definition has revisions and a change process; an execution record has a timestamp and cannot be revised without becoming a different kind of claim entirely.
What flows back, and what it is for
Three kinds of data cross from execution into definition, and each answers a question the definition side cannot.
- Inspection evidence, attached to quality records. A CAPA cannot close without verification evidence, and that evidence is frequently a measurement set from the line rather than anything produced in engineering.
- As-built configuration, per serialised unit. What was actually consumed, including approved substitutions made on the floor — which is the difference between what a unit was specified to contain and what it contains.
- Lot and batch genealogy, which is what makes recall scoping possible. A nonconformance traced to a lot needs to reach the units that lot went into, and that path exists only where execution recorded it.
The failure it prevents
A customer reports a failure on a unit built fourteen months ago. Engineering resolves the structure as at that build date and produces what the unit was specified to contain — which is the right answer to a question nobody asked.
The unit actually contains an approved alternate connector, substituted on the line during a shortage, recorded in the MES and nowhere else. The investigation runs for two weeks against the wrong component before somebody thinks to check the build record.
Specified and built are different facts, and a PLM that presents the first as though it were the second is worse than one that admits the gap. The seam exists so that the resolved structure and the as-built record are both available and visibly distinct.
How it meets the rest of the product
The MBOM is what the MES consumes, which is why MBOM ownership is the contested row in the system-of-record matrix. Where manufacturing owns it in the ERP, the MES reads it from there and Manufacturing PLM stops at the EBOM; where it lives here, it publishes outward like any other structure.
Work instructions are generated from the MBOM rather than maintained beside it, so an instruction referencing a part that has since revised is flagged rather than quietly describing a component nobody stocks. The MES displays them; Manufacturing PLM controls their revisions.
Quality records accept execution evidence as attachments with their own provenance, so a verification result carries where it came from and when — which matters because a CAPA closed on evidence nobody can trace is a CAPA that will be reopened.
Serialised as-built configuration consumes the same flow. A unit's actual content is assembled from what execution recorded against what Manufacturing PLM specified, and the two are presented as distinct rather than merged — because merging them produces a record that looks authoritative and cannot be traced to either source.
How it meets your ERP
In most deployments the ERP sits between Manufacturing PLM and the MES rather than beside it. Manufacturing PLM publishes the released structure to the ERP; the ERP creates the work order; the MES executes against it. Manufacturing PLM does not talk to the MES directly in that arrangement and does not need to.
Where a direct seam exists it is usually for evidence flowing back — inspection results and as-built records that the ERP has no place for. That is a read into Manufacturing PLM rather than a write out of it, and it goes through the API or the connector SDK like any other integration.
Nothing about this seam is transactional in either direction. Manufacturing PLM does not create work orders, issue material, book labour or record completions, and it does not accept instructions to do so.
Where the boundary is
There is no built-in MES connector, and the seam is described here rather than shipped. Where a direct integration is needed it is built on the API and the connector SDK, which have the lifecycle and reconciliation semantics that work requires.
Manufacturing PLM also does not hold execution data as a system of record. As-built configuration and lot genealogy are consumed as evidence and referenced; the authoritative copy stays where it was produced, because a second copy of transaction data is a second copy nobody maintains.
Facts
| The line | Manufacturing PLM defines what should be built; the MES records what was |
| The test | Can it be revised? Definitions can; execution records cannot |
| Definition | Inspection plans · work instructions · routings · tooling |
| Execution | Results · completions · cycle counts · lot genealogy |
| Flows back | Inspection evidence · as-built · lot genealogy |
| Usual topology | Manufacturing PLM → ERP → work order → MES |
| Transactional | Nothing, in either direction |
| Not offered | A built-in MES connector · execution data as record |
Frequently asked
Where exactly does the boundary sit?
At execution. An inspection plan is definition — characteristics, acceptance criteria, sampling — and revision-controlled. An inspection result is execution: this operator measured this characteristic on this unit and got this number. The test is whether the thing can be revised.
Do you have an MES connector?
No. The seam is described rather than shipped, and where a direct integration is needed it is built on the API and connector SDK — which carry the lifecycle, retry and reconciliation semantics that any integration handling evidence flowing back actually requires.
Why does as-built matter if we have the BOM?
Because specified and built are different facts. A unit containing an approved alternate substituted on the line during a shortage was specified one way and built another, and a PLM presenting the first as though it were the second is worse than one admitting the gap.
Who owns the MBOM in this picture?
It is decided per tenant, and it is the contested row in the system-of-record matrix. Where manufacturing owns it in your ERP, the MES reads it from there and Manufacturing PLM stops at the EBOM. Where it lives here, it publishes outward like any other structure.
How do work instructions reach the line?
They are generated from the MBOM and revision-controlled here, then displayed by the MES. Generating rather than maintaining them beside the structure is what stops an instruction quietly describing a component that has since revised and is no longer stocked anywhere at all.
Does Manufacturing PLM create work orders?
No, and nothing about this seam is transactional in either direction. It does not create work orders, issue material, book labour or record completions, and it does not accept instructions to do any of those. That work belongs where the transactions already live.
Do you store lot genealogy?
It is consumed as evidence and referenced rather than held as a system of record. The authoritative copy stays where it was produced, because a second copy of transaction data is a second copy nobody maintains and the two diverge the first time either is corrected.