A blog by Oleg Shilovitsky
Information & Comments about Engineering and Manufacturing Software

How PLM Missed the C-Level and Why ERP Didn’t — and How to Fix the Story

How PLM Missed the C-Level and Why ERP Didn’t — and How to Fix the Story
Oleg
Oleg
11 December, 2025 | 9 min for reading

Stories are the only things that reliably capture human attention. It does not matter if we speak about movies, books, presentations, or enterprise software. Everything begins with a story. 

A project gets approved because someone tells a story that resonates. Technology gets adopted when someone hears a story that makes sense. A sale moves forward when the customer starts to see themselves inside the narrative. Sales is not an exception. To sell anything, you need a story. And in every story there is a hero. 

If the seller and the buyer do not recognize the same hero, the story breaks. This simple idea explains a surprising amount about the struggles PLM has had with the C-level for more than two decades. It also explains why ERP walked straight into the executive office while PLM kept knocking on the side door.

This article continues the line of thinking from my recent blog, “PLM Needs a New Hero: Why the Old Story Must Be Turned Upside Down.” There I explored the internal limitations of PLM’s traditional positioning. In this article I want to look at how PLM framed its story externally, how that story traveled inside organizations, and why it consistently lost the room at the executive level.

The Old PLM Story

For many years, the PLM story revolved around engineering complexity. It was a world built around CAD models, revisions, BOM structures, change processes, workflows, approvals, and everything that sits between design and production. It was a story of chaos threatening to overwhelm engineering teams. Files scattered everywhere. Revisions going out of sync. People working on the wrong version. Processes that only a few understood. Engineering departments are drowning in their own data.

In this narrative, PLM was positioned as the hero. PLM arrived to bring structure. PLM organized the revisions. PLM controlled the changes. PLM eliminated duplicates. PLM established order. PLM promised a clean, structured, controlled engineering environment. This story worked. Engineers felt the pain. They experienced the daily tension. They understood the need. When vendors told this story, engineering teams usually nodded in agreement. The emotional connection was strong because the hero was saving them from a problem they recognized.

The problem was not the story itself. The problem was where the story stopped.

The PLM narrative was built entirely around engineering. It was an engineering story told by engineering people to engineering audiences. And when the time came to take the story outside that group, things became complicated.

When the Story Travels Upward

Inside engineering, the PLM story works. The hero is clear. The plot is logical. The problems are familiar. The “love for PLM” drops down sharply once you close the door of an engineering department. As soon as the story needs to climb the organizational hierarchy, a shift occurs. The story is retold to people who live in a completely different narrative world. And that is where the trouble begins.

When the story reaches the C-level, the executives listen. They hear about files, revisions, and processes. They hear about engineering workflows, BOM misalignment, and the promises of structure. But they do not hear themselves in the plot. The story has no room for them. It does not describe their world of responsibilities. It does not reflect their daily concerns. It does not align with their identity.

Executives see themselves as the hero of the business story. Their narrative is about margin, risk, predictability, delivery, customer exposure, and financial performance. In their story, they are responsible for the company’s outcomes. Every major system that gains their attention is expected to reinforce that narrative.

This is where the two stories collide. A story about engineering operations cannot simply be retold as a story about business performance. The hero does not transfer. You cannot replace the protagonist without rewriting the plot. The engineering story and the executive story contain two different heroes. And there is a fundamental storytelling rule: a narrative cannot support two competing heroes.

PLM ignored that rule for a long time. ERP did not.

Engineering as a Black Box

Another challenge is that engineering remains a black box for most executives. They understand the high-level goals but not the details. They know the company depends on engineering, but the day-to-day pain of revision mistakes and disconnected workflows feels distant. They do not feel the urgency because they do not experience the consequences directly. When an engineering-driven PLM story is presented to them, they see an abstract problem that belongs somewhere else in the organization.

This creates a psychological disconnect. The executive is not present in the PLM story. They cannot imagine themselves benefiting from the hero’s success. Even when they intellectually agree that engineering inefficiencies matter, they do not emotionally recognize the story as theirs.

PLM stories were written in engineering language. Executives speak the language of business. The translation rarely worked.

Why ERP Walked Right In

While PLM was selling an engineering-first story, ERP took a different path. ERP never tried to be the hero. ERP never tried to rescue engineering or redesign product development. Instead, ERP framed its story around money, operations, inventory, cash flow, and business control. This is the natural language of the C-suite. ERP approached executives with a simple promise: better visibility, better control, better predictability. The C-level instantly recognized themselves as the protagonist in that story.

ERP said, “You lead the financial engine of this company. Here is the system that gives you control over it.”
PLM said, “Engineering has a mess. Here is the system that can clean it up.”

One story aligned with the executive identity. The other story did not. One story framed the system as a tool the executive hero uses. The other story framed the system as a hero in its own right.

Because ERP positioned the executive as the hero, adoption was natural. Because PLM positioned itself as the hero, adoption became difficult.

The Moment PLM Loses the Room

