bpmn - staud.info · das mit der bpmn verfolgte ziel ist somit, eine standardvisualisierungsme-...

BPMN - Einführung und Einschätzung ENTWURF / DRAFT

©2014 Josef L. Staud

Autor: Josef L. Staud

Inhaltlicher Stand: Februar 2012

Umfang: 71 Seiten

Dieser Text richtet sich an meine Studierenden. Er befindet sich im Ent-wurfsstadium. Der geplante Fertigstellungstermin ist Dezember 2014.

Urheberrrecht

Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, ins-

besondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen oder der Vervielfältigung auf anderen Wegen und der

Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser

Verwertung, vorbehalten. Eine Vervielfältigung dieses Textes oder von Teilen

dieses Textes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestim-

mungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. Sep-

tember 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich ver-

gütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtsgesetzes.

Warenzeichen und Markenschutz

Alle in diesem Text genannten Gebrauchsnamen, Handelsnamen, Marken, Pro-

duktnamen, usw. unterliegen warenzeichen-, marken- oder patentrechtlichem

Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen

Inhaber. Die Wiedergabe solcher Namen und Bezeichnungen in diesem Text be-

rechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche

Namen im Sinne der Gesetzgebung zu Warenzeichen und Markenschutz als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Prof. Dr. Josef L. Staud

2 1 Einleitung

Josef L. Staud: BPMN - Einführung und Einschätzung /Entwurf, Draft. Geplante Fertigstellung: Dezember 2014

1 Einleitung

1.1 Um was geht’s?

Die Business Process Modeling Notation (BPMN) wird von ihren Autoren als DIE

Methode zur Prozessmodellierung gesehen. Sie soll die Lücke zwischen einfachen

“Business-Anwendern” und Programmnähe schließen. Überraschenderweise

scheinen sie anzunehmen, dass „einfache Anwender“ Flussdiagramme verwenden

[OMG 2009, S. 11]. Dies ist schon erstaunlich. Die Methoden von außerhalb der

USA scheinen die Autoren nicht zu kennen, nicht mal die doch in Deutschland

und Europa weit verbreiteten Ereignisgesteuerten Prozessketten (EPK).

Bezeichnungen: BPMN: Business Process Modeling Notation. Ab Version 2.0: Business Process Model and Notation

BPD: Business Process Diagram

Eine Abgrenzung nehmen sie nur vor gegen „web service-based XML execution

languages for Business Process Management (BPM) systems“. Sprachen wie

BPEL4WS, die sie als zu formal ansehen für „business people“.

Ihr Standpunkt ist folgender: “Business people” sind sehr vertraut damit, Ge-

schäftsprozesse in einem “flow-chart format” zu visualisieren – und – es gibt

Tausende von “business analysts”, die mit Hilfe der “flow charts” untersuchen,

wie Unternehmen arbeiten und die damit auch Geschäftsprozesse definieren

[OMG 2009, S. 11].

Dadurch sehen sie eine Lücke und die Motivation für BPML. Denn obiges führt

ihrer Ansicht nach zu einer technologischen Lücke (“technical gap”) zwischen

dem Format der ersten Entwürfe von Geschäftsprozessen und dem Format von

Sprachen wie BPEL4WS, die diese Geschäftsprozesse ausführen. Und genau diese

Lücke wollen sie überbrücken mit einer formalen Sprache, die die geeignete Vi-

sualisierung der Prozesse (“a notation”) auf ein geeignetes “execution format”

(eine „BPM execution language“) abbildet [OMG 2009, S. 11].

Das mit der BPMN verfolgte Ziel ist somit, eine Standardvisualisierungsme-

thode für Geschäftsprozesse zu liefern, die in einer für die “execution” optimierten

“business process language” definiert ist.

Vorgesehene Abdeckung

Die Business Process Modeling Notation soll sich auf Modellierungskonstrukte

konzentrieren, die für Geschäftsprozesse geeignet sind [OMG 2009, S. 12]. Nicht

betrachtet werden sollen insbesondere:

Der Anspruch

1.2 Ziel 3


Organisationsstrukturen

Funktionen und ihr Aufbau

Datenmodelle

Strategiebetrachtungen

Geschäftsregeln

Dies bedeutet eine starke Einschränkung gegenüber einer sinnvollen und notwen-

digen Abdeckung. Insbesondere dann, wenn die Geschäftsprozessmodellierung

einer Unternehmensmodellierung dienen soll.

1.2 Ziel

Ein Ziel der BPMN-Autoren war Einfachheit, die es aber trotzdem erlauben sollte,

die Komplexität, die Geschäftsprozesse nun mal aufweisen, zu beherrschen [OMG

2009, S. 17]. Dabei ensteht für die Autoren ein Konflikt. Einerseits soll die Me-

thode ermöglichen, komplexe Geschäftsprozesse zu modellieren, andererseits soll

sie die Abbildung auf “BPM execution languages” erlauben. Die Lösung sehen sie

wie folgt:

Erstens durch die Definition einer Menge von “Kernelementen”, die den

Anforderungen an eine einfache Darstellungstechnik genügen. Damit sollen

die meisten Situationen in Geschäftsprozessen bewältigt werden können.

Zweitens durch zusätzliche Elemente, mit denen zusammen anspruchsvollere

Modellierungssituationen bewältigbar sein sollen.

Drittens durch nicht-grafische Elemente. Diese sollen zusätzliche Informatio-

nen liefern, die notwendig sind für eine „execution language“ oder andere

Modellierungsvorhaben.

1.3 Geschäftsprozesse

Wie definieren die BPMN-Autoren Geschäftsprozesse? Im Text finden wir

folgende Definitionsmerkmale (S. 32):

Ein Geschäftsprozess ist eine Aktivität, die in einem Unternehmen (oder einer

Organisation) oder zwischen mehreren ausgeführt wird.

Er besteht aus mehreren Aktivitäten und den Sequenzflussmechanismen, die

sie strukturieren.

Prozesse gibt es auf mehreren Hierarchieebenen. Man kann sie

unternehmensweit definieren oder auch entlang der Aktivitäten einer Person

[OMG 2009, S. 32].

Prozesse auf einem niedrigen Aggregationsniveau (low-level processes), die

zusammen eine Aufgabe erledigen, können gruppiert werden.

Jeder Prozess kann seine eigenen Subprozesse haben und kann in einem Pool

enthalten sein.

Einzelne Prozesse können voneinander unabhängig sein, was den Sequenz-

fluss angeht, aber verbunden durch einen Nachrichtenfluss.

Prozess vs. Geschäftsprozess

Bezüglich der Abgrenzung von Prozessen und Geschäftsprozessen führen die

BPMN-Autoren aus, dass sie den Begriff Prozess ziemlich spezifisch sehen und

4 1 Einleitung


den des Geschäftsprozesses allgemeiner als eine Menge von Aktivitäten, die in-

nerhalb einer Organisation oder über Organisationen hinweg realisiert werden.

Somit kann ein Geschäftsprozess, wie er in ein Business Process Diagram inte-

griert ist, mehr als einen separaten Prozess enthalten.

1.4 Prozesstypen

Im Rahmen ihrer Typisierung von Geschäftsprozessen sprechen sie von “end-to-

end BPMN model”, in dem sie wie folgt unterscheiden:

Interne Geschäftsprozesse (private (internal) business processes)

Öffentliche Geschäftsprozesse (abstract (public) processes)

Globale Geschäftsprozesse (collaboration (global) processes)

Mit Internen Geschäftsprozessen sind schlicht die gemeint, die innerhalb eines

Unternehmens ablaufen. Da die Zuordnung von Trägern der einzelnen Tätigkeiten

zu den Geschäftsprozessen in der BPMN über die Schwimmbahnentechnik mit

Becken und Bahnen erfolgt (vgl. Kapitel 4), können die BPMN-Autoren auch

definieren, dass die internen Prozesse in einem Becken (pool) ablaufen.

Kommt es zu einer Interaktion (i.d. Regel ist dies ein Informationsfluss, z.B.

eine Rechnung) zwischen einem internen Geschäftsprozess und anderen Prozes-

sen oder Partizipanten, sprechen die BPMN-Autoren von einem öffentlichen Ge-

schäftsprozess. In diesen wird folgendes gepackt:

Die Aktivitäten, die benutzt werden, um mit der Umgebung des privaten

Geschäftsprozesses zu kommunizieren.

Die entsprechenden Sequenzflusselemente.

Alle anderen Aktivitäten des internen Prozesses werden nicht angegeben [OMG

2009, S. 13]. Somit zeigt der öffentliche Prozess der Außenwelt die Folge von

Nachrichten, die notwendig sind, um mit diesem Geschäftsprozess zu interagieren.

Ein Globaler Prozess beschreibt das Zusammenwirken von zwei oder mehr

Geschäftseinheiten (business entities). Die Interaktionen sind eine Folge von Ak-

tivitäten, die den Nachrichtenaustausch zwischen den handelnden Einheiten dar-

stellen. Näheres hierzu und ein Beispiel findet sich unten.

1.5 Diagrammtypen

Folgende Diagrammtypen sollen mit der BPMN modellierbar sein [OMG 2009a,

Seite 14f]:

Hoch aggregierte interne Prozesse

Detaillierte interne Geschäftsprozesse (Istprozesse, Sollprozesse)

Detaillierte interne Geschäftsprozesse mit Interaktionen zu einem externen

Partner oder zu mehreren

Zwei oder mehr detaillierte interne Geschäftsprozesse, die miteinander inter-

agieren

Detaillierte Geschäftsprozesse mit Beziehungen zu einem öffentlichen Pro-

zess

Interne

Geschäftsprozesse

Öffentliche Geschäftsprozesse

Globale Prozesse

1.6 Gruppierung der Elemente 5


Beziehungen eines detaillierten internen Geschäftsprozesses zu einem globa-

len Prozess

Zwei oder mehr öffentliche Prozesse

Beziehung(en) eines öffentlichen Prozesses zu einem globalen Prozess

Einen globalen Prozess alleine („e.g., ebXML BPSS or RosettaNet“)

Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch einen öffent-

lichen Prozess interagieren

Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch einen globa-

len Prozess interagieren.

Zwei oder mehr detaillierte interne Geschäftsprozesse, die durch ihre abstrak-

ten Prozesse und einen Kollaborationsprozess interagieren.

Ganz nebenbei wird in obiger Liste bzgl. der vertikalen Dimension noch die nahe-

liegende Unterscheidung von

hoch aggregierten Aktivitäten interner Prozesse und

detaillierten internen Geschäftsprozesse

eingeführt. Somit haben wir insgesamt folgende Prozess- und Geschäftsprozessty-

pen in der BPMN:

Hoch aggregierte Aktivitäten interner Prozesse

Interne Geschäftsprozesse

Detaillierte interne Geschäftsprozesse

Öffentliche Geschäftsprozesse

Globale Prozesse

Grenzen

Folgende Grenzen formulieren die BPMN-Autoren für ihre Methode: Falls zu

viele Typen von Submodellen kombiniert werden, z.B. drei oder mehr interne

Prozesse mit Nachrichtenfluss zwischen all diesen, dann könnte die Abbildung zu

schwierig zum Verstehen werden. Deshalb empfehlen sie, sich zu konzentrieren,

z.B. auf einen internen oder einen globalen Prozess [OMG 2009a, Seite 15].

1.6 Gruppierung der Elemente

Die BPMN-Autoren teilen die verwendeten Elemente in vier Gruppen ein:

Flussobjekte (flow objects)

Verknüpfende Objekte (connecting objects)

Schwimmbahnen (swimlanes)

Artifakte (artifacts)

Die Flussobjekte werden noch unterteilt in:

Ereignisse

Aktivitäten

Gateways (Operatoren, vgl. unten)

Als verknüpfende Objekte werden die bezeichnet, mit denen die Flussobjekte

miteinander verknüpft werden können. Dies ist möglich durch:

6 1 Einleitung


Sequenzfluss

Nachrichtenfluss

Assoziationen

Schwimmbahnen dienen der Gruppierung der Basismodellelemente. Hier wird

unterschieden in

Becken (pools)

Bahnen (lanes)

Artifakte liefern zusätzliche Informationen über den Prozess. Drei werden vorge-

geben, andere können – so die BPMN-Autoren – hinzugefügt werden:

Datenobjekte

Gruppen

Anmerkungen

1.7 Token

Ebenso wie die UML-Autoren nutzen auch die BPMN-Autoren das Token-

Konzept. Wie in [Staud 2010] ausgeführt, dient es dort zur Verdeutlichung des

Kontrollflusses, hier also des Sequenzflusses.

Ein Token durchläuft also die Ablauffolge und die Flussobjekte des Prozesses.

Das Verhalten des Prozesses kann beschrieben werden, indem die einzelnen Pfade

des Tokens durch den Prozess festgehalten werden. Betrachtet man den

Tokenfluss eines konkreten Durchgangs, entsteht so etwas wie eine Instanz des

Geschäftsprozesses.

Ein Token hat eine Identität (TokenID), die benutzt werden kann, um

verschiedene Token zu unterscheiden, die wegen verschiedener Prozessinstanzen

existieren können oder weil der Token für die Parallelverarbeitung in einer

Prozessinstanz aufgeteilt wird. Das parallele Aufteilen eines Token erzeugt ein

„lower level of the TokenId set“. Die Menge aller Ebenen von TokenId

identifiziert einen Token. [OMG 2009a, Seite 36].

Grundsätzlich gilt, dass ein Startereignis einen Token erzeugt, der eventuell bei

einem Schlussereignis verbraucht wird (entweder explizit in der Abbildung ausge-

drückt oder implizit, falls nicht). Der Pfad der Token sollte nachvollziehbar sein

durch das Netzwerk des Sequenzflusses, der Gateways (Operatoren) und Aktivitä-

ten im Prozess. Es darf im Verlauf des normalen Sequenzflusses keine impliziten

Flüsse geben, d.h., es muss immer entweder ein Sequenzfluss da sein oder ein

„graphical indicator“ wie ein Zwischenereignis um alle potentiellen Wege von

Token aufzuzeigen.

Impliziter Fluss

Ein Beispiel eines impliziten Flusses ist, wenn ein Token an einem Gateway (Operator) ankommt, aber

keines der Gates (keine der Bedingungen) gültig ist, denn dann geht der Token (implizit) an das Ende

des Prozesses.

Instanzen

1.7 Token 7


Token können auch durch Ereignisse mitten im Sequenzfluss (Zwischenereignis-

se, vgl. unten) gesteuert werden, die Ausnahmen erfassen, die wie ein erzwunge-

nes Ende einer Aktivität wirken.

Die BPMN-Autoren merken ausdrücklich an, dass ein Token nicht entlang ei-

nes Nachrichtenflusses „wandern“ kann.

8 2 Einführende Beispiele


2 Einführende Beispiele

2.1 Das erste Business Process Diagram

Es sieht am Anfang ganz vertraut aus, wenn man die UML-Methoden (insbeson-

dere Aktivitätsdiagramme) und Ereignisgesteuerte Prozessketten kennt. Es gibt ein

grafisches Element, das Tätigkeiten erfasst, ein Rechteck mit abgerundeten Ecken.

Mit ihm wird erfasst, was in dem Geschäftsprozess konkret getan wird, genauer:

in welche einzelnen Aktivitäten der Geschäftsprozess zerlegt wurde. Dieses Ele-

ment wird hier auch Aktivität genannt.

Abbildung 2.1-1: Darstellung einer Aktivität (Prozess, Subprozess, Aufga-

be)

Es gibt auch eines, das den Kontrollfluss (hier sequence flow, übersetzt mit Se-

quenzfluss) ausdrückt, gerichtete Pfeile, die die einzelnen Aktivitäten verbinden

sowie Start- und Schlussereignisse (Kreis mit dünner bzw. dicker Linie) für den

Anfang und das Endes eines Geschäftsprozesses. Damit können wir bereits eine

erstes natürlich noch sehr schlichtes Prozessmodell erstellen: Eine Folge von Ak-

tivitäten, die – einmal initiiert – nacheinander abgewickelt werden.

Abbildung 2.1-2: Auftragsabwicklung – Variante 1

Natürlich ist das wirkliche „Prozessleben“ nicht so einfach und es fehlt hier auch

noch vieles, was man in der Prozessmodellierung erwartet, aber dies kommt noch.

Die einzelnen Tätigkeiten, in die man den Geschäftsprozess zerlegt hat, werden

von den BPMN-Autoren Aktivitäten (activities) genannt. Mehr dazu in Kapitel 4.

Am meisten vermisst man in obigem Beispiel sicherlich die Entscheidung, ob

der Auftrag überhaupt angenommen wird und das Auffächern der Tätigkeiten in

parallele Pfade, Auftragsabwicklung auf der einen und Zahlungsabwicklung auf

der anderen Seite. Dies ist aber möglich, die dafür nowendigen Operatoren liegen

in der Methode vor.

Was wird getan?

Wo geht’s lang?

Aktivitäten

2.1 Das erste Business Process Diagram 9


