BOM Review: The Missing Space Before the Change

In the last few posts, I started with the limits of PDM and file-based workflows, then gradually moved toward collaborative BOM review. That progression was not accidental. It reflects a simple realization: managing files and even managing data changes is not the same as managing decisions.

I’ve been circling around the same problem from different angles. First, I wrote about the limits of traditional PDM and file-based approaches, and why managing files alone is no longer enough when products are defined by data, not documents. Then I introduced the idea of collaborative BOM review, focusing on the need for better discussion, chat, and task management around product structures. Finally, I connected those ideas to a broader pattern I see everywhere: when systems fail to support real workflows, the work quietly leaks into spreadsheets – Why does PLM leak to Excel.  

Taken together, these discussions point to something deeper than a feature gap. They point to a missing phase in how we support product development and related engineering and manufacturing work. This is not a missing button or workflow, but a missing space where decisions are formed before they become formal changes and records in PLM, ERP, and other systems of records.

In this article I want to talk about that space and also explain why I think, a growing AI tools are making this space critical these days. 

Decisions Before the System

When we talk about PLM, change management, or digital thread initiatives, the conversation usually assumes that important work happens inside formal systems. We focus on approvals, traceability, revisions, and governance, as if the most meaningful decisions naturally occur there. But when I look at real engineering and manufacturing teams, that is not what I see. The most important decisions happen earlier, when ideas are still tentative and when the cost of being wrong is still low.

This early phase is messy by nature. People explore alternatives, challenge assumptions, and discover constraints they did not initially anticipate. A simple design change quickly turns into a manufacturing discussion, a sourcing concern, a cost trade-off, or a serviceability question. None of this fits neatly into a linear workflow, and none of it feels appropriate to commit into a system of record too early.

This is not because teams are undisciplined. It is because uncertainty is a real and necessary part of decision-making.

The space no system truly owns

Between informal discussion and formal change, there is a space that no system truly owns. It is the space where someone proposes a change to the BOM, another person questions feasibility, and a third realizes that the implications are broader than expected. It is also the space where multiple options coexist, sometimes for weeks, while the team learns which constraints matter most.

Formal systems struggle with this phase because they are designed to treat change as something that should already be understood. PLM systems assume intent is clear enough to be governed. ERP systems assume decisions are ready to be executed. PDM systems assume files represent a stable design state. None of them are designed to host uncertainty itself.

So teams invent their own solution. They copy BOMs into spreadsheets, annotate screenshots, and hold meetings where decisions are made but not preserved. Later, someone goes back and “documents” the outcome in PLM, often without the context that led to it. The system captures what changed, but not why it changed.

This is the structural reason behind what I’ve described elsewhere as “Excel leaks.” Work does not leak into Excel because people prefer spreadsheets. It leaks because Excel offers a safe, informal space to think, explore, and be wrong without consequences.

Why Formal Systems Come Too Early

It is tempting to conclude that PLM should simply do a better job supporting early decisions. But this misses an important point. Early decision-making and formal change management are fundamentally different modes of work, and forcing them into the same structures creates friction.

Early BOM changes are provisional. Many will never survive. Others will be explored in parallel, compared, and discarded. If every one of these ideas becomes a formal object, teams pay a high cleanup cost, both technically and psychologically. People become cautious. They stop experimenting. They move the real work outside the system.

Spreadsheets thrive in this environment because they impose almost no consequences. They allow people to explore without committing. But they also fragment context, disconnect discussions from product data, and make it hard to converge toward a decision that can be confidently released.

What is missing is not a more powerful PLM screen or a better spreadsheet import. What is missing is a space intentionally designed for this phase of work.

The Decision Sandbox

A decision sandbox is not a draft BOM and not an unreleased revision. It is a temporary, collaborative workspace where the goal is understanding rather than correctness. In this space, nothing is final, and nothing is “wrong” yet. Ideas are allowed to exist long enough to be evaluated, challenged, and either refined or rejected.

This distinction matters because it changes how people behave. When exploration is safe, teams surface problems earlier. They ask harder questions. They involve the right disciplines sooner. Instead of protecting the system of record from uncertainty, the decision sandbox absorbs that uncertainty on purpose.

