PDM vs. PLM: A Data Perspective

PDM vs. PLM: A Data Perspective

I want to talk about what I consider as one of the most controversial topics in the industry – PDM vs. PLM. How many times, you had a chance to hear the following question: What is the difference between PDM and PLM? I guess, the only one question can practically compete with this – question about what is PLM? So, I decided to step into this winding road to give you my perspective on that. I will try to get rid of multiple high-level pitches and TLA-oriented presentations.

The Status quo
My first shot to get the status quo is to see what Google can show me on this topic. So, the following search, brings some interesting set of links. Here is what I found.

The oldest material I found is the article by Martin Day in CAD Digest – Is PLM the new PDM? . He is giving a deep perspective of PLM definition based on his conversation with Pascal Daloz, back that time VP R&D strategy in Dassault Systems. You can see their opinion about PDM to PLM race as well as the definition of how PLM is expanding PDM.

The later materials about PLM and PDM comparison are related to Solidworks white paper PLM vs. PDM: It All Starts From PDM. You can find this whitepaper on the following link. Their PDM is a subset of the overall solution called PLM. The explanations of SolidWorks PDM people are very simple and straightforward. However, they are giving you too much marketing flavor – buy PDM first and later think about your PLM.

A very interesting perspective on PDM vs. PLM topic provided by Mark J. Silvestri, CEO at Lifecycle Solutions in his video. I found it as a pretty balanced view presenting a very practical historical perspective about expansion of product data management into management a diversity set of moving pieces related to information about products.

Arena Solutions put their sponsored link with “PDM vs. PLM” label pointing on their white paper. You to register, so I did and then discover seven pages long white paper about advantages of PLM solution from Arena. There are few more links. However, they are giving you pointers to the websites of multiple PLM solution providers explaining advantages of PLM software.

PLM Confusion
In my view, the most notable confusion around PLM is related to a very different view on this from two opposite sides – vendors and customers. For the last few years, I can hear more and more customers are talking about PLM strategies,  concepts and industry adoption. However, in many cases it becomes very controversial when the discussion is moving to the vendor/product side. Most of the vendors pushing “a complete PLM solution” actually missing the point that this solution probably cannot be delivered by a single vendor and customer considering it more as a strategy rather than a product. At the same time, you can see PDM movement into the “commodity space” where PDM is considered as a software to manage CAD data that, in most of the cases, need to be purchased from CAD vendor to prevent version compatibility hassles.

PLM Data Perspective
Here is my short take on the PDM vs. PLM from the data perspective. Both TLAs were born to provide a name to a solution that helps engineering and manufacturing companies to manage product data. In the early beginning, it was mostly about vaulting CAD data. However, within the time, companies in that space understood that broader strategy needs to be developed to compete with ERP behemouths  that started to capture market in a very aggressive way by consolidating enterprise application around MRP and finance domains. That was the time the idea of managing broader scope of data was born. Solutions started to expand their offering to manage data about requirements, engineering and manufacturing BOMs, supply chain data. However, to sell pure data management is not an easy job. C-level people are not driven by data. They are driven by processes. So, broader data management solution for engineering and manufacturing came to the idea of “Lifecycle”. Finally, PLM was born. In my view, it stands for a broader data management solution that includes the orientation on processes that influence changes of this data as well decision management in a context of this data.

What is my conclusion? The ugly truth of enterprise software – it is all about data and the control over the data. It appears in every solution. It is all about what data you manage, how do you keep your customers accessing and processing this data?. PLM is the attempt to manage data in the much broader scope than PDM. It creates lots of benefits from the standpoint of data completeness and, at the same time, created many overlaps in data management solutions in enterprise organizations.

Just my thoughts. I’m open and looking forward to having a discussion on this topic.
Best, Oleg

Share

