A BOM Review Is Not One Meeting. It Is Every Handoff in Your Company

Since we first introduced OpenBOM BOM Review in July, I have been asking engineering managers a simple question: how many times does a single product BOM get reviewed before the product ships? 

The answers range from two to more than fifteen. Nobody says one.

Then I ask a second question, which produces much longer pauses. Who participates in each of those reviews, and what does each person actually check? At that point the conversation usually turns into a list of names, spreadsheets, and habits that exist nowhere except in the heads of two or three experienced people.

This is the gap I want to write about, because it explains something that has bothered me for twenty five years in this industry. Every company reviews BOMs. Almost no company has a repeatable process for it. And the reason is not laziness or missing software. It is that BOM review was never one thing to begin with.

The Trigger for a Review Is a Handoff.

Look at when reviews actually happen. Before long lead items get ordered. Before the prototype build kit is assembled. Before the package goes to the contract manufacturer. Before a change order is approved. Before a service kit is defined.

What those moments have in common – it is that responsibility is moving from one function to another. This is the handoff. 

A BOM gets reviewed every time somebody has to accept responsibility for data they did not create. Purchasing accepts an engineering BOM and becomes responsible for buying it. Manufacturing accepts a released BOM and becomes responsible for building it. Service accepts a shipped configuration and becomes responsible for supporting it for the next fifteen years. No sane professional accepts that kind of responsibility without checking the data first.

Once you see review as a handoff, the question changes. The useful question is not “is this BOM correct.” Correct against what? The useful question is “is this BOM good enough for the person who is about to take responsibility for it.”

That is a different question at every handoff, which is why the same product structure gets looked at repeatedly by people who never agree on what “ready” means.

Four Checkpoints, One BOM, Four Definitions of Ready

Companies name their checkpoints differently, and the number varies with product complexity. But underneath the local vocabulary, most reviews are asking one of four questions.

Can we design it? This is the engineering-internal review, somewhere between concept and design freeze. Participants are mechanical, electrical, and software engineers, sometimes a systems architect. They are checking structure completeness, missing parts, duplicate part numbers, wrong quantities, inconsistent units, naming conventions, and whether standard library parts were reused instead of reinvented. At this checkpoint nobody cares about approved suppliers or inventory. Those questions are not wrong, they are just premature.

Can we buy it? This is usually the first painful review, and it typically arrives with prototype readiness. Purchasing joins the conversation, and sometimes a supplier does too. The questions are about lead time, obsolescence, single-source risk, minimum order quantities, alternates, and cost against target. This is the checkpoint where a mechanically perfect design meets a twenty six week lead time on one connector, and where engineering discovers that a design which passes every internal check cannot actually be procured this quarter.

Can we build it? Manufacturing engineering, production, and quality take ownership here, through pilot build and into production release. Now the questions are about the manufacturing view of the structure, assembly sequence, reference designators, consumables and packaging that never appeared in the engineering BOM, work instructions, approved vendors, and the compliance documents that operations will be asked for later. This is where a BOM stops being an engineering artifact and becomes an operational one.

Can we change it? Every engineering change reopens all of the above, but with a different emphasis. The question is impact. What inventory is affected, what open work orders, what supplier commitments, what certifications, which customers, and what does the change cost across all of them. This checkpoint has the widest audience of all, and it is the one companies handle worst, because the people who need to weigh in are scattered across five departments.

Notice what does not change across these four. The product structure is nearly identical. A few properties get added, revisions advance, a manufacturing view appears. The data is roughly the same data.

What changes completely is the question being asked, and who is in the room to ask it. At the first checkpoint the reviewer might be one engineer. By the last one, the review touches purchasing, operations, quality, finance, service, suppliers, and occasionally customers. The later in the lifecycle, the more people depend on a BOM they had no part in creating.

One Size Doesn’t Fit All – Manufacturing Model Matter

The manufacturing model helps to decide which questions to ask. This is a second variable that makes universal BOM review impossible, and it has nothing to do with the lifecycle stage. It is how your company manufactures.

An ETO machine builder and a high volume electronics manufacturer both run something they call a BOM review. They share almost no criteria. If you have ever wondered why a best-practice BOM checklist from a conference talk felt useless when you got back to the office, this table is the reason.

This Is Why the Universal Checklist Never Worked

Put the two variables together. Review criteria depend on which handoff you are at, which role is asking, and how your company manufactures. That is a three-dimensional problem, and a checklist is a flat list.

So checklists fail in one of two ways. Either they are written generically enough to apply everywhere, in which case they catch nothing that mattered, or they are written specifically enough to be useful, in which case they encode one team’s knowledge at one checkpoint and quietly stop working when that engineer retires or the product line changes.

Most companies I talk to live with a mix of both. There is a system of record with an official version and a private spreadsheet on an engineer’s desktop that everybody actually depends on.

This is a problem worth solving, and it is not a problem of finding errors. It is a problem of encoding judgment.

A Check Card Is One Question, Made Repeatable

This is the design principle we created in OpenBOM BOM Review Agent, and it is why we built it as a set of check cards rather than a validation report.

