BPMN 2.0 Business Process Model and Notation - Thomas Allweyer - Kurze Prozesse
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Thomas Allweyer
BPMN 2.0
Business Process
Model and Notation
Einführung in den
Standard für die
Geschäftsprozessmodellierung
4. Auflage2 BPMN am Beispiel
2.1 Ein erstes BPMN-Modell
Zur Einführung wird ein einfaches BPMN-Prozessdiagramm betrachtet. Das in Ab-
bildung 1 dargestellte Modell einer Stellenausschreibung ist für die meisten Menschen
unmittelbar verständlich, die sich bereits mit irgendeiner Art der Ablaufmodellierung
beschäftigt haben. Die Darstellung ähnelt bekannten Flussdiagrammen und Programm-
ablaufplänen.
Fachabteilung
Mitarbeiter- Stellenaus-
bedarf schreibung
Stelle ausschreiben
melden prüfen
Mit- Okay
arbeiter
Nicht okay
benötigt
Stellenaus-
Stellenaus- Stellenaus-
Personal-
abteilung
schreibung
schreibung schreibung
ver-
verfassen überarbeiten
öffentlichen Stelle
ausge-
schrieben
Abbildung 1: Ein einfaches BPMN-Modell
An dem Prozess „Stelle ausschreiben“ sind eine Fachabteilung und die Personalabtei-
lung beteiligt. Er beginnt, wenn ein Mitarbeiter benötigt wird. Die Fachabteilung meldet
diesen aufgetretenen Mitarbeiterbedarf. Daraufhin verfasst die Personalabteilung eine
Stellenausschreibung. Die Fachabteilung prüft diese Stellenausschreibung.
Hierbei gibt es zwei Möglichkeiten: Entweder die Stellenausschreibung ist okay, oder
sie ist nicht okay. Ist sie nicht okay, wird sie von der Personalabteilung überarbeitet.
Hierauf folgt erneut die Prüfung durch die Fachabteilung, wobei das Ergebnis wie-
derum okay oder nicht okay sein kann. Es kann also vorkommen, dass die Stellenaus-
schreibung mehrfach überarbeitet werden muss. Ist die Stellenausschreibung okay, so
wird sie von der Personalabteilung veröffentlicht. Damit ist die Stelle ausgeschrieben,
womit das Ende des Prozesses erreicht ist.
In der Praxis kann der Ablauf zur Erstellung und Veröffentlichung einer Stellenanzeige
wesentlich komplexer und umfangreicher sein. Das dargestellte Modell stellt – wie alle
Beispiele in diesem Buch – eine starke Vereinfachung dar, um übersichtliche Modelle zu
erhalten, an denen sich die verschiedenen Elemente der BPMN gut erläutern lassen.
2.2 Verwendete Konstrukte der BPMN
Im Folgenden werden die einzelnen Elemente des Modells aus Abbildung 1 näher be-
trachtet.
16Der gesamte Ablauf befindet sich in einem sogenannten „Pool“. Hierbei handelt es sich
ganz allgemein um eine Art „Behälter“ für einen kompletten, abgeschlossenen Prozess.
Im Beispiel ist der Pool mit dem Namen des enthaltenen Prozesses bezeichnet.
Ein Prozess befindet sich prinzipiell innerhalb eines Pools. Ist dieser jedoch für das
Verständnis des Prozesses nicht von Bedeutung, kann man darauf verzichten, ihn in der
Grafik darzustellen. Ist in einem Prozessdiagramm also kein Pool eingezeichnet, befin-
det sich der gesamte Prozess in einem unsichtbaren, „impliziten“ Pool.
Interessant werden Pools vor allem dann, wenn mehrere Pools verwendet werden, um
eine „Kollaboration“ zu modellieren, also das Zusammenspiel von Prozessen mehrerer
Partner. Dann werden die Prozesse der verschiedenen Partner in unterschiedlichen
Pools dargestellt. Dies wird in Kapitel 5 beschrieben.
Der Pool aus Abbildung 1 ist in zwei Bahnen unterteilt. Eine Bahn (engl. „Lane“) kann
beispielsweise verwendet werden, um – wie hier – die Zuordnung zu einzelnen Organi-
sationseinheiten vorzunehmen, oder innerhalb eines technischen Systems die Aufgaben
einzelner Komponenten darzustellen.
Im betrachteten Beispiel wird mit Hilfe der Bahnen dargestellt, welche Aktivitäten des
Prozesses von der Fachabteilung und welche von der Personalabteilung durchgeführt
werden.
Pools und Bahnen werden auch „Swimlanes“ („Schwimmbahnen“) genannt. Dies erin-
nert an die Unterteilung von Schwimmbecken in einzelne Bahnen, wobei sich jeder
Wettkampfteilnehmer nur innerhalb seiner Bahn bewegt.
Der Ablauf selbst beginnt mit dem Startereignis (engl. „Start Event“) „Mitarbeiter benö-
tigt“. Prozesse beginnen im Normalfall mit einem solchen Startereignis. Dieses wird
durch einen einfachen Kreis dargestellt. Meist ist es auch sinnvoll, genau ein Start-
ereignis zu verwenden, und nicht mehrere.
Ein Rechteck mit abgerundeten Ecken stellt eine Aktivität (engl. „Activity“) dar. In einer
Aktivität wird etwas getan. Dies kommt in den Bezeichnungen zum Ausdruck, z. B.
„Mitarbeiterbedarf melden“ oder „Stellenausschreibung prüfen“.
Die Verbindungspfeile oder Kanten werden zur Modellierung des Sequenzflusses (engl.
„Sequence Flow“) verwendet. Sie stellen dar, in welcher Reihenfolge oder Sequenz die
verschiedenen Ereignisse, Aktivitäten und weiteren Elemente durchlaufen werden.
Häufig wird dies als Kontrollfluss bezeichnet, doch gibt es in der BPMN auch noch
Nachrichtenflüsse (engl. „Message Flow“), die z. T. ebenfalls den Ablauf beeinflussen
und somit ebenfalls zum Kontrollfluss gezählt werden können. Daher wurde der neue
Begriff „Sequenzfluss“ geschaffen. Zur Unterscheidung von anderen Flüssen und
Kanten ist es auch wichtig, Sequenzflüsse mit durchgehenden Linien und ausgefüllten
Pfeilspitzen zu zeichnen.
17In dem Prozess „Stelle ausschreiben“ gibt es eine Verzweigung: Auf die Aktivität „Stel- lenausschreibung prüfen“ folgt ein „Gateway“. Eine leere Raute bezeichnet dabei einen exklusiven Gateway (engl. „Exclusive Gateway“). Dies bedeutet, dass von mehreren ausgehenden Sequenzflüssen immer genau einer gewählt werden muss. Jedes Mal, wenn im Rahmen der Stellenausschreibung der in der Abbildung rechts dargestellte Gateway erreicht wird, muss also entschieden werden, ob dem Sequenzfluss nach rechts zur Aktivität „Stellenausschreibung veröffentlichen“ oder dem nach links zur Aktivität „Stellenausschreibung überarbeiten“ gefolgt wird. Beides gleichzeitig ist nicht möglich. Die Logik einer solchen Entscheidung wird auch als „exklusives Oder“ bezeichnet, ab- gekürzt „XOR“. Welchem der ausgehenden Pfade gefolgt wird, wird mit Hilfe von Be- dingungen (engl. „Condition“) an den ausgehenden Sequenzflüssen bestimmt. Wenn man ein Modellierungstool verwendet und der Prozess von einer Software simuliert oder ausgeführt werden soll, dann können Bedingungen zumeist ganz exakt mit Hilfe einer formalen Beschreibung oder einer Programmiersprache in spezielle Attribute der Sequenzflüsse geschrieben werden. Dient das Modell hingegen nur dazu, den Prozess anderen Menschen verständlich zu machen, empfiehlt es sich, die Bedingungen im Klartext an die Sequenzflüsse zu schreiben. „Okay“ und „Nicht okay“ im Anschluss an die Aktivität „Stellenausschreibung prüfen“ ist für Menschen unmittelbar verständlich – eine Software könnte damit wenig anfangen. Auch zur Zusammenführung alternativer Pfade werden Gateways verwendet. Im Bei- spielprozess führt der links von der Aktivität „Stellenausschreibung prüfen“ gezeigte Gateway die beiden eingehenden Sequenzflüsse zusammen. Es handelt sich wiederum um einen exklusiven Gateway. Dieser erwartet, dass im Prozess vorher entweder die Aktivität „Stellenausschreibung verfassen“ oder „Stellenausschreibung überarbeiten“ durchgeführt wird – nicht jedoch beide zugleich. Es sollte darauf geachtet werden, dass man einen Gateway immer nur entweder als Verzweigung oder als Zusammenführung verwendet, nicht jedoch als Kombination aus beiden. Das letzte Element des betrachteten Prozesses ist das Endereignis (engl. „End Event“). Es wird wie das Startereignis als Kreis dargestellt – allerdings mit einem dicken Rand. 2.3 Logik des Sequenzflusses Die Ablauflogik des obigen Stellenausschreibungsprozesses ist recht leicht verständlich. Bei komplizierteren Prozessmodellen tauchen aber gelegentlich Unklarheiten auf, wie eine bestimmte modellierte Struktur genau zu verstehen ist. Es ist daher hilfreich, wenn die Bedeutung der im Sequenzfluss verwendeten Elemente möglichst eindeutig definiert ist. 18
Die Logik des Sequenzflusses in einem Prozessdiagramm lässt sich mit Hilfe von „Mar-
ken“ (engl. „Token“) erklären. Wie bei einem Gesellschaftsspiel Spielmarken entspre-
chend den Spielregeln über den Spielplan geschoben werden, kann man gedanklich
Marken nach den Regeln der BPMN durch ein Prozessmodell schieben.
Jedes Mal wenn der Prozess gestartet wird, erzeugt das Startereignis eine Marke (vgl.
Abbildung 2). Da der Stellenausschreibungsprozess öfter durchgeführt wird, können im
Laufe der Zeit ganz viele Marken erzeugt werden. Dabei kann es vorkommen, dass der
Prozess für die eine Stellenausschreibung noch gar nicht beendet ist, wenn der Prozess
für die Ausschreibung einer anderen Stelle startet. Jede Marke durchläuft den Prozess
völlig unabhängig von den anderen Marken.
Mitarbeiter Mitarbeiter Mitarbeiter
benötigt benötigt benötigt
Abbildung 2: Ein Startereignis erzeugt eine Marke.
Die vom Startereignis erzeugte Marke wandert über den Sequenzfluss zur ersten Akti-
vität. Diese nimmt die über den eingehenden Sequenzfluss ankommende Marke entge-
gen, führt ihre Aufgabe aus (in diesem Fall „Mitarbeiterbedarf melden“) und gibt an-
schließend über den ausgehenden Sequenzfluss wieder eine Marke aus (vgl. Abbildung
3).
1.) 2.)
Mitarbeiter- Mitarbeiter-
bedarf bedarf
melden melden
Abbildung 3: Eine Aktivität nimmt eine Marke entgegen und gibt anschließend wieder eine
Marke aus.
Auch die folgende Aktivität gibt eine Marke weiter. Sie gelangt dann zum zusammen-
führenden exklusiven Gateway. Die Aufgabe dieses Gateways ist einfach: Er nimmt
lediglich eine Marke entgegen, die über einen beliebigen eingehenden Sequenzfluss
ankommt, und gibt diese Marke über den ausgehenden Sequenzfluss weiter. Dies ist in
Abbildung 4 dargestellt. Im Fall A kommt eine Marke von links an, im Fall B von unten.
In beiden Fällen wird diese Marke über den rechten Sequenzfluss wieder ausgegeben.
Interessanter ist die Aufgabe des verzweigenden exklusiven Gateways. Er nimmt eine
ankommende Marke entgegen und entscheidet nun aufgrund der Bedingungen, über
welchen der ausgehenden Sequenzflüsse er eine Marke ausgibt. Abbildung 5 zeigt oben
den Fall, dass die Bedingung „Okay“ zutrifft, d. h. dass die vorangehende Prüfung ein
positives Ergebnis erbracht hat. In diesem Fall wird die Marke über den rechten
19A1) A2)
B1) B2)
Abbildung 4: Weitergabe einer Marke durch einen zusammenführenden exklusiven Gateway
Sequenzfluss ausgegeben. Ansonsten, wenn die Bedingung „Nicht okay“ zutrifft, wird
die Marke entsprechend über den unteren Sequenzfluss ausgegeben.
Der Modellierer muss die Bedingungen so aufstellen, dass immer nur genau eine der
beiden Bedingungen zutrifft. Wie Bedingungen formuliert werden und wie überprüft
wird, welche Bedingung zutrifft, wird in der BPMN-Spezifikation nicht geregelt. Da der
betrachtete Prozess nicht von einer Software ausgeführt werden soll, genügen die hier
gewählten, recht einfachen Angaben. Ansonsten müsste man die Bedingungen nach den
Erfordernissen und Regeln der verwendeten Software formulieren.
Schließlich gelangt die Marke – ggf. nach mehrfachem Durchlaufen der Schleife zur
Überarbeitung der Stellenausschreibung – zum Endereignis. Dieses verschluckt einfach
jede ankommende Marke und beendet damit die Durchführung des Prozesses (Ab-
bildung 6).
A1) A2)
Okay Okay
Nicht okay Nicht okay
B1) B2)
Okay Okay
Nicht okay Nicht okay
Abbildung 5: Weitergabe einer Marke durch einen verzweigenden exklusiven Gateway
20Stelle aus- Stelle aus- Stelle aus-
geschrieben geschrieben geschrieben
Abbildung 6: Ein Endereignis verschluckt eine ankommende Marke.
Der Sequenzfluss jedes Prozessdiagramms lässt sich auf diese Weise mit Hilfe des
Markenflusses durchspielen. Hierdurch kann man beispielsweise überprüfen, ob die
Ablauflogik eines bestimmten Prozesses korrekt modelliert wurde.
Bei der Marke handelt es sich übrigens nicht um ein Datenobjekt, Dokument oder der-
gleichen. Bei dem Stellenausschreibungs-Prozess könnte man sich vorstellen, ein Doku-
ment „Stellenausschreibung“ durch den Prozess wandern zu lassen, das dann auch die
ganzen Daten enthielte, wie z. B. ein Attribut für das Ergebnis der Aktivität „Stellen-
ausschreibung prüfen“. Die Entscheidung des verzweigenden Gateways könnte dann
mit Hilfe dieses Attributwertes gefällt werden. Der BPMN-Sequenzfluss beschränkt sich
aber auf die reine Ausführungsreihenfolge, die Marken selbst tragen somit keine Infor-
mationen – abgesehen von einem eindeutigen Identifizierer, um die Marken unterschei-
den zu können. Für Datenobjekte gibt es eigene BPMN-Konstrukte, die in Kapitel 10
vorgestellt werden.
2.4 Darstellungsmöglichkeiten
Meist werden Pools horizontal dargestellt. Damit verlaufen die Sequenzflüsse vorrangig
von links nach rechts. Es ist aber genauso möglich, vertikale Pools zu verwenden und
die Sequenzflüsse von oben nach unten laufen zu lassen, wie im Beispiel der Abbildung
7.
Es ist sinnvoll, sich auf eine Variante – horizontal oder vertikal – festzulegen. Allerdings
gibt es Modellierungstools, die von Vornherein nur die horizontale Modellierung unter-
stützen.
Abbildung 7 zeigt außerdem ein Beispiel für verschachtelte Bahnen (engl. „Nested
Lanes“). Die Bahn „Vertrieb“ ist selbst wieder in die zwei Bahnen „Außendienst“ und
„Auftragsabwicklung“ unterteilt. Prinzipiell lassen sich Bahnen beliebig tief verschach-
teln, auch wenn dies sicherlich nur bis zu einer gewissen Ebene sinnvoll ist.
Wo und wie die Namen der Pools und Bahnen angegeben werden, ist übrigens nicht
vorgeschrieben. Meist sieht man jedoch die in Abbildung 1 und Abbildung 7 gewählten
Varianten, wo die Namen links neben bzw. bei vertikaler Darstellung über den Pools
bzw. Bahnen dargestellt werden. Die Bezeichnung eines Pools wird meist durch eine
Linie abgetrennt. Dagegen stehen die Bezeichnungen von Bahnen direkt in den Bahnen.
Eine Trennlinie wird bei der Bezeichnung einer Bahn nur verwendet, wenn diese noch
weiter unterteilt ist.
2112 Konversationen
12.1 Konversationsdiagramm
Ein Konversationsdiagramm bietet eine Übersicht darüber, welche Partner eines be-
stimmten Anwendungsgebiets welche Aufgaben gemeinsam abwickeln. So sieht man in
Abbildung 168 drei Konversationen (engl. „Conversation“). Beim Abwickeln eines An-
zeigenauftrags arbeiten ein Kunde, eine Werbeagentur und mehrere Grafiker zusam-
men. Kunde und Werbeagentur können aber auch gemeinsam eine Werbekampagne
durchführen, wobei sie zusätzlich noch mit mehreren Medien zusammenarbeiten. Auch
ein Grafiker kann noch an einer anderen übergreifenden Aktivität beteiligt sein: Zu-
sammen mit einem Verlag wickelt er Aufträge für Illustrationen ab.
Werbekampagne
durchführen
Kunde Medium
Anzeigenauftrag
Werbeagentur
abwickeln
Auftrag für
Illustrationen
abwickeln
Grafiker Verlag
Abbildung 168: Konversationsdiagramm
Realisiert wird eine Konversation letztlich durch eine Folge von Nachrichtenflüssen. Wie
diese im Detail aussieht, kann z. B. in einem Choreographie- oder Kollaborations-
diagramm modelliert werden. So wird der Nachrichtenfluss, der der Konversation „An-
zeigenauftrag abwickeln“ zugrunde liegt, durch das Kollaborationsdiagramm in
Abbildung 159 sowie durch das Choreographiediagramm in Abbildung 160 beschrie-
ben. Ein Kollaborations- oder Choreographiediagramm muss aber nicht unbedingt
genau eine Konversation spezifizieren, es können z. B. auch die Nachrichtenflüsse von
zwei oder mehr Konversationen in einem Diagramm zusammengefasst werden.
14912.2 Korrelation von Nachrichten
Die Nachrichtenflüsse, die zu einer Konversation gehören, hängen stets inhaltlich mit-
einander zusammen. So beziehen sich die Nachrichten, die bei einer einmaligen Durch-
führung der Konversation „Anzeigenauftrag abwickeln“ ausgetauscht werden, alle auf
den gleichen Anzeigenauftrag. Die Korrelation, d. h. die Zuordnung der Nachrichten
kann dann etwa über die Auftragsnummer erfolgen. Erhält z. B. der Kunde im Rahmen
dieser Konversation eine Anzeige mit der Bitte um Freigabe, so kann er mit Hilfe der in
der betreffenden Nachricht angegebenen Auftragsnummer feststellen, zu welchem
Auftrag – und damit zu welcher Prozessinstanz – diese Nachricht gehört. Die Nach-
richten einer Konversation verfügen immer über eine gemeinsame Korrelation.
Die Verbindung einer Konversation mit einem Teilnehmer wird Konversationsbe-
ziehung genannt (engl. „Conversation Link“). Eine Konversation hat immer Beziehun-
gen zu zwei oder mehr Teilnehmern.
Es können auch mehrere Partner desselben Typs an einer Konversation beteiligt sein.
So sind an „Anzeigenauftrag abwickeln“ jeweils ein Kunde und eine Werbeagentur
beteiligt, aber mehrere Grafiker. Der Pool „Grafiker“ enthält entsprechend ein Mehrfach-
symbol. Aus dem Mehrfachsymbol geht die allerdings nicht ganz eindeutig hervor, bei
welchen Konversationen mehrere Teilnehmer desselben Typs beteiligt sind. So ist der
Teilnehmer „Grafiker“ auch mit der Konversation „Auftrag für Illustrationen ab-
wickeln“ verbunden. Es könnte z. B. sein, dass dieser jeweils nur immer ein Grafiker
Kunde
Änderungs- Freigabe
Anfrage wünsche Absage
Anzeige
Angebot Auftrag
Werbeagentur
Grafikauftrag
abwickeln
Grafiker
Abbildung 169: Konversationsdiagramm für Unterkonversation „Anzeigenauftrag abwickeln“
150beteiligt ist. Das lässt sich hier nicht eindeutig feststellen. Solche Informationen muss
man ggf. aus detaillierteren Kollaborations- oder Choreographie-Diagrammen entneh-
men.
12.3 Hierarchisierung von Konversationen
Neben einfachen Konversationen können auch Unterkonversationen (engl. „Sub-
Conversations“) verwendet werden. Ähnlich wie ein Unterprozess wird eine Unter-
konversation mit einem „+“-Zeichen gekennzeichnet und kann durch ein weiteres
Konversationsdiagramm näher beschrieben werden. In dem Diagramm der Unterkon-
versation können nur die Teilnehmer verwendet werden, zu denen im übergeordneten
Diagramm eine Konversationsbeziehung besteht.
Abbildung 169 zeigt ein detailliertes Konversationsdiagramm für die Unterkonversation
„Anzeigenauftrag abwickeln“. Wie man hier sieht, kann man in ein Konversations-
diagramm auch direkt Nachrichtenflüsse einzeichnen. Im Gegensatz zu einem Kollabo-
rationsdiagramm dürfen aber keine Prozesse in den Pools oder Choreographien zwi-
schen den Pools dargestellt werden.
Hier sind die Nachrichtenflüsse eingezeichnet, die sich alle auf denselben Auftrag be-
ziehen. Genau genommen beziehen sie sich auf dieselbe Anfrage. Zu Beginn liegt noch
kein Auftrag vor, und es wird auch nicht zu jeder Anfrage ein Auftrag erteilt. Daher ist
die Anfrage der gemeinsame Bezugspunkt für die Korrelation der Nachrichtenflüsse.
Neben den direkt eingezeichneten Nachrichten zwischen Kunde und Werbeagentur ist
zwischen Werbeagentur und Grafiker noch die Konversation „Grafikauftrag abwickeln“
eingezeichnet. Zwar beziehen sich alle Nachrichtenflüsse dieser Konversation ebenfalls
auf dieselbe Anfrage, doch genügt diese Information noch nicht, um alle eingehenden
Nachrichten in der Werbeagentur richtig zuzuordnen. Es können nämlich Verfügbar-
keitsanfragen an mehrere Grafiker gesendet werden. Geht nun eine Verfügbarkeits-
meldung in der Werbeagentur ein, soll diese der richtigen Verfügbarkeitsanfrage zuge-
ordnet werden. Zur Korrelation dieser Nachrichten ist daher eine weitere Information
Werbeagentur
Auftrag
Verfügbar-
Verfügbarkeits- für Grafik
keits
anfrage Grafiker
meldung
Grafiker
Abbildung 170: Kollaborationsdiagramm für Konversation „Grafikauftrag abwickeln“
151Verfügbar- Auftrag für
keitsanfrage Grafiker
Werbeagentur Werbeagentur
Verfügbarkeit
stellen Grafik
stellen
abfragen
Anfrage erstellen
Anfrage
lassen
Grafiker
Grafiker
Verfügbar-
Grafik
keitsmeldung
Abbildung 171: Choreographiediagramm für Konversation „Grafikauftrag abwickeln“
notwendig, z. B. die Nummer der Verfügbarkeitsanfrage. Daher wird hier für die
Nachrichtenflüsse zwischen Werbeagentur und Grafiker eine eigene Konversation
verwendet.
Der Nachrichtenaustausch dieser Konversation kann nun wieder mit Hilfe eines Kolla-
borationsdiagramms (Abbildung 170) oder eines Choreographiediagramms modelliert
werden (Abbildung 171). Selbstverständlich ist es auch möglich, die Nachrichtenflüsse
der gesamten Unterkonversation in einem Diagramm darzustellen, (Abbildung 159 bzw.
160 im vorhergehenden Kapitel).
Ebenso wie Unterprozesse dürfen auch Unterkonversationen aufgeklappt dargestellt
werden, d. h. das Sechseck wird größer gezeichnet, und die detaillierte Konversation
wird in seinem Inneren angezeigt. Allerdings ist es grafisch nicht ganz einfach, etwa die
Inhalte von Abbildung 169 in eine aufgeklappte Unterkonversation in Abbildung 168
einzufügen. Auch die BPMN-Spezifikation enthält leider keine Beispiele für aufge-
klappte Unterkonversationen.
12.4 Aufruf von Kollaborationen und globalen
Konversationen
Wie bei Prozessen und Choreographien ist es auch in Konversationsdiagrammen mög-
lich, anderswo definierte Konversationen aufzurufen. Hierfür können einerseits unab-
hängig von dem konkreten Konversationsdiagramm definierte, globale Konversationen
aufgerufen werden, andererseits Kollaborationen. Die aufrufende Konversation wird
mit einem dicken Rand dargestellt (Abbildung 172).
Da die aufgerufenen Konversationen an anderer Stelle definiert sind, müssen die zuge-
ordneten Teilnehmer sowie ggf. die Korrelationsinformationen gegebenenfalls auf die
Teilnehmer und Korrelationsinformationen des Diagramms abgebildet werden, aus
dem heraus der Aufruf stattfindet. Dies ist aber hauptsächlich ein Thema für die Auto-
matisierung unternehmensübergreifende Prozesse. Bei rein fachlichen Modellen ergibt
15214 BPMN-Modellierungsmuster
Es gibt zahlreiche Sachverhalte bei der Prozessmodellierung, die in ähnlicher Form
immer wieder vorkommen. Modellierungsmuster stellen Vorschläge dar, wie sich sol-
che wiederkehrenden Fälle sinnvoll modellieren lassen. Anstatt jedes Mal selbst über-
legen zu müssen, wie sich eine bestimmte Fragestellung gut abbilden lässt, kann man an
vielen Stellen auf vorhandene und bewährte Lösungen zurückgreifen. Nutzen die
Modellierer eines Unternehmens alle denselben Musterkatalog, so wird erreicht, dass
gleiche Sachverhalte auch immer gleich dargestellt werden. Dies erhöht die Verständ-
lichkeit der Modelle.
Es empfiehlt sich daher, eine solche Sammlung an Mustern aufzubauen und kontinu-
ierlich um Muster zu erweitern, die bei der täglichen Modellierung neu gefunden wer-
den. Je nach Anwendungsbereich und Modellierungszweck kann es sich um ganz un-
terschiedliche Muster handeln.
Im Folgenden werden einige allgemeine Muster für Fragestellungen vorgestellt, die in
vielen Unternehmen eine Rolle spielen dürften. Ein Großteil dieser Muster entstand in
Zusammenarbeit mit BPMN-Trainern der Firma AXON IVY AG.
14.1 Vier Augen-Prinzip
Das Vier Augen-Prinzip wird für wichtige Dokumente, Briefe, Angebote etc. angewandt.
Diese dürfen nicht von einer einzigen Person erstellt und freigegeben oder versandt
werden. Die Prüfung durch einen zweiten Mitarbeiter soll sicherstellen, dass Fir-
menrichtlinien eingehalten, Fehler rechtzeitig entdeckt und Betrugsversuche verhindert
werden.
Die Anwendung dieses Prinzips in einem Prozess lässt sich recht einfach modellieren
(Abbildung 175). Nach dem Verfassen des betreffenden Dokuments durch den Autor
wird es von einem anderen Mitarbeiter geprüft. Ist dieser mit dem Inhalt einverstanden,
Dokument Dokument
Autor
Dokument erstellen
verfassen überarbeiten
Nein
Mitarbeiter
Anderer
Dokument Ja
prüfen
Dokument Dokument
okay? freigegeben
Abbildung 175: Vier Augen-Prinzip
157so ist das Dokument anschließend freigegeben. Ist das Dokument hingegen nicht okay,
so wird es vom Autor überarbeitet und anschließend erneut geprüft.
Statt eines Dokuments kann es sich bei dem erstellten Objekt auch um ein Angebot, einen
Vertrag, eine Berechnung oder ähnliches handeln.
Wichtig bei diesem Muster ist, dass die beiden durch die Lanes repräsentierten Rollen
tatsächlich von unterschiedlichen Personen wahrgenommen werden müssen. Während
es bei vielen anderen Prozessen durchaus in Ordnung ist, wenn ein und dieselbe Person
einmal zwei oder mehrere Rollen in Personalunion wahrnimmt, muss dies hier ausge-
schlossen werden. Daher wurde die untere Lane explizit mit „Anderer Mitarbeiter“
bezeichnet. Werden bei der Anwendung des Musters in einem konkreten Prozess andere
Lane-Bezeichnungen verwendet (z. B. „Entwickler“ und „Qualitätsprüfer“), kann man
ggf. in einer Anmerkung notieren, dass es sich um unterschiedliche Personen handeln
muss.
Bei genauer Betrachtung kann man an dem Modell in Abbildung 175 bemängeln, dass
es keine Abbruchmöglichkeit vorsieht. Können sich der Autor und der andere Mitarbei-
ter nicht einigen, so werden die Arbeitsschritte „Dokument prüfen“ und „Dokument
überarbeiten“ in einer endlosen Schleife immer wieder durchlaufen. In der Praxis wird
man diese irgendwann abbrechen – auch wenn es im Prozessmodell nicht explizit be-
schrieben ist.
Möchte man es genauer modellieren, so kann man am verzweigenden Gateway einen
dritten Ausgang modellieren, der ebenfalls zu einem Endereignis führt, das den erfolg-
losen Abschluss des Prozesses markiert. Dies ist in Abbildung 176 dargestellt. Hier trifft
der andere Mitarbeiter bei der Prüfung des Dokuments ggf. die Entscheidung, das
Dokument komplett zu verwerfen. Genauso könnte man aber auch vorsehen, dass der
Autor entscheiden kann, ob er das Dokument ggf. verwerfen möchte. Dann müsste man
Dokument Dokument
Autor
verfassen überarbeiten
Nein, zu überarbeiten
Dokument erstellen
Dokument
Dokument okay? Nein, abgelehnt
Anderer Mitarbeiter
prüfen
Dokument
Ja
verworfen
Dokument
freigegeben
Abbildung 176: Vier Augen-Prinzip mit Abbruchmöglichkeit
158nach „Dokument überarbeiten“ eine weitere Verzweigung zum Endereignis „Dokument
verworfen“ einfügen.
Das Muster lässt sich leicht erweitern. So könnte man aus dem Vier Augen- ein Sechs
Augen-Prinzip machen, indem man noch eine Prüfung durch einen dritten Mitarbeiter
hinzufügt. Diese zweite Prüfung kann parallel zur ersten Prüfung durchgeführt werden,
wie dies im Muster „Parallele Prüfungen“ (Kapitel 14.4) beschrieben wird. Auch kann
man für den Fall, dass sich Autor und Prüfer nicht einig werden, zu einem von einer
dritten Person auszuführenden Entscheidungs-Task verzweigen.
14.2 Entscheidung durch Unterprozess
Häufig hat ein Unterprozess mehrere mögliche Ergebnisse, die anschließend im über-
geordneten Prozess zu unterschiedlichen Pfaden führen. Durch das Muster „Entschei-
dung durch Unterprozess“ wird der Bezug zwischen der im Unterprozess getroffenen
Entscheidung und dem gewählten Pfad deutlich. Eine Anwendung dieses Musters
findet sich bereits bei der Besprechung von Unterprozessen in Kapitel 7.1 (Abbildung
107).
Im Unterprozess kann ein beliebiger Ablauf modelliert werden. Der in Abbildung 177
dargestellte Ablauf innerhalb von „Antrag evaluieren“ ist nur beispielhaft zu sehen.
Wichtig für das Muster ist nur, dass jedes mögliche Ergebnis des Unterprozesses durch
ein eigenes Endereignis dargestellt wird. Gleichartige Ergebnisse werden jeweils zu
einem Endereignis zusammengefasst. So führen im Unterprozess in Abbildung 177 die
beiden „Nein“-Zweige der Gateways zu einem gemeinsamen Endereignis „Antrag
abgelehnt“. Alle Endereignisse sind am rechten Rand des Unterprozesses platziert.
Antrag evaluieren
Antrag
angenommen
Antrag formal Ja Antrag Ja
Antrag
in Ordnung? inhaltlich in ange-
Änderungen Mit
Antrag Antrag Ordnung? nom-
Ja erforderlich Auf-
formal inhaltlich men?
lagen
prüfen prüfen
Antrag
Nein Nein mit Auflagen
angenommen Nein
Antrag
abgelehnt
Abbildung 177: Zu jedem Endereignis des Unterprozesses gibt es einen Pfad am exklusiven
Gateway.
159Über den Autor
Thomas Allweyer studierte Ingenieurwissenschaften an der Universität Stuttgart und
der Brunel University in London. Er promovierte am Institut für Wirtschaftsinformatik
an der Universität des Saarlandes in Saarbrücken zum Thema „Adaptive Geschäftspro-
zesse“. Danach war er bei IDS Scheer (heute Software AG) als Produktmanager im Be-
reich der ARIS-Modellierungswerkzeuge und als Berater tätig. Es folgte eine Tätigkeit
als Prozessmanager bei emaro, einem Joint Venture von Deutsche Bank und SAP. Seit
2001 ist er Professor für Unternehmensmodellierung an der Hochschule Kaiserslautern.
Neben seiner Hochschultätigkeit ist er auch beratend tätig. Außerdem hält er regelmäßig
Seminare und Schulungen für namhafte Firmen, u. a. zum Thema Geschäftsprozess-
management und IT – und natürlich BPMN.
In seinem Weblog „Kurze Prozesse“ schreibt er regelmäßig über aktuelle Entwicklungen
zum Thema Geschäftsprozessmanagement (www.kurze-prozesse.de).
Weitere Bücher des Autors:
Geschäftsprozessmanagement –
Strategie, Entwurf, Implementierung, Controlling.
W3L, Herdecke 2005. ISBN 978-3-9371-3711-7
BPMS – Einführung in Business Process Management-Systeme.
BoD, Norderstedt 2014. ISBN 978-3-7357-4030-4
184Sie können auch lesen
