Where the PLM/ERP boundary actually sits

Ask which system should own product data and you will get an answer shaped by whoever is asking. Engineering says PLM. Operations says ERP. The integrator says both, carefully. None of this is useful when you are trying to decide where a specific field lives.

The useful observation is that the overlap is small. PLM and ERP disagree about three things: the BOM, the item master, and the approved vendor list. Almost everything else has an obvious home. Requirements, CAD, change processes and configuration belong to PLM. Purchase orders, inventory, scheduling, costing and finance belong to ERP. Nobody argues about those.

So the integration problem is not “how do we connect two large systems.” It is “who masters these three objects, and when.”

Mastership is the only question that matters

The principle is simple to state: for every field, exactly one system is the master, and every other system holds a read-only copy. Where two systems can both edit the same field, they will, and the copies will diverge. Not occasionally — reliably, because the two systems are used by different people under different pressures.

The difficulty is that the intuitive split — PLM owns engineering data, ERP owns business data — cuts across objects rather than along them. An item has a part number, a description and a material (engineering), and also a cost, a lead time and a stocking policy (business). Both live on the same record.

Mastership therefore has to be defined per field, not per object. That sounds bureaucratic until you have watched a programme fail for lack of it.

The three contested objects

The item master

Usually the cleanest to resolve. PLM masters identity and definition: part number, description, revision, classification, unit of measure, material, lifecycle state. ERP masters commercial and logistical attributes: cost, lead time, order policy, safety stock, planner code.

The item is created in PLM and released to ERP. ERP then extends it with fields PLM never had, and does not write back.

The common failure here is part numbering. If ERP can also create items — and it usually can, because operations needs to buy things engineering has not designed — you get two numbering authorities and eventually two records for one physical part. The fix is procedural, not technical: decide which system issues numbers for which categories of item, and enforce it.

The BOM

This is where it gets genuinely hard, and where the usual advice quietly changes the subject.

PLM masters the EBOM. That is uncontroversial. The question is who masters the MBOM, and the honest answer is that it depends on where your manufacturing engineering actually happens.

If manufacturing process planning is done in PLM, the MBOM is mastered there and released to ERP alongside the EBOM. If it is done in ERP — which is common, particularly where the ERP came first — then PLM releases the EBOM and ERP transforms it. Both work. What does not work is leaving it undecided, or letting each system hold a partially-authoritative version.

The reason this is harder than the item master is covered in more depth in why the EBOM and the MBOM drift apart: the MBOM is not a copy of the EBOM but a transformation of it, containing items with no engineering counterpart. Whoever masters it owns that extra content, and it must be somewhere it can be maintained under change.

The approved vendor list

Frequently forgotten in the design and then bolted on. The AVL links a part to the suppliers approved to supply it, which is simultaneously an engineering statement (this alternate is form-fit-function equivalent) and a commercial one (this supplier is qualified and under contract).

Split it: PLM masters technical equivalence, ERP masters commercial standing. A part can be engineering-approved and commercially unusable at the same time, and both systems need to be able to say so without overwriting the other.

Add MES and the granularity problem appears

The PLM/ERP conversation is usually two-sided, but a third system changes it. MES needs the BOM at a different level of detail again — work instructions, station allocation, operations — and MES structures are typically coarser at the top and finer at the point of assembly.

The specific failure that follows is worth naming: independent revision management. Each system can revise its own BOM. A revision released in PLM that does not propagate to MES produces a line building to a superseded definition, and nothing in either system reports an error, because each is internally consistent. Three internally consistent systems can disagree completely.

This is also where part number conflicts bite hardest. If the same physical component carries different identifiers in different systems, reconciliation depends on a mapping table, and mapping tables rot.

A rule that survives contact

Rather than asking which system owns product data, ask which system owns the lifecycle phase in which this field changes.

A field that changes while the design is in work: PLM masters it.
A field that changes after release, during planning and execution: ERP masters it.
A field that changes on the line: MES masters it, and reports it back.

This works because it aligns mastership with the people actually making the change, which is the only arrangement that survives real use. Fields owned by a system whose users cannot edit them get edited somewhere else — a spreadsheet, an email, a verbal instruction — and that is how the authoritative record quietly stops being authoritative.

Practical checks

Write the mastership matrix before choosing an integration tool. Fields down the side, systems across the top, one master per row. If you cannot fill it in, no amount of middleware will help; you will simply automate the ambiguity.

Decide the direction of every flow, and make it one-way per field. Bidirectional sync on a field is a race condition with a project plan around it.

Test with a change, not with a load. Initial data migration always looks fine. The integration is proven or broken by what happens on the second revision of a part that exists in three systems.

Watch for the shadow spreadsheet. It is the reliable indicator that some field is mastered in the wrong place. Find it, and you have found a mastership decision that does not match how people work.