Is Your BOM Accurate? That May Be the Wrong Question.

Building products is a complex process. One topic that comes very often across what we do at OpenBOM is information reconciliation. Here is how it usually happens… 

A few weeks before a prototype build, someone runs the list one last time and finds that a handful of components can’t be ordered. Not the wrong parts. Not bad part numbers. Just parts that nobody can actually buy under production conditions. The build slips. Somebody pays for expedited shipping. An engineer spends two days finding an alternate.

Or the opposite version, which is quieter and more common than anyone admits. The unit gets built, it works, it ships, and there are components left in the bin. Nobody investigates. The parts get put back on the shelf.

In both cases, if you go back afterwards and audit the BOM, you will usually find that the BOM was fine.

That is the part I keep coming back to. Manufacturing companies put enormous effort into making product data correct. Part numbers, quantities, units of measure, required properties, valid structures, reference designators, supplier and manufacturer information. These are real problems and they are worth solving. But after a number of conversations with people who have worked with BOMs in the industry for many years, I have started to think we may be asking the wrong question.

Instead of asking is the BOM correct, the more useful question may be: does all the information required to build this product agree?

Those are not the same question. A BOM can pass every validation rule you can write against it and still describe a product you are not ready to build.

Three questions

Let me put the data model aside for a moment and ask three questions that a plant manager or a program lead would recognize without any explanation.

Are we building what engineering actually designed?

A component exists in the mechanical assembly or the electronic schematic and never makes it into the released BOM. Or it makes it in, but pointing at a different revision. The BOM itself looks entirely valid — nothing about it, examined on its own, would trip a validation rule. But the design and the BOM have quietly stopped describing the same product.

You can turn this into a technical discussion about CAD-to-BOM synchronization very quickly. The business question underneath it is much simpler, and it is the one that gets asked in the room when a prototype doesn’t go together.

Can we source every part we need?

The BOM is structurally correct and complete, and several components have no approved supplier. A part is obsolete. Purchasing has nothing associated with a newly released item. Engineering selected something that procurement cannot buy under the conditions production requires.

Nobody discovers this while looking at the BOM. It gets discovered when someone tries to place an order.

Will the parts be there when we build?

Having a supplier isn’t sufficient. The part has to be orderable, the purchasing system has to recognize it, lead times have to fit the build schedule, MRP needs the right demand at the right location at the right time, and inventory has to reflect reality. You can have a correct engineering BOM, approved suppliers, and valid purchase information, and still find out a week before the build that a critical component is four weeks out.

Different problems, same root cause

Those three questions look like they belong to three different departments, and that is exactly how most companies treat them. The first is an engineering problem. The second belongs to procurement. The third is planning, or ERP, or both. Each function investigates its own version, fixes its own version, and adds its own checkpoint.

What makes this worth a second look is that each of those departments is usually right. Engineering’s data is correct. Procurement’s data is correct. Planning’s data is correct. The failure isn’t inside any one of them.

Information describing the same physical product lives across multiple systems and multiple organizations, and those representations have to be continuously reconciled as the product changes. Every one of the three questions above is a different symptom of that single condition.

I have started calling this problem by a name, so let me define it plainly. Manufacturing information reconciliation is the ongoing work of verifying that all the information required to build a product — design, bill of materials, bill of process, work instructions, procurement, ERP, and MRP — agrees, as the product and its data continuously change. It is not a system or a module. It is a condition that has to be maintained across systems, and the BOM sits in the middle of it.

This also suggests a useful split in how we think about BOM data quality. Some problems are intrinsic — missing fields, inconsistent units, quantities that don’t add up, a reference designator count that doesn’t match, an invalid structure. You can find all of these by analyzing the BOM by itself, and this is where most of the tooling and most of the discussion has gone. The other category is cross-functional — the BOM is internally valid and disagrees with something maintained elsewhere. These are harder to detect, more expensive when missed, and considerably less well served.

The BOM at the center

Think about the core information environments involved in building a complex product.

There is design — mechanical CAD, ECAD, schematics, increasingly software-defined elements. There is the bill of materials, the structured definition of what the product contains. There is the bill of process, how the company intends to manufacture it. There are process sheets and work instructions, what a person at a specific station actually does. There is procurement — sourcing decisions, suppliers, pricing, delivery commitments. There is ERP, the transactional environment where parts get ordered, received, and financially controlled. And there is MRP and production planning, determining what has to be available, where, and when.

[DIAGRAM: BOM at the center of the seven systems]

Each of these systems can be individually correct. The question is whether they agree.

