Synchronous and asynchronous processes

The world can learn a lot from programmers. He already studies, but not to that and not so. For example, he took processes and algorithms, but did not notice such an approach as asynchrony.

Any programmer understands what synchrony and asynchrony are. This is how much it is clear to the programmer, as it is also incomprehensible to ordinary process developers.

Synchronous process actions are those that are executed in the main thread, within a single process instance. The key difference of the synchronous mode: the next action starts only when the previous one is completed. Accordingly, until one action is completed, the process is worth the stake.
')
Asynchronous actions are those that are executed in parallel to the main thread, either in the same process instance or in general in another process. The key difference of the asynchronous mode: parallel execution of two or more branches of the process.

Synchronous processes, like programs, are much easier to write and debug, so this approach to process design is very common. It is necessary to tinker with asynchrony a lot, especially with the designation of points of transition to parallel execution and return back to the mainstream. There are no promises in life.

For example, the same procurement process on request. It is drawn as a standard sequence of actions: a request appears, the supplier selects a supplier, requests time and cost, coordinates with the seller or the internal control department, creates an order for the supplier, asks the counterparty’s assessment in the legal department or in accounting, creates a request for payment, waits for this payment, tracks the order, then organizes or tracks the posting in the warehouse, in the end, close the application. The process is completely synchronized.

Now let's imagine - in our information system the supplier evaluation service is not connected. This means that the legal department needs to collect information from open sources. This means that it takes time to complete the assessment. Given the queue of applications to lawyers, it will take three days.

What will happen to the process at this time? According to synchronous logic, it will be a stake. The supplier, being the right element of the system, will not lift a finger until he receives a supplier's assessment - especially if there are sanctions for working with unverified counterparties.

Can we add asynchrony here? Of course. At that moment, when the supplier has chosen a supplier, he can send a request for an assessment of the counterparty to the legal department, while he himself will negotiate, agree on prices and terms. By the time he is ready to place an order, and the estimate will come in time. The process will end three days earlier.

Of course, lawyers may be indignant - what will we evaluate this supplier, if you have not clearly decided there, will you order from him? What do they answer?

The decision suggests itself, above we have already identified it - to connect the supplier evaluation service. Now we even better understand why it is needed - to impart asynchrony and speed up the process. Although the service will probably be just synchronous. What do you think?

If the service is not connected, it is possible to justify such an assessment of the work "for the future." If your information system has where to write these estimates, then the next time the need arises to work with this supplier, you will no longer have to contact the legal department. Of course, the evaluation has an expiration date, but it can be used in some reasonable limits.

In asynchrony, the lack of guarantees usually scares, that is, the risk of a negative result in one of the parallel branches of the process. What if the negotiation fails?

Here you need statistics. If you work with an existing process, then approximately, or exactly, imagine how often certain actions end up negatively - for example, coordination. It is from this probability that it is worth proceeding by launching parallel execution.

Asynchrony is straightforward in all coordination processes. If you work there only in a synchronous mode, and, moreover, follow the instructions of the coordinators, then long, interdependent chains are formed, generating bureaucracy and mutual responsibility.

A typical example: “I will agree only after it agrees.” Or "I will look at this contract only after the financiers." Although, according to statistics and common sense, such statements have no basis, and are only a way to shift responsibility.

The main thing here is not to worry, and not to take on everything at once. Try to select in asynchronous mode, first one branch of coordination. It may be necessary to revise the task, the parameters of coordination - so as to eliminate interdependence.

For example, let the financial department, standing in the chain of agreement of the contract, looking only at the terms of payment. Let him have his own, clear assessment criteria. It is better if they are formalized in the form of a model contract - for example, 100% post-payment for suppliers, 100% prepayment for buyers. In this case, the contracts that meet the criteria, will slip on time. And financiers will have no reason to wait for an assessment from the same lawyers.

The only thing that matters is that asynchronous processes are very difficult to implement without automation. If processes, their execution and tracking are implemented only on paper, then adding parallel branches will turn them into chaos. Need automation.

Best of all for such automation the principle of "Autotasks" is suitable. Although you can get by with the standard means of drawing processes that exist in modern platforms, you just have to tinker.

Standard "drawing" processes will require you to identify the entire process, all branches and relationships. If the process is complex and long, then you will encounter a problem - it will trivially stop climbing on the screen, wide. If you studied at the institute as a programmer, then remember the following rule for the design of algorithms: no more than three parallel vertical branches. The rule was invented for a reason - if there are more branches, it will be problematic to understand the algorithm scheme.

Autotasks from this problem relieve - there is no process image at all, because there is no such entity - process. There are tasks. If you really want, you can assemble a process from them. But not the other way around. A kind of deductive method of drawing processes.

In addition to asynchrony, there is an even more powerful optimization method - process buffering. About him - another time.