BPMN

Introduction

The Business Process Modeling Notation (BPMN) is a standardized graphical notation for drawing business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is now being maintained by the Object Management Group since the two organizations merged in 2005. The intent was to identify the best practices of existing approaches and to combine them into a new, generally accepted language.

Diagramme in der BPMN heißen Business Process Diagram (BPD). A diagram with different pools collaboration diagram.

A goal for the development of BPMN is that the notation be simple and adoptable by business analysts. Also, there is a potentially conflicting requirement that BPMN provide the power to depict complex business processes and map to BPM execution languages. To help understand how BPMN can manage both requirements, the list of BPMN graphic elements is presented in two groups. First, there is the list of core elements that will support the requirement of a simple notation. Second, there is the entire list of elements, including the core elements, which will help support requirement of a powerful notation to handle more advanced modeling situations.

Versions

1.0 2006
- Die BPMN wurde 2002 durch Stephen A. White, Mitarbeiter von IBM, erarbeitet und durch die Business Process Management Initiative (BPMI) veröffentlicht.
1.1 see here for changes to 1.0
- signal event
- multiple instance marker not a pause symbol anymore
- optical difference between throwing and catching events
- event bases gateway and complex gateway => no star, but pentagon

Missing Functionalities

The modeling of the following will not be a part of BPMN:

Organizational structures and resources
Functional breakdowns
Data and information models
Strategy
Business Rules

Notation

Colours have no meaning, but can be used.

There are for categories (s. 1. in Resources sheets BPMN-I, BPMN-II):

Swimlanes
- Pools
- Lanes
Flow Objects
Connecting Objects
- sequence flow
- message flow
- association

Artifacts
- data objects
- groups
- annotations

Swimlanes

Pools

Ein Pool ist ein Behälter für einen vollständig abgeschlossenen Prozess. Die Aktivitätenabfolge kann eine Poolgrenze nicht überschreiten, sondern nur innerhalb des Pools modelliert werden. Die Pools interagieren über den Austausch von Nachrichten. Ein Pool kann ein Unternehmen, eine Organisationseinheit, eine Person oder ein Computersystem sein. Silver empfiehlt einen Pool pro Prozess zu verwenden und den Pool wie den Prozess zu benennen. Eine Choreographie beschreibt das Zusammenwirken von Prozessen in unterschiedlichen Pools.

Pools können entlang ihrer Ausdehnung wiederum in Lanes unterteilt werden, wobei ein Pool mindestens eine Lane enthalten muss. Die Frage, ob Pool oder Lane scheint nicht eindeutig zu beantworten sein. Kriterien könnten sein:

ist Prozessinformation z.B. Status notwendig, dann Lanes
ist Änderbarkeit oder Transparenz notwendig, dann Pool
Prozess- und Bearbeitungsübergänge, dann Pool

Lanes

Eine Lane repräsentiert jeweils eine ausführende Einheit (Rolle, Funktion, Position9. Möglich ist auch eine Lane pro System (alternativ Kennzeichnung der Activities durch eine System-spezifisches Icon).

Flow Objects

Activities

can have an icon

Subprocess

can also shown in a BPD inline/expanded

Events

Start Events

Start events are always catching.
There can be more than one start event. For each event a separate process instance is started.
There are six different start events.
The undefined start event represents normally the manual process start by an user.
There should be only one undefined start event.

Intermediate Events

Intermediate can be split in catching und throwing.
Catching intermediate events are waiting until the event arrives.
Intermediate events at an activity borders are catching events which trigger the cancellation of the activity.
undefined intermediate events can e.g. be used to model state transitions of objects

End Events

end events are always throwing.
there can be more end events.
a process instance lives until the last token arrived at an end event or a process terminating end event is reached.

Gateways

Gateways can have multiple outgoing paths
Default outgoing path is always the only outgoing path, because it is only used when no condition fits
the merging gateways has to be the same as the splitting gateway

Exclusive Gateway

also called 'split and merge'
exactly one outgoing path gets the token
if the condition leads to no or more than one outgoing paths is a modelling error

Parallel Gateway

other names: AND-join, synchronizing join
merge only, when all ingoing paths have the token
doesn't have to be merged, can end in separate end events. In that case process or subprocess isn't finished until all end events are reached.

Inclusive Gateway

one or more outgoing path gets the token
merge only, when all paths which got the token have the token

Complex Gateway

merge by rules

Event-based Gateway

selects exactly one outgoing path based on the incoming event

Connecting Objects

Sequence Flow

may not go out of a pool

Message Flow

message flows are only allowed between different pools
tasks can only be completed when the the message to this task has arrived

Associations

no flow information

Modeling Conventions

use of gateways
implicit or explicit start events
implicit or explicit end events

Questions

send messages asynchron
event symbol waiting
end signal whole process or just the path
mehrere end events in subprocesses

Resources

C:\Uwes\Documents\Software_Development\Modeling\BusinessProcessModeling\BPM.vsd
Short, good Introduction C:\Uwes\Documents\Software_Development\Modeling\BusinessProcessModeling\Introduction_to_BPMN.pdf
Poster mit Elementen C:\Uwes\Documents\Software_Development\Modeling\BusinessProcessModeling\BPMN1_1_Poster_EN.pdf
BPMN Wikipedia http://de.wikipedia.org/wiki/Business_Process_Modeling_Notation Wikipedia