PDM vs. PLM – Is this about Process?

I was reading interesting article during the weekend- PLM & The Importance Of Process by Gary S. Vasilash. Gary is the founding editor of Automotive Design & Production (AD&P) Magazine.plm-vs-pdmThere are few very interesting points were made by Gary and I liked it very much. Gary is discussing PLM topic with Twila Osborn, Lean Manufacturing and PLM, Computer Sciences Corp. (CSC; csc.com). Started with a solid statement came out of CIMData about strategic importance of the process for PLM, later Mr. Vasilash made some very important notes about handling of design data and BOM. “Who owns BOM?” Excellent questions.”The BOM is a corporate asset, not an engineering asset.” Sounds like PLM is the best candidate to own Bill of Material. However, a conclusion made immediately after mentioned that PLM companies (like DS and Siemens) invested a lot in Design Process, and it really works today. What sounds to me, BOM story is not as completed as a design story for PLM systems. You can hear a lot of “buts” when you start to discuss BOM story of PLM. “The mindset needs to change; it is not just CAD data.” About most of PLM implementations in organizations “It might be very old, out of date. It might not have an integrated BOM. Some have BOMs based on proprietary technology, built from scratch. They might have a PLM system, but they’re using it as a PDM system.” A lot of “buts.”. What is very remarkable is a short review of top three PLM vendors (DS, PTC and Siemens). Unfortunately, this summary is corp-
What will be very interesting is to find analyzes related to who owns Bill of Material and how to manage a BOM and related process beyond engineering on the corporate level using standard PLM systems.

But, I’d like to get back to the original topic PDM vs. PLM. I asked many times about what is the difference between these two from customers, on conferences and during professional meetings. I think, professional community made a tremendous job in trying to explain it, but these two domains are continuing to confuse users.

I thought about few definitions to make before:

Product Data product design, bill of materials
Product Data Changes ECO-related information including design and Bill of Materials.
Product Lifecycle information and process-definitions related to global product development stages.

I think PDM is definitely about first two. However, getting back to Mr. Vasilash’s “The mindset needs to change; it is not just CAD data”. As soon as we can come to matured Bill of Material implementations (not home grown as it today), PDM will become mature to manage a complete scope of Product Data Changes and not only Design portion.

PLM definition is very fuzzy, in my view. However, this is definitely about how to move from Product Data Changes to Product lifecycle and corresponded to organizational processes. There are many business process management software suites (BPMS). However, all of them won’t be able to provide a relevant answers on product lifecycle. Because “product data” is a key asset that needs to be taken into consideration to manage organizational processes around product.

This is not the first time I’m touching this topic. I’d be interested to hear your voices and comments.



