The Missing Human Layer in BOMing 

Most teams do not fail because they lack data.

They fail because the human part of the data is missing.

If you have been in hardware development long enough, you know the pattern. Someone opens a BOM and it looks “right.” The quantities add up. The part numbers exist. The CAD is released. Procurement can technically place an order. Manufacturing can technically build.

And yet everyone is still nervous.

Because the real question is never only “what parts are in the product?” The real question is “what do we know about these parts, what do we agree on, what is still uncertain, and who is responsible for closing the gaps?”

That human layer is usually scattered. Some of it lives in email threads. Some of it lives in a Slack conversation that nobody can find later. Some of it lives in meeting notes. A lot of it lives in someone’s head. When the project is small, teams survive on momentum and memory. As soon as the team grows, or suppliers get involved, or you start doing multiple builds, that approach becomes fragile.

A BOM without context is just a list.

A Digital BOM becomes valuable when it turns that list into a shared workspace where the structure of the product and the collaboration around it live together.

That is what I mean by the “human part of BOM connections.”

The Missing Layer Is Not Another File. It Is Shared Context

Most companies already have plenty of places to store information.

Engineering has CAD and folders. Sometimes there is PDM. Manufacturing has work instructions and routings. Procurement has vendor records, quotes, and lead times. Operations has ERP. Each area has a system that makes sense locally.

The problem shows up in the gaps between them.

Those gaps are not only technical. They are human:

• When a component changes, who needs to know and why?
• Is this substitute acceptable for performance, compliance, and reliability?
• Are we changing the part because it is better, or because it is available?
• Did we validate the supplier, or did we just place an order?
• Are we aligned on what “released” means for this build?

You can have accurate part numbers and still ship a product that is late, expensive, or hard to build, simply because decision context never got captured in a place the whole team can use.

This is where the idea of a BOM as a workspace becomes important.

A digital BOM is not only a nicer table. It is a structured piece of context that can carry human collaboration along with the data: comments, reviews, and tasks.

When you attach collaboration to the structure, something changes. Discussions stop floating around as disconnected messages. Decisions stop becoming folklore. Work stops depending on who happens to remember the last call.

Comments: Turning a BOM Into a Living Conversation

Let me start with the simplest and most underestimated tool: comments.

People often think of comments as “nice to have.” In practice, comments are where the product’s intent gets recorded. They are the difference between “we used this part” and “we used this part for a reason.”

Here is a very common scenario.

Engineering picked a regulator early in the design. The prototype worked. Then the team hits a sourcing issue. Procurement finds a substitute. The datasheet looks similar. The footprint is close. Someone says, “We can probably use it.”

Now you have a decision to make. This decision is not purely technical, and it is not purely purchasing. It is cross-functional. It needs context.

If that discussion happens in email, three things usually happen:

1. the thread gets long and confusing
2. the conclusion is not clear
3. the conclusion is hard to find later

If the same discussion happens as a comment attached to the exact BOM item, the conversation becomes anchored. Everyone sees what part the discussion is about. The decision is visible next to the data it affects. Months later, when the substitute comes up again, the reasoning is still there.

That is the human part: not “chat for chat’s sake,” but decision context attached to structure.

What I like about treating comments as part of BOM management is that it changes how teams behave. People become more willing to document “why,” because the effort is small and the benefit is immediate. It also reduces meetings whose only purpose is to reconstruct history.

A practical rule of thumb I use is: if a decision will matter again, it deserves a comment next to the BOM item.

Review: Turning Change Into Alignment

Comments help capture discussion. Reviews help create alignment.

If you think about how change actually happens in product development, it is rarely a single step. Even when you have an ECO process, the messy part is not the form. The messy part is getting the right people to look at the change, understand the impact, and respond in a timely way.

In many companies, “review” means sending a PDF around and waiting. Or it means a meeting where a few people talk and everyone else nods, and then later someone says, “Wait, I did not realize this was changing.”

A good review process does something very specific. It makes change visible and bounded.

It is a moment where the team says: this is what is changing, this is why, this is the impact, and this is what we are agreeing to.

That matters because “agreement” is the real currency of execution. Without agreement, people work in parallel with different assumptions. That is how you end up with engineering thinking the design is ready, procurement thinking parts are not approved, and manufacturing discovering issues during the build.

A BOM workspace review helps because it is attached to the same structured context. You are not reviewing an abstract document. You are reviewing the product structure, the items, and the changes that matter.

A simple example: engineering swaps a connector for a better locking mechanism. Technically it is an improvement. But the change impacts procurement, manufacturing, and service. A review makes those impacts visible and forces the team to align, not later, but at the moment when change is still cheap.

This is the human part again. The tool is not replacing people. It is helping people see the same thing at the same time.

Tasks: Turning Collaboration Into Execution

Comments create understanding. Reviews create alignment. Tasks create movement.

This is where many teams struggle. They have conversations, they even agree, and then things still slip because there is no clear ownership and no visible follow-through.

In reality, coordination is work. And work needs a home.

When tasks are connected to the BOM workspace, they stop being generic to-do items floating in a separate system. They become part of the product context.

A task like “validate alternate for R17” is different from “validate alternate.” It has a target, a reason, and a place. It also has a clear owner and status.

That structure matters because cross-functional work is full of invisible dependencies. Procurement might be waiting for engineering approval. Engineering might be waiting for a supplier datasheet. Manufacturing might be waiting for a drawing update. If tasks are not visible, the project feels like it is moving until suddenly it is not.

Check the video how the activities in procurement starts with the comments:

BOM Workspace as a Single Structured Context Piece

Let me explain the phrase “single structured context piece” in plain language.

A spreadsheet BOM is a representation. It is a snapshot of a list.

A BOM workspace is context. It is a living structure with relationships, revisions, and human collaboration attached to it.

When you keep the structure and the collaboration together, you get something powerful:

• the data is not only visible, it is understandable
• the product is not only defined, it is agreed upon
• changes are not only recorded, they are navigable

This is also where onboarding becomes easier. New people do not just inherit a list of parts. They inherit the reasoning: what was debated, what was decided, what is still open, and what the team considers done.

How to Start Without Changing Everything

If you want to adopt this approach, you do not need a big rollout.

Start with one product, one team, and one simple habit: attach collaboration to the product structure.

A practical path looks like this:

First, create a BOM view that everyone can access, including engineering and procurement. The goal is visibility.

Second, start using comments for decisions that will matter again. The goal is captured reasoning.

Third, use reviews at key moments of change, especially when change crosses boundaries between engineering, procurement, and manufacturing. The goal is alignment.

Fourth, use tasks to assign ownership and track follow-through for cross-functional work. The goal is execution.

Conclusion: The Human Multiplier of a Digital BOM

I have seen many teams focus on the “accuracy” part of a BOM. Accuracy is necessary, but it is not sufficient.

The biggest improvements come when the BOM becomes a shared workspace that captures the human part of product development: discussions, decisions, reviews, responsibilities, and progress.

That is what connects teams and that is what reduces late surprises. And that is what turns product data into a true workflow.

REGISTER FOR FREE to check how OpenBOM can help you to organize the data and connect human activities to this data. 

Best, Oleg