The bill of materials management process is the set of controls that create a BOM, release it, change it, and retire it so that engineering, purchasing, and production always build from the same version. It has seven steps: create, review, release, maintain, change, audit, and obsolete. Most of the process is change control, because a bill that never changed would need almost no management, and no real bill stays unchanged for long.
The published guidance on this topic tends to describe software features. What follows is the process a plant needs whether the bill lives in a PLM system, an ERP, or a locked spreadsheet: who owns each step, what artifact each step produces, and where the failures actually happen.
What bill of materials management covers
BOM management governs the product-structure record through its whole life: the parts, quantities, units, revisions, and effectivity that make up each bill, plus the workflow that decides who may change them and when the change takes effect. Arena’s glossary definition frames it as managing the BOM across departments and product stages; the operational meaning is narrower and more useful: one released version at a time, and a controlled path from one version to the next.
The record being managed and its structure, from levels to the difference between engineering and manufacturing views, are covered in the guide to what a bill of materials is. This page assumes that structure and concentrates on the process around it.
The seven-step BOM management process
| Step | What happens | Artifact produced | Owner |
|---|---|---|---|
| 1. Create | Engineering builds the EBOM from the design; each line gets a part number, quantity, unit, revision | Draft engineering BOM | Design engineering |
| 2. Review | Manufacturing, purchasing, and quality check buildability, sourcing, and missing lines; the MBOM is derived | Reviewed EBOM and MBOM | Manufacturing engineering |
| 3. Release | Formal approval; the bill becomes the single version production and MRP may use | Released revision (e.g., Rev A) | Change control board or designated approver |
| 4. Maintain | Item-master data (units, make/buy flags, scrap factors, costs) is kept current against the released bill | Current item master | Master data owner |
| 5. Change | Any modification goes through an engineering change request, impact review, approval, and effectivity-dated release | Approved ECO with effectivity | Change control board |
| 6. Audit | Sampled bills are verified against the physical build; errors are classified and traced to cause | Accuracy scorecard | Manufacturing engineering |
| 7. Obsolete | Superseded revisions are archived, not deleted; end-of-life bills close purchasing and preserve service history | Archived revision, service BOM | Engineering with aftermarket |
Steps 1 through 3 happen once per new product; steps 4 through 6 run continuously; step 7 happens once per revision. The process is mostly step 5 by volume, which is why the section on change control below is the longest.
Change control: the core of the process
An engineering change moves through five gates, and skipping any of them is how a plant ends up with two versions of the truth:
- Request. Anyone may raise an engineering change request (ECR); it states the problem, not the solution.
- Impact review. Engineering proposes the change; purchasing, production, quality, and cost review it. Where-used analysis is mandatory here: a component that appears in six products means six bills to update, six inventories to run out, six suppliers to notify.
- Approval. A change control board (or, in small companies, a named approver) authorizes the engineering change order (ECO). Fast lanes exist for trivial changes, but the lane is still a lane.
- Effectivity. The change takes effect by date, serial number, or lot, aligned with run-out of the old part. A change cut in mid-kit strands material.
- Release and verify. The new revision replaces the old in ERP and on the floor at the effectivity point; the next build is checked against it.
Two rules keep the loop honest. Every change carries an owner and an effectivity, no exceptions. And nothing is edited in the live BOM outside the loop, however obvious the fix looks, because two people fixing the same bill differently in the same week is the most common way a controlled process reverts to chaos.
A worked example: one bushing, six products
The scenario below is illustrative. A supplier discontinues an axle bushing used in six hand-truck models. The ECR states the problem: current part unavailable after 90 days. Where-used analysis shows the bushing appears at quantity 2 per wheel assembly, 2 wheel assemblies per truck, in all six models. Engineering qualifies a replacement with the same dimensions but a different part number.
| Item | Value | Source |
|---|---|---|
| Old bushings on hand | 9,600 | Inventory |
| Bushings per truck | 4 (2 per assembly × 2 assemblies) | BOM |
| Trucks the stock covers | 9,600 ÷ 4 = 2,400 | Derived |
| Combined monthly build, six models | 1,600 | MPS |
| Run-out | 2,400 ÷ 1,600 = 1.5 months | Derived |
The ECO sets effectivity at the start of the second month after approval, when roughly 800 old bushings remain, so the last old stock is consumed on the final pre-change lots and the new part arrives inside the 90-day window. Six bills change on one ECO with one effectivity, purchasing gets one notice, and no kit is stranded with half a change. Skip the where-used step and the likeliest outcome is five bills changed, one forgotten, and a line stop on the sixth model discovered at assembly.
Who owns what
The single most common failure in BOM management is not a missing tool but split ownership: engineering thinks purchasing keeps the bill current, purchasing thinks engineering does, and the item master drifts. Z2Data’s overview of BOM management lists the functions that touch the bill; the process only works when one of them is named as the owner of record for structure data. In most mid-size manufacturers that role sits with manufacturing engineering or a master data function, with design engineering owning the EBOM content and the change board owning approval.
The audit step is where ownership gets tested. Sampled bills are checked against the physical assembly, errors classified by type, and each error type traced to an owner who fixes the cause rather than the instance. How to run that audit, including the line-level versus whole-bill accuracy conventions, is covered in the guide to bill of materials accuracy.
Common BOM management mistakes
- Editing the live bill directly. The obvious fix applied outside change control is the seed of every duplicate version.
- Changes without effectivity. A correction that cuts in immediately strands material and confuses kits already picked.
- Skipping where-used. Shared components change in some products and not others; the forgotten one stops a line.
- Deleting old revisions. Service and warranty need to know what was actually built; archive, never delete.
- Running MRP on the EBOM. The engineering view lacks packaging, consumables, and station grouping; the manufacturing BOM is what planning consumes.
- Spreadsheet past its limits. Once revisions overlap or shared parts multiply, a file cannot enforce the loop; that threshold is a recurring line in the ERP readiness checklist.
Bill of materials management FAQ
What are the 5 required elements in a bill of materials table?
Every BOM line needs a part number, a description, a quantity per parent, a unit of measure, and a revision level. Production-grade bills add reference designators, scrap factors, make-or-buy flags, and effectivity dates on top of those five.
What are the steps in the bill of materials management process?
Create the engineering BOM, review it cross-functionally and derive the manufacturing BOM, release one approved revision, maintain the item master against it, run all changes through an effectivity-dated change order, audit sampled bills against the physical build, and archive superseded revisions rather than deleting them.
What are the two types of BOM processing?
Explosion and implosion. Explosion walks down the structure to compute component requirements for a given quantity of finished product, which is what MRP does. Implosion (where-used) walks up from a component to every parent that consumes it, which is what change control depends on.
What are common BOM mistakes to avoid?
Editing the live bill outside change control, releasing changes without effectivity dates, skipping where-used analysis on shared components, deleting old revisions, and running material planning on the engineering BOM instead of the manufacturing BOM.
Next steps
- Name the owner of record for structure data and write it down; if two functions both claim it, that is the first fix.
- Route the next three BOM changes through the five gates on paper, even if the system is a spreadsheet, and record how long each gate took.
- Pick five bills for an audit against the floor this month, and classify what you find by the mistake list above.