Share This Post

  • AndyF


    Where I work we don’t talk so much about PDM, PLM, ERP anymore since we find these terms to cause confusion. We instead try to focus on business issues and problems. Our vision at the moment to provide design engineers with a “content rich BOM”. That being, a BOM where a simple right click of the mouse provides the engineer with information on each part number. This information would include items such as: cost information, tooling status, field failure data, inventory level on hand, vendor contact information, drawing status, etc.

    Some of this information comes from our “PDM” system, some comes from the “ERP” system, some comes from home-grown legacy systems with no fancy label. In the end what matters is that the decision maker has all of the relevant info at their fingertips when they make a decision.

    We haven’t found any PLM system that can actually provide all of this information at a reasonable price so we’re building our own federated system using the Aras Innovator toolkit. If you know of anyone who has actually gotten a full blown PLM system installed (and are happy with it) let me know. I’d love to talk to someone who is successful with PLM. We’ve been talking to customers, vendors, peers for years and haven’t found anyone yet who actually has a complete rich BOM system up and running.

  • Andy, Thanks for your comment! ENOVIA V6 provides federated BOM functionality. It can be considered as “content rich BOM”. However, based on experience, there is a significant “design” flavor. Have you had chance to evaluate ENOVIA option? I assume Aras and your own development has a different price point compared to DS portfolio… Best, Oleg

  • Srini

    Oleg/Andy, Dont you think the latest flavor of Teamcenter 8 from Siemens would be able to handle the content rich ‘BOM’


  • Brian

    From my point of view PLM is almost entirely about process. The data has to be available to the users and the only way you can get reliable data is through rigorous processes.
    Company policies, procedures and work instructions must be written to provide the framework in which an effective PLM (and other Enterprise) system can operate.
    Where possible workflows must lead the users to follow the required process and the side effect of following these processes is that the right information is available when it is needed without any more effort than is absolutely necessary.
    Without the process which covers both the company requirements and the PLM system it doesn’t matter how good the software is. It will not achieve the results you are after.
    Flexibility for certain stages of the process is important but this flexibility must be excercised within a robust framework.


  • Brian, I’d say, not everything in product development, can follow rigorous process. For example, design activity is very much interactive. The same, probably, related to various “decision support” situations. So, formal and in-formal should co-exist, in my view. Could you, please, give me an example of “robust framework” you mentioned? Thanks for your comments! Best, Oleg

  • Emmanuel

    Brian, your view of the process is right, but I believe already out of date. There exist tools today to model a process, and make it executable (BPMS, Change management tools, etc). It’s not just a written description. This makes it possible to answer automatically, at any time the question any engineer asks in a big project: “what should I do now?”. Now, because the process is executable, it is described in actual files. And these process files should be not only stored in the PDM tool, but also version-controlled, and even configuration-controlled. Think of a big project, with different disciplines involved: mechanical engineers, EDA guys, software guys, systems engineers, safety guys, you name them… These guys have different processes, dipending on their trade. So the process to develop a complex product is a configuration, i. e. an assembly of different processes which may evolve independently from a version to another. So the overall process (the configuration) will also evolve from version to version as its component processes evolve. That looks very much like version control and configuration control at least in software development. Hence, all the process-related files should also be stored in the PDM tool.
    My 2 cents (of a €) worth!

  • Emmanuel, I think you are right – there are tools like BPMS etc. The biggest problem, I see with these tools is their disconnect from meta data and Product Data. Most of the decision (or automatic procedures) the can do are actually requires pretty big chunk of information. Best, Oleg

  • Brian

    Oleg, You are right. Not every single thing follows a rigorous process. Design is a creative process. However, it is (usually) only at the very early stages of a product design that one gets to excercise “unlimited creativity”. Once someone (CEO,CTO,Customer etc) has essentially defined the product at the high level then everything flows down (out) from that in a progressively more detailed way. At each stage (Conceptual Design, Preliminary Design, Critical Design, Validation/Verification) there should be three high level process blocks which are followed. 1. Confirm the inputs to the process are complete and determine what the outputs from the process should be, 2. Do the “creative” design process to meet the inputs just confirmed, 3. verify that you met the inputs through the creative design process.
    At each major phase the inputs become more defined and the creative aspects become more restricted.
    This is essentially the “robust framework” that I mentioned. It must be supported by company policy, and procedures external to any software systems. The PLM system guides you through the aspects of the overall process which are consistent (change management, part definition, document storage, project management) through workflows or other mechanisms. It also holds the information for all users to see and for all external processes (say production, procurement and repair).
    The question of “what should I do now” for an engineer/designer should be answered through the Project Management process for new products and throught he Change Management process for existing products (although it is not that black and white I appreciate that). The designer is working to support the business and the business should be working to direct the designer along the best lines possible to achieve the companies overall aims. Very few designers would be comming into work on a given day thinking “so what should I design today?” Their managers assign them work which should be coming from Project managers which is in turn coming from approved projects that the company has sanctioned. Or they are working on Enterprise Change items which are again directed by a “higher” authority.
    As for BPMS I have no real understanding of what they might achieve but can surmise that they may, one day, become a common tool in design/manufacturing to help manage the overall company processes.
    I wonder, though, how often a companies processes really change and how often you want them to change? Change is difficult to manage at the best of times. Once a process is written and followed it takes a lot of effort to get users to adopt a new process unless there is a driver which forces them to adopt the new process like a new software system that just doesn’t work the way the old one did.


  • Brian

    Additional point. The three step process that I describe includes a Risk Assessment and Milestone Approval process as part of the third step. In this step the decision is made whether to continue to the next phase of product development, go back through this loop again, go to an earlier loop because requirements were found to be inadequate/incorrect or cancel the entire project.
    This gives management the opportunity to recommit or bail out based on current information at every major point in the Product Development process without unnecessarily restricting the designers in the “creative” part of the process.

  • Brian, Thank you for sharing of your insight and thoughts. What you mentioned as a robust framework make sense. At the same time, I have to mention that I see two possible levels – 1/framework you mentioned; 2/design collaboration. When first is much formal, second is more “decision oriented”. With regards to BPMS, I think they can solve (1). Most of them are advanced workflow-based product with well established administration and process handling mechanisms. So, to frame three steps in framework you mentioned confirm/do design/verify should be easy for them. Btw, I think most of PLM products today can do it as well. The problem I see is that 3 steps you mentioned in most of the organizations I seen is cyclic process. And there is a lot of parties involved into this cycle. To establish such process is much more complicated task in my view. Regards, Oleg

  • Brian, this 3rd step validation you made is exactly point I mentioned before. Everything is going in cycles. And process in most of the cases is very unpredictable. This is brings customers to the idea of flexible/on-demand processes that they will be able to hold and change in every time. In the end their process requirements becomes very close to “email” capabilities from flexibility standpoint. Regards, Oleg.

  • Jim

    I agree with the notion that one major distinction of PDM versus PLM is process. There has been some work done within the PLM vendor community that acknowledges the need to understand and implement the “rigorous process” that Brian mentions. Furthermore, I agree that there is an appropriate time when tacit activity best serves the innovation process (early rather than later) but in complex design environments, the sooner one can define the “what” and “how” that needs to be done, the better the PLM environments/tools can/will act to orchestrate the lifecycle complexity. There are well proven frameworks in industry (for example CMMI-DEV) that when incorporated into the PLM application framework, can serve well as the engine to manage enterprise “process rigor”. I understand that PTC has been working this agenda aggressively. I’m not sure of the others though, but would be interested in hearing more about what Dassault and Siemens are doing in this regard (having read the article you referenced).

  • Jim, Thank you for your comment! I think good balance between “rigorous process” and “tacit activities” is what can create ideal PLM process management environment. Best, Oleg

  • BOM does not have any Business function mapping. Henceforth, it does have any Owner. However, BOM is a integration feature in Any Manufacturing and Operations System to see data logically arranged. Since, view is to display clear information related to Design and Manufacturing.

    Organization, are looking to see the same BOM what exist in a like to build and in like to Order.

    In my understanding, None of the applications in the market has such capabilities as OOTB features.

    Also, it Doesn’t matter where BOM data exist, whether it is in PDM or ERP? What matters is how the data is view and interpreted?

    Here I can say if configurators are made independent of PLM and ERP. Configurator has ability to show like to build and like to order BOM. Also, this means that Sales and Engineering Department can access same information instantaneously and can communicate each other using Engineering Configurator and Sales Configurator.

    As these two departments has the ownership to propagate information to manufacturing.

    By Definition PDM application is to manage data pertaining to product and this definition is compounded by Productivity features which are on the lines of PLM strategy can be achieved easily.

  • Paritosh, Thank you for your insight. Actually, I have to agree, not much “BOM-like” application on the market. Most of Bill of Materials tools are belonging to the specific domain application – ERP, PLM, PDM etc. However, I do see a problem to share ownership on the same BOM between two departments and two systems. Best, Oleg

  • PLM is full of processes that are driven collaboratively; the problem between two departments is a change management issue. This issue is due collaboration.

    In my understanding, the issue of ownership is lack of visibility in change management process cross functional synergy created is not handled properly and this is due to collaboration because it is nothing but communication and coordination in asynchronous way.

  • Paritosh, I agree collaborative processes create some uniqueness in the way they need to be implemented and handled. Cross-department issues are just additional load on the complexity of such processes. I see very small amount of implementations today close to solve it because of the following reasons: data and integration complexity in organization, communication and change tracking. Thanks for your comment! Oleg.

  • Paul

    Two separate threads as I see it. The first point about the ‘rich BoM’ which includes things like design data, CAD model, parameters also inventory levels etc. There is a difference here between ‘created’ data which needs change control – i.e. the usual configuration controlled set of data within a PDM system (although this is growing as part of PLM as areas other than engineering/manufacturing get invovled). The other data is what I coarsely define as Logistics and I would see as being Read Only in the ‘rich BoM’ within PLM – you don’t control inventory via configuration management, similarly life, hours used, etc. I expect any of the PLM solutions could be made to provide access (visibility) to this (typically) ERP information, the key is not to put it under configuration control (ECO release to change stock levels anyone?).

    The second thread is really the LM bit of PLM – the greatly extended reach of process control under PLM (cradle to grave, every discipline) as opposed to PDM (typically engineering data managed during design upto release to manufacture). As Brian says, the key is a consistent framework of Gateways which govern the process across the enterprise. When can process X in department A start – what must have finished, what else must have started etc. The depth of management of that process within the tool will depend on the appetite of the business, the stability of those processes and the nature of the business (regulatory compliance etc). Again, the major PLM systems all have some level of process control, some are better at it than others, some manage external steps better than others, some are easy to maintain, some are difficult. Also bear in mind that the more process definition there is within the tool, the more the definition of that process must be managed as it implements Authorised Signatories by definition.

  • Paul, Thank you for your comment! Your two threads reminded me basically “data” and “process”. I had lots of discussion with Jim Brown during the last two weeks about which come first “data” or “process”. However, in the context of your thoughts agree absolutely. Rich BOM- this is what everybody needs. On top of that, we need an ability to involve people in to different types of decisions and changes. Sounds like a very simple model for PLM… Why it is so complex when it comes to the implementation??? Best, Oleg

  • Pingback: How to Get PTC Referrals()

  • Pingback: PLM: Data vs Process – Wrong Dilemma? | Daily PLM Think Tank Blog()

  • Vinay Chavan

    Nice article. Keep Writing sir.

    I work for a medium scale comapny. where we use DS ePDM but before i joined it was used just for data storage and security.

    After i joined i studied and standardized use of ePDM by making custome process flow according to requirment. and several data cards and custom BIll of material. Which in return saved our ample time in data migration when we were implementing SAP for BOM.

    These facts i have mentioned here is because these tools and software made the task so easy to understand for current and new employee. its simply amazing.

    I am exploring more day by day. I am just loving my job.

    And sir please keep writing.

  • Vinay, you are welcome! Please keep commenting. Best, Oleg