Why is it hard to implement PLM workflows?

Why is it hard to implement PLM workflows?


One of the most painful topics in PLM is related to implementations. Let me be more specific. PLM implementation is combined from several steps – installing a system, setting up data model, importing legacy data and  implementing business workflows. I want to speak about that specific last one – business workflows. This is where things are getting very complicated, in my view. But let me step back to show you a big picture.

Workflow applications

You probably familiar with type of software – workflow applications. Surprisingly, the technology of workflow is not very sophisticated. Just think about ‘state machine’. It is easy to implement. It can be a bit complicated to scale, but good software engineers can solve that too. There are many available workflow apps available.

Things are getting more tricky when you actually need to create a specific workflow. This is where some aspect of workflow, such as friendly user interface can shine and provide you some advantages. However, the biggest effort in implementation of workflows is related to capturing of actual data and process from people (or organization) you are making workflow for.

Inflated expectations of enterprise workflow applications

Workflow technologies created significant expectations from businesses over the last decade. Actually, some vendors renamed workflow apps with a fancy marketing name – business process applications (BPM). Here is a typical sales pitch you can hear from PLM vendor selling you business process applications in a way of workflow solution:

“Product development and manufacturing are complex. It requires lot of collaboration and, more importantly, decision making. Departments and people should be aligned and work together to guarantee a timely decision process to happen. There are many examples of such applications – new product development decision (NPI), change management (CM), supplier quotation (RFQ). PLM business applications (workflows) can help you to improve speed of processes and make informative decision about your product development” 

So far, it sounds great. Where is the problem? The core of the problem is laid between workflow tools and people in the organization.

Implementation workflows – devil is in details

Any workflow application (PLM is counted in the list) is selling you an idea of configurable components you can design a business workflow almost without any coding (ask more about configuration vs. customization). And the assumption is that customer itself or service provider will make it happen. Even more, software vendor will sell you “industry templates” to leverage existing best practices. And this is 90% ready out-of-the-box.

The problem is that remaining 10% will take 90% of the time and will require a lot of legwork in your organization. It will require people and time to agree about final workflows, specific details about data that you need to capture and finally some coding to get missing information from existing enterprise applications, spreadsheets and databases. And it is very-very hard to do…  and it is very-very hard to use, because after all, user interface around “generic workflow” is boring and can easy create a set of unmanageable forms with data with the need to follow current status in the graphic representation of workflow.

How to kill PLM workflows dream?

I think few decades of PLM workflow experiments provided enough information to kill the idea of PLM workflow app in the form it exists today. The cost to implement workflows is high and the effort required from customer is huge. It also creates a set of inflated expectations. The trick to implement good workflows is mostly dependent on the person capturing data model and process needs from a customer. And it is hard, painful and unpredictable, which leaves almost no space to make your customer happy.

What is my conclusion? PLM is focusing on how to streamline product development and manufacturing processes. However, it doesn’t mean the best way to do so is to sell and implement workflow applications. PLM business process applications is a glorified envelope around workflow engine, which can give short productivity gain, but mostly leads to complex implementation challenges and slow ROI. Is there a better way? Robust product data management and focus on specific customer user experience can bring better results. There is a lot of space to innovate here. Just my thoughts…

Best, Oleg


Share This Post

  • Hey Oleg,

    Your post brought up a lingering thought I have had for a while which I thought I would get your thoughts. As mentioned in your post defining the workflows you want your system to use is very difficult for many reasons:

    It will require people and time to agree about final workflows, specific details about data that you need to capture and finally some coding to get missing information from existing enterprise applications, spreadsheets and databases.

    I wonder if part of this issue is our attempt to constrain workflows to a very rigid and well defined process. In most situations I think this is the challenge we have since most businesses are not rigid (some by designJ) and there is always the one-off case.

    My thought is instead of trying to lock down to a well-defined, cannot deviate from path strategy we try to achieve a more structured chaos method with only having states in the workflow that are 100% needed. I know that technically all states in a well-defined strategy are considered “100% needed” but are they really?

    What is your thoughts and experience with a structured chaos strategy?

  • beyondplm

    Hi Denis,

    thanks for sharing your thoughts! I don’t think that rigid workflow is an issue. Most of PLM workflow implementations are flexible and will allow you to keep flexible process going. Even more, one of the key requirements is to have flexible flows that can be triggered by different events (e.g. person absence, etc.). The real problem I can see in implementations is to be able to create a formal flow and get people in a company to agree.

    So, what could a structured chaos? One of the most successful flow implementation was just an ability to route messages with attached contextual data and voting/signature mechanisms. There are PLM systems that can do it in a very flexible way. Is it good for structured chaos? Not sure.

    IMHO, Workflows are just plain hard. PLM vendors are facing the reality of establishing workflows, which is costly approach to implement PLM.

    Best, Oleg

  • Thanks for the response Oleg.

    I think there might have been a misinterpretation with my comment of a rigid workflow. I was not talking about the stage of creating and defining workflows. As you mentioned most have a very flexible workflow engine allowing many options to accomplish what you want. However at the end of the day most PLM as well as other systems lock you in a very tight (rigid) workflow. All scenarios of your next step had to be pre-determined like a state machine. I know there are solutions and even some implementations which allow “Power edits” even for just a few users.

    It probably is possible to have a “perfect” (or at least really good) workflow for almost every company but it takes a lot of time to determine the correct workflow. The reality is that most companies do not spend enough time investing in this and why most users find the end result of the workflow rigid. This is no fault of the technology from the aspect that the technology does contain the feature set to describe the needed workflow. However my point is that maybe technology and implementations could strive for a structured chaos strategy than trying to create a flexible workflow engine that results in very well defined workflow. I do not know what this actually means but the idea is interesting at least to meJ

  • beyondplm

    Denis, I think you are absolutely right – company (and more importantly many people together) must spend a lot of time to make a correct workflow. I guess, nothing wrong here with workflow technology. It might be a problem of suggesting a different paradigm for user experience of building workflows and processes. I’ve seen many times how users are looking how bring more undefined tasks and routes to workflow just because users cannot finalize the right behavior – there are too many options.

  • Pingback: PLM Workflow “California Roll” Style | Daily PLM Think Tank Blog()

  • McCheeseFist

    Workflow for PLM systems are laughable. Integrate with SharePoint guys… we all have it, its workflow is untouchable.

  • beyondplm

    Not sure what you mean by laughable. Can you clarify, please?
    SharePoint has some workflow capabilities, but in many cases, the integration cost won’t be justified if a company already using PLM system. What is the cost of average SharePoint implementation?

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » PLM workflows are dead. “Interactive” user experience is coming()

  • Pingback: PLM workflows are dead. “Interactive” user experience is coming | Daily PLM Think Tank Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » PLM Workflows: balance between value and complexity()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog AI can remove mental load of PLM workflows - Beyond PLM (Product Lifecycle Management) Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog Will companies abandon PLM workflow idea? - Beyond PLM (Product Lifecycle Management) Blog()

  • Pingback: Will companies abandon PLM workflow idea? | Daily PLM Think Tank Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog Why PLM sales are stuck in overwhelming workflows - Beyond PLM (Product Lifecycle Management) Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog PLM workflows and agile design design - Beyond PLM (Product Lifecycle Management) Blog()