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).
Pingback: Mythbusting PLM is an Industry Affair - Or is It? | Clarity on PLM
Pingback: BOM for Dummies: BOM and CAD « Jos Voskuil’s Weblog