Betrachten wir dazu die folgende Abbildung. In ihr ist obiges BPD etwas aus-

gebaut. Sie ist außerdem mit Nummern in Kreisen versehen (so wie es die Rand-

spalte zeigt). Diese sind nicht Teil der Methode BPMN, sondern dienen nur der

Kennzeichnung für die folgenden Ausführungen.

Wie in der vorigen Abbildung liegt ein Startereignis vor (1), das die Aktivität

Auftragseingang (2) anstößt. Nach diesem folgt eine erste Verzweigung mit einem

Operator (4). Konkret bedeutet dies hier, dass aus einem Sequenzfluss mehrere

werden. Es geht entweder mit dem Sequenzflusszweig Auftrag abgelehnt (5) oder

mit dem Zweig Auftrag akzeptiert (6) weiter.

Diese Operatoren werden von den BPMN-Autoren Gateways genannt. Das

grafische Symbol ist ein auf die Spitze gestelltes Quadrat. Die unten folgende

Abbildung mit dem um die Gateways angereicherten Business Program Diagram

(BPD) enthält mehrere solche Operatoren. Der erste (mit der Nummer 4 in einem

Kreis gekennzeichnet) stellt einen Operator des Typs exklusives Oder dar

(XODER, vgl. [Staud 2006] für eine Beschreibung). Die BPMN-Autoren nennen

ihn exclusive decision. Kurz kann er so beschrieben werden:

Es gibt mehrere weiterführende Pfade nach dem Gateway, nur einer

davon kann aktiv werden.

Der Schrägstrich bei „Akzeptiert“ bedeutet in dieser Modellierungsmethode, dass

der durch ihn markierte Pfad die Voreinstellung ist, was hier nur bedeuten kann,

dass er meistens aktiv wird.

Der Pfad, der die Zurückweisung des Auftrags ausdrückt, führt direkt an das

Ende des Geschäftsprozesses, zu einem Gateway, das mehrere Zweige zusammen-

fasst. Dazu gleich unten mehr.

Im positiven Fall („Akzeptiert“) wird die Aktivität Auftrag ausführen angesto-

ßen. Ist sie ausgeführt, werden zwei Aktivitäten angestoßen, zum einen die Liefe-

rung, zum anderen das Versenden der Rechnung (Rechnung senden). Für eine

solche Situation (quasi paralleles Anstoßen zweier Aktivitäten) wird ein UND-

Gateway verwendet. Es gibt ihn in allen Methoden zur Prozessmodellierung, hier

wird er durch ein Pluszeichen dargestellt. Dieses UND-Gateway bei (7) ist ein

verzweigendes, weiter unten folgt noch ein verknüpfendes.

Oftmals wird in den Beispielen der BPMN-Autoren an einer solchen Stelle auf

ein Operatorsymbol verzichtet (so auch in [OMG 2009a, S. 104, Figure 10.12]).

Dies ist aber nicht sinnvoll. Nach den Erfahrungen des Verfassers führt eine Mo-

dellierung ohne Operatorsymbol zu Unübersichtlichkeit und sollte deshalb ver-

mieden werden. Allerdings war dies auch bei dem Modellelement Aktivitäten der

UML bereits vorgekommen (vgl. die Anmerkungen dazu in [Staud 2010]).

Die Parallelität durch das UND-Gateway bedeutet hier, dass beide weiterfüh-

renden Pfade angestoßen werden und dass die Aktivitäten der beiden Pfade durch-

laufen werden. Hier liegt ja in jedem Pfad jeweils nur eine einzelne Aktivität vor,

es können aber natürlich auch viel mehr sein. „Parallel“ bedeutet hier also nur

Gateways

(Operatoren):

Näher beschrieben in

Kapitel 8

Gabeln / forking

Parallel?



gleichzeitiges Anstoßen, nicht echte Parallelität der Abläufe. Die beiden Sequenz-

flüsse werden dann, da es in nur einem Sequenzfluss weitergeht, zusammenge-

fasst. Hierfür wird wieder das UND-Gateway genommen (8), da beide Sequenz-

flusszweige ja durch ein UND-Gateway entstanden sind. Dieses UND-Gateway ist

ein zusammenführendes, verknüpfendes.

Am Schluss des Geschäftsprozesses, am rechten Rand der Abbildung, folgt

dann die Zusammenführung der durch ein XODER-Gateway getrennten Flüsse.

Hierfür wird wiederum das XODER-Gateway genommen. Die BPMN-Autoren

nennen dieses Gateway exclusive merging. Dies ist hier im übrigen die Variante

„data based“, neben der es noch die Variante „event based“ gibt. Dazu mehr in

Kapitel 9.


Quelle: [OMG 2009a, S. 104, Figure 10.12], Übersetzung

durch den Verfasser

Soweit der erste „vorzeigbare“ Geschäftsprozess als BPD1. Es fehlen ihm aller-

dings noch einige wichtige Komponenten, z.B. die Informationsobjekte, mit denen

er umgeht.

2.2 Jetzt mit Daten

Informationsobjekte aller Art2 auf beliebigen Trägern (digital oder auch nicht)

sind natürlich von großer Bedeutung für jeden Geschäftsprozess, weshalb jede

1 Business Process Diagram 2 Dazu gehören u.a. alle Geschäftsobjekte wie Rechnungen, Lieferscheine, usw., jegliche Koordinie-

rungsinformation (Anfragen, Angebot, Liefermitteilungen) und natürlich die ganz normale Daten-

bank des Unternehmens mit all ihren Datenbeständen.

exclusive decision and

merging

Welche Informationen liegen vor?

2.3 Handelnde - Träger der Aktivitäten 11


Methode zur Modellierung von Geschäftsprozessen vorsehen muss, sie zu erfas-

sen.

In der BPMN können Informationsobjekte einer Aktivität oder einem Sequenz-

fluss zugeordnet werden. Außerdem können sie in einem eigenen Fluss neben dem

Sequenzfluss dargestellt werden.

In der folgenden Abbildung sind zwei Informationsobjekte eingebaut. Zuerst

der Auftrag, der ins Unternehmen kommt und damit den Geschäftsprozess ja erst

auslöst (1). Er wird ganz einfach der Aktivität Auftragseingang zugewiesen.

Durch die Pfeilspitze wird der Informationsfluss ausgedrückt. Das zweite Informa-

tionsobjekt in diesem Beispiel ist die Rechnung. Sie ist der Aktivität Rechnung

senden zugeordnet (2).


Quelle: [OMG 2009a, S. 86], Übersetzung durch den Ver-

fasser

Mehr zu Informationsobjekten in Kapitel 5.

2.3 Handelnde - Träger der Aktivitäten

Für eine Basisausstattung einer Methode zur Prozessmodellierung fehlen jetzt nur

noch die im Geschäftsprozess Handelnden. Diese werden zuerst einmal für die

einzelnen Aktivitäten bestimmt. Möglich sind hier Menschen oder auch Program-

me, mit oder ohne Maschinen3. Für die Zuordnung der Träger von Aktivitäten

haben die BPMN-Autoren die bekannte Schwimmbahnentechnik gewählt. Bei ihr

werden Becken (pools) und Bahnen (lanes) angelegt. Becken erfassen die überge-

ordneten Träger (z.B. ganze Unternehmen), Bahnen die untergeordenten (z.B.

Abteilungen oder Personen auf Stellen). Die folgende Abbildung zeigt das erwei-

terte einführende Beispiel.

Das obere Becken enthält alle Aktivitäten, die durch das hier betrachtete Unter-

nehmen realisiert werden. Es ist weiter unterteilt in zwei Bahnen, eine für die

Abteilung Auftragsbearbeitung, eine für die Abteilung Finanzwesen. Die Aktivitä-

ten sind in der Bahn der Abteilung, die sie realisiert. Der Sequenzfluss geht dann

entsprechend zwischen den Bahnen hin und her.

Der Kunde ist eine eigene handelnde Einheit und wird deshalb in der BPMN

durch ein eigenes Becken dargestellt. Zwischen verschiedenen „handelnden Ein-

heiten“4 gibt es – so der Vorschlag der BPMN-Autoren – keine Sequenzflüsse,

sondern nur Nachrichtenflüsse. Deshalb wurde hier das Verschicken der Rech-

3 Ein Beispiel für eine Aktivität, die evtl. durch ein Programm mit zugehörigen Maschinen erfolgt,

ist eine vollautomatische Lagerentnahme.

4 Das eigene Unternehmen und von diesem ausgehend die Kunden, die Lieferanten, Behörden, usw.

Alle, die mit dem Unternehmen im Rahmen von Geschäftsprozessen zusammenwirken.

Wer tut es?

Mehr zum Thema Nachrichtenflüsse

zwischen Becken findet

sich in Kapitel 4.



nung zum Kunden als Nachricht modelliert, ebenso die umgekehrte Information

(„Zahlungseingang“).


Quelle: Weiterentwickelt von [OMG 2009a, S. 104, Figu-

re 10.12]

Übersetzung durch den Verfasser

2.4 Ein öffentlicher Geschäftsprozess

Öffentliche Geschäftsprozess wurden oben schon kurz vorgestellt. Die BPMN-

Autoren verstehen darunter Geschäftsprozesse, bei denen es zu einer Interaktion

zwischen einem internen Geschäftsprozess und anderen Prozessen oder

Partizipanten kommt. Sie sind immer in einem Pool enthalten.

Erinnerung an die Begrifflichkeit der BPMN-Autoren: - Interne Geschäftsprozesse = private (internal) business processes

- Öffentliche Geschäftsprozesse = abstract (public) processes

2.5 Ein globaler Prozess 13


- Globale Geschäftsprozesse = collaboration (global) processes

Wie im vorigen Abschnitt schon ausgeführt, verläuft die Kommunikation mit

externen Partnern in der BPMN nicht als Kontrollfluss, sondern durch Austausch

von Nachrichten. So wie im folgenden Beispiel. Dort ist der Patient als Becken

ohne Aktivitäten dargestellt. Dies ist in der BPMN möglich. Die Nachrichtenflüs-

se zu einem solchen Teilnehmer am Geschäftsprozess enden und starten dann an

der Grenzlinie des Beckens. Ansonsten dürfte das folgende Beispiel selbsterklä-

rend sein.

Abbildung 2.4-1: Kontakt zwischen Arztpraxis und Patient - Version 1

Quelle: [OMG 2009a, S. 13, Figure 7.2]; Übersetzung

durch den Verfasser

2.5 Ein globaler Prozess

In der vorigen Abbildung wurde der öffentliche Prozess nur als Becken repräsen-

tiert. Es ist aber auch möglich, ihn durch Angabe seiner Aktivitäten und des Kont-

rollflusse zu spezifizieren. Dann kann auch das Zusammenwirken zwischen inter-

nem und öffentlichem Prozess durch Nachrichtenverkehr genauer angegeben

werden, als Nachrichtenfluss zwischen einer Aktivität des einen und einer des

anderen Prozesses.

Die folgende Abbildung zeigt, in Anlehnung an das Beispiel oben, diesen aus-

gestalteten Prozess beim Patienten und den Nachrichtenverkehr zwischen einzel-

nen Aktivitäten. zwei oder mehr öffentliche Prozesse, die miteinander kommuni-

zieren Wenn dann - wie hier - zwei oder mehr öffentliche Prozesse miteinander

kommunizieren, sprechen die BPMN-Autoren von einem globalen Prozess. Bei

diesem verlaufen die Nachrichtenflüsse zwischen je zwei Aktivitäten – eine vom

einen, eine vom anderen Prozess.



Abbildung 2.5-1: Kontakt zwischen Arztpraxis und Patient - Version 2

Quelle: [OMG 2009a, S. 14, Figure 7.3];


Soweit die Einführung anhand einiger Beispiele. In den folgenden Kapiteln wer-

den nun die Theorieelemente vertieft und in vollem Umfang vorgestellt.

3.1 Aktivitäten 15


3 Tätigkeiten

3.1 Aktivitäten

Wie zu Beginn von Kapitel 2 schon kurz ausgeführt, werden die einzelnen Tätig-

keiten, in die der Gesamtprozess im Rahmen einer Prozessmodellierung zerlegt

wird, in der BPMN mit Aktivität (activity) bezeichnet. Dies hat mit dem gleichna-

migen Begriff aus der UML direkt nichts zu tun. Er entspricht dem, was bei den

Ereignisgesteuerten Prozessketten Funktion genannt wird und bei den UML- Ak-

tivitätsdiagrammen Aktion. Wie auch schon oben angegeben, wird eine BPMN-

Aktivität in den Abbildungen durch ein Rechteck mit abgerundeten Ecken darge-

stellt.

Die BPMN-Autoren definieren wie folgt ([OMG 2009, S. 52], Übersetzung

durch den Verfasser):

Definition: Aktivität

Eine Aktivität ist eine Tätigkeit, die in einem Geschäftsprozess aus-

geführt wird.

Beschreibungsebenen, Aggregationsniveaus, Granularität

Die Unschärfe dieser Definition liegt am Gegenstand. Ein wenig Klärung erfolgt

durch die Festlegung, dass eine Aktivität elementar („atomic“) oder auch nicht

(„non-atomic“) sein kann und durch die Festlegungen der Ebenen, auf denen Ak-

tivitäten angesiedelt sein können. Dies sind drei:

Aufgaben (task)

Subprozesse

Prozesse

Aufgabe

Auf der untersten Ebene sind die Aufgaben angesiedelt, die als „atomar“ (atomic)

bezeichnet werden. Es sind also elementare Tätigkeiten, die im jeweiligen Kontext

nicht weiter unterteilt werden. Die Wortwahl macht die Subjektivität deutlich, die

natürlich erhalten bleibt. Hier die Definition ([OMG 2009, S. 21], Übersetzung

durch den Verfasser):

Definition: Aufgaben

Aufgaben sind elementare Tätigkeiten. Sie werden benutzt, wenn

die Prozesstätigkeiten nicht weiter zerlegt werden sollen.

BPML: Aktivität

EPK: Funktion

AD: Aktion

16 3 Tätigkeiten


Konkret bedeutet dies wohl keine tayloristische Ebene, aber doch eine, die an

elementaren Aufgaben orientiert ist. Eher also Kalkulation durchführen als Ange-

bot erstellen. Die Beliebigkeit einer solchen Festlegung (vgl. dazu auch [Staud

2010]) wird dadurch allerdings auch nicht überwunden.

Aufgaben werden, genauso wie Aktivitäten und die im nächsten Abschnitt vor-

zustellenden Subprozesse durch Rechtecke mit gerundeten Ecken dargestellt.

Abbildung 3.1-1: Darstellung von Aufgaben und Subprozessen

Kompensationsaktivitäten

Eine besondere Rolle nehmen Kompensationsaktivitäten ein. Sie werden einge-

setzt, wenn die eigentliche Aktivität scheitert und an ihrer Stelle eine andere aus-

geführt werden soll. Ein Beispiel: Eine Transaktion geht schief, als Kompensation

werden Aktivitäten ausgeführt, die den Zustand wieder zurücksetzen. In Abschnitt

6.4, wenn die Ereignisse besprochen sind, folgt dazu die Klärung der Syntax und

Beispiele.

3.2 Subprozesse

Ein Subprozess ist eine zusammengesetzte Tätigkeit, die in einem Prozess enthal-

ten ist. Selbst ist sie aber zerlegbar im jeweiligen Kontext. Hier ist die Definition

wie folgt ([OMG 2009, S. 56], Übersetzung durch den Verfasser):

Definition: Subprozess

Ein Subprozess ist eine zusammengesetzte, zerlegbare Tätigkeit, die

in einem Prozess enthalten ist.

Bei diesem Theorieelement sind von den BPMN-Autoren noch einige Varianten

vorgesehen, die im Folgenden betrachtet werden:

verborgene Subprozese (collapsed Sub-Processes)

entfaltete Subprozesse (expanded Sub-Processes)

eingebettete Subprozesse (embedded (or nested) Sub-Processes)

Verborgene Subprozesse

Bei diesem Element wird – sozusagen – der Subprozess versteckt. Es wird ein

grafisches Element (wie bei Aktivitäten) angegeben und angedeutet, dass in ihm

ein ganzer Subprozess enthalten ist, der aber an dieser Stelle nicht dargestellt wird.

Dies wird zum Beispiel dann benutzt, wenn die Darstellung des Prozessabschnitts

in der aktuellen Abbildung nicht nötig ist oder wenn wirklich hierarchische Pro-

zessstrukturen vorliegen (vgl. unten).

In der grafischen Darstellung wird bei einem solchen Theorieelement zusätzlich

ein Pluszeichen in einem Quadrat am inneren unteren Rand der Grafik eingefügt.

Subprozess-Varianten

3.2 Subprozesse 17


Abbildung 3.2-1: Darstellung eines verborgenen Subprozesses (collapsed

sub-process)

Entfalteter Subprozess

Bei einem entfalteten Subprozess dagegen wird im Gegensatz zu obigem Theorie-

