Migrationsassistent BPMN 2.0 nach BPI

Transkript

1 Hochschule Luzern Technik & Architektur Migrationsassistent Master of Science in Engineering Master-Thesis Simon von Däniken Zihlmattweg 42 / Luzern simon.vondaeniken@gmail.com Matrikel-Nummer Horw,

2 Selbständigkeitserklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig angefertigt und keine anderen als die angegebenen Hilfsmittel verwendet habe. Sämtliche verwendeten Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden ausdrücklich als solche gekennzeichnet. Simon von Däniken, Horw Kontaktangaben Advisor Prof. Jörg Hofstetter Leiter Kompetenzzentrum Experte Prof. Dr. André J. Rogger Wirtschaftspartner Bison Schweiz AG Seiler Thomas II

3 Inhalt Abbildungsverzeichnis... V Tabellenverzeichnis... VI Abkürzungsverzeichnis... VII Abstract... VIII 1 Einleitung Ausgangslage Problemstellung Zielsetzung Erwartete Resultate Aufbau der Arbeit Einführung Was ist die BPMN 2.0? Was ist der BPI? Analyse Ziel Vorgehensweise Resultat Umsetzung Grundlegende Herausforderungen Überführung eines fachlichen Prozesses in einen ausführbaren Abhängigkeiten während der Transformation Transformation der Prozesssemantik Migration von eingebetteten Unterprozessen Erweiterung des Zielmodells als Alternative zur Migration Umgang mit nicht migrierbaren Elementen Transformation der Prozess-View Verschmelzung von Prozesssemantik und -darstellung Transformierter Referenzpunkt der Flussobjekte Spiegelung des Prozessdiagramms Benutzerschnittstelle Benutzereingabe Benutzerinteraktion Benutzerrückmeldung Umsetzung im Prototyp Evaluierung der eingesetzten Mitteln Simple Transformer (SiTra) Atlas Transformation Language (ATL) Einsatz generierter Metamodelle Architekturentscheid III

4 5 Schluss Fazit Ausblick Literatur- und Quellverzeichnis Kurzlebenslauf des Verfassers Anhang A Begriffsübersetzung B Transformationsbeispiele B.1 Beispiel B.2 Beispiel B.3 Beispiel C Aufgabenstellung D Projektplanung D.1 Rahmenplan D.2 Detailplanung D.3 Arbeitsjournal E Sitzungsprotokolle E E E E E : Review E E : Zwischenbesprechung E IV

5 Abbildungsverzeichnis Abbildung 1: Ein einfaches BPMN Prozessmodell... 3 Abbildung 2: BPI Designer (links) und Web-Interface des Business Process Integrators... 4 Abbildung 3: Kosten/Nutzen-Matrix der Start- und Endereignisse... 7 Abbildung 4: camunda BPMN-Framework (cabpmn)... 9 Abbildung 5: Notwendigkeit einer manuellen Nachbearbeitung Abbildung 6: Transformation eines eingebetteten Unterprozesses mit angeheftetem Ereignis Abbildung 7: Transformation eines eingebetteten Unterprozesses mit mehreren Endereignissen Abbildung 8: Transformation eines eingebetteten Unterprozesses ohne Start- und Endereignis Abbildung 9: Transformation eines Ad-hoc-Unterprozesses Abbildung 10: Umsetzung einer Schleifenaktivität Abbildung 11: Modellierung von Sequenzflüssen in BPMN (links) und BPI Abbildung 12: Optische Verschiebung aufgrund unterschiedlicher Objektgrössen Abbildung 13: Durch die Spiegelung verursachte Verzerrung der Zwischenräume Abbildung 14: Benutzerschnittstellen der Prozesstransformation Abbildung 15: Benutzerschnittstelle des umgesetzten Prototypen Abbildung 16: BPMN Demo-Prozess Abbildung 17: Migrierter BPI Demo-Prozess Abbildung 18: BPMN Demo-Prozess Abbildung 19: Migrierter BPI Demo-Prozess Abbildung 20: BPMN Demo-Prozess Abbildung 21: Migrierter BPI Demo-Prozess V

6 Tabellenverzeichnis Tabelle 1: Deutsche Übersetzung der Begrifflichkeiten aus der BPMN VI

7 Abkürzungsverzeichnis API Application Programming Interface ATL Atlas Transformation Language BPEL Business Process Execution Language BPI Business Process Integrator BPM Business Process Management DI Diagram Interchange EMF Eclipse Modeling Framework INRIA Institut national de recherche en informatique et en automatique OCL Object Constraint Language OMG Object Management Group QVT Query View Transformation SAX Simple API for XML UML Unified Modeling Language XML Extensible Markup Language XSD XML Schema Definition XSLT Extensible Stylesheet Language Transformation VII

8 Abstract The Bison Schweiz AG operates as an enterprise software developer. Amongst other things they offer a BPM system called Bison Process Integrator (BPI) for the execution of business processes. Due to the increasing distribution of the Business Process Model and Notation (BPMN) an automatic transformation of BPMN processes into the BPI process model is verified within this assignment. Therefore both process models are analysed and compared to identify the structural differences. Based on the results of an implemented prototype, the challenges of developing a migration assistant are explained by means of concrete examples. The prime challenge is porting a process model, defined from a business point of view, to a technical execution model. Furthermore, BPMN elements that can t be transformed are anticipated because of the BPMN s large functional range. It is shown, how the prototype deals with such elements. A simple, additional BPI component allows to take over as much information about the non-transformable element as possible. Subsequently the user interface is discussed because of its importance for an efficient, manual post-editing of the migrated process. Eventually, existing model transformation frameworks are brought into focus and with SiTra and the Atlas Transformation Language (ATL) two examples are briefly presented. The assignment ends with a conclusion and continuative thoughts about possible enhancements of BPI. Die Bison Schweiz AG ist in der Entwicklung von Business-Software tätig und bietet unter anderem mit dem Business Process Integrator (BPI) eine eigene BPM-Lösung zur Ausführung von Geschäftsprozessen an. Aufgrund der zunehmenden Verbreitung der Business Process Model and Notation (BPMN) wird innerhalb dieser Arbeit überprüft, ob sich ein in der BPMN modellierter Geschäftsprozess automatisiert ins BPI Prozessmodell transformieren lässt. Dazu werden in einer Analyse die beiden Prozessmodelle miteinander verglichen und die strukturellen Differenzen identifiziert. Basierend auf den Erkenntnissen eines umgesetzten Prototypen werden anschliessend anhand konkreter Beispiele die Herausforderungen bei der Implementierung eines Migrationsassistenten erläutert. Hierzu zählt insbesondere der Übergang eines aus fachlicher Sicht modellierten BPMN Prozesses in einen technischen, ausführbaren BPI Prozess. Des Weiteren ist aufgrund des grossen Funktionsumfangs der BPMN mit Elementen zu rechnen, welche nicht in das BPI Modell transformiert werden können. Es wird aufgezeigt, wie der Prototyp auf derartige Elemente reagiert. Mit Hilfe eines zusätzlichen BPI Bausteines sollen möglichst viele Informationen über das nicht migrierbare Element in den BPI Prozess übernommen werden. Als Basis für eine effiziente manuelle Nachbearbeitung des migrierten BPI Prozesses steht danach die Benutzerschnittstelle im Zentrum. Schlussendlich wird auf bestehende Frameworks zur Modelltransformation eingegangen und mit SiTra und der Atlas Transformation Language (ATL) werden zwei Ansätze kurz vorgestellt. Die Arbeit endet mit einem Fazit und weiterführenden Gedanken über mögliche strategische Weiterentwicklungen des BPI. VIII

9 Einleitung 1 Einleitung 1.1 Ausgangslage Die Bison Schweiz AG mit Sitz in Oberkirch LU besitzt langjährige Erfahrung in der Entwicklung und im Vertrieb von Business-Software. Im Zentrum ihrer Produktpalette steht ihr hauseigenes ERP-System, basierend auf JavaEE. Dieses wird seit einigen Jahren durch eine eigens entwickelte BPM-Lösung namens Business Process Integrator (BPI) komplettiert. Die Laufzeitumgebung basiert auf jbpm 3, eine Open-Source Prozess-Engine von jboss. Die Business-Prozesse werden im Web-Browser in einem eigenen Prozess-Editor basierend auf Flash definiert. Um eine möglichst einfache Handhabung zu erreichen, wurde der Funktionsumfang bewusst aufs Wesentliche reduziert und ein eigenes Prozessmodell entwickelt. Parallel zur Entwicklung vom BPI erfreute sich die Business Process Model and Notation (BPMN) immer grösserer Beliebtheit. Der von der Object Management Group (OMG) festgelegte Standard zur Modellierung von Geschäftsprozessen und Arbeitsabläufen erschien im Januar 2011 bereits in der Version 2.0. Die Verbreitung der BPMN ist auch für die Bison Schweiz AG nicht übersehbar. Eine Vielzahl von Neukunden haben ihre Geschäftsprozesse bereits in der BPMN modelliert. Sie zeigen daher ein reges Interesse an einer Unterstützung der BPMN innerhalb vom BPI, damit die Geschäftsprozesse nicht neu modelliert werden müssen. Unabhängig davon plant die Bison Schweiz AG einen Ausbau vom BPI hinsichtlich einer besseren Integration in das oben genannte ERP-System sowie eine allgemeine Funktionserweiterung. Für die Bison Schweiz AG stellen sich wichtige, strategische Fragestellungen bezüglich der zukünftigen Entwicklung vom BPI. Um den Kundenanforderungen gerecht zu werden, bietet sich im Rahmen dieser BPI Erweiterungen als mögliche Teilstrategie die Entwicklung eines Migrationsassistenten an. Dieser soll es erlauben, einen BPMN Prozess automatisiert ins BPI Prozessmodell zu transformieren. Der Migrationsassistent könnte als Import-Funktion innerhalb vom BPI angeboten werden. 1.2 Problemstellung Die Machbarkeit eines automatisierten Migrationsassistenten ist zurzeit ungewiss. Es wird davon ausgegangen, dass die BPMN in der Funktionalität umfangreicher und flexibler ist als das BPI Prozessmodell. Die exakten strukturellen und funktionalen Differenzen sind jedoch unbekannt und können nur erahnt werden. Dieser Umstand trägt dazu bei, dass die bevorstehenden strategischen Entscheidungen nicht mit vollständiger Gewissheit gefällt werden können. 1.3 Zielsetzung Mit der längerfristigen Absicht, existierende BPMN 2.0 Prozesse der Kunden in den BPI integrieren zu können, soll im Rahmen dieser Arbeit die Machbarkeit eines automatisierten Migrationsvorgangs aufgezeigt werden. 1

