Steuerungssicht 2/BPMN

Jörg Krüger 

Christian Uhlig 

Geschäftsprozessmodellierung WS13/14 

4. Steuerungssicht 2 (BPMN)

Agenda 

• Einführung zu BPMN 

• Modelltyp 

• BPMN Process Diagram 

• BPMN Collaboration Diagram 

• Beispiele 

• Bewertung EPK vs BPMN 

• Daten- und Organisationsauszeichnung in BPMN 

Übung Prozessmodellierung WS13/14 

Seite 2

BPMN / Processes / Collaborations / Beispiele / Warum BPMN? / Daten & Organisation 

Die ARIS-Beschreibungssichten 

• Organisationssicht 

• Datensicht 

• Steuerungssicht 

• Funktionssicht 

• Leistungssicht 


Seite 3


BPMN Einführung (1) 

• BPMN = Business Process Model and Notation 

• Relativ junge Alternative insbesondere zu EPK-Modellen 

• Entwickelt 2002, seit 2005 Standard der Object Management Group (OMG), 

d.h. wird von einer offenen Standardisierungsinstitution gepflegt 

• Motivation 

• In der praktischen Anwendung von EPK deutlich gewordene Schwachstellen 

• Bessere Berücksichtigung einiger Anwendungsfelder, insbesondere des Software- 

Engineerings 

• EPK im Grunde ein informeller Standard, der durch einen einzigen Hersteller bzw. 

dessen Softwareimplementierung begründet wird 

• BPMN stattdessen unter Mitwirkung verschiedener Interessengruppen entwickelt 

und gepflegt 

• Im Ergebnis sind BPMN deutlich differenzierter und komplexer hinsichtlich der 

Notationselemente, aber auch ausdrucksstärker 


Seite 4


BPMN Einführung (2) 

• Aktuell BPMN Version 2.0 

• ARIS bietet eine weitreichende Unterstützung für BPMN 1.x und 2.0 

• Integration entsprechender Modelltypen und der Notation mit Adaption an ARIS- 

Methode (Objekttypen und Kantentypen) und -Sichtenkonzept 

• Integration in fortgeschrittene ARIS-Mechanismen: Semantikchecks, 

Modellgenerierung, Simulation, … 

• Wie bei EPK Funktionen, Ereignissen und Regeln als zentrale Konzepte 

• Nachfolgend werden wir die zentralen Elemente der BPMN-Modellierung 

kennenlernen und in ihren Eigenschaften zu EPK-Modellelementen abgrenzen 

• Wichtig: Wir zeigen nur einen Ausschnitt aus dem BPMN-Standard, der auf 

die aus unserer Sicht wesentlichen Teile mit einigen Blicken links und rechts 

eingeschränkt ist 


Seite 5


Modelltyp: BPMN Process Diagram 

• Ein Process-Diagramm beschreibt genau einen Prozess analog zu einer EPK 

• Die Modellelemente werden in fünf Kategorien strukturiert 

• Flow Objects: Activities, Events, Gateways 

• Connecting Objects (Kanten): Sequence Flows, Associations, Data Associations 

• Swimlanes: Lanes 

• Artifacts: Groups, Annotations 

• Data: Data Objects, Data Inputs, Data Outputs, Data Stores 


Seite 6


Elementtyp: Activity (1) 

• Activities entsprechen EPK-Funktionen und werden in ARIS über den Objekttyp 

Funktion abgebildet 

• Namenskonvention 

• Analog zu EPK Objekt + Verrichtung (z.B. "Lenkrad montieren") 

• Differenzierung von Activities in Tasks und Subprocesses 

• Tasks sind elementare Activities, d.h. solche Aktivitäten, für die keine 

weitere Zerlegung modelliert wird 

• Grafische Darstellung: 

• Subprocesses sind zusammengesetzte (komplexe) Activities, d.h. sie 

enthalten ihrerseits eine genauere Beschreibung in Form eines BPMN- 

Prozesses; sie werden hinsichtlich ihrer Darstellung wiederum differenziert in 

collapsed und expanded subprocesses 


Seite 7



• Collapsed Subprocess: Der modellierte Unterprozess ist nicht sichtbar; dies 

entspricht im wesentlichen EPK-Hinterlegungen in ARIS 

Grafische Darstellung: 

EPK-Modellierung 

