amikheev August 22, 2016 at 15:30

What are executable business processes. Domain Introduction

Recently on Habré several articles were published ( one , two ) on the topic of business processes. It states that everything in this area is so complicated and confusing that you cannot figure it out. It was also suspected that the theory of process management is essentially pure PR and marketing, which has no practical use.

I have been involved in process control for many years, and since this topic has been raised, I will describe what it is and why it is needed.

The term “process management” applies to two different areas of activity:

In the case when the automation of the execution of business processes is not performed. The task is to compile a business description in the form of graphical charts that are easily perceived by people. Such diagrams actually represent a special language of communication between managers, business analysts and enterprise managers and are used to develop and explain basic decisions on organizing an enterprise’s business.
In the case when business processes are directly executed in the computer environment of the enterprise. We will call processes of this kind - executable business processes. To execute such business processes, a special computer system is installed at the enterprise - BPMS (Business Process Managrment System) in the English version of the name, or SMS (Business Process Management System) in the Russian version. These business processes are the focus of this article.

The evolution of BPMS and “natural selection” over the course of about 15 to 20 years have resulted in the use of the same basic concept in existing BPMS. In it, two concepts relate to business processes: the definition of a business process and an instance of a business process. Sometimes a business process definition is also called a business process template. The definition of a business process contains a diagram of a business process, the roles of a business process, the rules for assigning executors to roles. A business process definition also describes the storage structures.

For each definition of a business process, you can create and run instances of this business process. The concepts of a definition and an instance of a business process are similar to the concepts of a class and an object in programming. That is, if a business process definition contains a business process diagram, data types, role names, then in the running instance of the business process, the diagram contains moving control points, specific executors are assigned to the roles, the business process instance contains specific data, the types of which match the data types in the business process definition.

The easiest way to imagine moving control points according to the scheme of an executable business process is by analogy with moving chips in a board game with a cube.

An executable business process diagram consists of nodes and transitions (sometimes also called edges). The appearance of a control point in a node of a certain type corresponds to the performance of some action in the production activities of the enterprise. At this point in time, BPMS generates a task for a specific performer. Transitions in the business process diagram, as well as nodes for branching and merging control points, are arranged in such a way that the actions contained in the business process are performed in a coordinated and correct manner.

In fact, the main function of BPMS is to distribute tasks by the contractor in accordance with the movement of management points according to the business process scheme and to control the implementation of these tasks.

In modern BPMS, the definition of a business process also contains a description of how the business process interacts with the job performer. Usually this is a graphical form for interaction of a business process instance with a user, or a program interface for interaction with an external information system. Another element of the definition of a business process are business rules that are used to select a specific path for the further movement of the management point at branch points of routes.

There is a certain similarity between an executable business process and a computer program. At the heart of both the executable business process and the computer program are algorithms. For computer programs, as well as for business processes for analytical modeling, there are graphical notations (for example, the UML class diagram) that programmers and software architects use to explain various software and architectural solutions. However, computer programs themselves are still not massively developed in the form of graphic objects, they are mainly written in the form of texts in programming languages. How is the situation for executable business processes different from computer programs? Unlike a program whose commands are executed by a computer, part of the actions of a business process is performed by people. They do it much longer than a computer, therefore, business process instances run relatively long; their state changes slowly. Moreover, unlike a computer program, during the execution of business processes, enterprise management can significantly affect their implementation, for example, increase or decrease the number of employees performing certain actions.

Therefore, it is important for managers and managers of the enterprise to quickly understand the state of the executing instances of the enterprise’s business processes. This understanding is provided by the graphical diagram of the business process with the current positions of the control points plotted on it, as well as the routes traversed by these points from the moment the business process instance was launched. For computer programs, such diagrams in most cases do not make sense, because the speed of movement of control points will significantly exceed the limits of human ability to track them.

Process approach for executable business processes

The process approach assumes that the activities of the enterprise can be represented as a set of running instances of business processes. It is effective for enterprises in the production of which there is a repeated repetition of the same chains of actions performed by various performers. Such enterprises are the majority of office companies engaged in various types of work with documents, such as banks, insurance, investment companies, consulting companies, publishing houses. Also, the use of the process approach is effective in enterprises whose activities are described by clear regulations, for example, in government bodies.

In the case of executable business processes, process management may include the following activities:

At the enterprise, business processes are allocated, built in an executable form, and put into operation by uploading to BPMS. Process management in this case is the result of:
- The actions of business analysts who developed executable business processes, in particular, business process diagrams
- Making managerial decisions by managers in the nodes of the diagrams of instances of business processes having various possible options for the further movement of management points
- Making managerial decisions by job executors when entering data into business process instances (on which their further behavior substantially depends).
Process management includes the operational change of schemes and other elements of the definition of business processes in response to changes in the conditions of an enterprise’s business.
Also, process management includes indirect administrative influence on the execution of specific instances of business processes. For example, the impact on “human resources” - the management of an enterprise can increase or decrease the number of employees performing certain operations, or change the qualification requirements of employees performing certain actions, as well as make specific personnel decisions, assigning employees to certain roles. Managers can also analyze the status of executing instances of business processes, analyze collisions that arise, and make various administrative decisions that affect the efficiency of executing instances of business processes without changing the scheme of business processes.

The main advantages of the process approach in the case of executable business processes

In the case of using executable business processes, an analogue of the production conveyor appears at the enterprise, from which it is possible to obtain an increase in labor productivity comparable to that obtained from the introduction of the conveyor in production. The increase in labor productivity is achieved due to the fact that this mechanism makes it possible to exclude routine operations, inefficient procedures associated with the search and transmission of information from the actions of employees, and significantly increase the speed of employee interaction. Workers perform the tasks received, without being distracted by:

Obtaining from other employees the data necessary to complete the task
Transferring the results of their work to other employees
Learning Job Descriptions

Everything necessary to complete the task appears before the employee on the computer screen.

However, the most effective use of executable business processes is associated with the concept of “Process Transformation”: After BPMS is put into operation and all employees of the enterprise are accustomed to the fact that their activity is the fulfillment of BPMS tasks, it turns out that by changing the definitions of business processes, you can quickly rebuild the business of the enterprise. Since in the case of BPMS, employees do not have to worry about who to get the source information from and who to send the result of the work to, they can easily and very quickly change the sequence of actions, artists and types of data used. At the same time, it is not necessary to change job descriptions, conduct trainings on training and certification. In many cases, task performers may not even be informed of changes in business processes, as this will not affect the nature of their work.
This leads to qualitative changes in management. The resulting rate of business change is tens or even hundreds of times faster than the rate of change by traditional methods. At the same time, the cost of transforming a business is small. This can be a significant competitive advantage.

A more detailed description of executable business processes

Business process diagram

A diagram is usually defined as a mathematical concept - a directed graph: a set of nodes interconnected by transitions (also sometimes called arrows or edges). Business process nodes can be of two types - nodes corresponding to process steps, and route nodes. At run time, management points (pointers to the active nodes of the business process instance) move through transitions.

A running instance of a business process can have multiple management points at the same time. In accordance with the business logic, the control point in the route node can be divided into several control points, and control points can wait for each other in a certain route node and then merge into one control point.

The node corresponding to the process step contains the action node. If the management point has arrived at the action node, then BPMS gives the task to the executor (employee or information system) and waits for a response (message that the work has been completed). After the executor answers, the management point moves to the next node of the business process.

The route node corresponds to the appearance, deletion, branching, merging of control points or the choice of transition along which the control point will be moved further. Based on the business rules contained in the route nodes of the business rules, BPMS selects the next node (s) to which the management point will be directed. Often more than one inbound or outbound transition is associated with these nodes.

Let us explain the behavior of the nodes most often used in business processes, and also present their graphic images in accordance with BPMN notation.

The “start” node corresponds to the point where the business process begins. It has no incoming edges (transitions) and there is only one outgoing edge. When a business process instance is launched, a management point is placed in the node, which immediately exits from it along the outgoing edge. In a business process, there must be a single “start” node. It is indicated by a thin circle (Fig. 1 a)

Figure 1. Designation of nodes: a - beginning; b - completion of the flow; in - ending; d - action

The node "completion of the flow" must have one or more incoming edges and no outgoing. When a management point enters this node, it is deleted. An instance of a business process in which no management points are left is considered completed. In a business process, there may be several flow termination nodes. This node is optional if at least one “end” node exists in the business process. It is indicated by a “thick” circle (Fig. 1 b).

End nodecorresponds to the point of completion of the business process. The “ending” node must have one or more incoming edges (transitions) and no outgoing edges. When control enters the “end” node, all control points in this process instance, as well as in all its subprocesses, are deleted. In a business process, there may be several end nodes. This node is optional if at least one “end flow” node exists in the business process. It is denoted by a black circle inside the circle (Fig. 1, c).