element der Subprozess innerhalb des grafischen Symbols aufgezeigt. Dies ist

natürlich nur für kleine Subprozesse möglich.

Die BPMN-Autoren weisen an dieser Stelle darauf hin, dass die Elemente eines

solchen Prozess nicht mit Elementen außerhalb des Subprozesses verknüpft wer-

den können [OMG2009, S. 30].

Das hier angesprochene Problem ist ein vertrautes5. Oftmals möchte man in der

Prozessmodellierung, die ja meist zu grafisch umfangreichen Darstellungen führt,

einzelne Aspekte aus der Darstellung nehmen, um andere dafür deutlicher zu

machen. Dies ist mit diesem Element möglich. Die folgende Abbildung zeigt ein

Beispiel.

Abbildung 3.2-2: Abstrahierte Darstellung eines entfalteten Subprozesses

Die BPMN-Autoren sehen auch vor, dieses Theorieelement für die Darstellung

von Parallelverarbeitung zu benutzen, weil die Darstellung etwas kompakter ist als

mit Gateways (vgl. Kapitel 8). Die folgende Abbildung zeigt ein Beispiel.

5 In Ereignisgesteuerten Prozessketten wird dafür z.B. ein (eingebetteter) Prozesswegweiser ver-

wendet oder einfach in eine Funktionsbeschreibung der ganze Vorgang hineingelegt, z.B. Material

beschaffen, anstatt der dafür notwendigen einzelnen Schritte.

18 3 Tätigkeiten


Abbildung 3.2-3: Darstellung von Parallelverarbeitung mit Hilfe eines

entfalteten Subprozesses

Entfaltete Subprozesse sollen keine Start- und Schlussereignise enthalten.

Eingebettete Subprozesse

Ein eingebetteter Subprozess6 ist eine Aktivität, die andere Aktivitäten enthält.

Der Prozess im Prozess ist vom übergeordneten Prozess initiiert. Er kann auf die

globalen Daten der übergeordneten Ebene zugreifen. Für einen solchen Subpro-

zess stehen nicht alle Theorieelemente zur Verfügung. Er darf keine Becken und

Bahnen enthalten, sondern nur Flussobjekte, Verknüpfungselemente und Artifakte

[OMG 2009, S. 58].

3.3 Typen verborgener Subprozesse

In BPMN gibt es verschiedene Arten von verborgenen Subprozessen. Alle werden

durch ein Kennzeichen verdeutlicht.

Subprozesse mit Schleife

Subprozesse mit Parallelverarbeitung

Subprozesse für Ersatzaktivitäten (compensation)

Ad-Hoc – Subprozesse

Die grafische Darstellung der entsprechenden Kennzeichen ist wie folgt (siehe

auch die Abbildungen unten):

Schleife: eine unterbrochene schmale Linie in Kreisform mit Pfeilkopf.

Parallelverarbeitung: drei parallele senkrechte Linien

Ad Hoc: eine Tilde

Ersatzaktivität: zwei nach links zeigende Dreiecke.

Es kann vorkommen, dass ein Subprozess mehrere dieser Merkmale und damit

mehrere dieser Kennzeichen hat. In einem solchen Fall werden alle zu einem Sub-

6 Embedded (or nested) Sub-Process

Verschachtelung

3.3 Typen verborgener Subprozesse 19


prozess gehörigen Kennzeichen zusammengestellt und zentriert am inneren unte-

ren Rand des Subprozesssymbols angegeben. Welche Merkmale tatsächlich in

Kombination auftreten können, wird unten betrachtet.

Schleifen

Bei einem Subprozess mit Schleifenkennzeichnung deutet man an, dass die Tätig-

keiten im verborgenen Subprozess Schleifencharakter haben. Eine solche Situati-

on ergibt sich in der Prozessmodellierung tatsächlich sehr oft. Geeignet sind alle

repetitiven Tätigkeiten, bei denen man darauf verzichtet, die „innere Schleife“

ausdrücklich im Geschäftsprozess zu modellieren. Z.B. Befragung durchführen

oder E-Mail - Eingang bearbeiten.

Abbildung 3.3-1: Darstellung eines verborgenen Subprozesses mit Kenn-

zeichen Schleife

Dieser Schleifentyp darf nicht verwechselt werden mit einer Schleife im Ge-

schäftsprozess, die man in den Sequenzfluss einbaut („Rücksprung nach flussauf-

wärts“). In einem solchen Fall wird die Schleife explizit ausgewiesen. Der Wie-

dereinstieg in den Sequenzfluss erfolgt flussaufwärts vor der Stelle, ab der wie-

derholt werden soll. Vgl. hierzu Abschnitt 7.6.

Parallelverarbeitung

Bei einem verborgenen Subprozess mit dem Kennzeichen Parallelverarbeitung

wird deutlich gemacht, dass Aktivitäten parallel ablaufen. Die folgende Abbildung

zeigt ein Beispiel. Stellen wir uns vor, dass – ähnlich wie im Beispiel von Abbil-

dung 3.3-3 - ein Text für ein Fachbuch fertiggestellt ist. Dann folgen Arbeiten, die

quasi parallel erfolgen7, wie Kontrolle der (neuen) Rechtschreibung, prüfen und

ergänzen des Stichwortverzeichnisses, prüfen und ergänzen des Literaturverzeich-

nisses, usw.

Abbildung 3.3-2: Darstellung eines verborgenen Subprozesses mit Paral-

lelverarbeitung

7 In Wirklichkeit erfolgen solche Arbeiten nicht parallel, sondern nacheinander, wobei aber die

Reihenfolge ohne Bedeutung ist. Trotzdem kann es eine innere Struktur geben: Hat man z.B. bei

der Schlussredaktion eines Textes Änderungen, die die Seitennummerierung verändern, müssen

nach diesen auf jeden Fall die Verzeichnisse neu erstellt werden, usw.

20 3 Tätigkeiten


Subprozess für Ersatzaktivitäten

Nehmen wir folgende Situation an: Eine Aktivität soll im Rahmen des Geschäfts-

prozesses durchgeführt werden. Für den Fall, dass sie schief geht, ist ein Subpro-

zess vorgesehen, der die Dinge wieder in Ordnung bringt. Als Beispiel stellen wir

uns vor, dass eine Überweisung durchzuführen ist und dass im Falle eines Schei-

terns die Daten zurückgesetzt werden müssen.

Abbildung 3.3-3: Darstellung eines verborgenen Subprozesses mit Kenn-

zeichen Compensation

Ad-Hoc – Subprozesse

Für einen Ad-Hoc-Subprozess gilt, dass es zwar eine klar definierte Menge von

Aktivitäten gibt, für diese aber keinen Sequenzfluss. Sei es, dass dieser nicht be-

kannt ist, nicht erhoben werden kann oder soll. Wobei die BPMN-Autoren das

„nicht können“ betonen:

„… and cannot be defined beforehand.” [OMG 2009, S. 128].

In der konkreten Geschäftsprozessrealisierung werden die Aktivitäten dann spon-

tan (in einer spontan realisierten Reihenfolge) abgearbeitet.

Aktivitäten in einem solchen Prozess sind voneinander getrennt. Während der

Prozessausführung können die Aktivitäten beliebig aktiv sein und in beinahe be-

liebiger Reihenfolge und Häufigkeit ausgeführt werden. Dann gilt, dass ein Attri-

but hinzugefügt wird (AdHocOrdering attribute), das angibt, ob die Aktivitäten

parallel oder sequentiell ausgeführt werden müssen. Die Voreinstellung ist paral-

lel. Außerdem gilt, dass dann ein weiteres Attribut angelegt werden muss, die

AdHocCompletionCondition. Dieses gibt an, unter welchen Bedingungen der

Prozess endet.

Die Kennzeichnung von Ad Hoc-Subprozessen erfolgt durch eine Tilde. Ein

Ad-Hoc - Subprozess kann gleichzeitig von jedem anderen Typ sein.

Abbildung 3.3-4: Darstellung eines verborgenen Ad-Hoc - Subprozesses

Die folgende Abbildung zeigt die Darstellung eines entfalteten Ad-Hoc – Subpro-

zesses.

Ersatzhandlung

Attribute

3.3 Typen verborgener Subprozesse 21


Abbildung 3.3-5: Darstellung eines entfalteten (expanded) Ad-Hoc - Sub-

prozesses

Quelle: [OMG 2009, Seite 129, Figure 10.55], Überset-

zung durch den Verfasser.

Als Beispiel für Ad-hoc-Prozesse nennen die BPMN-Autoren neben dem Schrei-

ben eines Buchkapitals die Programmentwicklung (auf einer niedrigeren Ebene)

und Verkaufsunterstützung.

Die BPM-Autoren führen aus, dass es für eine “BPM engine” eine Herausfor-

derung darstellt, den Status von Ad-Hoc-Prozessen zu beobachten. Diese Art von

Prozessen wird üblicherweise durch Groupware (groupware applications) unter-

stützt (die UML-Autoren erwähnen E-Mail(!)), was die Situation erschwert. Aber

– so die Autoren – BPMN erlaubt auch das Modellieren von Prozessen, die nicht

unbedingt ausführbar sind und sollte die Mechanismen für die „BPM engines“

liefern, die einem Ad-Hoc-Prozess folgen können. Irgendwann ist dann der Pro-

zess abgeschlossen. Dies wird durch die Prüfung einer Schlussbedingung festge-

stellt, die Prozessattribute abfragt, die durch eine Aktivität des Prozesses aktuali-

siert wurden.

Ein versteckter Subprozess kann neben seiner Kennzeichnung als „versteckt“

nicht nur eine, sondern bis zu drei weitere Kennzeichnungen haben. Dabei sind

alle Kombinationen möglich mit der Ausnahme, dass die gleichzeitige Kennzeich-

nung als Schleife und als parallelverarbeitender Subprozess (Multiple Instance)

nicht möglich ist.

Wiederverwendbarer Subprozess

Ein wiederverwendbarer Subprozess (reuseable sub-process) ist eine Aktivität in

einem Prozess, die einen anderen Prozess aufruft. Der aufgerufene Prozess ist

bezüglich der globalen Daten nicht abhängig vom übergeordneten Prozess des

wiederverwendbaren Subprozesses. Das Objekt mit dem wiederverwendbaren

Prozess kann mit dem aufgerufenen Prozess Daten austauschen. Ein Beispiel fin-

det sich in Figure 9.10 S. 59. Der aufgerufene Prozess existiert in einer eigenen

Abbildung, die mehrere Becken haben kann.

BPM engine

Mehrere

Kennzeichnungen

22 3 Tätigkeiten


Der aufgerufene Prozess muss durch ein Nicht Startereignis als Subprozess

instantiiert sein. In der nächsten Abbildung ist das die zu Beginn angeführte Kre-

ditanfrage. Um wiederverwendbar zu sein, könnte der Prozess auch als ein Sub-

prozess durch andere unabhängige Subprozesselemente (im selben Diagramm

oder in anderen) instantiiert werden. Zusätzlich kann er durch ein eigenes Starter-

eignis, das einen Auslöser hat, als Top-level – Prozess instantiiert werden. Dies ist

in der nächsten Abbildung durch das Startereignis ausgedrückt.

Abbildung 3.3-6: Ein Prozess, der als Subprozess oder als Top-Level –

Prozess genutzt wird

Quelle: [OMG 2009, S. 61, Figure 9.12], Übersetzung durch

den Verfasser

Referenzierter Subprozess

Es ist möglich, bei der Anlage eines Subprozesses, die Spezifikation eines ande-

ren schon definierten Subprozesses zu nutzen. Dann müssen die Attribute, die das

Verhalten festlegen, nur einmal erzeugt werden und nur an einem Ort gepflegt

werden. Voraussetzung ist aber, dass die zwei Subprozesse genau dasselbe Ver-

halten und dieselben Eigenschaften haben.

3.4 Subprozess als Transaktion

Ein entfalteter oder eingebetteter Subprozess kann als Transaktion gesehen wer-

den, die ein spezielles Verhalten hat, das durch ein Transaktionsprotokoll kontrol-

liert wird. Die Grenzlinie eines solchen Aktivitätssymbols hat eine Doppellinie,

um anzudeuten, dass es sich um eine Transaktion handelt. Die folgende Abbildung

zeigt ein Beispiel.

Aufruf als Subprozess

oder als eigenständiger Prozess

3.4 Subprozess als Transaktion 23


Abbildung 3.4-1: Subprozess mit Transaktion

Quelle: Figure 10.33, S. 179

Eine Transaktion wird typischerweise auf drei Arten beendet:

Durch erfolgreichen Abschluss.

Durch einen Fehlschlag.

Durch zufällige die Transaktion beeinträchtigende Ereignisse, die mit Begrif-

fen wie „Zufall / Gefahr / Wagnis / Risiko“ assoziiert werden können.

Der erfolgreiche Abschluss der Transaktion wird als Sequenzfluss angezeigt, der

vom Rand des Transaktionssymbols wegführt. In der Abbildung oben auf der

rechten Seite hin zur Aktivität Käufer belasten. Im obigen Beispiel kommt es zum

erfolgreichen Abschluss, wenn beide Aktivitäten erfolgreich realisiert wurden und

der Sequenzfluss des eingebetteten Prozesse zum Schlussereignis kam.

Wenn eine Transaktion abgebrochen wird, dann muss auf die eine oder andere

Weise der eingebettete Prozess gescheitert sein, d.h. es wurde ein entsprechendes

Zwischenereigniss der Transaktion (im obigen Beispiel ein Fehler-

Zwischenereignis oder ein Abbruch-Zwischenereignis, vgl. den unteren Rand)

angesprochen. Im obigen Beispiel bedeutet dies konkret, dass dann, wenn eines

der Kompensations-Zwischenereignisse eintritt (bei Flug buchen oder bei Hotel

buchen) das Abbruch-Zwischenereignis der Transaktion angesprochen wird. Die-

ses Cancel Intermediate Event, angelegt an der Grenzlinie der Aktivität, steuert

den Fluss, wenn die Transaktion rückabgewickelt wurde und alle Kompensationen

getätigt wurden. Das Abbruch-Zwischenereignis kann nur an der Grenzlinie einer

Beendigung durch erfolgreichen Abschluss

Beendigung durch

Fehlschlag

24 3 Tätigkeiten


Transaktionsaktivität genutzt werden, nicht im normalen Fluss und nicht bei einer

Aktivität, die nicht Transaktion ist.

Das Fehler-Zwischenereignis der Transaktion, das die Bearbeitung durch den

Kundendienst aktiviert, soll wohl weitere „von außen“ kommende Ereignisse

ansprechen, wie z.B. einen Stromausfall, einen Zusammenbruch der Datenleitung,

usw.

Hier wird eines der Grundkonzepte der BPMN-Autoren deutlich. Die Beein-

flussung von Aktivitäten in einem Prozess wird auch über Ereignisse realisiert, es

gibt einen Ereignisraum des Prozesses, in dem Ereignisse eintreten, die bestimmte

Aktivitäten auslösen, stoppen, usw. Ein ähnliches Konzept liegt, wenn auch weni-

ger deutlich artikuliert, bei Ereignisgesteuerten Prozessketten vor.

Kommt es dann zum Abbruch, werden die Aktivitäten von innerhalb der Trans-

aktion den Abbruchaktionen unterworfen, die eine Rückabwicklung des Prozesses

und einen Ersatz (compensation) für bestimmte Aktivitäten enthalten können.

Grundsätzlich gibt es zwei Mechanismen, die den Abbruch einer Transaktion

signalisieren:

Ein Abbruch-Schlussereignis wird im Transaktions-Subprozess erreicht. Ein

Abbruch-Schlussereignis kann nur in einem Subprozess genutzt werden, der

eine Transaktion ist.

Eine Abbruchnachricht kann über das Transaktionsprotokoll erhalten werden,

das die Ausführung des Subprozesses unterstützt.

Das Verhalten am Ende eines erfolgreichen Transaktions-Subprozesses ist etwas

anders als das eines normalen Subprozesses. Wenn jeder Pfad eines Transaktions-

Subprozesses ein Endereignis erreicht, das keinen Abbruch darstellt, geht der

Fluss nicht sofort zum übergeordneten Elternprozess zurück, wie das ein normaler

Subprozess tut. Zuerst muss das Transaktionsprotokoll sicherstellen, dass alle

Teilnehmer erfolgreich ihr Ende der Transaktion erreicht haben. Meistens wird

dies wahr sein und der Fluss wird dann „nach oben“ gehen zum übergeordneten

Prozess. Aber es kann sein, dass einer der Partizipanten mit einem Problem endet,

das einen Abbruch oder ein Risiko mit sich bringt. In diesem Fall geht der Fluss

zum entsprechenden Zwischenereignis, selbst wenn er offensichtlich erfolgreich

beendet wurde.

Grundkonzept

Ereignisraum

Wirkung eines

Abbruchs

Wirkung der erfolgreichen

Beendigung

3.5 Sequenzfluss zu und von Subprozessen 25


