The MBOM, and why it is not the EBOM

What it is, and what it is not

A manufacturing bill of materials is the structure a specific plant builds from, derived from the engineering bill but not identical to it. It has its own lines, its own quantities, its own sequence, and a traceable relationship back to the EBOM it came from.

It is not a view of the EBOM with a filter on it. The differences are additive and substantive: parts that exist only in manufacturing, parts that exist only in engineering, quantities that differ because of scrap and yield, and structure that is reorganised around how the thing is actually assembled.

It is also not a routing. A routing describes operations, sequences, work centres and times; an MBOM describes materials. They are related and often edited together, and in most deployments the routing belongs to whoever owns manufacturing execution — which is frequently your ERP rather than here.

Four kinds of divergence, all legitimate

Phantoms explode. A fastener kit is an engineering convenience that nobody buys as a kit. In the MBOM it becomes six M3 screws and four washers, because that is what gets picked.

Manufacturing-only parts are added. Packaging, cartons, labels, thread-locker, solder paste, protective film, the desiccant sachet. None of them are in the design and all of them are consumed building the product.

Plants substitute. The same product built in Frankfurt and in Austin takes a different label, a different carton, and sometimes a regionally sourced component. A single global structure that ignores this gets corrected on the floor, and those corrections never travel back.

Structure is restructured. Engineering groups by function; manufacturing groups by assembly sequence. Splitting one engineering sub-assembly across two manufacturing stages is not an error, and a tool that treats it as a difference to be reconciled is fighting the people using it.

The failure it prevents

A team runs one BOM for both purposes because two seemed like duplication. Manufacturing adds packaging to it. Engineering revises the product and, six months later, somebody notices the packaging is gone — deleted in a restructure by an engineer who had no idea it was load-bearing.

The other version of the failure is worse and more common. Manufacturing gives up on the shared structure and maintains its own in a spreadsheet. Now a design change reaches engineering's BOM and reaches nothing else, and the plant builds the old configuration until somebody notices.

The mechanism that prevents both is the trace. Every MBOM line either derives from an EBOM line or is explicitly manufacturing-only. When the EBOM changes, the affected MBOMs are identified — every plant, not just the one somebody remembered — and the divergences that were deliberate are preserved rather than flattened.

How it meets the rest of the product

Both structures resolve through the same engine, so effectivity, variants, revision policy and plant scope apply to an MBOM exactly as they do to an EBOM. A plant-specific MBOM effective from October is expressible without a workaround.

Change control spans both. An ECO's impact set includes the MBOMs derived from an affected EBOM, so the approver sees that a change touches two plants rather than discovering it afterwards. Release is atomic across everything the change carries.

Work instructions are generated from the MBOM rather than maintained beside it, which is the only arrangement where they stay current. A revision-controlled instruction that references a part number gets flagged when that part changes, instead of quietly describing a component nobody stocks any more.

Contract manufacturer transfer packages are assembled from the same structures — the MBOM, the drawings at their released revisions, the approved manufacturer list — and shared through the supplier portal at specific revisions rather than emailed as a zip.

How it meets your ERP

MBOM ownership is the one genuinely contested row in the system-of-record matrix, and it is decided per tenant rather than assumed. In many organisations manufacturing engineering has owned the production BOM inside the ERP for years, and there is no good argument for taking it away from them.

If you keep it there, Manufacturing PLM publishes the EBOM and stops at that boundary — it will not publish an MBOM and then behave as though it owned one. If you move it here, the MBOM publishes as the production structure in whatever form the target expects, and routings stay wherever you left them.

Routings and work centres are not published by default under either arrangement. They belong to manufacturing execution, and in most deployments that means Epicor's method of manufacture, Acumatica's BOM operations or Dynamics' route — where the people who own them already work.

Where the boundary is

Manufacturing PLM does not execute manufacturing. No work orders, no material issues, no labour booking, no shop-floor scheduling, no capacity planning. It defines what should be built and how; your ERP and MES run the building.

Tooling, fixtures and moulds are modelled as objects with their own lifecycle and ownership, but Manufacturing PLM does not track cycle counts in real time or drive preventive maintenance — those are execution data and belong to the systems that generate them.