Prozessmodelle sind wichtige Grundlagen zur effizienten und effektiven Gestaltung von Organisationen. Daru¨ber hinaus fordern zahlreiche nationale und internationale Standards und Normen die Modellierung und Dokumentation der Gescha¨ftsprozesse. Daher verfu¨gen viele Unternehmen heute u¨ber eine große Menge an ausgereiften und aufwa¨ndig erstellten Prozessmodellen. Im deutschsprachigen Raum sind ereignisgesteuerte Prozessketten (EPK) weit verbreitet. International wird der Standard Business Process Modeling Notation (BPMN) zunehmend eingesetzt. Die internationale Zusammenarbeit und Verflechtung der Organisationen ist ein versta¨rkender Grund dafu¨r, dass Unternehmen ihre EPKs in die BPMN-Notation u¨berfu¨hren mo¨chten. Hierzu wird in diesem Beitrag dargestellt, inwieweit dies automatisiert abgewickelt werden kann und welche Grenzen der Automatisierung gesetzt sind. Nach einem kurzen U¨berblick u¨ber die Konstrukte von erweiterten EPKs und BPMN werden sukzessive deren Transformationsmo¨glichkeiten dargestellt. Wa¨hrend bei zahlreichen Konstrukten die Transformation automatisiert erfolgen kann, ergeben sich in einigen Fa¨llen Schwierigkeiten bzw. Mehrdeutigkeiten. In diesen Fa¨llen ist i.d.R. nur ein semi-automatisches Vorgehen mo¨glich. Durch die Einhaltung geeigneter Modellierungsrichtlinien fu¨r EPKs lassen sich einige dieser Problemfa¨lle vermeiden. Eine Teilmenge der dargestellten Transformationsregeln wurde bereits in einer prototypischen Implementierung auf Grundlage des Modellierungswerkzeugs Signavio Process Editor umgesetzt.
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 englischsprachigen Raum ist zwar erst spa¨ter in Gang gekommen, gewinnt aber durch die weltweite, unternehmensu¨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) vero¨ffentlicht. Der Standardisierungsprozess wurde von der Object Management Group (OMG) u¨bernommen und eine u¨berarbeitete Version wurde im Juni 2005 vero¨ffentlicht. Die aktuelle Version 1.2 steht seit Februar 2009 zur Verfu¨gung. Momentan wird BPMN 2.0 vorbereitet und eine Vero¨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 fu¨r in den USA bo¨rsennotierte Unternehmen oder Unternehmen, deren Anteile in den USA außerbo¨rslich gehandelt werden sowie deren Tochtergesellschaften), COBIT (Control Objects for Information and related Technology, internationaler Wirtschaftspru¨ferstandard [IT-05]) oder CMMI (Capability Maturity Model Integration, Best Practice-Modell des Software Engineering Instituts der Carnegie Mellon University mit 22 Referenzprozessen/sog. “Prozesskategorien” fu¨r die Optimierung der IT-Organisation [CKS08]). Daraus folgt, dass ein international anerkannter Standard wie BPMN zunehmend an Bedeutung gewinnt und gewinnen wird. Auch Unternehmen des deutschsprachigen Raums werden durch internationale Kooperationen bzw. Verflechtungen, aus Gru¨nden der leichteren Gewinnung von qualifiziertem, international ta¨tigen Personal oder aus anderen Gru¨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 ereignisgesteuerten Prozessketten erstellt haben und durch externen Druck oder aus eigenem Antrieb zur Modellierungsmethode BPMN wechseln wollen, mu¨ssen also u¨berlegen, wie sie diese “Wertgegensta¨nde” mo¨glichst aufwandsarm u¨berfu¨hren ko¨nnen. In diesem Beitrag wird dargestellt, nach welchen Regeln ereignisgesteuerte Prozessketten mo¨glichst automatisierbar in BPMN-Modelle u¨berfu¨hrt werden ko¨nnen und bei welchen Modellelementen eine automatisierte Lo¨sung nicht unmittelbar mo¨glich bzw. sicher ist, da die Semantik der Sprachen dies nicht zula¨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.
1ARIS ist eine geschu¨tze Marke der IDS Scheer AG
Die Transformation von EPKs nach BPMN wird in der Literatur bisher kaum diskutiert. 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 Aktivita¨ten und Kommunikationsaktivita¨ten (d.h. Senden und Empfangen von Nachrichten).
Grundlage fu¨r eine saubere Transformation ist eine pra¨zise Definition der Semantik der Quell- und Zielsprache. Existierende Arbeiten zu EPK und BPMN konzentrieren sich hierbei vor allem auf die Kontrollflusssemantik. Wa¨hrend die Semantik von XOR- und UND-Konnektoren unstrittig ist, ist eine rege Diskussion bzgl. ODER-Konnektoren (ORJoins) entstanden. Sowohl auf der EPK-Seite als auch auf der BPMN-Seite gibt es eine Reihe von Arbeiten, die jeweils u¨ber Transformationen zu einem Formalismus die Kontrollflusssemantik der einzelnen Modellierungskonstrukte abbilden [DGHW07, Men07]. Eine
Neben der Kontrollflusssemantik wurde in der Literatur auch die Prozessinstanziierungssemantik 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 zweistufiges Mapping vorgenommen werden, welches zuna¨chst ein EPK-Modell in eine dritte Sprache abbildet und dieses Zwischenergebnis wiederum nach BPMN u¨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 genauen Mappingvorschriften werden allerdings nicht na¨her erla¨utert. Besonderes Augenmerk gebu¨hrt bei dieser Strategie der Frage, ob die dritte Sprache tatsa¨chlich eine semantische Obermenge der Quell- oder Zielsprache bildet. Ist dies nicht der Fall, kann durch den “Umweg” 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 ho¨here Ausdrucksma¨chtigkeit besitzt als die Quellsprache, sind Spracherweiterungen / -verfeinerungen in der Quellsprache eine ha¨ufig verwendete Strategie, um eine genauere Abbildung zu erreichen. Fu¨r EPKs existieren Erweiterungen, die genau aus diesem Grund hinzugefu¨gt wurden, z.B. fu¨r ein Mapping in Richtung Web-Service-Orchestrierungen [HW08]. 3
Im Folgenden werden die Grundelemente der ereignisgesteuerten Prozessketten (EPKs) grob skizziert. Fu¨r Details wird auf das Methodenhandbuch ARIS [IDS06] bzw. die zahlreich vorhandene Literatur (z.B. [Sch98] oder [Gad08]) verwiesen. Ereignisgesteuerte
Prozessketten (EPKs) bzw. deren Erweiterungen sind nicht formal normiert und unterliegen pragmatischer, kontinuierlicher Verbesserung bzw. Vera¨nderung, wie es fu¨r Industriestandards ha¨ufig der Fall ist. Daru¨ber hinaus werden von unterschiedlichen Beratern und Anwendern gelegentlich eigene Erweiterungen oder Erga¨nzungen entwickelt und propagiert. Im Kern stimmen die bekannten Grundelemente der EPKs jedoch im Wesentlichen u¨berein. Bei ereignisgesteuerten Prozessketten werden die Elemente der Funktionssicht (Funktionen) u¨ber Ereignisse verkettet. Ereignisse repra¨sentieren einen “betriebswirtschaftlich relevanten Zustand eines Informationsobjektes, der den weiteren Ablauf des Gescha¨ftsprozesses steuert oder beeinflusst. Ereignisse lo¨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 (repra¨sentiert durch eine gerichtete Kante) oder durch einen logischen Verknu¨pfungsoperator (UND, ODER, exklusives ODER) mit gerichteten Kanten. Abbildung 1 zeigt die drei Hauptkategorien von EPK-Konstrukten: Funktionen, Ereignisse und Konnektoren. Die zula¨ssigen Verknu¨pfungsregeln fu¨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 Ausdrucksfa¨higkeit nicht auf die Kontrollflussspezifikation zu beschra¨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 fu¨r einen Teil des Pru¨fungsprozesses einer Hochschule.
Zur Beschra¨nkung von Prozessen auf handhabbare Gro¨ßen und auf u¨berschaubare Ausschnitte bzw. Abstraktionsebenen werden Wertscho¨pfungskettendiagramme und Hinterlegungen verwendet. Wertscho¨pfungsketten abstrahieren EPKs und zeigen Abfolgen und Strukturen betrieblicher Funktionen auf ho¨herer Ebene auf. Hinterlegungen sind Verfeinerungen von Funktionen, die diese mit den Mitteln der eEPK auf na¨chster Verfeinerungsstufe beschreiben.
Fu¨r die Nennung von Nachfolgeprozessen und Vorga¨ngerprozessen in EPKs werden in der Praxis oft Prozessschnittstellen eingesetzt, die diese Prozesse symbolisieren. In manchen existierenden Prozessmodellen werden Prozessschnittstellen auch zur Darstellung von Unterprozessen eingesetzt. Diese Verwendung wird allerdings nicht empfohlen, da hierfu¨r bereits das Konstrukt der Hinterlegung existiert. Generell sind Prozessschnittstellen Studierender
Prüfungsleistung erbringen
Prüfungsaufgab
en Professor
Student zur Prüfung zugelassen Prüfungsleistung
erbracht Prüfungsleistung korrigieren, bewerten Prüfung korrigiert Prüfungsergebni sse erfassen Anwesenheiten überprüfen
Prüfungszulassu
ngen Studentische Abteilung
Studierender fehlt Fehlgrund prüfen Prüfungsergebni s bei Fehlen ermittelt Prüfungsergebni s zentral erfassen MS Excel individuelle Ergebnisliste Browser IE/FF Prüfungstool bewertete Prüfungsleistung en
Prüfungsergebnis
ermittelt Abbildung 2: EPK-Beispiel
Sammlung Prüfungsabmeld
ungen Prüfungstool bewertete Prüfungsleistung en
Abbildung 3: Verknu¨pfungsregeln nach [IDS06] zuru¨ckhaltend einzusetzen, da sie Informationen redundant darstellen. Eine Definition des Konstrukts Prozessschnittstelle findet sich im Methodenhandbuch von ARIS [IDS06] nicht. 4
der im Februar 2009 vero¨ffentlichten Version 1.2 [bpm09].
Abbildung 4 zeigt die vier Hauptkategorien an BPMN-Konstrukten: Swimlanes, verknu¨pfende Objekte, Flussobjekte und Artefakte. Swimlanes repra¨sentieren Organisationseinheiten, Rollen oder Systeme. Eine Unterscheidung, ob es sich um eine Organisationseinheit oder eine Rolle handelt, wird nicht unterstu¨tzt. Die ha¨ufigste Verwendung ist dabei jedoch, dass Pools Organisationen darstellen und Lanes Organisationseinheiten darin. BPMN unterscheidet Sequenzfluss und Nachrichtenfluss. Sequenzfluss stellt die Verhaltensabha¨ngigkeiten innerhalb eines Pools dar, wa¨hrend Nachrichtenfluss die Kommunikation verschiedener Pools miteinander repra¨sentiert. Nachrichtenfluss innerhalb des gleichen Pools ist nicht erlaubt.
Es gibt drei Arten von Flussobjekten in BPMN: Aktivita¨ten repra¨sentieren die Arbeitsschritte innerhalb eines Prozesses. Diese sind entweder atomar (Tasks) oder ko¨nnen in Unterschritte (Unterprozesse) weiter unterteilt werden.
Ereignisse gibt es in den Auspra¨gungen “auslo¨send” und “eintretend”. Bei auslo¨senden ErSwimlanes
Verknüpfende Objekte
Flussobjekte e n a lo L o P e n a L Pool
Sequenzfluss Nachrichtenfluss Assoziation
Aktivität 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 fu¨r die Spezifikation von Kontrollflusslogik verwendet. Hier gibt es die fu¨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 ausgewa¨hlte kurz erwa¨hnen. (1) Es ko¨nnen “Multiple Instanzen” spezifiziert werden, bei denen eine Menge von Instanzen von der gleichen Aktivita¨t parallel ausgefu¨hrt werden ko¨nnen. Beispielsweise kann so spezifiziert werden, dass fu¨r jeden Bestellposten innerhalb einer Bestellung eine bestimmte Aktion no¨tig ist. (2) Weiterhin ko¨nnen mittels angehefteter Zwischen-Ereignisse Abbruchkriterien fu¨r Aktivita¨ten spezifiziert werden. Zum Beispiel ko¨nnen Eskalationsmaßnahmen definiert werden fu¨r den Fall, dass eine Aktivita¨t nicht innerhalb einer bestimmten Zeit abgeschlossen wird.
Bei BPMN ist es mo¨glich, mehrere Ende-Ereignisse zu verwenden. Abgesehen vom speziellen Terminierungs-Ende-Ereignis, bei dem die laufende Prozessinstanz als Ganzes abgebrochen wird, la¨uft eine Prozessinstanz solange weiter, bis keine Aktion mehr mo¨glich ist. Dies wird auch “Implicit Termination” genannt [AtHKB03].
Abbildung 5 zeigt das Beispiel aus dem vorigen Abschnitt in BPMN-Darstellung. 5
Dieser Abschnitt untersucht die Transformation von EPK zu BPMN. Dabei sind fu¨r jedes Konstrukt jeweils zwei Aspekte zu pru¨fen. 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 mo¨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 bescha¨ftigen sich damit, ob der Informationsgehalt aus der EPK vollsta¨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 ko¨nnen, wie dies im Quellmodell der Fall war.
deren Entsprechungen in BPMN. 5.1
Funktionen Funktionen repra¨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 u¨ber Tasks und Subprozesse abgebildet. Auslo¨sende Ereignisse repra¨sentieren kurzlebige Aktionen innerhalb eines Prozesses. Somit erlaubt BPMN eine weiterfu¨hrende Typisierung von Aktionen. In ausgewa¨hlten Fa¨llen ko¨nnen daher Funktionen mit auslo¨senden Zwischen- und Ende-Ereignissen u¨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 repra¨sentieren zumeist Zusta¨nde. So ist es ein typisches Beispiel, dass die Funktion “Pru¨fungsleistung erbringen” von einem Ereignis “Pru¨fungsleistung erbracht” gefolgt wird. In diesem Fall tra¨gt das Ereignis keine nennenswerte Mehrinformation und scheint nur ein syntaktisches Fu¨llelement zu sein. In BPMN ist eine explizite Darstellung von Prozesszusta¨nden im Regelfall nicht vorgesehen. Der Fokus liegt vielmehr auf den Aktivita¨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 Verfu¨gung. Ein Datenobjekt “Akte” ko¨nnte sich dabei im Zustand Funktion Ereignis
V Prozessschnittstelle
Rolle l o o P e n a L e n a L
Pool Datenobjekt
Abbildung 6: Transformation von EPK nach BPMN – U¨ bersicht Akte anlegen
Klausur einsammeln
Akte angelegt “angelegt” befinden. Als Alternative fu¨r die Darstellung von Prozesszusta¨nden bieten sich weiterhin Blanko-Zwischenereignisse an. Diese Verwendung ist in der Praxis jedoch selten anzutreffen. Ein guter Hinweis darauf, dass Prozesszusta¨nde tatsa¨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 zusammenfu¨hrt. Hier haben die Konnektoren keinerlei Einfluss auf den Prozessfluss. Vielmehr findet hier eine explizite Aufza¨hlung von mo¨glichen Prozesszusta¨nden statt. Zu diskutieren wa¨re hier allerdings, ob es sich hier um guten Modellierungsstil handelt, da die Aufspaltung im Kontrollfluss zu keinem Unterschied bzgl. Der Funktionsausfu¨hrungen fu¨hrt.
Spannend wird es bei Startereignissen. Hier repra¨sentieren EPK-Ereignisse entweder Trigger oder Zusta¨nde [DM09]. Bei “Pru¨fungstermin eingetreten” handelt es sich um einen Trigger. In dem Moment, wo der Termin eintritt, wird der Prozess ausgelo¨st. In BPMN werden mehrere Typen von Triggern unterschieden. Der Typ kann lediglich durch die Beschriftung des Ereignisses oder durch den Prozesskontext ermittelt werden. Beispielsweise wu¨rde “Jeden Montagmorgen” auf ein zeitliches Ereignis hindeuten, “Zahlung ist eingegangen” 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 vollja¨hrig” ist ein Beispiel fu¨r eine Zustandsbeschreibung. Hier wird der Prozess nicht in dem Moment ausgelo¨st, wo der Kunde das 18. Lebensjahr vollendet. Eher ist diese Zustandsbeschreibung als Vorbedingung fu¨r die Prozessinstanziierung zu verstehen. Sofern eine EPK nur u¨ber ein einziges Startereignis verfu¨gt, ist eine Transformation offensichtlich: Im BPMN-Modell wird ein Startereignis erzeugt. Die einzige Frage ist, ob eine weitere Typisierung des Triggers sinnvoll ist.
Verfu¨gt eine EPK u¨ber mehrere Startereignisse, so ist eine gu¨ltige Transformation nur in bestimmten Fa¨llen mo¨glich. Idealerweise handelt es sich um alternative Startereignisse, d.h. es erfolgt spa¨ter eine Zusammenfu¨hrung mittels XOR-Konnektoren. In diesem Fall Prüfungstermin eingetreten Kunde ist volljährig Kunde ruft
an Messekontakt
wurde protokolliert
Trigger 1 Trigger 2 kann jedes EPK-Startereignis auf ein BPMN-Startereignis abgebildet werden. Ein Beispiel fu¨r alternative Eintrittspunkte in einen Vertriebsprozess wa¨ren “Kunde ruft an” vs. “Messekontakt wurde protokolliert”.
Abbildung 9: Abbildung von verknu¨pften Startereignissen Sofern es sich nicht um alternative EPK-Startereignisse handelt, so ist anhand der Beschriftungen zu pru¨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 u¨bersetzt. Gibt es mehrere Trigger, die spa¨ter u¨ber UND- oder ODER-Konnektoren zusammen gefu¨hrt werden, ist eine korrekte Transformation in ein BPMN-Modell unter Beibehaltung einer vergleichbaren syntaktischen Struktur nicht mo¨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 ha¨ufigsten Fall wird ein Blanko-Ende-Ereignis verwendet, welches optional mit einer kurzen Zustandsbeschreibung versehen ist, z.B. “Vertrag ist abgeschlossen”. Daher ko¨nnen EPK-Endereignisse einfach in BPMN-Ende-Ereignisse u¨bersetzt werden.
An dieser Stelle sei darauf hingewiesen, dass Zwischen- und Endereignisse auch in bestimmten Fa¨llen auf Nachrichten-Empfangs-Ereignisse abgebildet werden ko¨nnen [KWL09].
Student zur Prüfung zugelassen Studierender fehlt
Student zur Prüfung zugelassen Studierender
fehlt
Abbildung 10: Abbildung von Ereignissen (
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. Wa¨hrend bei der semantischen Entsprechung im Falle von XOR- und UND-Konnektoren mit den entsprechenden BPMN-Konstrukten keine Zweifel bestehen, so ist der ODER-Konnektor insofern problematisch, 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 Ausfu¨hrungssemantik von ODER-Konnektoren / inklusiven Gateways aber wahrscheinlich nicht: Es besteht die Vermutung, dass fu¨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 Verzweigungsbedingungen in EPKs in Form von Ereignissen gegeben sind, wa¨hrend BPMN hierfu¨r Kantenbeschriftungen vorsieht. Daru¨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 u¨blicher Weg verwendet werden. 5.4
Prozessschnittstellen Prozessschnittstellen bieten die Mo¨glichkeit, ein EPK-Modell mit anderen Modellen in Beziehung zu setzen. Hier gibt es jedoch zwei semantische Auspra¨gungen, die jeweils unterschiedlich in BPMN abgebildet werden mu¨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 wa¨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 Pa¨rchen von Link-Ereignissen also einer Kontrollflusskante, sofern die beiden Modelle in einem großen Modell zusammengefu¨hrt werden. BPMN sieht Link-Ereignisse zur Darstellung solcher Modell-Zerschneidungen vor.
Prüfung vorbereiten
Prüfung durchführen
Prüfung nachbereiten
Prüfung vorbereiten
Prüfung durchführen
Prüfung nachbereiten Leistung bewerten Bei der Wahl, ob nun ein Unterprozess oder ein Link-Ereignis die passende Entsprechung ist, helfen eine Reihe von Indizien. Besitzt eine Prozessschnittstelle Vorga¨nger- und Nachfolgerelemente, so handelt es sich um einen Unterprozess. Wird eine Prozessschnittstelle jedoch als Eintrittspunkt in einen Prozess oder als Austrittspunkt verwendet, so sind wahrscheinlich Link-Ereignisse die passende Entsprechung. Informationen daru¨ber, was von der Schnittstelle verlinkt wird (ganzes Modell vs. Prozessschnittstellen) gibt einen zusa¨tzlichen Hinweis.
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 ausgedru¨ckt werden kann, werden Organisationseinheiten und Rollen in EPKs nicht weiter in Beziehung gesetzt. Dies geschieht zumeist außerhalb des Modells in separaten Organigrammen. Da weiterhin keine Unterscheidung zwischen Sequenz- und Nachrichtenfluss in EPKs zu finden ist, ko¨nnen die Organisationseinheiten und Rollen am besten als nebeneinander angeordnete Lanes des gleichen Pools abgebildet werden. Ein Bezeichner fu¨r diesen Pool steht nicht zur Verfu¨gung. Als Behelfslo¨sung ko¨nnen generische Namen wie “Hauptpool” oder “Organisation” gewa¨hlt werden.
Ziele definieren
Arbeit durchführen
Manager Mitarbeiter Mitarbeiter r e g a n a M + re looP ragena iittrbae defZinieieleren
M M itr e e b itr a M r e g a n a lo M oP tr e i e b itr a M r e g a n a lo M oP tr e i e b itr a M r e g a n a lo M oP tr e i e b itr a M
Ziele definieren
Ziele definieren
Ziele definieren
Ziele definieren
Arbeit durchführen
Arbeit durchführen
Arbeit durchführen Gemeinsam mit dem Mitarbeiter
Arbeit durchführen
Abbildung 12: Abbildung von Rollen (und Organisationseinheiten)
Problematisch wird es, sobald mehrere Organisationseinheiten und/oder Rollen mit einer
Funktion verknu¨pft sind. Dieser Sachverhalt kann in BPMN nicht sauber abgebildet werden.
In BPMN-Diagramme sieht man des o¨fteren, dass eine Aktivita¨t mehrere Lanes abdeckt.
Dies ist von BPMN syntaktisch allerdings nicht vorgesehen. Verschiedene Workarounds
sind hier in BPMN denkbar. (1) Zum einen ko¨nnen separate Lanes geschaffen werden, die
explizit die Zusammenarbeit mehrerer Organisationseinheiten oder Rollen modellieren,
z.B. “Team”. (2) Zum anderen ist es mo¨glich, Unterprozesse zuna¨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 Aktivita¨t dupliziert wird und mit gleicher Bezeichnung in
verschiedenen Lanes erzeugt wird. (
Systeme
Systeme werden typischerweise auf eine von vier Arten abgebildet. (1) Sofern das
Modell eine reine Systemsicht liefert, d.h. Organisationseinheiten und Rollen kommen im
Modell nicht vor, so ko¨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 ko¨nnen Systeme als zugeklappte Pools dargestellt
werden, mit denen der Prozess Nachrichten austauscht. Von der Intuition her wu¨rde so z.B.
repra¨sentiert, dass ein Mensch im Laufe einer Aktivita¨t mit dem System u¨ber
Eingabemasken 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 bescha¨ftigen, kann die
Systemsicht wiederum abgedeckt werden. Es entstehen somit mehrere Perspektiven auf den
gleichen Prozess (organisatorische Sicht vs. IT-Sicht). (
BPMN-Datenobjekte und entsprechend gerichtete Assoziationen kann die EPK-Semantik direkt abgebildet werden. 6
Im vorigen Abschnitt wurden alternative Optionen vorgestellt, wie die verschiedenen EPKKonstrukte abgebildet werden ko¨nnen. Die Wahl einer geeigneten Option kann bei einer Migration einer gro¨ßeren Anzahl von Modellen oft ein einziges Mal fu¨r alle Modelle entschieden werden. Dies ist vor allem bei der Abbildung von mehreren Rollen / Organisationseinheiten oder bei der Abbildung von Systemen der Fall. Auch ko¨nnte z.B. entschieden werden, dass Ereignisse wenn immer mo¨glich in einer Abbildung ignoriert werden. Auch kann bei einer Abbildung behilflich sein, wenn die EPKs definierten Modellierungsrichtlinien folgen. Dies kann z.B. kla¨ren, wie Prozessschnittstellen bei einer Abbildung zu behandeln sind. Aufgabe
System 1 System 1 Aufgabe Aufgabe Aufgabe
Verwendet
System 1
Abbildung 13: Abbildung von Systemen In der ARIS-Methode sind EPKs nur eine von zahlreichen Diagrammtypen. Weitere ha¨ufig verwendete Diagrammtypen sind z.B. Wertscho¨pfungsketten und Organigramme. Organigramme ko¨nnen in BPMN nicht dargestellt werden. Zwar bietet BPMN die Mo¨glichkeit, Hierarchien an Lanes zu definieren. Dies deckt jedoch nicht die Ausdrucksma¨chtigkeit von Organigrammen ab. Wertscho¨pfungskettendiagramme, in denen Prozesse landkartenartig aufgeza¨hlt werden, ko¨nnen in BPMN insofern abgebildet werden, als dass eine Menge von Subprozessen nebeneinander im Diagramm platziert werden.
Dieser Beitrag bescha¨ftigt sich lediglich mit dem unidirektionalen Mapping von EPK nach BPMN. Es wird keine Antwort darauf gegeben, wie ein BPMN-Diagramm in eine EPK u¨berfu¨hrt werden kann. Ein Round-Tripping, bei dem das Modell in der Zielsprache editiert wird und wieder zuru¨ck in die Quellsprache u¨berfu¨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 ha¨ufig gestellt. Dieser Beitrag hilft bei dieser Diskussion insofern, als dass er einen ersten Anhaltspunkt dafu¨r bietet, wie im Falle der Entscheidung, zuna¨chst mit EPKs zu arbeiten und spa¨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 Vero¨ffentlichung der neuen Version 2.0 gerechnet werden. Die allermeisten Konvertierungsregeln bleiben davon unberu¨hrt. Lediglich bei der Darstellung von Systemen erleichtert BPMN 2.0 eine Abbildung. Durch “Data Stores” sowie u¨ber selbst definierbare Artefakte ko¨nnen Systeme damit abgebildet werden. 7
Dieser Beitrag hat gezeigt, dass weite Teile der EPKs automatisch bzw. semi-automatisch in bedeutungsgleiche BPMN-Modelle u¨berfu¨hrt werden ko¨nnen. Eine vorherige sachkundige Qualita¨tssicherung der EPKs sowie geeignete Modellierungskonventionen, die wiederum automatisch (z.B. mit sog. Reports) u¨berpru¨ft werden ko¨nnen, erho¨hen zusa¨tzlich das Einsatzpotenzial der automatischen Umstellung. Durch dieses Vorgehen ko¨nnen die in EPKs geta¨tigten Investitionen gesichert werden, wenn das Anwenderunternehmen von EPKs auf BPMN wechseln mo¨chte oder muss.
Eine Organisation sollte jedoch pru¨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 eingeu¨bt werden kann. Eine Teilmenge der vorgestellten Konvertierungsregeln wurde im Rahmen der SignavioOryx Academic Initiative2 als automatische Transformation realisiert. Dabei wird jede Funktion als Task, jedes Startereignis als Blanko-Start-Ereignis und jedes Endereignis als Blanko-Ende-Ereignisse umgesetzt. Zwischenereignisse werden igoniert – außer im Falle von Verzweigungsbedingungen. Prozessschnittstellen werden bislang nicht unterstu¨tzt und bei Rollen/Organisationseinheiten wird pro Funktion einfach nur eine Rolle/Organisationseinheit ausgewa¨hlt (und die anderen werden ignoriert). Als na¨chster Schritt wird eine semi-automatische bzw. durch Konventionen konfigurierbare Transformation realisiert, um den Entscheidungspunkten gerecht zu werden, die in diesem Beitrag beschrieben wurden.
[bpm09] [CKS08] [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. Business Process Modeling Notation (BPMN), Version 1.2. Bericht, Object Management Group (OMG), Feb 2009. http://www.omg.org/spec/BPMN/1.2/. 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. 2See http://www.signavio.com/academic [IDS06] [IT-05] [KWL09] [Men07] [Sch92] [Sch98] [SJ02] [SKI08] [SKLN09] [VZHA05]