Twenty Five Years Inside Bills Of Materials, And The Same Errors Are Still There

I had a conversation with Rob Ferrone earlier this week and we decided to publish it.

Rob spent 25 years working inside bills of materials, long before anyone in his world used the words PLM or digital thread, and he built a company of product data professionals whose job was to be custodians of BOM quality. 

I showed him the work we did with BOM Review – we planned the discussion about BOM validation and quality. We ended up in a far better place exploring the connection between BOM Review and Product Memory Flywheel. 

The video is below (scroll down to watch). Three moments from it have stayed with me, and I want to share them with you. 

Rob Went Back To A Customer After Fifteen Years And Found The Same Errors

Around 2019, Rob’s team was short staffed and he went back into project work himself, with a customer he had known for more than fifteen years.

He expected to find a different company. Instead he found the same problems, the same errors, the same issues they had been dealing with fifteen years earlier. Some of the systems had changed. The problems had not.

I asked him whether companies record how they solved BOM quality problems. His answer was that companies sometimes capture change reasons for product changes, that a part was changed because it made a noise or because it did not fit. But he does not see companies tracking the reasons for BOM changes and BOM errors. Lessons learned, in his words, are notoriously badly captured.

His explanation of why is the part I keep returning to, and it is not about laziness. Success in product development is measured on launching on time, at cost, at quality. So attention goes to the fires in front of you, for the product shipping right now. Nobody is measured on whether the next program inherits what this one learned.

Adding More Reviewers Is Extra Capacity, Not Extra Intelligence

There is a standard corporate response when BOM quality causes a visible failure. The company adds rigor. More people, more checks, more attention, more validation gates.

Rob’s assessment was simple – it is not smart, it is just extra capacity, and it is expensive.

I have watched companies do exactly this and I had never heard it named so precisely. The organization has a hard time to ask why that class of error occurred, and never builds the answer into the way it works with the data. So the next program hires the same rigor again, from scratch, and pays for it again. 

Extra capacity does not compound. Intelligence does. Almost every company chooses capacity, because capacity can be approved in a budget cycle and intelligence cannot.

This is an exact place for BOM Review intelligence to show up. 

Product Memory Might Not Be Only About Design Decisions and Change Records 

The third moment is the one that reorganized how I explain my own work.

I have been writing about Product Memory for the last year, and the engineering community always recognized that it (probably) applies to design decisions – material, tolerance, shape, size, etc. Rob acknowledged that this is how he had always translated it, but I missed the point and it was the aha moment for both of us – I didn’t communicate it precisely and engineering mind associated “product” with the “design”  .

Then we stopped, and realized that the same logic applies to the bill of materials and everything that related to that.

Why did this error occur? Why did someone enter this weight? Why was this field left blank? Why is the weight entered as 999? Why was this variant missed? Why do we put a negative quantity? Why was a specific supplier was chosen? 

Sitting with that afterwards, I think we identified something I had been circling without naming. Design intent is the version of Product Memory everyone thinks first about, and it is also the version that is easy to think about because it comes from the nature of engineering activities. BOM memory is less glamorous and far more tractable, because the reasoning is generated at a specific moment, about a specific value, by a specific person, in a system that could hold it.

Which raises the question I will hold my answer to until the next article. If the bill of materials generates memory continuously each time the team of engineers, production planners, procurement and supply chain managers work with it, and the reasoning is right there at the moment of correction, how valuable will it be to keep it over time? I will discuss it in the next article. 

Watch The Conversation

We covered more than fits here, including where validation belongs in a program, why an empty field is often not an error, and a use case for data migration that Rob raised and I had not considered.

Chapters

• Rob’s background and what a product data professional actually does
• Walking through BOM Review, check cards and findings
• The customer he returned to after fifteen years
• Why extra rigor is capacity rather than intelligence
• Design memory versus BOM memory
• Where validation belongs, and why gateway reviews are the wrong shape
• BOM Review for data migration

Rob pointed out during the recording that he is not sponsored by OpenBOM. I appreciated that, and I would rather publish a conversation with someone who will tell me when what we do doesn’t make sense. Open industry conversation is the best way to find what customers need. 

If you have not read the foundation article on how BOM Review works, it is linked below and it is the better starting point. And we are looking for design partners, so if BOM quality is quietly costing your organization, get in touch.

About Rob Ferrone

Rob Ferrone Rob has spent 25+ years helping the world’s manufacturers solve complex product data challenges. After founding, scaling and selling a leading product data consultancy, he is now tackling the biggest cause of transformation failure: the human side.

ReachR , a new venture Rob has started uses AI to understand every individual at scale, connecting strategy with the people who must deliver it, leading to better solution design, faster adoption and more successful transformations. The website is www.discoverreachr.com. 

Here is my conclusions

Three things I am taking from the conversation with Rob.

The recurrence is the signal. When the same errors repeat for a decade and multiple generations of systems, the tooling is not the variable. What happens is the absence of retained knowledge, and every new system inherits that lack of knowledge intact.

Capacity is the simple answer, but not a good solution. Adding more people to check BOM is an  immediate decision. Building the reasoning into how the data is handled is not a simple task, so it does not get proposed, so it does not happen.

The boring part of capturing all BOM conversations (I love how Rob calls it “BOMversations”) is super useful. While industry spent years arguing for capturing design intent. Rob’s reframe suggests the bill of materials is where the concept becomes practical first, because that is where reasoning is produced on a schedule rather than in flashes.

Register for free to check how OpenBOM can help you. 

Contact us to become a design partner and to work together on BOM Review. 

Best, Oleg