PDM vs. PLM: A Process Perspective

PDM vs. PLM: A Process Perspective

I want to continue the discussion started last week in my post ‘PDM vs. PLM: A Data Perspective‘. Thank you all for comments and your contribution to this conversation. I think, clarification in this space can be very beneficial for customers, vendors and other people involved in planning and operation systems for product development, engineering and manufacturing. From the data standpoint, PLM is about to cover a much broader scope of data. However, data is only one dimension, we can use to compare PDM and PLM. Another dimension is  a “process”. So, today I’d like to come with a process perspective on what are differences between PDM and PLM.

Process Definition

The definition of a term “process” is very broad. Looking on the Wikipedia “process” page I found a diverse set of definitions. I’d like to take two of them as a context of this discussion.

Wikipedia – Process.
Process or processing typically describes the act of taking something through an established and usually routine set of procedures to convert it from one form to another, as a manufacturing or administrative procedure, such as processing milkcheese, or processing paperwork to grant a mortgage loan, or converting computer data from one form to another.

Wikipedia – Business Process.
A business process or business method is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers.

I found that vendors in the space of design, engineering and manufacturing software are using the “process” word very frequently and by doing so, came to the situation where everything in their activity can be considered as a process. In my view, it created a lot of problems with explanations of what software solutions are actually doing in a context of particular organizational processes and needs.

Why PLM Is About Process?

The main reason when PLM is tightly bound with the definition of a process is actually related to the definition of a lifecycle. This is about a whole product life. Every step in this life cycle can be defined as a collection of activities / tasks that produce a result (product). Manufacturing organization activity is focused on the process of planning, engineering, development, manufacturing and supporting products. Design process, Change Management, Release Process, Sales Process… All these activities are part of the overall product lifecycle process. When you think about these steps, you can come to the definition of PLM as a software helping companies to organize and maintain product related processes.

PDM vs. PLM Processes?

Originally, PDM was created in order to maintain design and engineering data. Simply put it was about managing CAD data, related engineering files and their revisions. This type of activity normally can be localized inside of engineering organization. PDM systems are bound to the design tools (historically it was CAD) and serve engineers in their activity related to management of  versions and releasing of design and engineering information to manufacturing and rest of the organization. With such a scope PDM easy becomes a software to maintain a release process. However, in real life, this design release is connected to the other product development activities. This is a situation when PLM is coming with broader process support of managing a change, supply chain, quality and other (product related) processes.

What is my conclusion? The first ugly truth coming out of the data perspective post – PLM is about to cover wider data scope. Thinking about a process perspective, I came to the conclusion of the second ugly truth –  it is better to explain your software product value in association to the real organizational and product development processes. ERP first discovered a “process-secret-sauce” and started to bind their modules and expand ERP to additional organizational processes.. CAD/PDM companies came second to the spot and decided to capture a broad definition of Product Lifecycle Processes. PDM was about one simple process – Engineering Data Release. Shifting from PDM to PLM, vendors attempted to bind solutions to product development processes in an organization. However, the diversification of these processes in organizations is very high. It resulted in a very high level of complexity and growing amount of customization and software tailoring. Just my thoughts…

Best, Oleg

Share

Share This Post

  • Steve Porter

    Oleg,
    great blog as usual. I think the key phrase you have in your article is “Shifting from PDM to PLM, vendors attempted to bind solutions to product development processes in an organization. However, the diversification of these processes in organizations is very high.” This shift that CAD vendors have from PDM to PLM has been problematic for their clients. The structure of a good PDM tool does not necessarily lend itslef to being a good PLM tool. I think the CAD vendors have dramatically transformed themselves over the past several years but the jury is still out versus true PLM systems. My blog “Stuck Between a Rock and a Hard Place, the PLM Dilemma with engineering data” http://bit.ly/dvQ4Vy touches on this topic.

  • beyondplm

    Steve, Yep. You got it right. The match of PLM solutions to Product Development Processes is the most problematic piece of PLM software. In order to resolve this problem for big customers, PLM vendors and their partners created a very complicated customization and tailored solutions. The idea of Out-of-the-box and Industry verticals is the leading one, for the moment. This is another try to copy ERP business, in my view. Thanks for reference to your post. Best, Oleg

  • Paritosh Deshmukh

    Hi,

    We may need to Add CPDM, PIM along with PDM and PLM for focusing on PLM application usage.

    Regards,
    Paritosh

  • beyondplm

    Paritosh, Thanks for brining these acronyms too. I believe cPDM and PIM are valid terms and solutions when you think about enterprise and engineering software. PLM isn’t capturing a full scope. I found people are still referencing cPDM when talking more about collaboration in the context of design. I can see PIM as a more “outbound” product data provider. Does it make sense to you? Best, Oleg

  • Vladislav Skoupski

    Oh, Oleg. Again and again… :)

    Do you know Russian movie “National features of hunting”? There is one good phrase: “We will not dispute terminology” :)

  • beyondplm

    Yes, I know this movie. My attempt is not to dispute, but explain. These two – PDM and PLM are scoring on the top of mystic TLAs, in my view. Just my thoughts… Best, Oleg

  • Vladislav Skoupski
  • beyondplm

    Yes, thanks for sending this link anyway! I’m planning to address it in one of my future posts. Best, Oleg

  • Lars Taxen

    Oleg,

    I think you are absolutely right. In my view you need even to think even beyond the data / process dimensions. Data is about spatial orientation in a context; you need to know what things are relevant, how these can be characterized and how they are related to each other. Process is a temporal dimension in a context; you need to know in what order actions are to be performed. In addition to these dimensions you also need to consider the dimensions of context, stabilization (by which I mean things like routines, norms, standards etc) and transition (by which I mean the transition between contexts). The reason is very simple: every human action requires capabilities in all these dimensions; dimensions which I have called activity modalities in my research. Ultimately, these modalities – contextualization, spatialization, temporalization, stabilization and transition are cognitive predispositions for acting, and they are all interrelated, meaning that you need to consider them as a whole.

    What does this mean for PLM? Naturally, our predispositions for acting do not change when working with PLM instead of chopping wood, eating or doing anything else. We still need capabilities in all the five dimensions. Thus, in doing PLM work you need to think in contexts (actually the most basic dimension), the spatial dimension (data models, product structures, information models etc.), the temporal dimension (processes, workflows, etc.), the stabilization dimension (identification rules, revision rules, routines, etc.), and the transition dimension (for example how design and production shall coordinate their work, perhaps in terms of mapping between design item and production item states).

    If you think about PLM from activity modality perspective, the task of the PLM system is simply to manage all these modalities. But if you basically have a business process perspective, you will overload the process/temporal dimension with the other dimensions, expresses in statements like “the information of the process”. Basically, what you do is to “compress” a multi-dimensional problem into one dimension.

    I am quite convinced that if PLM is to advance beyond its current state you need to consider all activity modalities. Moreover, you need to start from the contextual dimension. Contexts are formed around work objects and motives in organizations. Engineering, development, manufacturing are examples of such contexts. Every context creates its own world in terms of meaningful things, actions, routines, and ways of cooperating with other contexts; i.e. all modalities are present in every context. Implementing a PLM system then becomes a matter of balancing between what is idiosyncratic for each context and what is to be common for all contexts, and in doing so, considering all modalities.

    In summary, I believe that we need to put much more emphasis on how the human aspect of PLM and design these systems in ways that are aligned to our innate predispositions for acting in the world. Just my ideas…

    Lars