A check card holds a specific set of questions or validation criteria (eg. Part Number standard, empty / not empty value / quantity ref designator check / circular reference / etc. etc. What information it needs, where that information comes from, how the answer is evaluated, and what should happen when the answer is wrong. When a card finds something, the finding becomes a reports attached to the review and an option to create a task attached to the data, date, and person responsible to fix it. All done in the context of the product structure, so the review moves from detection to resolution to confirmation without leaving the product data. I described that mechanism and the four cards we shipped in the BOM Review announcement, so I will not repeat it here.

What I want to say instead is what those four cards are and are not. Part number validation, property validation, quantity against reference designators, and structure loop detection all sit at the first checkpoint. They are engineering-internal checks, they apply to nearly every company, and that is exactly why we could build them ourselves. The new one coming at the end of this month is BOM Health – a special checkcard we defined to connect AI (Large Language Model) to the task (more about it soon).  We are also planning to have custom check cards. 

The cards that matter more are the ones we cannot write without you. Your lead time threshold and what happens when a part exceeds it. Your approved vendor policy and how a second source gets qualified. Your configuration rules. Your compliance evidence requirements. Your definition of what a service-ready BOM contains. Those are not generic validations. They are your company’s accumulated judgment about what “ready” means at a specific handoff, and today most of it is undocumented. This is something we want to learn together with you. Building those checkcards manually and then automatically is one of the goals of BOM Review agent. 

The card framework exists so that judgment can be written down, run automatically, and improved over time instead of walking out the door with the person who holds it.

The Answers Are Worth More Than the Checks

There is a longer term reason I care about this, and it connects to what we are building toward.

When a review finds a problem, the fix gets recorded. What almost never gets recorded is the reasoning. Why was this supplier rejected? Why engineering accepted a risk on a single-sourced part. Why manufacturing asked for a structure change. Six months later the data shows what was decided and gives no hint why, and the next team re-runs the same analysis to reach the same conclusion.

Every review produces this knowledge and nearly every company throws it away. That is what we mean by Product Memory, and why review sits in the middle of the Product Memory Flywheel between capture and flow. Capturing data is solved. Moving it downstream is solved. Preserving the reasoning that happened in between is not.

It also matters for AI, and not in the way most vendors are describing it. An AI agent asked to review a BOM has no idea which handoff you are at, which rules your company applies, or which risks were already accepted and closed. Give it that context and it becomes useful. Without it, it produces confident output that an experienced engineer will spend an hour disproving.

What I Am Asking For

BOM Review is available today to every OpenBOM customer, and I would like more companies to run it against real product data and tell us where it falls short.

Before you do, here is a fifteen minute exercise that is worth doing whether or not you ever use OpenBOM. Take your last three BOM reviews. For each one, write down what triggered it, who was in the room, and what each person was actually checking. Then mark which of those checks exist as a written rule, which live in a spreadsheet, and which live only in somebody’s head. In most companies the third category is the largest, and it is usually the most valuable.

If that exercise produces a list you recognize, I want to talk to you. We are working with a small group of companies as design partners on the next generation of check cards, and the goal is specific. Bring us one check that lives in someone’s head, and we will work with you to turn it into a card that runs automatically against your product data.

What we get from that is an understanding of how review actually works across different industries, product complexities, and manufacturing models. What you get is one piece of tribal knowledge made permanent, and early influence over a framework you will be using for years.

I am not trying to replace your review process. I am trying to learn what it really is.

Reach out to us at OpenBOM, or register for free and try BOM Review on your own data first.

Best, Oleg

Frequently Asked Questions

What triggers a BOM review? 

A BOM review is triggered whenever responsibility for the product data moves from one function to another. Common triggers include design freeze, prototype build, sourcing of long lead items, transfer to a contract manufacturer, production release, engineering change orders, and definition of service parts. The lifecycle stage determines who participates and what they check.

How many times should a BOM be reviewed? 

There is no single correct number. Most engineering and manufacturing companies review a product BOM between two and fifteen times before shipping, depending on product complexity, manufacturing model, and regulatory requirements. The useful measure is not frequency but whether each handoff has a defined set of questions and a defined owner.

Who should participate in a BOM review? 

Participation expands over the lifecycle. Early design reviews involve engineering disciplines only. Sourcing and prototype reviews add purchasing and sometimes suppliers. Production reviews add manufacturing engineering, quality, and operations. Change and service reviews can involve finance, compliance, field service, and customers.

Why do BOM review checklists fail? 

Review criteria depend on the lifecycle checkpoint, the role of the reviewer, and the company’s manufacturing model. A generic checklist is too broad to catch meaningful problems, while a company-specific checklist encodes one team’s knowledge and degrades as people and products change. Encoding checks as programmable, reusable cards addresses both failure modes.

How does the manufacturing model change BOM review? 

Engineer-to-order companies concentrate on design completeness and customer requirements. Configure-to-order companies focus on configuration rules and variant validity. High volume manufacturers prioritize cost, supplier stability, and second sourcing. Electronics companies focus on component lifecycle and obsolescence. Regulated industries emphasize traceability and certification evidence.

What is an OpenBOM check card? 

A check card is a reusable validation that performs one specific check against product data, reports findings in the context of the BOM, and connects those findings to comments and assigned tasks. OpenBOM ships cards for part number pattern validation, empty property detection, quantity against reference designator verification, and structure loop detection, and the framework can be extended using OpenBOM tools and APIs.

How can my company become a BOM Review design partner? OpenBOM is working with a small group of companies to develop company-specific and AI-enabled check cards. Design partners bring an existing validation rule, often one that currently exists only as tribal knowledge or a private spreadsheet, and work with OpenBOM to turn it into an automated check. Contact OpenBOM to discuss participation.