10 Einleitung 1.4 Erwartete Resultate Die Grenzen des Machbaren sind schwer abzuschätzen. Fundierte Kenntnisse bezüglich der BPMN sind nicht vorhanden. Es wird jedoch erwartet, dass die Grenzen durch zwei Umstände geprägt werden. Einerseits ist der Funktionsumfang des BPI Prozessmodells geringer gegenüber demjenigen der BPMN einzuschätzen. Dies hat die logische Konsequenz, dass nicht alle BPMN Elemente ein gleichartiges BPI Pendant haben. Einige dieser betroffenen BPMN Elemente lassen sich allenfalls durch alternative Konstrukte ausdrücken, sodass zumindest ein gleiches Verhalten während der Prozessausführung erreicht werden kann. Andererseits ist damit zu rechnen, dass es sich bei den BPMN Prozessen der Kunden um fachliche Prozesse handelt. Der BPI hingegen verlangt als Prozess-Engine technische Prozesse: Diese müssen derart präzis formuliert sein, dass sie durch die Maschine ausgeführt werden können. Die Transformation von fachlichen zu technischen Prozessen kann nicht vollständig automatisiert durchgeführt werden, ohne dass Informationslücken entstehen. Um diese zu schliessen werden manuelle Eingriffe notwendig sein. Ausserdem lässt sich die Grenze zwischen fachlichen und technischen Prozessen innerhalb des BPMN Modells nicht präzise erschliessen. Der Übergang wird fliessend sein. Für die Umsetzung eines Prototypen bedeutet dies, dass die BPMN Unterstützung vermutlich beinahe beliebig ausgebaut und verfeinert werden kann. 1.5 Aufbau der Arbeit Das folgende Kapitel 2 gibt fürs weitere Verständnis in wenigen Worten eine kurze Einführung in die BPMN und den BPI. Anschliessend wirft das Kapitel 3 einen Blick zurück auf die in einer ersten Projektphase durchgeführte Analyse. Das Resultat dieser Arbeit waren fünf Kosten/Nutzen-Matrizen. Diese halfen, einerseits die strukturellen Differenzen zwischen der BPMN und dem BPI zu verstehen und andererseits, die im Prototypen umzusetzenden BPMN Elemente zu priorisieren. Das Kapitel 3 fasst die Resultate der Analyse kurz zusammen. Die vollständige Analyse ist in einem separaten Dokumentes 1 abgelegt. Kapitel 4 befasst sich mit der Umsetzung des Prototypen des Migrationsassistenten. Die technischen Details 2 sind jedoch der Bison Schweiz AG vorbehalten. Dennoch sollen innerhalb dieses Kapitels die konzeptionellen Probleme und Herausforderungen sowie die durchgeführten Überlegungen und Erkenntnisse aufgezeigt werden. Die Arbeit wird mit Kapitel 5 abgeschlossen. Die Erkenntnisse werden nochmals in einem Fazit zusammengefasst und einen kurzen Ausblick mit möglichen Weiterentwicklungen vom BPI gegeben. 1 Migrationsassistent Analyse 2 Migrationsassistent Technische Dokumentation 2

11 Einführung 2 Einführung 2.1 Was ist die BPMN 2.0? Die Business Process Model and Notation (BPMN) ist ein Standard zur Modellierung von Geschäftsprozessen und Arbeitsabläufen. Im Zentrum steht die Notation, bestehend aus einer Vielzahl von Symbolen wie Aktivitäten, Gateways (Verzweigungen), Ereignissen, Sequenz- und Nachrichtenflüsse sowie Lanes und Artefakte. Die Abbildung 1 zeigt einen einfachen Beispielprozess, welcher in der BPMN modelliert wurde. Stelle ausschreiben Fachabteilung Mitarbeiter benötigt Mitarbeiterbedarf melden Stellenausschreibung erfassen Stellenausschreibung prüfen Personalausschreibung Stellenausschreibung überarbeiten Okay Nicht okay Stellenausschreibung veröffentlichen Stelle ausgeschrieben Abbildung 1: Ein einfaches BPMN Prozessmodell Quelle: Abbildung 1 in BPMN 2.0 Business Process Model and Notation [1 S. 16] Mit der zweiten Version der BPMN wurden nach [1 S. 11] zahlreiche interessante Erneuerungen eingeführt. Zwar wurde die Symbolpallette ebenfalls leicht erweitert, die grosse Entwicklung fand jedoch im Verdeckten statt. Die neuen Choreo- und Konversationsdiagramme erlauben, die Kommunikation zwischen zwei oder mehreren Teilnehmern zu fokussieren. Die beiden Diagramme stehen jedoch nicht im Zentrum dieser Arbeit und werden ausgegrenzt. In den früheren BPMN Versionen wurde die Bedeutung der Notation sowie die dazugehörigen Regeln verbal beschrieben. Mit der Version 2.0 wurde eine formale Definition in Form eines Metamodells (UML) eingeführt. Einerseits ist diese Definition viel präziser und andererseits können hiermit Zusatzinformationen für die Prozessausführung beschrieben werden, welche im Diagramm gar nicht ersichtlich sind. Das Metamodell bildet auch die Ausgangslage für ein standardisiertes Austauschformat basierend auf XML. Mit Hilfe dieses Formates ist es erstmals möglich, dass modellierte Geschäftsprozesse zwischen unterschiedlichen BPMN Tools ausgetauscht werden. Diese Erweiterung stellt eine wesentliche Grundvoraussetzung für diese Master-Thesis dar! Die BPMN 2.0 wurde letztendlich auch bezüglich der Ausführung verbessert. In früheren Versionen wurde lediglich beschrieben, wie ein BPMN Prozess ins ausführbare BPEL-Format umgewandelt werden kann. Die neue Version beschreibt neu auch eine Ausführungssemantik der einzelnen Symbole. Dies ist eine Voraussetzung für die Entwicklung von Prozess-Engines, welche BPMN Prozesse direkt interpretieren und ausführen können. 3

12 Einführung 2.2 Was ist der BPI? Beim Business Process Integrator (BPI) handelt es sich um eine BPM-Lösung der Bison Schweiz AG. Der BPI beinhaltet unter anderem mit dem BPI Designer ein Tool zur Modellierung von Geschäftsprozessen, eine Laufzeitumgebung zur Ausführung dieser Prozesse sowie für den Endbenutzer ein Web-Interface zur Administration seiner Aufgaben (siehe Abbildung 2). Abbildung 2: BPI Designer (links) und Web-Interface des Business Process Integrators Der Kern der Laufzeitumgebung bildet jbpm, eine Prozess-Engine von jboss. Die eingesetzte Version 3 interpretiert Prozesse in der jboss-eigenen jpdl Sprache. Diese wird jedoch nicht direkt im BPI Designer zur Modellierung der Prozesse verwendet. Stattdessen wurde ein eigenes BPI Prozessmodell entwickelt, welches einfach gestaltet und für die Modellierung optimiert ist. Ein ausformulierter BPI Prozess wird während des Deployment-Vorgangs in die jpdl Sprache übersetzt. Das BPI Prozessmodell beinhaltet nebst den grundlegenden Elementen wie Start, Ende, Entscheidung und Fork & Join auch Elemente zur Integration von Sharepoint, Web-Services und der ERP-Lösung der Bison Schweiz AG. 4

13 Analyse 3 Analyse Während einerseits aufgrund beruflicher Erfahrung Vorkenntnisse im Bereich des BPI vorhanden waren, bestand andererseits Nachholbedarf bezüglich der BPMN. Innerhalb einer ersten Analysephase bot sich die Gelegenheit, fundiertes Wissen anzueignen. Die ausführlichen Resultate der Analyse sind in einem separaten Dokument 1 festgehalten. Dennoch sollen in diesem Kapitel ein kurzer Rückblick gemacht und die Erkenntnisse zusammengefasst werden. 3.1 Ziel Ziel der Analyse war es, eine Grundlage in Form einer Kosten/Nutzen-Analyse zu schaffen, sodass einerseits eine Priorisierung der im Prototyp umzusetzenden BPMN 2.0 Elemente vorgenommen werden konnte und andererseits Lücken im BPI zur Integration von BPMN Prozessen ersichtlich wurden. 3.2 Vorgehensweise Ausgehend von der BPMN 2.0 Spezifikation [2] (insbesondere Kapitel 10) wurde schrittweise jedes Element betrachtet und analysiert. In erster Linie galt es, Möglichkeiten zu finden, wie die einzelnen Elemente im BPI umgesetzt werden können. Basierend auf diesen Erkenntnissen konnten der jeweilige Aufwand und somit die Entwicklungskosten für die Transformation eines Elementes nach BPI abgeschätzt werden. Ausgehend von der Annahme, dass die zu migrierenden BPMN Prozesse aus fachlicher Sicht modelliert sind, wurde für die Abschätzung des Nutzens hinterfragt, wie oft die jeweiligen Elemente auf fachlicher Ebene eingesetzt werden. Während beispielsweise ein Startereignis in einer Vielzahl von Prozessen zum Einsatz kommt, darf erwartet werden, dass Symbole zur Modellierung des Fehlverhaltens seltener anzutreffen sind und daher eine Unterstützung solcher Elemente durch den Migrationsassistenten einen eher geringen Nutzen hervorbringen würde. Für fachgerechte Aussagen fehlte jedoch das notwendige Wissen bezüglich der Häufigkeit einzelner BPMN Symbole. Auch seitens Bison Schweiz AG waren keine Erfahrungswerte diesbezüglich vorhanden. Im Praxishandbuch BPMN [3 S. 184] wird darauf hingewiesen, dass es sehr von der Organisation und den jeweiligen Bedürfnissen abhängt, welche Symbole auf fachlicher Ebene 2 zum Einsatz kommen und deshalb keine allgemeine Empfehlung abgegeben werden kann. Dennoch wird als erste Orientierung veranschaulicht, mit welcher Häufigkeit die einzelnen Symbole in den Projekten der Autoren eingesetzt wurden 3. Diese Erfahrungswerte dienten vorerst als Grundlage zur Beurteilung des Nutzens, wobei anzumerken ist, dass sich die Werte zukünftig im Umfeld der Bison Schweiz AG durchaus ändern könnten. 1 Migrationsassistent Analyse 2 Mit der fachlichen Ebene sind konkret die Ebenen 1 und 2 des camunda BPMN-Frameworkds (cabpmn) gemeint. Dieses wird in Kapitel noch genauer vorgestellt. 3 Häufigkeit der BPMN Symbole: siehe Migrationsassistent Analyse, Anhang A 5

14 Analyse 3.3 Resultat Die Analyse brachte zunächst hervor, dass durch den Verzicht insbesondere zweier BPMN Konstrukte eine Vielzahl von Elementen nur schwer bis gar nicht im BPI umgesetzt werden kann: 1. Im BPI wird bis zum momentanen Zeitpunkt auf den Einsatz von Unterprozessen verzichtet. In der BPMN hingegen nimmt der Unterprozess eine wichtige Rolle ein und bildet die Grundlage unterschiedlicher Anwendungsfälle: Als strukturierendes Element Zur Wiederverwendung von Teilabläufen Zur Modellierung von Transaktionen und Fehlerhandling Zur Modellierung von Aktivitäten, deren zeitliche Abfolge erst während der Prozessausführung bekannt wird (Ad-hoc-Unterprozess) 2. Die BPMN bietet mit anheftbaren Ereignissen ein äusserst flexibles Mittel, um auf eintretende Ereignisse während der Ausführung von Aktivitäten (wozu auch Unterprozesse gehören) zu reagieren. Der BPI bietet dieses Mittel nur in einem eingeschränkten Mass an. Insbesondere die Kombination eines Unterprozesses und daran angeheftete Ereignisse ist derzeit nicht umsetzbar. Beispielsweise können seriell geschaltete Benutzeraufgaben nicht modelliert werden, wenn diese nach Ablauf einer bestimmten Zeit seit der Erzeugung der ersten Aufgabe eine Handlung (beispielweise eine Eskalation) hervorrufen sollen. Trotz dieser fehlenden Basisfunktionalität seitens BPI darf das Resultat der Analyse durchaus positiv bewertet werden. Relativiert man die Umsetzbarkeit einzelner BPMN Elemente zu ihrem tatsächlichen Nutzen, stellt man fest, dass die nicht unterstützten BPMN Elemente häufig auch nur einen geringen Nutzen aufweisen. Anders betrachtet lassen sich BPMN Elemente mit hohem Nutzen meist gut nach BPI transformieren. Das Resultat der Analyse ist zur besseren Übersicht in fünf Kosten/Nutzen-Matrizen aufgeteilt. Die Abbildung 3 zeigt beispielhaft diejenige der Start- und Endereignisse. Das vollständige Resultat ist in der Dokumentation der Analyse 1 zu finden. 1 Migrationsassistent Analyse, Kapitel 4 6

15 Analyse Nutzen Event Sub-Process Kosten Abbildung 3: Kosten/Nutzen-Matrix der Start- und Endereignisse Aus dieser Matrix ist zu lesen, dass in beinahe jedem Prozess die unbestimmten Start- und Endereignisse verwendet werden. Diese können direkt in den BPI übertragen werden. Auf der Gegenseite unterstützt der BPI keine Ereignis-Unterprozesse, womit in dem Sinne die Umsetzung der Startsymbole des Ereignis-Unterprozesses mit grossen Entwicklungsaufwänden verbunden wäre. Eine Umsetzung ist jedoch nicht zwingend notwendig, da die Ereignis-Unterprozesse in fachlichen Prozessen eher selten eingesetzt werden. Die Resultate der Analyse zeigen die theoretischen Grenzen des Machbaren auf. Mit der Umsetzung eines Prototypen soll die Theorie in die Praxis umgesetzt werden. Die Kosten/Nutzen-Matrizen erlauben es, die einzelnen BPMN Elemente zu priorisieren und den Funktionsumfang abzustecken. 7

16 Umsetzung 4 Umsetzung Basierend auf den Resultaten der zuvor durchgeführten Analyse wurde ein Prototyp eines Migrationsassistenten umgesetzt. Die praktische Arbeit sollte insbesondere die Machbarkeit bestätigen und die zur Umsetzung geschätzten Aufwände konkretisieren. Ausserdem waren neue Erkenntnisse zu erwarten, welche in der Theorie nicht voraussehbar waren. Die Umsetzung des Prototypen dauerte sechs Wochen und basierte auf einer agilen Vorgehensweise. Im Zweiwochenrhythmus wurde das weitere Vorgehen mit der Bison Schweiz AG besprochen und die umzusetzenden BPMN Elemente identifiziert. Nach Ablauf jedes Zyklus fand vor Ort ein Review- Meeting mit unterschiedlichen Interessenten statt. Rückmeldungen konnten auf diese Weise sofort in den nächsten Zyklus einfliessen. Die technischen Details des umgesetzten Prototypen sind der Bison Schweiz AG vorbehalten. Dennoch soll dieses Kapitel die konzeptionellen Erkenntnisse und Problemstellungen beschreiben. Das folgende Kapitel 4.1 beschreibt die zwei grundsätzlichen Herausforderungen, welche die Entwicklung des Prototypen durchgehend begleitet haben. Die anschliessenden Kapitel 4.2 und 4.3 beschreiben die Umsetzung aus unterschiedlichen Blickwinkeln, wobei zwischen der Prozesssemantik (Kapitel 4.2) und der Prozess-View (Kapitel 4.3) unterschieden wird. Das Kapitel 4.4 geht auf die Benutzerschnittstelle eines Migrationsassistenten ein und beschreibt, welche Überlegungen hierzu durchgeführt werden sollten. Das letzte Kapitel 4.5 fasst eine zu Beginn durchgeführte Evaluierung bezüglich der einzusetzenden Mittel zusammen. Hierbei werden unterschiedliche Transformations- Frameworks kurz vorgestellt und deren Einsatz zur Umsetzung des Migrationsassistenten bewertet. Obwohl diese Evaluierung zeitlich vor der eigentlichen Umsetzung stattfand, wird erst zum Schluss darauf eingegangen, da die Erkenntnisse aus vorherigen Kapiteln zum Verständnis beitragen können. 4.1 Grundlegende Herausforderungen Überführung eines fachlichen Prozesses in einen ausführbaren Gemäss [1 S. 13] versuchen die Erfinder der BPMN eine gemeinsame Sprache für Betriebswirtschaftler und IT-Experten zu schaffen. Die BPMN soll daher zur Modellierung sowohl von technischen als auch von fachlichen Prozessmodellen genutzt werden können. Dies wiederspiegelt sich auch im sogenannten camunda BPMN-Framework (cabpmn) [3 S. 15] in Abbildung 4. Ein BPMN Prozess lässt sich auf unterschiedlichen Abstraktionsebenen modellieren. Die Ebenen unterscheiden sich inhaltlich von den eingesetzten Symbolpalletten und dem Detailierungsgrad. Es ist davon auszugehen, dass es sich bei den BPMN Prozessen der Kunden der Bison Schweiz AG jeweils um fachliche Prozesse aus den Ebenen 1 oder 2 handelt. Der BPI als Prozess-Engine forciert hingegen Prozesse auf der technischen Ebene 3a. Diese Prozesse müssen nicht nur syntaktisch und semantisch korrekt sein, sondern auch die notwendigen technischen Details enthalten, sodass sie durch eine Prozess-Engine ausgeführt werden können. 8

17 Umsetzung Ebene 1 Strategisches Prozessmodell Inhalt: Prozess im Überblick Ziel: Schnelles Verständnis Fachlich (Business) Ebene 2 Operatives Prozessmodell Inhalt: Operative Abläufe Ziel: Arbeits- und Umsetzungsgrundlage Technisch (IT) Ebene 3a Technisches Prozessmodell Mit Process Engine Ebene 3b IT-Spezifikation Ebene 4 Implementierung Inhalt: Technische Details Ziel: Umsetzung Ohne Process Engine Abbildung 4: camunda BPMN-Framework (cabpmn) Quelle: Praxishandbuch BPMN [3 S. 15] (leicht angepasst) Bei der Migration eines BPMN Prozesses nach BPI muss ein fachlicher Prozess somit in einen technischen Prozess überführt werden. Im Praxishandbuch BPMN wird in diesem Zusammenhang auch der Begriff Forward Engineering genannt, bei dem das technische aus dem fachlichen Modell generiert wird [3 S. 194]. (Die Autoren nehmen anschliessend noch Bezug auf Roundtrip Engineering: Änderungen am technischen Modell werden dort in das fachliche Modell zurückgeschrieben. Hiervon grenzt sich diese Arbeit jedoch klar ab, d.h. es ist nicht Ziel, einen BPMN Prozess aus einem BPI Prozess zu generieren.) Der BPI stellt somit als Prozess-Engine informelle Anforderungen, die durch einen fachlichen BPMN Prozess mit grosser Wahrscheinlichkeit nicht erfüllt werden und es entsteht eine Informationskluft zwischen Quell- und Zielmodell. In der Regel kann diese Hürde nicht automatisiert durch einen Migrationsassistenten gemeistert werden, womit eine manuelle Nachbearbeitung des BPI Prozesses zur Vervollständigung der technischen Details nicht ausgeschlossen werden kann. Bereits in vermeintlich trivialen Fällen kann eine Nachbearbeitung notwendig werden. Abbildung 5 zeigt als Beispiel auf der linken Seite einen exklusiven Gateway, dessen Bedingung in einer natürlichen Sprache erfasst wurde. Zur automatisierten Ausführung ist es jedoch notwendig, die Bedingung in eine durch die Prozess-Engine interpretierbare formale Sprache zu übersetzen. Obschon die Migration versucht, die erzeugte Decision wie auf der rechten Seite der Abbildung 5 zu konfigurieren, ist eine manuelle Nachbearbeitung unvermeidbar. 9

18 Umsetzung Abbildung 5: Notwendigkeit einer manuellen Nachbearbeitung Die Erwartungshaltung, dass ein fachlicher Prozess durch einen automatisierten Vorgang ohne manuelle Nacharbeiten in einen ausführbaren Prozess umgewandelt werden kann, muss eindeutig gesenkt werden. Stattdessen stellt sich die Frage, wie diese Nacharbeiten möglichst vereinfacht werden können. Dieses Thema darf keineswegs vernachlässigt werden. Das Kapitel 4.4 wird sich mit der Benutzerschnittstelle im Allgemeinen befassen und unter anderem aufzeigen, wie Nacharbeiten dem Endbenutzer präsentiert werden sollten Abhängigkeiten während der Transformation Bei der Transformation eines BPMN Prozesses nach BPI reicht es nicht aus, ein BPMN Element isoliert zu betrachten. Zwischen den Elementen existieren zahlreiche Abhängigkeiten, die es zu berücksichtigen gilt. Diese Abhängigkeiten treten auf unterschiedlichen Ebenen auf, wie die folgenden Beispiele zeigen: 1. Auf technischer Ebene: Referenzen basieren in der BPMN auf intern vergebenen IDs. Im BPI hingegen wird hierzu der im Prozessdiagramm sichtbare Namen verwendet. Dies hat zur Folge, dass ein Name innerhalb eines BPI Prozesses eindeutig sein muss. Der Migrationsassistent hat somit dafür zu sorgen, dass doppelt vorhandene Namen angepasst werden (beispielsweise durch die Vergabe einer Nummer als Suffix). Soll bei der Transformation eines Elementes eine Referenz auf ein anderes Element erzeugt werden, muss folglich dessen Name innerhalb des Zielmodelles bekannt sein. 2. Auf Ebene der Prozesssemantik: Im Gegensatz zur BPMN kennt BPI keinen zusammenführenden exklusiven Gateway. Die Sequenzflüsse werden stattdessen direkt auf die nächste Aktivität geführt. Bei der Migration eines exklusiven Gateways müssen somit die eintreffenden Sequenzflüsse unter Umständen auf die nächste Aktivität umgeleitet und der ausgehende Sequenzfluss weggelassen werden. Die Transformation eines Flussobjektes hat somit einen direkten Einfluss auf die umliegenden Sequenzflüsse. Ein Sequenzfluss kann nicht isoliert betrachtet nach BPI transformiert werden. 10

19 Umsetzung 3. Auf Ebene der Prozess-View: Im BPI sind die Koordinaten derjenigen Aktivitäten, welche einer Swimlane zugeordnet werden (dies sind der Start und der Task), relativ zur oberen linken Ecke der zugeordneten Swimlane. Um die absoluten Koordinaten einer Aktivität zur Swimlane relativieren zu können, muss die Position der Swimlane bekannt sein. Diese wiederum wird dynamisch berechnet und ist gegeben durch die sich rechts befindenden Swimlanes und die darin enthaltenen Aktivitäten. Die Koordinaten einer Swimlane zugeordneten Aktivität hängen somit indirekt von den Positionen anderer Aktivitäten ab. Aufgrund dieser Abhängigkeiten reicht es nicht aus, das BPMN Prozessmodell einmalig zu traversieren und daraus das BPI Modell zu generieren. Fasst man die Abhängigkeiten aller Ebenen zusammen, muss auch mit zyklischen Abhängigkeiten zwischen den Elementen gerechnet werden. Dieser Umstand beeinflusst das technische Design des Migrationsassistenten massgebend. Das Problem konnte bei der Entwicklung des Prototypen gelöst werden. Die umgesetzte Lösung ist jedoch der Bison Schweiz AG vorbehalten und kann an dieser Stelle nicht aufgezeigt werden. 4.2 Transformation der Prozesssemantik Bei der Transformation der Prozesssemantik stellt sich insbesondere die Frage, wie die einzelnen BPMN Elemente ins BPI Prozessmodell zu überführen sind. Diese Frage wurde mehrheitlich bereits in der zuvor durchgeführten Analyse (siehe Kapitel 3) beantwortet. Das folgende Kapitel soll dennoch exemplarisch anhand des Unterprozesses aufzeigen, welche typischen Überlegungen bei der Transformation durchzuführen sind. Anschliessend zeigt das Kapitel anhand eines konkreten Beispiels auf, dass im Falle unnötig komplizierter Transformationen durchaus als Alternative eine Erweiterung des Zielmodells in Betracht gezogen werden darf. Dies kann einerseits die Transformation vereinfachen und andererseits einen Mehrwert für das Zielsystem mit sich bringen. Das letzte Kapitel zeigt auf, wie im Prototypen mit nicht migrierbaren Elementen umgegangen wird Migration von eingebetteten Unterprozessen Aus der Analyse (siehe Kapitel 3) ging unter anderem hervor, dass der Unterprozess ein konzeptionell wichtiges Konstrukt der BPMN darstellt, welches sich in dieser Form nicht nach BPI transformieren lässt. Dennoch sollen die Abläufe innerhalb eines Unterprozesses bestmöglich migriert werden. Eine ideale Lösung kann jedoch nicht erwartet werden. Dieses Kapitel beschreibt schrittweise die bei der Umsetzung des Prototypen durchgeführten Überlegungen betreffend Unterprozesse. Es ist anzumerken, dass in den folgenden Abbildungen die Aktivitäten zur besseren Lesbarkeit manuell ausgerichtet wurden. In erster Linie muss zwischen auf- und zugeklappten Unterprozessen unterschieden werden. Obwohl diese Unterscheidung lediglich eine Eigenschaft auf View-Ebene ist und somit auch das Innere eines zugeklappten Unterprozesses semantisch ausmodelliert sein könnte, betrachtet der Prototyp einfachheitshalber einen zugeklappten Unterprozess als Blackbox und migriert diesen zu einer einzelnen Aktivität (genauer: Erzeugung eines AbstractTask, siehe Kapitel ). Im Folgenden liegt der Fokus auf den aufgeklappten Unterprozessen. 11

20 Umsetzung Der grundsätzliche Lösungsansatz zur Migration eines Unterprozesses besteht darin, den Unterprozess wegzulassen und dessen Inhalt in den äusseren Prozess zu integrieren. Abbildung 6 zeigt die Migration eines einfachen, eingebetteten Unterprozesses. Es ist zu erkennen, dass die Startund Endereignisse des Unterprozesses entfernt und die dazwischen liegende Benutzeraufgabe direkt in den Prozessfluss des äusseren Prozesses eingefügt wird. Bei dieser Vorgehensweise muss jedoch auf einiges verzichtet werden. In erster Linie geht ein wichtiges, strukturelles Element verloren. Dies betrifft auch die Laufzeit, beispielsweise im Falle einer Terminierung innerhalb des Unterprozesses. Das angeheftete Fehlerereignis in Abbildung 6 verliert zudem seinen Aufhänger und muss weggelassen werden. Der darauffolgende Prozesspfad (Error Handling Aktivität) wird jedoch beibehalten. Obschon dieser Prozesspfad in dieser Weise nicht genutzt werden kann, sollen möglichst viele Informationen des ursprünglichen BPMN Prozesses in den BPI Prozess überführt werden. Im besten Fall lässt sich der Prozesspfad durch eine manuelle Nachbearbeitung wieder in den normalen Prozessfluss integrieren. Abbildung 6: Transformation eines eingebetteten Unterprozesses mit angeheftetem Ereignis Während ein eingebetteter Unterprozess höchstens ein Startereignis enthalten darf [2 S. 430], wird die Anzahl der Endereignisse in der BPMN nicht eingeschränkt [2 S. 246]. Wie in Abbildung 7 dargestellt, werden im Falle mehrerer Endereignisse die Prozesspfade nach der Transformation über einen Join zusammengeführt. Abbildung 7: Transformation eines eingebetteten Unterprozesses mit mehreren Endereignissen Die Problematik dieser Vorgehensweise ist jedoch, dass der Einsatz eines Joins nicht zwingend korrekt sein muss. Abhängig von den verzweigenden Gateways und der Struktur des Prozessflusses wäre eine parallele, eine exklusive oder gar eine inklusive Zusammenführung notwendig. Eine automatisierte Entscheidungsfindung bezüglich der korrekten Zusammenführung ist jedoch sehr aufwändig und in ungünstigen Situationen gar nicht möglich. Der Prototyp fügt daher stets einen Join ein und vermerkt als manuelle Nacharbeit (siehe Kapitel 4.4.3) die Kontrolle des Prozessflusses. Im nächsten Schritt gilt es zu beachten, dass Start- und Endereignisse innerhalb eines Unterprozesses optional sind [2 S. 238]. (Allerdings ist ein Startereignis zwingend, wenn ein Endereignis vorhanden ist [2 S. 239]). Ist kein Startereignis gegeben, müssen zur Laufzeit beim Eintreffen eines Tokens alle diejenigen Aktivitäten und Gateways des Unterprozesses instanziiert werden, welche keine 12

21 Umsetzung eingehenden Sequenzflüsse haben [2 S. 430]. Diese Eigenschaft kann in der Praxis zur Modellierung von parallel auszuführenden Aktivitäten genutzt werden, wie es die Abbildung 8 zeigt. Abbildung 8: Transformation eines eingebetteten Unterprozesses ohne Start- und Endereignis Die Transformation eines Unterprozesses ohne Start- und Endereignis erfolgt, indem ein Fork und ein Join eingefügt und diese mit den Aktivitäten ohne ein- respektive ausgehende Sequenzflüsse verbunden werden. Die Ausgangslage in Abbildung 8 ähnelt einem Ad-hoc-Unterprozess. Ein Ad-hoc-Unterprozess (gekennzeichnet mit einer Tilde-Markierung) wird verwendet, wenn die Ausführungsreihenfolge der darin enthaltenen Aktivitäten nicht oder nur teilweise im Prozess modelliert werden kann und stattessen erst während der Prozessausführung bekannt wird. Der BPI kennt kein vergleichbares Konstrukt. Am ehesten kann dieses Verhalten nachgebildet werden, indem alle Aktivitäten wie in Abbildung 9 mittels Fork und Join parallel ausgeführt werden. Abbildung 9: Transformation eines Ad-hoc-Unterprozesses Die in diesem Kapitel aufgezeigten Beispiele lassen vermuten, dass bei der Umsetzung des Migrationsassistenten entsprechend viele Fallunterscheidungen gemacht werden müssen. Die Implementierung ist jedoch denkbar einfach und deckt dennoch sämtliche Fälle ab. Vereinfacht ausgedrückt werden zunächst alle Start- und Endereignisse entfernt. Die zum Unterprozess führenden Sequenzflüsse werden zu derjenigen Aktivität ohne einen eingehenden Sequenzfluss geführt. Sind mehrere derartige Aktivitäten vorhanden, wird ein Fork eingefügt und mit den Aktivitäten verbunden. Die Handhabung der vom Unterprozess wegführenden Sequenzflüsse erfolgt analog Erweiterung des Zielmodells als Alternative zur Migration Oftmals findet ein BPMN Element im BPI zwar nicht ein direktes Pendant, könnte aber mittels einer geeigneten Umwandlung durch ein anderes Konstrukt ersetzt werden, welches sich zur Laufzeit gleich oder zumindest ähnlich verhält. Ein derartiger Fall kann sich jedoch als Gratwanderung unterschiedlicher Aspekte erweisen, wie das folgende Beispiel zeigt. In der BPMN kann eine Aktivität wie auf der linken Seite von Abbildung 10 zu sehen als Schleifenaktivität markiert werden. Mittels Attributen lassen sich eine Wiederholbedingung und die maximale Anzahl Wiederholungen definieren. Die Überprüfung der Wiederholbedingung kann zudem entweder vor oder nach der Ausführung der Aktivität durchführt werden. 13

22 Umsetzung Abbildung 10: Umsetzung einer Schleifenaktivität Wie auf der rechten Seite von Abbildung 10 zu erkennen, muss im BPI eine Schleife im Prozessfluss explizit mittels Zählervariablen und Decision ausmoduliert werden. Obschon zwar eine automatische Migration möglich ist, sind einige Nachteile zu bekunden. Durch die drei zusätzlichen Aktivitäten nimmt die Lesbarkeit markant ab. Ausserdem erhält mit dem Setzen und Dekrementieren einer Variablen ein rein technischer Aspekt Einzug ins Prozessdiagramm. Der Migrationsaufwand ist verhältnismässig hoch. Werden die drei oben erwähnten Attribute bei der Migration beachtet, kann das Resultat im BPI acht unterschiedliche Ausprägungen haben. Einerseits sind diese in der Migrationslogik zu beachten und andererseits kann nicht davon ausgegangen werden, dass diese Attribute auf fachlicher Ebene durch den Prozessdesigner tatsächlich gesetzt wurden. Weiter ist auf der View-Ebene mit einem erhöhten Aufwand zu rechnen, wenn die neu hinzugefügten Aktivitäten korrekt positioniert werden sollen. In einer idealen Lösung muss allenfalls Platz innerhalb des Prozessdiagrammes geschaffen und die neuen Aktivitäten ausgerichtet werden. (Dies ist beim Prototypen nicht der Fall. Die Aktivitäten in Abbildung 10 wurden manuell positioniert.) Aufgrund der genannten Nachteile stellt sich die berechtigte Frage, ob eine Erweiterung des BPI Prozessmodells durch die Implementierung einer Schleife nicht sinnvoller wäre. Dieser Ansatz wäre mit einigen Vorteilen verbunden. Einerseits wird die Lesbarkeit verbessert und die Migration von BPMN Prozessen vereinfacht. Andererseits lässt sich eine neue Funktionalität auch ausserhalb dieses Kontextes bei der Erstellung neuer Geschäftsprozesse nutzen. Die Aufwände beim Prozess-Design und die damit verbundenen Kosten werden verringert. Die Implementierung einer Schleife wird nun von der Bison Schweiz AG in Erwägung gezogen. Dieses Beispiel zeigt auf, dass in Anbetracht einer komplizierteren Migration eines Elementes stets beachtet werden sollte, dass alternativ auch das Zielmodell um Funktionalitäten erweitert werden kann. Situationsbedingt kann dadurch sogar ein signifikanter Mehrwert für das Zielsystem generiert werden Umgang mit nicht migrierbaren Elementen Das BPI Prozessmodell wurde auf eine einfache Modellierung hin optimiert und fokussiert sich daher auf die wesentlichen Funktionen. Mit der BPMN hingegen liegt eine mächtige und flexibel einsetzbare Notation als Ausgangslage vor. Folglich sind BPMN Elemente anzutreffen, die kein vergleichbares Pendant im BPI Prozessmodell haben. Diese Elemente dürfen durch den Migrationsassistenten nicht einfach ignoriert werden. Es müssen stattdessen Lösungen gefunden werden, wie mit nicht unterstützten BPMN Elemente umgegangen werden soll. 14

23 Umsetzung Der Prototyp reagiert je nach BPMN Element unterschiedlich. Es lassen sich drei unterschiedliche Verhaltensweise ausmachen, welche im Folgenden kurz beschrieben werden. Zur Verdeutlichung kann der Beispielprozess 3 aus Anhang B.3 beigezogen werden. Er beinhaltet mehrheitlich nicht migrierbare BPMN Elemente Rückführung auf unterstütztes Element Die BPMN kennt einige Typen von Start- und Endereignissen, welche im BPI nicht unterstützt werden. In diesem Fall wird der Typ ignoriert und das Ereignis auf das unbestimmte Start- oder Endereignis zurückgeführt. Eine zusätzliche Warnung während der Migration weist auf das nicht unterstützte Ereignis hin. Diese Vorgehensweise wurde für Start- und Endereignisse gewählt. Sie hat den Vorteil, dass die Lesbarkeit des resultierenden BPI Prozessdiagramms erhalten bleibt und weiterhin ein Startereignis erkennbar ist. Der entstehende Informationsverlust wird in Kauf genommen Überführung in ein Vertreterobjekt Viele nicht unterstützte Elemente lassen sich nicht auf ein passendes Objekt rückführen. Dennoch ist es wünschenswert, möglichst viele Informationen in den BPI Prozess zu übertragen. Um dies bewerkstelligen zu können, wurde der BPI um eine provisorische, neue Aktivität, dem AbstractTask, erweitert 1. Hierbei handelt es sich um eine einfache Aktivität, bestehend aus einem Namen und einer Beschreibung. Zur Laufzeit führt der AbstractTask keine Logik aus und setzt stattdessen die Prozessausführung unmittelbar fort. Der AbstractTask kommt für eine Vielzahl von Anwendungsfällen zum Einsatz: Der AbstractTask dient als Ersatz für zugeklappte Unterprozesse, Ereignis-Unterprozesse und nicht unterstützte Gateways, Ereignisse und Aktivitäten (hierzu gehören insbesondere einige Task-Typen). In diesen Fällen weist der AbstractTask im Prozessdiagramm auf die Existenz eines nicht unterstützten Elementes hin und ermöglicht ausserdem, den Prozesspfad zu erhalten. Der BPI verlangt innerhalb eines Prozessmodells exakt ein Startereignis. Falls im BPMN Prozess mehrere Startereignisse festgelegt wurden, werden die überzähligen durch einen AbstractTask ersetzt. Der BPI bietet aktuell noch keine Möglichkeit, Kommentare in einem Prozessdiagramm einzufügen. Textanmerkungen werden daher ebenfalls als AbstractTask mit einer entsprechenden Beschreibung umgesetzt Keine Transformation Da der BPI die Datenmodellierung den Umsystemen überlässt, werden Datenobjekte bewusst nicht ins BPI Prozessdiagramm übertragen, Bei der Migration werden Datenobjekte daher weggelassen und eine Log-Meldung generiert. Die angehefteten Ereignisse werden im Gegensatz zu allen anderen Ereignissen aus Gründen der Übersicht ebenfalls weggelassen (siehe Abbildung 6 in Kapitel 4.2.1). Ob dieses Verhalten richtig ist, wird sich in der Praxis zeigen müssen. Allenfalls kann das Verhalten mit wenig Aufwand angepasst werden. 1 Der BPI sollte ursprünglich durch die Entwicklung des Prototypen unangetastet bleiben. Die Einführung eines AbstractTasks wurde jedoch als sinnvoll erachtet (siehe Sitzungsprotokoll vom , Anhang E.5). Weitere Änderungen am BPI wurden nicht durchgeführt. 15

24 Umsetzung 4.3 Transformation der Prozess-View Wie einführend in Kapitel 2.1 bereits erwähnt, wurde mit der BPMN 2.0 spezifiziert, wie ein BPMN Prozess serialisiert werden muss. Dies ermöglicht insbesondere den Modellaustausch zwischen unterschiedlichen BPMN Tools. Die BPMN trennt dabei strikt zwischen der Prozesssemantik und den Informationen zur graphischen Darstellung der einzelnen Symbole. Betrachtet man einen BPMN Prozess in seiner serialisierten Form (XML), sind dementsprechend zwei Teilbäume zu erkennen. Das View-Modell wird Diagram Interchange (DI) genannt. Es beinhaltet insbesondere die Positionen und Grössen der verwendeten BPMN Elemente, aber beispielsweise auch die Orientierung der Lanes (horizontal oder vertikal) oder ob ein Unterprozess zu- oder aufgeklappt vorliegt. Die Trennung zwischen Prozesssemantik und Darstellung soll gemäss [4] auch mehrere Ansichten desselben Prozesses ermöglichen. Das BPI Prozessmodell vereint Prozesssemantik und Darstellung. Dies bedeutet konkret, dass die Koordinaten einer Aktivität als Teil der Aktivität selbst betrachtet werden. Diese Verschmelzung ist durch die entstehende Einfachheit durchaus begründet. Für die Migration hat dies zur Folge, dass zwei Modelle zu einem zusammengeführt werden müssen. Dies stellt zwar keine grössere Herausforderung dar, kann aber das Design der Transformationslogik beeinflussen. Im folgenden Kapitel wird anhand eines einfachen Beispiels aufgezeigt, welchen Seiteneffekt die Verschmelzung von Semantik und Darstellung haben kann. Werden im BPI Prozessmodell neue Aktivitäten eingefügt, kann beinahe beliebig viel Aufwand in die Entwicklung einer optimalen Layout-Berechnung investiert werden. Mit der Bison Schweiz AG wurde jedoch vereinbart, dass neu eingefügte Aktivitäten die bereits bestehenden im Mindesten nicht überdecken sollten. Eine manuelle Ausrichtung wird vorerst in Kauf genommen. Dadurch vereinfacht sich die Entwicklung des Migrationsassistenten immens. In den Kapiteln und wird dennoch aufgezeigt, welche Koordinatentransformationen bei der Migration notwendig sind. Sie sind jedoch denkbar einfach gestaltet Verschmelzung von Prozesssemantik und -darstellung Sowohl in der BPMN als auch im BPI werden Sequenzflüsse (im BPI Transitions genannt) zum Festlegen der Ausführungsreihenfolge der Aktivitäten eingesetzt. Beide Modelle erlauben, Sequenzflüsse mit einem Namen zu versehen und die Sequenzflüsse zur optischen Verbesserung zu knicken. Sieht man von den in der BPMN bekannten Standard- und bedingten Sequenzflüssen ab, bieten beide Modelle somit dieselben Möglichkeiten. Der Aufwand, einen BPMN Sequenzfluss in eine BPI Transition zu überführen, ist entsprechend gering einzuschätzen. Bei genauerer Betrachtung ist festzustellen, dass Sequenzflüsse mit Eckpunkten in der BPMN und im BPI unterschiedlich modelliert werden und bei der Migration eine Umstrukturierung verlangen. Abbildung 4 versucht den Unterschied zu verdeutlichen. Eine Verbindung zwischen zwei Aktivitäten A und B besteht in der BPMN aus einem Sequenzfluss, festgelegt im semantischen Prozessmodell. Optional werden innerhalb des Darstellungsmodells (View) Eckpunkte hinzugefügt. Für die Prozessausführung ist das Darstellungsmodell irrelevant und kann weggelassen werden. 16

25 Umsetzung A B A B Abbildung 11: Modellierung von Sequenzflüssen in BPMN (links) und BPI Im BPI wird ein Eckpunkt mittels einer leeren Aktivität modelliert. Zwischen zwei Aktivitäten A und B und den Eckpunkten wird jeweils ein eigener Sequenzfluss eingefügt. Der BPI Designer täuscht dem Benutzer einen durchgehenden Sequenzfluss lediglich vor. Somit wird im Prinzip die Prozesssemantik genutzt, um einen Darstellungsaspekt zu modellieren. Dieses Modelldesign lässt sich damit begründen, dass das BPI Modell für die Modellierung im BPI Designer optimiert wurde und für die Laufzeitumgebung während des Deployment-Vorgangs nach jpdl transferiert wird. Für die Entwicklung der Modelltransformation dürfen zwei Erkenntnisse festgehalten werden. Zunächst zeigt dieses einfache Beispiel, dass sich eine Analyse der Differenzen zwischen dem Quellund dem Zielmodell nicht auf die sichtbare Notation beschränken darf. Vielmehr gilt es, die strukturellen Differenzen im Metamodell aufzudecken. Für die eigentliche Umsetzung des Migrationsassistenten hat dieses Beispiel zur Folge, dass die Prozessdarstellung (Ebene der View) ebenfalls zur Erzeugung von BPI Aktivitäten (Ebene der Semantik) führen kann. Das DI-Modell muss somit bei der Erzeugung der semantischen Modellobjekte zur Verfügung stehen Transformierter Referenzpunkt der Flussobjekte Sowohl in der BPMN als auch im BPI wird zur Positionierung eines Flussobjektes die obere linke Ecke der Aktivität als Referenzpunkt verwendet. Würden die Koordinaten einer Aktivität bei der Migration unverändert übernommen werden, käme es aufgrund unterschiedlicher Objektgrössen zu optischen Verschiebungen, wie in Abbildung 12 zu sehen. Abbildung 12: Optische Verschiebung aufgrund unterschiedlicher Objektgrössen Dieser unerwünschte Effekt kann sehr einfach behoben werden, indem das Zentrum der BPMN Flussobjekte berechnet und dieses als Zentrum für die BPI Aktivitäten verwendet wird. Das Resultat erfüllt die natürlichen Erwartungen eines Benutzers, d.h. die Aktivitäten sind sowohl horizontal als auch vertikal korrekt zueinander ausgerichtet. 17

26 Umsetzung Spiegelung des Prozessdiagramms Die sogenannten Swimlanes bilden im BPI das Pendant zu den BPMN Lanes. Im Unterschied zu den Lanes verlaufen Swimlanes immer vertikal. Horizontal ausgerichtete Lanes sind jedoch häufig anzutreffen, womit ein BPMN Prozessdiagramm für eine erfolgreiche Migration allenfalls gedreht oder gespiegelt werden muss. Mit der Annahme, dass das Startereignis durch den Prozessdesigner im Diagramm meist oben links platziert wird und dies beim migrierten BPI Prozess beibehalten werden soll, wird die Spiegelung an der zweiten Winkelhalbierenden gegenüber einer Drehung bevorzugt. Der Nullpunkt des Koordinatensystems kommt sowohl in der BPMN als auch im BPI auf die obere linke Ecke zu liegen. Im Gegensatz zum Kartesischen Koordinatensystem verläuft die y-achse in positiver Richtung nach unten. Mit diesen Gegebenheiten kann eine Spiegelung an der zweiten Winkelhalbierenden sehr einfach erreicht werden, indem die x- und y-koordinaten einer Aktivität miteinander vertauscht werden. Als unerwünschter Nebeneffekt der Spiegelung zeigt sich, dass die Abstände zwischen den Aktivitäten nicht mehr zu stimmen scheinen. In Abbildung 13 ist zu erkennen, dass sich einerseits die beiden Benutzeraufgaben überschneiden und andererseits der vertikale Abstand zwischen Fork und Task A im Vergleich zum ursprünglichen BPMN Prozess zu gross ist. Abbildung 13: Durch die Spiegelung verursachte Verzerrung der Zwischenräume Grund für die Verzerrung ist, dass zwar die Koordinaten vertauscht, die Höhen und Breiten der Aktivitäten hingegen unverändert bleiben. Der Effekt wird durch das grosse Verhältnis zwischen Breite und Höhe der BPI Aktivitäten zusätzlich verstärkt. Diesem Nebeneffekt wird auf einfache Weise entgegengetreten, indem der Migrationsassistent die Angabe einer horizontalen und vertikalen Streckung erlaubt. Die Standardwerte der Streckungsfaktoren sind auf 1.2 (horizontal) und 0.8 (vertikal) gesetzt. Es wäre auch denkbar, dass die Streckungsfaktoren automatisch berechnet werden. 18

27 Umsetzung 4.4 Benutzerschnittstelle Obwohl oder gerade weil die Benutzerschnittstelle im Zusammenhang mit einer Modelltransformation oft nicht die primären Fragestellungen hervorruft, sollen die hierzu durchgeführten Überlegungen in diesem Kapitel festgehalten und kurz aufgezeigt werden. Im allgemeinen Kontext eines Migrationsassistenten kann die Benutzerschnittstelle wie in Abbildung 14 dargestellt in drei Phasen unterteilt werden: Benutzereingabe, -interaktion und -rückmeldung. BPMN Prozess Transformation BPI Prozess Benutzerrückmeldung Benutzerinteraktion Benutzereingabe Abbildung 14: Benutzerschnittstellen der Prozesstransformation Benutzereingabe Als Benutzereingabe wird diejenige Benutzerschnittstelle bezeichnet, welche vor der Ausführung der Transformation zur Parametrisierung der Transformation dient. Hierzu gehören die Angaben zur Einund Ausgabedatei, BPI Prozessnamen, Skalierung etc. Hervorzuheben sind diejenigen Eingaben, welche auf dynamisch ermittelten BPMN Prozessdaten basieren (beispielsweise die Auswahl des zu transformierenden Pools). Diese Eingaben haben zur Folge, dass das BPMN Prozessmodell zur Benutzereingabe bereits geladen werden muss Benutzerinteraktion Als Benutzerinteraktion wird die Benutzerschnittstelle während eines laufenden Transformationsprozesses bezeichnet. Hierzu gehören insbesondere Rückfragen im Falle unvollständiger Modelle oder zur Entscheidungsfindung. Rückfragen sind jedoch aus unterschiedlichen Gründen zu vermeiden: Im Falle grosser Prozesse kann es zu einer unvorhersehbar grossen Anzahl Rückfragen kommen. Allenfalls können Rückfragen vom Anwender aufgrund von fehlenden Kenntnissen gar nicht beantwortet werden, womit die Transformation blockiert wird. Für eine Client-Server-Architektur (wie es beim BPI der Fall ist) nimmt der Integrationsaufwand des Migrationsassistenten durch Rückfragen markant zu, sofern die Transformationslogik auf dem Server ausgeführt werden soll. Als weitere Bestandteile der Benutzerinteraktion können Fortschrittsanzeigen und Statusmeldungen genannt werden, obschon es sich hierbei um eine unidirektionale Kommunikation handelt. Diese sind, im Gegensatz zu Rückmeldungen, durchaus erwünscht. Sie müssen jedoch beim Design der Transformation berücksichtigt werden. 19

28 Umsetzung Benutzerrückmeldung Als Benutzerrückmeldung wird diejenige Benutzerschnittstelle bezeichnet, welche dem Benutzer erst nach der Ausführung der Transformation angezeigt wird. Hierzu zählen unter anderem Informationen bezüglich der durchgeführten Transformation sowie Warnungen, aufgetretene Fehler und manuell zu erledigende Aufgaben. Die grosse Schwierigkeit kann hierbei sein, dem Anwender das richtige Mass an Transparenz zu schaffen. Bereits in Kapitel wurde begründet, weshalb ein migrierter BPI Prozess oftmals manuelle Nacharbeiten verlangt. Ob diese effizient erledigt werden können, hängt zu einem grossen Teil von der Qualität der Benutzerrückmeldungen ab. Wird diesen bei der Entwicklung eines Migrationsassistenten zu wenig Aufmerksamkeit gewidmet, kann die Nacharbeit zu einer mühsamen und langwierigen Angelegenheit werden. Die meisten Rückmeldungen nehmen jeweils Bezug zu einem oder mehreren Elementen des Quelloder Zielmodells. Beispielsweise: Das BPMN Element X konnte nicht migriert werden. Das BPI Element Y muss manuell konfiguriert werden. Das BPMN Element X wurde ins BPI Element Y transferiert. Wie aber können die jeweiligen Elemente innerhalb der Prozessdiagramme identifiziert werden? In textueller Form wäre es denkbar, die Elemente aufgrund ihrer Eigenschaften zu beschreiben. Hierzu gehören der Name und der Typ sowie die Koordinaten des Elementes. Aufgrund der relativ einfachen Umsetzung wurde dieser Ansatz für den Prototypen gewählt. Für eine Endlösung muss davon jedoch abgeraten werden. Die Suche nach dem jeweiligen Element innerhalb des Prozessdiagramms ist für grosse Prozesse schlicht unzumutbar und ineffizient. Eine markante Verbesserung kann erreicht werden, wenn die Meldungen in das Prozessdiagramm integriert werden. Die Meldungen werden somit Bestandteil des Prozessmodells. Dies wäre sowohl für das Quell- als auch das Zielmodell denkbar. Seitens BPMN Prozess könnten die Meldungen in Form von Textanmerkungen an die entsprechenden Elemente angebracht werden. Die notwendigen Mittel sind vorhanden. Allerdings wird für den weiteren Verlauf das Ausgangsmodell benötigt. Im Fokus steht jedoch die Nachbearbeitung des BPI Prozesses. Besser wäre, die Meldungen in den BPI Prozess zu integrieren. Nebst der optischen Zuweisung zum betroffenen Element hat dieser Ansatz auch den Vorteil, dass die Meldung nach Bedarf vom Benutzer entfernt werden können (beispielsweise sobald die beschriebene Aufgabe erledigt ist). Für eine Integration der Rückmeldungen in den BPI Prozess sind Erweiterungen sowohl im Prozessmodell als auch im BPI Designer notwendig. Es lassen sich jedoch durchaus Synergien nutzen, indem ein allgemeines Mittel zur Dokumentation von Prozessen (vergleichbar mit Textanmerkungen aus der BPMN) geschaffen wird Umsetzung im Prototyp Der Prototyp bietet zu Benutzereingabe das in Abbildung 15 dargestellte GUI an. Mit Ausnahme von Statusmeldungen und Log-Ausgaben wird auf eine Benutzerinteraktion verzichtet. Aus Gründen der Einfachheit werden Benutzerrückmeldungen als Textnachrichten ausgegeben. Die Meldungen sind nach dem verursachenden Element gruppiert und erscheinen in Form eines Baumes. Es ist klar zu 20

29 Umsetzung betonen, dass es sich hierbei um eine rudimentäre Lösung handelt, welche für einen produktiven Einsatz ungeeignet ist. Abbildung 15: Benutzerschnittstelle des umgesetzten Prototypen 21

30 Umsetzung 4.5 Evaluierung der eingesetzten Mitteln Für die Umsetzung des Prototypen zur Migration von BPMN Prozessen nach BPI mussten vorgängig architektonische Entscheide getroffen werden 1, welche nachträglich nur mit grossem Aufwand hätten korrigiert werden können. Dies beinhaltet insbesondere die einzusetzenden Mittel zur Modelltransformation sowie die zu verwendenden Modellklassen. Zur Entscheidungsfindung wurden experimentell unterschiedliche Ansätze in ersten Schritten angewendet. Es galt einen einfachen Musterprozess unter Einsatz unterschiedlicher Hilfsmittel ins BPI Prozessmodell zu migrieren. Der Prozess bestand aus Start- und Endereignis sowie zwei Benutzeraufgaben. Die Sequenzflüsse waren teils geknickt. Bereits bei diesem einfachen Beispielprozess galt es, einige Herausforderungen zu überwinden: Die BPMN trennt im Gegensatz zum BPI die Darstellung eines Elementes (d.h. Position und Grösse) von deren Semantik. Bei der Migration müssen diese beiden Teile miteinander verschmolzen werden (siehe Kapitel 4.3). Sequenzflüsse mit Eckpunkten werden in der BPMN und im BPI unterschiedlich modelliert und verlangen bei der Migration eine Umstrukturierung (siehe Kapitel 4.3.1). Die Koordinaten der einzelnen Elemente müssen transformiert werden: Die obere linke Ecke eines BPI Diagrammes kommt aufgrund der dargestellten Swimlane auf den Punkt (0, 23) zu liegen. Aufgrund der unterschiedlichen Elementgrössen muss der Mittelpunkt eines Elementes als Referenzpunkt verwendet werden (siehe Kapitel 4.3.2). Idealerweise sollten Elemente im BPI an den Raster angedockt werden. Die Rastergrösse ist im BPI Designer auf 20 Pixel festgelegt. In der BPMN basieren sämtliche Objektreferenzen auf eindeutigen, intern vergebenen IDs. Der BPI verwendet hierzu die (sichtbaren) Objektnamen. Zwei Benutzeraufgaben beispielsweise dürfen somit nicht gleich benannt werden! Bei der Migration müssen sämtliche Referenzen entsprechend ersetzt werden. Die Migration wurde auf drei unterschiedliche Arten implementiert: Als reine Java-Applikation Als Java-Applikation basierend auf SiTra (Simple Transformer) Mittels der Atlas Transformation Language (ATL) Des Weiteren stand XSLT zur Auswahl. Dieser Ansatz wurde jedoch aufgrund der zu erwartenden Komplexität nicht weiter verfolgt. Der Prototyp wurde letztendlich als reine Java-Applikation umgesetzt. Dennoch sollen die evaluierten Mittel kurz beschrieben und der Entscheid begründet werden. 1 Meilenstein 1 in Projektplanung, siehe Anhang D.1 22

31 Umsetzung Simple Transformer (SiTra) Die Java Library SiTra 1 wurde an der Universität von Birmingham entwickelt und stellt ein einfaches Framework zur Implementierung von Modelltransformationen dar. Eine Transformation wird anhand von Regeln festgelegt. Hierbei handelt es sich um Implementierungen eines Rule Interfaces. Jede Regel ist für die Transformation eines einzelnen Modelltyps des Ursprungmodells verantwortlich. Durch den Einsatz von SiTra kann kein Programmieraufwand eingespart werden kann. SiTra bietet vielmehr eine Möglichkeit, den Migrationscode zu strukturieren. Vorteile: Einfaches, leicht verständliches und überschaubares Framework Einsatz beliebiger Modellklassen möglich Nachteile: Teils unerwünschtes Verhalten und kleinere Hindernisse Keine Aufwandersparnisse gegenüber einer eigens entwickelten Migration SiTra geht grundsätzlich davon aus, dass stets ein Quellobjekt in ein Zielobjekt transformiert wird. Dies ist beispielsweise bei Sequenzflüssen nicht zwingend der Fall Atlas Transformation Language (ATL) Die Atlas Transformation Language (kurz ATL) ist eine eigene Programmiersprache zur Transformation von Modellen. Gemäss Wikipedia [5] wurde ATL von OBEO 2 und INRIA 3 als Antwort auf die QVT (Query View Transformation) Ausschreibung der OMG 4 zur Standardisierung einer Transformationssprache entwickelt. ATL kommt in Form eines Eclipse Plugins daher und basiert auf EMF 5 Modellen. Transformationen werden insbesondere mittels imperativen aber auch mit deklarativen Konzepten festgelegt, womit ATL als hybride Sprache bezeichnet werden kann. Modellabfragen werden mit Hilfe von OCL 6 Ausdrücken vorgenommen. Wichtiger Bestandteil einer Transformation bilden die sogenannten Rules, welche deklarativ festlegen, wie Modelle eines bestimmten Typs transformiert werden sollen. Das folgende Snippet zeigt zur Veranschaulichung, wie im Falle eines BPMN Endereignisses vom Typ TEndEvent eine BPI BoxChoice mit einem darin enthaltenen End erzeugt wird. Die Koordinaten der neu erstellten Box werden mittels eigens definierter Methoden in ATL Helpers genannt transformiert. rule EndEvent2End { from s: BPMN!TEndEvent to t: BPI!BoxChoice ( end <- tbox ), tbox: BPI!End ( name <- 'End', x <- thismodule.getshape(s.id).gettransformedx(), y <- thismodule.getshape(s.id).gettransformedy() ) } 1 SiTra (Simple Transformer): 2 OBEO: 3 INRIA (Institut national de recherche en informatique et en automatique): 4 OMG (Object Management Group): 5 EMF (Eclipse Modeling Framework): 6 OCL (Object Constraint Language) Spezifikation: 23

32 Umsetzung Die vorausgesetzten EMF Modelle lassen sich mit Hilfe des Eclipse EMF Plugins aus den BPMN- und BPI-XML-Schemen generieren. Beim Einsatz von ATL musste festgestellt werden, dass eine lange Lernphase eingerechnet werden muss, um sich mit den Prinzipien von ATL vertraut machen zu können. Während einfache Transformationen kein Problem darstellen und effizient umgesetzt werden können, bestand für komplexe Logiken eine grosse Ungewissheit bezüglich der Umsetzbarkeit. Weiter ist anzumerken, dass die Ausführung einer ATL Transformation sehr abgegrenzt scheint. Schnittstellen für eine Benutzerinteraktion während der Ausführungsphase (siehe Kapitel 4.4.2) konnten keine gefunden werden. Die Ausgabe von Textnachrichten beschränkt sich auf das Schreiben von Meldungen in eine Datei. Vorteile: Weniger Programmieraufwand und bessere Lesbarkeit aufgrund des Einsatzes einer domänenspezifischen Sprache. Nachteile: Die Machbarkeit ist nicht vollständig sichergestellt Know-How ist nicht vorhanden, auch nicht in der Bison Schweiz AG Setzt ein EMF Modell voraus Editor Unterstützung beschränkt sich aufs Wesentliche Interaktion mit Anwender nur sehr beschränkt möglich Einsatz generierter Metamodelle Sofern aufgrund eines eingesetzten Transformations-Frameworks keine Schranken vorgegeben sind, stellt sich die Frage, mit welchen technischen Mitteln Quell- und Zielmodell gelesen respektive geschrieben werden. Da keine Speicherprobleme erwartet werden, liegt keine Notwendigkeit für eine Datenstrombasierte Vorgehensweise (beispielsweise mittels SAX) vor. In Anbetracht der zahlreichen Abhängigkeit innerhalb des BPMN Prozessmodells (siehe Kapitel 4.1.2) ist es lohnenswert, das Modell vollständig in den Speicher zu laden. Hierfür bringt der Einsatz von statisch generierten Modellklassen einige Vorteile mit sich. Hierzu gehören: erhöhte Qualität und Stabilität, bessere Wartbarkeit und Nachhaltigkeit. Für die Implementierung des Prototypen wurden drei Modelle in Betracht gezogen: Apache XMLBeans, Eclipse Modeling Framework (EMF) und das BPI eigene Prozessmodell der Bison Schweiz AG. Apache XMLBeans 1 generiert Modellklassen aufgrund eines XML-Schemas. Als grosser Vorteil erlauben die generierten Klassen Modellabfragen mittels XQuery oder XPath. Das Framework ist leicht verständlich und innert kürzester Zeit einsetzbar. Als Nachteil ist zu nennen, dass zur Laufzeit kein Metamodell zur Verfügung steht. Das mächtige Eclipse Modeling Framework (EMF) 2 geht über das Generieren von Modellklassen hinaus und stellt eine Vielzahl von Werkzeugen zur Verfügung (sie sind für den Prototypen jedoch 1 Apache XMLBeans: 2 EMF (Eclipse Modeling Framework): 24

33 Umsetzung irrelevant). Zur Laufzeit steht ein Metamodell zur Verfügung. Für einen Einsatz von EMF spricht, dass EMF bereits bei der Bison Schweiz AG angewendet wird wenn auch nicht innerhalb von BPI. Als drittes Framework ist das BPI eigene Prozessmodell der Bison Schweiz AG zu nennen. Die Modellklassen werden ebenfalls mit Hilfe eines Generators aufgrund eines XML-Schemas generiert. Der Generator fokussiert sich jedoch auf eine Teilmenge aller Möglichkeiten von XSD und kann daher nicht für das BPMN-Schema zum Einsatz kommen Architekturentscheid Für die Entwicklung des Prototypen wurde entschieden, aufgrund der zu erwartenden Komplexität auf ein Transformations-Framework zu verzichten. Wenn auch mit leicht grösseren Aufwänden zu rechnen ist, soll die Transformation mit reiner Java-Programmierung implementiert werden. Hiermit werden keine Schranken durch ein Framework vorgegeben und es kann jederzeit flexibel auf neue Anforderungen reagiert werden. Als Modellklassen kommt einerseits EMF zum Lesen des BPMN Prozesses und andererseits das BPI eigene Modell zum Schreiben des BPI Prozesses zum Einsatz. Hiermit sollen die bereits eingesetzten Mittel der Bison Schweiz AG verwendet werden. Die BPI Modellklassen bringen ausserdem den grossen Vorteil mit sich, dass diese im Falle von Schemaänderungen durch die Mitarbeiter stets neu generiert werden. 25

34 Schluss 5 Schluss 5.1 Fazit Die durchgeführte Analyse hat die Unterschiede zwischen der BPMN und dem BPI Modell gut aufgezeigt. Es darf festgehalten werden, dass die in der Praxis für fachliche Geschäftsprozesse am häufigsten eingesetzten BPMN Symbole meist relativ gut nach BPI transformiert werden können. Dennoch wurden die Grenzen von BPI ersichtlich und es kristallisierten sich einige BPMN Elemente heraus, welche vom BPI nicht unterstützt werden. Mit dem Unterprozess und den angehefteten Ereignissen blieben zwei grundlegende BPMN Konstrukte im BPI vermisst. Sie beide bilden aber die Basis einer Vielzahl von Modellierungsmöglichkeiten. Die Umsetzung des Prototypen hat gezeigt, dass aus technischer Sicht die Entwicklung eines Migrationsassistenten mit reiner Java-Programmierung gut zu bewältigen ist. Als grösste Hürde galt es, die unterschiedlichen Abhängigkeiten innerhalb der Transformation aufzulösen. Eine Lösung hierzu wurde erfolgreich gefunden. Aus konzeptioneller Sicht wurde ersichtlich, dass ein fachlicher Prozess nicht vollständig automatisiert in einen technischen Prozess transformiert werden kann. Aufgrund der entstehenden Informationslücken sind manuelle Nacharbeiten unumgänglich. Um diese effizient erledigen zu können, nimmt die Benutzerschnittstelle, d.h. im Speziellen die Rückmeldung, eine wichtige Rolle ein. Es empfiehlt sich, die aus dem Migrationsvorgang entstehenden Informationen wie Hinweise, Warnungen oder manuelle Aufgaben direkt ins resultierende Prozessdiagramm zu integrieren. Hierzu sind jedoch Erweiterungen sowohl des BPI Prozessmodells als auch des Editors notwendig. Zu guter Letzt darf festgehalten werden, dass das Ziel dieser Master-Thesis erreicht werden konnte. Die Machbarkeit eines Migrationsassistenten zur Transformation von BPMN Prozessen nach BPI konnte aufgezeigt werden. Während einerseits die gängigsten BPMN Symbole unterstützt werden, ist andererseits ein professioneller und kommerzieller Einsatz eines Migrationsassistenten beim aktuellen Entwicklungsstand von BPI fraglich. Bei der Migration von Kundenprozessen bleibt die Wahrscheinlichkeit gross, auf nicht unterstützte BPMN Elemente zu stossen. Die Folge davon können Ratlosigkeit und Unzufriedenheit sein. Für eine erfolgreiche Unterstützung der BPMN ist daher für weitere Investitionen seitens BPI zu raten. 5.2 Ausblick Aus den Resultaten dieser Arbeit ergeben sich zwei mögliche Strategien für die Zukunft von BPI zur Unterstützung der BPMN. Einerseits kann der bestehende BPI erweitert und die fehlenden Funktionalitäten nach Bedarf umgesetzt werden. Insbesondere einfachere Elemente wie Ereignisse oder unterschiedliche Task- Typen lassen sich gut im aktuellen Kontext von BPI implementieren. Die Erweiterung betrifft mehrheitlich die Laufzeit und ist rein funktioneller Natur. Andere Elemente wie beispielsweise der Unterprozess führen zu tiefgründigen, konzeptionellen Fragestellungen und verlangen Erweiterungen sowohl im BPI Designer und dem Prozessmodell als auch zur Laufzeit. In Anbetracht der Tatsache, dass moderne Prozess-Engines diese Funktionen bereits anbieten, ist eine eigene Implementierung fragwürdig. Die zweite mögliche Strategie ergibt sich aus der logischen Konsequenz dieses Umstandes. 26