Every link on that diagram is a reconciliation, not a handoff. The BOM says part A and CAD says part B. Procurement has no source for part C. ERP doesn’t recognize part D. MRP expects part E at a different plant. The work instruction still shows the previous revision of part F.

And eventually all of these information streams meet the same unforgiving event: someone has to physically build the product. The product does not care which enterprise application was technically correct.

Doesn’t a single source of truth solve this?

For decades the standard answer has been to consolidate. Put everything in one integrated environment and the reconciliation problem goes away.

Manufacturing companies rarely operate that way, and I am not convinced they ever will. Mechanical engineers need CAD. Electrical engineers need ECAD. Manufacturing engineers need process planning tools. Supply chain needs sourcing systems. Operations runs on ERP and MRP. Plants run work instructions, MES, spreadsheets, and a long tail of specialized applications that exist because somebody needed something the platform didn’t do.

Even inside a single vendor’s portfolio, this information lives in different modules, different data models, and different organizational processes. Buying from one company does not make two applications agree with each other. It makes the integration somebody else’s product decision.

So the practical question isn’t where is the single source of truth. It is: how do we know the sources of information required to build this product are aligned enough to proceed?

From correctness to readiness

Which leads me to a different way of framing BOM data quality altogether. Maybe the measure isn’t whether the BOM is perfect. Maybe it is readiness.

Are we ready for a prototype build? Ready to hand the design to manufacturing? Ready to commit to long-lead components? Ready to release this configuration? Ready to start production?

Every one of those decisions draws on information from multiple functions, and every one of them can fail because of a disconnect nobody saw early enough. That is what makes this category so expensive. The disconnect is created upstream and discovered downstream — a missing supplier surfaces at purchasing, a design mismatch surfaces during assembly, a wrong revision surfaces on the floor, a lead time surfaces when the build is already on the schedule. By the time it is visible, the information problem has already become a business problem: delay, expedite cost, rework, scrap, or a missed commitment.

Why look at this now?

None of this is new. Manufacturers have been building integrations, writing validation rules, running reports, and doing manual reviews for decades. The reason I think it is worth reopening is that the economics may be changing.

Reconciliation has historically required agreement before it could start. Two systems could only be compared once somebody defined how their data maps, which meant a schema, a project, and a budget for every pair. That is why most of these efforts stall — the integration cost scales with the number of connections, and the connections keep changing.

AI systems are becoming genuinely capable of comparing heterogeneous representations of the same thing without that agreement being defined in advance: interpreting context, recognizing that two differently structured records describe one component, flagging what looks inconsistent, and explaining why. If that holds up in practice, it changes what is worth attempting. Instead of hard-coding every relationship between every pair of systems, it may be possible to continuously examine product information, surface inconsistencies, bring the right people into the conversation, and keep a record of what was decided.

I don’t think anyone knows yet what the right solution looks like. That is precisely why I think the problem is worth exploring in the open rather than behind a product.

What I’d like to learn from you

I am spending time right now trying to understand how manufacturing companies actually experience these cross-functional information problems — not what the software category says, what happens in the building.

So if you work in engineering, manufacturing, PLM, procurement, supply chain, or enterprise architecture, I would like to hear from you. Here is the question, and I have deliberately made it easy to answer.

Which of these hurts most in your organization?

1. The released BOM doesn’t always match what engineering designed.
2. Some parts aren’t fully sourced when engineering releases the product.
3. Required parts don’t arrive when a prototype or production build needs them.
4. Manufacturing processes or work instructions don’t match the released product definition.
5. Engineering/BOM information and ERP/MRP information drift out of sync.
6. Something else entirely — this is the answer I am most interested in.

Reply with a number. That’s it. If you have thirty more seconds, add where you usually find out — engineering review, sourcing, ordering, prototype assembly, production planning, or the factory floor. In my experience, where a company discovers the problem tells you more than which problem it is.

My working hypothesis is that a set of problems we currently treat as separate engineering, PLM, procurement, ERP, and manufacturing issues are really one problem wearing different clothes: keeping product information aligned across functions as the product changes.

I would like to find out whether that hypothesis survives contact with people who live it. To be clear about what this is: this is research into a problem space. It is separate from anything we have built, and there is nothing in this space to show you yet — which is exactly why the conversation is worth having now, while the questions are still open.

This is the first article in a series on manufacturing information reconciliation. Next: what “ready for the prototype build” actually means, and why nobody can answer it from a single system.

If the questions I’m asking resonate, please contact me directly to discuss. 

Best, Oleg