• Expanded Subprocess: Der modellierte Unterprozess wird direkt im 

(entsprechend vergrößerten) Activity-Symbol dargestellt 

Grafische 

Darstellung: 


Keine Analogie 

• Subprocesses werden in ARIS analog zu EPKs durch Hinterlegungen 

umgesetzt; die Unterprozesse werden nur in den hinterlegten Modellen 

bearbeitet, die direkt im Symbol dargestellten Elemente sind nicht editierbar 


Seite 8



• Ad-Hoc Process 

• Besondere Art Subprocess, die den Kontrollfluss ganz oder teilweise undefiniert lässt 

• Semantik: Abgesehen von definierten Kontrollflüssen wird die Reihenfolge und 

Häufigkeit der Aktivierung der enthaltenen Flow Objects dynamisch zur Laufzeit des 

Prozesses entschieden 

• Anwendungsbereich: z.B. kreative oder Management-Prozesse, bei denen 

bestimmte Schritte häufiger und in sehr dynamischer Reihenfolge ausgeführt 

werden, so dass eine ex ante Standardisierung nicht möglich oder unangemessen ist 




Seite 9



• Loop-Activity: Eine Activity (Task oder Subprocess) 

kann explizit als Schleife deklariert wird, die anhand 

einer Bedingung oder eines 

Zählers mehrfach ausgeführt 

wird 


• Multi-Instance-Activity: Beim Ausführen wird eine 

Menge von Instanzen ("Threads") dieser Activity 

(Task oder Subprocess) erzeugt, die parallel (vertikale 

Markierungslinien) oder nacheinander (horizontale 

Markierungslinien) ausgeführt werden. 

Anwendungsfall: z.B. gleichartige Verarbeitung 

einer Menge von 

Datenobjekten 


Keine Analogie; 

Nachbildung per 

Schleife notwendig, 

Parallelität kann 

nicht modelliert 

werden 


Seite 10



• Konventionen 

• Schleifen 

• Grundsätzlich kann eine Schleife entweder als Loop Activity oder analog zu EPKs 

(d.h. Entscheidungsfunktion zur Schleifensteuerung + Schleifenrumpf und 

Rücksprung) modelliert werden 

• Aber: Umfasst der Schleifenrumpf nur 1 bis 4 Funktionen, ist grundsätzlich eine 

Loop Activity (Task oder Subprocess, Loop-Type "Standard Loop") zu verwenden 

• Für einen Schleifenrumpf mit nur einer Funktion ist ein Loop Task zu modellieren 

• Für einen Schleifenrumpf mit 1 bis 4 Funktionen ist ein Subprocess zu modellieren, der 

expanded im Oberprozess dargestellt wird 

• Für einen Schleifenrumpf mit mehr als 4 Funktionen ist ein Subprocess zu modellieren, 

der nach eigenem Ermessen collapsed oder expanded im Oberprozess dargestellt wird 

• Bei Loop Activities ist über das Attribut "Loop Condition" (Gruppe "BPMN 2.0- 

Attribute" -> "Loop Characteristics" -> "Standard Loop Attributes") immer eine 

Schleifenbedingung anzugeben 

• Die Bedingung soll formulieren, wann die Schleife weiterläuft (z.B. "Weiterer Kunde 

zu verarbeiten?") oder im Falle einer Schleife über Datenobjekte die Menge der 

Datenobjekte charakterisieren (z.B. "für alle Kunden") 


Seite 11



• Konventionen (Fs.) 

• Schleifen (Fs.) 

• Über das Attribut "Test before" (Gruppe "BPMN 2.0-Attribute" -> "Loop 

Characteristics" -> "Standard Loop Attributes") kann eine kopf- (Test before 

aktiviert) oder fußgesteuerte Schleife (Test before deaktiviert) definiert werden. Wird 

dieses Attribut nicht gepflegt, wird implizit von einer kopfgesteuerten Schleife 

ausgegangen oder von einer Schleife, für die diese Frage keine Bedeutung hat. 

• Sowohl Tasks als auch Subprocesses können Loop Activities sein; Tasks kommen 

zum Einsatz, wenn der Schleifenrumpf nur eine (elementare) Funktion aufweist 

• Ad-Hoc-Prozesse und Multi-Instance-Activities sollen nicht verwendet werden 


Seite 12


Elementtyp: Event (1) 

• Differenzierung nach Flow Dimension: Start, Intermediate und End Events 



einfacher Kreis = Start, doppelter Kreis = Intermediate, dicker Kreis = End 

Die Farben sind lediglich ein ARIS-Feature 

• Ereignisnamen sind optional und werden entsprechend häufig weggelassen 

• Weitere Differenzierung nach Gegenstand des Ereignisses (Type Dimension): 

None, Message, Timer, Error, Cancel, ... 

• None Event: Ereignis ohne Type (entsprechend leeres Symbol, z.B. ) 



Keine Analogie bzw. informell 

über die Ereignisbezeichnung 

abbildbar 


Seite 13



• Differenzierung nach Ursache / Wirkung: Catching und Throwing Events 

• Catching Events: Start Events müssen und Intermediate Events können einen 

Trigger haben, den sie "catchen". Das Typsymbol ist bei Catching Events nicht 

gefüllt. 


• Throwing Events: End Events können ein Result haben, das sie "throwen". 

Intermediate Events können einen Trigger haben, den sie "throwen". Das 

Typsymbol ist bei Throwing Events gefüllt. 






• Anders als in EPKs sind Zwischenereignisse nicht zwingend (Trivialereignisse 

werden vermieden). Außerdem dürfen Ereignisse auch auf Ereignisse folgen. 

• Start- & Endereignisse dürfen fehlen, in diesem Fall gelten bestimmte Regeln, 

wo der Prozess beginnt 


Seite 14



Ereignisübersicht 

Beispiele 

• Start-Ereignis, das durch eine Nachricht 

ausgelöst wird 

(Start-Event, Catching Trigger, Message) 

• Zwischenereignis, das durch eine Zeit ausgelöst 

wird 

(Intermediate, Catching Trigger, Time) 

• Zwischenereignis, das eine Nachricht versendet 

(Intermediate, Throwing Trigger, Message) 

• Endereignis, das einen Fehler auslöst 

(End, Throwing Result, Error) 


Seite 15



• Beispiel im Zusammenhang 

Ein Prozess, a) der durch eine Zeit ausgelöst wird, b) einen elementaren Schritt 

ausführt, c) anschließend auf eine Nachricht wartet, d) nach Eintreffen der 

Nachricht einen zweiten Schritt ausführt und e) schließlich ohne Erzeugen 

eines besonderen Results abschließt. 

• Ereignisse können in einigen Fällen mit Tasks konsolidiert werden; so "enthält" 

z.B. ein Send Task implizit ein Ereignis, das eine Nachricht auslöst, und ein 

Receive Task ein Ereignis, das eine Nachricht empfängt. 

Beispiel mit 

Receive Task 


Seite 16



• Boundary Events: Bestimmte Ereignisse können auf Activity-Rändern platziert 

werden, um explizit Ausnahmen zu modellieren (z.B. Sonderfälle, 

Fehlersituationen usw.) und darauf zu reagieren 

• Beispiel: Fehlerereignis auf dem Rand eines Subprocess, fängt Fehler im 

Unterprozess ab 


Seite 17




• An Ereignistypen sollen nur folgende verwendet werden (die Auswahl erfolgt beim 

Anlegen oder über das BPMN-Kontextmenü des Events): 

• Message: Das Ereignis entsteht durch Empfang einer Nachricht oder bildet selber den 

Versand einer Nachricht ab 

• Timer: Das Ereignis bildet das Eintreten eines Zeitpunktes oder das Ablaufen eines 

Zeitraums ab 

• Conditional: Das Ereignis ist durch das Eintreten einer bestimmten Bedingung 

gekennzeichnet (z.B. "Reklamationsrate > 5%"); dazu sollen keine Kriterien wie z.B. 

"Lieferung eingetroffen" gehören, die einen inhärent booleschen Zustand aufweisen, der 

sich nach dem Eintreten nicht mehr ändert 

• None: Alle übrigen Ereignisse… 

• Für Message Events soll Throwing und Catching unterschieden werden (die 

Auswahl erfolgt beim Anlegen oder über das BPMN-Kontextmenü des Events) 

• Ereignisse sollen nicht direkt auf Ereignisse folgen 


Seite 18



• Konventionen (Forts.) 