Abbildung 3.4-2: Subprozess mit Transaktion – „Collapsed“ (verborgen)

Quelle: Figure 10.34, S. 179


3.5 Sequenzfluss zu und von Subprozessen

Zu einem Subprozess kann Sequenzfluss hinführen. Ein Sequenzflusszweig oder

mehrere, alternativ oder parallel. Dann gibt es im übergeordneten Prozess ein

Element, das auf den Subprozess verweist. Im Subprozess gibt es ein Startereignis.

Falls es mehrere Aufrufe gibt, wird die Beziehung durch ein Attribut (TargetRef)

hergestellt.

Falls ein Subprozess mehrere ankommende Sequenzflüsse hat liegt die Situati-

on vor, die die BPMN-Autoren als unkontrollierten Fluss bezeichnen. Dies

bedeutet: Kommt ein Token auf einer der Kanten an, wird der Subprozess

instantiiert. Es wird nicht auf eventuelle Token der anderen Kanten gewartet.

Kommt dann ein weiterer Token an, auf derselben Kante oder einer anderen, wird

der Subprozess erneut instantiiert.

Muss der Fluss kontrolliert werden, dann sollten die einzelnen Flüsse zu einem

Gateway (Operatoren, vgl. Kapitel 9) zusammengeführt werden, das vor dem

Subprozess angesiedelt ist. Hat ein Subprozess keinen ankommenden Sequenz-

fluss und auch kein Startereignis, dann muss der Subprozess instantiiert werden,

wenn der Prozess instantiiert wird.

Ausnahmen hierzu sind Subprozesse, die als Kompensationsaktivitäten

(compensation activities) deklariert sind, die also einen CompensationMarker

haben. Kompensationssubprozesse sind nicht Teil des normalen Flusses und wer-

den nicht instantiiert, wenn der Prozess instantiiert wird.

Unkontrollierter Fluss

Subprozess als Quelle

26 3 Tätigkeiten


Von einem Subprozess können Sequenzflüsse weggehen. Für jeden erzeugt der

Subprozess einen Token. Die TokenId wird so angelegt, dass deutlich wird, dass

alle diese Token von derselben parallelen Gabelung stammen und auch so, dass

die Anzahl der parallel existierenden Token deutlich wird.

Hat der Subprozess keinen abgehenden Sequenzfluss und gibt es kein Schluss-

ereignis, dann stellt der Subprozess das Ende eines Pfades oder mehrerer im Pro-

zess dar. Endet der Subprozess, ohne dass andere parallele Pfade aktiv sind, dann

muss der Prozess abgeschlossen (completed) werden. Ausnahmen hiervon sind

wiederum Subprozesse, die als Kompensationsaktivitäten festgelegt sind.

3.6 Nachrichtenflüsse mit Subprozessen

Nur zwischen Becken

Es wird noch mehrfach angesprochen werden, insbesondere in Kapitel 4, die

BPMN-Autoren sehen Nachrichtenflüsse zwischen handelnden Einheiten des

Geschäftsprozesses vor. Allerdings nur zwischen verschiedenen Becken und dort

ersetzen sie die ansonsten üblichen Sequenzflüsse. Die Nachrichtenflüsse können

zu den Grenzen der Becken führen oder zu Flussobjekten innerhalb der Becken-

grenzen. Sie können nicht zwei Elemente im selben Becken verbinden. Diese

Festlegung hilft bei der Klärung der Frage, was die BPMN-Autoren unter Nach-

richten verstehen.

Ein Subprozess kann Ziel eines Nachrichtenflusses sein; er kann keinen, einen

oder mehrere ankommende Nachrichtenflüsse haben. Ein Subprozess kann auch

Quelle eines Nachrichtenflusses sein. Er kann keinen, einen oder mehrere abge-

hende Nachrichtenflüsse haben.

4.1 Becken und Bahnen 27


4 Akteure und Nachrichten

Wer tut es?

In jeder Methode zur Prozessmodellierung ist vorgesehen, in den grafischen Dar-

stellungen der Geschäftsprozesse die Träger der einzelnen Tätigkeiten anzugeben,

diejenigen die die Aktivitäten ausführen. Sie sollen hier Akteure genannt werden.

Dies sind, je nach Modellierungsebene, Abteilungen, Stellen oder auch ganze

Unternehmen. In der BPMN wird dafür die im einführenden Beispiel schon kurz

vorgestellte Schwimmbahnentechnik genutzt. Dabei werden alle Aktivitäten eines

Akteurs entlang des Geschäftsprozesses in ein Rechteck gepackt. Dies geschieht

für jeden, so dass typischerweise mehrere langgezogene nebeneinanderliegende

Rechtecke entstehen, die wiederum an Schwimmbahnen in einem Becken erin-

nern. Entsprechend werden in der BPMN die Rechtecke als Becken (pools) be-

zeichnet, die noch in Bahnen (lanes) unterteilt werden können.

4.1 Becken und Bahnen

Becken

Hier nun die Festlegungen der BPMN-Autoren für ihre Schwimmbahnentechnik:

Jedes Becken (pool) repräsentiert einen Teilnehmer am Prozess (so die

Sichtweise), bzw. jeder Teilnehmer am Geschäftsprozess bekommt in der gra-

fischen Darstellung ein Becken.

Ein Becken geht über die gesamte Länge des Geschäftsprozesses.

Ein Becken unterteilt sich in Bahnen (lanes).

Die graphische Darstellung erfolgt als Rechteck, mit abgetrennter Kennzeichnung

an der linken Seite. Vgl. die Abbildung unten sowie die Beispiele im einführenden

Kapitel. Die grafischen Darstellungen der Geschäftsprozesse werden von den

BPMN-Autoren immer waagrecht angeordnet, so dass diese Becken in den meis-

ten Abbildungen auch waagrecht anzufinden sind.

Abbildung 4.1-1: Grafische Darstellung eines Beckens

Abteilungen

Stellen Unternehmen

pool,

lane

28 4 Akteure und Nachrichten


Die Schwimmbahnentechnik geht immer (allerdings meist unausgesprochen)

davon aus, dass es wenige Träger von Tätigkeiten gibt und dass diese nicht ständig

wechseln. Denn nur dann sind Schwimmbahnen sinnvoll einsetzbar. Die Vorstel-

lung, dass u.U. viele verschiedene Träger der einzelnen Aktivitäten vorliegen oder

dass sich diese im Prozessablauf grundlegend ändern, scheint den BPMN-Autoren

fremd zu sein. Dies ist auch den Formulierungen anzumerken, obwohl einige

Beispiele anderes andeuten, z.B. Figure 9.11 [OMG 2009, S. 60].

Bahnen

Falls bei einem Akteur eine für den Geschäftsprozess wichtige Untergliederung

vorliegt (z.B. in Abteilungen) kann ein Becken noch weiter unterteilt werden in

Bahnen (lanes). Solche Bahnen gehen über die gesamte Länge des Beckens.

Damit kann die organisatorische Zuständigkeit genauer festgelegt werden. Die

Abbildung unten zeigt zwei Becken (Kreditinstitut und Lieferant), wobei Lieferant

noch unterteilt ist in die zwei Bahnen Verkauf und Vertrieb.

Im Zusammenhang mit Bahnen ist folgende Festlegung bzgl. des Sequenzflus-

ses in Business Program Diagrams wichtig:

Der Sequenzfluss kann die Grenze von Bahnen überwinden, niemals aber die von Becken. Hat man also ein Zusammenspiel mehrerer Partizipanten aus verschiedenen Becken (z.B. das eigene Unternehmen einerseits und „den Kunden“ andererseits) muss dieses durch Nachrichtenverkehr gelöst werden.

Damit hat der Nachrichtenfluss hier, in der Methode BPMN, eine größere Bedeu-

tung als in anderen Methoden zur Prozessmodellierung.

4.2 Nachrichtenverkehr

Nachrichtenverkehr ist also nötig für das Zusammenspiel von Akteuren aus ver-

schiedenen Becken. Darüberhinaus legen die BPMN-Autoren fest, dass innerhalb

eines Beckens kein Nachrichtenverkehr erlaubt ist. Da liegt das Konstrukt Se-

quenzfluss vor, um das Zusammenwirken zu beschreiben. Die grafische Darstel-

lung einer Nachricht erfolgt durch einen speziell gestalteten Pfeil:

Die folgende Abbildung zeigt ein Beispiel für Nachrichtenverkehr. Der Lieferant

sendet im Rahmen einer Bonitätsprüfung eine Nachricht an ein Kreditinstitut zum

Zwecke der Karten- und Kontenprüfung. Er erhält dann, ebenfalls durch eine

Nachricht, die gewünschte Auskunft. Eine evtl. negative Auskunft und ihre Kon-

sequenzen haben die BPMN-Autoren hier nicht miteingebaut.

Vgl. zur Darstellung

von Bahnen die

Beispiele unten.

Keine Nachrichten

innerhalb eines Beckens

4.2 Nachrichtenverkehr 29


Abbildung 4.2-1: Nachrichtenverkehr zwischen Aktivitäten verschiedener

Becken

Quelle: [OMG 2009, S. 113, Figure 9.4], Übersetzung

durch den Verfasser

Die Abbildung enthält u.a. folgende Komponenten: Becken, Bahnen, Aktivitäten mit verborgenen

Subprozessen, Nachrichtenverkehr von Aktivität zu Aktivität, ein Start- und ein Schlussereignis.

Es ist in der BPMN aber auch möglich, den Nachrichtenfluss nur an den Rand des

„empfangenden“ Beckens zu führen. Bei einem solchen Vorgehen modelliert man

bewusst unscharf, man drückt lediglich aus, dass eine Nachricht an den anderen

Akteur geht und präzisiert nicht die konkrete Aktivität zu der die Nachricht gehen

soll. Im Beispiel unten ist dies dargestellt, auch die antwortende Nachricht ist nur

an den Beckenrand geführt.

Nur zum Beckenrand

30 4 Akteure und Nachrichten


Abbildung 4.2-2: Nachrichtenverkehr vom und zum Beckenrand


durch den Verfasser

Die Abbildung enthält im wesentlichen einen Nachrichtenverkehr vom und zum Beckenrand.

4.3 Becken, Bahnen und Akteure

Jede einzelne Aktivität benötigt also einen Akteur (Träger der Aktivität), der sie

durchführt. In den Textabschnitten von [OMG 2009] zu Becken (pools) und Bah-

nen (lanes) kann genauer geklärt werden, was die BPMN-Autoren als Akteure (sie

sprechen von Teilnehmern am Geschäftsprozess) ansehen. Zum einen können dies

bestimmte Unternehmenseinheiten (Abteilung, Hauptabteilung, Stelle) wie Fi-

nanzwesen, Beschaffung, Vertrieb, usw. sein, zum anderen abstrakte Rollen wie

Käufer, Verkäufer, Hersteller. Bei der Lektüre des Originaltextes gewinnt man

darüberhinaus den Eindruck, dass die Erfassung der Träger von Aktivitäten auf

Abteilungs- bzw. Partnerebene, nicht auf Stellenebene stattfinden soll.

Bei der Erläuterung von Bahnen zielen die BPMN-Autoren dagegen auf kleine-

re Einheiten. Hier, so führen sie aus, spielen „internal roles“ (Manager,

Associate), Systeme (z.B. Anwendungsprogramme) und auch interne Abteilungen

(z.B. Vertrieb, Finanzwesen, usw.) eine Rolle.

Akteure und damit auch Bahnen können verschachtelt sein. Zum Beispiel kön-

nen übergeordnete Bahnen für die Abteilungen eingerichtet werden und innere

Bahnen für die Rollen (Stellen) in jeder Abteilung. Oben (auch im einführenden

Beispiel) war solch eine Struktur bereits vorhanden. Außerdem können Bahnen

auch in Matrizen definiert werden.

Die folgende Abbildung zeigt ein Beispiel für die Verschachtelung von Akteu-

ren. Es geht um Produktentwicklung, Verkäufe an Kunden, evtl. Fehlermeldung

von Kunden und die Reaktionen darauf, alles sehr abstrakt. Der Geschäftsprozess

ist nicht ausgestaltet, er stellt eher eine Sammlung von Methodenkonstrukten dar,

wohl um den deren Einsatz zu demonstrieren.

Becken eher für größere

Einheiten

Bahnen eher für kleinere

Einheiten

Verschachtelung von Akteuren

4.3 Becken, Bahnen und Akteure 31


Der Kunde ist als eigenes Becken angelegt, ohne Ausdifferenzierung seiner Ge-

schäftsprozesse. Der Lieferant ist durch ein Becken repräsentiert, das auf der ers-

ten Ebene in die Bahnen Entwicklung, Kundendienst, Marketing und Verkauf

unterteilt ist. Alles Abteilungen also. Die Abteilung Marketing ist dann noch un-

terteilt in Nach Verkauf und Vor Verkauf, was wiederum durch Bahnen ausge-

drückt wird.

Entsprechend den obigen Ausführungen haben die BPMN-Autoren die Kontak-

te zwischen Lieferant und Kunde (zwischen zwei verschiedenen Becken also) als

Nachrichtenfluss dargestellt. Betrachten wir die einzelnen Nachrichtenflüsse ge-

nauer:

Ganz links wird durch eine Nachricht von der Aktivität Verkauf an Kunden

zum Becken des Kunden der Verkauf (z.B. der Software) erfasst.

Der nächste Nachrichtenfluss kommt vom Kunden und landet bei einem sog.

Zwischenereignis und enthält wohl eine Fehlerliste.

Abbildung 4.3-1: Verschachtelte Bahnen


durch den Verfasser

32 5 Informationen und ihre Verarbeitung


5 Informationen und ihre Verarbeitung

In BPMN werden Daten (data objects) zusammen mit den Konstrukten Group und

Annotation unter dem Stichwort Artifakte zusammengefasst.

5.1 Einführung

Die BPMN-Autoren bezeichnen die im Geschäftsprozess eine Rolle spielenden

Informationen als Datenobjekte. Sie sehen sie wie folgt [OMG 2009, S. 19]:

Datenobjekte liefern Informationen darüber, was der Prozess leistet, wie Do-

kumente, Daten und andere Objekte im Prozess genutzt und aktualisiert wer-

den.

Sie liefern Informationen darüber, was Aktivitäten für ihre Umsetzung benö-

tigen und/oder was sie erzeugen.

Sie haben keinen direkten Einfluss auf den Kontroll- oder Nachrichtenfluss

[OMG 2009, Seite 19].

In der BPMN sind Datenobjekte normalerweise mit Flussobjekten verknüpft (wie

alle Artifakte der BPMN). Die Verknüpfung erfolgt über eine Assoziation. Dies

nicht im Sinne des entsprechenden Begriffs der objektorientierten Theorie (z.B.

der UML), sondern im Sinne einer Verknüpfung von Flussobjekt und Information.

Definition: Assoziation

Eine Assoziation ist eine Verknüpfung zwischen einem Flussobjekt

und einem Datenobjekt.

Manchmal wird das Datenobjekt auch als Informationsfluss von einer Aktivität

zur nächsten an einem Sequenzfluss angegeben. Vgl. hierzu das einführende Bei-

spiel oben. Datenobjekte können auch mit einem Nachrichtenfluss verbunden

werden. Vorgesehen ist auch, dass ein Datenobjekt Input liefert für eine Aktivität

und per Output (nach Verarbeitung) als geändertes Datenobjekt wieder entsteht.

Grafische Darstellung

Ein Datenobjekt wird wie ein Blatt Papier dargestellt, bei dem das in der Drauf-

sicht rechte obere Eck nach vorn gefaltet ist. Es muss mit einer durchgezogenen

schwarzen Linie gezeichnet werden. Vgl. die folgende Abbildung.

data objects = Daten

5.2 Assoziationen 33


Abbildung 5.1-1: Darstellung eines Datenobjekts

5.2 Assoziationen

Ganz allgemein wird die Verknüpfung von Text und Nicht-Fluss-Elementen mit

Flussobjekten Assoziation genannt. Dies gilt dann auch für die Verknüpfung von

Datenobjekten mit Flussobjekten. Assoziationen werden als gepunktete Linie

dargestellt, mit oder ohne offener Pfeilspitze. Die folgende Abbildung zeigt ein

Beispiel einer ungerichteten Assoziation, die ein Datenobjekt mit einer Sequenz-

flusskante verbindet.

Abbildung 5.2-1: Assoziation von Datenobjekt mit Sequenzflusskante

Quelle: [OMG 2003a, S. 93], Übersetzung durch den Ver-

fasser

Vgl. die Pfeillinie zum Datenobjekt Rechnung

im einführenden

Beispiel.

34 6 Ereignisse


6 Ereignisse

6.1 Ereigniskonzept

Auch wenn Ereignisse in den BPDs nicht so deutlich in Erscheinung treten wie in

anderen Methoden zur Prozessmodellierung haben die BPMN-Autoren, wie die

anderen, die sich an einer Methode zur Prozessmodellierung versuchen, ein Ereig-

