Product and Process Models in PLM – What Should Come First?

Common definition of the process – “a set of activities leading to the desired outcome”. Despite on such simple and straightforward definition, implementation of processes in PLM delayed and very often lead to a significant complexity in implementation. I’d like to analyze and discover why it happens and what other factors can influence process implementation in the organization.

Process Model.
It depends on tools, technologies and environment customer has, processes in the organization can be modeled and implemented differently. Normally, there are more than one enterprise systems in the organization that is able to handle process modeling. Starting from middleware and specialized BPM software, following by enterprise systems such as ERP and PLM and ending with various Enterprise 2.0 collaboration tools. Process model, these days, can be developed by multiple tools. For the last few years, BPMN becomes somewhat similar to the standard process definition tools. What is the main problem? Data. Various products and corporate data needed to be injected into process implementation to make it work.

Product Model.
Originally started from CAD models, product model developed as an extended set of information describing various aspects and dimension of product – model, bill of material, requirements, items, information about customer requests etc. As we learned from process model definition, this specific product model information is needed to make process definition. Processes actually need to access data to trigger tasks and events to handle processes.

So, what should come first? Product or Process? My conclusion is that lack of the rational product model can drive to a very high level complexity of process definition and implementation. Product Model is the foundation of product lifecycle. Without a well defined product model that can cover enterprise product definition scope and related disciplines, development of a process oriented PLM environment becomes a complex and not achievable task. Organization implementing PLM as a process environment needs to invest first in implementation or adoption of the product model that will be used as a process foundation.

What is your opinion? What was your experience in similar tasks and efforts?
Best, Oleg

Share

