BPMN (Business Process Model and Notation) is a de-facto standard for modeling detailed processes for documentation and automation purposes.
When it comes to process documentation, each good process model should help us answer the questions we have for a process.
Those questions differ from organization to organization, but most commonly what we need to know is:
1) What starts the process
2) What are the results of a process
3) What needs to be done
4) What are the possible variants
5) Who does what
BPMN helps us answer all those questions and more using few simple object types shown in a graphic below.
Points 1 and 2 help us understand the scope of the process, the process boundaries.
In BPMN we use Events (depicted as circles) to show what starts a process (Start Events – see element 1), what are the results of a process (End Events – 2a and 2b), but also what can happen during the process and how do we handle those events (Intermediate Events).
Point 3 helps us understand what is the work to be done inside a process. Elements representing the work are called Activities in BPMN and are shown as rounded rectangles.
When the work is simple we use the Tasks (3a). When work is complex and can be divided into many elements we use Sub-Processes (often shown with a “+” marker in a box like in case of 3b).
Point 4, helps us understand how does the process flow. Usually, we model not only so-called “happy path”, but also some exception flows – potentially leading to different End Events.
In BPMN we split (and merge) the process flows using Gateways, shown as diamonds (4). Process flow itself follows the arrow called Sequence Flow (e.g. 4a and 4b).
Last, but not least we often want to know what are the process participants (so for example what are the organizations we are interacting with) and who is responsible for performing tasks in our organization.
In BPMN the former can be documented using so-called Pools (5), while the latter is done using Lanes (5a and 5b), which are divisions of Pools.
Before we start BPMN modeling
While it may be tempting to start modeling right away it is often a good idea to start from a process architecture. This way we can make sure that we consider all the processes and see how are they connected.
Starting from a process architecture also helps us create a high-level overview of the process (WHAT), before we start the detailed modeling (HOW).
There are many approaches for documenting higher level view of the process including SIPOC and IGOE (see e.g. https://www.brcommunity.com/articles.php?id=b634). The important thing, however is that we can capture various aspects of the process like goal, triggers, results, resources etc. which will be useful when we start detailed modeling.
Want more?
This is a part of a book about BPMN I am working on. Sign up for updates&get the latest version.