niskonzept. Sie definieren wie folgt:

Definition: Ereignis

Ein Ereignis ist etwas, was während des Ablaufs eines Geschäfts-

prozesses geschieht. Ein Ereignis betrifft den Sequenzfluss. Ereig-

nisse zeigen Verzweigungen an. Normalerweise haben Ereignisse

einen Auslöser und eine Wirkung ([OMG 2009, S. 35], Übersetzung

durch den Verfasser).

Die Einschränkung auf Ereignisse, die den Prozessfluss betreffen, ist sinnvoll.

Folgende abstrakten Beispiele für Ereignisse führen sie an (S. 35):

Start einer Aktivität

Ende einer Aktivität

Veränderung eines Dokuments

Nachricht, die eintrifft

Obiges entspricht dem Standard bei der Definition von Ereignissen. Weiter geht

dagegen die folgende Unterscheidung dreier Ereignistypen, die danach erfolgt,

wann die Ereignisse den Fluss beeinflussen:

Startereignisse (start events)

Zwischenereignisse (intermediate events)

Schlussereignisse (end events)

Start- und Zwischenereignisse haben Auslöser (trigger). Schlussereignisse können

Ergebnisse haben, die sich aus dem Geschäftsprozess ergeben.

Grafische Darstellung

Die grundsätzliche grafische Darstellung ist die eines leeren Kreises, in den man

Kennzeichnungen (marker) des konkreten Ereignisses platzieren kann. Dazu

gleich unten mehr.

6.2 Ausdifferenzierung 35


Abbildung 6.1-1: Darstellung eines Ereignisses – allgemeine Form

6.2 Ausdifferenzierung

Die Ereignisse werden von den BPMN-Autoren auf vielfältige Weise unterschie-

den und alle diese Unterscheidungen werden auch in der grafischen Darstellung

ausgedrückt.

Der Ausgangspunkt der Differenzierung ist die oben schon eingeführte Unter-

scheidung von Start-, Zwischen- und Schlussereignissen. Ihre grafische Gestaltung

erfolgt mit schwarzen Linien und ist ansonsten wie folgt:

Startereignisse werden mit einer einzelnen dünnen Linie gezeichnet

Zwischenereignisse erhalten zwei dünne Linien

Schlussereignisse werden mit einer dicken Linie gezeichnet

Dazu folgen unten gleich Beispiele. Dann wird danach unterschieden, ob der Aus-

löser des Ereignisses empfangend oder abgebend ist. Zusammen mit der Festle-

gung, dass Startereignisse nur empfangende Auslöser, Schlussereignisse nur abge-

bende Auslöser und Zwischenereignisse beide haben, ergibt sich die Kopfzeile der

folgenden Abbildung.

Die dritte Ausdifferenzierung erfolgt nach den Auslösern der Ereignisse. Hier

gibt es neben der Situation Kein Auslöser („kein bestimmter Auslöser“) noch

folgende weitere:

Nachricht (message). Dies bedeutet, dass von einem Teilnehmer am Prozess

eine Nachricht erwartet oder versendet wird.

Zeitgeber (timer). Mit diesem Kennzeichen kann zum Ausdruck gebracht

werden, dass das Ereignis Zeitaspekte erfasst.

Fehler (error). Dieses Symbol gibt an, dass eine benannte Fehlermeldung

erzeugt wird.

Abbruch (cancel). Durch diese Kennzeichnung entsteht ein Ereignistyp, der

den Geschäftsprozess bzw. den jeweiligen Fluss abbricht.

Kompensation (compensation). Erhält ein Ereignis das Kennzeichen Kompen-

sation (compensation) und wird dieses Ereignis an die Grenzlinie einer Akti-

vität angefügt, muss es auch einen Sequenzflusspfeil zu einer anderen Aktivi-

tät geben. Diese andere Aktivität ist dann im Krisenfall Ersatz für die Aus-

gangsaktivität (die mit dem Kompensationsereignis).

Bedingung (conditional). Für Ereignisse, die durch Bedingungen beschrieben

werden können, z.B. „Lagerbestand ist unter die Nachbestellmarke gefallen“.

Verknüpfung (link). Ein Ereignis mit dem Kennzeichen Verknüpfung (link)

zeigt an, dass zwei Abschnitte eines Prozesses verknüpft werden.

Signal. Gibt an, dass Signale gesendet oder empfangen werden.

Beenden (terminate). Ein Ereignis mit diesem Kennzeichen beendet den Pro-

zess.

Kriterium 1:

Start- / Zwischen- /

Schlussereignis

Kriterium 2: Empfangend oder

Abgebend

Kriterium 3:

Auslöser

36 6 Ereignisse


Mehrfach (multiple) Das Kennzeichen Mehrfach (multiple) bedeutet, dass

dem Ereignis mehrere Auslöser zugewiesen sind.

Eine ausführliche Beschreibung der Auslöser, auch in Zusammenhang mit den Ereignistypen und der Art des Auslösers, folgt in Kapitel 7.

Für jeden Auslöser außer der Fehlanzeige („Keiner“) gibt es in der grafischen

Darstellung ein Kennzeichen (marker). Für diese gilt: Bei Ereignissen, die emp-

fangen, sind die Kennzeichen nicht gefüllt. Bei Ereignissen, die abgeben, sind sie

gefüllt. In der folgenden Abbildung sind alle Ereignistypen mit ihren grafischen

Darstellungen zusammengestellt.

6.2 Ausdifferenzierung 37


38 6 Ereignisse


Abbildung 6.2-1: Alle Ereignistypen mit ihren Kennzeichen

In der Abbildung ist auch zu erkennen, dass nicht alle Marker in allen Ereignisty-

pen vorkommen. Dazu unten mehr.

6.3 Startereignisse - allgemein

Startereignisse können die Kennzeichen Kein Auslöser, Nachricht, Zeitgeber,

Bedingung, Signal und Mehrfach besitzen. Ein Startereignis startet den Geschäfts-

prozess. Es kann auch mehrere geben, dazu unten mehr. Folgende Eigenschaften

und Regeln legen die BPMN-Autoren für Startereignisse fest:

Ein Startereignis hat keinen ankommenden Sequenzfluss, nur einen oder

mehrere abgehende.

Nicht auf jeder Modellierungsebene muss ein Startereignis vorhanden sein,

z.B. nicht bei einem „top-level Process“ und nicht bei einem entfalteten Sub-

prozess. Deshalb können die BPMN-Autoren schreiben, dass Startereignisse

optional sind.

Wenn das BPD mehrere Ebenen hat, sind die Startereignisse der Ebenen un-

abhängig voneinander.

Falls ein Prozess komplex ist oder falls die Startbedingungen nicht offensicht-

lich sind, wird empfohlen, ein Startereignis zu nutzen.

Falls ein Schlussereignis vorliegt, muss mindestens ein Startereignis vorlie-

gen.

Falls ein Startereignis genutzt wird, müssen alle anderen Flusselemente (min-

destens) einen ankommenden Sequenzfluss haben. Ausnahmen hierzu sind

die sog. Kompensationsaktivitäten (vgl. Abschnitt 8.5). Eine weitere Aus-

nahme sind Zwischenereignisse, die mit einer Aktivität verknüpft sind (vgl.

den nächsten Abschnitt). Sie haben keinen ankommenden Sequenzfluss.

Implizite Startereignisse

Falls kein Startereignis vorliegt werden beim Start des Prozesses alle Flussobjekte

ohne ankommenden Sequenzfluss gestartet. Dabei wird angenommen, dass es nur

ein implizites Startereignis gibt, was bedeutet, dass alle startenden Flussobjekte

zur selben Zeit starten. Eine Ausnahme sind wiederum die Kompensationsaktivitä-

ten. Sie werden natürlich nicht beim Start eines solchen Prozesses automatisch

auch gestartet. Außerdem gilt, dass das implizite Startereignis keinen Trigger

haben sollte und dass alle Flussobjekte, die keinen ankommenden Sequenzfluss

haben, Startpunkt für jeweils einen parallelen Pfad sind.

Token

Tritt ein Startereignis ein, wird ein neuer Prozess instanziiert und für jeden Se-

quenzfluss, der von diesem Startereignis herkommt, wird ein neuer Token erzeugt.

Mehrere Startereignisse

Die BPMN-Autoren sehen vor, dass ein Geschäftsprozess mehrere Startereignisse

haben kann. Dabei wird für jeden weiteren Fluss ein neuer paralleler Pfad geschaf-

fen. Zwei Fälle sind zu unterscheiden:

Vgl. zu den

Kennzeichen Kapitel 7

Start ohne Startereignis

6.4 Zwischenereignisse – allgemein 39


Falls mehrere Ereignisse eintreten müssen, bevor ein Prozess startet, dann

müssen diese Startereignisse zur selben Aktivität führen. Die Attribute der

Aktivität legen fest, wann die Aktivität starten kann. Die Startereignisse müs-

sen also sozusagen alle gemeinsam eintreten. Dem entspricht eine UND-

Verknüpfung zwischen den Startereignissen.

Die Startereignisse sind unabhängig voneinander. Dies tritt v.a. bei umfang-

reicheren Geschäftsprozessen auf.

Selbstverständlich können von einem Startereignis auch mehrere Flüsse abgehen.

Im Subprozess

Oben wurde ja schon angemerkt, dass ein Startereignis nicht Ziel des Sequenz-

flussablaufs sein darf. Eine Ausnahme ergibt sich, wenn das Startereignis in einem

entfalteten (expanded) Subprozess benutzt wird und mit der Grenze dieses Sub-

prozesses verbunden wird. In einem solchen Fall kann ein Sequenzfluss vom

übergeordneten Prozess mit diesem Startereignis verbunden sein, statt mit der

aktuellen grafischen Grenze des Subprozesses.

6.4 Zwischenereignisse – allgemein

Zwischenereignisse können alle Kennzeichen besitzen (vgl. die Liste oben und –

ausführlich – Kapitel 7). Sie treten im Sequenzfluss zwischen dem Start- und dem

Schlussereignis auf, geben also Ereignisse an, die zwischen dem Start- und

Schlussereignis eines Prozesses eintreten und prozessrelevant sind. Sie können …

… zeigen, wo in einem Prozess Nachrichten erwartet oder versandt werden

… zeigen, wo in einem Prozess Verzögerungen erwartet werden

… den normalen Fluss durch Ausnahmebehandlung (exception handling)

unterbrechen

… zeigen, wo Ersatzaktivitäten (Kompensationen) benötigt werden

Graphische Darstellung

Die Zwischenereignisse werden mit einer doppelten dünnen schwarzen Linie

gezeichnet. Dies soll ihrer unmittelbaren Erkennbarkeit dienen.

Einsatzgebiete

Wann kommen eigentlich Zwischenereignisse vor? Wird nicht, wie bei Ereignis-

gesteuerten Prozessketten, zwischen zwei Tätigkeiten (dort: Funktionen) jeweils

ein Ereignis gepackt (was die Erledigung der vorangehenden andeutet und den

Start der nächsten signalisiert), gibt es im Sequenzfluss nur folgenden Bedarf an

Ereignissen:

Bei Verzweigungen aller Art, um die verschiedenen weiteren Fortführungen

des Sequenzflusses zu beschreiben. Dies lösen die BPMN-Autoren allerdings

durch Kantenbeschriftungen.

Bei der Einarbeitung von zeitlichen Ereignissen, d.h., beim Einbau von Er-

eignissen, die zeitliche Aspekte ausdrücken.

40 6 Ereignisse


Beim Empfang und beim Senden von Nachrichten (nach dem Start und vor

dem Ende des Geschäftsprozesses).

Zu Letzterem gehört auch der Nachrichtenversand im Krisenfall (vgl. „Kompensa-

tionen“).

Wie sehen dies nun die BPMN-Autoren? Sie sehen ein Einsatzgebiet für Zwi-

schenereignisse darin, Ausnahmen und Kompensationen zu bewältigen. Dies

geschieht, indem das Zwischenereignis auf die Grenze der Aufgabe (Task) oder

des Subprozesses gesetzt wird. Die folgende Abbildung zeigt ein Beispiel. Hier

wird zum einen eine E-Mail-Diskussion moderiert. Zum anderen wird regelmäßig

eine Zusammenfassung der Diskussion erstellt. In der Abbildung wird dafür ein

Zwischenergebnis mit dem Kennzeichen Zeitgeber (vgl. unten) gesetzt. Dieses

gibt an, dass nach 7 Tagen (oder alle 7 Tage) ein Bericht über die Diskussion

erstellt wird.

Abbildung 6.4-1: Zwischenereignis mit Zeitgeber

Anknüpfen an die Grenzlinie von Aktivitäten

Zwischenereignisse können also an die Grenzlinie von Aktivitäten angefügt wer-

den. Dafür gelten folgende Regeln:

Es muss eines der Kennzeichen Nachricht, Zeitgeber, Fehler, Abbruch, Kom-

pensation, Bedingung, Signal oder Mehrfach vorliegen. Nicht vorliegen dür-

fen Kein Auslöser und Verknüpfung.

Das Kennzeichen Abbruch darf nur dann an die Grenze eines Subprozesses

gesetzt werden, falls der Subprozess eine Transaktion ist (vgl. unten), falls al-

so das IsATransaction-Attribut des Subprozesses auf TRUE gesetzt ist).

Das Zwischenereignis darf nicht Ziel eines Sequenzflusses sein.

Das Zwischenereignis muss Quelle genau eines Sequenzflusses sein.

Zum letztgenannten Punkt gibt es eine Ausnahme: Ein Zwischenereignis mit ei-

nem Kompensationsauslöser darf keinen wegführenden Sequenzfluss haben. Es

kann aber eine wegführende Assoziation haben.

Verknüpfung im Sequenzfluss

Zwischenereignisse können auch im normalen Fluss eingesetzt werden. Dabei

dürfen folgende Kennzeichen benutzt werden: Kein Auslöser, Nachricht, Zeitge-

Ausnahmen und

Kompensationen bewältigen

6.5 Schlussereignisse - allgemein 41


ber, Kompensation, Bedingung, Verknüpfung und Signal. Nicht benutzt werden

dürfen also Fehler, Abbruch und Mehrfach.

Folgende Regeln gelten hier:

Zwischenereignisse der Typen Kein Auslöser und Kompensation müssen das

Ziel eines Sequenzflusses sein. Sie müssen genau einen ankommenden Fluss

haben.

Zwischenereignisse der folgenden Typen dürfen Ziel eines Flusses sein:

Nachricht, Zeitgeber, Bedingung, Verknüpfung und Signal. Sie dürfen genau

einen ankommenden Fluss haben. Diese Zwischenereignistypen sind immer

bereit, die Ereignisauslöser zu akzeptieren (einmal), solange der Prozess, in

dem sie enthalten sind, aktiv ist. Sie sind nicht optional, sie sollten während

der Ausführung des Prozesses ausgelöst werden.

Ein Zwischenereignis muss Quelle eines Sequenzflusses sein; es muss einen

(und genau einen) abgehenden Sequenzfluss haben.

Ein Zwischenereignis mit dem Kennzeichen Nachricht kann das Ziel oder die

Quelle eines Nachrichtenflusses sein, allerdings nicht beides gleichzeitig.

Token bei Zwischenereignissen

Kommt ein Token bei einem Zwischenereignis an, das im normalen Fluss einge-

ordnet ist, geschieht folgendes: Wird das Ereignis genutzt, um den Ereignisauslö-

ser abzugeben, dann erfolgt die Auslösung unmittelbar (z.B. indem die Nachricht

verschickt wird) und der Token geht weiter im Fluss. Wird das Ereignis genutzt,

um den Ereignisauslöser zu empfangen, dann bleibt der Token bis der Auslöser

erscheint (z.B. die Nachricht angekommen ist). Danach bewegt sich der Token

weiter.

Damit stellt ein solches Zwischenereignis im “empfangenden Fall” eine Warte-

position dar. Der Geschäftsprozess steht solange, bis das Ereignis eintritt.

6.5 Schlussereignisse - allgemein

Schlussereignisse gibt es für die Kennzeichen Kein Auslöser, Nachricht, Fehler,

Abbruch, Kompensation, Signal, Beenden und Mehrfach. Sie haben nur ankom-

mende Sequenzflusskanten. Die graphische Darstellung erfolgt mit einer dicken

schwarzen Linie.

Folgende Regeln definieren die BPMN-Autoren für Schlussereignisse:

Ein Schlussereignis muss das Ziel eines Sequenzflusses sein.

Ein Schlussereignis kann mehrere ankommende Sequenzflüsse haben.

Die Flüsse können von alternativen oder parallelen Pfaden stammen.

Als Modellierungskonvention wird empfohlen, dass jeder Pfad zu einem

eigenen Schlussereignis führt.

Auf einer Prozessebene kann es mehrere Schlussereignisse eines Prozesses

geben.

Der Einsatz von Schlussereignissen ist optional. Eine bestimmte Prozessebene

