Ask anyone in PLM world about processes and an immediate response would be “workflows?”. This is where a traditional wisdom of process thinking took all PLM developers. Processes were translated into an attempt to create a formal framework on workflow – steps to follow to achieve results.

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

Workflow paradigm brings a lot of good things into engineering and manufacturing software. At the same time, workflow complexity is well known. In my view, the complexity of workflows is one of the inhibitors of PLM progress.  

PLM Process: Flowchart vs. Rule-based workflows?

The definition of process is somewhat tricky. PLM vendors developed different technologies and tools to define processes. Most of them are traditionally workflow-oriented. If you talk to engineers in an organization, you will discover that flowchart is widely used way to define a process. You can see below few examples of such a workflows.

We can find such definitions in all PDM/PLM systems. Definition of processes done in this way is very straightforward. However, when processes become complicated, the overall definition of a process can become a bit complicated too. You can see one of the examples below.

At the same time, definition of processes can be done verbally as a set of written rules. Such a workflow definition can be done much easier and can be easy read and interpreted by people involved into people’s definition. You can see a simple example of such definition created on the whiteboard.

I found both practices implemented in SharePoint Designer 2010. You can find similar implementation in other business process management systems. However, I found MS SharePoint case as a very representative one. You can create flow-based process definition using MS Visio based flowcharts.

At the same time, you can use a very interesting implementation of rule-based processes. I found such rule-based definition of processes as something that can be easier understood by users.

The ability easy to define a process is very critical. Process definition is one of the most complicated parts of PLM system implementation. To have a tool that allows you easy to understand and define processes can become an important competitive advantage for any PLM system. I think, systems are evolving and create new ways to implement processes.

How many workflow tools does organization need?

The challenge of manufacturing organization and process management is that every enterprise software (PLM included) developed some sort of workflow and process management tools. Which is actually leads us to the question – how many do we need?

With such a large number of capabilities, I noticed that companies often develop multiple solutions to manage these processes – and these solutions are tightly connected to existing products. From a particular standpoint, it will let customers maximum the reuse of product capabilities and organize a dedicated process management and workflow solution integrated with data managed by a particular system (PDM, ERP etc.). But, one of the biggest drawbacks of that kind of situation is that organizations have multiple silos of disconnected solutions, with multiple process/workflow management implementations.

So my question is how many ”workflows” do we need in an organization? More specifically, I’d like to think about how to organize separated and disconnected workflow and business processes management solutions. Following are the priorities needed to organize this solution:

1. Establish a single process modeling environment
2. Multiple process deployment
3. Immersive access to workflow execution in user environment

A single process modeling environment would user to organize and maintain a single picture of the organizational processes. My preference in this case is IT platforms. Organizations normally chooses one IT platform, so having an environment in which to model processes makes a lot of sense to me. Consolidation around popular notations such as BPMN can let you use 3rd party tools, in some cases, if they provide additional benefits in managing of single process model.

Multiple process deployment can resolve the procedure of integrating processes into many existing systems. This depends on the specific system deployed by the company, and can be done in different ways – but the goal here is to keep the process connected to specific solution as much as possible (i.e. product data management and/or any vertical solution in the organization). This will allow existing systems to maintain the connection with data management using this system/sub-system. Access to this data is very important since most of process logic, in many cases, depends on this information.

Most of the processes require user involvement for control and data submission (i.e. document approval, ECO management etc.) Immersive access to process/workflow execution and control from the regular user daily environment is critical – because this is what guarantees the user’s acceptance. A process solution will be live only when customers will use it rather than bypass it.

So, where do you start? Here is my step-by-step proposal

1- Analyze what system can be used to keep overall control of processes in the organization;

2- Choose process modeling tools;

3- Analyze how to connect multiple workflow and process management solutions that already exist in the organization;

4- Give priority to solutions that have immersive integration in the user environment.

What is the right time to implement PLM workflows and processes?

Every time I’ve been talking with customers about processes, work flows and PLM, the conclusion was that one of the important factors of process implementation is to choose right timing. You need to have company ready to think about process improvements. So, the point was very clear – to change business processes in organization is not simple. To make it happen you need to have all stakeholders on board and do it with timing, which will be aligned with overall organizational changes.

