What is BPMN?
BPMN is a graphical notation for drawing business processes. It is an industry standard first developed in 2002 as the Business Process Modelling Notation and now managed as the Business Process Model and Notation 2.0 by the international, open membership, not-for-profit, technology standards consortium, the Object Management Group (OMG).
The objective of BPMN is to
- assist communication about business processes
- support business process management
- provide a mapping between the notation and computing execution languages such as the Business Process Execution Language (BPEL)
Uses of BPMN Models
Business processes are underlying mechanisms that support the delivery of every organisation's day-to-day services. A business process encompasses participants, tasks and supporting systems that work together to produce an end result that is of value to the organisation. Organisations are becoming increasingly aware of the importance of adopting a process-centric view of their business activities to better coordinate implementation activities.
Business process modelling is a technique that promotes the visual representation of an organisation's business processes. The use of BPMN process models allows an organisation to obtain a view of its business activities so that it can then:
- identify interactions and inter-dependencies between various components of a process
- analyse a process for improvements
- allocate ownership of a process
- identify risk in a process
- apply metrics to a process to measure the impact of any process change
- report the metrics and key performance indicators for use in business performance management
- determine the alignment of a process with business strategy and objectives
- identify the information, applications and technologies associated with a process
- simulate changes to a process and determine the outcome
The following section provides a condensed summary of the most important BPMN elements. For further definitions, please refer to the glossary on page 499 of the OMG specification at https://www.omg.org/spec/BPMN/2.0/PDF.
An Event is something that happens in the course of a Process. Thus Events affect the flow of the process. There are three types of Events, based on when they affect the flow: Start, Intermediate, and End.
Examples of events include the start of an Activity, the end of an Activity, the change of state of a document, or the arrival of a Message. The Start Event and some Intermediate Events have "triggers" that define the cause for the Event. End Events may define a "result" that is a consequence of a Sequence Flow path ending. Start Events can only react to ("catch") a trigger. End Events can only create ("throw") a result. Intermediate Events can catch or throw triggers.
Events are shown as circles with open centres to allow internal markers to differentiate different triggers or results. For the triggers that catch, the event markers are unfilled, and for triggers and results that throw, the markers are filled.
The Start Event indicates where a particular Process will start. It does not have any incoming Sequence Flows. It must have at least one outgoing Sequence Flow. A Start Event may have zero or more incoming Message Flows; each one is a trigger for the Process. Only one of the triggers is required to start the Process. A Start Event cannot have outgoing Message Flows. Use of a Start Event is recommended. Use of multiple Start Events is not recommended as it impedes understanding. A Start Event is a circle drawn with a single thin line. It has an open centre so that markers can be placed within the circle to indicate variations of the Event.
The End Event indicates where a path of the Process will end. It must have at least one incoming Sequence Flow but does not have any outgoing Sequence Flows. An End Event must not have any incoming Message Flows. It can have zero or more outgoing Message Flows; each one will have a Message sent when the Event is triggered. There may be multiple End Events within a single level of a Process. Use of an End Event is recommended. An End Event is a circle drawn with a single thick line. It has an open centre so that markers can be placed within the circle to indicate variations of the Event.
Intermediate Events occur between a Start Event and an End Event. They will affect the flow of the Process but will not start or (directly) terminate the Process.
An Activity is a generic term for work that an organisation performs in a Process. An Activity can be an atomic Task or a non-atomic (compound) Sub-Process. An Activity can have multiple incoming and multiple outgoing Sequence Flows. An Activity can have zero or more incoming and zero or more outgoing Message Flows.
A Task is an atomic Activity in a Process. A Task is used when the work in the Process cannot be broken down to a finer level of detail. Generally, an end-user or an application is used to perform the Task when it is executed. Tasks are drawn as a rounded rectangle with the task name in the centre.
A Sub-Process is a compound Activity that is included within a Process. It is compound in that it can be broken down into a finer level of detail (a Process) through a set of sub-Activities. In a Collapsed Sub-Process, the details of the Sub-Process are not visible in the diagram. Sub-Processes can be used to indicate a group of Activities in a less-cluttered, more compact way. A "plus" sign in a square in the lower-centre of the rounded rectangle indicates that the Activity is a Sub-Process (not a Task) and has a lower level of detail.
A Gateway is used to control the divergence and convergence of Sequence Flows in a Process. The term "Gateway" implies that there is a gating mechanism that either allows or disallows passage through the Gateway. Thus, it will determine branching, forking, merging, and joining of paths. It is recommended that a single Gateway has either multiple input or multiple output flows but not both. Thus, it would take two sequential Gateways to first converge and then to diverge the Sequence Flows. It is recommended that sequence flows connect to the corners of the diamond where possible. Gateways do not represent "work" being done and they are considered to have zero effect on the operational measures of the Process being executed (cost, time, etc.). A Gateway is a diamond that may have internal markers to indicate the type of behaviour control.
Exclusive gateways perform "either/or" decisions (diverging) and merging. A diverging Exclusive Gateway (Decision) is used to create alternative paths within a Process flow. This is basically the "diversion point in the road" for a Process. Only one of the paths is taken. A Decision can be thought of as a question that is asked at a particular point in the Process. The question has a defined set of alternative answers. Each answer is associated with a condition Expression that is associated with the Gateway’s outgoing Sequence Flows. A default path can optionally be identified, to be taken in the event that none of the conditional Expressions evaluate to true.
Inclusive Gateways perform "or" decisions and merging where more than one path can be taken. A diverging Inclusive Gateway (Inclusive Decision) can be used to create alternative but also parallel paths within a Process flow. Unlike the Exclusive Gateway, all condition Expressions are evaluated. The true evaluation of one condition Expression does not exclude the evaluation of other condition Expressions. All Sequence Flows with a true evaluation will be traversed. Since each path is considered to be independent, all combinations of the paths MAY be taken, from zero to all. However, the gateway should be designed so that at least one path is taken. A default path can optionally be identified, to be taken in the event that none of the conditional Expressions evaluate to true. A converging Inclusive Gateway is used to merge a combination of alternative and parallel paths.
A Parallel Gateway is used to model "and" forking and joining, i.e. to create parallel flows and to synchronize (combine) parallel flows. A Parallel Gateway creates parallel paths without checking any conditions; each path is taken. For incoming flows, the Parallel Gateway will wait for all incoming flows before triggering the flow through its outgoing Sequence Flow.
Data Objects provide the information requirements or information products of an Activity. Data Objects model data within the Process flow and must be contained within a Process or Sub-Process element. A Data Object can represent a single instance of a data structure or, with the addition of a set of three vertical lines in the lower-centre of the document shape, it can represent a Collection of data structures. A Data Object can be represented in a Process multiple times, each time referencing the same Data Object instance.
These objects are used to connect Flow Objects to each other.
A Sequence Flow is used to show the order in which Activities will be performed in a Process i.e. the order of the flow. Each Sequence Flow has only one source and only one target. The source and target MUST be from the set of the following Flow Elements: Events (Start, Intermediate, and End), Activities (Task and Sub-Process; for Processes), and Gateways.
A Message Flow is used to show the flow of Messages between two Participants that are prepared to send and receive them. The Participants MUST be in two separate Pools. The Message Flow connects either to the Pool boundary or to Flow Objects within the Pool. They MUST not connect two objects within the same Pool. A Message Flow is a dashed line with an open circle line start and an open arrowhead line end.
Data Associations are used to move data between Data Objects and inputs and outputs of Activities and Processes. They have no direct effect on the flow of a Process. A Data Association is a dashed line with an arrowhead which indicates the direction of the data flow.
A Pool is the graphical representation of a Participant in a Collaboration. It also acts as a "swimlane" and a graphical container for partitioning a set of Activities and their Sequence Flows from other Pools, usually in the context of business-to-business situations. The Sequence Flows can cross the boundaries between Lanes of a Pool but cannot cross the boundaries of a Pool. That is, a Process is fully contained within the Pool. The interaction between Pools is shown through Message Flows.
Another aspect of Pools is whether or not there is any Activity detailed within the Pool. Thus, a given Pool MAY be shown as a "White Box" with all details (e.g. a Process) exposed, or as a "Black Box" with all details hidden. No Sequence Flows are associated with a "Black Box" Pool, but Message Flows can attach to its boundaries.
A Pool is a square-cornered rectangle with a label name separated from the contents of the Pool by a single line.
A Lane is a sub-partition within a Process, sometimes within a Pool, and will extend horizontally the entire length of the Process. Lanes are used to organise and categorise Activities. Lanes are often used for such things as internal roles (e.g. Manager, Contact Centre Staff), systems (e.g. an application), or internal business units (e.g. Finance).
A Lane is a square-cornered rectangle with a solid single line.
Providing a textual description of the business process diagrams is essential to ensure understanding and maintenance of process models. It is strongly recommended that the business process diagrams created in BPM.WIKI are fully described and/or equipped with appropriate metadata (tags, categories).
BPM.WIKI allows the creation of so called "Collections" that can contain any number of diagrams. Collections can be thought of as process models and are meant to provide better access to content that belongs together (i.e. a certain number of sales processes).
Large parts of this condensed BPMN guide are based on the Business Process Model and Notation (BPMN 2.0) guideline licensed under the Creative Commons Attribution 4.0 International license.