Bill of materials (BOM), eBOM, mBOM: the backbone of your product data — and the roles of PDM, PLM and ERP

1. What is a bill of materials (BOM)?

The BOM (bill of materials) is the structured list of every component, sub-assembly and raw material needed to make a product. It is the pivot document between engineering, production and purchasing.

It is not a mere inventory. It encodes the parent-child relationships between parts: a hydraulic cylinder is a sub-assembly containing a body, a piston, seals and screws. Deleting a line or getting a quantity wrong can stop a production line or trigger a product recall.

There are several types of BOM, depending on the product stage and on who uses it:

2. eBOM vs mBOM: two views of the same product

The eBOM and the mBOM describe the same product from radically different angles. Mixing them up, or not planning the transformation from one to the other, is one of the most common sources of friction between engineering and the shop floor.

The eBOM → mBOM transformation is rarely automatic. It needs a structural transformation step: parts disappear (blank → machined part), operations are added, levels are reorganised to follow the routings.

3. PDM: keeper of CAD data and the eBOM

PDM (product data management) is a system that manages the technical data coming out of CAD. Its main job is to store, version and secure the SOLIDWORKS files, drawings and custom properties, and to extract the bill of materials (eBOM) from them automatically.

The most widespread PDM solutions in industrial SMEs:

• SOLIDWORKS PDM Standard / Professional — the most common choice in SOLIDWORKS design offices
• PTC Windchill PDMLink — paired with Creo, aimed at large companies
• 3DEXPERIENCE platform (Dassault Systèmes) — PDM built into a full PLM environment
• Autodesk Vault — for Inventor design offices

4. PLM: orchestrating the lifecycle

PLM (product lifecycle management) is a strategy as much as a system, covering a product's whole lifecycle: from idea to end of life. It includes PDM, but goes much further.

Where PDM focuses on data (files, eBOM, states), PLM focuses on the processes that change that data.

In practice, the line between PDM and PLM is often blurred. Many SMEs only have a PDM (SOLIDWORKS PDM) and call it "their PLM". That is not wrong in day-to-day use, but you need to know what is missing: formal change management, configuration traceability and the link with projects.

5. ERP: the mBOM in production and purchasing

ERP (enterprise resource planning) runs the business as a whole: finance, HR, purchasing, inventory, production, logistics. Here, what matters is the manufacturing module (MRP) and the management of manufacturing bills of materials.

The ERP consumes the mBOM to:

• Create work orders with the required components
• Trigger purchase orders from net requirements (MRP run)
• Calculate product cost (standard cost × BOM quantities)
• Manage inventory by backflushing components as each work order is issued
• Record production traceability (lot number, serial number)

6. How PDM, PLM and ERP connect

The three systems are not independent silos. They exchange data both ways, and that is precisely where companies struggle most.

The main flow: PDM → ERP (eBOM → mBOM)

This is the most common flow. Each time a BOM is released in the PDM, the data must reach the ERP to create or update the manufacturing BOM. In SMEs this transfer is rarely automatic: it is still often done by hand, through Excel exports.

The available integration mechanisms:

• PDM Gateway (SOLIDWORKS PDM Professional) — native connector to SAP, Sage, Cegid and other ERPs via XML/CSV
• REST API / web services — for custom integrations
• EAI middleware (Boomi, MuleSoft, Talend) — for complex multi-site architectures
• Manual CSV export/import — still very common in small SMEs

The PLM → ERP flow: product changes

When a product change (ECO) is approved in the PLM, it must trigger a coordinated update: a new revision in the PDM and an updated mBOM in the ERP. This is where BOMs drift apart if the processes are not formalised.

The ERP → PLM flow: feedback from the shop floor

Less known but crucial: production feedback (scrap, component substitutions, non-conformities) must flow back to the PLM to trigger formal changes. Without that loop, the design stays frozen on a reality that has moved on.

7. What happens when nothing is aligned

These are the recurring symptoms you see when PDM, PLM and ERP do not speak the same language:

These failures have a direct cost that is rarely measured: useless stock, rush purchases, line stoppages, wrong product costs, and engineering time spent reconciling lists instead of designing.

Where to start?

1. Check the state of your PDM — is the generated eBOM clean, up to date, with standardised properties?
2. Compare the PDM eBOM with the ERP mBOM on a representative product — measure the gap
3. Formalise a change process — even a simple one, even without a dedicated PLM tool
4. Automate the PDM → ERP flow if the volume justifies it (PDM Gateway or a structured export script)
5. Share a common vocabulary — engineering, manufacturing engineering and supply chain must speak the same BOM language

Frequently asked questions

What's the difference between eBOM and mBOM?

The eBOM is the engineering bill of materials: the structure as the product is designed. The mBOM is the manufacturing one: the same content seen as it is actually assembled, with consumables, routings and intermediate assemblies. The two always differ, and believing otherwise is the source of most gaps between engineering and production.

Should the BOM come from CAD or from the ERP?

The eBOM comes from design, the mBOM is built on the methods side. What matters isn't the originating tool but the rule: one system is authoritative for each BOM, and the direction of flow is written down. Two systems correcting each other always end up diverging.

How do you avoid BOM errors?

By removing manual entry wherever possible: properties controlled at source, closed lists, automatic extraction from the model. A BOM retyped into Excel is a BOM that will diverge — the only question is when.

Do you need a PLM to manage BOMs?

Not necessarily at the start: a well-configured PDM and clean properties already cover the eBOM. PLM becomes useful when the mBOM, variants and changes must be managed together, across several departments.