• Trivialereignisse (d.h. Zwischenereignisse, die lediglich den Übergang zwischen zwei 

Funktionen modellieren) können weggelassen werden, in Sequenzen dürfen also 

Funktionen prinzipiell auf Funktionen folgen 

• Start- und Endereignisse sind zu modellieren; analog zu EPKs soll jeder 

Prozesspfad mit min. einem Ereignis anfangen und mit min. einem Ereignis enden 

• Die Ereignisbenennung erfolgt in Abhängigkeit vom Ereignistyp: 

• Message: Liegt ein eingehender Message Flow mit benannter Message vor (siehe später 

zu Collaboration), erfolgt keine Benennung; ansonsten gibt die Benennung analog zu EPK- 

Ereignissen Auskunft über die empfangene Nachricht (z.B. "Auftrag erhalten") 

• Timer: Die Benennung soll den Zeitpunkt bzw. Zeitraum des Ereigniseintritts 

charakterisieren (z.B. "8 Uhr" oder "24h verstrichen"). Die eigentlich vorgesehenen BPMN- 

Attribute "Timedate" und "Timecycle" sollen nicht gepflegt werden. 

• Conditional: Die Benennung soll die Eintrittsbedingung charakterisieren (z.B. 

"Reklamationsrate > 5%"). Das eigentlich vorgesehene BPMN-Attribut "Condition" soll 

nicht gepflegt werden. 

• None: Benennung analog zu EPK-Ereignissen (z.B. "Lieferung eingetroffen"); soweit 

Trivialereignisse modelliert werden, brauchen diese nicht benannt zu werden 


Seite 19


Gateways in BPMN 

• Gateways in BPMN entsprechen prinzipiell EPK-Regeln (XOR, OR, AND) 

• Statt durch Ereignis(-Namen) wie in EPKs werden Bedingungen 

gegebenenfalls durch Kanten(-Attribute) repräsentiert 

• Gateways als Entscheidungsfunktionen 

• XOR/OR-Gateways können in manchen Fällen die Rolle von 

Entscheidungsfunktionen übernehmen und damit eine explizite 

Entscheidungsfunktion wie bei EPKs unnötig machen 

• Gateways sollen allerdings nur dann Entscheidungen im Sinne einer Funktion 

treffen, wenn diese deterministischer Natur und auf Basis von Daten möglich sind, 

die bei Ausführung des Gateways verfügbar sind (data-based decision) und nicht 

durch das Gateway erhoben werden müssten. 

• Damit könnte ein Gateway z.B. die Entscheidung "Kundenzahlungsziel = 0?" treffen, 

allerdings keine Entscheidung wie "Reklamationswunsch des Kunden 

entsprechen?". In letzterem Fall liegt die Entscheidung bei einer vorgeschalteten 

Activity und das Gateway dient nur der Abbildung der Entscheidungsergebnisse. 


Seite 20


Elementtyp: Exclusive Gateway (1) 

• Data-Based Exclusive Decision and Merging (Exclusive Gateway) 

• Verzweigung in mehrere Pfade, wobei genau einer ausgewählt wird (entspricht 

einem EPK XOR-Split) 



• Zusammenführung mehrerer Pfade, wobei der Kontrollfluss zur Laufzeit von 

genau einem eintrifft (entspricht EPK XOR-Join) 




Seite 21



• Kanten der abgehenden Sequence Flows entsprechen Bedingungen 

(Conditional Sequence Flows), zu Wahr ausgewertete Bedingung markiert 

Zielpfad 


• Beispiel: 

• Für den Fall, dass keine Kantenbedingung zutrifft, kann eine 

Defaultkante (Default Sequence Flow) festgelegt werden. 

• Ein XOR-Merge ist das Standardverhalten, wenn kein 

Gateway angegeben wird 

= 


Seite 22



• Beispiel: Gateway als (datenbasierte) Entscheidungsfunktion 


• In diesem Fall weist das Gateway eine Bezeichnung auf, der dem Namen einer 

entsprechenden Entscheidungsfunktion entspricht 


Seite 23




• Gateways dürfen in den beschriebenen Fällen die Rolle von 

Entscheidungsfunktionen übernehmen; sie sind dann entsprechend zu benennen. 

Bildet ein Gateway das Entscheidungsergebnis einer vorgeschalteten Activity ab, so 

soll es nicht benannt werden. 