– ein top-level Prozess oder ein entfalteter (expanded) Subprozess muss kei-

nes haben.

Regeln für

Schlussereignisse

42 6 Ereignisse


Falls keines genutzt wird, sollte das implizite Schlussereignis für den Prozess

kein Ergebnis haben.

Falls ein Schlussereignis genutzt wird, darf es keine anderen Flusselemente geben,

die keine abgehenden Flüsse haben, d.h., alle anderen Flussobjekte müssen Quelle

von mindestens einem Sequenzfluss sein. Ausnahmen stellen wieder die Kompen-

sationsaktivitäten dar. Diese dürfen keinen abgehenden Sequenzfluss haben.

Ein Schlussereignis darf nicht Ziel oder Quelle eines Nachrichtenflusses sein.

Eine Ausnahme ergibt sich, falls das Schlussereignis in einem entfalteten Subpro-

zess genutzt und an die Grenze dieses Subprozesses angefügt wird. In diesem Fall

kann der Sequenzfluss von diesem Schlussereignis zu einem Sequenzfluss des

übergeordneten Prozesses führen, anstatt dass dieser mit der aktuellen Grenze des

Subprozesses verbunden ist.

Falls in einem BPD kein Schlussereignis genutzt wird, dann markieren alle

Flussobjekte, die keinen abgehenden Sequenzfluss haben, das Ende eines Pfades

in dem Prozess. Jedoch darf der Prozess erst enden, wenn alle parallelen Pfade

vollständig realisiert wurden. Ausnahmen hierzu sind wie Kompensationsaktivitä-

ten.

Token

Token, die nach ihrer „Wanderung“ durch den Geschäftsprozess bei einem

Schlussereignis ankommen, gelten als verbraucht. Solange nicht alle im Prozess

erzeugten Token auf diese Weise verbraucht wurden, ist der Prozess noch aktiv.

Obiges gibt einen wichtigen Hinweis auf das Prozessverständnis der BPMN-

Autoren. Ein Geschäftsprozess hat u.U. mehrere aktive Bereiche, die eine gewisse

Unabhängigkeit voneinander haben. In einer Standardprozessmodellierung, bei

der typischerweise nicht an die Umsetzung in ein Programm oder System gedacht

wird, hat ein Geschäftsprozess einen (u.U. tief verzweigenden) Sequenzfluss, der

startet und irgendwann später endet.

Bei Prozessen ohne Schlussereignis wird ein Token, der ein Flussobjekt am

Ende eines Flusses erreicht, verbraucht, wenn der Pfad abgearbeitet ist. Falls die

ankommenden Flüsse parallel sind, werden sie verbraucht, wenn sie ankommen.

Falls der Prozess ein Subprozess ist, kann er auch durch ein „unterbrechendes“

(interrupting) Zwischenereigniss vor dem normalen Abschluss beendet werden. In

einem solchen Fall werden die Token durch das Zwischenereignis verbraucht.

Schlussereignisse und

Nachrichten

„Implizite“ Lösung

Prozessverständnis

7.1 Kein Auslöser 43


7 Ereignistypen

Ereignistyp: Ereignis + Kennzeichen

Oben wurden die Kennzeichen (marker) schon vorgestellt, hier nun eine Beschrei-

bung im Gesamtzusammenhang, also mit Berücksichtigung der drei möglichen

Positionen im Sequenzfluss (Start-, Zwischen-, Schlussereignis) und der Eigen-

schaft „empfangend / abgebend“. Durch die Zuweisung von Kennzeichen zu Er-

eignissen entstehen Ereignistypen, so die Wortwahl der BPMN-Autoren.

7.1 Kein Auslöser

Falls man kein Kennzeichen angibt, wählt man das Ereignissymbol ohne Inhalt.

Dies bedeutet, dass die nach dem Ereignis folgende Tätigkeit gestartet wird, ohne

dass ein spezifischer Grund angegeben wird. Ein solches Startereignis ohne Kenn-

zeichen wird auch für Subprozesse verwendet, die starten, wenn sie durch den

übergeordneten Prozess angestoßen werden.

Abbildung 7.1-1: Ereignisse ohne Kennzeichen

Diesen Ereignistyp gibt es in allen vier Varianten. Die Bedeutung ist wie folgt:

Bei Startereignissen: Start des Geschäftsprozesses ohne explizite Angabe des

Grundes.

Bei empfangenden Zwischenereignissen: Ein weiterer Startpunkt liegt vor.

Bei abgebenden Zwischenereignissen: Eine weitere Initiierung erfolgt.

Bei Schlussereignissen: Beendigung des jeweiligen Sequenzflusszweiges. Es

wird auch benutzt, um das Ende eines Subprozesses anzuzeigen, durch den

der Fluss zurück zum übergeordneten Prozess geht.

Das grafische Element für empfangende und abgebende Zwischenereignisse ist

gleich.

Start ohne besonderen

Grund

44 7 Ereignistypen


7.2 Nachricht

Die Kennzeichnung Nachricht (message) bedeutet, dass von einem Teilnehmer am

Prozess eine Nachricht erwartet oder versendet wird:

Bei Startereignissen bedeutet dies, dass durch die Nachricht der Prozess ge-

startet wird.

Bei empfangenden Zwischenereignissen, dass eine Nachricht eintrifft und das

Ereignis auslöst. Typischerweise war der Prozess also angehalten und wartete

auf eine Nachricht.

Bei abgebenden Zwischenereignissen, dass eine Nachricht zu einem Prozess-

teilnehmer geschickt wird.

Bei einem Schlussereignis, dass bei der Beendigung des Sequenzflusszweiges

eine Nachricht an einen Prozessteilnehmer geschickt wird.

Abbildung 7.2-1: Ereignistyp und Marker Nachrichten

7.3 Zeitgeber

Mit diesem Kennzeichen kann zum Ausdruck gebracht werden, dass das Ereignis

Zeitaspekte erfasst. Dabei sind feste Zeit- und Datumsangaben möglich („nach

sieben Tagen“) sowie auch Zyklen („Monatsende“). Ein Beispiel ist in Abbildung

6.4-1 angegeben. Diese „Kennzeichnung“ gibt es nur für empfangende Ereignisse.

Abbildung 7.3-1: Ereignistyp und Marker Zeitgeber

Bedeutung des Kennzeichens bzw. der Ereignistypen:

Bei Startereignissen für die Klärung der Zeitaspekte zum Start des Prozesses.

Bei empfangenden Zwischenereignissen: Für die Klärung von Zeitaspekten.

Falls es im Hauptfluss benutzt wird, kann es als Verzögerungsmechanismus

genutzt werden. Falls es benutzt wird, um Ausnahmesituationen zu beschrei-

ben, ändert es den normalen Fluss in einen Ausnahmefluss.

7.4 Fehler

Dieses Symbol gibt an, dass eine benannte Fehlermeldung erzeugt wird. Es darf

nur für empfangende Zwischenereignisse und Schlussereignisse genutzt werden.

7.5 Abbruch 45


Abbildung 7.4-1: Ereignistyp und Marker Fehler


Bei empfangenden Zwischenereignissen wird es benutzt, um eine Fehlermel-

dung einer Aktivität zu empfangen. In der Grafik kann es nur mit dem Rand

der Aktivität verbunden werden.

Bei Schlussereignissen bedeutet dieses Kennzeichen, dass am Prozessende ein

benannter Fehler erzeugt werden soll.

Die Vorstellung der BPMN-Autoren ist diesbezüglich wie folgt: Die Fehlermel-

dung wird von dem Fehler-Zwischenereignis empfangen, das auf der Grenzlinie

der am nahesten liegenden umfassenden Elternaktivität liegt.

7.5 Abbruch

Durch diese Kennzeichnung entsteht ein Ereignistyp, der den Geschäftsprozess

bzw. den jeweiligen Fluss abbricht. Er wird nur in besonderen Situationen einge-

setzt (vgl. unten). Diese „Kennzeichnung“ gibt es für empfangende Zwischener-

eignisse und für Schlussereignisse.

Abbildung 7.5-1: Ereignistyp und Marker Abbruch

Bei empfangenden Zwischenereignissen wird dieser Ereignistyp für Transaktions-

Subprozesse genutzt. Das Ereignis wird an die Grenzlinie des Subprozesses ange-

fügt. Es wird ausgelöst, wenn ein Abbruch-Schlussereignis im Transaktions-

Subprozess erreicht wird. Es soll außerdem auch ausgelöst werden, wenn während

der Ausführung der Transaktion eine Abbruchnachricht im Transaktionsprotokoll

erreicht wurde, d.h., wenn sozusagen der Transaktions-Subprozess signalisiert,

dass keine vollständige Abarbeitung (kein korrektes Ende) erreicht wurde.

Dieser Ereignistyp wird in Transaktions-Subprozessen benutzt. Er zeigt an,

dass die Transaktion abgebrochen werden soll und löst ein Fehler-

Zwischenereignis aus, das an der Grenzlinie des Subprozesses angefügt ist. Zu-

sätzlich zeigt es an, dass eine Abbruchnachricht des Transaktionsprotokolls an alle

Bei empfangenden Zwischenereignissen

Bei Schlussereignissen

46 7 Ereignistypen


Entities (so die Wortwahl der BPMN-Autoren) geschickt werden soll, die an der

Transaktion beteiligt sind.

7.6 Kompensation

Erhält ein Ereignis das Kennzeichen Kompensation (compensation) und wird

dieses Ereignis an die Grenzlinie einer Aktivität angefügt, muss es auch einen

Sequenzflusspfeil zu einer anderen Aktivität geben, der sogenannten Kompensati-

onsaktivität. Diese ist dann im Krisenfall Ersatz für die Ausgangsaktivität (die mit

dem Kompensationsereignis). Kompensationsaktivitäten dürfen keinen ankom-

menden Sequenzfluss haben, selbst wenn ein Startereignis auf der Prozessebene

vorhanden ist. Diese Kennzeichnung gibt es für Zwischen- und Schlussereignisse.

Abbildung 7.6-1: Ereignistyp und Marker Kompensation


Bei empfangenden Zwischenereignissen wird dieser Ereignistyp für Ersatzak-

tivitäten (Kompensationen) benutzt, zur Aktivierung und zur Ausführung.

Im normalen Fluss (bei abgebenden Zwischenereignissen) bedeutet es, dass

eine Kompensation nötig ist.

In diesem Fall ist das Kompensationsereignis „abgebend“ (throw) und das Kenn-

zeichen muss gefüllt sein. Falls das Ereignis eine Aktivität identifiziert, ist das die

zu ersetzende. Ist keine Aktivität identifiziert, wird die Kompensation ausgedehnt

auf alle Aktivitäten, die innerhalb der Prozessinstanz realisiert wurden, einschließ-

lich des obersten Prozesses (top-level process) und einschließlich aller Subprozes-

se. Jede realisierte Aktivität, die Gegenstand der Kompensation ist, wird in umge-

kehrter Reihenfolge gegenüber der ursprünglichen Realisierung kompensiert. Um

kompensiert zu werden, muss ein Kompensationszwischenereignis an seiner

Grenzlinie sein.

Wenn es an die Grenzlinie einer Aktivität angefügt wird (als abgebendes

Zwischenereignis), dann wird das Ereignis durch eine „abgegebene Kompen-

sation“, die die Aktivität identifiziert oder durch eine Broadcast-

Kompensation ausgelöst.

Wenn das Ereignis ausgelöst wird (das Kompensationsereignis also empfan-

gen wird), dann wird die Kompensationsaktivität, die mit dem Ereignis ver-

knüpft ist, ausgeführt.

Bei Schlussereignissen bedeutet dieses Kennzeichen, dass am Ende eine Kompen-

sation notwendig ist. Falls eine Aktivität identifiziert wird, ist das die zu kompen-

7.7 Bedingung 47


sierende Aktivität. Ist keine Aktivität identifiziert, werden alle Aktivitäten, die im

Prozess durchgeführt wurden, beginnend mit der obersten Ebene und alle Subpro-

zesse umfassend, kompensiert – in umgekehrter Reihenfolge.

7.7 Bedingung

Dieser Ereignistyp wird ausgelöst, falls eine bestimmte Bedingung erfüllt ist, z.B.

„Lagerbestand ist unter die Nachbestellmarke gefallen“. Die Bedingung für das

Ereignis muss falsch und dann wieder wahr werden, bevor das Ereignis wieder

ausgelöst werden kann. Diese Kennzeichnung gibt es nur bei empfangenden Er-

eignissen.

Abbildung 7.7-1: Ereignistyp und Marker Bedingung


Bei Startereignissen wird der Prozess nur gestartet, falls die Bedingung erfüllt

ist.

Bei empfangenden Zwischenereignissen bedeutet es, dass es im Sequenzfluss

erst weiter geht, wenn die Bedingung erfüllt ist.

7.8 Verknüpfung

Ein Ereignis mit dem Kennzeichen Verknüpfung (link) zeigt an, dass zwei Ab-

schnitte eines Prozesses verknüpft werden. Z.B. für Schleifen oder um sehr lange

Sequenzflusslinien zu vermeiden. Sie dürfen nicht ebenenübergreifend verwendet

werden, sondern jeweils nur auf einer Modellierungsebene. Mit jeweils zwei sol-

chen Zwischenereignissen können somit auch Prozessfragmente verknüpft wer-

den, die über mehrere Seiten gedruckt werden müssen.

Es kann mehrere Quell-Verknüpfungsereignisse geben, aber nur ein Ziel-

Verknüpfungsereignis. Wird das Kennzeichen benutzt, um zu empfangen (von den

Quell-Verknüpfern), bleibt das Kennzeichen unbefüllt. Wird es benutzt, um zum

Zielverknüpfer abzugeben, wird das Kennzeichen gefüllt. Diese Kennzeichnung

gibt es für Zwischenereignisse.

Nur auf derselben Ebene

48 7 Ereignistypen


Abbildung 7.8-1: Ereignistyp und MarkerVerknüpfung

7.9 Signal

Dieser Ereignistyp wird verwendet, um Signale zu senden oder zu empfangen. Es

gibt ihn für alle vier Ereignistypen.

Abbildung 7.9-1: Ereignistyp und Marker Signal


Bei Startereignissen: der Prozess wird durch das Signal gestartet.

Bei empfangenden Zwischenereignissen im normalen Fluss: ein Signal kann

empfangen werden.

Bei abgebenden Zwischenereignissen im normalen Fluss: ein Signal kann

gesendet werden.

Bei Schlussereignissen: Nach Beendigung des Prozesses wird ein Signal

ausgesandt. Dies kann über Prozessebenen hinaus und über Becken hinweg

geschehen.

Obiges zeigt, dass ein Signal zur Kommunikation verwendet werden kann, inner-

halb einer Prozessebene und über Prozessebenen hinweg. Wenn es ausgelöst wird,

ist es „für alle“ erkennbar. Es gibt also eine Quelle, aber kein bestimmtes Ziel.

Dies unterscheidet Signale von Nachrichten, die eine spezifische Quelle und ein

bestimmtes Ziel haben.

Ähnlich wie ein Fehlerereignis führt ein Signalereignis zu einem Abbruch von

Aktivitäten. Der Unterschied liegt darin, dass das Signalereignis eine allgemeine-

re, nicht unbedingt von einem Fehler herrührende Bedingung definiert, wie z.B.

den erfolgreichen Abschluss einer anderen Aktivität.

Wird der Ereignistyp dazu benutzt, das Signal zu empfangen, bleibt das Kenn-

zeichen ungefüllt. Gibt er das Signal ab, wird er gefüllt. Mehrere Prozesse können

Startereignisse haben, die vom selben „Breitband“-Signal ausgelöst werden.

Signal

vs.

Nachricht

7.10 Beenden 49


7.10 Beenden

Ein Ereignis mit dem Kennzeichen Beenden beendet den Prozess. Dabei werden

alle Aktivitäten im Prozess unmittelbar beendet. Dies umfasst auch alle Instanzen

von Mehrfachinstanzen. Der Prozess wird ohne Kompensation oder Handlungen

durch Ereignisse beeendet. Diese Kennzeichnung gibt es nur für Schlussereignis-

se.

Abbildung 7.10-1: Ereignistyp und Marker Beenden

7.11 Mehrfach

Das Kennzeichen Mehrfach (multiple) bedeutet, dass dem Ereignis mehrere Aus-

löser zugewiesen sind. Es ist in allen vier Konstellationen einsetzbar.

Abbildung 7.11-1: Ereignistyp und Marker Mehrfach

Im normalen Fluss kann das Ereignis den Auslöser abgeben oder die Auslöser

empfangen. Auf die Grenzlinie einer Aktivität gesetzt, kann das Ereignis den

Auslöser nur empfangen. Das Kennzeichen bleibt dann unbefüllt. Wenn es benutzt

wird, um den Auslöser abzugeben, geschieht dies für alle zugewiesenen Auslöser

und das Kennzeichen wird gefüllt.

Bei Schlussereignissen bedeutet dieses Kennzeichen, dass die Beendigung des

