The previous post, titled “Static and dynamic processes” (part 1), touched upon the division of processes into static and dynamic processes, as well as the risks involved with the static modeling of processes which are in fact dynamic in nature, such as processes pertaining to construction management, the work of an MD in a hospital ER, or that of a flight controller at an airport, or, in more general terms, also the business decision-making process itself.

     1. Static flowchart modeling

The modeling of such processes can, of course, include all of the possible and probable actions leading to decisions or further actions.

Figure 1. Example of static decision-making process modeling.

 However, the process pictured in Figure 1 is bound not to foresee all of the possible needs and possibilities, which means that it will no doubt require continued modifications in the process modification phase. The management will be sure to find out about such needed alterations as far along as in the process of evaluating the effects of suboptimal or even flawed decisions. The process will become less and less transparent and will start to include “just in case” provisions, as well as call upon disinterested individuals for no good reason to oversee decisions in specific situations. Perhaps it would be wiser to model decision-making processes in reaction to specific events?

     2. Event context modeling

Let us take a closer look at an example of the static modeling of decision-making processes based on the specific event context.

Figure 2. An example of the static modeling of decision-making processes based on the specific event context.

   XOR, OR, and event-based gates are used to distinguish between different kinds of agreements / contexts of signing an agreement. An event-based gate also offers us the option of distinguishing between e.g. time contexts of signing particular kinds of agreements, e.g. delays and no time for negotiation, as well as the need to make a decision despite not being able to finish the consultation process. Regardless of which gate we choose, we are presented with a process which depicts a list of all possible variants of a given decision. Even when all of the variants are modeled in an optimal manner, the number of potential variants will increase with time like in the previous example, and this increase will result in wrong decisions being made. Of course, all of the variants are just optimal for the time being. With time, all of them will accumulate the risks and drawbacks from the previous example.

     3. Event sub-process modeling

The BPMN standard enables us to extract the management of specific kinds / contexts from the main decision-making process, and depict it in the form of independent event sub-processes triggered by business events.

Figure 3. An example of static modeling of decision-making processes with the use of event sub-processes.

            As before, such a solution requires us to define all of the variants / contexts of signing an agreement in the course of the modeling phase. And as in the previous examples, this solution also runs the risk of being incomplete or too complex. However, it leaves us with a more transparent graphic diagram and enables us to make use of predefined sub-process templates with ease. In a practical implementation, the sequence of executing subsequent processes depends on the time of their appearance and the priorities assigned to them in BPMS.

     4. Dynamic process modeling

BMPN2.0 offers us the option to model an ad-hoc sub-process which allows us to perform multiple non-organized, non-prioritized, but predefined actions. Such actions can take the form of actions (the equivalent of a checklist) or short sub-processes (the equivalent of business scenarios, also offering the option of using predefined sub-process templates). The actions can involve the ad-hoc sub-process performer, as well as other individuals. In most implementations in BPMS systems (e.g. Bizflow), the process performer can also perform actions which were not taken into account in the initial process modeling phase. In regard to each action, performers of ad-hoc processes can make use of documents (data objects), IT systems (data objects), or virtually any other objects which fit within the predefined attributes.

Figure 4. An example of dynamic decision-making process modeling

The diagram from Figure 4 enables the process performer to perform selected consultations (one consultation, a selected number of consultations, or all of them) on a one-time basis or on a repeated basis as required (e.g. finance > vendor > finance > Topic manager > another finance consultation etc.). Each time, the results of particular actions are notified in appropriate data objects. By reading the timestamps associated with performing specific actions in the BPMS system log, we are able to determine the performer, the sequence, and the results of each action. With such data readily available at hand, building a knowledge base on the subsequent performances of a given process. their course, data, results, and the individual process performers, is just one simple step away.

Instead of supplementing the static “Sign an agreement” process with additional consultations, the logic conditions for performing a process, and process priorities, the possible options were described in the form of a single, much more transparent diagram, empowering the process performer to perform the process in accordance with the requirements of a specific business process case. Such a solution supports normal, natural work-flow, which draws from the engagement, creativeness, and the knowledge of the employees. Furthermore, it reduces the risks associated with performance thanks to full transparency and the ongoing oversight of ad-hoc actions, preventing the so-called “hidden factory” effect.

Follow