Responsibilities for Task Assignment

Reading a process is like reading a book. It follows a certain orientation and is 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 do. The effort is worth it, as you can 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 must do 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 must do.
• An end event, which describes the state reached at the end of the process.

Imagine that your business process is a marble run.

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

The marble example 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.

If you think these 'technical checks' aren't important, because your models are not executed by systems, we're here to tell you - they are important.

The same concept applies in:

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

If you apply the token concept properly, you can understand any BPMN process model, no matter how complex.

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

Keep in mind that 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 identify the IS state. In practice, potential signal words for naming events are:

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

You don't need to use the term "is", but it helps to ensure that you are actually describing an IS state.

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 you to assign tasks to responsibilities,rather than the other way around. This makes more sense because every task is performed by someone, and assigning the same person to multiple tasks every time is cumbersome (which was the case in notations such as EPC).

A Pool usually represents the whole organization in which the process takes place.

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

In general, each lane of a pool is responsible for applying 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. Therefore, participants must 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 found a new recipe on the internet. However, Tim can't cook very well. Fortunately, his flat-mate Robert loves to cook and is happy to try 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 (extra process participant)

• is also involved into the task 'eat dinner'

Let's conclude what we have observed in our dinner eexample:

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

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

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