Types of process modeling today with usage guidelines

There may be a debate on whether to model or just jump into coding or composition and fail fast. We suggest modeling is a great way to plan more critical or complex processes. Today there are many options for developing processes and applications. There is great debate about modeling representation and even the need to model in the first place. Before we get into the representation issues, let’s think about the reasons to model in the first place. We know tremendous pressure exists to get to code quickly to show results. There are better ways to compose code, link APIs, and leverage low-code approaches that might lead one away from models. After all, models generally don’t execute directly, or do they? Though models might not seem to get to code as quickly, they help code the right solution to meet the needs. There are three great reasons to create a visual model, and they are as follows.

Visualize the connections between processes and resources

Management, customers, partners, and employees often think they understand the operational efforts needed to complete work, but they don’t. Indeed, there is not a common understanding of operational processes and applications in all the contexts and views held by the collective participants. Creating an agreed-upon visual representation gives a solid construct for explanation to all managers and participants. Combining the different views and perspectives into a whole model makes a shared understanding of the likely outcome. The model identifies all the participant’s roles, decisions, actions, and results.

Gain a common understanding of the current situation

Often, there are processes, data, events, and patterns belonging to each participant in an application or process that may have been created by their organizational position, role, or specialty. By better understanding the moving parts and how they contribute to business outcomes, existing processes and applications work better without needing to change the base process or application. If changes are being considered, the current state models can enable better approaches or remind developers or participants of crucial constraints.

Create a consensus on a future solution

Gaining consensus on a set of target processes and applications is essential in all transformations, especially in digital transformations. Creating a group of participants to define a new way forward and enabling them with models allows for faster progress. Models can be used to verify whether the new solution is correct from several perspectives outside the core design group. Also, it allows management to understand the sticking points in significant changes and engage participants early in the change process.

Often, organizations pick one of these approaches to start the modeling efforts and realize they need the other two to figure out the transformation efforts, including scope, skills, available resources, partners, technologies, and a reasonable schedule. It is crucial to determine what levels of pioneering and risk the transformation efforts will allow within the organization’s culture in charge of the digital efforts.

Three different process styles require different process modeling approaches, each concentrating on representing how work is managed toward a business, process, or technical outcome. In more complex situations that deliver high-value outcomes, more than one style may be used. See the process styles in Figure 1.4 for a visual representation of each style.

Figure 1.4 – Process styles

An explanation of each style is enumerated as follows.

Structured processes

While multiple process sub-styles exist in this category, they all start with planning a process and identifying almost all the paths and exceptions. Then a process that is relatively static and brittle is put into place. These can be whole processes or process snippets, meaning partial cohesive pieces of processes that are bound steps for specific results. Structured processes work best for standard and straightforward outcomes. Still, they can be expanded to take advantage of BPM and rule agility to make them less static and more adaptable to new business requirements and exceptions. Some organizations build extensive and comprehensive structured processes that become hard to test and maintain. The relationship between bots and these processes is more around the bots serving the process than vice versa. The extensive process brain controls it all.

Case collaboration

More dynamic processes start showing up in case management, where the goals and milestones are static, but the paths to these goals can vary. It is accurate for knowledge-intensive work, where one person does not understand how to solve or complete an individual case. Case collaboration can get even more agile and dynamic when the goals and milestones can change. This calls for adaptive case management. Bots can be used in a couple of scenarios to start. One is that a bot could contain automated personal assistants in the cloud that could grok large amounts of information from data lakes or produce deep analytic efforts on behalf of the knowledge worker. In this situation, the structured part of the process becomes a minor part of the overall process and evolves to snippets of process sequences or bots/personal assistants. This way, you could swap out AI agents or people at the direction of management. It introduces more complexity, but the case brain will control events and patterns fired from bots for potential decisions and actions.

IoT bot collaboration

Imagine a network of collaborating bots and IoT devices working together to decide what the next step should be and firing off another structured process, a case, or a set of bots to meet dynamic goals set by a managing agent. Of course, these agent collaborations and actions would have to be bound by constraints to avoid violating governance policies or rules. It is a very dynamic approach where the brains of the operation are no longer a central control process or case in charge. In this case, goals and constraints with contexts now lead the way. Real-world examples are emerging every day. One such use case is automatically feeding farm fields with water and fertilizer for bigger yields. See https://jimsinur.blogspot.com/2013/07/smart-farm-operations-processes.html for a case study.

There are three significant reasons for modeling processes. The most common is understanding the current processes, which will likely include process/data mining techniques and technologies as it automates part of the understanding of the current processes more scientifically. The next most common reason is to create a future process model that will most likely use visual modeling tools and get more detailed throughout the phases of progress. In complex or wide-scoped processes that coordinate many resources, a model of the connections and the boundaries the process crosses is also essential. Often, significant efforts will employ all three. Three styles of processes are also employed to achieve unique business outcomes. It is essential to understand all three, but the point of control that the processes need will point to a particular style or combination.