What I learned this week … came from some reflection on PDM-less PLM: Is It Pragmatic or Just Problematic? on engineering-matters. Chad Jackson raises some great questions about whether PLM can be achieved without PDM. I wanted to share some of my thoughts on managing product data and managing product-related processes. I don’t think you can draw such a hard line between processes and data. This brings me back to a lot of my conversations with Oleg in PLM think tank on which is more important – data or business processes.
A Better Definition for PLM
They just take the words in the acronym and expand them into sentence structure. While there is some good information in the entries, defining PDM as “managing product data” (paraphrased) and PLM as “managing the lifecycle of a product” (and adding some color to what lifecycle means) is pretty worthless. That is what I call one of the “Myths of PLM.” Here is what I use:
- PLM (Product Lifecycle Management) is a software-enabled strategy to improve processes to conceptualize, design, develop, and manage products and drive higher levels of product profitability.
I find this more useful because I don’t think that anybody ever earned one more penny by “managing the lifecycle of a product.” They make money by effectively bringing innovative products to market. The other definition makes it sounds like implementing PLM is an end to itself, and not a means to an end. Is that important? When I continue to see people implementing software (PLM and others) for the sake of the software and no concept of what business value they will get from it, I say yes. OK, I will now step down from my soapbox. And while I am on the soapbox, I have to admit that I don’t really care that much about the definition of PDM. To me, PDM is just the data management portion of PLM (see the definition above). Don’t get me wrong, it is vitally important, I just think it needs to in the context of business value.
Who Cares about Acronyms?
PLM, in my opinion, started as the maturation of PDM. Once companies had their data under control, wasn’t it just natural to try to do something with it? Starting with adding engineering change control, perhaps, as a starting point? Many would argue today, of course, that change control is a basic function of PDM. So where does PDM end and PLM start? PLM was developed as PDM that understood processes, as I think Chad would agree. Now, the lines between PDM and PLM are really blurry. PDM is core capability of most PLM suites. Can you have PDM without PLM? Of course. Can you have processes without underlying data? I don’t think so. There are clearly PDM solutions that are just focused on managing product data, particularly 3D CAD. If it doesn’t add process on top, is that a basic PLM system that handles PDM or a different kind of system. Once you add processes to it, does it change? I don’t see it. PDM is a capability of a PLM solution.
The Real Questions? Engineering Data Management and Integration?
Clearly process-oriented applications are acting on something. They need data. So maybe the real question is do you need to manage CAD data to have PLM? I would say that you need PDM capabilities to run in a 3D CAD environment effectively, see my Managing Engineering Data report. But do you have to have CAD? No, as many companies in the process and CPG industries have proven by getting value from PLM when CAD is not at the core of their products. But they do have a lot of product data that needs to be managed. So do you need rich product data to run processes? No. But as Chad points out, people need access to product data. The more product information available (to the right people at the right time) provides value.
So maybe the real question is integration? Can you have a PLM solution that includes a PDM system from one vendor and process enablement from another that sits on top? As Chad says, integrating “these two systems”? I suppose that a PLM solution can be integrated from a best-of-breed PDM with processes added on top, but isn’t that just a PLM system “mashed up” by integrating solutions from two vendors? Yes, its possible. But is it practical? To me, the rich integration of product data and processes is a big part of the value available from PLM (or any enterprise application).
Implications for Manufacturers
Chad hits the nail on the head with his conclusion. The conclusion is a resounding “it depends.” You need to understand what you are trying to accomplish in your business and then find applications that support it. My guess is that leads to both data and processes together. Maybe not CAD data, although if you have it then it needs to be managed anyway and why not have it integrated. But the plan on what to implement when – the path to PLM – should be based on business requirements and business value.
So those are my thoughts on PDM and PLM, I hope you found it interesting. I realize they are a bit scattered, maybe I am missing something. Or maybe I just don’t care that much acronyms.