What makes a BOM “good”? Is there such a thing at all?
The traditional perspective of any PLM or even Excel is simple – there are part numbers and follow the simple set of additional data – quantities are non-zero and units come from an allowed list, vendors and cost are in place, revision numbers mentioned. Drawings are attached and released. Purchased parts have an approved manufacturer. Run those checks, pass them all, and you have a BOM that is technically ready to be sent to a contractor or procurement department.
And then it brings problems anyway.
Rob Ferrone (officially known as “Product Data Plumber”), posted a comment this week that made me think deeply about BOM and quality. It came out of a longer conversation he has been having with Jos Voskuil about whether data quality and data governance are substance or hype, and it contains the most useful description of the BOM quality problem I have read in a long time.
Rob described an automotive OEM where an average product-offering change meant manually validating more than 500 BOM lines, updating over 100 of them, and pushing the change through more than five systems and ten departments. Across the programme, he estimates that consumed around 7,560 hours of cross-functional effort every month. Despite what he calls a genuinely world-class team, BOM and product-definition issues still caused production stoppages, and one stoppage costs roughly $2.5 million.
Then the passage menitoned by Rob that, in my view, should reframe how the industry talks about this:
The people were not the problem. The complexity, churn and volume had simply gone beyond what even very capable humans could reliably manage unaided.
BOM Errors Are Not a People Problem, They Are a Process Problem
BOM errors at scale are not caused by careless engineers. They are produced by a process that no individual participant can see the whole of. The detail that proves it in Rob’s example is not the hours, it is that the team was professional and dedicated to the work, but the process still failed.
It is tempting to read that example as a scale story instead. Too many lines, too few people, therefore automate. That reading is not wrong, but it is shallow, and it leads straight to the conclusion that BOM quality is a throughput problem you solve by making validation faster.
When capable people following a correct process produce defects at a predictable rate, the defect is not in the people and it is not in any individual step. It is in the structure of the work. Quality here is not a property of the file and it is not a property of the engineer who released it. It is a property of a process that spans five systems and ten departments, in which no single participant can see the whole thing at once.
That is the shift I want to talk about when I speak about BOM Review. We keep treating BOM quality as an attribute of a document (usually an Excel file), something you can inspect and certify before handoff. And because it is the Excel we are all familiar with, we can make it work.
But it is actually different. It is an attribute of a handoff, and handoffs cannot be inspected by one side of the team (e.g. a human that sends the data)
What Makes a BOM Release Ready Is Not Whether It Is Correct
The working definition we landed on internally is deliberately unglamorous. Release-ready means purchasing can source and planning can schedule without coming back to engineering.
Notice what that definition does. It refuses to describe quality in terms of the data at all. It describes quality in terms of whether the next team has to send it back.
This matters because every function reads the same structure looking for something different. Engineering asks whether the design definition is right. Manufacturing asks whether it can be built. Supply chain asks whether it can be sourced. Quality asks whether it is compliant and traceable. Service asks whether it reflects what is actually installed in the field. Can we design it, can we buy it, can we build it, can we change it. Same BOM, five different verdicts, and a BOM that satisfies one reader can be useless to the next.
Which is why a BOM with every mandatory field populated can still fail. The purchased component has no approved manufacturer. The drawing link resolves to the wrong revision. The quantity is right but the unit is not. Nobody flagged the long-lead item until the critical path was already committed. PLM and ERP disagree about the description. The part was valid last quarter and went end-of-life since. Or the simplest failure of all, everyone can see the problem and nobody knows whose problem it is.
On top of that, keep in mind that parts of the problem is that the information “sitting in the BOM” usually located in multiple databases, systems and often departments. How to coordinate the data and people is a big question.
BOM Data Quality Has Six Dimensions, and the Expensive Ones Come Last
In the same thread, Rob shared a framework I found genuinely clarifying. Credit where it belongs: the graphic is courtesy of Marcus Youden and Quick Release_, and it lays out six dimensions of data quality that increase in both business impact and difficulty of measurement.
The first is completeness, meaning whether required fields are filled at all. Then validity, whether values conform to expected formats, rules and domains. Then integrity, whether the relationships between records actually hold. These three are the ones most organizations think of when they say data quality, and they are the easy end of the scale.
The harder three come after. Consistency asks whether the data agrees with itself across systems and domains. Timeliness asks whether it was updated when it needed to be. Accuracy asks the hardest question of all, whether the data reflects real-world truth.
Rob’s KPI examples were general data-quality examples, addresses conforming to ISO 3166 country codes, asset locations matching GPS coordinates from service visits. Translating them into product structure is where it gets interesting, because a BOM is a graph and every dimension gets harder when you move from records to relationships.
Completeness stops being about a field on a row and becomes a question about whether the required properties, files, sources and classifications are present across an entire multilevel structure. Validity has to hold not just per line but across a hierarchy, which is how you get assemblies that mix inches and millimeters without anyone violating a single field-level rule. Integrity means every child exists in the parts master, is not obsolete, and that the structure contains no duplicates, orphans or circular references. Consistency means engineering, purchasing, ERP and supplier records agree about the same item. Timeliness means the structure changed when the change became effective, not when someone got to it. And accuracy means the BOM describes the product that will actually be purchased, manufactured and delivered, which is the only dimension the shop floor experiences directly.
The reason the top of that scale is where the money is: completeness failures get caught by the next person who opens the file. Accuracy failures get caught by the line.
BOM Validation Finds Errors, It Does Not Supply Judgment
Finding the error was never the hard part of BOM quality. Deciding which errors matter was. A validation engine can flag every deviation from a rule, but it cannot rank those flags by consequence, and consequence is what determines whether a BOM is safe to release.
Rob described the Product Data Professional role this way. Owning BOM quality meant proactively preventing problems, reactively fixing them, and
knowing the difference between what was OK for now, what had to be right now, and which upstream values would fail downstream and create $$$$$ problems.
It is not a description of validation. It is a description of judgment.
A rule engine can tell you that lead time is blank on 40 buy lines. It cannot tell you that 38 of them are commodity fasteners nobody will ever wait for and 2 of them are the parts that will decide whether the program ships. That distinction is not in the data. It was in someone’s head, built over years of watching which blanks turned into stoppages.
And this is the structural problem underneath the staffing one. When companies eliminated the Product Data Professional role, they did not eliminate the need for that judgment. They eliminated the place it was stored. The rules could be written down. The exceptions, the reasoning, the sense of which blank field is cosmetic and which one is expensive, all of that walked out with the person.
So when a validation result gets recorded as pass or fail, we lose exactly the thing that made the role valuable. The useful artifact is not the verdict. It is the verdict plus why the exception was accepted, plus who accepted it, plus what has to be true before release. That record is what lets the next person, or the next system, make the same call without rebuilding the intuition from scratch.
A checklist cannot hold that. It has nowhere to put it.
What OpenBOM BOM Review Checks Today
This is why we built BOM Review as a collaborative agent rather than a validation report.
The first release implements four families of check cards, and I want to be precise about the scope because the gap between vision and shipped software is where vendor credibility goes to die. Today BOM Review checks Part Number and Identity, Property, Quantity, and Structure. That covers the identity of every item, whether required properties are populated and meaningful, whether quantities and units make sense, and whether the structure itself is sound, with no duplicates, orphans or circular references.
That is the completeness, validity and integrity end of the scale. It is the foundation, not the finished picture.
Two things make it different from running a rule set. The first is that it operates on a connected product model rather than an uploaded file, so a check can reason about relationships, revisions, attached documents and change history instead of scanning rows. The second is that a check result is not a line in a report. It is an object the team works on together.
That means a finding can move through an actual loop:
- Review the issue in the context of the BOM, not in a separate spreadsheet.
- Assign it to whoever owns that class of problem.
- Discuss the context, which is where the judgment lives.
- Record the decision, including an accepted exception with its rationale.
- Correct the BOM.
- Re-run the check.
Step 4 is the one I would defend hardest. Recording an accepted exception with a name and a reason attached is how the organization stops relying on one person’s memory. And step 6 is what turns validation from a release ceremony into something continuous, because a BOM that passed last Tuesday tells you nothing about a BOM that has changed twice since.
A Single BOM Quality Score Hides the Failures That Matter
There is an obvious temptation to roll all of this into a single BOM Quality Score. I think that is a mistake, and I want to say so before someone asks us to build it.
A composite score at 94% feels reassuring and tells you nothing about whether the 6% is trailing zeros in descriptions or the two long-lead items with no supplier engaged. Averaging across dimensions hides precisely the failures that have the highest business impact, because those failures are rare by definition.
Separate readiness indicators survive that problem better. Completeness against required properties. Sourcing readiness across buy lines. Count of release-blocking issues. Long-lead exposure. Cross-system inconsistencies. And the one metric I would put in front of any executive who asks whether this is working: bounce-back rate, meaning post-release changes caused by missing or wrong data. That number is the direct measurement of whether the next team had to send it back.
On top of those, three statuses do more work than any score. Ready, meaning downstream teams can proceed. Ready with exceptions, meaning known risks have owners and approved dispositions. Not ready, meaning blocking information or relationships are missing. The middle status is the honest one, and most release decisions in real companies live there whether or not the system admits it.
The BOM Quality Checks We Have Not Built Yet
Identity, properties, quantities and structure are the first layer of BOM quality, not the whole of it. The checks that catch the expensive failures sit above them, and most of those are still ahead of us.
The next layer is the checks that discrete manufacturers actually run once the basics hold. Long-lead flags against a threshold with supplier engagement confirmed. Obsolescence and end-of-life indicators. Approved alternates and substitutes visible to purchasing with their rules attached. Category-specific requirements, which look completely different for a fastener, a sheet metal part and a PCBA. Beyond that sits the enterprise layer, effectivity on lines subject to phased changes, variant and option filtering, supplier quality status enforced when someone picks from the AML, country of origin and tariff codes, lifecycle coherence so a child cannot sit at higher maturity than its parent.
None of that is in the product today. I am describing the roadmap, not the release notes.
What I am much less certain about is the part that cannot be built generically. Every company I talk to has rules that are specific to their products, their industry, their customers, and often to one painful failure that happened four years ago. Those rules are the ones that catch the expensive problems, and they are exactly the ones a standard check library will never contain.
That is why BOM Review ships with a design partner program for custom AI-enabled check cards. If you have rules you enforce today through tribal knowledge, review meetings or a spreadsheet somebody maintains on the side, those are the rules I want to see. We will build them as check cards with you.
Rob’s conclusion was that AI-powered BOM validation was the only remaining option at that scale. I would put it slightly differently. Validation was never the missing piece. Companies have had validation rules for decades and still stopped lines. What went missing was the capacity to apply judgment continuously, at the volume and speed that modern product change actually moves, and to keep a record of that judgment when the person who made it moves on.
The BOM does not need to be inspected harder. It needs to be reviewed continuously, by the people who will have to live with it, with enough context that the decisions survive.
Are you interested in learning more about BOM Review and how we can work together?
Contact us and we would be happy to talk about your BOMs.
Best, Oleg
FAQ
What is BOM quality?
BOM quality is the degree to which a bill of materials can be used by downstream teams without being sent back to engineering. It is broader than data completeness. A BOM can have every mandatory field populated and still fail if purchasing cannot source it, planning cannot schedule it, or manufacturing cannot build it.
What does release-ready mean for a BOM?
Release-ready means purchasing can source and planning can schedule without coming back to engineering. The definition is deliberately expressed in terms of downstream usability rather than field-level completeness, because the cost of a bad BOM is paid downstream.
What are the dimensions of data quality that apply to a BOM?
Six dimensions are commonly used: completeness, validity, integrity, consistency, timeliness and accuracy. They increase in both business impact and difficulty of measurement. Completeness failures are usually caught by the next person who opens the file. Accuracy failures are caught on the production line.
What does OpenBOM BOM Review check today?
The first release implements four families of check cards covering Part Number and Identity, Property, Quantity, and Structure. These address item identity, whether required properties are populated, whether quantities and units are valid, and whether the product structure is free of duplicates, orphans and circular references.
Why is a BOM quality checklist not enough?
A checklist produces a verdict but has nowhere to store the reasoning behind it. Real BOM decisions involve judgment about what is acceptable for now, what must be fixed immediately, and which values will cause expensive downstream failures. A review process records that judgment, assigns ownership, and re-runs as the BOM changes.
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
