Responsibilities for Task Assignment

Reading a process is like reading a book. It follows a certain orientation and are read from left to right and top to bottom. Learning BPMN is like learning a language. All the BPMN elements have a specific meaning, like words. The effort is worth it, as you will be able to speak (and even think) in the language of a process.

Assuming we are hungry, let's create a process using basic BPMN elements to describe what we have to do in order to reach the goal of satisfying our hunger.

• A start event to describe what triggers our process
• A sequence flow, which guides us through the process and our tasks
• A task to describe what we have to do
• An end event, which describes the state reached at the end of the process

Imagine your business process is a marble run.

Within a process, there are flows that the marble needs to follow continuously. The only thing that can stop our marble through the process are tasks. Here, the marble has to wait until the task is executed. In the end, we need to make sure all the flows reach the end event, so the marble can cross the finish line every time... sooner or later. If the marble doesn't arrive, we know there is something wrong and the flow was interrupted somewhere.

The marble example above is an easy way to think about the BPMN concept of a 'token'. In BPMN, our marble is officially called a token. The token concept explains the execution behavior of business processes, no matter how complex they are.

Once you grasp this idea, it really helps to understand business process flows, and especially error messages when you check process execution behavior.

Oh, and if you think these 'technical checks' aren't important, since your models aren't supposed to be executed by systems, we're here to tell you - they are!

The same concept applies in:

• BPMN syntax check (applies whenever you save your diagram)
• Process simulation (where tokens can even be visualized)

Select each item below to learn if it is named correctly or not.

Whenever multiple people in a company are involved in process modeling, its important to ensure your consistent with naming. Fortunately, there are naming conventions for tasks and events to ensure all BPMN processes follow the same universal style so they are understood all around the globe.

Keep in mind. Naming conventions for tasks and events are based on Best Practices of BPMN and are therefore not to be recognized as strict policies or rules. You can deviate from it if it is properly justified, meaningful and also comprehensible for the modelers.

So, how can you name an event properly and consistently? There are conventions which help you to identify the IS state. In practice, potential signal words for naming events are:

• [demand] occurred
• [order] received
• [service] available
• [invoice] created
• ...

The term "is" doesn't need to be used necessarily, but helps to make sure you are actually describing an IS state.

Select each item below to learn if it is named correctly or not.

Select each level in the figure for more information.

Following in the real world, BPMN uses another easy-to-remember concept for modeling purposes called Pool and Lane. This concept is used to model responsibilities in business processes. The lanes can be compared to a swimming pool as swim lanes - as they actually look like them.

The pool and lane concept allows assigning tasks to responsibilities instead of the other way around. This makes indeed more sense since every task is performed by someone and assigning the same person to multiple tasks again every time would be very cumbersome (which was the case in notations like EPC, EPC).

A Pool is usually representing the whole organization, in which the process takes place.

Lanes represent the actual responsibility for executing tasks, which could be a role, department, position and even a named person (not recommended).

In general each lane of a pool is responsible for executing all assigned tasks. Since the sequence flow connects the task, a crossing of lane can also be considered as a handover of information and responsibility of execution, so the involved process participants have to interact and communicate with each other.

The usage of pools and lanes is explained with the following story of Tim and Robert, two mates who share an accommodation.

Tim has found a new recipe on the internet but unfortunately, he can't cook very well. Fortunately, his flat-mate Robert loves cooking and is happy to try out the new recipe. However, after cooking the delicious dinner, Robert was so hungry that he could not wait any longer for Tim (who was on a call with his mum). So, he started eating dinner alone.

Tim (Lane)

• buys groceries

Robert (Lane)

• prepares dinner
• eats dinner (Tim is not involved)

While Robert was already eating, Tim has smelled the dinner during his phone call and went to the kitchen - just in time! Now they can both eat together.

Robert (Lane)

• prepares dinner
• eats dinner

Tim (additional process participant)

• is also involved into the task 'eat dinner'

Let's conclude what we have observed in the example above:

• Responsibilities (Lanes) belong to one organization (Pool), in our example: the shared accommodation
• Responsibilities for tasks can be visualized in process models
  • via lanes
  • via additional process participants

Although additional participants are assigned to tasks, there must be one major responsibility owning this task. You can think of a person, who makes sure all assigned additional participants get together.

Note

The additional participant is an SAP Signavio specific element, to be used in BPMN process modeling. It doesn't belong to the official set of elements in the BPMN 2.0 notation.

Find below the possibilities of naming conventions for Swimlanes and select the markers for more information. All the naming styles used in this picture are correct and can be used also in combination, even though the "Person" style should be avoided if possible.

Select each level in the image below for more information.