The “action” node generates a task for the executor, it is indicated by a rectangle with rounded corners, in the center of which the name of the node is written (Fig. 1 g)

“Exclusive gateway” nodemay have several incoming and several outgoing edges. For each control point that arrives at it, it is selected along which of the outgoing edges it will be moved further. It is indicated by a rhombus in which the “cross” is depicted (Fig. 2 a).

Figure 2. Designations of nodes: a - exclusive gateway; b - parallel gateway

The node “parallel gateway” is indicated by a rhombus, which shows a “plus” (Fig. 2 b). It can have several incoming and several outgoing edges. For each incoming edge, the control point that came along it to the parallel gateway is queued. If for all incoming edges their queues are filled with at least one control point, then all control points located at the first position of the queue of each incoming edge are deleted, and a control point is generated on each outgoing edge.

Figure 3. An example (simplified) scheme of the business process “Payment of a supplier’s invoice”

Business process variables

Using variables, information is exchanged between the steps of the process. Business process variables are also used to select a specific internal movement of the control point between nodes along any of the possible transitions. Business process variables can be inbound and outbound when BPMS interacts with enterprise information systems.

Business process roles

An instance of a business process associates action nodes with job executors using roles. When developing a business process, a role is created and put into correspondence with certain action nodes. During the execution of the business process, roles are assigned to specific executors. Here you can draw an analogy with a theatrical performance: in the process of writing the script, the roles used in the play are determined. Then, when staged in a particular theater, actors - performers of roles are assigned to roles.

There may also be various rules for completing tasks in a business process. For example, a business process can send a task for execution to all members of a certain group of users, and this task will be performed by the first user who has taken the task for execution - the remaining members of the group will have this task recalled.

Business process management systems and their main components

Modern BPMS should provide for the development of business processes in a graphical environment, the execution of business process instances, monitoring of instance states, maintaining the event history of business process instances, application integration using the connectors used by business processes, user administration, and the ability to replace task executors.

The following graphical interfaces are used to perform these functions in BPMS:

interfaces for working with performers
interfaces for working with business process definitions loaded into BPMS
interfaces for working with process instances running in BPMS
interfaces for administering users and user groups
interfaces for configuring job executor substitutions

To create and modify business processes, graphic designers are usually used, which are part of the development environment, which can be either separate stand-alone programs or Internet applications.

A typical BPMS consists of the following main components:

Business Process Execution Environment
Development environment for business processes and related objects
Client notifier of received tasks
Component connector to other information systems

BPMS may also contain a business process simulator used to debug business processes before loading them into an industrial system.

The business process runtime is a core component of BPMS. It implements the execution of a business process instance in accordance with its definition. This component contains definitions of the business processes loaded into it and running instances of business processes. Generates task lists and visual forms that correspond to tasks. As a rule, the runtime environment for business processes allows you to create and change user properties, and also allows you to set various rights to system objects.

The development environment for business processes and related objects is used to create and modify executable business processes. In this environment, the sequence of steps of the business process and data are determined, roles are assigned to the participants of the process, routing rules are introduced, graphic forms of tasks used by the participants of the business process to perform tasks are defined. The development environment allows you to construct a graphical diagram of a business process with a description of its details in the form of properties of individual elements (actions, subprocesses, route nodes, etc.) or the business process as a whole. The development environment is a tool for a business process developer (business analytics); in particular, it provides changes to the business process by simply modifying the graphical diagram and properties of elements.

The client-notifier of incoming tasks is a component that provides users with access to the functionality of the business process execution environment. In particular, it: Displays task lists and visual task forms. Allows users to complete tasks. Allows the system administrator to set rights to system objects. It makes it possible to monitor the execution of instances of business processes. It also implements a notification of the user about incoming tasks.

The component connector to other information systems in different BPMS is implemented differently. In this article, we will consider a connector component, which is a set of special applications - bot stations. Each bot station must be located on a separate server, one of the bot stations (local bot station) can be located on the same server as the runtime. Bot stations contain special entities - bots, which periodically poll the execution environment. Bots are automatic performers, somewhat reminiscent of a person (such a connector organization is more convenient for managers - it is easier for them to think in these such terms). If business process instances running in the runtime environment contain tasks for bots uploaded to the bot station, then the bots perform these tasks and return the results to the runtime. In particular, while bots can access other information systems.