• Gateways in der Rolle von Entscheidungsfunktionen dürfen vermieden und 

grundsätzlich durch vorgeschaltete Activities gesteuert werden. 

• Eine Decision muss min. 2 ausgehende Sequence Flows aufweisen, analog ein 

Merge min. 2 eingehende Sequence Flows. 

• Die ausgehenden Sequence Flows einer Decision müssen Conditional oder Default 

Sequence Flows sein (Auswahlattribut "Sequence Flow Condition", Gruppe "BPMN 

2.0-Attribute"). Für jeden Conditional Sequence Flow ist das Attribut "Condition 

Expression" (Gruppe "BPMN 2.0-Attribute") mit der entsprechenden 

Kantenbedingung zu pflegen. 

• Das leere Gateway-Symbol als Variante des XOR-Gateways soll nicht verwendet 

werden. 


Seite 24


Elementtyp: Inclusive Gateway (1) 

• Data-Based Inclusive Decision and Merging (Inclusive Gateway) 

• Analog zu Exclusive Gateways, allerdings können mehrere Pfade, deren 

Bedingungen zu Wahr auswerten, ausgewählt werden 

• Entspricht EPK OR-Split/Join 



• Analog zum Exclusive Gateway kann für den Fall, 

dass keine Kantenbedingung passt, eine 

Defaultkante festgelegt werden 


Seite 25



• Auf das Verteiler-Gateway (Decision) kann verzichtet werden; stattdessen 

können die Conditional Sequence Flows direkt von einer vorgeschalteten 

Entscheidungsactivity ausgehen und werden in diesem Fall mit einer Raute 

dargestellt. 


= 


Seite 26




• Soweit anwendbar gelten die gleichen Konventionen wie für Exclusive Gateways 

• Direkt von Activities ausgehende Conditional Sequence Flows zur Vermeidung eines 

Inclusive Gateways sollen nicht verwendet werden 


Seite 27


Elementtyp: Parallel Gateway (1) 

• Parallel Forking and Joining (Parallel Gateway) 

• Alle ausgehenden Pfade werden aktiviert, analog zu EPK AND-Verteilern 



• Es werden normale und keine Conditional Sequence Flows verwendet 

• AND-Fork ist Standardverhalten, wenn kein Gateway angegeben wird 

= 


Seite 28


Elementtyp: Parallel Gateway (2) 


• Parallel Gateways sollen nicht benannt werden 

• Ein Fork muss min. 2 ausgehende Sequence Flows aufweisen, analog ein Join min. 

2 eingehende Sequence Flows 

• Die ausgehenden Sequence Flows einer AND-Fork müssen normale Sequence 

Flows sein, weder ist ein anderer Typ (Conditional oder Default) auszuwählen noch 

eine Bedingung anzugeben 

• Die Darstellung von AND-Forks ohne Gateway soll nicht verwendet werden 


Seite 29


Elementtyp: (Exclusive) Event Gateway (1) 

• Event-Based Decision statt Data-Based Decision: Anstelle von Bedingungen an 

den Kanten werden an dieser Stelle im Prozess erwartete Ereignisse zur 

Auswahl des Pfades genutzt 

• Der Prozess wird mit dem ersten eintretenden Ereignis aus der 

Nachfolgermenge fortgesetzt 

• Nur Decision/Split, keine Join/Merge-Variante 



• Als Ziele sind ausschließlich Intermediate 

Events der Typen Message, Signal, Timer, Conditional 

und Multiple zulässig, außerdem Receive Tasks 

(entsprechend Message Events) 

Aber: Die EPK sagt aus, dass 

genau eines der Ereignisse 

ausgelöst wird; der Aspekt, dass 

mehrere Ereignisse ausgelöst 

werden können, von denen das 

erste zur Auswahl genutzt wird, 

kann nicht modelliert werden. 


Seite 30



• Beispiel: Ein Angebot wird zugestellt, anschließend wird auf den Auftrag des 

Kunden gewartet. Trifft dieser nicht binnen einer Woche ein, wird das Angebot 

zurückgezogen. 


Prinzipiell darstellbar, aber umständlicher, 

ungenauer und informeller 


Seite 31




• Ein Event Gateway hat nie Entscheidungsfunktion (die Entscheidung fällt ja "von 

selbst" per Eintreten eines Ereignisses) und soll daher nicht benannt werden. 

• Ein Event Gateway muss min. 2 ausgehende Sequence Flows aufweisen, die jeweils 

in einem Intermediate Event des Typs Message, Timer oder Conditional münden; 

andere Ereignistypen oder Receive Tasks sollen nicht verwendet werden. 

• Die ausgehenden Sequence Flows eines Event Gateways müssen normale 

Sequence Flows sein, weder ist ein anderer Typ (Conditional oder Default) 

auszuwählen noch eine Bedingung anzugeben 


Seite 32


Modelltyp: BPMN Collaboration Diagram 

• Collaboration-Diagramme dienen der Darstellung mehrerer Prozesse (interne 

und/oder externe) im Zusammenspiel; dabei wird zusätzlich zum von EPK- und 

BPMN-Prozessen bereits bekannten Kontrollfluss der Nachrichtenfluss 

modelliert, d.h. welche Nachrichten in welcher Richtung ausgetauscht werden. 

Dabei kann über Nachrichten synchronisiert werden, d.h. ein Prozess kann 

explizit auf eine bestimmte Nachricht warten 

• Zusätzlich zu den vom Process-Diagramm bekannten Objekten sind Message 

Flows (Connection Objects) und Pools (Swimlanes) vorgesehen 

• Die Modellierung von Collaborations im Allgemeinen und des 

Nachrichtenflusses im Speziellen sind wesentliche und wichtige BPMN- 

Merkmale; es existieren keine vergleichbaren EPK-Analogien 


Seite 33

Pool 


Elementtyp: Pool (1) 

• Pools werden verwendet, um unterschiedliche Prozesse abzugrenzen; ein Pool 

repräsentiert jeweils genau einen Teilnehmer an einer Collaboration bzw. 

typischerweise einen Prozess aus Flow Objects und Sequence Flows (der 

Inhalt des Pools stellt also prinzipiell ein Process-Diagramm dar) 


• Ein Pool kann leer sein („black box“), wenn zwar ein Teilnehmer an einer 

Collaboration modelliert werden soll (z.B. der Kunde), seine internen Abläufe 

jedoch unbekannt oder für den Prozess unwichtig sind 

• Die Benennung ist flexibel und kann beispielsweise der Prozessbezeichnung 

oder einer organisatorischen Einheit folgen 


Seite 34



• Die Kommunikation und Synchronisierung zwischen Pools findet per Message 

Flows statt; Sequence Flows dürfen Poolgrenzen nicht überschreiten. 

• Beispiel-Collaboration: 


Seite 35




• Prozesse, an denen der Kunde oder eine andere externe Instanz per 

Nachrichtenaustausch beteiligt ist, sind immer als Collaborations zu modellieren 


Seite 36


Elementtyp: Message / Message Flow (1) 

• Ein Message Flow repräsentiert den gerichteten Austausch einer Nachricht 

zwischen zwei Teilnehmern einer Collaboration bzw. zwei Prozessen 


• ARIS modelliert einen Message Flow durch ein Message-Objekt, zu dem vom 

Sender eine Kante und von dem zum Empfänger eine Kante gezogen werden 

• Message Flows verbinden grundsätzlich zwei verschiedene Pools; dabei kann 

der Message Flow sowohl auf der Sende- als auch auf der Empfangsseite 

entweder direkt an ein Objekt des Pools (Event oder Activity) oder nur an den 

Rand des Pools angebunden werden (damit ohne Angabe des Events oder der 

Activity, die die Nachricht konkret sendet bzw. empfängt). 


Seite 37


Elementtyp: Message / Message Flow (2) 


• Ist der Pool eine "black box", soll die Kante zur Message am Poolrand enden, 

ansonsten ist sie direkt zum sendenden/empfangenen Objekt (Event oder Activity) 

zu ziehen 


Seite 38

Lane 


Elementtyp: Lane (1) 

• Ein Pool kann unterteilt werden in mehrere Lanes 

• Typischerweise werden mit Lanes organisatorische Strukturen abgebildet 

(Organisationseinheiten, Rollen, Systeme…); der Prozessablauf wechselt 

zwischen Lanes und drückt damit die Zuordnung von Prozessteilen zu 

Organisationseinheiten aus 

• Lanes sind als Elementtyp sowohl in Prozessen als auch in Collaborations 

zulässig; in Prozessen stehen sie allein, in Collaborations unterteilen sie Pools 


• Darstellung informell auch für EPKs bekannt, ARIS etwa bietet EPK-Swimlane- 

Diagramme an 


Seite 39


Elementtyp: Lane (2) 

• Beispiel-Collaboration mit Lanes: 


Seite 40


Beispiele EPK vs. BPMN (1) 

• Keine Trivialereignisse 

• Explizite Schleife ohne "händische" Kontrollstruktur (Rücksprung und Austritt) 

• Attribut "Loop Condition" ersetzt Funktion zur Schleifensteuerung 


Seite 41



• Keine Trivialereignisse 

• Kunde als Prozess- 

Teilnehmer explizit 

modelliert 

• Nachrichten explizit 

modelliert 

• Synchronisation bzgl. 

externer Ereignisse 

(Vertrag trifft ein 

oder Zeit abgelaufen) 

explizit modelliert 


Seite 42



• Hierarchische EPK: Unterprozess "Antrag prüfen" steuert per Ereignis den 

anschließenden Prozesszweig an 


Seite 43



• In BPMN problematisch: Im Oberprozess ist nicht bekannt, mit welchem 

Endereignis ein Subprocess endete; ein Bezug ausgehender Kanten zu den 

Endereignissen des eingebetteten Unterprozesses kann nicht hergestellt 

werden 

• In der Folge wird ein zusätzliches Gateway benötigt 


Seite 44



• Aber: Das Problem entsteht häufig durch EPK-Modellierungsgewohnheiten 

• Der konkrete Fall kann in BPMN z.B. auch leicht ohne Subprocess und 

separate Prüffunktionen modelliert werden. 

• Hier wird ausgenutzt, dass Gateways in BPMN Entscheidungsfunktion haben 

können (außerdem, dass der XOR-Join nicht modelliert werden muss). 

• Ein Unterprozess macht aus BPMN-Sicht gar keinen Sinn, da die 

Entscheidungskaskade unmittelbar und ausschließlich der Auswahl des 

anschließenden Prozesspfades im Oberprozess dient 


Seite 45


Einfacher Beispielprozess in BPMN (1) 

• Angebote für Einkauf einholen (Quelle: BPMN 1.2 Specification) 


Seite 46




Gateway als 

Entscheidungsfunktion 

(data-based decision) 


Seite 47




Expanded Subprocess & 

Loop 


Seite 48




Ausnahmebehandlung: 

Abbruch eines 

Subprocesses bzw. einer 

Schleife nach Ablauf 

einer Zeit 


Seite 49




Verzicht auf Ereignisse 

bei einfachen Sequenzen 


Seite 50


BPMN vs EPK (1) 

• Warum BPMN? 

• Zusätzliche Detailinformationen können modelliert werden: z.B. Differenzierung von 

Ereignisarten und Funktionsarten, präzise Definition der Input/Output-Daten von 

Activities (oben nicht angesprochen, von ARIS auch noch gar nicht unterstützt) 

• Interaktion zwischen Prozessteilnehmern bzw. mehreren Prozessen kann modelliert 

werden (Collaborations); Hand-Over-Vorgänge können durch Nachrichten sauber 

dargestellt und synchronisiert werden 

• Mächtige Schleifenkonstruktionen: z.B. Wiederholung von Funktionen aufgrund von 

Bedingungen, Parallelität kann explizit modelliert werden 

• Unterstützung für Ad-Hoc-Prozesse 

• Unterstützung für Exceptions: Ausstiege aus Funktionen aufgrund von Fehlern, 

Ablauf von Fristen (zeitliche Ereignisse) o.ä. können sauber modelliert werden 

• Unterstützung von transaktionalen Prozessen 

• BPMN wesentlich besser als EPK zur Unterstützung von Softwareentwicklung 

geeignet (Schnittstellensprache Business & IT) 


Seite 51



• Warum nicht BPMN? 

• Komplexer als EPK-Modellierung 

• Deutlich mehr Modellelemente 

• Viele Syntaxregeln (insbesondere aufgrund der Elementvielfalt) 

• Viele Freiheitsgrade (z.B. bezüglich Start/Endereignissen, Weglassen von 

Ereignissen, usw.) 

• Einige Modellelemente mit weder trivialer noch intuitiver Semantik, die häufig 

technikgetrieben ist 

• Vieles kann auf mehrere Weisen modelliert werden, z.B. gibt es zwei Symbole für die 

Exclusive Decision, manche Gateways können entfallen (in einigen Situationen dann 

aber doch nicht), Schleifen können per Marker oder explizit (und hier mit oder ohne 

Ereignisse) dargestellt werden usw. 

• Für Modellierungsvorhaben, die keine Softwareentwicklung zum Ziel haben, ist die 

Komplexität von BPMN ein fragwürdiger Overhead; die zusätzlichen Möglichkeiten 

werden häufig nicht benötigt oder nicht bzw. falsch genutzt 


Seite 52



• Fazit 

• BPMN wird die EPK ablösen 

• Unternehmen wollen mehrheitlich BPMN für zukünftige Projekte nutzen und sehen 

deutliche Vorteile bei der Unterstützung von IT-Projekten 

• Offener Standard: Bereits heute viele Tools 

• Inzwischen gute Unterstützung durch Taktgeber wie ARIS 

• BPMN flexibler und für einige Anwendungsfelder (Softwareentwicklung, ausführbare 

Prozesse, …) deutlich besser geeignet 

• Aber: Viele fortgeschrittene BPMN-Konstrukte werden nicht genutzt oder nicht 

verstanden – soweit diese Konstrukte nicht erforderlich sind, bieten sich EPK- 

Modellierung oder Einschränkungen von BPMN per Konvention an 

• Aber: EPK sind nach wie vor stark dominierend bei bestehenden Modellen 

• Aber: EPK scheinen zur Erlernung der GPM-Grundlagen besser geeignet, da sie auf 

wenige Elemente und Regeln beschränkt, einfach in der Anwendung und bei 

Bestandsmodellen am stärksten verbreitet sind 

• Auch denkbar: Kombination der Modelltypen (z.B. WSK/BPMN für Grobebene, EPK 

für mittlere Ebene und wieder BPMN für Detailebene) 


Seite 53


Daten & Organisationsauszeichnung in BPMN (1) 

• BPMN bietet umfassende Modellierungsmöglichkeiten hinsichtlich genutzter 

Daten oder beteiligter organisatorischer Einheiten 

• Allerdings andere Modellierungsstrategie: Statt mehrerer Modelltypen für 

Prozess, Daten und Organisation (die jeweils auf den Zweck zugeschnitten 

sind) sieht BPMN im Grunde die Verwendung eines einzigen mächtigen 

Modelltyps vor 

• Daher Schwierigkeiten und Schwächen bei der Integration in die ARIS- 

Modellierungslandschaft, die derzeit noch im Fluss ist 

• Insbesondere Berücksichtigung von Daten in BPMN 2.0 zu mächtig, um in der 

Veranstaltung behandelt zu werden; die Unterstützung in ARIS ist mithin bei 

weitem noch nicht vollständig 

• Kompromiss: Vernetzung mit bekannten Modellen (also ERD und 

Organigramm) über ARIS-Mechanismen 


Seite 54


Daten & Organisationsauszeichnung in BPMN (2) 


• Daten 

• Datenbezüge an Activities sollen durch Hinterlegung mit einem 

Funktionszuordnungsdiagramm modelliert werden 

• Damit einziger Unterschied zur EPK-Modellierung: Die Datenobjekte und ihre 

Beziehungen zu Activities können nicht direkt in BPMN-Diagrammen dargestellt 

werden, d.h. die Funktionszuordnungsdiagramme werden hier zwingend notwendig 

• Ausnahme: Gateways können keine Funktionszuordnungsdiagramme hinterlegt 

werden. In Konsequenz sollen keine Gateways mit Entscheidungsfunktion eingesetzt 

werden, die Zugriff auf Objekte des Datenmodells erfordern. 

• Organisation 

• Analog zu Daten sollen Organisationsbezüge per Funktionszuordnungsdiagramm 

hergestellt werden 

• Häufig gar nicht erforderlich, da bereits die Oberfunktion z.B. auf WSK-Ebene mit 

einer Organisationseinheit verbunden wurde 

• Auf Lanes soll verzichtet werden, da kein Bezug zum Organigramm bzw. seinen 

Objekten hergestellt werden kann 


Seite 55

Steuerungssicht 2/BPMN

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?