This pattern appears repeatedly in PLM sales cycles. The engineering team loves the PLM story. They engage, they test, they validate. They understand the hero’s role. They want the transformation. And then they need to retell the story to their executives.

The story goes upstairs. A new audience hears it. And the meaning begins to fade. The hero is unclear. The value is indirect. The narrative no longer fits the worldview of the executive listener.

The stakeholder presenting PLM is telling one story. The executive receiving it is living inside another. The collision is invisible but powerful. Without a shared hero, the story cannot align. Without alignment, the sale stalls. It is not a technology problem. It is not an ROI problem. It is a narrative identity problem.

Storytelling Truth: One Hero per Story

The core storytelling principle applies to business just as much as it applies to literature. A coherent narrative needs a single protagonist. Everyone inside the story understands who the hero is. ERP gave that role to the C-level. PLM gave that role to engineering. When PLM tried to sell upward, the presence of two heroes created narrative confusion. The story did not translate because the protagonist did not translate.

If PLM wants to succeed with the C-suite, it must fix the story. It must stop competing with the executive identity and start supporting it. PLM must rewrite its narrative so that the executive becomes the hero and the system becomes the enabler.

This brings us to the next question: What could a new PLM story look like?

Three New Stories That Could Solve the Collision

If the old PLM narrative fails because it centers engineering as the hero, the obvious solution is to write new stories where the C-level naturally sees themselves as the protagonist. These stories must still reflect the reality of engineering, but they must frame the outcome in a language executives understand.

Here are three possible narratives that could redefine PLM’s relationship with the C-suite.

A. The Business Performance Story

In this story, PLM becomes the intelligence layer behind predictable revenue, margin protection, and business execution. Instead of describing engineering workflows, the story focuses on clarity, accuracy, and confidence in decisions that affect the entire business. The executive remains the hero who leads the organization. PLM becomes the system that gives them product insight they can trust.

This narrative says:“You lead the business. PLM gives you the product knowledge to run it be tter.”

It reframes PLM as a provider of decision intelligence rather than a controller of engineering processes.

B. The Operational Risk and Exposure Story

Another framing focuses on risk. Bad product data is one of the most expensive types of business risk, especially when it reaches manufacturing, suppliers, procurement, or customers. Mistakes triggered by incorrect versions or disconnected information can create delays, cost overruns, warranty claims, and customer dissatisfaction. In this narrative, the executive hero fights uncertainty. PLM becomes the tool that eliminates exposure.

This narrative says: “Your greatest operational risk is product uncertainty. PLM removes that uncertainty.”

Executives already respond to risk stories. PLM can fit directly into that framework.

C. The Digital Knowledge Capital Story

The third narrative positions product knowledge as a strategic asset that compounds over time. Companies invest huge resources into design, engineering, testing, and validation. Yet much of that knowledge remains fragmented, siloed, or trapped in documents and files. In this story, PLM is the infrastructure that transforms product knowledge into digital capital. The executive becomes the steward of that capital, responsible for growing and protecting it.

This narrative says: “Your product knowledge is one of your most valuable assets. PLM is the system that grows and connects it.”

This approach reframes PLM as long-term strategic infrastructure rather than a departmental tool.

What Is My Conclusion? 

So, which story should PLM tell next? After two decades of selling the engineering-first narrative, the PLM industry has an opportunity to rethink its approach. The three stories above offer different paths. Each one aligns the hero with the C-level instead of engineering. Each one changes the identity of PLM from a departmental savior to an enterprise enabler. Each one reflects the reality of modern product development without falling into the trap of positioning PLM as the hero.

The real question now is simple. Which of these narratives should shape the next chapter of PLM?

Which story finally aligns the seller and the buyer around the same hero? Which story would make the C-level instantly recognize themselves inside the PLM narrative rather than outside it? Which story will carry PLM into the executive conversation where it has struggled for decades?

I would love to hear what resonates with you and where you see the strongest foundation for the next PLM story.

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. 

Recent Posts

Also on BeyondPLM

4 6
4 September, 2009

For years, PLM and not only PLM, but also other enterprise systems like ERP supported idea of a single backbone...

26 May, 2010

If you think about the future of enterprise systems, this is a “must see” video presentation. Core Content and the Cloud...

24 June, 2010

I read Fortune CNN Money Blog article by Jon Fortt – Chrysler’s Engineering Software Shift. In the competitive world of...

16 May, 2016

Monica Shnitger article Openness — will you know it when you see it? made me think again about PLM and openness. The...

29 June, 2010

My post Open vs. Closed PLM Debates last week and related Fortune CNN Money Blog article by Jon Fortt –...

3 October, 2012

I’m in Moscow these days to attend the first Autodesk University Russia (AU.Ru). Even so, I feel like attending multiple...

6 December, 2019

Everyone needs data. But nobody wants to manage it. I’ve learned it for many years of working with the engineering...

10 June, 2016

The idiom “the devil is in the detail” refers to a catch or mysterious element hidden in the details, and derives...

12 September, 2023

The industrial world is changing and so product lifecycle management (PLM) software. Back decades ago, PLM software was only for...

Blogroll

To the top