Workflows is one of the fundamental elements of all PLM products today. Workflow abstraction is easy to understand to engineers and it drove it initial adoption. Think about process, diagrams, logic of making progress in product development – workflow seems to be a logical choice. And it was… for the last two decades of PLM software development
But here is the thing. With the obvious logic and clean abstraction, to implement workflow is not an easy task. As implementation goes into planning stage, IT and managers are thinking about the ideal processes – everything goes well at this moment. However, as soon as application runs into the reality of real process, the problems are starting to come. What seemed as linear, starts to be circular. In real life, things are not running sequentially – people are doing many things in parallel. Design and product development process is very iterative and to express it using simple workflow diagram is not a simple task.
Below few comments from my readers on LinkedIn article related to the nature of engineering workflows and current PLM paradigm:
Stephanie Green: PLM still is a linear-process-based paradigm. In spite of all the conversation around collaboration, it still is, for the most part, just moving a set of data or a document from one person to another for some action. Yes, we have better dashboards, but that is a view of the data, but not interaction with the data.
Erich Meier: Most of the engineering processes are NOT linear, although most of the tools treat and implement them as such. Engineering processes are highly iterative, have multiple dimensions, and need to honor variance instead of eliminating it. In fact, that’s what differentiates them from most of the other typical business processes. Those things are not easy to describe, that’s why we are all struggling to even express them 🙂
These comments made me think about Workflow paradigm and its role in current PLM development. You might remember my article few months ago – Why is hard to implement PLM workflows?
The idea is great, but the devil is in details…
The devil is in details as you think about the implementation. PLM workflow is selling on the 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.
10% of customization = 90% of complexity
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.
Will interactive user experience replace workflows?
Everything is connected today. So, users are thinking about getting connected, interacting and working together. The idea of workflows moving data between message inboxes might be appealing to some business managers thinking about formal organization. But looks like outdated for people operating in connected world. Especially, when it comes to new generation of people. Real time access to data and simultaneous collaboration are key element of new connected behaviors. I tried to answer on this question – PLM workflows are dead. Interactive user experience is coming.
What PLM vendors are thinking?
My attention was caught by Aras PLM article – Effective creation of PLM lifecycle and workflows by David Ewing. It compares workflows in Aras PLM with moving a collection of items through a process. As an item moves through the process, it is likely to change states. Dave is a fan of modeling tools like Visio and Draw.io. According to him such tools can be used ideally to define workflows and translate them into XML language and (I guess) transfer into Aras PLM. However, the following passage is a key, in my view:
“Nailing the process before configuring in Aras is key. Get feedback from all the participants early and upfront.” This is an area I CANNOT STRESS ENOUGH: Really nail your process. PLM software is no better than your process definition. Remember the old adage – “garbage in, garbage out.” Luckily Aras Innovator allows you to create customized complex lifecycles and workflows to suit your needs.
And getting feedback from the users is another key point! This means you NEED to “get your boots dirty” and go see the folks doing the work. I have been in situations where I trusted a spec written by management and after we deployed our work everything fell apart. Don’t do that!! (Not that the management was wrong – they just didn’t know all of the process nuance)
What is my conclusion? Workflow is a reflection of the real process. The ideal workflow is a good starting point, but you need to get your hands dirty with workflow details. This is a reality and a problem of analog PLM paradigm – your tools are as good as the process and customization you do. Workflows are easy to start. Especially using graphic diagramming tools. But you can quickly run into complexity of the implementation and the reality of your organization. People are running product development and manufacturing process. Customers likely to dump your workflow implementation if it will add an additional level of complexity to organizational process management. Just my thoughts…