By anchoring discussion directly to the BOM structure, the sandbox keeps conversations grounded. Instead of abstract debates in meetings or scattered comments in email threads, the discussion stays connected to the product itself. Rationale is captured while it still exists, not reconstructed later.

Editing for Decisions, Not Data

This is where terminology often causes confusion. Collaborative BOM editing, in this context, is not about letting everyone freely modify released data. It is about making decision-making visible.

Teams are not editing the BOM for the sake of maintaining an accurate parts list. They are using the BOM as a shared reference to align their understanding of the product. They explore what happens if a part changes, what constraints emerge, and how different disciplines interpret the impact. Comments, redlines, and annotations are not documentation artifacts; they are expressions of thinking.

This is why a collaborative BOM review must support the natural flow of decision-making. Proposals lead to questions, questions lead to refinement, and refinement leads to convergence. If that flow is broken, people will revert to tools that allow them to think freely, even if those tools are disconnected from the product data itself.

Products Are Multidisciplinary

Product decisions are rarely owned by a single discipline, even when tools suggest otherwise. A BOM may originate in engineering, but it quickly becomes a shared concern for manufacturing, supply chain, quality, cost, and service. Each discipline brings valid constraints, and most disagreements are not about correctness but about priorities.

Traditional systems tend to impose a single viewpoint, often engineering-centric, and ask everyone else to adapt. Meetings partially compensate for this by allowing perspectives to collide, but meetings do not preserve context or translate naturally into structured change.

A decision sandbox built around BOM review offers a better alternative. It provides a shared object and a shared conversation where different perspectives can coexist without forcing premature agreement. Alignment emerges gradually, and when it does, it is stronger.

Parallel What-If Is Normal

Another reality that systems often ignore is that teams explore multiple futures at the same time. They do not move directly from one BOM to another. They branch, compare, and sometimes keep competing options alive until uncertainty collapses.

Formal systems are uncomfortable with this because branches look like commitments. A decision sandbox treats parallel what-if as normal and expected. Options can exist side by side without governance overhead, making comparison easier and convergence more deliberate.

This alone explains why so much early BOM work happens outside formal tools today.

Capturing the “Why”

When a decision is finally made and formalized, most systems do a decent job recording the outcome. What they fail to capture is the reasoning that led there. Why one option was chosen over another, which risks were accepted, and which constraints drove the decision are often lost.

Collaborative BOM review naturally captures this context as part of the discussion. Over time, this becomes more than documentation. It becomes organizational memory. Teams stop re-litigating old decisions, and new team members gain insight into how trade-offs were evaluated, not just what the final answer was.

A Foundation for AI and Product Memory

I want to be careful not to turn this into an AI story, because AI is not the reason this space matters. But it is worth acknowledging what becomes possible once collaborative decision data exists. When discussions, alternatives, and rationale are captured in a structured way, they create a foundation for summarization, comparison, and analysis later. AI can help teams remember what they already decided, highlight unresolved questions, and surface patterns across decisions.

This only works because the data reflects how decisions were actually made, not just their final state. In that sense, collaborative BOM review lays the groundwork for what I increasingly think of as product memory: a living record of how understanding evolved over time.

From Agreement to Change

Once a team converges, formal systems reclaim their central role. This is where PLM, change management, and governance belong. The difference is sequencing. Decisions form in a space designed for exploration. Commitments are made in a space designed for control.

Seen this way, BOM review does not replace PLM. It completes it by addressing the phase PLM was never meant to own.

Conclusion: Understanding Comes First

The recurring pattern behind Excel leaks, disconnected discussions, and late surprises is not user resistance or lack of discipline. It is the absence of a place where early decisions can safely exist. Until that place is acknowledged and supported, teams will continue to invent informal workarounds.

Before products change, understanding must change first. Collaborative BOM review provides a place for that understanding to form, together, before anything becomes permanent.

Meantime, you can try OpenBOM Review very soon later this week. 

REGISTER FOR FREE and you will get access to OpenBOM instant trial for 14 days. 

Best, Oleg