For the manufacturing engineer
You are the person who finds out that engineering restructured an assembly when a kit does not scan. This page is about the two things that change that: a manufacturing structure that is genuinely yours, and a change process that tells you before the floor does.
What you are actually worried about
That a PLM bought by engineering will treat your structure as a derived view they can overwrite. That packaging, consumables and labels will keep disappearing from a shared bill. And that you will be asked to maintain routings in a second system while the first one still owns them.
All three are reasonable, and all three describe what usually happens. The answers below are specific rather than reassuring, including the one where the honest answer is that your routings should stay exactly where they are.
The MBOM is a structure, not a filter
A manufacturing bill in Manufacturing PLM is its own structure with its own lines, quantities and sequence, derived from the engineering bill with a traceable relationship back to it. Four kinds of divergence are first-class rather than tolerated.
Phantoms explode. The fastener kit engineering finds convenient becomes six M3 screws and four washers, because that is what gets picked. Manufacturing-only parts stay. Cartons, labels, thread-locker, desiccant, protective film — added by you and never deleted by an engineering restructure.
Plants differ. Plant is a first-class effectivity dimension, so Frankfurt's EU label and Austin's regional power supply are the same product expressed correctly, not two products or a custom field. Structure is restructured. Grouping by assembly sequence rather than by function is not a difference to be reconciled.
The trace is what makes this safe. Every MBOM line either derives from an EBOM line or is explicitly manufacturing-only, so a design change identifies the affected MBOMs — every plant, not the one somebody remembered — while preserving the divergences that were deliberate.
You find out before the floor does
An ECO's impact set is computed by traversing the relationship graph, and it includes the MBOMs derived from the affected EBOM. That means the approver sees a change touches two plants, and it means you see it during review rather than when a kit fails to scan.
The impact set is deterministic — no model in the path — so the same question asked twice returns the same bytes. That matters for you specifically because it makes the set attached to an approved change into evidence of what was known at the time, rather than a snapshot somebody might have edited.
Release is atomic. Every affected revision, lifecycle transition and structure update commits together or not at all. There is no window in which the EBOM has moved and your MBOM has not.
Work instructions that cannot go stale
Instructions are generated from the MBOM rather than maintained alongside it, which is the only arrangement in which they stay current. An instruction that references a part number is flagged when that part changes, instead of quietly describing a component nobody stocks any more.
They are revision-controlled like any other document, so the instruction issued to the line in March is recoverable and a controlled copy carries a watermark and an expiry. A printout taped to a bench cannot silently become the current version, and cannot silently remain the old one either.
Contract manufacturer transfer packages assemble from the same structures — the MBOM, the drawings at their released revisions, the approved manufacturer list — and go out through the supplier portal at specific revisions rather than as an emailed zip that is stale the moment a change releases.
How it meets your ERP
Your routings should probably stay where they are, and Manufacturing PLM will not argue. Routings, operations, work centres, resources and setup times belong to manufacturing execution, and in most deployments that means Epicor's method of manufacture, Acumatica's BOM operations or the Dynamics route — where you already work.
MBOM ownership is the contested row in the system-of-record matrix and it is decided per tenant. Keep it in the ERP and Manufacturing PLM publishes the EBOM and stops at that line rather than publishing a manufacturing structure it does not own. Move it here and it publishes as the production structure in the shape your ERP expects.
Either way nothing transactional is written: no work orders, no material issues, no labour booking, no scheduling. What flows back is context — on-hand, open orders, lead time — so an impact review shows you the stock consequence of a change alongside the structural one.
Where the boundary is
Manufacturing PLM does not execute. It defines what is built and how; your ERP and MES run the building, and no part of this asks you to move that. Capacity planning, scheduling and shop-floor dispatch are not attempted.
Tooling, fixtures and moulds are modelled as objects with lifecycle and ownership, but cycle counts and preventive maintenance are execution data generated by systems Manufacturing PLM does not talk to. Inspection execution is likewise MES work — Manufacturing PLM holds the plan and the characteristics, not the measurement.
Facts
| MBOM | Its own structure, with a per-line trace to the EBOM |
| Manufacturing-only parts | Never deleted by an engineering restructure |
| Plants | First-class effectivity dimension, not a custom field |
| Change impact | Includes every derived MBOM, before approval |
| Release | Atomic — no window where EBOM and MBOM disagree |
| Work instructions | Generated from the MBOM, revision-controlled |
| Routings | Stay in your ERP by default — we will not argue |
| Not attempted | Scheduling · capacity · dispatch · labour booking |
Frequently asked
Will engineering overwrite my structure?
No. The MBOM is its own structure with a per-line trace back to the EBOM, so manufacturing-only lines are recorded as such and survive an engineering restructure. A design change identifies the affected MBOMs and preserves the divergences that were deliberate.
Do I have to move routings into Manufacturing PLM?
No, and by default you should not. Routings, operations, work centres and setup times belong to manufacturing execution, and in most deployments that is Epicor, Acumatica or Dynamics — where you already work. Manufacturing PLM publishes the material structure and stops there.
Can each plant build differently?
Yes. Plant is a first-class effectivity dimension, so a Frankfurt structure with an EU label and an Austin structure with a regional power supply are the same product expressed correctly. Both trace to one engineering definition, and both are visible in a change's impact set.
When do I hear about a change?
During review, because the impact set includes the MBOMs derived from the affected EBOM. The approver sees the change touches two plants before approving it, rather than you discovering it when a kit fails to scan on the line three weeks later.
How do work instructions stay current?
They are generated from the MBOM rather than maintained beside it. An instruction referencing a part number is flagged when that part changes, and controlled copies carry a watermark and expiry so a printout on a bench cannot silently become — or remain — the wrong version.
What about a contract manufacturer package?
Assembled from the same structures — MBOM, drawings at their released revisions, the approved manufacturer list — and shared through the supplier portal at specific revisions. Not an emailed zip that goes stale the moment the next change releases and nobody re-sends it.
Does it schedule or dispatch anything?
No. Manufacturing PLM defines what gets built and how; your ERP and MES run the building. Capacity planning, scheduling, dispatch, material issues and labour booking are all outside it, and nothing in the integration asks you to move any of that work.