In today’s turbulent time, many companies are thinking about rationalization, improvement and changes. So, I think this should be right time for companies to think about PLM processes in organization. I want to propose a possible 3-steps plan to achieve it.

Step 1: Analyze

Make analyses of existing organizational processes. To focus on these processes that require improvement first. Capture existing process definitions with process/workflow tools you have in your PLM systems.

Step 2: Plan

Plan your data and IP management for these processes. Your processes and workflow can work efficiently only in the case they will have access to the right data. Without accessing right data, your processes will not reflect reality, and you will not be able to follow them as well as use them for your decision support. So, by creating right data modeling and/or connecting PLM system to right sources of data, you will prepare solid basement for good process orchestration.

Step 3: Optimize

Optimize and run your process/workflow environment. As soon as you existing processes and data in your hands, you can start planning process optimization and executing. This is time when you will need to analyze captured processes, make improvement and right first pilot and second production environment.

PLM Workflow Tool Dream

Process management is a very important part of any PLM software. You can find one in every PLM system. There are so many ways to define and manage process. Few years ago I captured some of them here – PLM Processes: Flowchart vs. Rule-based? While, I believe, we can agree about importance of processes management, I found hard to find simple and powerful implementation of PLM workflow. I believe this statement holds for every enterprise system. Time ago I had a dream that PLM vendors will adopt best in class BPM (Business Process Management) tools and infrastructure. My dream didn’t come true. Instead of that, the reality is that every PLM system has some (not the best) workflow implementation.

One of the processes I can see actively happening these days are “un-bundling”. We can see many new tools and apps that “un-bundled” from existing large software suites to solve a specific problem or fulfill a need of company or people. To follow this trend, I wanted to come with a description of what I call PLM workflow dream – list of features for an ideal PLM workflow system.

1- Visual designer.

Majority of people think visually when it comes to workflow. So, visual designer should be a tool to draw a workflow in an easiest way, put boxes with activities and connect them together. It would be very interesting to have it done in a collaborative manner – typically, you need more than 1 person to define a good workflow.

2 – Drag-n-drop activity planning.

There should be a very clear way to define activities. In most of PLM systems, activities should be connected to something that happens in your system (eg. Part status change; Document release, etc.) To connect them together with flow activities is a key.

3- Visualize and test.

Designer should provide a way to “lineup” worklow into simple set of events (boxes) without cumbersome lines/nodes intersection mess. No cyclic visualization, unclear sub graph connections etc. System also should provide way to test the workflow with dummy or real data.

4- Program activities easily.

Each activity node should support a notion of process such as failure, alert, delegation and user action (if needed). It would be really nice to have some predefined “processing rules” such as how to react on people absence and mistakes. The interface to set these values and action should be user friendly without additional complexity.

5- Failure programming.

I need to be able to program what happens in case of general workflow failure in terms of who to call and what to do.

6- Programming scripts.

The ability to attach programmable scripts to every activity/note. These days, Java script is probably a standard to should be just adopted. Don’t invent yet another programming language. Testing ability should support debugging and data dump for analysis.

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

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.

The future of “voice” in PLM workflows

Processes and workflows is a big topic in PLM. If you think about PLM as a way to manage a full scope of product development processes in organization, workflow is a foundation part of technologies and tools to implement that.

The definition of PLM process is usually complex and can come as workflow or rule-based. You may ask – why is it complex? Very often the answer is simple – enterprise organization is complex as well as communication between people is complex too. However, this is still not a reason to keep them complex in the future. In one of my earlier posts about PLM processes and implementation confusions, I shared my classification of PLM processes into design collaboration and change processes. People are still one of the most complex part of process implementations. Especially, if you speak about engineers. To manage engineering processes is like herding cats. Read more in my PLM and Engineering (task) process management post. One of my conclusions – we need to simplify process management.

In a real life, email remains one of the key players in process-driven implementations. There is nothing wrong in email and the requirement to integrate PLM processes with email is still on the top of PLM process requirement list. I honestly think that I need to update my workflow dream list.

The question how to simplify workflow and make collaboration easy is on the top of workflow and process management professionals. Some of PLM mindshare companies are focusing primarily how to improve process management.

One of my previous ideas around process simplification was related to mobile technologies. Earlier today, my attention was caught by Benedict Evans blog – Voice is the next big thing in mobile. Article speaks about different form of communication – text messages, instant messaging and vocie. Here is the passage I liked:

…there is a lot of scope to innovate around the actual voice experience in much the same way that we have seen around messaging apps.In messaging we have seen two levels of innovation in experience. WhatsApp delivers ‘SMS 2.0′ – it does the things that telco technologies like IMS were supposed to add close to a decade ago, but not much more, so far. On the other, we have things like Line, Wechat, Kik and Snapchat that actually change what messaging is, even before you look at the platform elements of their offerings. I suspect (but no more) that it is harder fundamentally to change what voice is than to create alternatives to a snippet of text, and so the basic voice experience might change less – the innovation, like WhatsApp, may be more about the handling and routing and setup. That is, it kills the dialer. That’s one way to look at Talko – it rethinks what ‘dialer’ mean when there is no DTMF (or pulse), and builds value around that.

I specially like the idea of “setup simplification” to make a call. Sometimes, to make a dial is complex or even impossible. Imagine, you have engineers and service technician working on the same problem. They are located in separate places. Modern 3D collaboration technologies can share visual information between them. They can even share photos or camera. But “chatting” or “IMing” in such situation can be a complex thing. To be able to establish voice communication can be a killer function.

Another example can be related to “change process” approval. The description of problem is often complex and requires clarification. Very often it leads to going back and forth in approval process between people with messages and explanation. To setup one minute voice communication can solve a problem.

Voice and mobile can become a killer approach to simplify communication and streamline PLM process management. It can decrease number of messaging loops, speed up approvals or improve customer service. PLM vendors are very much behind in mobile innovation. Voice is part of this gap.

The brutal reality of process management in hardware startups

Startup company and process management. These are probably two most conflicting definitions you might think about. Everyone is familiar with famous Zuckerber’s statement – move fast and break things. How process management can survive in such environment? Although Facebook is more careful these days about “breaking things”, startups are still operating on the edge to move as fast as possible. The outcome is questionable for many hardware startups. A large majority of young companies are not delivering on time. The rough statistics said 75-80% of hardware projects on Kickstarter are not shipping products on time. That was a piece of information that made me wrote the following post last year – Why Kickstarter projects need PLM?

The blog post Speed Can Kill: the importance of process for hardware written by Ben Einstein of Bolt put a great perspective on what means process for manufacturing startups companies dealing with atoms (not bits like software companies). Take a look on the article – I found it very interesting. So called “long shadow effect” is brutal if you think about potential impact of decisions made during the lifecycle of product development. The following passage can give you an explanation how it can happen:

Early mistakes often don’t have a measurable impact until first shots are coming off tooling and the manufacturing process grinds to a halt. My partner Scott calls this the “long shadow effect.” An early decision about which microcontroller to use or the shape of a housing can appear correct until months or even years later during the first production run. Sometimes parts can have exceptionally long lead times, require odd financing terms, demand manual rework, or be entirely un-moldable. None of these problems can be uncovered by moving quickly to get to production.

The article speaks about four “trunks” as a the way to organize processes. I found it interesting comparing to more traditional department organization you can in PLM implementations done in larger companies. It reminded me my earlier blog about why PLM companies should revise NPI processes. The waterfall process is complicated and can introduce many artificial breakpoints to prevent company from moving fast. At the same time, running out of process organization will fail you on late stages of product development and manufacturing. My favorite passage from Bolt’s blog is the following conclusion:

This is not to say that hardware startups can’t move quickly; in fact they can move faster than ever before. But the ability to go fast and build good products on time and under budget comes from process, not pure iteration. The fastest companies tend to be exceptionally organized about their product development and manufacturing process. Many people have asked us to cover this in much more detail and we’re working on a 4 part series exploring each of these trunks.

I’d change the original “breaking things” statement in order to fit manufacturing companies reality as following – “move fast and respect process”. It is easy to say and hard to implement.

The complexity of product and processes is high. Products are combined of mechanical parts, electronics and software. Work and teams are distributed. All things are interconnected and can create “long shadow effects”. Hardware startup companies are struggling to set basic elements of information and process organization. My hunch that those companies that are able to organize four trunks right will survive. This is a note for PLM architects and other people thinking how to apply PLM technologies for agile and dynamic processes.

Picture credit (c) Can Stock Photo