Ten years ago, I wrote about the tension between Excel and PLM, framing it as a choice between tools and a process-adoption challenge. A decade later, the debate persists—but it still misses the point.
This is not about whether Excel should exist or whether PLM should replace it. The two can coexist because they serve different purposes. Any organization that designs, industrializes, and scales products is practicing PLM—whether that work happens in Excel, a custom database, or a fully integrated ecosystem spanning PDM, CAD, end-to-end PLM, ERP, MRP, MES, and broader supply-chain platforms.
Some organizations have even attempted to block “export to Excel” functions to prevent offline manipulation, IP leakage, or loss of control. Yet this approach consistently fails. The issue is not the tool. It is how organizations manage product portfolio deliverables, share intellectual property, govern decision-making, and maintain data continuity across the value chain.
PLM involves multiple business functions contributing to product value and return on innovation. It implies various master data owners, shared accountability, and an ecosystem of interconnected systems and collaboration platforms. Excel persists not because PLM is absent, but because trust, incentives, and process adoption are misaligned.
PLM strategies originate from the need for traceability: from concept through production and service, from NPI deployment to delisting. Working “offline” in Excel is not scalable or reliable. Yet in specific situations—such as a startup validating a prototype, or a mature OEM onboarding a new supplier—Excel can be a pragmatic bridge, provided it remains part of a traceable thread.
Technology matters. It enables speed, visibility, and scale. But value comes from discipline and consistent adoption, not from software choice. Treating Excel and PLM as opposites obscures this truth. It distracts from the real challenge: embedding PLM practices early enough to evolve with uncertainty—and creating the conditions for people to trust and follow them.
The False Debate: Tools Were Never the Question
For years, the “Excel vs PLM” conversation has been framed as a binary choice. That framing remains fundamentally flawed.
PLM is not a single system to be purchased. It is a holistic discipline applied across innovation and operations to manage product data and decisions over time. The supporting tools—CAD, PDM, ERP, MRP, analytics, cloud services—are enablers, not sources of value in themselves.
Excel and PLM are not philosophical opposites. When they are positioned this way, the discussion drifts toward tool advocacy rather than operational reality. The predictable result is that organizations debate platforms while real decisions continue to be made elsewhere.
Excel’s Persistence: Practicality, Autonomy, and Incentives
Excel remains ubiquitous not because it is trusted, but because it is immediately available, flexible, and unconstrained.
It is often criticized—rightly—for duplication, weak version control, and limited traceability. Yet it persists because teams need a place to explore options, reconcile conflicting inputs, and move quickly before commitments are formalized. Excel is rarely preferred; it is tolerated.
More importantly, Excel becomes a refuge when users do not trust enterprise systems—or are not incentivized to use them. When PLM processes are perceived as slow, bureaucratic, or misaligned with how teams are measured, spreadsheets offer autonomy and speed without procedural friction.
Crucially, Excel does not sit outside PLM practice. It operates within it, but without governance or scalability. Its persistence signals not technical inadequacy, but gaps in trust, incentives, and early-stage lifecycle support.
The Real Misdiagnosis: Excel Is Not “Before PLM”
A recurring narrative suggests Excel survives because PLM only works after decisions are made—casting spreadsheets as a legitimate pre-PLM decision space.
This diagnosis is incomplete.
Most experimentation and early concept work are not greenfield—aside from a startup’s first prototype. They build on existing designs, engineering constraints, and manufacturing realities. That is why traceability from prototype to production, SKU profitability, and eventual delisting must be treated as inherent PLM concerns from the outset, forming the backbone of the product knowledge base.
The Excel debate is wrong not because Excel is helpful, but because it misdiagnoses the problem: Excel survives where PLM discipline, trust, and incentives are missing.
Excel does not exist because PLM cannot handle uncertainty. It exists because organizations delay PLM discipline until they believe uncertainty has disappeared—or treat PLM as a static, old-style system of record. By then, BOMs, cost models, and Excel-managed specifications are already institutionalized.
Uncertainty does not require spreadsheets. It requires provisional states, evolving structures, and governance models that tolerate incompleteness. When PLM is implemented only as a late-stage control layer, Excel becomes the default reasoning environment—not by design, but by omission.
PLM as Product Master Data Discipline
Operationally, PLM does not stop at release. Product definitions are reused and enriched across manufacturing execution, supplier management, cost optimisation, quality analysis, and future programs. As products move through their lifecycle, governance tightens as confidence increases and decisions solidify.
Excel may still be used for analysis or reporting in these phases. However, when product definitions, BOMs, or cost structures are reworked in spreadsheets, governance has already broken down—whether before or after formal milestones. The issue is not timing; it is authority.
PLM is a structured approach to managing product deliverables and project and portfolio information across the lifecycle—not merely a capability activated at release. It provides the product master data discipline, allowing knowledge to accumulate rather than be fragmented.
Practical PLM evolves with confidence and trust. It supports exploration early, convergence in the middle, and traceability at scale. Governance is progressive, not binary; it strengthens as uncertainty reduces, rather than appearing abruptly at predefined gates.
The enabling technologies—cloud platforms, analytics, AI, knowledge graphs—amplify this discipline but do not create it. Flexibility and control are not opposing forces when PLM is treated as a living operating model rather than a static system of systems.
Scaling With Intent: Moving Beyond Excel
Scaling is not a tooling decision; it is a leadership decision. The critical judgment is knowing when experimentation gives way to governed continuity—and making that transition explicit. In practice, this shift is rarely technical. It is managerial, cultural, and incentive-driven.
Organizations that scale successfully are deliberate. They identify which datasets truly matter—product definitions, BOMs, cost structures, compliance records—and ensure those are governed early. Excel may serve as a temporary bridge, but it is never allowed to become the destination. Governance is extended progressively across the ecosystem, in step with confidence and business impact.
Just as importantly, incentives are aligned so that following PLM processes accelerates work rather than obstructing it. When teams are measured on speed, cost, and delivery—but governance is perceived as overhead—spreadsheets become the rational choice. When PLM discipline is embedded into how performance is evaluated, governed systems become the fastest path, not the slowest.
Technology can accelerate this transition, but it cannot substitute for it. Cloud platforms, enterprise analytics, and AI amplify what already exists; they do not create trust, ownership, or accountability. Those must be designed into the operating model.
Reducing Excel dependency is therefore not about eliminating spreadsheets. It is about embedding PLM discipline early, aligning incentives, and building trust so that governed systems become the natural place to work. Tools may speed execution—but discipline, trust, and adoption ultimately determine outcomes.
What are your thoughts?
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
