Back to profile

The BOM Is Not a List - It's a Graph

And once you see it, you cannot unsee it.

For a long time, I thought my frustration with PDM systems was about workflows. Too many approvals. Too many clicks. Too many states. But the deeper I went, the more I realized something else was fundamentally off. It was not the UI. It was not even the process. It was the BOM itself.

The Lie We All Accept: "Here Is the BOM"

In most organizations, when someone says "the BOM," what they really mean is an Excel sheet, a flattened table, a report generated from somewhere else. Rows and columns. Part number. Quantity. Maybe a reference designator if you are lucky. It looks neat. It feels concrete. And it is wildly misleading.

Because that thing we call "the BOM" is just a snapshot of something much richer.

What a BOM Actually Is (When You Think About It)

If you step back and ignore how tools represent it, a BOM is really a hierarchy with alternatives, conditional branches, lifecycle states, sourcing constraints, and manufacturing dependencies.

In other words: a BOM is a graph. Not a list. Not a tree. A graph.

And that distinction changes everything.

The First "Oh..." Moment

This hit me while thinking about variants. A simple example:

In Excel, that becomes multiple BOMs, comments, notes, manual filters. But conceptually? It is just a graph with conditions. Same product. Different paths. The list breaks. The graph holds.

Why Trees Are Not Enough Either

Some systems proudly say: "We support multi-level BOMs." That is good. But it is not sufficient. Trees assume one parent, one path, and a clean hierarchy. Real products do not behave like that.

The same component might appear in multiple assemblies, behave differently in different contexts, and have different alternates depending on usage. That is not a tree. That is a graph with shared nodes and contextual edges.

This Is Where Traditional PDMs Start to Crack

Most legacy PDM and PLM systems are built on assumptions like:

That works until scale. Then you get duplicated BOMs, divergence, "do not touch this one," and tribal knowledge again. The system technically works. But humans stop trusting it.

The Hidden Cost of Flattening

Flattening a BOM is convenient. It is also destructive. When you flatten, you lose why a part exists, you lose what it is connected to, and you lose what depends on it.

So when someone asks, "If we change this part, what breaks?" the system cannot answer. A meeting does. That is not a tooling problem. That is a data model problem.

Why Change Impact Analysis Is So Painful

Here is a simple test I started using mentally: can the system explain a change without a meeting? In most cases, the answer is no. Because explaining impact requires traversing relationships, understanding variants, knowing lifecycle states, and mapping manufacturing and sourcing constraints. That is graph traversal. Not table lookup.

Scale Makes This Impossible to Ignore

This becomes painfully obvious at scale. When BOMs reach 50k parts, 100k parts, or millions of nodes in large systems, flattened views do not just become slow. They become meaningless. You cannot reason about a list that big. But you can reason about a graph if the system is built for it.

This is where my thinking started drifting away from "better UI" toward "different foundations."

Why This Matters Beyond PDM

This is not just about data elegance. Once you treat the BOM as a graph, AI can reason over it, change impact becomes computable, variants become first-class, manufacturing feedback can attach to nodes, and repair data can flow backward.

Suddenly, BOMs stop being documentation. They become infrastructure. That is a big shift.

A Quiet Realization

At some point, I caught myself thinking: if the BOM is the graph of the physical world, then PDM is really a graph system pretending to be a file vault. That explained so much: why extensions feel bolted on, why AI feels "on top" instead of inside, why performance hacks pile up, why people export to Excel anyway. The core abstraction is wrong.

This Is Where the OS Analogy Comes Back

Operating systems do not treat processes as lists. They treat them as states, relationships, dependencies, and events. Once you see the BOM that way, it stops being "just engineering data." It becomes the nervous system of the product. And that is when PDM quietly starts morphing into something bigger.

Why This Post Ends Here

I am deliberately stopping short of solutions. Because the point of this post is not "Here is how to build a graph database." It is this: if you model the wrong thing, no amount of workflow or AI will save you.

In the next post, I want to talk about what happens when you do get this right and you introduce AI not as a chatbot, but as something that can actually reason over this graph. That is where things get interesting.