Automation of business processes. Ad-hoc changes on the example of life. Part 3

The topic of introducing changes in business processes has reached the Russian branch of the International Association of BPM Professionals ( ABPMP Russian Chapter ) in the form of an article by the President of this association, Mr. Belaichuk, entitled “How the change management begins . ” More precisely, Mr. Belaichuk shared with the readers of his blog the translation of the article from an English-language resource.

The article deals with the management of changes in business processes. The main idea is that “you need to start managing changes much earlier - at the first stage of the BPI project, when the charter is developed, the process is identified and modeled.” The author of the article makes it clear that change management must be systematic, and it must be taken into account that only changes can be permanent in the work of any organization.

Further, the article describes the difficulties that will certainly arise in the organization with each turn of the iteration of the changes to the "established" work of the organization's processes, and how to deal with them at the level of the psyche ?! "people facing change."

Not sure exactly how members of an international association BPM psychologists , excuse me, BPM-professionals solve their tasks, because besides psychological methods for solving the issues of introducing changes to others, no one has been suggested, alas.

Therefore, I propose instead of consolation to employees of organizations who, willy-nilly or otherwise, have to deal with changes in the structure of business processes, so as not to upset them in vain, consider a more technical approach to this situation.

The essence of the approach is as follows:

Running instances adjust automatically to process model changes.

That is, it is enough to make a change in the business process model, and then you can relax and not think about how to embed new changes in the already running instances, which, for example, will be active for several more years. After all, to wait for the end of their life cycle in order to completely forget about them, there is neither desire nor possibility.

Please do not confuse this approach with adaptive case management (ACM).

ACM is the most flexible approach to date, which makes it possible to customize each instance launched individually.

The considered approach, in this article, describes semi-structured processes (semi-structured), which have a predetermined set of rules, but may change during the process.

These changes are also automatically applied to running instances until changes are made, thereby ensuring that there is a global model of the business process at a given time.

In other words, the changes are applicable not only to new instances (i.e., delayed changes), but also to all running instances of this business process model, using the migration method (i.e. emergency changes).

Consider an example from life, taking the process of returning travel, and accept the assumption that the life cycle of this process is 10 years (to more clearly understand the advantage of emergency changes in running instances).

Process Model "Travel Return" in version 1.0:

An application for the return of travel expenses is filled, then the application is processed by the manager, who can immediately approve it, reject or request additional information.
According to the decision, the process initiator is notified. And after the return of travel or refusal to return the process is completed.

The process was launched and quietly fulfills the applications, until at a certain point in time there is a notification from management that applications over € 200 must be retroactively approved by the head of the department. That is, this change also applies to previously launched bids, which were approved by the manager, but, as usual, the accounting department did not reach this point and the travelers did not return.

To do this, a new version of the process is created taking into account the necessary changes, in this case, you can add another UserTask and one ExclusiveGateway.

And the next version of the process will look like this:

A new branch appeared after the application was approved by the manager; and if the amount exceeds € 200, then approval from another person with another level of access is required.

Everything seems to be good, new applications will be launched under the new process model, but the question remains how to deal with already running instances, especially with those where the refund amount exceeds € 200? Here we also recall the assumption made that the end of the life cycle of running instances in the next 10 years is not foreseen, and now we need to make changes to more than one thousand running instances with scattered execution steps throughout the model.

In this case, as already described in the first part , the subsequent version of the process is connected to the previous one by means of the so-called "Migration Map", in which the "transitions" of tokens between adjacent versions of the process are indicated.

For this example, the "Migration Map" may look like this, in which bids that were approved for payment in process version 1.0 but have not yet been processed by the accounting department will be redirected to a new branching "more than € 200". In the event that the amount exceeds € 200, additional approval will be required by the authorities. Applications with a sum of up to € 200 will, as in the first version, go to UserTask "Refund expenses" immediately without additional approval.

Migration is activated when a token is transferred between tasks of any type or when a user accesses one of the UserTask.

In this case, the new requirements that must be applied to the running instances will be implemented when the user tries to open UserTask "Refund expenses". The process control system (EMS) determines that a new version of the process has appeared and looks in the "Migration Map". The SOUP by the name of the process, the name of the source UserTask, and knowing which version the current process instance was running at, determines the version of the process to be migrated and the name of the item in the new version of the process.

According to these parameters, there is a "jump" between versions. For the user, this happens unnoticed. If after migration in the new version of the process this user does not have access rights to the new element, then a corresponding message appears that the version of the process has been changed and the requested UserTask is not available.

Migration for the remaining tasks occurs without structural changes, i.e. In the same task, but already in the updated version of the process.

Summarizing, we can say that with an increase in the number of used BPNM elements, the flexibility of the processes themselves deteriorates.

To solve this problem and ensure sufficient flexibility and adaptability of the process, modeling occurs at two abstract levels ( Part 2 ). The subject level is described at the top level. The lower level is technical, it describes subprocesses for the upper level.

The golden rule of process modeling: simplify the subject level and transfer everything complicated to the technical level.

I wish you all a simple, understandable and easy modeling!