For years, PLM has been sold with a simple and powerful message: One Single Source of Truth. One system. One database. If you speak with PLM sales people, you can translate it in a simple way – Go PLM or die.
It is a compelling story. Executives like it. Compliance teams depend on it. IT departments are comfortable with it. Vendors have built entire business models around it. Control, traceability, and governance sit at the center of this promise, and on paper, it makes perfect sense.
And yet, when I speak to many companies, I can hear how they “export Excel” to do some stuff. In every place, it is like the same quiet confession from engineering and manufacturing teams:
“Yes, we have PLM, it is good for records, we keep all released data there… but when we need to do some work, when the real work starts, we export the BOM to Excel to do some changes, check, review, discuss. Once we done we bring it back to PLM for traceability”
This is not an edge case. It is not a training problem. It is not even user resistance (although sometimes it is). And it is definitely not a temporary habit that will disappear with the next PLM (nicer, easier, simpler) upgrade. In my view, it is a pattern.
Here is the thing – if PLM truly delivered on the promise behind “Go PLM or Die”, Excel should be gone by now. Instead, spreadsheets are alive, thriving, and deeply embedded in the many critical moments of product development, communication with contractors, cost estimations, supply chain analysis, reviews, etc. Especially when decisions are still fluid.
That raises an uncomfortable question: If PLM is the “Single Source of Truth”, why does truth keep leaking into Excel?
The Leak Is Real
Let’s start by acknowledging something most people already know but rarely say out loud.
PLM systems are very good at recording decisions. They are far less comfortable hosting decisions while they are still forming. This difference matters more than we usually admit.
When teams need to explore alternatives, question assumptions, or move quickly across roles, they rarely stay inside PLM. Instead, someone exports a BOM. Sometimes it is framed as “just for now.” Sometimes it is described as a workaround. Often, it is justified as a one-time exception.
But those exceptions pile up. And over time, Excel becomes the place where conversations happen, where disagreements surface, and where provisional decisions are made.
PLM, in contrast, waits patiently for certainty. That is not a flaw. It is how PLM was designed. The problem is that most important product decisions happen before certainty exists.
Where the Leak Happens
The leak from PLM to Excel is not random. It appears in very specific moments, and once you see the pattern, it is hard to unsee.
It happens before ECOs, when change is being explored but not yet justified. This is the phase where teams are asking whether a change is worth pursuing at all. PLM expects a reason; Excel allows the question to exist.
It happens before formal release, when the cost of being wrong is still lower than the cost of waiting. Teams want to test scenarios, run rough calculations, and see how far an idea can go before committing to it.
It happens during reviews, cost checks, and sourcing discussions, when questions outnumber answers. At this stage, data is incomplete, assumptions are provisional, and decisions depend on input from multiple roles.
It happens when multiple roles need to react fast. Engineering, manufacturing, sourcing, and finance are all touching the same information at the same time. PLM is optimized for handoffs between roles; Excel is optimized for overlap.
It also happens when data must be combined across multiple products and systems. Real decisions rarely live inside a single product structure. They require pulling information from several assemblies, variants, ERP snapshots, supplier files, or legacy spreadsheets. PLM assumes a bounded product context. Excel does not care where the data came from.
And finally, it happens when work crosses company boundaries. The moment suppliers, contractors, manufacturing partners, or customers are involved, control weakens. Data leaves the enterprise boundary. Excel becomes the neutral meeting ground where collaboration can happen without onboarding everyone into the same PLM system.
These are not rare situations. This is where real product work actually happens.
A Simple Hypothesis
Looking at these patterns, I keep coming back to a simple hypothesis: Excel survives where decision velocity matters and data flexibility is important. Excel does not win because it manages data better. It wins because it tolerates unfinished work.
Tools fail to replace Excel when multiple roles must iterate together, when decisions are provisional, and when work happens before formal release or ECO. Excel does not demand certainty. It does not enforce approval. It does not ask whether a decision is final. It simply allows the work to continue.
This is why spreadsheets keep showing up even in organizations with mature PLM deployments. Excel is not competing with PLM. It is filling a gap PLM was never designed to cover.
Why PLM Struggles in This Space
It is tempting to frame this as a usability problem or a cultural issue. The latest trend is to blame education. This is a place where recently I see a lot of “OCM projects” – it is about organizational change management. Once we explain it, the problem will be solved. But I think that misses the point. PLM struggles here for structural reasons.
PLM systems, strategies and ideas are built around control. Their core value proposition is traceability, auditability, and compliance. They assume that decisions already exist and need to be documented, approved, and preserved. In that world, uncertainty is something to eliminate, not something to host.
PLM workflows ask questions like: Is this approved? Is this released? Is this the correct revision? Those are the right questions — just not at the beginning of the decision process.
Excel, on the other hand, asks a different question: What if? What if we change this part? What if the supplier cannot deliver? What if the cost target moves? What if we need to support two variants instead of one? What are alternative suppliers? What if we replace one supplier with another? What if we buy this part 1000 pieces now? How it will impact the cost?
These questions do not fit comfortably into systems designed around final answers.
This is not a failure of PLM vendors or users. It is a reflection of the incentives and architectures that shaped these systems in the first place. PLM monetizes control. Excel survives on permissiveness.
Excel Is Not the Enemy
At this point, it is important to say something clearly: Excel is not the problem. In fact, Excel is a signal.
It shows up exactly where PLM stops being helpful. It appears at the boundary between exploration and control. And instead of treating it as a threat, we should be asking why that boundary exists in the first place.
If Excel survives because it supports fast, provisional, multi-role decisions, then we should be able to predict exactly where it appears. And we can.
Look for early BOM exports. Look for color-coded rows and comment columns. Look for file names that include words like “final,” “v2,” or someone’s name. Look for side notes that say “check supplier” or “risk.”
These are not signs of chaos. They are signs of work happening before certainty exists.
The real question is not how to eliminate Excel, but how to support the kind of work Excel is currently enabling without losing context, traceability, or continuity. How to get everyone in an organization and outside of the team involved?
The Missing Layer Before PLM
If Excel lives in the gap between idea and release, then replacing it requires something PLM was never designed to be.
It requires a space where multiple roles can work together on the same product context without committing to final answers. A space where decisions can be provisional, debated, revised, and revisited. A space where the history of decisions matters just as much as their outcomes.
This is not a lighter PLM. It is not faster workflows. And it is not another approval layer. It is a decision layer before PLM.
Such a layer would not replace PLM’s role as a system of record. Instead, it would feed it. It would capture the messy, iterative work that leads up to formal decisions and make that work visible, shareable, and connected.
Most importantly, it would acknowledge something PLM has traditionally avoided: that uncertainty is not a bug in the process, but a fundamental part of how engineering decisions are made.
What is my conclusion?
Should we rethink “Go PLM or Die”? Is something wrong with SSO (Single Source of Truth)? When I look back at the single source of truth slogan, I no longer see it as wrong. I see it as incomplete. Driving on SSOT Highway, we need sometimes to take an Excel turn, do some work and come back to the highway.
PLM is essential. It plays a critical role in managing released products, controlled changes, and long-term traceability. But PLM alone cannot cover the full lifecycle of decision-making — especially the early, messy, collaborative part.
Companies bring PLM to have a structured control and traceability. Depending on the company size and product complexity it means different things. For some companies, control means to have traceability BOM release with related CAD files frozen in time. For some other companies, it means to organize a structured process with approvals and different roles. Both are structured processes.
Excel survives not because PLM failed, but because decisions move faster than control.
The real challenge is not to force all work into PLM earlier, but to recognize that something important happens before PLM takes over. Ignoring that reality does not eliminate Excel. It just pushes critical work into tools that were never meant to carry that responsibility.
So perhaps the better question is not Go PLM or Die, but something more uncomfortable:
What if Excel is telling us where PLM stops too early? And what would it take to finally close that gap — not by adding more control, but by supporting how decisions actually unfold?
Just my thoughts… What is your take?
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-native Collaborative Digital Thread platform providing connecting engineers and manufacturing teams.
