BOM management: keeping one version true across four departments

BOM management is the practice of keeping a bill of materials accurate, versioned and shared as a product changes. It becomes a discipline rather than a file the moment more than one function needs to act on it, because purchasing, production, quality and finance all read it and at least two of them want to change it.

The predictable failure is copies. An engineer sends a spreadsheet, purchasing adds supplier columns, production annotates it with substitutions made on the floor, and finance builds a costing from a version that predates both. Nothing is wrong with any of the copies individually; what has been lost is the ability to say which one is the BOM.

What BOM management means in practice

• One source, with everything else explicitly a view or an export of it.
• Revision control on the BOM as a whole, not just on parts — with a record of what changed between revisions and why.
• A release state: which revision is approved for production, and which is in progress.
• Effectivity — the date or serial number from which a revision applies, so a change does not retroactively invalidate what was already built.
• Where-used, so the effect of superseding a component across every product it appears in can be seen before the change is approved.
• Access rules: who may propose a change, who may approve one, who may only read.

Where-used is the query that prevents surprises

The question that matters when a part is discontinued is not what it is in, but everything it is in. A component used in one flagship product and quietly in three legacy ones produces an obsolescence problem three times larger than anticipated, discovered as each of those products fails to build. A structure that supports the reverse lookup — from part to all parents — turns that into a planning exercise instead.

Spreadsheets are a legitimate answer for a small product with slow change. What ends their viability is not part count but change rate: once revisions arrive faster than people reconcile copies, the copies diverge permanently, and no amount of discipline recovers it.

Suppliers see a different document

What goes to a contract manufacturer is not your internal BOM. It is a released revision, with approved alternates stated, with any part you do not want substituted marked as such, and with the drawings and specifications attached at the revision referenced. Sending a working spreadsheet instead is how substitutions get made in good faith that nobody approved, and the resulting argument is expensive because both parties were working from documents that were each internally consistent.

Keeping it manageable

Ettex Sheets holds the structure with a revision per column set rather than overwritten cells, Ettex Records keeps the released revisions with their effectivity and the supplier packages sent out, and the mechanism for moving between revisions is covered in engineering change order. The document itself is covered in bill of materials.

Plainly: this is a spreadsheet and records approach, not product lifecycle management software. PLM exists because this problem is real; what this covers is doing it deliberately at the scale where PLM is not yet justified.