=Paper=
{{Paper
|id=Vol-554/paper-6
|storemode=property
|title=Migration von EPK zu BPMN
|pdfUrl=https://ceur-ws.org/Vol-554/epk2009-paper06.pdf
|volume=Vol-554
}}
==Migration von EPK zu BPMN==
https://ceur-ws.org/Vol-554/epk2009-paper06.pdf
Migration von EPK zu BPMN
Gero Decker, Willi Tscheschner Jörg Puchan
Signavio GmbH Hochschule München
(gero.decker,willi.tscheschner)@signavio.com puchan@hm.edu
Abstract: Prozessmodelle sind wichtige Grundlagen zur effizienten und effektiven
Gestaltung von Organisationen. Darüber hinaus fordern zahlreiche nationale und
internationale Standards und Normen die Modellierung und Dokumentation der
Geschäftsprozesse. Daher verfügen viele Unternehmen heute über eine große Menge an
ausgereiften und aufwändig erstellten Prozessmodellen. Im deutschsprachigen Raum
sind ereignisgesteuerte Prozessketten (EPK) weit verbreitet. International wird der
Standard Business Process Modeling Notation (BPMN) zunehmend eingesetzt. Die in-
ternationale Zusammenarbeit und Verflechtung der Organisationen ist ein verstärkender
Grund dafür, dass Unternehmen ihre EPKs in die BPMN-Notation überführen möchten.
Hierzu wird in diesem Beitrag dargestellt, inwieweit dies automatisiert abgewickelt
werden kann und welche Grenzen der Automatisierung gesetzt sind. Nach einem kurzen
Überblick über die Konstrukte von erweiterten EPKs und BPMN werden sukzessive
deren Transformationsmöglichkeiten dargestellt. Während bei zahlreichen Konstrukten
die Transformation automatisiert erfolgen kann, ergeben sich in einigen Fällen Schwie-
rigkeiten bzw. Mehrdeutigkeiten. In diesen Fällen ist i.d.R. nur ein semi-automatisches
Vorgehen möglich. Durch die Einhaltung geeigneter Modellierungsrichtlinien für EPKs
lassen sich einige dieser Problemfälle vermeiden. Eine Teilmenge der dargestellten
Transformationsregeln wurde bereits in einer prototypischen Implementierung auf
Grundlage des Modellierungswerkzeugs Signavio Process Editor umgesetzt.
1 Einleitung
Die Gründe für die Prozessmodellierung in Unternehmen sind vielfältig. Häufig werden
Prozesse modelliert, um diese nachfolgend zu optimieren, im Unternehmen verbindlich
zu machen oder prozessunterstützende Systeme zu entwickeln bzw. anzupassen. Weite-
re Motivationen zur Prozessmodellierung resultieren aus der Notwendigkeit, gesetzliche,
aufsichtsrechtliche, revisorische oder ähnliche Anforderungen zu erfüllen (Compliance),
freiwillig bzw. marktgetrieben die Prozessorientierung zu fördern (z.B. Zertifizierungen)
oder Vergleiche mit Standardprozessmodellen (z.B. CMMI, ITIL) zu ermöglichen bzw.
diese schrittweise einzuführen. In jedem dieser Fälle wird in Unternehmen und Behörden
eine große Menge an Ressourcen, Zeit und Kosten aufgewandt, um diese Prozessmodelle
zu erstellen, zu optimieren, zu implementieren und sie aktuell zu halten. Im deutschspra-
chigen Raum sind dabei seit Mitte der neunziger Jahre des vergangenen Jahrhunderts
ereignisgesteuerte Prozessketten (EPK) und deren Erweiterungen (eEPK) auf der Grund-
lage bzw. nach den Vorgaben der “Architektur rechnergestützter Informationssysteme”
(ARIS) zunehmend und heute weit verbreitet. Die Modellierungsmethode und -sprache
wurde ursprünglich von Scheer entwickelt und dokumentiert [Sch92, Sch98] und dann im
91
Rahmen zahlreicher Projekte weiterentwickelt und verfeinert [SJ02, IDS06]. Heute sind
EPKs bei zahlreichen Unternehmen im Einsatz. Es kann angenommen werden, dass ein
Großteil der ca. 7.500 ARIS1 -Kunden der IDS Scheer AG EPKs zur Modellierung ihrer
Prozesse einsetzen. Genaue Statistiken zum Einsatz und zum Bestand von EPKs liegen den
Autoren allerdings nicht vor. Die internationale Entwicklung vor allem im englischspra-
chigen Raum ist zwar erst später in Gang gekommen, gewinnt aber durch die weltweite,
unternehmensübergreifende Kooperation, Verflechtung und Standardisierung immer mehr
an Bedeutung. Die Business Process Modeling Notation (BPMN [bpm09]) wurde 2004
erstmalig von der Business Process Management Initiative (BPMI) veröffentlicht. Der
Standardisierungsprozess wurde von der Object Management Group (OMG) übernommen
und eine überarbeitete Version wurde im Juni 2005 veröffentlicht. Die aktuelle Version 1.2
steht seit Februar 2009 zur Verfügung. Momentan wird BPMN 2.0 vorbereitet und eine
Veröffentlichung ist im Laufe des Jahres 2010 zu erwarten.
Unternehmen arbeiten heute zunehmend international zusammen. Viele Unternehmen
sind selbst internationale Konzerne. Auch internationale Standards und regulatorische
Anforderungen verlangen zunehmend standardisierte und dokumentierte Prozesse, z.B.
das US-Gesetz Sarbanes-Oxley Act 2002 (SOX, aufsichtsrechtliche Anforderungen für
in den USA börsennotierte Unternehmen oder Unternehmen, deren Anteile in den USA
außerbörslich gehandelt werden sowie deren Tochtergesellschaften), COBIT (Control Ob-
jects for Information and related Technology, internationaler Wirtschaftsprüferstandard
[IT-05]) oder CMMI (Capability Maturity Model Integration, Best Practice-Modell des
Software Engineering Instituts der Carnegie Mellon University mit 22 Referenzprozes-
sen/sog. “Prozesskategorien” für die Optimierung der IT-Organisation [CKS08]). Daraus
folgt, dass ein international anerkannter Standard wie BPMN zunehmend an Bedeutung ge-
winnt und gewinnen wird. Auch Unternehmen des deutschsprachigen Raums werden durch
internationale Kooperationen bzw. Verflechtungen, aus Gründen der leichteren Gewinnung
von qualifiziertem, international tätigen Personal oder aus anderen Gründen zunehmend
BPMN als Modellierungssprache einsetzen wollen. Die Autoren begleiten derzeit einige
Unternehmen, bei denen diese Entwicklung zu verzeichnen ist.
Anwenderunternehmen, die also wertvolle Prozessmodelle in Form von ereignisgesteu-
erten Prozessketten erstellt haben und durch externen Druck oder aus eigenem Antrieb
zur Modellierungsmethode BPMN wechseln wollen, müssen also überlegen, wie sie diese
“Wertgegenstände” möglichst aufwandsarm überführen können. In diesem Beitrag wird
dargestellt, nach welchen Regeln ereignisgesteuerte Prozessketten möglichst automati-
sierbar in BPMN-Modelle überführt werden können und bei welchen Modellelementen
eine automatisierte Lösung nicht unmittelbar möglich bzw. sicher ist, da die Semantik der
Sprachen dies nicht zulässt.
Dieser Beitrag stellt somit eine direkte Transformation von EPK zu BPMN vor und ist wie
folgt strukturiert. Nach einer kurzen Vorstellung der verwandten Arbeiten werden eEPKs
und BPMN jeweils in einem eigenen Abschnitt vorgestellt. Die Transformation wird in
Abschnitt 5 vorgestellt. Die Ergebnisse werden anschließend diskutiert. Der Beitrag schließt
mit einer Zusammenfassung und einem Ausblick.
1 ARIS ist eine geschütze Marke der IDS Scheer AG
92
2 Verwandte Arbeiten
Die Transformation von EPKs nach BPMN wird in der Literatur bisher kaum disku-
tiert. Ein Beitrag von Hoyer et al. [HBS07] ist ein erster Schritt in Richtung einer (semi-
)automatischen Transformation. Neben einer Abbildung der Kontrollflusskonstrukte wird
hier vor allem auf die Unterscheidung zwischen internen Aktivitäten und Kommunikations-
aktivitäten (d.h. Senden und Empfangen von Nachrichten).
Grundlage für eine saubere Transformation ist eine präzise Definition der Semantik der
Quell- und Zielsprache. Existierende Arbeiten zu EPK und BPMN konzentrieren sich
hierbei vor allem auf die Kontrollflusssemantik. Während die Semantik von XOR- und
UND-Konnektoren unstrittig ist, ist eine rege Diskussion bzgl. ODER-Konnektoren (OR-
Joins) entstanden. Sowohl auf der EPK-Seite als auch auf der BPMN-Seite gibt es eine
Reihe von Arbeiten, die jeweils über Transformationen zu einem Formalismus die Kontroll-
flusssemantik der einzelnen Modellierungskonstrukte abbilden [DGHW07, Men07]. Eine
Übersicht über die Diskussion findet sich in [KMWL09].
Neben der Kontrollflusssemantik wurde in der Literatur auch die Prozessinstanziierungs-
semantik von EPK und BPMN beleuchtet. Dies ist besonders relevant, da sowohl EPK
als auch BPMN mehrere Eintrittspunkte in einen Prozess zulassen und die Anzahl der
Modellierungsfehler stark mit der Anzahl an Startknoten in einem Prozessmodell korreliert
[DM09].
Als Alternative zu einem direkten Mapping von EPK nach BPMN kann auch ein zwei-
stufiges Mapping vorgenommen werden, welches zunächst ein EPK-Modell in eine dritte
Sprache abbildet und dieses Zwischenergebnis wiederum nach BPMN übersetzt. Ein solcher
Ansatz wird propagiert in [VZHA05] unter Verwendung einer speziellen XML-Sprache.
Zwar werden EPK und BPMN als motivierendes Beispiel in diesem Beitrag genannt, die ge-
nauen Mappingvorschriften werden allerdings nicht näher erläutert. Besonderes Augenmerk
gebührt bei dieser Strategie der Frage, ob die dritte Sprache tatsächlich eine semantische
Obermenge der Quell- oder Zielsprache bildet. Ist dies nicht der Fall, kann durch den “Um-
weg” mehr Information verloren gehen als bei einer direkten Abbildung. Insofern kommt
der Einsatz von Petrinetzen oder BPEL nicht in Frage, obwohl entsprechende Mappings
von EPKs / zu BPMN existieren [SKI08, KWL09, WDGW08, SKLN09].
Gerade in Situationen, bei denen die Zielsprache eine höhere Ausdrucksmächtigkeit besitzt
als die Quellsprache, sind Spracherweiterungen / -verfeinerungen in der Quellsprache eine
häufig verwendete Strategie, um eine genauere Abbildung zu erreichen. Für EPKs existieren
Erweiterungen, die genau aus diesem Grund hinzugefügt wurden, z.B. für ein Mapping in
Richtung Web-Service-Orchestrierungen [HW08].
3 EPKs im Überblick
Im Folgenden werden die Grundelemente der ereignisgesteuerten Prozessketten (EPKs)
grob skizziert. Für Details wird auf das Methodenhandbuch ARIS [IDS06] bzw. die zahl-
reich vorhandene Literatur (z.B. [Sch98] oder [Gad08]) verwiesen. Ereignisgesteuerte
93
Prozessketten (EPKs) bzw. deren Erweiterungen sind nicht formal normiert und unterliegen
pragmatischer, kontinuierlicher Verbesserung bzw. Veränderung, wie es für Industriestan-
dards häufig der Fall ist. Darüber hinaus werden von unterschiedlichen Beratern und An-
wendern gelegentlich eigene Erweiterungen oder Ergänzungen entwickelt und propagiert.
Im Kern stimmen die bekannten Grundelemente der EPKs jedoch im Wesentlichen überein.
Bei ereignisgesteuerten Prozessketten werden die Elemente der Funktionssicht (Funktionen)
über Ereignisse verkettet. Ereignisse repräsentieren einen “betriebswirtschaftlich relevanten
Zustand eines Informationsobjektes, der den weiteren Ablauf des Geschäftsprozesses steu-
ert oder beeinflusst. Ereignisse lösen Funktionen aus und sind Ergebnisse von Funktionen.
Im Gegensatz zu einer Funktion, die ein zeitverbrauchendes Geschehen darstellt, ist ein
Ereignis auf einen Zeitpunkt bezogen.” (vgl. [IDS06]). Die Verkettung der Elemente erfolgt
entweder sequenziell (repräsentiert durch eine gerichtete Kante) oder durch einen logischen
Verknüpfungsoperator (UND, ODER, exklusives ODER) mit gerichteten Kanten.
Konnektoren
Prüfungs- Prüfungs- V
leistung leistung V
erbringen erbracht
Exklusives
Funktion Ereignis UND ODER
ODER
Abbildung 1: EPK-Konstrukte
Abbildung 1 zeigt die drei Hauptkategorien von EPK-Konstrukten: Funktionen, Ereignisse
und Konnektoren. Die zulässigen Verknüpfungsregeln für Konnektoren sind in Abbildung 3
dargestellt (vgl. [IDS06], S. 110).
EPKs starten und enden stets mit einem Ereignis. In der Praxis kommt es auch vor, dass
Modelle mehrere Startereignisse und mehrere Endereignisse haben.
Um die Ausdrucksfähigkeit nicht auf die Kontrollflussspezifikation zu beschränken, wurden
die EPKs erweitert. Erweiterte EPKs (eEPKs) zeigen auch beteiligte Organisationseinheiten,
Stellen oder Rollen (Organisationssicht), Ein- und Ausgabedaten (Datensicht), sowie die
verwendeten Systeme (ein spezieller Aspekt der Funktionssicht) auf. Abbildung 2 zeigt ein
eEPK-Beispiel für einen Teil des Prüfungsprozesses einer Hochschule.
Zur Beschränkung von Prozessen auf handhabbare Größen und auf überschaubare Aus-
schnitte bzw. Abstraktionsebenen werden Wertschöpfungskettendiagramme und Hinter-
legungen verwendet. Wertschöpfungsketten abstrahieren EPKs und zeigen Abfolgen und
Strukturen betrieblicher Funktionen auf höherer Ebene auf. Hinterlegungen sind Verfeine-
rungen von Funktionen, die diese mit den Mitteln der eEPK auf nächster Verfeinerungsstufe
beschreiben.
Für die Nennung von Nachfolgeprozessen und Vorgängerprozessen in EPKs werden in
der Praxis oft Prozessschnittstellen eingesetzt, die diese Prozesse symbolisieren. In man-
chen existierenden Prozessmodellen werden Prozessschnittstellen auch zur Darstellung
von Unterprozessen eingesetzt. Diese Verwendung wird allerdings nicht empfohlen, da
hierfür bereits das Konstrukt der Hinterlegung existiert. Generell sind Prozessschnittstellen
94
Prüfungstermin
eingetreten
Anwesenheiten Prüfungszulassu
überprüfen ngen
Student zur
Prüfung Studierender fehlt
zugelassen
Sammlung
Studierender Prüfungsleistung Prüfungsaufgab
en Fehlgrund prüfen Prüfungsabmeld
erbringen ungen
Studentische Prüfungsergebni
Prüfungsleistung
erbracht Abteilung s bei Fehlen
ermittelt
Prüfungsleistung Prüfungsergebni
Professor korrigieren, MS Excel s zentral Prüfungstool
bewerten erfassen
individuelle bewertete
Prüfung korrigiert Prüfungsleistung
Ergebnisliste
en
Prüfungsergebni
Browser IE/FF
sse erfassen
Prüfungstool
bewertete
Prüfungsleistung
en
Prüfungsergebnis
ermittelt
Abbildung 2: EPK-Beispiel
95
V V V V
V V V
Abbildung 3: Verknüpfungsregeln nach [IDS06]
zurückhaltend einzusetzen, da sie Informationen redundant darstellen. Eine Definition des
Konstrukts Prozessschnittstelle findet sich im Methodenhandbuch von ARIS [IDS06] nicht.
4 BPMN im Überblick
Der folgende Überblick über die Business Process Modeling Notation (BPMN) basiert auf
der im Februar 2009 veröffentlichten Version 1.2 [bpm09].
Abbildung 4 zeigt die vier Hauptkategorien an BPMN-Konstrukten: Swimlanes, ver-
knüpfende Objekte, Flussobjekte und Artefakte. Swimlanes repräsentieren Organisationsein-
heiten, Rollen oder Systeme. Eine Unterscheidung, ob es sich um eine Organisationseinheit
oder eine Rolle handelt, wird nicht unterstützt. Die häufigste Verwendung ist dabei jedoch,
dass Pools Organisationen darstellen und Lanes Organisationseinheiten darin.
BPMN unterscheidet Sequenzfluss und Nachrichtenfluss. Sequenzfluss stellt die Verhal-
tensabhängigkeiten innerhalb eines Pools dar, während Nachrichtenfluss die Kommunikati-
on verschiedener Pools miteinander repräsentiert. Nachrichtenfluss innerhalb des gleichen
Pools ist nicht erlaubt.
Es gibt drei Arten von Flussobjekten in BPMN: Aktivitäten repräsentieren die Arbeits-
schritte innerhalb eines Prozesses. Diese sind entweder atomar (Tasks) oder können in
Unterschritte (Unterprozesse) weiter unterteilt werden.
Ereignisse gibt es in den Ausprägungen “auslösend” und “eintretend”. Bei auslösenden Er-
96
Swimlanes Verknüpfende Objekte Flussobjekte Artefakte
Lane
Sequenzfluss Aktivität Datenobjekt
Pool
Lane
Nachrichtenfluss Ereignis Annotation Text
Pool Assoziation Gateway Gruppe
Abbildung 4: BPMN Modellierungskonstrukte
eignissen handelt es sich um spezielle Aktionen, z.B. werden Nachrichten an einen anderen
Pool verschickt. Bei eintretenden Ereignissen wird der Prozessfluss solange blockiert, bis
das entsprechende Ereignis eingetreten ist, z.B. bis eine Nachricht eingetroffen ist oder bis
eine Zeitbedingung erreicht wurde.
Gateways werden für die Spezifikation von Kontrollflusslogik verwendet. Hier gibt es
die fünf Typen daten-basiert exklusiv, ereignis-basiert exklusiv, parallel, inklusiv und
komplex. Auf ein ereignis-basiertes Gateway folgt immer eine Reihe von eintretenden
Ereignissen. Wird das Gateway erreicht, blockiert der Prozessfluss und es wird auf die
Ereignisse gewartet. Sobald ein Ereignis eingetreten ist, wird nicht weiter auf die anderen
Ereignisse gewartet und der Prozessfluss setzt sich an der Verzweigung fort entsprechend
dem eingetretenen Ereignis. Dieses Verhalten wird im Workflow-Patterns-Katalog als
“Deferred Choice” bezeichnet [AtHKB03].
BPMN bietet einige besondere Kontrollflusskonstrukte, wovon wir zwei ausgewählte kurz
erwähnen. (1) Es können “Multiple Instanzen” spezifiziert werden, bei denen eine Menge
von Instanzen von der gleichen Aktivität parallel ausgeführt werden können. Beispielsweise
kann so spezifiziert werden, dass für jeden Bestellposten innerhalb einer Bestellung eine
bestimmte Aktion nötig ist. (2) Weiterhin können mittels angehefteter Zwischen-Ereignisse
Abbruchkriterien für Aktivitäten spezifiziert werden. Zum Beispiel können Eskalationsmaß-
nahmen definiert werden für den Fall, dass eine Aktivität nicht innerhalb einer bestimmten
Zeit abgeschlossen wird.
Bei BPMN ist es möglich, mehrere Ende-Ereignisse zu verwenden. Abgesehen vom spe-
ziellen Terminierungs-Ende-Ereignis, bei dem die laufende Prozessinstanz als Ganzes
abgebrochen wird, läuft eine Prozessinstanz solange weiter, bis keine Aktion mehr möglich
ist. Dies wird auch “Implicit Termination” genannt [AtHKB03].
Abbildung 5 zeigt das Beispiel aus dem vorigen Abschnitt in BPMN-Darstellung.
5 Transformation von EPK zu BPMN
Dieser Abschnitt untersucht die Transformation von EPK zu BPMN. Dabei sind für jedes
Konstrukt jeweils zwei Aspekte zu prüfen.
97
Abbildung 5: BPMN-Beispiel
98
1. Existiert ein BPMN-Konstrukt (oder eine Kombination von BPMN-Konstrukten), das
die Semantik des EPK-Konstruktes abdeckt? Falls nicht, welche Konstrukte kommen
der Semantik möglichst nahe?
2. Ist die Abbildung injektiv, d.h. werden keine zwei EPK-Konstrukte auf das gleiche
BPMN-Konstrukt abgebildet? Falls eine nicht-injektive Abbildung vorliegt, handelt
es sich um einen echten Informationsverlust?
Beide Fragen beschäftigen sich damit, ob der Informationsgehalt aus der EPK vollständig
erhalten werden kann. Dies ist wichtig, da Modelle vor allem zur Beantwortung von Fragen
dienen. Gehen Informationen verloren, kann dies zur Folge haben, dass bestimmte Fragen
im Zielmodell nicht im gleichen Maße beantwortet werden können, wie dies im Quellmodell
der Fall war.
Abbildung 6 zeigt eine tabellarische Übersicht über alle betrachteten EPK-Konstrukte und
deren Entsprechungen in BPMN.
5.1 Funktionen
Funktionen repräsentieren einen Arbeitsschritt innerhalb des Prozesses und finden somit in
BPMN-Tasks ihre Entsprechung. Ein Sonderfall ergibt sich im Falle von Hinterlegungen.
Ist der Funktion ein Prozessmodell hinterlegt, so entspricht dies einem zugeklappten
Subprozess in BPMN, der auf ein weiteres Diagramm zeigt.
Aktionen werden in BPMN nicht ausschließlich über Tasks und Subprozesse abgebildet.
Auslösende Ereignisse repräsentieren kurzlebige Aktionen innerhalb eines Prozesses. Somit
erlaubt BPMN eine weiterführende Typisierung von Aktionen. In ausgewählten Fällen
können daher Funktionen mit auslösenden Zwischen- und Ende-Ereignissen übersetzt
werden. Beispielsweise kann eine Funktion “Bescheid verschicken” als Zwischen- oder
Ende-Nachrichten-Sende-Ereignis dargestellt werden. Eine detaillierte Diskussion zu dieser
Unterscheidung ist in [HBS07] zu finden.
5.2 Ereignisse
Ereignisse in EPKs repräsentieren zumeist Zustände. So ist es ein typisches Beispiel, dass
die Funktion “Prüfungsleistung erbringen” von einem Ereignis “Prüfungsleistung erbracht”
gefolgt wird. In diesem Fall trägt das Ereignis keine nennenswerte Mehrinformation und
scheint nur ein syntaktisches Füllelement zu sein. In BPMN ist eine explizite Darstellung
von Prozesszuständen im Regelfall nicht vorgesehen. Der Fokus liegt vielmehr auf den
Aktivitäten. Daher werden die meisten EPK-Ereignisse in einem Mapping auf BPMN
ignoriert.
Soll ein Prozesszustand zwingend dargestellt werden, so stehen in BPMN Datenobjekte mit
Zustandsattributen zur Verfügung. Ein Datenobjekt “Akte” könnte sich dabei im Zustand
99
Funktion Task Subprozess
Ereignis Bedingung
[Zustand]
V
V
Prozess-
schnittstelle Subprozess
Lane
Rolle
Pool
Lane
Org.-Einheit
Annotation
Pool
System
Datenobjekt Daten-
objekt
Abbildung 6: Transformation von EPK nach BPMN – Übersicht
100
Prüfungs- Prüfungs- Prüfungs- Prüfungs- Prüfungs-
leistung leistung leistung leistung leistung
erbringen erbracht korrigieren erbringen korrigieren
Prüfungs-
leistung
Akte Akte erbringen
anlegen angelegt
Akte
[angelegt]
Prüfung
Klausur Klausur
abge-
einsammeln einsammeln
schlossen
Prüfung
abgeschlossen
Abbildung 7: Abbildung von Zwischenereignissen
“angelegt” befinden. Als Alternative für die Darstellung von Prozesszuständen bieten sich
weiterhin Blanko-Zwischenereignisse an. Diese Verwendung ist in der Praxis jedoch selten
anzutreffen. Ein guter Hinweis darauf, dass Prozesszustände tatsächlich eine wichtige
Information im Modell darstellen, besteht in folgendem Fall: Eine Funktion wird gefolgt
von einem XOR- oder UND-Konnektor, dieser von einer Reihe von Ereignissen und
diese wiederum von einem weiteren XOR- oder UND-Konnektor, der den Prozessfluss
wieder zusammenführt. Hier haben die Konnektoren keinerlei Einfluss auf den Prozessfluss.
Vielmehr findet hier eine explizite Aufzählung von möglichen Prozesszuständen statt. Zu
diskutieren wäre hier allerdings, ob es sich hier um guten Modellierungsstil handelt, da
die Aufspaltung im Kontrollfluss zu keinem Unterschied bzgl. Der Funktionsausführungen
führt.
Spannend wird es bei Startereignissen. Hier repräsentieren EPK-Ereignisse entweder Trig-
ger oder Zustände [DM09]. Bei “Prüfungstermin eingetreten” handelt es sich um einen
Trigger. In dem Moment, wo der Termin eintritt, wird der Prozess ausgelöst. In BPMN
werden mehrere Typen von Triggern unterschieden. Der Typ kann lediglich durch die Be-
schriftung des Ereignisses oder durch den Prozesskontext ermittelt werden. Beispielsweise
würde “Jeden Montagmorgen” auf ein zeitliches Ereignis hindeuten, “Zahlung ist einge-
gangen” auf eine eingehende Nachricht oder “Wasserstand hat kritisches Level erreicht”
auf eine Business-Regel. Ist ein Ereignis-Typ nicht eindeutig auszumachen, so kann auch
einfach ein untypisiertes Start-Ereignis (Blanko-Ereignis) verwendet werden.
“Kunde ist volljährig” ist ein Beispiel für eine Zustandsbeschreibung. Hier wird der Prozess
nicht in dem Moment ausgelöst, wo der Kunde das 18. Lebensjahr vollendet. Eher ist diese
Zustandsbeschreibung als Vorbedingung für die Prozessinstanziierung zu verstehen.
Sofern eine EPK nur über ein einziges Startereignis verfügt, ist eine Transformation offen-
sichtlich: Im BPMN-Modell wird ein Startereignis erzeugt. Die einzige Frage ist, ob eine
weitere Typisierung des Triggers sinnvoll ist.
Verfügt eine EPK über mehrere Startereignisse, so ist eine gültige Transformation nur in
bestimmten Fällen möglich. Idealerweise handelt es sich um alternative Startereignisse,
d.h. es erfolgt später eine Zusammenführung mittels XOR-Konnektoren. In diesem Fall
101
Prüfungs-
termin
eingetreten Prüfungstermin
eingetreten
Kunde ist
volljährig
Bedingung:
Kunde ist volljährig
Abbildung 8: Abbildung von Startereignissen
kann jedes EPK-Startereignis auf ein BPMN-Startereignis abgebildet werden. Ein Bei-
spiel für alternative Eintrittspunkte in einen Vertriebsprozess wären “Kunde ruft an” vs.
“Messekontakt wurde protokolliert”.
Kunde ruft
an
Kunde ruft an
Messekontakt
wurde
protokolliert
Messekontakt
wurde protokolliert
Trigger 1
Trigger 1 Trigger 2
V
Trigger 2
Trigger 2 Trigger 1
Abbildung 9: Abbildung von verknüpften Startereignissen
Sofern es sich nicht um alternative EPK-Startereignisse handelt, so ist anhand der Beschrif-
tungen zu prüfen, ob es unter den Startereignissen mehr als einen Trigger gibt. Ist dies nicht
der Fall, so wird das triggernde EPK-Startereignis wiederum mit einem BPMN-Startereignis
übersetzt. Gibt es mehrere Trigger, die später über UND- oder ODER-Konnektoren zu-
sammen geführt werden, ist eine korrekte Transformation in ein BPMN-Modell unter
Beibehaltung einer vergleichbaren syntaktischen Struktur nicht möglich. Die parallele
Struktur muss entsprechend sequentialisiert werden, was eine Duplizierung von Ereignissen
im Diagramm zur Folge hat (siehe Abbildung 9) und das Diagramm schwer lesbar macht.
Eine detaillierte Diskussion zu diesem Fall findet sich bei Decker und Mendling [DM09].
BPMN-Prozessmodelle schließen mit Ende-Ereignissen ab. Im häufigsten Fall wird ein
Blanko-Ende-Ereignis verwendet, welches optional mit einer kurzen Zustandsbeschreibung
versehen ist, z.B. “Vertrag ist abgeschlossen”. Daher können EPK-Endereignisse einfach in
BPMN-Ende-Ereignisse übersetzt werden.
An dieser Stelle sei darauf hingewiesen, dass Zwischen- und Endereignisse auch in bestimm-
102
ten Fällen auf Nachrichten-Empfangs-Ereignisse abgebildet werden können [KWL09].
Student zur Prüfung
Student zur
zugelassen
Prüfung
zugelassen
Studierender
fehlt Studierender
fehlt
Abbildung 10: Abbildung von Ereignissen (4)
Bei denjenigen EPK-Ereignissen, die weder Start- noch Endereignisse sind, d.h. eingehende
oder ausgehende Kontrollflusskanten besitzen, gibt es einen speziellen Fall, in dem das Er-
eignis auf jeden Fall in der Transformation beachtet werden muss: Entscheidungen werden
in EPK über XOR- und ODER-Konnektoren mit mehreren ausgehenden Kanten modelliert.
In diesem Fall geben die nachfolgenden Ereignisse die Verzweigungsbedingungen an,
z.B. “Student zur Prüfung zugelassen”. Verzweigungsbedingungen werden in BPMN über
Kantenbeschriftungen realisiert.
5.3 Konnektoren
Konnektoren realisieren Kontrollflussbeziehungen in EPKs. XOR-Konnektoren finden in
daten-basierten exklusiven Gateways ihre Entsprechung, UND-Konnektoren in parallelen
Gateways und ODER-Konnektoren in inklusiven Gateways. Während bei der semanti-
schen Entsprechung im Falle von XOR- und UND-Konnektoren mit den entsprechenden
BPMN-Konstrukten keine Zweifel bestehen, so ist der ODER-Konnektor insofern proble-
matisch, da sowohl auf EPK- als auch auf BPMN-Seite Unsicherheit bzgl. der Semantik
besteht (siehe Abschnitt 2). Praktische Relevanz haben die verschiedenen Nuancen in der
Ausführungssemantik von ODER-Konnektoren / inklusiven Gateways aber wahrscheinlich
nicht: Es besteht die Vermutung, dass für die allermeisten Prozessmodelle diese Nuancen
keinen Unterschied in der Semantik bedeuten. Ein entsprechender empirischer Nachweis
fehlt in der Literatur allerdings noch.
Zu beachten bei einem Mapping von Konnektoren ist lediglich, dass die Verzweigungs-
bedingungen in EPKs in Form von Ereignissen gegeben sind, während BPMN hierfür
Kantenbeschriftungen vorsieht. Darüber hinaus sieht BPMN alternative Darstellungen von
XOR-Joins, AND-Splits und OR-Splits vor: Hier werden mehrere Sequenzflusskanten mit
Flussobjekten verbunden. Beispielsweise haben mehrere eingehende Kanten in einen Task
XOR-Semantik. Eine Abbildung auf BPMN-Gateways, wie oben beschrieben, kann jedoch
als üblicher Weg verwendet werden.
103
5.4 Prozessschnittstellen
Prozessschnittstellen bieten die Möglichkeit, ein EPK-Modell mit anderen Modellen in
Beziehung zu setzen. Hier gibt es jedoch zwei semantische Ausprägungen, die jeweils un-
terschiedlich in BPMN abgebildet werden müssen. Zum einen werden Prozessschnittstellen
verwendet, um Prozesshierarchien darzustellen. Hierbei verweist eine Prozessschnittstelle
auf ein Modell als Ganzes oder auf ein Startereignis in einem anderen Modell. Die Semantik
hierbei ist, dass der zweite Prozess beendet sein muss, bevor die auf die Prozessschnittstelle
folgenden Funktionen angestoßen werden. Die Entsprechung auf BPMN-Seite wäre damit
ein Unterprozess.
Alternativ realisieren Prozessschnittstellen zuweilen jedoch auch einfache Zerschneidungen
von Prozessmodellen. Hierbei wird auf eine Prozessschnittstelle in einem anderen Modell
verwiesen. Semantisch ist ein Pärchen von Link-Ereignissen also einer Kontrollflusskante,
sofern die beiden Modelle in einem großen Modell zusammengeführt werden. BPMN sieht
Link-Ereignisse zur Darstellung solcher Modell-Zerschneidungen vor.
Prüfung
Prüfung Prüfung Prüfung Prüfung Prüfung
durchführen
vorbereiten durchführen nachbereiten vorbereiten nachbereiten
Leistung Prüfung
Eintragung vorbereiten
bewerten
Eintragung
Prüfung
Ergebnisse Ergebnisse
abge-
eintragen eintragen
schlossen
Prüfung
abgeschlossen
Abbildung 11: Abbildung von Prozessschnittstellen
Bei der Wahl, ob nun ein Unterprozess oder ein Link-Ereignis die passende Entsprechung
ist, helfen eine Reihe von Indizien. Besitzt eine Prozessschnittstelle Vorgänger- und Nach-
folgerelemente, so handelt es sich um einen Unterprozess. Wird eine Prozessschnittstelle
jedoch als Eintrittspunkt in einen Prozess oder als Austrittspunkt verwendet, so sind wahr-
scheinlich Link-Ereignisse die passende Entsprechung. Informationen darüber, was von der
Schnittstelle verlinkt wird (ganzes Modell vs. Prozessschnittstellen) gibt einen zusätzlichen
Hinweis.
5.5 Organisationseinheiten / Rollen
Organisationseinheiten und Rollen werden in BPMN durch Pools und Lanes dargestellt.
Anders als in BPMN, wo durch Enthaltenseinsbeziehungen von Pools, Lanes und Sub-Lanes
eine hierarchische Beziehung ausgedrückt werden kann, werden Organisationseinheiten
und Rollen in EPKs nicht weiter in Beziehung gesetzt. Dies geschieht zumeist außerhalb
104
des Modells in separaten Organigrammen. Da weiterhin keine Unterscheidung zwischen
Sequenz- und Nachrichtenfluss in EPKs zu finden ist, können die Organisationseinheiten
und Rollen am besten als nebeneinander angeordnete Lanes des gleichen Pools abgebildet
werden. Ein Bezeichner für diesen Pool steht nicht zur Verfügung. Als Behelfslösung
können generische Namen wie “Hauptpool” oder “Organisation” gewählt werden.
Manager
Manager
Ziele
definieren
Manager +
Mitarbeiter
Ziele
Pool
Mitarbeiter definieren
Mitarbeiter
Arbeit
durchführen Arbeit
Mitarbeiter durchführen
Manager
Ziele
definieren
Pool
Mitarbeiter
Arbeit
durchführen
Manager
Ziele
definieren
Pool
Mitarbeiter
Ziele Arbeit
definieren durchführen
Manager
Gemeinsam mit
Ziele dem Mitarbeiter
definieren
Pool
Mitarbeiter
Arbeit
durchführen
Abbildung 12: Abbildung von Rollen (und Organisationseinheiten)
Problematisch wird es, sobald mehrere Organisationseinheiten und/oder Rollen mit einer
Funktion verknüpft sind. Dieser Sachverhalt kann in BPMN nicht sauber abgebildet werden.
In BPMN-Diagramme sieht man des öfteren, dass eine Aktivität mehrere Lanes abdeckt.
Dies ist von BPMN syntaktisch allerdings nicht vorgesehen. Verschiedene Workarounds
sind hier in BPMN denkbar. (1) Zum einen können separate Lanes geschaffen werden, die
explizit die Zusammenarbeit mehrerer Organisationseinheiten oder Rollen modellieren,
z.B. “Team”. (2) Zum anderen ist es möglich, Unterprozesse zunächst einer bestimmten
Lane zuzuordnen und bei einer Verfeinerung in einem separaten Diagramm die Aufgaben
entsprechend den verschiedenen Lanes zuzuordnen. (3) Manchmal sieht man, dass eine
gemeinschaftliche Aktivität dupliziert wird und mit gleicher Bezeichnung in verschie-
denen Lanes erzeugt wird. (4) Die Aktivität wird nur einer Lane zugeordnet, und zwar
der verantwortlichen oder führenden Organisationseinheit/Rolle, und über entsprechende
105
Textannotationen (Kommentare) wird die Beteiligung der anderen erwähnt. Abbildung 12
illustriert diese vier Strategien.
5.6 Systeme
Systeme werden typischerweise auf eine von vier Arten abgebildet. (1) Sofern das Mo-
dell eine reine Systemsicht liefert, d.h. Organisationseinheiten und Rollen kommen im
Modell nicht vor, so können Systeme als Pools und Lanes dargestellt werden. Hier stellt
sich wiederum die gleiche Frage wie bei Organisationseinheiten und Rollen: Wie kann
dargestellt werden, dass mehrere Systeme einer Funktion zugeordnet sind. Schwieriger
wird es außerdem, falls sowohl Systeme als auch Organisationseinheiten / Rollen in einem
Modell definiert sind. (2) Alternativ können Systeme als zugeklappte Pools dargestellt
werden, mit denen der Prozess Nachrichten austauscht. Von der Intuition her würde so z.B.
repräsentiert, dass ein Mensch im Laufe einer Aktivität mit dem System über Eingabe-
masken und entsprechende Bildschirmanzeigen interagiert. (3) Als dritte Option kann ein
Modellierer auch auf die Darstellung von Systemen in einem Modell verzichten. Mit Hilfe
weiterer Modelle, die sich dann speziell mit einer Systemzuordnung beschäftigen, kann die
Systemsicht wiederum abgedeckt werden. Es entstehen somit mehrere Perspektiven auf den
gleichen Prozess (organisatorische Sicht vs. IT-Sicht). (4) Abschließend, und wahrschein-
lich am häufigsten verwendet, können auch Textannotationen verwendet werden, um die
Systemzuordnung widerzuspiegeln. Diese vier Optionen sind in Abbildung 13 illustriert.
5.7 Datenobjekte
Für Datenobjekte gibt es eine offensichtliche Abbildung von EPKs auf BPMN: Über
BPMN-Datenobjekte und entsprechend gerichtete Assoziationen kann die EPK-Semantik
direkt abgebildet werden.
6 Diskussion
Im vorigen Abschnitt wurden alternative Optionen vorgestellt, wie die verschiedenen EPK-
Konstrukte abgebildet werden können. Die Wahl einer geeigneten Option kann bei einer
Migration einer größeren Anzahl von Modellen oft ein einziges Mal für alle Modelle
entschieden werden. Dies ist vor allem bei der Abbildung von mehreren Rollen / Organisati-
onseinheiten oder bei der Abbildung von Systemen der Fall. Auch könnte z.B. entschieden
werden, dass Ereignisse wenn immer möglich in einer Abbildung ignoriert werden.
Auch kann bei einer Abbildung behilflich sein, wenn die EPKs definierten Modellierungs-
richtlinien folgen. Dies kann z.B. klären, wie Prozessschnittstellen bei einer Abbildung zu
behandeln sind.
106
System 1
System 1 Aufgabe
Pool
Aufgabe
System 2
Org.-Einheit
System 1
Org.-Einheit
Aufgabe
Org.-Einheit
Aufgabe
Verwendet
System 1
Org.-Einheit
Aufgabe
Abbildung 13: Abbildung von Systemen
In der ARIS-Methode sind EPKs nur eine von zahlreichen Diagrammtypen. Weitere häufig
verwendete Diagrammtypen sind z.B. Wertschöpfungsketten und Organigramme. Organi-
gramme können in BPMN nicht dargestellt werden. Zwar bietet BPMN die Möglichkeit,
Hierarchien an Lanes zu definieren. Dies deckt jedoch nicht die Ausdrucksmächtigkeit von
Organigrammen ab. Wertschöpfungskettendiagramme, in denen Prozesse landkartenartig
aufgezählt werden, können in BPMN insofern abgebildet werden, als dass eine Menge von
Subprozessen nebeneinander im Diagramm platziert werden.
Dieser Beitrag beschäftigt sich lediglich mit dem unidirektionalen Mapping von EPK
nach BPMN. Es wird keine Antwort darauf gegeben, wie ein BPMN-Diagramm in eine
EPK überführt werden kann. Ein Round-Tripping, bei dem das Modell in der Zielsprache
editiert wird und wieder zurück in die Quellsprache überführt wird, bleibt somit erst recht
undiskutiert.
Auch beantwortet dieser Artikel nicht die Frage “Wann setze ich welche Sprache ein?”, bzw.
die Frage nach Vor- und Nachteilen der beiden Sprachen in den unterschiedlichen Phasen
des Entwurfs prozessorientierter Informationssysteme. Diese Fragen werden zu Beginn
von BPM-Initiativen häufig gestellt. Dieser Beitrag hilft bei dieser Diskussion insofern, als
dass er einen ersten Anhaltspunkt dafür bietet, wie im Falle der Entscheidung, zunächst mit
EPKs zu arbeiten und später auf BPMN umzusteigen, hinterher eine Migration der Modelle
aussehen kann.
Dieser Beitrag hat sich auf BPMN in der Version 1.2 konzentriert. Im Laufe des Jahres 2010
kann mit der Veröffentlichung der neuen Version 2.0 gerechnet werden. Die allermeisten
107
Konvertierungsregeln bleiben davon unberührt. Lediglich bei der Darstellung von Systemen
erleichtert BPMN 2.0 eine Abbildung. Durch “Data Stores” sowie über selbst definierbare
Artefakte können Systeme damit abgebildet werden.
7 Zusammenfassung und Ausblick
Dieser Beitrag hat gezeigt, dass weite Teile der EPKs automatisch bzw. semi-automatisch in
bedeutungsgleiche BPMN-Modelle überführt werden können. Eine vorherige sachkundige
Qualitätssicherung der EPKs sowie geeignete Modellierungskonventionen, die wiederum
automatisch (z.B. mit sog. Reports) überprüft werden können, erhöhen zusätzlich das
Einsatzpotenzial der automatischen Umstellung. Durch dieses Vorgehen können die in
EPKs getätigten Investitionen gesichert werden, wenn das Anwenderunternehmen von
EPKs auf BPMN wechseln möchte oder muss.
Eine Organisation sollte jedoch prüfen, ob nicht auch eine erneute BPMN-Modellierung,
gepaart mit einer Anpassung und Aktualisierung der Modelle eine valide Alternative bildet.
Dies hat gleichzeitig den Effekt, dass die Verwendung der BPMN eingeübt werden kann.
Eine Teilmenge der vorgestellten Konvertierungsregeln wurde im Rahmen der Signavio-
Oryx Academic Initiative2 als automatische Transformation realisiert. Dabei wird je-
de Funktion als Task, jedes Startereignis als Blanko-Start-Ereignis und jedes Endereig-
nis als Blanko-Ende-Ereignisse umgesetzt. Zwischenereignisse werden igoniert – außer
im Falle von Verzweigungsbedingungen. Prozessschnittstellen werden bislang nicht un-
terstützt und bei Rollen/Organisationseinheiten wird pro Funktion einfach nur eine Rol-
le/Organisationseinheit ausgewählt (und die anderen werden ignoriert). Als nächster Schritt
wird eine semi-automatische bzw. durch Konventionen konfigurierbare Transformation rea-
lisiert, um den Entscheidungspunkten gerecht zu werden, die in diesem Beitrag beschrieben
wurden.
Literatur
[AtHKB03] Wil M. P. van der Aalst, Arthur H. M. ter Hofstede, Bartek Kiepuszewski und Alistair P.
Barros. Workflow Patterns. Distributed and Parallel Databases, 14(1):5–51, 2003.
[bpm09] Business Process Modeling Notation (BPMN), Version 1.2. Bericht, Object Manage-
ment Group (OMG), Feb 2009. http://www.omg.org/spec/BPMN/1.2/.
[CKS08] Mary Beth Chrissis, Mike Konrad und Sandy Shrum. CMMI, Guidelines for Process
Integration and Product Improvement, Second Edition. Addison Wesley, 2008.
[DGHW07] Marlon Dumas, Alexander Grosskopf, Thomas Hettel und Moe Wynn. Semantics of
BPMN Process Models with OR-joins. In Proceedings of 15th International Conference
on Cooperative Information Systems (CoopIS), Jgg. 4803 of LNCS, Seiten 41–58,
Vilamoura, Portugal, November 2007. Springer Verlag.
2 See http://www.signavio.com/academic
108
[DM09] Gero Decker und Jan Mendling. Process Instantiation. Data & Knowledge Engineering,
2009.
[Gad08] Gadatsch. Grundkurs Geschäftsprozess-Management, 5. Auflage. Vieweg, 2008.
[HBS07] Volker Hoyer, Eva Bucherer und Florian Schnabel. Collaborative e-Business Process
Modelling: Transforming Private EPC to Public BPMN Business Process Models.
In Business Process Management Workshops, Jgg. 4928 of LNCS, Seiten 185–196,
Brisbane, Australien, 2007. Springer Verlag.
[HW08] Stefan Huth und Thomas Wieland. Geschäftsprozessmodellierung mittels Software-
Services auf Basis der EPK, Seiten 61–76. 2008.
[IDS06] ARIS Platform, Methode ARIS 7.0. Bericht, IDS Scheer, Saarbrücken, 2006.
[IT-05] COBIT 4.1. Bericht, IT-Governance Institute, 2005.
[KMWL09] Oliver Kopp, Daniel Martin, Daniel Wutke und Frank Leymann. The Difference
Between Graph-Based and Block-Structured Business Process Modelling Languages.
Enterprise Modelling and Information Systems, 4(1):3–13, June 2009.
[KWL09] Oliver Kopp, Matthias Wieland und Frank Leymann. External and Internal Events
in EPCs: e2EPCs. In 2nd International Workshop on Event-Driven Business Process
Management (edBPM09). Springer Verlag, 2009.
[Men07] Jan Mendling. On the Detection and Prediction of Errors in EPC Business Process
Models. EMISA Forum, 27(2):52–59, 2007.
[Sch92] August-Wilhelm Scheer. Architektur integrierter Informationssysteme - Grundlagen
der Unternehmensmodellierung, 2. Auflage. Berlin, 1992.
[Sch98] August-Wilhelm Scheer. ARIS – Modellierungsmethoden, Metamodelle, Anwendungen,
3. Auflage. Berlin, 1998.
[SJ02] August-Wilhelm Scheer und W. Jost. ARIS in der Praxis, Gestaltung, Implementierung
und Optimierung von Geschäftsprozessen. Berlin, Heidelberg, New York, 2002.
[SKI08] Sebastian Stein, S. Kühne und K. Ivanov. Business to IT Transformations Revisited. In
MDE4BPM 2008, 2008.
[SKLN09] David Schumm, Dimka Karastoyanova, Frank Leymann und Jörg Nitzsche. On Vi-
sualizing and Modelling BPEL with BPMN. In Proceedings of the 4th International
Workshop on Workflow Management (ICWM2009). IEEE Computer Society, 2009.
[VZHA05] D. Vanderhaeghen, S. Zang, A. Hofer und O. Adam. XML-based Transformation of
Business Process Models–Enabler for Collaborative Business Process Management.
XML4BPM, 2005.
[WDGW08] Matthias Weidlich, Gero Decker, Alexander Grosskopf und Mathias Weske. BPEL to
BPMN: The Myth of a Straight-Forward Mapping. In Proceedings 16th International
Conference on Cooperative Information Systems (CoopIS), Jgg. 5331 of LNCS, Seiten
265–282, Monterrey, Mexico, Nov 2008. Springer Verlag.
109