PLM Strategy & Digital Transformation

If PLM Is Becoming Difficult to Manage, Where Is the Real Problem?

Before asking which PLM system to implement, it’s worth asking a harder question: is the software the problem — or is it everything happening around it?

But are they all working with the same product definition?

This is where many PLM problems actually begin.

It is easy to look at situations like this and conclude that the organization needs a better PLM system. Sometimes it does. But often, the real problem is somewhere else.

The process may not be clear. Product information may be moving through too many disconnected channels. Responsibilities may not be defined. Engineering changes may not reach the right people at the right time.

And sometimes the organization has a PLM system already — but people still work around it.

So the question is not simply:

“Do we have PLM?”

The more important question is:

“Is PLM actually helping us manage our product lifecycle?”

The problem may not be the software

I have seen organizations approach PLM as a technology project.

They select a platform, define requirements, configure workflows, migrate data, train users and go live.

Yet months later, some of the old problems remain.

• Engineers still maintain spreadsheets.
• People still exchange information by email.
• Manufacturing still calls Engineering to confirm which drawing to use.
• Changes still take too long to reach downstream functions.
• Users sometimes create their own ways of working because the official process feels difficult.

At that point, adding more software features may not solve the problem.

It is worth stepping back and asking:

What is actually making PLM difficult?

Start with what people are experiencing

Suppose an engineer makes a change to a product.

On paper, the process may look straightforward:

But what happens in reality?

• Does Procurement know that a component has changed?
• Does Manufacturing know when the new version becomes effective?
• What happens to material already purchased?
• Does Quality know which inspection documentation needs to change?
• Does Service know whether an existing product is affected?
• Does everyone know which version is now valid?

If the answers are unclear, the problem is bigger than an engineering-change workflow.

It is an information and process problem.

And that is where looking only at the PLM system can be misleading.

Five places where the real problem can sit

When I look at a PLM situation, I don’t start with the software. I first look at what is happening around it.

1. What is the business trying to improve?

   This sounds obvious, but it is often not clear.

   • Is the organization trying to reduce engineering effort?
   • Improve new product development?
   • Control engineering changes?
   • Reduce manufacturing errors?
   • Improve reuse of existing designs?
   • Connect Engineering and Operations?
   • Improve visibility across multiple locations?

   Or is the organization simply implementing PLM because it has become a strategic technology initiative?

   Without a clear business reason, PLM can easily become a list of system features rather than a business improvement program.

2. How does the work actually happen?

   The process shown in a presentation is not always the process followed by people every day.

   Take a drawing release. The official process might say:

   Create → Review → Approve → Release

   But perhaps the real process is:

   Create → Email → Review → Excel update → Another review → Approval → Email → Manufacturing

   That difference matters.

   Before changing the system, it is useful to understand the process people actually follow. Because sometimes the system is being blamed for a process that was never clearly defined in the first place.

3. Where is product information kept?

   Ask a simple question:

   “Where do you find the latest product information?”

   If the answer depends on the person you ask, there may be a problem.

   • One person may point to PLM.
   • Another may point to ERP.
   • Another may open Excel.
   • Someone else may search their email.

   And an experienced engineer may say: “Just ask Neel. He knows which one is correct.”

   That last answer is particularly revealing.

   When important product knowledge exists mainly in people’s heads, the organization becomes dependent on individuals. People may be doing their best. But the process is fragile.

4. Do people know who owns what?

   Product information moves across many functions.

   • Engineering creates and changes information.
   • Procurement uses it to source components.
   • Manufacturing uses it to make the product.
   • Quality uses it to verify the product.
   • Service may use it years after the product was delivered.

   If ownership is unclear, every change creates questions. Who approves it? Who communicates it? Who decides when it becomes effective? Who checks the impact? Who makes sure the downstream functions have acted on it?

   These are not software questions. They are management and process questions.

5. Where does Engineering stop and Operations begin?

   This is one of the areas I find particularly important.

   Engineering may have a well-controlled product definition. But what happens when that information moves into Operations?

   • A drawing may need to become a manufacturing instruction.
   • An engineering BOM may need to support procurement and production.
   • An engineering change may affect material already ordered.
   • A product configuration may need to be understood by Service.

   Every handoff creates an opportunity for information to be delayed, misunderstood, copied or changed.

   This is why I often look beyond Engineering and ask:

   What happens to product information after Engineering creates it?

   That question can reveal problems that are invisible if we look only at the PLM application.

The Excel file is not always the problem

There is a tendency to blame Excel. But Excel is often only a symptom.

If people maintain an Excel file because the official system does not give them the information they need in a usable form, simply telling them to stop using Excel will not solve the underlying problem.

The better question is:

Why did they create that Excel file in the first place?

• Perhaps they need a view that the system does not provide.
• Perhaps the process is too slow.
• Perhaps the information is owned by another function.
• Perhaps they don’t trust the information in the system.
• Perhaps the system has not been adopted properly.

Understanding the reason is more useful than simply removing the spreadsheet. The same applies to email, local files and other workarounds. They are often symptoms of a deeper issue.

Having PLM does not automatically mean having control

This is an important distinction.

The presence of technology does not automatically create process discipline. And process discipline does not automatically appear because a system has been implemented.

The organization has to decide how it wants to work — and then make the technology support that way of working.

So what should come first?

Before asking:

“Which PLM system should we implement?”

or:

“What additional PLM functionality do we need?”

it may be more useful to ask:

• What problems are we actually trying to solve?
• Where does product information get delayed or lost?
• Which processes create the most friction?
• Where are people creating workarounds?
• Which information is difficult to trust?
• Where do Engineering and Operations struggle to stay aligned?
• Which activities depend too heavily on individual knowledge?
• What capabilities do we already have?
• What needs to change before technology can help?

The answers will be different for every manufacturer. That is why I don’t believe there is a single PLM journey that works for everyone.

Diagnose before deciding

Depending on the situation, the starting point may be different.

An organization preparing for its first major PLM initiative may need to understand its PLM readiness.

An organization that already has PLM but is not seeing the expected value may need a capability or maturity assessment.

If the biggest problems are between Engineering and Operations, an Engineering-to-Operations assessment may be more useful.

If the underlying issue is how people work, process consulting may be needed.

And once the gaps and priorities are understood, the organization can define a practical roadmap.

The sequence I use is therefore simple:

Not every organization needs to start at the same point.

PLM should make the product lifecycle easier to manage

Ultimately, PLM is not about having another system.

It is about helping people manage the product more effectively as it moves through its lifecycle.

The real test is therefore not:

“Have we implemented PLM?”

It is:

“Can our people reliably find, understand, use and change the right product information when they need it?”

And beyond Engineering:

“Can the people who need that information downstream act on it without unnecessary interpretation, re-entry or delay?”

If the answer is yes, the technology is doing its job.

If the answer is no, the next step should not automatically be another software investment.

It may be time to understand where the problem actually sits.

Where I typically start

My work with manufacturing organizations starts with the current situation — how people work, how product information moves, where processes break down and what the business is trying to achieve.

Depending on what we find, the journey may involve:

The objective is straightforward:

Understand the problem before deciding the solution.

That can help an organization make better decisions about what needs to change in the process, what needs to change in the way people work, and what actually needs to change in the technology.

Because the goal of PLM is not to create another system people have to manage.

The goal is to make the product lifecycle easier to manage.