Business Process Model and Notation (BPMN) is the global standard for process modeling and one of the most important components of a successful Business-IT-Alignment.
More and more organizations are using BPMN and in more and more universities BPMN is taught as a subject. These are the reasons:
Let's begin our BPMN tutorial with a rather simple process diagram:
This diagram shows a simple process triggered by someone being hungry. The result is that someone must shop for groceries and prepare a meal. After that, someone will eat the meal and have his or her hunger satisfied.
When naming tasks, we try to adhere to the object-orientated design principle of using the [verb] + [object] pattern. We would say "acquire groceries," for example, not "first take care of shopping for groceries."
Events refer to something that has already happened regardless of the process (if they are catching events) and as a result of the process (if they are throwing events). For this reason, we use the [object] and make the [verb] passive in voice, so we write "hunger noticed." BPMN does not require you to model start and end events for a process - you can leave them out - but if you model a start event, you must model an end event for each path. The same is true for end events that require start events. We always create our models with start and end events for two reasons: first, that way it's possible to determine the process trigger, and second, you can describe the final status of each path end. We only sometimes abandon this practice with sub-processes. More on this later.
You could always draw your diagrams from top to bottom instead from left to right - the BPMN 2.0 standard does not forbid it. However we do not recommend it: It is very uncommon, and experience has proven that people tend to understand the process flow better if it is described in the same way like written text (from left to right, at least in the western world).
In this diagram you can find the preparing steps a hardware retailer has to fulfill before the ordered goods can actually be shipped to the customer:
In this example, we used only one pool and different lanes for the people involved in this process, which automatically means that we blank out the communication between those people: We just assume that they are communicating with each other somehow. If we had a process engine driving this process, that engine would assign user tasks and therefore be responsible for the communication between those people. If we do not have such a process engine, but want to model the communication between the people involved explicitly, we would have to use a collaboration diagram as in the next chapter.
This example is about Business-To-Business-Collaboration. Because we want to model the interaction between a pizza customer and the vendor explicitly, we have classified them as "participants", therefore providing them with dedicated pools:
Please note that there is no default semantics in this type of modeling, which means you can model collaboration diagrams to show the interaction between business partners, but also zoom into one company, modeling the interaction between different departments, teams or even single workers and software systems in collaboration diagrams. It is totally up to the purpose of the model and therefore a decision the modeler has to make, whether a collaboration diagram with different pools is useful, or whether one should stick to one pool with different lanes, as shown in the previous chapter.
Here you can find lots of additional practical BPMN examples and patterns.
If you want to get a deeper understanding of BPMN 2.0, you can