BOM Management for Manufacturing
What the BOM management engine delivers
eBOM and mBOM editor in one view
One editor, two views. Engineering edits the eBOM as design intent — parts, parents, quantities, references to the CAD item. Manufacturing edits the mBOM as build recipe — phantom assemblies, consumables, line allocations. Both views read the same typed component master, so a renamed item or a corrected unit propagates wherever it is referenced.
Versioning with full audit trail
Every BOM revision is a first-class object — who proposed it, who approved it, which engineering change triggered it, which downstream system has consumed it. Revisions are diffable line by line; superseded versions stay queryable for warranty, recall and regulatory work. No more shared Excel with a date in the filename.
AI attribute inheritance from PIM
When the BOM references a component, the editor pulls its typed attributes from the product attribute extraction engine — material, finish, tolerance class, certification. A Mastra pipeline narrows one engineering reference against the supplier SKUs that match its spec, and a human approves which SKU enters the mBOM.
eBOM to mBOM sync workflow
Engineering changes do not silently overwrite the manufacturing recipe. A change on the eBOM surfaces in the mBOM as a diff with a routing rule — auto-accept for in-kind swaps, queue for review when a phantom assembly is affected, block when a certified component would be dropped. Production knows what changed and when it takes effect.
PLM export to PLM of record
Approved BOM revisions export to the PLM of record through its published API — Siemens Teamcenter, PTC Windchill, Aras Innovator or a custom stack. Identifiers, parent-child links, effectivity dates and attachments map to the PLM schema. A legacy PLM upgrade ships alongside through our legacy modernization track.
ERP export to SAP, Abacus, vertical
The mBOM also exports to the ERP that drives procurement and shop-floor execution — SAP S/4HANA, Abacus or a Swiss vertical ERP — through the ERP and PIM connectors we maintain. Routing alternatives, lot sizes and cost-centre allocations are mapped during onboarding; later revisions flow through the same connector.
How we deliver BOM
Component inventory
We inventory the components your BOMs reference today — Excel, ageing PLM exports, CAD masters, supplier catalogues. Duplicates collapse against canonical items, and each component picks up a typed attribute set.
Schema baseline for BOMs
Item, parent-child, quantity, unit, effectivity, revision — every field gets a type, a required flag and a downstream owner. The schema is the contract between engineering, manufacturing and PLM/ERP.
Versioning rules
We codify the change rules with you — who can propose a revision, who must approve, which downstream system blocks release. Rules live as configuration; engineering change orders are first-class objects with audit trail.
AI inheritance pilot
On one product family we wire the multi-agent inheritance pipeline — one BOM line, twenty supplier SKUs, the system narrows to the matching subset on type, and a human commits over Reverb websockets.
eBOM and mBOM rollout
We turn on diff routing — auto, queue, block — against your real change history. Production gets a queue scoped to its lines; engineering sees which proposals are stuck, and why each one stuck on which rule.
PLM and ERP hand-off
We map approved revisions to the PLM of record (Teamcenter, Windchill, Aras or custom) and the ERP that drives procurement (SAP, Abacus or Swiss vertical). Schema, rules, mappings and runbook transfer.
We inventory the components your BOMs reference today — Excel, ageing PLM exports, CAD masters, supplier catalogues. Duplicates collapse against canonical items, and each component picks up a typed attribute set.
Item, parent-child, quantity, unit, effectivity, revision — every field gets a type, a required flag and a downstream owner. The schema is the contract between engineering, manufacturing and PLM/ERP.
We codify the change rules with you — who can propose a revision, who must approve, which downstream system blocks release. Rules live as configuration; engineering change orders are first-class objects with audit trail.
On one product family we wire the multi-agent inheritance pipeline — one BOM line, twenty supplier SKUs, the system narrows to the matching subset on type, and a human commits over Reverb websockets.
We turn on diff routing — auto, queue, block — against your real change history. Production gets a queue scoped to its lines; engineering sees which proposals are stuck, and why each one stuck on which rule.
We map approved revisions to the PLM of record (Teamcenter, Windchill, Aras or custom) and the ERP that drives procurement (SAP, Abacus or Swiss vertical). Schema, rules, mappings and runbook transfer.
Why this BOM engine, not a bolt-on
BOM reconciliation is a state-machine problem
Engineering BOM and ERP BOM diverge every quarter — a renamed component, a swapped supplier SKU, a change order that landed in one system and not the other. The drift accumulates silently until a warranty claim forces a manual reconciliation, and the reconciliation itself is rarely captured. We model the BOM as a state machine: each revision is a transition with a proposer, an approver, a trigger and an effectivity window, so the diff is queryable.
Variants and supersession as typed, versioned data
Components carry typed attributes against ETIM, eClass or your own OEM extensions — material, finish, tolerance class, certification — and every attribute is versioned alongside the supersession chain. When an obsolete SKU is replaced, the chain stays intact and the editor resolves old revisions without rewriting the new ones. The same typed surface powers the product attribute extraction engine.
Role-scoped review across engineering, supply chain, ERP ops
Engineering owns structure — parts, parents, design intent. Supply chain owns sourcing — which approved SKU satisfies the line, which alternates are on the catalogue. ERP operations owns the push — when a revision becomes effective, which cost centre and routing it lands against. Each role sees only the lines it owns, with a queue scoped to its decision rights.
Integration targets are schemas, not adapters
Teamcenter, Windchill and Aras on the PLM side, SAP S/4HANA and Abacus on the ERP side, are integration targets, not partnerships. We bind through published APIs and map identifiers, effectivity and attachments to each system's schema; the mappings are configuration our ERP and PIM connectors track maintains.
Frequently Asked Questions
PLM owns engineering intent; ERP owns procurement. Neither owns the typed component master both depend on, nor the diff between engineering and manufacturing views. We treat BOM and components as master data — typed, versioned, audited — so PLM and ERP become consumers.
The eBOM is engineering's view — the product, parent-child links, references to the CAD item. The mBOM is manufacturing's view — phantom assemblies, consumables, line allocations. Both read the same typed master; eBOM changes route as auto, queue or block by rule.
A multi-agent Mastra pipeline narrows the SKU set on typed attributes — material, finish, tolerance class, certification — from the product attribute extraction engine. Candidates surface over Reverb websockets, and a human commits which SKU enters the mBOM. Each step is logged.
Each BOM revision is a first-class object carrying the proposer, the approver, the engineering change that triggered it, the effectivity window and the consuming downstream systems. Revisions are diffable line by line; superseded versions stay queryable.
Approved revisions export to Siemens Teamcenter, PTC Windchill, Aras Innovator and custom PLM stacks via published APIs; mBOMs export to SAP S/4HANA, Abacus and Swiss vertical ERPs through our connector library. We are not a PLM-vendor partner — we integrate against open APIs.
Yes. The stack — Laravel 12, Next.js 13, PostgreSQL, Mistral, OpenAI and Mastra — runs on AWS in EU or Swiss regions, or on-prem. For FINMA-, MDR- or IVDR-sensitive flows we deploy on Swiss hosting; schema and prompt registry are portable, so residency is a deployment choice.
About SAPIENTROQ
Interested in a solution?
We are glad to show you various options without any obligation.
Roland Kurmann
CEO, SAPIENTROQ
