BOM quality in PLM: Validation, standardisation and data discipline that reduce errors across the value chain

Many improvement projects stall at “we need to clean up the data”. But BOM quality is not about one major clean-up – it is about establishing mechanisms that prevent errors from recurring. When BOM data is incomplete or inconsistent, the consequences quickly become apparent: purchasing errors, incorrect cost estimates, production errors and increased non-conformances.

PLM is a suitable place to build in quality because this is where the product definition is created and approved.

What does “BOM quality” mean in practice?

Good BOM quality means that the BOM is:

• complete (all necessary parts and documents are included)
• consistent (the same definitions and naming conventions)
• valid (follows rules for structure, units, quantities and alternatives)
• traceable (revision, effectivity, history and decisions)
• usable (can be consumed by ERP/MES without manual post-processing)

The most common BOM errors (and how PLM can prevent them)

1) Missing attributes

Example: unit, material, weight, “make/buy”, supplier information.

Action in PLM: mandatory fields at status transitions (draft → review → released).

2) Invalid quantities or units

Example: “1.5 pcs”, incorrect unit (m vs mm), or mixed decimal formats.

Action: validation rules + standardised units and formats.

3) Duplicates and “almost identical” parts

Example: the same bolt registered three times with different descriptions.

Action: reuse processes, similarity searches, an approval gate for new parts.

4) Documentation not linked to the correct BOM line

Example: an incorrect datasheet or an outdated instruction.

Action: require document links for each critical component, and a release package.

Establish simple BOM governance (without bureaucracy)

A practical model is to define:

• BOM Owner (often the engineering lead/product owner)
• Data Steward (standards, naming, duplicate checks)
• Change Board (approves changes with cross-functional representation)

The goal is not more meetings, but clear accountability and fewer “nobody owns this” situations.

“Quality gates” for BOMs: Three levels that make a difference

Gate 1: Draft checks (quick)

• mandatory fields
• basic structure validation
• duplicate checks

Gate 2: Pre-release (cross-functional)

• production and purchasing review
• alternatives/substitutes verified
• documentation package complete

Gate 3: Release-to-ERP (automated)

• format and attributes match ERP requirements
• effectivity and revision validated
• export/publishing logged (traceability)

Integration: Quality is established at the handover

Many find that “PLM is well organised, but ERP gets messy”. The problem often lies in:

• unclear master data rules (which system owns which fields)
• missing attribute mapping
• no feedback when errors occur (ERP errors should be returned as non-conformances)

A good principle is: PLM only publishes released data, and transfer errors are handled as controlled issues – not manual “fixes in ERP”.

Summary

BOM quality in PLM is about making correct data the default outcome – not a heroic effort. With standards, validation, gates and clear ownership, you can reduce errors across the value chain: engineering, purchasing, production, service and quality.

Next step: Create a “Top 10 BOM rules” list (mandatory fields, units, naming standard, release requirements), and implement them as validations and gates in PLM. This delivers quick benefits.