Why Your BOM Doesn’t Tell You What You Need to Know

If you work with CAD systems—SolidWorks, Altium, anything in that CAD family—you already know the reflex. Something doesn’t add up. A part looks off. A supplier asks a question you can’t immediately answer. BOM is a single source of truth where you can find the answer.

The strategy makes sense. The Bill of Materials is supposed to be the source of truth. It connects mechanical and electronic pieces, it link design to procurement, feeds manufacturing, and becomes the shared reference point across suppliers, contractors, and production teams. In a lot of ways, the BOM is the product definition.

So, you search for your BOM excel or PDM system and cannot find the answer (or you cannot find Excel 🙂 – a bit of a separate problem). But most teams I talked to, hit the same quiet realization eventually: the BOM spreadsheet is complete, and it’s still doesn’t provide all info as needed. 

Engineering BOM Structure vs Product Understanding: What a BOM Actually Tells You

A BOM does one thing extremely well – it gives you a list of items (aka structure). You open a SolidWorks assembly, export a BOM to a spreadsheet, and everything looks organized: Part A, Qty 4. Subassembly C containing D, E, F. Quantities are in place (most of the time) It’s logical. It feels simple and what you need. And for a moment, it creates real confidence, because it answers the most basic question: what is in the product?

But real engineering work rarely stops there.

Mechanical excel includes 10 switches, but electronic BOM includes 7 and 3 switches separately. Take a simple example – Cable Pull Switches ER6022-022NELSS – Qty 10.  Now imagine someone asks why you’re using this switch and not another one. Was there a cheaper option? Did you switch suppliers recently? Was this chosen by design, or was it changed by procurement six months ago? Is it still the approved part?

None of those answers are in the BOM (a simple Excel). Not because they’re unimportant – they’re often the most important things to know – but because the BOM Excel was never designed to hold them. Those answers live in a Slack thread, in someone’s inbox, in an ECO or engineering review that wasn’t documented, or in the head of the engineer who made the call. And as time passes, they fade.

The lack of understanding brings me to the conversation about Product Memory.

Product Memory Gap in BOM Management: Why Engineering Decisions Are Missing

There’s another layer to this that’s becoming harder to ignore as products get more complex. Modern products aren’t purely mechanical. They’re combinations of mechanical components, electronics, firmware, and software—but the way BOMs get managed hasn’t really caught up with that reality.

In a lot of companies, the mechanical BOM comes from CAD, the electronics BOM comes from ECAD, and the firmware lives somewhere else entirely. Eventually, everything gets exported into Excel. And when that happens, something subtle but significant is lost: the relationships between those domains disappear.

Consider an electrical switch. It’s a mechanical component—housing, actuator, physical assembly. It’s also an electronic component—it controls current, interacts with a circuit, affects system behavior. But once it lands in an Excel spreadsheet, it’s just another row. The multi-disciplinary nature of the product gets flattened into a list, and with it, an important layer of understanding quietly disappears.

Multi-Disciplinary BOM Challenges: Mechanical, Electrical, and Software Disconnected

Excel remains the most common destination for BOMs, and it’s easy to see why. It feels flexible, easy to own, and immediately familiar. But over time it introduces a different kind of complexity—one that’s not visible at first but is very real.

The clearest symptom is what happens to history. Changes happen constantly: parts get updated, suppliers change, alternatives get introduced. Excel can show you the latest value, but it can’t reliably tell you what changed, when it changed, or—most importantly—why it changed. Sometimes there are comments. Sometimes there are notes in the margin. But the actual reasoning almost always lives outside the file, in Slack or email or someone’s memory.

Then there’s the version problem. Engineering exports a BOM. Procurement modifies it. A supplier gets a copy. A contractor works from another version. A few weeks later there are four BOMs in circulation, each one slightly different. And eventually someone asks: “Is this the latest version?” That question alone is a signal. If the answer isn’t immediately obvious, the system is already broken.

Excel BOM Limitations: Lack of Change History, Version Control, and Context

Here’s how this plays out in practice. A supplier issue forces a change. The original part becomes unavailable, someone finds an alternative, the BOM gets updated in Excel. A note is added. A Slack message goes out. Maybe it’s mentioned in a meeting. Then time passes.

A few weeks later, another engineer looks at the BOM and sees the updated part. They ask: “Why are we using this one?” No one is completely sure. So the whole process starts again—checking CAD, searching messages, asking around, re-evaluating the decision. Sometimes the part gets changed again. Not because the previous choice was wrong, but because the reasoning behind it is gone.

When reasoning disappears, confidence disappears with it.

BOM Change Management Problems: Why Engineering Context Gets Lost Over Time

The real problem isn’t the BOM itself. The BOM is doing exactly what it was designed to do—it captures structure. But products aren’t just structures. They’re decisions, trade-offs, constraints, changes over time, and interactions across disciplines that don’t naturally talk to each other. None of that is visible in a traditional BOM.

The simplest way to put it: a BOM is a snapshot. It shows what the product looks like right now. It doesn’t show how it got there, what options were considered, what constraints shaped the outcome, what changed and why. Without that context, every new decision becomes harder. Teams compensate by recreating knowledge: repeating discussions, re-validating choices, rediscovering constraints. The cost doesn’t show up on a spreadsheet. It shows up in time, in inconsistency, and in risk.

Products aren’t just assembled—they’re decided into existence. Every part in a BOM is the result of a decision, made by someone, at a specific point in time, under specific constraints. The BOM captures the outcome. It doesn’t capture the thinking.

Conclusion: Product Memory Strategy and The Missing Layer Around the BOM

So what’s actually needed isn’t a better BOM or a more elaborate spreadsheet. It’s something built around the BOM—a way to capture why a part was selected, what alternatives were on the table, what changed and why, how mechanical, electrical, and software elements connect to each other, and who made the call.

A memory around the BOM. Because without that memory, the BOM is contextually incomplete, even when it’s structurally perfect.

Your BOM tells you what is built. It doesn’t tell you why it was built this way, how different systems connect, or how decisions evolved over time. In modern products, that’s exactly where most problems begin.

Want to talk about your engineering data management strategy? How to connect mechanical, electronics and software components together? 

REGISTER FOR FREE and check how OpenBOM can help you. 

Best, Oleg