The promise of Product Lifecycle Management (PLM) is captivating. Still, before you reach the golden lands of accelerated time to market, better product quality, efficient collaboration, and faster deliveries that PLM offers, you’ll likely encounter a few potholes. In this article, I’ve listed some of the most common PLM problems I’ve encountered in the PLM projects we’ve been a part of.
#1 – Management chose the PLM system based on PowerPoints and company dinners.
Improved time to market, cross-company collaboration, capitalizing on the lifecycle value…the buzzwords, the charming sales guy, his shiny demo, and a bold pitch got your organization’s C-suite to say “Yes!” to Product Lifecycle Management.
Data-quality issues, system architecture mismatches, and clashes with corporate culture are conveniently left out of those marketing-led meetings.
All too often, management thinks PLM is as simple as implementing a system.
The product dashboards might look great in the demo, but getting them implemented in your company will take some time.
How to avoid this PLM problem:
Let me tell you a secret. A successful PLM journey doesn’t start with a “best-in-class” system. It starts with a great team of people. Together, they can make almost any system work.
If it’s not too late with this PLM problem, consider the solution’s history of industry success, customization, flexibility, integration ability, customer support, and how well the solution addresses the organization’s requirements.
#2 – The system is seen as ugly, too slow, and expensive.
Your management picked the wrong system – it’s a common problem with PLM implementation. Maybe they didn’t have time to evaluate different ones or got sucked in by the siren song of a good deal. Either way, you ended up with a PLM system that’s not right for you.
It’s not that the system isn’t good. It just doesn’t fit your business.
Perhaps they selected a system with too many features. It could even be that the system’s interface doesn’t look good. Or maybe the OOTB solution is hard to use – it seems like you’re designing an aircraft when you need to manage your BOMs!
How to avoid this PLM problem:
The secret to a better user experience is doing the up-front work to determine what matters most. What are the top workflows? What functionalities do people use the most? Is it the EBOM module or the search engine?
Figure out what’s important, then stay focused on the key things. Find a compromise that marries your workflow to the realities of your system.
More is not necessarily better, even when it comes to PLM systems. If you show every feature, view, and integration, you’ll soon be drowning in so much functionality that you won’t be able to focus on what’s important.
#3 – Good old Excel is still the go-to tool.
“The biggest market share in PLM belongs to Excel,” says Oleg Shilovitsky, co-founder of OpenBOM, a cloud-based bill of materials and inventory management tool for hardware start-ups, manufacturing, and supply chain.
Engineers love Excel. It’s still the go-to tool for “critical” engineering calculations such as process design or product configurations. Excel is good at things PLM isn’t, like moving data back and forth and creating cool dashboards from multiple data sources.
But while Excel is convenient and useful for simple calculations, it’s a terrible tool for collaboration and enterprise data management.
How to avoid this PLM problem:
Old habits die hard!
If you want to convince the engineers and project managers in your organization to move away from Excel, you have to make a case for collaboration and transparency.
Identify some real-life examples where Excel has failed to deliver the lifecycle visibility your organization needs, and show them a better way using your PLM system.
In a start-up with a young workforce, getting over Excel will be easier.
However, it’s an entirely different ball game to get older staff members to come to grips with your PLM system and change their ingrained Excel-centric ways of working.
#4 – There’s a war going on between your systems.
If you’ve been in the PLM world for a while, you’ve probably witnessed a lot of system wars: PLM vs ERP, PLM vs CRM, even PLM vs PLM!
The tricky thing about Product Lifecycle Management is that product data is spread across different systems. There’s often a lack of clarity about where and how to manage product data, especially after a merger. Also, different systems offer the same functionality. If the people managing these systems don’t talk to each other, it won’t be long before a system war breaks out.
How to avoid this PLM problem:
In the end, it’s all about defining system responsibilities. Who does what? Where do you need to manage BOMs? Do you need more than one system to release parts to production? Where do you do what?
Often, you’ll need to compromise. Don’t try to get it all right at once. Having a vision, planning out the system roles, and the PLM architecture will slowly build peace in your system wars.
#5 – Your teams are competing against each other.
The Germans vs the Swedes. The French vs the Americans.
This is a variation on our previous point – Teamcenter vs 3Ds, or Catia vs NX.
Political infighting can be overwhelming in international PLM projects.
If you’ve been part of a PLM implementation in a global company, I’m sure you’ve heard this before:
- “That’s not how we do things here.”
- “This might work for a simple product like yours, but ours are much more complex.”
- “This system is too complex. Have a look at what we have in-house!”
A PLM implementation often threatens Country-specific ways of working.
For example, the cool product configurators they’ve developed in-house could be lost when you begin to adopt the PLM system’s configurator for internal efficiency purposes.
How to avoid this PLM problem:
Sometimes bringing down the walls between teams starts with dinner or an outdoor event.
Having a PLM project leader from a country other than fighting the war can help keep tempers in check.
Plan and be prepared to deal with political turmoil if you’re deploying PLM in a global company.
#6 – Your middle-aged users are set in their ways.
Who is Markus, and how you can drag him into the 21st century?
Markus is that grumpy, belligerent engineer who created the first Excel-based product configurator when dinosaurs still roamed the earth.
“You guys in management sell the PLM as a productivity tool, but now it takes me ten minutes longer to save my CAD models than before! So, what’s in it for me?”
Of course, Markus is an archetype, but there are plenty like him – people who refuse to engage with new ways of doing things.
How to avoid this PLM problem:
Here’s another secret: Technology is a small challenge compared to people in a PLM implementation. Identify skill gaps and invest in education and organizational change management.
My advice here is to ensure you bring in the right team to engage in your PLM implementation – people who can listen, empathize and move things forward.
Don’t know how to get started? We can help!
#7 – The “Mister-Know-it-all” PLM consultant’s solutions aren’t the best for you.
Nobody likes a know-it-all consultant, but many companies’ PLM implementations have been led by one of them.
You’ve probably been there. An experienced and charming guy with more than 20 years of consulting experience delivering a conceptual presentation deck filled with management jargon, mountains of charts, figures, and statistics.
Some of these consultants resort to “one-size-fits-all” approaches. They use the same slide decks from client to client and keep asking for more budget. The solutions they propose are not necessarily the best for the company, but only what they can deliver and capitalize on.
When you attempt to implement what you’ve received, you have few actionable steps to take.
While certain strategies might have been successful on similar projects, no two engagements are identical.
How to avoid this PLM problem:
Bringing in a PLM consultant can be essential to move PLM forward. But if you’re not careful about how you make the decision, you can end up with a “Mister-Know-It-All” leading the change.
Not all consultants are arrogant know-it-alls. Look for a consultant who listens—someone who has worked in your industry. And hire a person, not a company name.
#8 – The PLM architect has their head is in the clouds.
“We’re going to lose all the customizations this year, get back to the Out of The Box (OoTB) solution, and build an internal ecosystem with API-powered applications connected to the cloud. Then we’ll build a digital twin portfolio powered by Artificial Intelligence (AI). This strategy will give us a real edge.”
Buzzword bingo!
If you’re like me, you’ve probably met a lot of PLM system architects whose “heads are in the cloud.”
I get it. Tech can be intoxicating.
But talking about advanced geeky stuff when the basics aren’t in place is a joke.
Trying to make sense of what constitutes PLM architecture (rather than, say, a system upgrade or a website redesign) is never easy. Product Lifecycle Management is the enabler of many cool things that digitalization does, but its roots go far back.
How to avoid this PLM problem:
The latest powerful advances in tech are exciting. Having a bold vision is not necessarily a bad thing.
But if your system architecture teams keep only dreaming big, your PLM solution will soon be perceived as an “ivory tower” by the business.
A great system architect balances technical and business knowledge. If it’s not too late with this PLM problem, hire a PLM system architect who’s not just a tech-obsessed geek.
#9 – The PLM concept owner wants to keep it conceptual.
I’ve been part of several PLM implementations where the concept owner didn’t want to hear about the system. She wants to “keep it all at a conceptual level” because the concept doesn’t need to be “system-specific.”
But the reality is, a PLM concept goes hand in hand with the PLM system.
If your PLM concept hides its absence of real tactical advice under many layers of fancy-looking “conceptual” data models, you have a problem with your concept owner.
How to avoid this PLM problem:
If your PLM concept owner is swimming in high-level theories and complex concepts, you might want to raise an eyebrow. A good concept owner needs to get her hands dirty by getting down to the nitty-gritty details to understand the system.
Ask questions and make sure they can show you how things should work with the toolset you have on hand, not “in the perfect world.”
#10 – The IT department doesn’t care.
Does granting your users access take ages? Your PLM system keeps crashing, and no one seems to be able to fix it? You can’t access your system today, and the guy from the helpdesk keeps asking you if you’ve tried turning it off and on again?
There’s nothing worse than a non-supportive IT department. Technology plays a key role in PLM, and if your information technology department can’t help you get it right, you have a real PLM problem.
How to avoid this PLM problem:
The best way to resolve the PLM IT-related issues is to treat the problem as a team effort. Once the departments identify an issue with IT support, they will find the root of the problem. Is it knowledge? Is it motivation? Is it politics?
Identify the key tasks your IT department needs to help you with, and document how to do it. If you don’t have enough internal knowledge to support your PLM users, it might be worth outsourcing it.
There are many small companies with well-informed people that can help you solve daily user problems and think strategically about how to improve your PLM system performance.
#11 – There’s little excitement about data.
Product data is power – but only if the data is correctly collected, processed, and managed.
Simply put, product data quality refers to the “health” of your data and whether it’s fit for its intended use. If your product data is duplicated across systems, outdated, or full of errors such as typos, abbreviations, and punctuation mistakes, it’s impossible to extract insights and value from it.
The problem is that although big data and data analytics sound sexy, the real, nitty-gritty data work is boring.
Ensuring that attributes are common across the enterprise and getting integrations and migrations right is difficult and takes a lot of work.
How to avoid this PLM problem:
All too often, key data quality issues are overlooked. I’ve seen several key digital transformation programs fail because the product data wasn’t prepared or good enough.
Don’t build your product data foundations on sand. Make sure you have funding in place to support the effort to get to good product data.
Build a case for management and use plenty of real-life examples. Explain why your product data management initiative is needed, and be prepared to explain why it’s so expensive.
#12 – It’s time for the dreaded system upgrade.
Your system is outdated, and it’s time for an upgrade. Now that you’ve got the ball rolling and your people are used to your PLM system, your system vendor has informed you that, as of next year, they won’t be supporting the version you installed.
Outdated PLM systems can put companies at risk of security issues and holes in their system architecture. Updating a PLM system can seem as simple as updating a software version – but if you’ve been through a PLM system upgrade, you know it’s not.
Customizations and company-specific configurations will often make it hard and time-consuming.
How to avoid this PLM problem:
System customizations will be needed, but if you customize your system too much, you’ll end up on your own at upgrading time.
Plan and budget for upgrades, and don’t underestimate the effort they involve. A PLM system upgrade is a project on its own.
#13- You’re having a hard time demonstrating the PLM’s ROI.
Data quality issues, technology hurdles, poor people engagement with the system … any or all of these common PLM problems can make your C-suite feel like they’re not getting a big enough bang for their buck.
Why is the return of investment such a big deal for Product Lifecycle Management? Because justifying the value of PLM through ROI is very challenging.
The tricky thing about PLM is that it’s a bit different for everyone.
When a PLM journey begins, most companies don’t understand what they’re implementing, let alone how much it costs or how long it will take.
Our blogging peers Jos Voskuil and Oleg Shilovitsky discuss this in detail in some of their articles.
How to avoid this PLM problem:
PLM implementations often focus on technology and pay far less attention to the human aspects. People’s problems are the reason for most of the PLM failures I’ve seen.
While systems and technology require attention, people need at least as much careful consideration and strategic planning.
Put people first, and make them your superpower!
Source: SharePLM
Don’t hesitate to contact Thanh for advice on automation solutions for CAD / CAM / CAE / PLM / ERP / IT systems exclusively for SMEs.
Luu Phan Thanh (Tyler) Solutions Consultant at PLM Ecosystem Mobile +84 976 099 099
Web www.plmes.io Email tyler.luu@plmes.io