Using interfaces for working with performers, a user can:

Receive, filter, perform tasks generated by instances of business processes
Launch new instances of business processes
View the status of running instances of business processes
Upload new business process definitions to the runtime, or new versions of the business process definitions already contained in the runtime

Figure 4 . An example of an interface that displays a list of user tasks.

Figure 5 . An example interface where you can start new instances of business processes and load new business process definitions.

Using the interfaces for system administration, the administrator can:

Create-delete users and user groups
Include (exclude) users in groups
Distribute rights to system objects to users and user groups
Force stop business process instances
Add, change user substitution rules

Figure 6. An example of an interface in which you can view the status of running instances of business processes

Using a development environment, a business analyst can develop business processes, including business rules, various elements of connectors to external systems and other elements, as well as load them into the environment execution.

Figure 7. An example of an interface in which you can develop business processes

Using a business process simulator, you can test developed business processes on a conditional configuration on the analytics client computer without loading them into an industrial system.

Description of the work of users and BPMS components

The business process runtime is launched on one server. Multiple servers can run bot stations.

On client computers of users, a client-notifier about incoming tasks is launched or a browser opens in which the BPMS web-interface is opened.

On the client computers of analysts, the environment for developing business processes and related objects is launched. Also, on the client computers of analysts, a business process simulator is launched.

The runtime executes instances of business processes.

Bots located in bot stations (automatic task executors) periodically interrogate the environment for the execution of business processes. If business process instances running in the runtime environment contain tasks for bots, then bots perform these tasks and return the results to the runtime environment.

Web interfaces and siren clients periodically access the runtime and display user tasks.

Using the BPMS web-interface, users:

Receive, filter, perform tasks generated by instances of business processes
Launch new instances of business processes
View the status of running instances of business processes

Using the BPMS web interface, administrators:

Download or modify business process definitions
Create or modify user and user group settings
Distribute rights to system objects
Change the parameters of bots and bot stations

Using the analytics development environment:

develop and modify business processes

To develop a business process, analytics needs to:

use the mouse to draw a business process diagram
identify the roles involved in the process, assign performers to roles
set business process data (process variables)
Define graphic elements of business process job forms
associate the nodes of the business process diagram with the corresponding roles of users or bots (automatic executors)

Once a business process is developed, it is uploaded to BPMS. After that, you can run instances of this business process and perform the tasks they generate.

Using a business process simulator, analysts test developed business processes on a conditional configuration before loading them into an industrial BPMS.

Notification clients alert users of new jobs.

Reengineering and Evolutionary Business Process Management

Historically, the process approach at first included only business processes for analytical modeling. In the framework of this approach, the company’s business processes were identified, the business processes identified were analyzed, and proposals were made to improve business efficiency by changing business processes. Next, the implementation of the modified business processes at the enterprise was carried out.

Since changing business processes for analytical modeling is not related to automation, the introduction of modified business processes was an expensive procedure, involving retraining of personnel, changing job descriptions, and often changing the organizational structure of an enterprise. Such changes are very costly to do in consecutive small steps. Therefore, such changes were rarely made, but the changes themselves were significant. In the literature, such a transformation of business processes is called re-engineering of business processes. Reengineering of business processes implies a radical redesign of the business processes of the enterprise to achieve a significant effect of production, business and financial and economic activities.

When using executable business processes, the cost of implementing changes is relatively small, therefore, in this case, an evolutionary change in business processes is often applied. BPMS is installed at the enterprise, business processes are developed, loaded into the system and put into operation “as is”, after which they are gradually, for a long time converted into business processes “as needed” and gradually evolve following changes in the conditions of the enterprise.

The business processes are often tied to the calculation of various indicators of enterprise performance (KPI), both financial and non-financial. There are process management methods based on KPIs that provide for the prediction of performance and planning for their achievement.

For a figurative understanding of how business processes are used as a business management tool in the case of evolutionary management using KPIs, A. Belaichuk (chairman of the Association of Business Process Management Professionals) proposed the following analogy: Enterprise management can be figuratively compared to driving a car. In this case, the KPIs are analogous to what the driver sees - the view through the windshield of the car and the values of the indicators of the sensors (speed, oil pressure, engine speed, amount of gasoline, etc.), and business processes act as steering wheels, pedals ( gas, brake, clutch) and the car’s gear lever. That is, they serve to directly control the trajectory in space and time.

