What I learned this week … is that there are still some technical challenges that make implementing PLM challenging, but that is not what this post is about. The technical challenges include customization, data migration, and integration among others. See Oleg’s post on the “3 main factors of mainstream PLM adoption” for more detail on each of these, and his views on why these three factors impact the adoption rate of PLM. I accept Oleg’s premise on these factors (although we will likely continue to debate the relative priority of ERP integration) from a technical perspective. 
But I think any technical conversation about PLM implementation has to be complemented with a view on why PLM is really hard – you have to change the way people work in order to improve your product development performance and your product profitability.
Some Past Research in Implementing PLM (and some validation too!)
In August of last year, I wrote about some Aberdeen Group research on implementing PLM in Research Rap: Implementing PLM Takes Hard Work (when will we learn?). My key points then, which I will re-emphasize here are:
- The value that can be achieved is significant, and can impact company performance and profitability
- That value will require changing the way the business operates, which takes more effort than loading up some new software
In reviewing my prior post, I also noticed a comment from Martin Ohly referencing his website, global plm.com. He has a number of slides on his site, one which I replicated (in part) above. I dropped the company reference because I don’t have permission to publish it (see Martin’s site, it is a very well respected, global company) but I really liked it because in comparing PDM to PLM it mentions two points that I think mirror (and validate) the points from my earlier post:
- PLM has Business Focus = Exponential Benefit (vs. limited benefit for PDM)
- PLM addresses cross-business processes, supply chain, commercial view or product, enterprise efficiency, customers
I would take some liberty and say that point number two on the slide is very closely related to my point number two above, and they are both a big part of why PLM is hard. The interesting thing is that the slide is dated February, 2004! This is not a new issue. And as my previous post indicates, this is something we should have learned from implementing other enterprise applications like ERP and supply chain – the technical challenges pale compared to the need to change the way people work!
Implications for Manufacturers?
So why am I jumping up on my soapbox this Monday morning? I believe that PLM is hard not because of technology, but because of people. I am not disagreeing with Oleg that there are technical challenges (and he probably knows them better than I do, frankly). But manufacturers need to keep the two points above in mind. Implementing PLM requires a business transformation effort, not a software install. This is what I wrote about in my post last week about the PLM ecosystem being ready to implement PLM. Manufacturers can’t lose sight of the importance of business processes and people in their focus on a sound technical implementation! I know this isn’t what Oleg is suggesting, but both aspects need to be considered when you discuss what is required for PLM adoption.
So those are my views on why implementing PLM is hard (but worth it), I hope you found it interesting (and maybe even useful).
Fantastic points, Jim. I agree that PLM is worth it, and difficult technically for the reasons that Oleg mentioned and difficult philosophically for the reasons that you mentioned.
I would like to add something. While PDM doesn’t have the same level of benefit as PLM, it is a necessary milestone to pass on the way to PLM. And it has the same challenge as PLM – you’re asking people to change their behavior. So how do we get past PDM and on to PLM when the value of PDM is smaller yet it’s challenges are almost as large?
I think this takes businesses with vision – companies willing to invest in the PLM backbone (PDM) to get the future value they expect from PLM. This is notoriously hard to communicate because most businesses start looking at PDM so they can just “manage their CAD files”.
Jim you are right, this is a people problem, not a technology issue. Just because something is good for us >>> it does not mean we will do it. The slide above makes me think of lip stick on a pig. There is nothing there other than hand waving and technology argument. Where is the user based proof? Lets not forget people pushed back hard on the concpet of feature based associative CAD… What got us over the hurdle, other than some hard selling, was the fact that “INDIVIDUALS” found the value. I’m not saying PLM is bad, but I am saying the users need to find/see the value for them. Which in turn makes this a people problem.
May be I am taking the slide out of context but the other thing that strikes me is that the authour is comparing on technolgy that was slow to be adopted with another…
Jonathan makes a very interesting point that I think would be great to explore. Unless I miss read his point he is saying PDM is on the way to PLM or a stepping stone in the implementation of PLM. Said another way PDM comes before PLM!
I imagine PDM is the first step in most implementations but I WONDER DOES IT REALLY NEED TO BE? Since PLM creates value across the business, then I think it would be safe to assume that file management is not required to create value. It would be interesting to see if there are cases where PLM has generated value without PDM functionality. These cases would provide significant definition of value for individual users.
Some simple situations that could be looked at are the connections between marketing peope an engineering where a CAD file is not the standard means of communication or between a project manager and a designer…
Jonathan,
Thanks for yoru comment. I think that PDM is a very critical element of PLM. I do think (depending on your definition of PLM of course) that there are other places to start than PDM. For example, you could start down the path of PPM – focusing first on projects and commercial product considerations – and bring the technical product information along later. That said, I think the most logical place to start is PDM. But I would suggest that companies can implement those parts of PDM that are important to support the functionality that is going to drive the fastest business value. For example, they could focus on compliance first by implementing part and BOM management, without integrating to the underlying CAD models. Would you agree, or do you think there needs to be a “full” PDM step in the PLM implementation?
My view is that you do need a PLM Vision that helps you understand the end state (as well as you can), and then approach it in a step-wise fashion that I have been calling “The PLM Program.” The worst thing anybody could do (in my opinion) would be to start putting in software without understanding the long-term goals and the impact on people and processes.
Thanks!
Chris,
You make some interesting points. I don’t see companies questioning whether or not PLM is valuable, I see them concerned about the investment (in people as much as in the software) it takes to acheive it. Most companies want (need) what PLM offers, but just haven’t taken the plunge. In one of my earliest posts on MBT I pointed out I could find two kinds of people:
– Those that didn’t understand the value, but thought it was easy to implement
– Those that understood the value, but thought it was hard work to get there
Of course both are problems, just different ones. From those that I talk to, more people have learned about the value of PLM since that time, and are moving to the second category. Now, they know they need to do it but struggle with how to pull it off. The real question that I take away from Jonathan is where should they start?
Dear Va Va,
Exactly!
Jim and others thanks for the interesting discussion. As you might know from my blog it is one of my recurring remarks : PLM requires a change in doing business and it is the human factor that makes it hard to implement.
And here I see the major challenge for PLM vendors and implementers. Most of the vendors logically focus on their product capabillities, not talking about the implementation impact (as you might loose from the competitor)
PLM implementers, in case of the big organisations like Accenture or IBM focus on the business change and PLM is a tool.
For the mid-market (coming back to your previous post too: Is the PLM Ecosystem Ready for PLM) the main challenge is that the implementer cannot come in with the business change approach as the customer expects more an IT-project, not a business change(but still huge ROI)
In such a situation to get the real value out of PLM you need to be trustworthy and experienced enough to guide the customer to change the way they work (which not many mid-market implementers can do I believe, due to lack of scale or experience with this kind of situations)
Therefor the question will be raised every year again – why is PLM hard to implement (in the mainstream)
Jos,
I will put a reminder on my calendar for end of next summer, “see if PLM got easy to implement.” 🙂
Seriously, you and I see this in a very similar way. But it is up to the manufacturer to take their success in their own hands. They have learned in the past from earlier PLM initiatives, ERP, CRM, SCM, or any other number of systems implementations with three-letter acronyms. This stuff is hard work! The manufacturer has to demand the right expertise and the right project plan, whether it comes from their vendor (Dassault, PTC, Siemen, etc.), from a big constultancy (Accenture, etc.), from a specialty company (Kalypso, Razorleaf, NovaQuest, etc.) or internally. In many cases, the best bet might be a combination that includes the vendor. But in the end – the manufacturer has to take their success in their own hands.
For the rest of the PLM ecosystem, the job is to make it as easy as possible from the software usability, data migration, integration, services, industry tailoring, training, and other perspectives as possible.
In the end, though, let’s not just focus on how hard it is. The second key point is that it is incredibly VALUABLE! So if we can reduce the “I”or “Investment” by making it easier, it make the ROI that much more compelling. And that will benefit everybody in the PLM ecosystem, including the vendors and the systems integrators.
Jim, I’m adding your slide to my collection of PDM vs. PLM stuff… Everything you said about processes, transformation, people and organization is just right… But, I think, we will not be able to change people. They dislike hard work, even if this is for their own benefits and ROI and even… for their own success. So, the only variable I see in this eco-system is to improve PLM technologies… It will make life simpler and easy. You note about 2004 just a reminder in front of all try to get process improvement hard work. PLM made huge progress since 2004, but it was really hard .. Best, Oleg.
Correction–>
Jim, I’m adding your slide to my collection of PDM vs. PLM stuff… Everything you said about processes, transformation, people and organization is just right… But, I think, we will not be able to change people. They dislike hard work, even if this is for their own benefits and ROI and even… for their own success. So, the only variable I see in this eco-system is to improve PLM technologies… It will make life simpler and easy. You note about 2004 just a reminder. PLM made huge progress since 2004, but it was really hard .. Best, Oleg.
Oleg,
If you want the full version of the slide, you can get it from http://www.global-plm.com. There are a number of slides with some interesting perspectives on them.
Your point about not being able to change people is – I think – the exact reason that you can’t fix the problem with technology. I don’t believe people are lazy, but I do believe that they need to see what the value is for them or believe in a cause bigger than themselves that they can serve. How does that apply to PLM? Without changing (hard things) like incentives and compensation plans, technology is worthless. If you don’t develop a team mission around PLM where people understand they are not just “feeding the software system” but really believe that the extra work they are doing is helping produce a higher quality product or make their company more competitive (and that, in turn, benefits them), then easier implementations won’t solve much. What is in the vendors’ control, though, is the technology. And you should do everything that you can do to reduce the barriers. But in the end, it is up to the manufacturers themselves to do it right. And doing it right is hard – but valuable. As the 2004 slide said – exponentially valuable.
I find this “conversation” interesting. I am not much of a blogger but I couldn’t agree more with Jim and Chris based on my personal experience. Over the past ten years or so, I have been on the business side of five significant system/process implementations. Most of those implementations failed to meet our optimistic first year use expectations. My personal observation is that the most challenging part of implementing is people change management and it was clearly the driver behind failing to meet our expectations. Is anyone out there aware of research that validates or refutes this observation? I generally think leaders repeat the mistakes of the past because the value (or lack of) of effective people change management is viewed as an expense rather than a ROI investment. For anyone on an implementation team, I suggest you advocate for a comprehensive change management process. You will typically find that vendors and consultants like Kalypso can help you build a compelling business case and change management plan.
Scott, I agree, efficient change management is important. But at the same time we need to make a progress in products and technologies too. When I’m looking on PLM revenues analyses by CIMData, I see 50-60% is coming from services. I don’t think this is good number. What is your view on this? Would you be able to make change management process simpler with some technological improvements (toward Apple-like-integration-between-products, for example)? Regards, Oleg.
Oleg,
50-60% is too low in total, I am hopeful that there are implementation services that our outside that number (3rd party). Perhaps this is why people find it so hard, and aren’t being as successful as they should be? They aren’t getting the help they need?
Apple-like integration would be nice, but it isn’t the major issue (in my opinion).
Jim
Interesting debate. I think the answer lies somewhere in between. My earlier blog made a case for comprehensive change management. Oleg makes an interesting point – making the technology easier to use or at least more aligned with today’s millennials/Gen Y (age 15-34). They are the first generation to grow up with computers and have become the IPOD/IPHONE/Google generation. This generation is now the core user group of PLM type solutions. While technically savvy, they are a demanding group and are the driving user group behind Google and Apple innovation. Why wouldn’t PLM usability evolve at the same pace?
Two things I notice about General Y, or the iPod and Facebook generation: (1) They like to be in charge of their own digital environment. They want to be able to set their own privacy levels, background colors, layout, and RSS feeds that appear on their virtual wall. (2) They’re comfortable mixing work and play, personal and professional interactions. To ask this demographics to work in a one-size-fits-all Excel-like interface where there’s no amusement of distraction to keep them engaged is next to impossible. Unfortunately, that pretty much describes most PLM systems.
Scott,
I agree with you on change management, it is critical. A portion of change management is teaching people how to use the software (click here, click there, wait for this, enter some data, click twice, …) That can absolutely be improved with better user interfaces (along the lines of what Kenneth Wong is saying). The more “configuration” users can do to make their environment work on their own without changing code via “customization” the more usable it becomes.
Another portion of change management is teaching processes beyond the system, but how it fits into the busines. Enhancing software systems can help there too, because today’s systems are better at emobodying the process. But better systems is only a part of the answer, because companies have to figure out what the processes will be in the first place. Templates, industry-tailoring, and other advancements definately help here. But there is also a business analysis role that needs to be played, and new processes need to be put into the context of the user’s job.
The other part (or one other, maybe I am not complete) is organizational change management. Aligning the software initiative and processes with business strategy, redefining roles, changing workflow and responsibilities between departments (and getting the managers to agree to it), and getting the intended users of the system to see what it is in it for them (including performance metrics and incentive programs) are all important for success. And I am probably leaving things out, as I have been more on the “process” and “technology” side than the pure “people” side. These, unfortunately, the software really can’t help with. These are purely business functions that need to be addressed or the software might very well get implemented, but it will not return the “exponential benefits” as described in the chart early on.
So Scott, I feel like I am preaching to the choir a bit because I know you live this on a regular basis.
To net out my thoughts on this discussion:
1 – Yes, absolutely improve the software. Do it. No doubt. It will help.
2 – Don’t expect PLM to suddenly implement itself, even if the “install” becomes a 30-minute download or just pointing people’s browsers to a new bookmark.
Thanks to all for a great discussion on this topic. And thanks Oleg for getting it started.
Jim
Implementing PLM is not hard! nor people are lazy
Many times PLM projects are started with core resources of company who are given the responsibility to implement PLM along with external consultants but not the time
Role of these people gets limited to just providing the information what PLM consultants are asking and they never get enough time to analyze outcome
or usefulnness of the data provided.By the time they start understanding PLM software behaviour ,consultants already finish up their project and their is no scope for further improvement
Most of these champions hardly get 1-2 hrs to work dedicatedly with team implementing PLM,that too sometime they spend on getting appointments from different groups
Solution I see here is to have PLM projects implemented with proper time frame considering availability of core resources of company implementing PLM.
Other aspect on service provider side is many of these companies are in rush to get the next order thus giving only the bare minimum services to customer without doing complete analysis of proposed solution
All of the above to be done within constraints of cost,competition and customer demands!!!
Prashant,
Nice to hear from you! Thank you for your perspective. You touch on a very interesting point that I try to stress to people when they are starting a PLM project. Think of the key people in your business that are really the starts – the ones that make things happen, the ones that get respect, the ones you can’t afford to be away from their projects – and free them up for the project. Not part time, not 1-2 hours, but dedicate them. If a manufacturer is not willing to invest the right people for the project, they will not get the results they are looking for. They may get a very good technical implementation, but they will not see the business benefits.
I am glad you say it isn’t hard. Remind me to pull you in if I ever need PLM implemented!
Jim
Thanks Jim – It would be wonderful working with you on PLM Implementation 🙂
Thanks Enjoy,
Prashant