PLM Philosophies Collide?

PLM Philosophies Collide?

Somebody asked me last week about how I see th future of PLM… Does it look like-BOM or like-Workflow? I found this question very interesting. Bill of Materials and Workflow (or process management) are fundamentally two most important pieces of PDM and PLM systems for many years. So, we have them already in place. However, thinking about the future – what will be a dominant solution? Do we need re-invent the wheel? Is there any conflict here? I want to elaborate about both to see what future PLM looks like.

Bill of Material World

BOM is considered as a foundation of design, engineering and manufacturing. You can see it everywhere – design BOM in CAD system, Engineering BOM, Manufacturing BOM, Support and Service BOM. You can follow a product lifecycle by discovering different bill of materials. You can find lots of methodologies and systems that help you to handle your Bill of Material world. These things are really complicated. Bill of Materials represents many issues related to product development and in the end of the day you can think about a virtual Bill of Material representing everything.

Workflow World

Processes (or how we can simply call them Workflows) are very important for an organization too. They are a life blood of every manufacturing organization. Organization is running business processes and making overall execution of the business. We can classify them as local and global cross-department. Local are mostly focusing on departmental processes. The more interesting and challenging thing are cross-departmental processes. These processes are connected people working in different departments. Cross-departmental processes are very important if you think about the overall product lifecycle.

PLM Philosophies Difference

So, why I put BOM world against Workflow world? You can draw your organization in terms of Bill of Material and, at the same time, in terms of organizational processes. Is it about philosophy or about real development practices? In the early days of PDM and PLM, the main focus was absolutely on files, data management, revisions, Bill of Materials. Later, PLM system discovered “process world”. This “discovery” was part of the competition between PLM and ERP world. PLM systems made an upscale to compete in the high society. The “process approach” presented organic change to fit product development processes in organizations.

What is my conclusion?

I think, this question represents one of the biggest philosophical collide in engineering and manufacturing software. What will be the winning behavior in the future? It is hard to say. In my view, the end-game solution will need to provide answers to both sides of the problem. BOM and Worklow need to be equaly included into PLM solutions. Only together they can keep an organization to manage efficiently product lifecycle. Just my thoughts. What is your take?

Best, Oleg

Share

Share This Post

  • Vladislav Skoupski

    Your ‘two worlds’ are extremums and cannot exist in real life one world without other.

  • Graham Mccall

    Yes, I think there’s an interesting divide within the PLM market place.. There are one or two big PLM products (with roots in CAD data management) which are fantastic at BOMs and Product Structure but less so when it comes to process & workflow.. Other PLM products (typically without the CAD data management roots) are fantastic at process but not as strong when it comes to manipulating complex product structures. It seems to me right now you cannot have the best of both worlds. Typical end users still often think about BOMs first, process second. And they pick the best tool for BOMs. When they then come to add process, they are disappointed.. There’s a trade-off. But people are not as aware of this trade off as they should be..

  • beyondplm

    Vladislav- yes, In engineering software BOM and Workflow are deeply connected. However, the point is here is more about “platform” differentiation. You can build “a BOM platform” or “a Process/Workflow” platform. The question is “who will be dominant”? Who will change the course after collide? Another possible question is “what will happen after collide?”. Best, Oleg

  • Hemboy

    According to my view, BOM world and Workflow world are two sides of the same coin. They are actually the questions and also the answers themselves. What I mean to say is, BOM per se cannot exist without a process in it to get into the next stage. And the workflow per se cannot move forward without containing anything in it. So, both BOM and workflow complement each other and churn out a solution or a conclusion. According to me, future of PLM and will be that these 2 philosophies do not collide but need to complement and appreciate each other to come out with a futuristic PLM solution. Again it depends people, their mindset and how well they appreciate this concept or philosophy. There can be and will be lot of iterations of improvement in BOM and Workflow in terms of getting them stabilized, but, they both are husband and wife. They should not be divorced.

  • beyondplm

    Vladislav- yes, In engineering software BOM and Workflow are deeply connected. However, the point is here is more about “platform” differentiation. You can build “a BOM platform” or “a Process/Workflow” platform. The question is “who will be dominant”? Who will change the course after collide? Another possible question is “what will happen after collide?”. Best, Oleg

  • beyondplm

    Graham, you are right! People are obviously starting from BOM side. This is what hurt them more, in my view. That’s why we are still bad in delivery of “collaborative solutions” and collaboration is a “dirty” marketing word and not something that associated with productivity. I believe both problems need to be addressed together. Thanks for your comment! Best, Oleg

  • beyondplm

    Hemboy, Thanks for sharing your insight! Agree 100%. I specially liked your thoughts about iteration between Workflow-based and BOM-based solutions. In my view, this is a real path forward. Best, Oleg

  • Milt

    Funny, I have more trouble rationalizing the BOM oriented view of PLM with the “source code control for CAD files” view of it.
    They are, of course, intimately related (in some scenarios BOMs can be abstracted from the design) but not usually in simple ways. This, of course, leads to the need for complex Workflow, BPM and other types of EAI. The challenges here are not fundamentally different than they are in other enterprise software domains except that design data is astonishingly more complex than the simple relational DB data that comprise most other enterprise systems (ERP-financials, CRM, SCM).

  • To me, the proper approach to PLM is something more than a BOM or a process. I can’t say what, as I have yet to find the words to articulate it. I think of it this way, a BOM is to PLM as a 2D drawing is to a 3D model. Useful certainly, but a 2D drawing fails to completely capture what a 3D model can document. 3D models can now do more than define geometry, but can define “Design Intent’, or the relationships between geometric features (and much more).
    PLM applications can capture more than a BOM, more than that the process used to control the BOM, more than just the BOM data.

  • beyondplm

    Milt, thanks for point on this issue. You are right! I found Design and Bill of Material relationships are very complex, and they are reflected in many design decisions and processes. The complexity of design data is reflected in complexities of PLM systems. Best, Oleg

  • beyondplm

    Dan, thank you for your insight! I like your definition of “design intent importance”. BOM and Process are two fundamental pieces. The future (after “collide” :)) system will be required to interplay between them in a more robust way. Best, Oleg

  • Yaronr

    Oleg,

    My philosophy is that Data and Process are two aspects of the same thing. Both equally important.
    This is true for all enterprise applications. It just happens that PLM data is more complicated than ERP or CRM, hence the complexity of software required to handle it.

    The trick is how to have both Data and Process aspects, embedded in an Application – work for the User.
    And how to make all three – Data, Process and Application – easy to customize and quick to change, or – agile.

    In existing PLM software it indeed looks like Process was added on top of Data, using a complex monolithic application(s), and therefore no agility, expensive to own, and unhappy customers.

  • beyondplm

    Yaron, thanks for your view! To manage processes without data (or meta-data, if you will) is a very complicated task. If I understand correctly, the ability of “specific PLM data” is a key enabler for Cordys collaborative engineering solutions. Right? Best, Oleg