This post was originally published at bpmntraining.ru.

Typical BPMN use cases are:

1. create a process-based operations manual (let’s call this “analogue” process modeling)
2. create a BPMS-executable model (let’s call this “digital” process modeling)
3. create process-based software requirements for application developers

Let’s define the analogue/digital divide first and then proceed to use case #3.

• Analogue process is performed by human participants following standard operations procedures manual or some othe document usually combining process diagrams with text instructions. Performers may leverage various tools ranging from phone and desktop calculator to SAP terminal; what’s importaing is that a process performer is responsible not only for completing the assigned tasks but also for transfering the responsibility to the next participant. BPMN is good in depicting who is responsible for what and at what points of the process the “relay baton” is passed.

Fig. 1. Analogue process example

• Digital process execution is controlled by so-called “process engine” - specialized software that tracks the process status, assigns tasks to human performers and makes API calls to various corporate applications functions and/or online services according to the BPMN process model. A process model that a process engine is able to read and follow is called “executable”. In this scenario a human participant is only responsible for completing assigned tasks while the process engine controls the transfer of responsibility. From the participant’s point of view, tasks appear out of nowhere and disappear to nowhere after completion while in fact the process engine immediately assigns the next task to the appropriate performer as soon as the current task is completed.

Fig. 2. Digital process example

It is sometimes argued that BPMN is invented for digital processes only but this is an exaggeration.

The true statement is that many BPMN elements only make sense in a digital processes. E.g.:

• Script and service tasks assume no human performer and therefore are inapropriate for analogue process - there is no one to run them.
• Message event, send and receive tasks, error event, escalation, compensation, etc. are also more suitable for programming an automatic process than for depicting human performers’ activities.

These two different BPMN applications utilize different subsets of BPMN palette so I recommend to make it clear before starting a modeling excercise: are we dealing with a digital process or analogue one? If it’s an analogue process then one should use the reduced BPMN palette that includes user task, two or three types gateways, subprocesses, multi-instance loops, timer, terminator, lanes, data objects and data stores, annotations. You may be surprised how much can be done with such a limited set of elements, if used wisely.

Otherwise - in the case of a digital process - one may use complete BPMN palette including messages, conditional events, errors, escalations and others.

Outside view of the application - user’s perspective

Computer applications are usually considered as a “black box” both in analogue and digital business processes: user presses a button, some magic occurs in the application and voila - the money are transferred between customer’s deposit and credit card or a product is reserved for sale in the warehouse database. It is assumed that business is always done by people and whatever tools they may use - a phone, paper and pencil, a spreadsheet or an ERP system - they are just tools.

Let’s consider receiving goods delivered by supplier as an example. The simplified process comprises three tasks triggered by the supplier’s truck arriving to the warehouse gate:

Fig. 3. Receiving goods at the warehouse, outside view

One may add a custom annotation to specify the computer application used:

Fig. 4. Custom annotation

Inside view of the application - developer’s perspective

Now let’s consider the third BPMN use case scenario: process automation. Let’s suppose that we are in charge of designing and developing the warehouse application.

The common “black box” approach would be inapropriate if the application does not yet exist or if we are going to redesign it. In this case we must not only explain process performers where to use the application but also explain to the developers what the application should do.

The common - naive - approach is to show the activities performed by the human and by the application in a sequence:

Fig. 5. Receiving goods at the warehouse, combined outside/inside view

Here we have used the lane to depict activities performed by the application. It’s pretty legal - lanes in BPMN may be used for everything but external participants.

Digital subprocess within analogue process

I’m not comfortable with the diagram depicted in Fig. 5 because it assumes that the process is digital since there are service tasks. But what if there is no process engine to execute the sequence of human and serivce tasks?

I’d recommend the two-layer approach:

• the outer (process) layer presents end-to-end logic
• the inner (subprocess) layer presents application internals

Fig. 6. Layered process

Here the “Goods receipt processing” is implemented as a reusable process invoked from the “Goods acceptance” end-to-end process via call activity.

Conclusions

1. Use the reduced BPMN palette if there is no process engine to execute the process.
2. Depict the computer application via lanes and/or custom annotations.
3. Use script and service tasks performed by an application internally only if you are (re)designing it.
4. Use subprocesses to integrate application internals into end-to-end process logic.