Prozesses mehrere Konsequenzen hat. Alle werden deutlich, z.B., wenn mehrere

Nachrichten zu senden sind. In den Attributen des Schlussereignisses ist festge-

legt, welche der anderen Ergebnisse Gültigkeit gewinnen.

50 8 Kontrollfluss - Sequenzfluss


8 Kontrollfluss - Sequenzfluss

8.1 Einführung

Geschäftsprozesse haben einen Kontrollfluss. Er gibt die Ablaufstruktur an und

ohne ihn gibt es keine Erfassung, Durchdringung und Modellierung. Die Autoren

von [OMG 2009a] bevorzugen allerdings, wie oben schon ausgeführt, den Begriff

sequence flow (hier mit Sequenzfluss übersetzt) gegenüber control flow und defi-

nieren wie folgt:

Definition: Sequenzfluss (sequence flow)

Der Sequenzfluss zeigt die Abfolge, in der Aktivitäten im Prozess

abgearbeitet werden8.

([OMG 2009, S. 97], übersetzt vom Verfasser).

Folgende Begründung geben die BPMN-Autoren dafür, dass sie nicht den Begriff

Kontrollfluss verwenden:

BPMN does not use the term “Control Flow” when referring to the

lines represented by Sequence Flow or Message Flow. The start of

an activity is “controlled” not only by Sequence Flow (the order of

activities), but also by Message Flow (a message arriving), as well

as other process factors, such as scheduled resources. Artifacts can

be associated with activities to show some of these other factors.

Thus, we are using a more specific term, “Sequence Flow,” since

these lines mainly illustrate the sequence that activities will be per-

formed. [OMG 2009, S. 98]

Es ist also die Bedeutung des Nachrichtenflusses und anderer „steuernder Elemen-

te“, die zu dieser Festlegung führten.

Jeder Fluss hat nur eine Quelle und nur ein Ziel. Quelle und Ziel sind entweder

Ereignisse (Start-, Zwischen-, Endereignisse), Aktivitäten (Aufgabe und

Subprozess) oder Operatoren (hier Gateways genannt).

8.2 Flüsse

Die BPMN-Autoren unterscheiden verschiedene Arten von Flüssen:

Normaler Sequenzfluss

Verknüpfungen

Ad Hoc (kein Fluss)

8 “A Sequence Flow is used to show the order that activities will be performed in a Process.” [OMG

2009, S. 19]

8.2 Flüsse 51



Fluss mit Bedingungen

Voreingestellter Fluss

Flüsse für Ausnahmen

Normaler Sequenzfluss

Damit ist der ganz normale Sequenzfluss gemeint, vom Startereignis über die

Aktivitäten hin zu einem Schlussereignis. Er wird grafisch wie oben schon ge-

zeigt, durch eine Linie mit gefülltem Pfeilkopf dargestellt.

Abbildung 8.2-1: Darstellung einer Sequenzflusskante


Als unkontrollierten Fluss bezeichnen die BPMN-Autoren eine Sequenzflusskan-

te, die keinen Bedingungen unterliegt, da sie keinen Operator passiert. Der ein-

fachste Fall ist eine Sequenzflusskante, die schlicht zwei Aktiväten verbindet, wie

in der obigen Abbildung. Damit ist aber auch die Situation gemeint, wenn mehrere

Sequenzflusskanten ohne Operator zu einer Aktivität hinkommen oder wegführen.

Das Tokenkonzept sieht hier vor, dass für jeden unkontrollierten Sequenzfluss

ein Token vom Quell- zum Zielobjekt fließt. Die grafische Darstellung ist wie

oben gezeigt.

Fluss mit Bedingungen

Ein Sequenzfluss kann Bedingungen haben, die zur Laufzeit(!) (des Prozesses)

überprüft werden, um zu bestimmen, ob der Zweig aktiv wird/genutzt wird.

Kommt der Zweig von einer Aktivität, erhält er eine kleine Raute am Anfang der

Linie. Vgl. die folgende Abbildung.

Abbildung 8.2-2: Darstellung eines Flusses mit Bedingung

Kommt der Zweig von einem Operator (gateway, vgl. unten), erhält er keine Rau-

te. Dann wird also die ganz normale Pfeildarstellung genommen, wie oben ge-

zeigt.

Voreingestellter Fluss

Für datenbasierte Exklusiv-Oder-Entscheidungen oder für inklusive Entscheidun-

gen (mehr zu Beidem unten) gibt es einen weiteren Sequenzflusstyp, den vorein-

gestellten Fluss. Dieser wird nur benutzt, wenn die anderen zur Laufzeit (wört-

lich!) keine Gültigkeit erlangen. Bei diesen Sequenzflusskanten wird ein umge-

kehrter Schrägstrich am Beginn der Linie eingefügt.

Fluss ohne Bedingungen

Token



Abbildung 8.2-3: Darstellung eines voreingestellten Flusses

Flüsse für Ausnahmen

Bei diesem Flusstyp geht es darum, Ausnahmen zu verarbeiten. Er tritt außerhalb

des normalen Flusses auf. Die grafische Darstellung erfolgt durch ein Zwischener-

eignis, das bei einer Aktivität platziert wird. Tritt dieses Ereignis ein, gibt eine

Pfeillinie an, welche Aktivität dann angestoßen wird.

Die folgende Abbildung zeigt ein Beispiel: Die Aktivität sei ein Rechenzent-

rumsbetrieb. Die Ausnahmesituation sei Hochwasser. Ausgelöst wird dann das

Notfallmanagement.

Abbildung 8.2-4: Darstellung eines Ausnahmeflusses

Elemente der Abbildung: Aktivität - Ereignistyp und Marker Fehler - Fluss für Ausnahmen

8.3 Nachrichtenflüsse

Die BPMN-Autoren haben das Konzept des Nachrichtenflusses (Message Flow)

in ihre Methode umfassend eingebaut9. Nachrichtenflüsse finden zwischen zwei

Teilnehmern am Geschäftsprozess statt. Für diese verwenden die BPMN-Autoren

den Begriff entity. Nicht zulässig sind Nachrichtenflüsse zwischen Elementen im

selben Becken.

Grafisch werden sie durch eine Pfeillinie ausgedrückt, die am Anfang einen

kleinen Kreis und am Ende eine leere geschlossene Pfeilspitze hat. Vgl. die fol-

gende Abbildung.

Abbildung 8.3-1: Darstellung eines Nachrichtenflusses

Regeln für den Nachrichtenfluss

Die folgende Tabelle gibt alle Elemente der Methode BPMN an, die Nachrichten

empfangen oder weitergeben können und zeigt, welche Elemente durch Nachrich-

9 Dass dies bei einer Methode zur Prozessmodellierung nicht so sein muss, zeigt das Beispiel der

Ereignisgesteuerten Prozessketten, bei denen dieses Konzept nicht vorkommt. Vgl. [Staud 2006].

8.4 Assoziationen 53


tenflüsse verknüpfbar sind. Ein Pfeil bedeutet, dass das Element der Zeile mit dem

in der Spalte durch einen Nachrichtenfluss verbunden werden kann.

Abbildung 8.3-2: Mögliche Nachrichtenflüsse

Quelle: [OMG 2009, S. 31]

8.4 Assoziationen

Flusselemente können mit zusätzlichen Informationen ausgestattet werden, z.B.

mit Texten oder anderen Elementen, die nicht Flusselemente sind. Diese Art der

Verknüpfung wird Assoziation genannt. Grafisch wird sie durch eine gestrichelte

Linie ausgedrückt. Hat die Assoziation eine Richtung, erhält die Linie eine offene

Pfeilspitze.

Abbildung 8.4-1: Darstellung von Assoziationen

Kompensationsassoziation

Eine Kompensationsassoziation tritt außerhalb des normalen Flusses auf und ba-

siert auf einem Kompensationszwischenereignis, das durch den Fehlschlag einer

Transaktion oder ein Kompensationsereignis ausgelöst wird. Das Ziel der Assozia-

tion muss als Kompensationsaktivität deutlich gemacht werden.

Abbildung 8.4-2: Darstellung einer Kompensationsassoziation

Verknüpfung mit Flusselementen durch

Assoziationen



Elemente der Abbildung: Aktivität / Ereignistyp Kompensation / Marker Kompensation / Kompensati-

onsassoziation

8.5 Schleifen

In Prozessen im allgemeinen und Geschäftsprozessen im besonderen gibt es Be-

darf an der Wiederholung von Prozessabschnitten durch Rücksprünge auf eine

flussaufwärts gelegene Stelle des Prozesses. Da diese Wiederholung oft mehrfach

möglich ist, entstehen Schleifen. Die BPMN-Autoren haben zwei

Schleifenkonstrukte in ihre Methode eingebaut, activity looping und sequence flow

looping.

Schleife in einer Aktivität – Standardsituation

Es kommt in der Prozessmodellierung oft vor, dass eine Tätigkeit von vorneherein

wiederholend angelegt ist. Eine solche modelliert man u.U. in ein Basiselement

des Modellierungsansatzes, hier also in Aktivitäten. Dann enthält das Basisele-

ment (die Aktivität) eine implizite Schleife.

Die BPMN-Autoren nennen diesen Vorgang activity looping und haben dafür

ein eigenes Symbol vorgesehen, einen geöffneten Kreis mit Pfeilspitze, der innen

und zentriert am unteren Rand des Aktivitätsdiagramms angefügt wird. Die fol-

gende Abbildung zeigt dies und ein Beispiel.

Ansonsten ist die Spezifikation der Schleife in den Attributen der Aktivität

festgehalten.

Abbildung 8.5-1: Darstellung einer Aktivität mit Schleifencharakter

Exkurs: Vergleich mit EPKs Dem entspricht bei Ereignisgesteuerten Prozessketten das Kapseln einer Schleife in einer Funktion

(vgl. [Staud 2006]). Standardmäßig hat eine solche Schleife einen booleschen Ausdruck, der nach jedem Schleifendurchgang geprüft wird. Z.B.: „Weitere Post im Posteingang?“ Falls der Ausdruck

weiterhin TRUE ist, macht die Schleife weiter.

Einen Schritt in Richtung Programmierung machen die BPMN-Autoren mit der

Unterscheidung von While- und Until-Schleifen, wie es in der prozeduralen Pro-

grammierung üblich ist. Dabei gilt:

Eine While-Schleife prüft die Bedingung, bevor die Aktivität ausgeführt wird,

was bedeutet, dass die Aktivität u.U. gar nicht ausgeführt wird (wenn die Be-

dingung von vorneherein nicht erfüllt ist).

Eine Until-Schleife prüft den Ausdruck, nachdem die Aktivität ausgeführt

wurde, d.h., die Aktivität wird mindestens einmal ausgeführt.

Schleife in einer Aktivität - Multiple Instances / Mehrere Instanzen eines Subprozesses

Nach flussaufwärts

Von

vorneherein repetitive

Handlungen

While oder Until

Multi Instance Loop

8.6 Prozessunterbrechung 55


Hierbei handelt es sich um eine Schleife, in der mehrere Instanzen eines Subpro-

zesses aktiviert werden. In den Attributen der Aufgaben bzw. Subprozesse ist

festgehalten, ob sie wiederholt oder nur einfach ausgeführt werden. Ein grafisches

Symbol (drei senkrechte Linien) am unteren Rand (zentriert) gibt diesen Schlei-

fentyp an.

Abbildung 8.5-2: Schleifen durch Multiple Instance

Die Instanzen können seriell (nacheinander) oder parallel angeordnet sein. Sind

sie seriell angeordnet, wird dies zu einer While-Schleife mit einer bestimmten

Anzahl von Durchgängen.

Sind sie parallel angeordnet sehen dies die BPMN-Autoren so, dass mehre In-

stanzen der Aktivität vorliegen. Etwa so wie beim Schreiben eines Buches, wo das

Schreiben eines Kapitels ein Subprozess wäre und dann für jedes Kapitel eine

Kopie dieses Subprozesses angelegt würde [OMG 2009, S. 118].

Der Multiple Instance Marker kann in Kombination mit jedem anderen Marker,

mit Ausnahme des Loop Marker verwendet werden.

Schleife im Sequenzfluss

Dieses Konzept entspricht dem in der Prozessmodellierung üblichen Rücksprung-

bzw. Schleifenkonstrukt. Dabei wird – von einem exklusiven Oder-Operator

ausgehend – zu einer Stelle im Sequenzfluss gesprungen, die „weiter oben“ (fluss-

aufwärts) liegt.

Die syntaktische Umsetzung ist wie folgt: Der Rücksprung kommt von einem

Gateway (Operator/Verzweigung) und geht zurück vor eine Aktivität (Aufgabe,

Subprozess). Dort wird sie ohne eigenen Operator eingebunden. Vgl. die folgende

Abbildung.

Abbildung 8.5-3: Rücksprung per Schleife im Sequenzfluss

Elemente der Abbildung: Aktivitäten / Schleife im Sequenzfluss

8.6 Prozessunterbrechung

Mit Hilfe von empfangenden Zwischenereignissen des Typs Nachricht können

Prozessunterbrechungen eingebaut werden. Im nachfolgenden Fragment geht es

im Sequenzfluss erst weiter, wenn das Angebot eingetroffen ist.

Seriell oder parallel

Flussaufwärts springen



Abbildung 8.6-1: Darstellung einer Prozessunterbrechung

Elemente der Abbildung: Aktivitäten / Zwischenereignis (empfangend) / Nachricht

8.7 Transaktionen

Das ganz übliche Transaktionenkonzept wurde von den BPMN-Autoren ebenfalls

in ihren Modellierungsvorschlag eingebaut. Sie definieren wie folgt:

Definition: Transaktion

Eine Transaktion ist ein Subprozess bei dem alle „Beteiligten“ (all

parties involved) übereinstimmen, dass der Prozess entweder ganz

abgeschlossen oder abgebrochen wird.

Festgelegt wird die Eigenschaft, Transaktion zu sein, in den Attributen. Die grafi-

sche Darstellung erfolgt durch eine doppelte Grenzlinie für den Subprozess.

Abbildung 8.7-1: Grafische Darstellung einerTransaktion

8.8 Verknüpfungsregeln

In der folgenden Tabelle bedeutet ein Pfeil, dass das Element der Zeile mit dem in

der Spalte verknüpft werden kann.

8.8 Verknüpfungsregeln 57


Abbildung 8.8-1: Regeln für die Verknüpfung von Elemenen im Sequenz-

fluss


58 9 Operatoren / Gateways


9 Operatoren / Gateways

9.1 Grundlagen

Wie jede Methode zur Prozessmodellierung weist auch die BPMN Operatoren auf,

mit denen Verzweigungen und Zusammenführungen von Kontrollflüssen erfasst

werden. In der BPMN werden sie Gateways genannt.

Wir kennen Operatoren aus allen möglichen Bereichen, v.a. der Mathematik

und der Logik. Doch wozu dienen eigentlich Operatoren in der Prozessmodellie-

rung? Die Antwort ist einfach: Durch die Operatoren kann geklärt werden, welche

Situation vorliegt, …

wenn mehrere Flüsse (Kontroll- bzw. Sequenzflüsse) zusammenfließen

oder

wenn mehrere entstehen und getrennt fortgeführt werden.

Die allgemeine Situation bei Operatoren in Geschäftsprozessen ist, wie es die

folgende Abbildung zeigt: Zu einem Operator kommt eine Kante (Sequenzfluss-

zweig) und mehrere gehen weg (A). Dies wird auch Verzweigung genannt. Oder

es kommen mehrere Kanten an und eine geht weg (B), was auch Verschmelzung

genannt wird. Möglich ist auch, dass gleichzeitig mehrere ankommen und wegge-

hen. Dann müssen einfach die beiden Situationen A und B kombiniert werden.

Die folgende Abbildung zeigt die Darstellung der zwei erstgenannten Situatio-

nen.

Warum Operatoren?

9.1 Grundlagen 59


Abbildung 9.1-1: Verzweigende und verschmelzende Sequenzflusskanten

Situation A

Aus einer Kante werden mehrere. Dies kann folgende Bedeutungen haben:

Die 2 bis n nach dem Operator angesiedelten Kanten werden beim jeweiligen

Durchgang alle aktiv. In einem solchen Fall spricht man von einem UND-

Operator.

Inhaltliches Beispiel: Für einen Urlaubsantrag müssen mehrere Aktivitäten

angestoßen werden, z.B. „Urlaubsvertretung klären“, „Einverständnis Abtei-

lungsleiter einholen“ und „Antrag stellen".

Genau eine der Kanten wird beim jeweiligen Durchgang aktiv. In einem

solchen Fall spricht man von einem exklusiven Oder-Operator (XODER).

Inhaltliches Beispiel: Nach einem Auftragseingang wird geprüft, ob der Auf-

trag angenommen werden kann oder nicht. Der eine Zweig führt dann zur Ak-

tivität Auftrag annehmen, der andere zu Auftrag ablehnen.

Mindestens eine und ansonsten eine beliebige Teilmenge der wegführenden

Kanten wird aktiv. In einem solchen Fall spricht man von einem Oder-

Operator (ODER).

Inhaltliches Beispiel: Eine Ermäßigung für den Besuch einer Kindertagesstät-

te kann gewährt werden, wenn mindestes eine der folgenden Bedingungen er-

füllt ist: Kind ist Geschwisterkind, Eltern sind arbeitslos, Eltern sind alleiner-

ziehend.

Der Typ des Operators wird durch die Semantik des jeweiligen Prozessabschnitts

bestimmt. Ein UND- Operator bedeutet hier (verzweigend) zum Beispiel, dass an

dieser Stelle des Geschäftsprozesses mehrere Aufgaben angestoßen werden, so

wie es das oben angeführte inhaltliche Beispiel zeigt. Hier wird auch von Teilauf-

gaben gesprochen.

Ein exklusives Oder bedeutet, dass Alternativen vorliegen. Z.B. die oben ange-

deutete. Oftmals liegen hier Entscheidungssituationen vor, deren Ergebnis durch

Verzweigung

UND: Mehrere

Aufgaben - Teilaufgaben



die alternativen Kontrollflüsse modelliert wird. Eine solche „exklusiv-Oder-

Situation liegt in Geschäftsprozessen sehr häufig vor.

Weniger vertraut ist das oben angeführte „einfache“ Oder. Es kommt aber, wie

ja auch das Beispiel andeutet, in Regelungen, Vorschriften und Gesetzen durchaus

vor. Hier werden Situationen des Geschäftsprozesses erfasst, bei denen mindes-

tens einer der wegführenden Flüsse aktiv wird. Die Betonung liegt auf dem „min-

destens“.

Situation B

Situation B beschreibt sozusagen das Gegenstück: Aus mehreren Kanten wird

eine. Hier wird durch den Operator beschrieben, wie die „ankommenden“ Kon-

trollflüsse strukturiert sein müssen, damit der Fluss über den Operator weiter geht:

Es müssen alle (2 bis n) Kanten ankommen, erst dann geht es über

den Operator weiter. Dann liegt ein UND-Operator vor.

Inhaltliches Beispiel: Mehrere Teilaufgaben müssen gelöst werden, damit es

weitergeht.

Genau eine Kante muss und darf nur ankommen, dann geht es weiter.

Dann ist es ein exklusiver Oder-Operator (XODER).

Inhaltliches Beispiel: Nach einer Entscheidungssituation werden die Flüsse

wieder zusammengeführt, weil danach Aktivitäten kommen, die für alle Al-

ternativen Gültigkeit haben.

Mindestens eine und ansonsten eine beliebige Teilmenge muss ankommen,

dann geht es weiter. In einem solchen Fall sprcht man von einem Oder-

Operator (ODER).

Inhaltliches Beispiel: Nach einer Verzweigung wie in „Situation A/Oder-

Operator“ oben geht es einheitlich weiter, z.B. durch „Bearbeitung des An-

trags auf Ermäßigung für den Besuch der Kindertagesstätte“.

Die BPMN-Autoren haben die drei hier angeführten Operatoren (Gateways) vor-

gesehen und zusätzlich noch einen weiteren, den sie „complex“ nennen (vgl. un-

ten). Ihre Bezeichnungen sind wie folgt:

Operatoren der BPMN - Gateways

Operator BPMN-Bezeichnung

UND verzweigend Parallel Gateway, Parallel forking

UND verknüpfend Parallel Gateway, parallel joining

XODER verzweigend exclusive decision

XODER verknüpfend exclusive merging

ODER verzweigend Inclusive Gateway

ODER verknüpfend Inclusive Gateway

Gegenüber der UML wollten sie wohl die grafische Darstellung von Operatoren

vereinfachen. Es gibt nur noch ein einziges grafisches Basiselement, mit dem alle

Operatoren dargestellt werden können. Dieses besteht aus einer auf die Spitze

gestellten Raute.

Verschmelzung

UND, exklusives ODER, ODER,

COMPLEX

9.2 XODER 1 61


Abbildung 9.1-2: Darstellung eines Gateways (Operators)

9.2 XODER 1

Datenbasiert, verzweigend

Der Operator für das exklusive Oder (XODER) tritt hier als „exclusive decision

and merging“ auf. Und zwar datenbasiert („data-based“) oder ereignisbasiert

(„event-based“). Er hat die oben beschriebene übliche Bedeutung.

Der Operator ist datenbasiert, falls die Entscheidung, welcher Zweig gegangen

wird, aufgrund von logischen Ausdrücken bei den abgehenden Kanten getroffen

wird. Neben dem allgemeinen Symbol kann bei diesem Operator auch das mit

dem „X“ verwendet werden.

Abbildung 9.2-1: Symbole für die Darstellung eines datenbasierten XO-

DER-Operators (exclusive Data-Based)

Die folgende Abbildung zeigt ein einfaches Beispiel. Die Bearbeitung der Anfrage

eines potentiellen Kunden führt entweder dazu, dass der Auftrag angenommen

oder abgelehnt wird.

Abbildung 9.2-2: Darstellung eines Gateway vom Typ Exclusive Decision

9.3 XODER 2

Datenbasiert, verknüpfend

Die folgende Abbildung zeigt ein Beispiel für die Zusammenführung entspre-

chender Sequenzflusskanten. Über dieses Gateway geht es weiter, wenn genau

eine der Kanten aktiv wurde.

Machbarkeitsprüfung



Abbildung 9.3-1: Darstellung eines ereignisbasierten XOder-Operators -

verknüpfend

9.4 XODER 3

Ereignisbasiert, verzweigend

Im Falle eines ereignisbasierten verzweigenden Gateway fällt die Entscheidung

durch ein Ereignis, das zum jeweiligen Zeitpunkt im Prozess auftritt. Normaler-

weise wird dies „dem Geschäftsprozess“ durch den Empfang einer Nachricht

mitgeteilt. Dieses Ereignis legt fest, welcher weiterführende Sequenzflusszweig

aktiv wird.

Abbildung 9.4-1: Darstellung eines ereignisbasierten XOder-Operators

Auch andere Ereignistypen sind hier denkbar, z.B. Timer. Auf jeden Fall aber

Zwischenereignisse vom Typ „empfangend“ (vgl. Abschnitt 6.4). Es gibt zwei

Möglichkeiten, eine Nachricht zu erhalten:

(1) Durch Aufgaben des Typs „Empfangen“

Abbildung 9.4-2: Darstellung eines Nachrichtenempfangs 1


(2) Durch Zwischenereignisse des Typs Nachricht.

9.5 XODER 4 63


Abbildung 9.4-3: Darstellung eines Nachrichtenempfangs 2


9.5 XODER 4

Ereignisbasiert, verknüpfend

Diese Anordnung wird nur als Zusammenführung ohne spezifische Ereignisse

benötigt, wie oben schon gezeigt.

Abbildung 9.5-1: Exklusives ODER - Zusammenführung

9.6 UND 1

Verzweigend

Mit ihrem Parallel Gateway möchten die BPMN-Autoren parallele Flüsse erzeu-

gen und synchronisieren. Konkret bedeutet dies, dass die Flüsse parallel gestartet

werden und dann in einem Zeitfenster ablaufen. D.h., flussabwärts ab dem Opera-

tor gibt es eine Stelle, wo die parallelen Flüsse zusammengeführt werden und es

nur weiter geht, wenn alle angekommen sind (vgl. die Thematik „Zeitfenster“,

beschrieben in [Staud 2006]).

Zuerst die Aufspaltung. Dabei wird das Pluszeichen in das Symbol für den Ga-

teway genommen.

Parallel Gateway;

Parallel forking

Aufspaltung



Abbildung 9.6-1: Darstellung eines Parallel Gateway – UND / verzweigend

Inhaltlich bedeutet dies, dass nach Erledigung einer Aufgabe mehrere andere Auf-

gaben angestoßen werden.

9.7 UND 2

Verknüpfend

Bei der Zusammenführung gilt das Entsprechende. Alle ankommenden Kanten

müssen „ankommen“, erst dann geht es im Prozess über das Gateway weiter und

erst dann wird die nächste Aufgabe angestoßen.

Abbildung 9.7-1: Darstellung eines Parallel Gateway – UND / verknüpfend

Die BPMN-Autoren präzisieren dann den UND-Operator mit Hilfe ihres Token-

Konzepts: Der Prozess wartet auf alle Ankunftssignale, bevor es weitergeht („…

the process will wait for all signals to arrive before it can continue“).

In dieser Situation ist es auch möglich, auf das Operatorsymbol zu verzichten.

Hier betonen die BPMN-Autoren allerdings das Unkontrollierte der Situation

(„uncontrolled“ flow).

Parallel Gateway;

Parallel joining, Synchronization

Token

9.8 ODER - verzweigend 65


Abbildung 9.7-2: UND-Verknüpfung ohne Operatorsymbol

9.8 ODER - verzweigend

Wie oben ausgeführt, ist der ODER-Operator wie folgt definiert: Von den ver-

knüpften Sequenzflusszweigen (Kanten) kann bei jeder Instanz des Geschäftspro-

zesses eine beliebige Teilmenge und mindestens eine Kante aktiv werden.

Die BPMN-Autoren nennen den ODER-Operator Inclusive Gateway. Er hat

die in der folgenden Abbildung angegebene grafische Form.

Abbildung 9.8-1: ODER-Operator - Inclusive Gateway

Sie definieren ihn ohne Rückgriff auf die Definition des ODER-Operators der

formalen Sprachen (siehe Hinweis oben) wie folgt: Bei weggehenden Sequenz-

flusszweigen unterliegt jeder einzelne einer unabhängigen binären Ja/Nein-

Entscheidung. Damit gilt:

Da jeder Pfad unabhängig ist, sind alle Kombinationen von Pfaden möglich,

auch keiner oder alle.

Mit Hilfe einer voreingestellten weiterführenden Kante wird dann noch sicherge-

stellt, dass mindestens eine Kante aktiv wird [OMG 2009, S. 26]. Die BPMN-

Autoren begründen dies damit, dass sonst u.U im Sequenzfluss Blockaden entste-

hen könnten.

Diese ODER-Verzweigung kann auf zwei Arten realisiert werden:

(1) Mit mehreren abgehenden Sequenzflusszweigen

Diese sind mit kleinen Rauten (mini-diamonds) am Anfang gekennzeichnet. Ein

zusätzlicher Zweig gibt dann die „Voreinstellung“ und sichert ab, dass mindestens

ein Zweig aktiv wird. Vgl. die folgende Abbildung.

Als eine Einschränkung geben Sie an, dass das Quellobjekt (also das dem Ope-

rator vorangehende Element) kein Ereignis sein darf. Vgl. hierzu das Konzept der

„verbotenen Strukturen“ in Ereignisgesteuerten Prozessketten, das dasselbe Archi-

tekturmerkmal verlangt [Staud 2006, Abschnitt 4.4-3].

Beliebige Teilmenge, mindestens eine Kante

Verzweigend

Viele Ja/Nein-

Entscheidungen

Verbotene Anordnung



Abbildung 9.8-2: Darstellung einer Inclusive Decision ohne Gateway-

Symbol

Das Beispiel stellt Aspekte einer Wareneingangsprüfung dar. Die Semantik ist wie folgt: Jede der Tätigkeiten kann einzeln oder in beliebiger Kombination mit den anderen vorkommen. Außerdem ist

es auch möglich, dass keine Aktion nötig ist. Vgl. zum ODER-Operator und seinen „Untiefen“ [Staud

2006].

(2) Mit einem Inclusive Gateway.

Die folgende Abbildung zeigt die grafische Darstellung mit dem Operatorsymbol.

Abbildung 9.8-3: Darstellung einer Inclusive Decision mit einem Inclusive

Gateway

9.9 ODER - verknüpfend

Der Inclusive Gateway wird auch für das Zusammenführen („merge“) von Se-

quenzflusszweigen benutzt. Für die ankommenden Sequenzflusszweige gilt die-

selbe Struktur wie oben, nur dass sie hier von flussaufwärts angesiedelten Elemen-

ten realisiert wurde. D.h., bezüglich dieser Sequenzflusszweige gilt, dass sie bei

einer Instanz in beliebiger Kombination auftreten können und dass immer mindes-

tens ein Zweig ankommt.

Verschmelzend

9.10 Complex Gateway - verzweigend 67


Abbildung 9.9-1: Darstellung eines Inclusive Gateway – Merging Sequence

Flow

Prozesssemantik Im obigen Beispiel geht es um Neukunden eines Kreditinstiuts. Der Ausschnitt zeigt, welche der

Leistungen der Neukunde in Anspruch nehmen möchte, formuliert z.B. in einem Gespräch zwischen

dem Kundenberater und dem Kunden. Die Punkte deuten an, dass es hier natürlich noch weitere Leis-

tungen geben kann.

9.10 Complex Gateway - verzweigend

Mit dem Complex Gateway (verzweigend und verschmelzend) sollen Situationen

beherrschbar werden, die mit den anderen Gateways nicht leicht bewältigt werden

können [OMG 2011, Abschnitt 10.5.5]. Wörtlich schreiben die BPMN-Autoren,

dass er helfen soll „… to model complex synchronisation behavior“ (S. 295).

Damit können z.B. komplexe Situationen, die durch einen Algorithmus be-

schrieben werden, modelliert werden. Z.B.: „Nachbestellung erfolgt erst, wenn der

Lagerbestand unter das Doppelte des Absatzes der letzten drei Monate gefallen ist

oder falls die Prognoserechnung eine Erhöhung des Absatzes um mindestens 50%

ergibt …“.

Das Gateway wird durch einen Stern dargestellt, der in der Mitte des Gateway-

Symbols eingefügt ist, wie es die folgende Abbildung zeigt.

Abbildung 9.10-1: Darstellung eines Complex Gateway

Falls er zur Darstellung einer Entscheidungssituation genutzt wird, also mit abge-

henden Kanten, muss ein Ausdruck vorliegen der festlegt, welche der abgehenden

Kanten aktiv wird. Der Ausdruck kann auf Daten des Geschäftsprozesses und den

Status des ankommenden Sequenzflusses Bezug nehmen [OMG 2009, S. 82].

Auch an dieser Stelle weisen die BPMN-Autoren darauf hin, dass sicherzustellen

Verzweigend, für

Entscheidungen



ist, dass mindestens eine Kante aktiv wird. Die folgende Abbildung zeigt ein Bei-

spiel.

Abbildung 9.10-2: Darstellung eines Complex Gateway - verzweigend

Semantik Hier geht es um eine, z.B. regelmäßig automatisiert stattfindende Prüfung des Lagerbestandes. Abhän-

gig vom Ergebnis der Prüfung (hier vereinfacht) erfolgen die weiteren Tätigkeiten.

9.11 Complex Gateway - verknüpfend

Wenn er verknüpfend eingesetzt wird, dann kann dies nur bedeuten, dass die zu-

sammenzuführenden Aktivitäten auf die oben beschriebene Weise („komplexe

Entscheidung“) aufgeteilt wurden und dass der Sequenzfluss jetzt in einer Kante

weitergeführt wird, so dass die Verknüpfung notwendig ist. Das folgende Beispiel

ist deshalb als Fortsetzung des obigen konzipiert.

Abbildung 9.11-1: Darstellung eines Complex Gateway - verknüpfend

Semantik: Nachdem die Aktivitäten aus der Entscheidung abgearbeitet wurden (d.h. eine davon wurde aktiv) geht

es in einem Sequenzflusszweig weiter, deshalb müssen die Kanten zusammengefasst werden. Das Gateway-Symbol drückt hier also nur aus, dass die davor angesiedelten Aktivitäten auf die oben be-

schriebene Weise zustande kamen.

Verknüpfend

10 Literatur

OMG 2003

Object Management Group: UML 2.0 Superstructure Specification (Unified

Modeling Language: Superstructure, version 2.0, final Adopted Specification,

ptc/03-08-02), August 2003

OMG 2009

Object Management Group (OMG): Business Process Modeling Notation

(BPMN). Version 1.2 January 2009 (OMG Document Number: formal/2009-

01-03. Standard document URL: http://www.omg.org/spec/BPMN/1.2)

OMG 2011

Object Management Group (OMG): Business Process Modeling Notation

(BPMN). Version 2.0 January 2011 (OMG Document Number: formal/2011-

01-03. Standard document URL: http://www.omg.org/spec/BPMN/2.0)

Staud 2006

Staud, Josef: Geschäftsprozessanalyse. Ereignisgesteuerte Prozessketten und

objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche

Standardsoftware (3. Auflage). Berlin u.a. 2006 (Springer-Verlag)

Staud 2010

Staud, Josef: Unternehmensmodellierung – Objektorientierte Theorie und Pra-

xis mit UML 2.0. Berlin u.a. 2010 (Springer-Verlag)

bpmn - staud.info · das mit der bpmn verfolgte ziel ist somit, eine standardvisualisierungsme-...

Documents