Clarity on PLM

What I learned this week … was that we could use a good, common PLM definition and scope, but we will not get one. The discussion (a lot of discussion in multiple forums, actually) came from my post SAP, Too Much or Too Little Credit for PLM Efforts and another called Who Will Disrupt Entrenched PLM Vendors? Chris Williams pointed out on a LinkedIn thread that he felt maybe the confusion was due to a lack of understanding of what PLM really is, and asked for a common definition. My response? Not so much.

A Not-so-Common Defintion

Chris asked the million dollar question. But PLM is not one thing. While ERP has matured to a more common footprint across the vendors, the scope of PLM from each of the vendors differs. I define PLM as “processes and software used to improve product innovation, product development, and engineering performance.” That is (by definition, not by fault) very broad. There is no one “PLM” definition. The vision of the vendors shows consoliation over time, but today they are very different. Siemens includes MRO (maintenance, repair and overhaul) for A&D. Dassault Systemes has spent much more effort in “lifelike simulation.” PTC includes development of product documentation. Then, there are the applications that don’t come as a part of the suite, which makes each implementation different. Aras includes APQP and quality. They are all different.

Implications for Manufacturers

The lack of a common definition is also why putting in PLM without a strategy is a quagmire waiting to happen. But a common defintion won’t help. While there are standard processes in PLM, they are not as common as in ERP. There are examples of common processes, such as Stage-Gate processes for new product development (NPD) or CMII for change management. But product innovation and product development are not as standardized processes as accounting, as an example. It is not the lack of common PLM system definition at the root of this, it is the lack of common PLM processes. And as much as companies like Invention Machine are putting process orientation into innovation, it will still not be as standardized as ERP functions like human resource management.

So, manufacturers really need to think about what problems they want to solve before implementing PLM. You can’t just install the software and expect any benefits (beyond maybe simple data management). This is what I call the PLM Program, a strategy and vision for PLM that you accomplish in small, incremental steps.

So those are my thoughts on a common PLM defintion, don’t hold your breath waiting for it. I hope you found it interesting. Do you have a better one? I didn’t, if you do let us know about it.

That, by the way, is one of the reasons it is very hard for ERP to simply build another module and call it PLM. That is why SAP has a long program to develop PLM (which will be yet another variation on the PLM theme, different from the others).

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:

1. The value that can be achieved is significant, and can impact company performance and profitability
2. 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:

1. PLM has Business Focus = Exponential Benefit (vs. limited benefit for PDM)
2. 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).