A modern view of process management involves the separation of control on several levels.

At the first level, the overall strategic management of the enterprise is considered. At this level, business processes are used for analytical modeling. The task of business processes at this level is the formation of common ideas about the main business processes of the enterprise and the exchange of these ideas between managers. This level does not imply the actual execution of developed business processes.

It is possible to describe the sequence of actions in business processes of the first level simply in the form of text, such descriptions are called textual regulations. However, people perceive visual information much faster and easier than text descriptions. Therefore, the most widely used are graphical representations of business processes for analytical modeling.

At the top level of process management, simulation tools are also used. This class of programs does not provide for the real execution of business processes in the computer environment. Simulation systems contain a customizable statistical model of the organization’s business processes. By setting various parameters of this model and repeatedly "losing" business processes on conditional automatic users, one can obtain the values of various performance indicators and thus predict changes in the real performance of the enterprise in the future, depending on various changes in business processes. If the statistical model is built correctly, then simulation can be a means of determining the optimal parameters of business processes.

At the next level, the strategic business processes of the enterprise are translated into executable business processes. At this level, business process diagrams are usually depicted in BPMN, UML (Activity Diagram) and related notations. At this level, the current activity of the enterprise is represented in the form of many running instances of business processes.

The next (third) level of process management corresponds to the business objects of the enterprise. The state of the entire enterprise at the current time is determined by the state of all business objects of the enterprise at this time. The process approach assumes that the state of business objects is changed by instances of second-level business processes when performing the corresponding tasks. For this layer, content management systems (ECM systems), or database management systems, are traditionally used as storages. It is also possible at this level to use ERP systems. To explain the concept of business objects, you can use the analogy with accounting: the accounting condition of the enterprise at a fixed point in time is determined by the cash balances on the accounts of accounting, and the change in the state of the enterprise is determined by accounting entries. In the framework of this analogy, postings will correspond to business processes, and account balances will correspond to business objects.

Mathematical Foundations of Executable Business Processes

The success of the query language for SQL relational databases is usually associated with the fact that it is based on a solid mathematical theory - relational algebra. Language developers describing executable business processes also try to put a serious mathematical theory at the heart of the language.

Most existing languages describe executable business processes to one degree or another relate to one of two mathematical theories:

theory of Petri nets
pi calculus concept

The theory of Petri nets is based on the classical theory of graphs, is an extension of the theory of finite automata. It arose in the 60s of the twentieth century and has since been constantly evolving. The theory of Petri nets is a complex, very well-developed theory, it strictly defines concepts such as states, conditions, transitions, etc. The theory also includes graphical notation (a system of graphical notation on the basis of which you can draw the corresponding graphs). Petri nets are well studied by mathematicians - many of their properties are established, a large number of theorems are proved.

The practical use of the theory of Petri nets was mainly associated with the description of the behavior of very complex systems, for example, elements of integrated circuits. Having built the corresponding Petri net for the system, then it was possible to use the results of the corresponding theorems and thus study the properties of the system.

It is inconvenient to use the concept of Petri nets explicitly to describe BPMS, since the graphical notation of Petri nets is not intuitive. It is difficult for business analysts, let alone managers, to work with it. In addition, some classes of business processes have appeared that cannot be described using it.

The first languages for defining business processes (for example, WPDL and XPDL of the WfMC coalition) became the heirs of the theory of Petri nets. They are based on graph theory and conceptually include many concepts and concepts of Petri nets: nodes, transitions, conditions, etc. However, unlike Petri nets, these languages are not strict - in some cases it is possible to compose language sentences that are syntactically valid, however, the behavior of the generated business process will not be unambiguous.

The concept of Pi calculus was developed in the late 80s of the XX century by Robin Milner and is based on the algebra of parallel processes. Unlike Petri nets, the mathematical objects of Pi calculus are not graphs, but expressions over elements of special sets and transformations over these expressions. At present, Pi calculus is a promising, but still young and developing theory, it has many open questions and unresolved problems. It was mathematically proven that the functionality of Pi calculus is higher than Petri nets.

The developers of the BPEL and BPML languages claim that these languages have a higher expressive power than languages based on Petri nets, since these languages are based on the Pi calculus. However, there are skeptics who believe that the connection of these languages with the concept of Pi calculus is not obvious, and suggesting that these statements are closer to the marketing move than to the real use of this theory in constructing these languages.

Tags: