Bill of Materials Management: The Process, the Owners and the Failure Points

What bill of materials management covers, and what it does not

Bill of materials management is a configuration-management problem wearing manufacturing clothes. The international guidance for that discipline, ISO 10007, breaks the work into five activities: configuration management planning, configuration identification, change control, configuration status accounting and configuration audit (ISO 10007 overview). Translate those into shop-floor language and you get the actual scope:

• Planning — deciding in advance who may change what, and what approval a change needs.
• Identification — every part, assembly and BOM has a unique number and a revision, and exactly one of them is “current”.
• Change control — a change is requested, assessed, approved and released, never just edited.
• Status accounting — you can answer at any moment which revision is live, which changes are pending, and what was built on 3 March.
• Audit — you can prove what you shipped matches the revision you released.

What it does not cover: designing the product, choosing the software, or deciding which BOM views you need. Tool selection belongs in BOM software, the engineering-versus-manufacturing split in engineering vs manufacturing BOM. Management sits above whichever tool and whichever views you use.

Who owns the BOM: the four roles that must exist

Ownership fails when it is implicit. Four roles need naming, even if one person wears two hats in a 25-person firm.

The author (engineering or technical). Creates the initial structure, part numbers, quantities and units of measure. In small manufacturers this is often the founder or the one CAD user. The author proposes; the author does not unilaterally release.

The manufacturing owner (production engineering or the works manager). Turns the designed structure into the buildable one: consumables, packaging, scrap allowances, build stages. This person owns the version the floor actually uses, and is the one who gets hurt when a change lands without warning.

The approver (the change board). The person or small group who says yes. Arena’s change-order guidance recommends exactly this — a change control board overseeing proposed changes, with approvers alerted when a review is waiting on them (Arena — guide to engineering and manufacturing change orders). In a small firm the board is two people and a five-minute conversation, which is fine. What is not fine is nobody.

The consumers (purchasing, planning, costing, quality). They do not change the BOM but must be told when it changes, because a component swap moves an open purchase order, a works order, a standard cost and possibly a customer certificate.

A useful test: name the person who gets asked “why is there a different bracket in this batch?” If the answer is “depends who did it”, you have no ownership model.

The BOM lifecycle: draft, released, superseded, obsolete

A managed BOM has states, and the states have rules.

The rule doing the heavy lifting is the third: a released revision is immutable. You do not fix rev C, you release rev D. That is what makes “what did we build in March?” answerable at all, and it is the exact rule a spreadsheet cannot enforce, because any open copy of a spreadsheet can be typed into.

Superseded revisions are not deleted. A machine sold three years ago was built to whatever revision was live then, and the spares you sell against it have to match.

Revision control: revision, version, and when to change the part number instead

Three distinct mechanisms get muddled constantly.

Revision. The same part, changed in a way that does not affect interchangeability. Bracket rev B replaces rev A; either fits, so stock can be mixed and old ones used up. Revisions are usually letters and belong to the released item.

Version or iteration. Working states between releases — rev C draft 3. Useful internally, meaningless outside engineering. Nobody buys or builds to a draft.

New part number. The change breaks form, fit or function, so the part must not share a number or purchasing and the floor will mix them. Blunt test: if fitting the old one to a new build would produce a defect, or the new one to an old machine would, you need a new number rather than a revision.

Getting that third one wrong is the most expensive small mistake in bill of materials management, and it stays invisible until a service engineer orders “the bracket”, receives the version that no longer fits the older frame, and bills you for a wasted site visit.

Change control that works: ECR, ECO, ECN and the change board

The standard flow, stripped of enterprise ceremony:

1. Engineering change request (ECR). Anyone can raise one: a welder tired of a fixture, a buyer facing an 18-week lead time, a customer complaint. Arena describes ECRs as documenting the initial request to address a design problem — deliberately low-friction, because a process nobody can enter gets bypassed.
2. Impact assessment. The step everyone skips. What stock of the old part exists, what is on order, what is mid-build, does the change touch a certificate or an approved drawing, what does it do to standard cost and price?
3. Engineering change order (ECO). The formal instruction to change the baseline. It names the revised items, the new revision levels and — critically — the effectivity.
4. Approval. In ERP terms a hard gate: Oracle’s engineering module will not set an ECO to Scheduled or Implemented unless the approval status is Approved (Oracle Engineering User’s Guide). Worth copying even if you never buy Oracle.
5. Engineering change notice (ECN). The broadcast: purchasing, planning, the floor, quality, service. A change is finished not when it is approved but when everyone who acts on it knows.
6. Verification. First article, first build, or a check on the first works order consuming the new revision.

Small manufacturers reasonably compress steps 1 to 3 into one form. What cannot be compressed is the impact assessment and the notice — the two whose absence causes the four-figure surprises.

Effectivity dates: date, unit or serial, and use-up

Effectivity answers “from when?” — and it is the most under-used control in small-firm BOM management, because a spreadsheet has no way to express it.

Date effectivity. A component carries an effective-from and a disable date. Oracle’s BOM documentation defines the effective date as the first day a component becomes effective for a bill, and the disable date as the point from which you can no longer assign it (Oracle Bills of Material User’s Guide). SAP does the same job with a change master record carrying a valid-from date, which makes the edit a tracked change with history rather than a silent overwrite (SAP — creating a change status with date validity).

Unit or serial effectivity. The change applies from unit number 41 onward, regardless of date. Used where products are serialised and slow-moving — machines, vehicles, capital equipment. Oracle treats the two as alternatives: an item is controlled by date or by model/unit number, not both.

Use-up effectivity. The commercially sensible one: the change takes effect when stock of the old component runs out. Oracle supports basing a revised item’s effective date on the use-up date of another item, and alerting planners when the planning run computes a new one. Without it, a harmless improvement writes off a shelf of good parts.

The practical point: effectivity is what stops a change being retrospective. A BOM edited in place applies instantly to everything, including jobs already quoted, picked and half-built.

Worked example: a hinge supplier change, from request to first build

A 30-person enclosure fabricator. Current hinge, HNG-114 rev A, lead time has gone from 3 weeks to 11.

Monday — ECR raised. The buyer logs it: lead time is driving late deliveries on two product lines. A second supplier’s hinge is dimensionally equal except for fixing centres, 2 mm apart.

Wednesday — impact assessment. Those 2 mm move the door panel’s pilot holes, so this is not a hinge swap; it touches two items. Stock: 640 old hinges on the shelf, 1,200 on an open purchase order, two works orders in progress. Standard cost £0.42 lower per hinge, six per unit, roughly £2.52 a unit.

Thursday — the numbering decision. Because the fixing centres change, the new hinge gets a new part number, HNG-220, not a revision of HNG-114 — fit an HNG-114 to the new pattern and the door sits proud. The door panel gets a revision, rev C to rev D, because rev D is slotted to take either hinge. That is the interchangeability test doing its job: the panel stays one part number precisely because the two revisions can be mixed on the shelf.

Friday — ECO raised and approved. Revised items: door panel to rev D; enclosure manufacturing BOM to rev E, replacing HNG-114 with HNG-220. Approvers: works manager plus engineering. Effectivity: use-up on HNG-114, with the open purchase order cut from 1,200 to 400. Projected effective date, week 6.

Friday — ECN issued. Purchasing amends the PO. Planning marks the two in-progress works orders as built to enclosure BOM rev D and excludes them from the change. The laser programmer prepares the new nest and holds it, dated. Service is told that machines shipped before the effectivity date still take HNG-114 as a spare, which is why the old part stays orderable rather than obsolete.

Week 6 — first build. Rev E goes live, the first unit is checked against the drawing, and the works order records the revision it was built to.

Total admin: perhaps three hours. Without change control: someone edits the shared spreadsheet on Thursday, the floor’s printed copy still says HNG-114, the laser cuts the old pilot pattern for a fortnight, and 400 door panels get drilled twice.

Keeping the BOM in step with purchasing and production

A BOM that is accurate but disconnected still leaks money. Four joins matter.

BOM to purchasing. A revision that changes a component must immediately surface open purchase orders for the old part, with quantity in transit and cancellation terms. Goods-in needs the current revision too, so a wrong part is caught at receipt rather than at build.

BOM to works orders. A works order should snapshot the revision at release rather than point at “current”. Otherwise a mid-job change rewrites what a half-built unit was meant to contain. The snapshot is what lets you say, two years later, exactly what went into serial 0412.

BOM to costing. Every revision moves the standard cost. If cost lives on an unversioned BOM, margin analysis compares this month’s actuals against a standard that has quietly shifted — guesswork with decimal places.

BOM to stock. Issuing a works order should consume components at the released revision. If it does not, the stock figure drifts between counts and the shortage announces itself as a stopped line rather than a warning.

Where spreadsheet BOM management fails, control point by control point

Spreadsheets are good at holding a parts list and structurally incapable of managing one. The failures are specific.

The two that bite earliest are stale revisions on the floor — a printout or PDF taken before the last change — and silent concurrent edits, where two people open the same file from a shared drive and one person’s work is discarded. Neither produces an error message. Both produce scrap.

A minimum BOM governance policy you can run from Monday

You do not need a PLM platform to stop the bleeding. You need rules that are written down and actually enforced.

1. One place is the master. Everything else — printouts, PDFs, supplier copies — is a controlled copy carrying a revision stamp and a print date.
2. Named author, named approver, per product family. Never the same person on the same change.
3. Released revisions are frozen. A change creates a new revision. No exception for “small” changes; those are the ones that escape.
4. Every change gets an impact check before approval covering stock on hand, on order, in WIP, plus any certificate or customer approval affected.
5. Every change gets an effectivity, even if the answer is “immediately”. Writing “immediately” is a decision. Leaving it blank is an accident.
6. Every change gets broadcast to purchasing, production, quality and service. One message, one distribution list.
7. Works orders record the revision they were released against. The traceability backbone, and free to start doing.
8. Quarterly BOM audit. Pull three products at random, walk the floor, compare what is being fitted against the released revision. What you find tells you whether the other seven rules are real.

Firms too messy for spreadsheets but not ready for a full ERP usually stall here: the rules are obvious, but enforcing them on discipline alone fails in the first busy week. That is where a right-sized operations system earns its keep — revisions that lock on release, a change request that cannot be approved by the person who raised it, effectivity dates that gate what a works order consumes, and an audit trail that exists whether or not anyone remembered to write it. An owned operations system shaped around how you make things, rather than a platform you reshape yourself around.

FAQ

What is the bill of materials management process?

A controlled loop: create the BOM, release it at a revision, receive change requests, assess their impact on stock, open orders and work-in-progress, approve formally, set an effectivity date or use-up point, notify purchasing and production, then verify the first build. Between changes the released revision is frozen, so a change always produces a new revision rather than an edit to the old one. The underlying activities are the five ISO 10007 names for configuration management: planning, identification, change control, status accounting and audit.

Who is responsible for maintaining the bill of materials?

Engineering usually authors it, production engineering owns the manufacturing version, and a small change board approves changes — but the roles matter more than the titles. In a 20 to 50 person manufacturer one person may author and another approve, which is enough as long as the approver is never the requester on the same change. Purchasing, planning, costing, quality and service are consumers: notified of changes, but not able to edit.

What is an effectivity date on a BOM?

It is the point from which a component or change becomes valid, expressed as a date, a unit or serial number, or the use-up point of existing stock. Date effectivity gives a component an effective-from and a disable date; unit effectivity applies the change from a given serial number onward; use-up effectivity delays it until the old part is exhausted, avoiding scrapped stock. Effectivity is what stops a change applying retrospectively to jobs quoted, picked or part-built under the previous revision.

How often should a bill of materials be reviewed?

Continuously by exception — every change request forces a review of the affected items — plus a scheduled audit at least quarterly on a sample of live products. The audit is what catches drift: parts the floor substitutes informally, consumables never added, quantities rounded years ago. If a quarterly sample turns up no discrepancies twice running, stretch the interval; if it turns up several, the problem is the change process rather than the BOM.

Sources

• ISO 10007 — Quality management, guidelines for configuration management — the five configuration management activities: planning, identification, change control, status accounting and audit.
• Oracle Bills of Material User’s Guide — component effectivity — effective-from, disable and inactive dates, and date versus unit effectivity control.
• Oracle Engineering User’s Guide — engineering change orders — ECO statuses, revised items, approval gating and use-up effectivity.
• SAP — creating a change status with date validity — change master records with valid-from dates for editing bills of material.
• Arena — guide to engineering and manufacturing change orders — ECR versus ECO, change control boards and approval alerts.