Share This Post

  • Herve Menga

    This question is a fake question, and, in my opinion, is only asked by the software vendors.The underlying assumption that PDM could be compared to PLM by comparing the amount of features or the different levels of capabilities is typically coming from the vendors. It is not surprising that a search by Google is just retrieving things emitted by the software vendors… marketers are doing their job.
    I think that nobody cares about PDM vs PLM, but the vendors. I remember the fight between parametric vs variational modelers, and also the fondamental question between relational databases and non relational databases… insignifiant debates…
    Of course, i have my idea about PDM and PLM : PDM is the manager, the software system that runs somewhere on a computer, and PLM is the management, the discipline that deals with the mastering of the product definition.
    Companies are running PLM processes with the help of PDMs, so what is the problem. The responsibility of PDM vendors is to put on the market PDMs systems with more and more capabilities, ok.
    But PLM, as a discipline, remains independent from the PDMs, the same way mathematics are independent from the computers and the softwares.
    As a PLM consultant, i know what PDMs can do, and more, i know what PDMs cannot do to execute PLM processes. I am not working for any software vendor, i am doing my consulting job on PLM.
    And what the hell with the product data ? I did not know that a product should have data to exist… This is also a software vendor POV. The sphinx of Gizeh has been designed and produced, i am not sure of the sphinx data that could have been at the origin of this marvelous enterprise. I am sure that ancient egyptians already exercised some PLM processes, and this without PDMs.
    I wonder what PLM processes could have been run at that time : vault management ? configuration management ? project management ? industrialization and BOM management ? SCM ? assembly management? Surely they did some piece of them, and on papyrus and stone, with a calam… but this was already PLM, the discipline that organizes the building of the product definition.
    Crazy, isn’t it ?

  • GB

    PLM vs PDM vs SDM – perhaps that is the question instead….

    From my perspective, PLM –> PDM –> SDM in reverse order of importance.

  • beyondplm

    GB, Thank you for the comment. I’m not sure familiar with this acronym. What means SDM? Best, Oleg

  • beyondplm

    Herve, Thank you for such a great insight! I agree with you, all acronyms EDM, PDM, PLM, etc. was kind of proposed by vendors. Nevertheless, I see also some reflection of industry people as well. In the end, everybody has their vision on what is PLM and PDM. I had chance to hear PLM vs. PDM question from an end-users very often.
    I think product data (or engineering data, if you will) is always coming in the process of design. It comes in different forms. In ancient days was presented by model that architect kept in his hand. Later it comes in the way of paper drawings and tables. Now it is digitized in different forms. In order to have processes in place, you will always need to assume some data about what you are doing. Data vs. Processes is one of the very often used comparisons between PDM and PLM. However, I found that in many cases, simple explanation people are giving about PLM is just more data domains (i.e requirements, engineering, manufacturing, supply, etc.). I like your definition of PLM: “PLM, the discipline that organizes the building of the product definition”. Even so, I’d say it is not only about a definition- this is about an actual product creation. Thanks for such a great discussion.
    Best, Oleg

  • Herve Menga

    If you say “data”, it has a relation to software. A model or a drawing are not data, they are representations of a concept. They are containing information, but they do not contain data.
    A process outputs artifacts, some of them may be digitized, some other not.
    PLM processes output physical artifacts in the ancient times (clay models, paper/papyrus/sand/clay drawings), and nowadays the SAME PLM processes output digitized artifacts (3D/2D models, objects in a database, objects manipulated by PDMs…).
    The objective of PLM process is only to construct and maintain the definition of a product. To define a product is to build the most precise border between what will be the product and ist surroundings or background (latin de-finire = to draw the groove in a field to indicate its borders).
    What is a product creation ? A product is not created (only concepts are created from nothing in the product design activity), the product is produced, i.e. raw physical materials are transformed with methods and tools according to its definition ; PLM does not deal with product creation, but with product engineering (designing something that will be produced).
    I use to say that PLM is engineering engineering, by analogy with software engineering (software design and production), mechanical engineering (mechanical design and production), electrical, civil engineerings…
    So PLM, for Product Lifecycle Management, is something like the engineering design and production, while PDM, the Product Data Manager, is a software solution (based on PDM objects manipulation in a database) that is used like others (CAD, CAM…) when PLM processes are executed by the engineers.
    Even if some engineers are asking strange questions like “what is the difference between PLM and PDM”, you certainly agree with me that the good marketers are paid to educate the prospects in a way they only ask the questions that have answers known by the vendors, typically answers about level or volume of software features, rather than focusing on their business needs.
    I am a bit cynical here, i am in holidays. And i apologize, if the equation PLM = PDM++ has no meaning because PDM and PLM refer to very different things – we say in french “on ne mélange pas les torchons et les serviettes”, kitchen clothes and bath towels are not mixed, nothing exists beyond PLM – sorry again PLM++ does mean anything 😉

  • Mike Leach

    Herve, I agree wholeheartedly with your perspective. For decades three letter acronyms (TLA’s) have been created by vendor marketing organizations in order to create competitive battlefields. However, the need to manage the life-cycle of products has gone on forever. The processes required to manage products throughout their life-cycles are many and varied. Each industry (mechanical, electronics, Oil & Gas, chemical, food, consumer products, etc.) has its own set of requirements and processes they need to manage success. Those processes, historically, have always gone far beyond “product definition”. Companies have always considered life-cycle management to include ALL phases of the product’s life (ideation, conceptual design, detailed design, strategic sourcing, release to manufacturing, production, release to customer, maintenance, and EOL). It has always been accepted that product-related information might be created, modified, distributed, and used at every stage of the process. This is where technology comes in. Technology’s role (i.e. h/w, s/w, etc) is to “enable” those processes, nothing more. Over the past 40 years we have seen an explosion of technology solutions, starting with point management solutions (CAD, CAM, CAE, mrp (materials management), sfc (shop floor control), finite and infinite scheduling systems, AP (Accounts Payable), AR(Accounts Receivable), FA (Fixed Assets), HR (Human Resource Planning)) to name a few, and evolving into more integrated solutions (MRP (Manufacturing Resource Planning), ERP , EDM, PDM) to name a few. The integrated solutions combine the efforts of their point solution predecessors into comprehensive product data management environments (some better than others). PLM, in my opinion, is simply the current in vogue acronym. Its definition is still evolving, as we can see from the discussions going on. Everyone is confused, including some very big companies. Simply stated, I advise my clients to identify best practice processes for their industry and develop a phased, measurable plan, involving people, process, and technology that will result in early successes that will leverage the costs of ongoing improvement. I advise them that there is NO one technology vendor that can enable the entire product life-cycle process. I advise them the the critical path to success is PEOPLE, not technology. We so often forget that change will not occur if the people don’t want it. Thanks again, Herve and Oleg, for your perspectives.

  • Christine

    I don’t think PLM is PDM with more options at all. Managing files is simply necessary if you want to leverage them later. Leveraging them intelligently, and in a collaborative manner across multi disciplinary teams requires a wildly different type of software. Lately, wearing my manufacturing operations hat, I have been viewing PLM as simply a preprocessor for data flowing into our MRP.

    Cheers,
    Christine

  • Vladislav Skoupski

    My vision is: PDM-system is a part of PLM-infrastructure. I mean that PLM = PDM+CAD+ECAD+CAE+…

    Is ERP-system and PM-system within PLM? I don’t know.

  • Herve Menga

    We have a problem here, and this is highlighted by Christine and by Mike. One position is to consider PLM only for the product definition construction / maintenance (i do not want to use the word “management” on purpose), which is Christine’s and my opinion. The other position is to consider PLM as the general process that deals with product (here i do not know what kind of feature i should use instead of the un precise “management”), which is Mike’s position. This question is also raised by Vladislav.
    The trick is that the L in PLM is put for “lifecycle”, which gives the impression that all features of the product should be “managed” – again this very bad word – as we say “from the cradle to the grave” of the product…
    According to this interpretation, the PDM systems, the CAD systems, the CAM systems, the ERP systems, the MRO systems and so on should participate to PLM.
    I feel very unconfortable with this, i have a problem of definition (finding the limits), i cannot accept that PLM is the whole thing concerning the product : if PLM is the whole thing, first i cannot draw the limits of the concept (this is not acceptable if i want to manipulate it), second i am sure that existing information systems are not “sufficient” to cover the execution of the whole thing…
    This is the reason why i prefer to restrict the term PLM to the product definition construction/maintenance, and this throughout the whole life of product : this definition is “growing” from the very early times of the product (when the product does not yet exist) through the classical engineering processes such as requirements elicitation, functional design, process design, logistic support design, etc., is maturing when the product just begins to exist through the prototype building, is evolving when the product is mature (when it is really produced) because of the engineering changes, and also when the product is sold and used by the customer, and also when the product dies or better now when it is recycled into another product… From my point of view, PLM is only the discipline that deals with the following question : How can i organize the living definition of the product during the whole product life ?
    Remember that this product definition is a reference (a referential) for all other organizations “external” to engineering : production, sales, marketing, logistics, supply chain, design and manufacturing partners…
    And i think this is why the mastering of the product definition under the flow of definition changes requests (ECRs)
    is the central point of PLM – we use to say “configuration management” (again this bad unprecise word) to call this mastering, no ?
    if you are interested in this point of view, and if you read french, do not hesitate to read and comment in french 😉 http://hmenga.wordpress.com.

  • Mike Leach

    Herve, thanks again for your perspective. Having read your more detailed explanation, I’m not sure that we far apart in our thought processes. Let’s put aside the three-letter acronyms for the moment. Let’s also assume the the words “life-cycle” and “management” are difficult concepts to get one’s arms around. Let’s also assume the the term “product definition” is itself a term which has multiple definitions across the global ecosystem employed to design, build, distribute, and maintain a product. A leading mobile phone company has up to 7 external design houses, 5 external manufacturing partners, 6 global distribution/service centers for each product. Individual companies no longer do all this themselves. This all being said, in my opinion (and the opinion of my clients over the past 20 years), companies expect that accurate product definition information will be available to consumers of that information when they need it, throughout the product life-cycle and beyond (e.g., in order to enable reuse and leverage). Whatever combinations of business processes and enabling technologies are required to accomplish that end AND result in a positive ROI are encouraged to be implemented. I totally agree with your perspective that the product definition is a “living” document, and must be maintained thoughout the life of the product. Changes will occur throughout the ecosystem that will need to be reflected in the product definition, many on an urgent basis. These might include testing results force material changes, manufacturing capabilities change at an outsourced manufacturer, part availability goes down, part/component failures at customer sites, potential obsolete inventory at product EOL needs to be consumed, etc., etc. In a perfect world, product problems such as these would be reflected both upstream and downstream in the ecosystem in near-real time. And we certainly are not in a perfect world. In my prior message I purposely used the uncapitalized term “product life-cycle management” to differentiate it from the over-hyped PLM. I agree with you that “product definition and maintenance” is the core concept. I further agree that it is a “living” document. But I would respectfully suggest that the “scope” of the maintenance of that document is all-inclusive of the product’s ecosystem and that all product-related information created, modified, distributed, and used within that ecosystem might potentially be managed (maintained) in the product definition.
    Saying we’re not in a perfect world, I’m really trivializing the problem. Blending business processes and enabling technologies WITHIN a company is hard enough. Blending critical business processes and technologies throughout an product ecosystem is almost impossible. In my opinion, even approaching a solution will require, at least in the near term (a decade or so), the full plethera of three letter acronyms participating in product life-cycle management (N.B. no capitals). I sincerely sympathize with technology vendors. It’s really tough out there. Herve, I appreciate our discussions and your perspectives. Thank you for the intellectual stimulus.

  • GB

    SImulation Data Management = similar to Engineering Data Management (EDM) but focuses on the management of the data produced during design and analysis steps. Especially in the concept design phase where the produce is being created…

  • Allen

    Why do we need product? For the business;
    Why do we need CAD & PDM ? For better serve the business;
    Why do we need a PLM Vision? For best serve the business;

  • Herve Menga

    I am sorry, if you really think that all things are driven by the business (or worse “to serve” the business), your life as human dasein must be very empty, and i believe you only express the vision of PLM from your point of view…

  • beyondplm

    Christine, Thanks for commenting on this. However, my main point was related to a “data perspective”. From this standpoint, I can see PLM is covering much broader range of topics in an organization. It is obviously hits and overlaps other systems in an organization. This is what created so many “debates” around what PLM is actually doing. Don’t you think “data perspective” is a simpler way to handle product lifecycle management? Best, Oleg

  • beyondplm

    Allen, Thanks for commenting! I think, “business vision” is important. However, I can see PLM provide some “utility functions”. This is about data and not about business. Just my thoughts… Best, Oleg

  • beyondplm

    Oh… I’m sorry. Terrible missed this TLA :)… I’ve seen that as part of CAE, isn’t it? I think EDM was about management of documents in the beginning. However, this abbreviation appears more and more pointless. Don’t you think so? Best, Oleg

  • Allen

    Agree that from the data perspective, PLM is the attempt to manage data in the much broader scope than PDM.
    But as you say: “C-level people are not driven by data. They are driven by processes. ” , I believe they are driven by the business processes.

  • beyondplm

    Herve, I see two different perspectives on PDM/PLM and other engineering software. 1-Data, 2-Process. Both are equally important, in my view. However, people and organizations may see things differently. I know people that see “a process” everywhere. For them creating of a model /drawing is a “design process”. They are certainly right from their “process perspective”. Among the people talking about PLM, the process orientation is very popular. PLM came out of large OEM implementations (i.e. Boeing, Airbus, Ford, Toyota, etc.) and was ERP-competition-minded. So, process-orientation was initially something that helped marketing and sales people to explain what is PLM about. My “cynical view” on enterprise software (sorry for taking your statement) is very “data oriented”. Everything in the organization has “data representation” (I’m not going to argue if this is “software-related” or not). For many years, enterprise software built on top of very strong data-ownership orientation. It started before RDBM by development of proprietary data storages and file formats, later with RDBMS by development of proprietary data models. So, the ugly truth in PDM vs. PLM data perspective is that I can see it as “data expansion”. Process-minded people will see “process expansion”. They are both right, btw. Thank you for such a great discussion and apologies for some delays from my side during this week. Best, Oleg

  • beyondplm

    Mike, thank you for such an interesting perspective! I think, you are right by saying “PLM, in my opinion, is simply the current in vogue acronym. Its definition is still evolving, as we can see from the discussions going on. Everyone is confused, including some very big companies”. What you presenting is a very “process-oriented” view, which is absolutely correct. My point is that there is a data behind processes and by taking a look on this data some of the “software differences” can become very obvious. What you call “point solution” is actually data islands. We are in the early beginning of thinking how to connect them. Great discussion! Best, Oleg

  • beyondplm

    Vladislav, I think, this is a very valid perspective. Thinking about data-enabling, PDM can certainly become part of PLM. I prefer “engineering software” term, which is less TLAish :). Best, Oleg

  • beyondplm

    Mike, thank you for such a great explanation. You are certainly right, especially this one–> “Blending business processes and enabling technologies WITHIN a company is hard enough. Blending critical business processes and technologies throughout a product ecosystem is almost impossible.”
    What I like the most is your statement of “definitions”. My perspective on this – definition is a data. This is a main point of my original post. Starting to think “data first” we can simplify the way companies are working now. What is your take on this? Best, Oleg

  • Viktor

    Does it really matter? As a customer you want a solution that support the strategy and visions developed within the company. As a vendor you may want to position the solution into PDM or PLM segment, but I have found that most PDM systems just changed the name to PLM and continued on their track. I use to answer this question by saying “PDM is vertical” and “PLM is horizontal”. Or “PDM is the old name”, “PLM the new name with more focus on the lifecycle of the product”. Soon there will be new names like “Interactive BOM game” – IBG or something :)

  • beyondplm

    Viktor, thanks for your insight! Yes, you can take it this way too. However, I think, those PDM vendors re-branded as PLM has added some stuff. My perspective is that most of the enhancements were about expanded data scope to manage and control. What is your view on this? Best, Oleg

  • Viktor

    I agree. They would have done it even if the name was still PDM. PDM for me is about handling the product structure and the connections to the product documentation itself. Variant control, revisioning, versions of parts and having control of it as it is being developed including connection to the CAX tools. Also variant control mechanisms is connected to the handling of the product structure (or configuation if you want). But if you want to take parts further into next step in the overall business process (manufacturing maybe) perspective, then you need to control the lifecycle of the product by some process tool. If the product is developed in a project oriented scope then it is nice to have the project management tool in the same environment etc.. So with PLM the vendors takes a bit of the MRP/ERP cake with PLM. The name change was then more tactical and strategic from the vendor(s) I believe. Document management is ECM today. Customer database is CRM etc etc.

  • beyondplm

    Viktor, you are right. I’ve seen customers preferred PLM solutions because of better business process / project management integration. It is about data+collaboration. Name is marketing, of course. Best, Oleg