Share This Post

  • egg or hen ? what should come first ?

  • Stanislas

    I’ve been involved in a PDM and then PLM approach.
    The PDM one offers us the ability to fix the rules about Product Model as it was the first to come.
    Then when we move to PLM, we describe it first via the Project Management, and keep the PDM as it was.
    The third step was to merge the PDM inside the PLM which allow us to work on Process Model to describe Product Model.
    We didn’t have a lot work to do has the Product Model has been fully described and accepted with PDM.
    So in my mind, the first step for future PLM adopters should be to describe Product Model as Process Model should have it as a target.

  • Thomas

    To Stanislas:
    Please kindly, can you share with us which PDM you merged into which PLM?
    Thanks a lot
    Thomas

  • Hervé, You can ask also this :)… Best, Oleg

  • Stanislas, Thanks for your comment! You emphasized well, the importance of product models to successfully model and manage processes. That was exactly my point… Best, Oleg

  • Stanislas

    Yes, sure Thomas!
    We began with Matrix (heavy client) in ’97. We included the CAD Data in 2000. And we switch to eMatrix after 2003 for Projects first. The full inclusion of PDM has been a part of the PLM project afterwards. As it’s the same editor, we got a lot of help from him. Now, we fully integrate Project Management, Product Data Management, Quality & the last part of our PLM is Labs tests.

  • MOX

    what lifecycle to follow if no product is in place?
    by defining and agree on the product model a lifecycle comes into place. Let if live for a while without an automated lifecycle and measure. Take the best practises and use as a base for your PLM. Measure again and the effects of automated PLM will become obvious.

  • George Hielscher

    It’s hard to define the scope or focus of the process model without having a product design and lifecycle (or a set of them). In my opinion, when the process is related to product development, it is easiest and best to define the product model first. For a large project, the product model is structured to fit the organization of the company (design and manufacturing groups). The process designs generally follow the required organization and product design.

  • Cam Bickel

    The way I see it, the product data existed before PLM was invented and it will live on after PLM is replaced by something else. Same case with product data from acquired companies. So, you really don’t have a clean slate with the product model.

    The process model is much easier to make dramatic changes when introducing PLM. To some extent you have to deal with the change process model that is built into the PLM package. On top of that you can design your process as needed and it does not depend a whole lot on the actual product data. If anything, it affects metadata. The challenge here is where metadata is new or existing metadata is dirty so your process cannot be tight without a data cleansing exercise first.

  • Some details about my previous comment:
    My answer through a kind of a joke “egg or hen ? what should come first ?” was not intended to be taken at first level only.
    Sorry to give more details hereafter.
    What you call “product model” means maybe the description of the product “as it is” (i dont know what this means, but our cad education leads us to think that the product model is somehow the 3D model, as you say it (may be with additional attributes, but not so far).
    What you call the “process model” means maybe the way the product model is manufactured (at least, process is dependent from manufacturing “things” : tools, routings, …).
    So product model = “as-it-is”, process model = “as-it-is-got” ; ok.

    Now let us play with the poultry.
    I could say that egg=”as-it-is”=product model and hen=”as-it-is-got”=process model…
    or also reverse (it depends on the point of view of the modeler): egg=”as-it-is-got”=process model and hen=”as-it-is”=process model.
    Your question about product model or process model, who comes first, can be “instanciated” on the poultry case:
    egg or hen, who comes first ? or reverse hen or egg, who comes first ?
    The apparent paradox that is very visible on the poultry instanciation is now very clear on the “generic” question: product model or process model, who comes first? So this question is not a well-formed question.
    Why? how can we solve the paradox ? the same way we can solve it for the poultry case: the product model and the process model are two “visions” of the same object : the product. Both visions are “simultaneous”, they are not “sequenced”, they are complementary, like the two sides of a coin. You cannot have a coin with only one side, can you ? A coin has always two faces, and one does not come first.
    This a wrong paradigm to consider that the product model and the process model are different things, they are the same thing, viewed from different points of view.
    And I consider that the “temporary capability limitation” of current softwares that deal with product model and process model, which are all considering the product model and the process model as two different models instead of one unique model, is just temporary.
    I have a dream (sorry): One day a PLM software will consider one unique model for product and process, so we can forget the vicious loop between “egg or hen, who comes first ?”
    NB. This is another avatar of the question about the multiple BOMs that would have to be “synchronized” (why? is this a “well-formed” question to ask “who comes first”? the EBOM or the MBOM? egg or hen?) instead of being considered – within the softwares – as a unique BOM with different points of view.

  • MOX, thanks for your comment. I agree, product and product data lifecycle is prerequisite for successful process mode. Best, Oleg

  • George, Thanks! I had the same assumption- product comes in the beginning… before processes. Best, Oleg

  • Cam, Thank you! It make a lot of sense. Especially your example with acquired companies. This is something, I’ve seen many times. Best. Oleg

  • Hervé, Thanks a lot for your insight! I liked your poultry story :)… The idea of single model for product and process is not viable in my view. The reason is the same as one because I think all trials to bring enterprise to a single model/application can rarely happen. Thanks! Oleg

  • Well, it is not because the model must be single that the application must be single.
    Imagine a real single model that could be built by many applications, each of which is constructing a piece of the model: several stake holders coming from different businesses are collaborating towards the construction of this single model : people from the “product” view (the product as it should be, the “functional” view), together with people as it should be built, the “physical” view). This is already the case in software engineering, the software workbenches are enabling the collaborative construction of a single model, why could not we dream that in the future the “other engineering softwares” could not provide same capabilities?

  • Oleg,

    There is a movement towards an additional style of process management, integrated with BPMN, but distinct. More towards something like “agile project management”. Information and work product are in the driver seat, as well as the human worker, who majorly decides on how to continue. We call this “case management”, although it is much broader applicable than just to what’s traditinally called “case management”. It is very applicable to managing innovative processes, such as in SCRUM. You might have a look at the OMG RFP (see http://www.omg.org/cgi-bin/doc?bmi/2009-9-23 ).
    Note that the submission process, the process that aims to deliver this standard has started. If you are interested: be invited to join. You might also have a look at e.g. the Cordys website(www.cordys.com ) and search on “case management”. If you want to talk further: just let us know. Note that we also work on integrating this more into the PLM world. You might also look on our website at what we do in the PLM world itself, such as in the area of PLM data federation.

  • Hervé, On the level of dreams, it is ok. I want to have a single system. However, in practice, and also from the software lifecycle standpoint it remains as a dream :)… Enterprises are living with reality of multiple systems that deliver best of the bread functionality. So, in the context of my post, I wanted to point that first focus needs to be on the product model and second on the process. And, if you can do it in the single application, it can be just great! Best, Oleg

  • In our company we had a model for the product life cycle that was pretty much aligned with the stage-gate product development process.

    As we became more ‘agile’ we adapted this and realised that in fact it’s a multi-level model: we have a PRODUCT lifecycle management process and underneath we have multiple PRODUCT RELEASE development projects. They each follow a PRODUCT RELEASE PROCESS and there are multiple overlapping PRODUCT RELEASE lifecycles.

    The PRODUCT and the first RELEASE are aligned at the beginning, and the PRODUCT and the last RELEASE are (somewhat) aligned at the end.

    Now how you map this to PDM and PLM is another long story 🙂

  • Jez, thanks for sharing your experience. I think, we need to stop with PDM and PLM mapping…. It brings a huge amount of marketing and emotions. We’d better talk about models and processes. In your example, what happens between first and last releases with product alignment? Is it two processes that going in parallel? Best, Oleg

  • Oleg asked: “In your example, what happens between first and last releases with product alignment? Is it two processes that going in parallel?”
    Answer: there is no specific PROCESS happening to the PRODUCT except through regular sales and support activities; in its lifecycle it’s just ‘available’. Meanwhile, multiple major/minor/maintenance RELEASES go through their full lifecycles.

  • Jez, In this case, I just see “Product Available” as a “data” available in the context of various processes (like you said major/minor/maintenance releases). This is where my “product model” plays a primary role in comparison to process one. Thanks! Oleg PS. Of course, both models are important.

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll