Automate business processes or what is "complexity." Part 1

Much has been written about the automation of business processes (BP). In the literature, and on the Internet, the benefits of automating everyday routine processes through Business Process Management (BPM) and Workflow Management Systems (WMS) are well described.

The purpose of this article is to go further and consider what exactly the word “Automation” implies, and why an increase in the requirements for process models necessarily leads to an increase in the complexity of the system itself, and how to deal with it.

At the beginning of the article I will focus on the theoretical foundations of BP classification according to the degree of their resistance to change, and then I will touch on the technical aspect of BP modeling.

In the middle of the article I will try to explain why the systems are complex, using the concepts of similar sounding notions “Complexity” and “complex”, but having different semantic meanings.

At the end of the article I will give specific examples of how to deal with Complexity on the example of modeling adaptive power supplies.

So, for the sake of clarity about what is being said, I cite the BP classification according to the degree of their resistance to changes, according to the structure, the processes differ from clearly structured to collaborative ones.

Figure 1: the degree of resistance of BP to change [source Vos 1997, S. 40]

From Figure 1, it is clear that structured processes are efficiently supported by conventional WMS and BPM, while semi-structured and collaborative ones require more flexible IT solutions.

But the main thing is to understand that each of the listed classes should have its own approach when modeling the PSU. Do not use a wrench to turn the screws and try to tighten the nuts with a screwdriver.

Now consider the most common technical concepts in the modeling of BP, i.e. what tools for tightening the screws and screws are in the box.

Figure 2: technical concepts [source Aalst ua 2005, S. 158]

To avoid confusion, I will give the main idea of ​​each concept:

- EAI - systems, which are based on the principle of the tire. The system should only be connected to the bus to access other services.

- SOA are services that have interfaces according to the OASIS standard. This provides a simplified way of communicating between services.

- Case Management oder Adaptive Case Management (ACM) - support unpredictable scenarios. These systems are effective for non-repetitive and unique business scenarios.

- Ad-hoc-Workflow - processes that have the ability to change the workflow on the fly (also in an already running process instance).

- Groupware - software to support the interaction between people working together to solve common problems.

Now, having an idea of ​​the types of business processes and possible technical approaches, it will be easier to choose the right solution for a certain type of business process (a screwdriver is still for screws, and the key is suitable for nuts).

With categories and tools more or less sorted out, it remains to deal with external factors; it seems like everything was done correctly - we tighten the screw with a screwdriver and the nuts with a wrench, but something still “tight” goes. Maybe we screw the screw into the concrete or the screwdriver scrolls.

Why some processes are easy, while others are difficult to model and implement?

Perhaps someone will immediately answer: "... because of the different requirements for the processes. As the requirements for the processes' functionality increase, their complexity increases."

For a start, it is necessary to separate the two concepts " complex " (English. Complicated; German. Kompliziert, Kompliziertheit) and " Complexity " (English. Complex; German. Komplex, Komplexität). Very often these two terms are taken for the same thing, but there is a significant semantic difference between them.

The system is " complex " - when it is hardly possible to divide the system into smaller components or, conversely, to assemble a system of smaller components, but the final functionality of the system is predictable.

An example is when the system is complex: for individual components of a car, you can predict how it will behave on the road (max. Speed, taxiing sensitivity, etc.). In principle, we are talking about tactics, the distinction between complex and technically possible simple components.

The concept of " complexity " is rather a state of the system when, with known components, the final result is not predictable.

An example of "complexity" is a football or orchestra. On football, with all the known parameters of players and tactics, the outcome of the game is impossible to predict. As in the orchestra - the result also depends on many external components. So, for example, the sound of an orchestra does not directly depend on the musical score and skills of the musicians, here are added such factors as room acoustics, electrical amplification of sound, the audience itself and even visual perception.

In other words:

When a system (business, project - does not depend on context) causes Difficulty , then to overcome it will require new knowledge that will need to be understood (rethought, accept, change the point of observation, change itself).

When the system (business, project - does not depend on the context) is complex , it will take an effort with the existing knowledge.

From the above, an interesting formulation of the work of the project manager follows:

transformation of the system, causing complexity, into a complex system with its subsequent decomposition into technically possible small components.

But this is a separate topic for the article. Returning to the main topic and taking into account new knowledge, I will begin to transform the Difficulties in automating business process models into a complex task.

Upon reflection, I will focus on implicitly structured BP models in order to be able at any time to change the BP model according to the new requirements.

This item is significantly relevant if the lifetime of the instance of the BP> the period of release of the BP model. In other words, I have the opportunity to support the evolution of this business process "on the fly" - without restarting the BP instance.

An example of such a BP model is the process of repaying a loan in a bank. Often, the loan repayment period is approximately from 10 to 30 years, respectively, the life of a running BP instance is calculated in dozens of years. During this period, the changes simply cannot be avoided, even a well-thought-out BP will not be able to take into account all the external factors for the coming years ahead, and in this case, decades.

According to fig. 2 I’ll use Ad-Hoc Workflow. This principle is well suited for tasks where the initial PSU model is known and subsequent changes are applied to both the running and all subsequent BP instances.

I will formulate the basic rules of evolution presented for Ad-Hoc processes:

• BP instance is always launched only in the latest version, it is impossible to start an outdated BP version (thereby preventing the process from entering the dead lock)
• The possibility of parallel existence of several versions of the same BP
• It is possible to prohibit the transition to a new version, thus enabling the instance to complete the initial workflow.

Now you can go to the structural example of changing the BP model. The two most common scenarios when changing a BP model are as follows:

1. add a new task to the model
2. delete existing task from model

Adding a new task

It is necessary to add task 3 to the BP model.

The principle of embedding a new task in the model is shown in the following diagram. In this case, the tokens from version 1 are moved to the corresponding task of version 2. In the second version of the BP, the tokens from task 1 fall into a fork and further along the standard BP execution scenario. After task 2, the process ends, as in the previous version of the PSU.

The dotted lines show the movement of tokens between versions of BP:

Delete existing Task

It is necessary to remove task 2 from the PSU model. Deletion takes place in three steps, version 2 - intermediate, final version - version 3.

Step 1: tokens are moved from version 1 to version 2. In the second version, task 2 is no longer available for new instances. The instances launched from version 1 and which have already started execution of task 2 will finish its execution.

Step 2: in version 2, task 2 gradually "dies off", as the instances in version 1 no longer start and the flow of tokens to task 2 from version 1 will stop (the second rule of BP evolution).

Step 3: after the complete “withering away” of task 2, version 3 is added - already final, without task 2, which is no longer necessary with confidence.

(Dotted lines indicate the movement of tokens between versions of BP).

In this article, the transition from the “Complexity” with changes in the BP model to the complex task of modeling adaptable BPs was considered on the fly.

Two main scenarios of changes in business processes were also considered, which will be demonstrated on the example of the current prototype, but in the next part.

The article “ Everything you wanted to know about BPM, but were afraid to ask, ” sshikov , where the author describes technical problems in implementing changes to the BP model, may also be useful.

If there is time, I will try to respond to comments, additions, as well as criticism of the idea of ​​the article.

Thanks for attention!