PDM vs. PLM – Is this about Process?

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

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

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!

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.

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

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).

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.

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.

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.

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.