35 Schluss Seit der fünften Version von jbpm ist eine direkte Ausführung von BPMN Prozessen möglich. Zwar wird die Spezifikation noch nicht vollumfänglich unterstützt, die grundlegenden Konstrukte sind jedoch bereits implementiert (ein kurzer Überblick ist in der Dokumentation der Analyse 1 zu finden). Für eine zukunftsorientierte und nachhaltige Lösung wird geraten, ein Upgrade von jbpm zumindest in Betracht zu ziehen. Obwohl die hierzu notwendigen Aufwände nicht zu unterschätzen sind, können die Vorteile durchaus überwiegen. Nebst dem funktionalen Gewinn kann insbesondere technologisch aufgeholt und eine Alterung von BPI vermieden werden. In Anbetracht der geplanten Vernetzung mit der ERP-Lösung und der daraus entstehenden Bedeutung von BPI ist diese strategische Möglichkeit daher dringend abzuklären. 1 Migrationsassistent Analyse, Anhang B 27

36 Literatur- und Quellverzeichnis 6 Literatur- und Quellverzeichnis [1]. Allweyer, Thomas. BPMN Business Process Model and Notation. Norderstedt : Books on Demand, [2]. Object Management Group (OMG). Business Process Model and Notation (BPMN). 3. Januar [3]. Freund, Jakob, Rücker, Bernd und Henninger, Thomas. Praxishandbuch BPMN. München : Carl Hanser Verlag, [4]. Silver, Bruce. BPMS Watch. The DI Mess. [Online] 05. August [Zitat vom: 21. Januar 2013.] [5]. Wikipedia. Wikipedia. ATLAS Transformation Language. [Online] 19. März [Zitat vom: 9. November 2012.] [6]. Allweyer, Thomas. BPMN 2.0 Business Process Model and Notation - Das Buch zum Standard für die Geschäftsprozessmodellierung. BPMN 2.0-Begriffe auf Deutsch. [Online] 12. Februar [Zitat vom: 13. Januar 2013.] 28

37 Kurzlebenslauf des Verfassers 7 Kurzlebenslauf des Verfassers Name, Vorname von Däniken Simon Adresse Brünigstrasse 18 Wohnort 6005 Luzern Geb. Datum Telefon Zivilstand simon.vondaeniken@gmail.com ledig Ausbildung Primarschule in Hildisrieden Kantonsschule in Beromünster Fachhochschule Aargau, Studiengang Informatik mit Vertiefungsrichtung Enterprise Computing Master of Science in Engineering, Hochschule Luzern, Technik & Architektur Berufliche Tätigkeiten Bison Schweiz AG, Enterprise, 6210 Sursee Praktikum als Application Developer Bison Schweiz AG, Enterprise, 6210 Sursee Software Developer 29

38 Anhang Anhang A Begriffsübersetzung Die Begrifflichkeiten der englischsprachigen BPMN 2.0 Spezifikation wurden in dieser Arbeit gemäss der folgende Tabelle 1 in die deutsche Sprache übersetzt. Als Vorlage dienten Übersetzungstabellen aus bestehender Literatur (zweite und dritte Spalte). Englisch Deutsch BPMN 2.0 Spezifikation [2] BPMN Praxishandbuch [3 S. 261] BPMN Business Process Model and Notation [6] Migrationsassistent BPMN 2.0 nach BPI Abstract Process Abstrakter Prozess Abstrakter Prozess Abstract Task Unbestimmter Task Unbestimmter Task Activity Aktivität Aktivität Aktivität Ad hoc Subprocess Adhoc-Teilprozess Ad-hoc-Unterprozess Ad-hoc-Unterprozess Artifact Artefakt Artefakt Association (not directed / Assoziation (ungerichtet / Assoziation Assoziation directed / bidirectional) gerichtet / beidseitig gerichtet) Attached Event Angeheftetes Ereignis Angeheftetes Ereignis Angeheftetes Ereignis Business Rule Task Geschäftsregel-Task Geschäftsregel-Task Call Activity Aufrufaktivität Aufrufaktivität Cancel Event Abbruchsereignis Abbruchereignis Abbruchsereignis Catching Event Eingetretenes Ereignis Empfangendes Ereignis Eintretendes Ereignis Choreography Choreographie Choreographie Collapsed Sub-Process Zugeklappter Teilprozess Zugeklappter Unterprozess Zugeklappter Unterprozess Compensation Kompensation Kompensation Kompensation Compensation Activity Kompensationsaktivität Compensation Event Kompensationsereignis Kompensationsereignis Kompensationsereignis Compensation Event Sub- Process Kompensations-Ereignis- Unterprozess Compensation Handler Kompensations-Handler Complex Gateway Komplexes Gateway Komplexer Gateway Komplexer Gateway Conditional Event Bedingungsereignis Bedingungsereignis Bedingungsereignis Conditional Sequence Flow Bedingter Sequenzfluss Bedingter Sequenzfluss Data Input Dateninput Dateninput Data Object Datenobjekt Datenobjekt Datenobjekt Data Output Datenoutput Datenoutput Data Store Datenspeicher Datenspeicher Data-Based Exclusive Gateway Datenbasiertes exklusives Gateway (XOR) Datenbasierter exklusiver Gateway Datenbasierter exklusiver Gateway Default Sequence Flow Standard-Sequenzfluss Embedded Sub-Process Eingebetteter Unterprozess End Event Endereignis Endereignis Endereignis Error Event Fehlerereignis Fehlerereignis Fehlerereignis Escalation Event Eskalationsereignis Event Ereignis Ereignis Ereignis Event Sub-Process Ereignis-Unterprozess Ereignis-Unterprozess Event-Based Exclusive Gateway Ereignisbasiertes exklusives Gateway Ereignisbasierter exklusiver Gateway Ereignisbasierter exklusiver Gateway Event-Based Parallel Gateway Ereignisbasierter paralleler Gateway Ereignisbasierter paralleler Gateway Exclusive Gateway Exklusiver Gateway Exklusiver Gateway Expanded Sub-Process Aufgeklappter Teilprozess Expandierter Unterprozess, Aufgeklappter Unterprozess aufgeklappter Unterprozess Gateway Gateway Gateway Gateway Global Task Globaler Task Globaler Task Group Gruppierung Gruppierung Gruppierung Inclusive Gateway Inklusives Gateway (OR) Inklusiver Gateway Inklusiver Gateway Intermediate Event Zwischenereignis Zwischenereignis Zwischenereignis Join Zusammenführung (paralleler Zusammenführung, Join Pfade) Lane Lane Bahn, Lane Lane Link Event Link-Ereignis Link-Ereignis Loop Schleife Schleife Schleife Loop Activity Schleifenaktivität Schleifenaktivität Schleifenaktivität Manuel Task Manueller Task 30

39 Anhang Marker Merge Markierung Zusammenführung Zusammenführung (exklusiver Pfade) Message Nachricht Nachricht Nachricht Message Event Nachrichtenereignis Nachrichtenereignis Nachrichtenereignis Message Flow Nachrichtenfluss Nachrichtenfluss Nachrichtenfluss Multiple Event Mehrfachereignis Mehrfachereignis Mehrfachereignis Multiple Instance, Multi- Mehrfache Instanz Mehrfachinstanz Mehrfachinstanz Instance Multiple Participant Mehrfachteilnehmer Nested Lanes Verschachtelte Bahnen Verschachtelte Lanes None Event Unbestimmtes Ereignis Parallel Gateway Paralleles Gateway (AND) Paralleler Gateway Paralleler Gateway Parallel Multiple Event Paralleles Mehrfachereignis Participant Teilnehmer Teilnehmer Teilnehmer Pool Pool Pool Pool Process Prozess Prozess Prozess Receive Task Empfangs-Task Empfangs-Task Script Task Skript-Task Skript-Task Send Task Sende-Task Sende-Task Sequence Flow Sequenzfluss Sequenzfluss Sequenzfluss Service Task Service-Task Service-Task Signal Event Signalereignis Signalereignis Signalereignis Split Verzweigung Verzweigung Start Event Startereignis Startereignis Startereignis Sub-Process Teilprozess Unterprozess Unterprozess Swimlane Swimlane Swimlane Task Aufgabe Task Task Terminate Event Terminierungsereignis Terminierungsereignis Terminierungsereignis Text Annotation Text-Anmerkung Textanmerkung Throwing Event Ausgelöstes Ereignis Sendendes Ereignis Ausgelöstes Ereignis Timer Event Timer-Ereignis, Zeitereignis Zeitereignis, zeitliches Ereignis Zeitereignis Token Marke Token Transaction Transaktion Transaktion Transaktion User Task Benutzer-Task Benutzeraufgabe Tabelle 1: Deutsche Übersetzung der Begrifflichkeiten aus der BPMN 31

40 Anhang B Transformationsbeispiele Die folgenden Transformationsbeispiele wurden im Rahmen von Review-Meetings zu Demonstrationszwecken genutzt. B.1 Beispiel 1 Abbildung 16: BPMN Demo-Prozess 1 32

41 Anhang Abbildung 17: Migrierter BPI Demo-Prozess 1 33

42 Anhang B.2 Beispiel 2 Abbildung 18: BPMN Demo-Prozess 2 34

43 Anhang Abbildung 19: Migrierter BPI Demo-Prozess 2 35

44 Anhang B.3 Beispiel 3 Abbildung 20: BPMN Demo-Prozess 3 36