DANKSAGUNG

Ich möchte mich bei meiner Betreuerin DI (FH) Birgit Kammerhofer dafür bedanken, dass sie mir, wann immer es notwendig war, mit Rat und Tat zur Seite stand.

II

KURZFASSUNG

Viele Unternehmen befassen sich heute mit der Dokumentation ihrer Geschäftsprozesse. Die Gründe dafür sind vielfältig. Der Anlass kann zum Beispiel die Erhaltung des immateriellen Wissens in Form von Geschäftsprozessdokumentationen oder die Optimierung der Ressourcenverwendung sein. In der IT werden Workflows verwendet, welche eine große Ähnlichkeit zu Geschäftsprozessen haben. Diese Arbeit bewertet unterschiedliche Wege wie ein Unternehmen die Lücke zwischen Geschäftsprozessen und Workflows schließen kann. Es wird gezeigt, dass es in der Theorie drei verschiedene Wege zur Lösung des Problems gibt: Manuelle Transformation, halbautomatische Transformation und automatische Transformation. Diese drei Wege werden durch jeweils ein Beispiel demonstriert. Durch diese Beispiele wird gezeigt, dass automatische Transformation und halbautomatische Transformation fließend ineinander übergehen.

Die unterschiedlichen Ableitungsvarianten werden ebenfalls nach ihrer Praxistauglichkeit bewertet. Die Bewertung zeigt, dass der beste Weg um diese Lücke zu schließen eine Kombination der halbautomatischen und der automatischen Variante ist, auch wenn es nicht immer möglich ist einen manuellen Ansatz zu vermeiden.

ABSTRACT

Nowadays many companies document their business processes. Information technology uses workflows, which are similar to business processes. The purpose of this paper was to evaluate different ways of how a company can derive workflows from business processes. The theoretical part describes business processes and workflows, and shows three theoretical ways of how the transformation can be carried out, namely manual transformation, half-automatic transformation and automatic transformation. This is followed by a demonstration of the three ways by means of examples in the practical part. The Examples also show that the half-automatic approach and the automatic approach practically merge. Finally the possibilities are evaluated according to their practicability. The result of this evaluation shows that the best way to close the gap between business processes and workflows is a combination of the halfautomatic and the automatic approach, however, it also not always possible to avoid a manual approach.

III

GLEICHHEITSGRUNDSATZ

Aus Gründen der Lesbarkeit wurde in dieser Arbeit darauf verzichtet, geschlechtsspezifische Formulierungen zu verwenden. Jedoch mochte ich ausdrücklich festhalten, dass die bei Personen verwendeten maskulinen Formen für beide Geschlechter zu verstehen sind.

IV

INHALTSVERZEICHNIS

1  EINLEITUNG  1

1.1  Ausgangssituation  1

1.2  Aufgabenstellung und Zielsetzung  2

1.3  Vorgehensweise  2

1.4  Aufbau der Arbeit  2

1.5  Verwandte Arbeiten  3

2  GESCHÄFTSPROZESSE UND GESCHÄFTSPROZESSMANAGEMENT  4

2.1  Einordnung in Unternehmen  4

2.2  Begriffsdefinition für Geschäftsprozess  4

2.3  Geschäftsprozessmanagement  5

2.4  Prozessoptimierung  5

3  WORKFLOWS  6

3.1  Begriffsdefinition  6

3.2  Workflowmanagement  7

3.3  Workflowmanagementsysteme.  8

3.4  Service Orientierte Architekturen  8

3.4.1  Services  9

3.4.2  Architekturprinzip SOA  9

3.4.3  Zukunft von SOA  9

4  PROZESSMODELLIERUNG  10

4.1  Aufbau von Geschäftsprozessmodellen  10

4.2  Zweck fachlicher Prozessmodelle  11

4.3  Workflowmodellierung  13

4.4  Notationen.  13

5  ABLEITUNG VON TECHNISCHEN PROZESSMODELLEN  15

5.1  Ziele  15

5.2  Herausforderungen  15

5.3  Unterscheidungsmerkmale für Ableitungsmethoden  16

5.4  Lösungsansätze  17

5.4.1  Keine Ableitung  17

5.4.2  Manuelle Transformation  17

5.4.3  Halbautomatische Transformation  17

5.4.4  Automatische Transformation  17

6  BEWERTUNGSKRITERIEN  19

7  IMPLEMENTIERUNG DER LÖSUNGSANSÄTZE  21

V

7.1  Manuelle Transformation  21

7.1.1  Verwendete Tools  21

7.1.2  Verwendetes Beispiel  22

7.1.3  Beschreibung  22

7.2  Halbautomatische und Automatische Transformation  22

7.2.1  Verwendete Tools  22

7.2.2  Verwendetes Beispiel  23

7.2.3  Beschreibung der Erstellung des fachlichen Modells  23

7.2.4  Ablauf bei der Generierung des technischen Modells  23

7.2.5  Überprüfung und Nachbearbeitung des technischen Modells  24

7.2.6  Vorgehen bei Änderungen  24

7.3  Weitere Transformationstools  24

8  BEWERTUNGSMATRIX  26

9  FAZIT DER BEWERTUNG  27

10  ZUSAMMENFASSUNG UND AUSBLICK  29

ANHANG A:  BEISPIEL ZUR MANUELLEN TRANSFORMATION  30

  (A) MODELLIERUNG DES EPK-MODELLS  30

  (B) ERSTELLUNG DES WORKFLOWS  32

ANHANG B:  BEISPIEL ZUR AUTOMATIONSUNTERSTÜTZTEN TRANSFORMATION  37

  (A) MODELLIERUNG DES BPMN-MODELLS  37

  (B) ABLEITUNG DES WORKFLOWS  41

  ()C ÜBERPRÜFUNG UND NACHBEARBEITUNG DES TECHNISCHEN MODELLS  44

  (D) VORGEHEN BEI ÄNDERUNGEN  47

ABK  ÜRZUNGSVERZEICHNIS  50

ABBILDUNGSVERZEICHNIS   51

TABELLENVERZEICHNIS   52

LITERATURVERZEICHNIS   53

VI

Einleitung

1 EINLEITUNG

Die Unterschiede zwischen Fachbereichen und IT eines Unternehmens werden von vielen wie jene zwischen zwei absolut konträren Welten empfunden. Dies liegt vor allem an unterschiedlichen Begriffen und Ausdrucksweisen der jeweiligen Vertreter. Der Techniker sieht seine Implementierung und all die Herausforderungen die damit verbunden sind, während der Mitarbeiter in der Fachabteilung rein den Beitrag der IT zu seiner Tätigkeit sieht.

Im folgenden Kapitel wird erläutert wo die Unterschiede zwischen Fachabteilungen und der IT bei der Darstellung von Geschäftsprozessen zu tragen kommen. Aus dieser Ausgangssituation stellt sich die Aufgabe diese Unterschiede zu überbrücken. Die in diesem Kapitel beschriebene Vorgehensweise zur Erreichung der Zielsetzung und der grobe Aufbau der Arbeit dienen dazu einen Überblick über die Arbeit zu geben. Ein kurzer Überblick über verwandte Arbeiten zeigt, wo die Arbeit in ihrem Umfeld eingebettet ist.

1.1 Ausgangssituation

Moderne Unternehmen begnügen sich nicht mehr mit einer Aufbauorganisation, sondern legen zunehmend Wert auf eine gut durchdachte Ablauforganisation und im Besonderen auf optimierte Geschäftsprozesse. Die daraus resultierende neue Sichtweise auf das Unternehmen wirkt sich auch auf die IT aus. Mit dem Aufkommen der Geschäftsprozessmodellierung wurden Workflow-Management Systeme eingeführt und in letzter Zeit entwickelt sich zunehmend ein Trend zu Service Orientierten Architekturen (SOA), welche ebenfalls Workflows verwenden.

Workflows basieren teilweise auf Geschäftsprozessen. Die IT benötigt Prozessmodelle jedoch in einer anderen Form als diese vom Management erstellt werden. Aus diesem Grund müssen die Geschäftsprozesse der Fachbereiche für die IT aufbereitet werden. Zwar existieren bereits verschiedene Ansätze zur Lösung des Problems, allerdings gestaltet sich die Überleitung der fachlichen Modelle in technische Prozesse in der Praxis auch heute noch schwierig.

1

Einleitung

1.2 Aufgabenstellung und Zielsetzung

In dieser Arbeit werden aktuelle Ansätze zur Ableitung technischer Prozessmodelle (Workflows) aus fachlichen Geschäftsprozessmodellen verglichen. Einzelne Ableitungsmethoden werden durch Referenz-Werkzeuge bewertet um die Vor- und Nachteile der Methoden aufzuzeigen und herauszufinden welche derzeit die zweckmäßigste Lösung für die Praxis darstellt. Die Beschreibung der Vor- und Nachteile einzelner Werkzeuge ist allerdings nicht Teil dieser Arbeit. In diesem Zusammenhang sollen folgende Fragen beantwortet werden:

Welche Möglichkeiten zur Ableitung eines IT-Prozessmodells aus Geschäftsprozessen gibt es? Welche ist die für die Praxis Geeignetste?

Müssen Prozessverantwortliche die Bedürfnisse der IT kennen oder kann sich die IT anpassen?

Die Beschreibung Service Orientierter Architekturen dient der Erläuterung des Praxisbezuges der Arbeit und der Anforderungen an die Modelle. Die Arbeit befasst sich jedoch nicht mit der Darstellung des Gesamtkonzeptes der Service Orientierten Architekturen.

1.3 Vorgehensweise

Die Arbeit basiert auf der deduktiven Methode. Auf Basis der allgemeinen Beschreibungen des Geschäftsprozessmanagements und der Workflow-Management-Systeme werden detaillierte Informationen über die Modellierung von Geschäftsprozessen auf unterschiedlichen Ebenen gesammelt. Es wird beschrieben warum formale Modelle aus Geschäftsprozessmodellen erstellt werden und welche Probleme hierbei auftreten.

Basierend auf diesen Grundlagen werden Kriterien zur Bewertung der einzelnen Ableitungsmöglichkeiten ermittelt. Im nächsten Schritt werden Beispiele für verschiedene Ansätze erstellt, um die Abläufe vergleichen zu können. Im Anschluss wird aus diesen Beispielen eine Vergleichsmatrix erstellt, in der die einzelnen Methoden miteinander verglichen und bewertet werden.

1.4 Aufbau der Arbeit

Die ersten beiden Kapitel beschreiben Geschäftsprozesse, Workflows und damit verbundene Tätigkeiten in einem Unternehmen. Im dritten Kapitel wird darauf eingegangen wie Workflows und Geschäftsprozesse festgehalten werden, und zwar in Form von Modellen. Weiters wird der Zweck solcher Modelle näher erklärt. Durch diese drei Kapitel soll ein Verständnis für die Thematik geschaffen werden.

Das vierte Kapitel beinhaltet die theoretischen Grundlagen für die Ableitung von Workflowmodellen. In diesem Kapitel ist beschrieben warum Workflowmodelle abgeleitet werden sollten, was die Probleme dabei sind und wie es grundsätzlich bewerkstelligt werden kann. Im Kapitel „Bewertungskriterien“ wird definiert, woran man die Praxistauglichkeit einer Ableitungsmethode messen kann. Diese

2

Einleitung

Bewertungskriterien werden auf die im Kapitel sieben gezeigten Implementierungen angewandt und das Ergebnis wird im Kapitel acht in Form einer Bewertungsmatrix dargestellt.

Im letzten Kapitel wird aus der Bewertungsmatrix ein Fazit gezogen und es gibt einen Ausblick was auf diesem Gebiet noch getan werden muss.

1.5 Verwandte Arbeiten

Es existieren zahlreiche Arbeiten zu diesem Thema, die eine Transformation von Geschäftsprozessmodellen zu Workflows behandeln, wobei jedoch alle hier aufgeführten Arbeiten jeweils einen Ansatz vorstellen.

(Stein, et al., 2007) beschreibt in seiner Arbeit einen Ansatz wie ereignisgesteuere Prozessketten (EPKs) zu Business Process Execution Language (BPEL)-Workflows transformiert werden können. Hierbei wird das Geschäftsprozessmodell vor der Transformation daraufhin geprüft, ob es transformiert werden kann. Ebenfalls eine Transformation von EPKs zu Workflow-Modellen wird in (Kopp, 2005) und (Beer, et al., 2007) beschrieben, wobei hier jeweils ein eigenes Werkzeug beschrieben wird. In (Kurbel, et al., 1997) wird eine Ableitung eines Workflows aus einem Geschäftsprozessmodell erläutert. Die Ableitung erfolgt hier manuell, das Workflow-Modell wird also neu modelliert. Eine Variante bei der ein EPK-Modell zuerst manuell in ein eher technisches BPMN-Modell überführt wird, aus dem halbautomatisch ein BPEL-Modell generiert wird, wird in (Thomas, et al., 2007) beschrieben. (Nissen, et al., 2007) beschreibt einen Ansatz in dem UML-Diagramme solange verfeinert werden bis sie zu einem BPEL-Workflow transformiert und im Anschluss daran nachbearbeitet werden können.

3

Geschäftsprozesse und Geschäftsprozessmanagement

2 GESCHÄFTSPROZESSE UND

GESCHÄFTSPROZESSMANAGEMENT

Geschäftsprozessmanagement ist ein aktuelles Thema in vielen Unternehmen die versuchen, aus unterschiedlichsten Gründen, wie zum Beispiel der zunehmenden Globalisierung und den dadurch gestiegen Druck zur Kostenreduktion, ihre Abläufe zu optimieren. In diesem Kapitel wird darauf eingegangen wo Geschäftsprozessmanagement im Unternehmen einzuordnen ist. Weiters wird definiert was in dieser Arbeit unter einem Geschäftsprozess verstanden wird. Im letzten Teil wird beschrieben aus welchen Aktivitäten in einer Organisation sich das Geschäftsprozessmanagement zusammensetzt.

2.1 Einordnung in Unternehmen

Geschäftsprozesse und Geschäftsprozessmanagement sind Teil der Ablauforganisation eines Unternehmens, welche die Tätigkeiten in einem Unternehmen und deren zeitliche und logische Abfolge behandelt. Im Gegensatz dazu befasst sich die Aufbauorganisation mit der Struktur in einem Unternehmen und definiert über diese Struktur Zuständigkeiten und Weisungsbefugnisse. 1

2.2 Begriffsdefinition für Geschäftsprozess

Im Geschäftsprozessmanagement unterscheidet man zwischen den Begriffen „Prozess“ und „Geschäftsprozess“. Ein Prozess ist eine Abfolge von einzelnen Aktivitäten in einer zeitlichen und logischen Abarbeitungsreihenfolge mit einem bestimmten Zweck, beispielsweise der Durchführung einer Rechnungsprüfung. 2

Geschäftsprozesse stellen eine spezielle Form von Prozessen dar. Die Abgrenzung eines Geschäftsprozesses ist nicht eindeutig definiert. Als die drei wichtigsten Eigenschaften gelten jedoch: Ein Geschäftsprozess ist ein wertschöpfender Prozess. Dieser erzeugt beim Kunden einen Nutzen, welcher der Kernaktivität des jeweiligen Unternehmens entspricht. Ein Geschäftsprozess ist funktionsübergreifend, d.h. er wird von mehreren Einheiten - im Sinne der Aufbauorganisation - eines Unternehmens behandelt.

¹ Vgl. (Becker, et al., 2006) S. 6f

² Vgl. (Becker, et al., 2006) S. 6f

4

Geschäftsprozesse und Geschäftsprozessmanagement

Ein Geschäftsprozess ist ebenso kundenorientiert, er nimmt seinen Ausgang beim Kunden (Bsp.: Bestellung) und endet auch beim Kunden (Bsp.: Lieferung, Zahlungsbestätigung). 3

2.3 Geschäftsprozessmanagement

Geschäftsprozessmanagement beinhaltet folgende drei Aspekte: 4

Prozessabgrenzung Prozessmodellierung Prozessführung

Die Prozessabgrenzung umfasst die Ableitung und Erstellung neuer Geschäftsprozesse aus der Unternehmensstrategie und dem Produktsortiment. Für eine zu lösende Aufgabe werden hierbei mehrere Prozessvarianten verglichen und modelliert, worauf eine Prozessvariante zur Implementierung ausgewählt wird. Die Geschäftsprozessmodellierung beschäftigt sich mit der Abbildung bestehender Prozesse eines Unternehmens aus fachlicher Sicht. Die Aufgabe der Prozessführung ist festzustellen, ob die Geschäftsprozesse den strategischen Zielen eines Unternehmens genügen. Hierzu müssen aus den strategischen Zielen Kennzahlen abgeleitet werden, anhand welcher die Prozesse kontrolliert werden können. Gegebenenfalls müssen Prozesse nachmodelliert oder verändert werden. 5

2.4 Prozessoptimierung

Geschäftsprozesse sind nichts Statisches. Zum einen sind Prozesse nicht zwangsläufig von Anfang an tatsächlich ausgereift, zum anderen ergeben sich durch geänderte Rahmenbedingungen auch neue Möglichkeiten der Prozessdefinition. Es gibt zwei Möglichkeiten Prozesse eines bestehenden Unternehmens zu verbessern: Business Process Reengineering ist ein radikaler Ansatz, bei dem die Geschäftsprozesse völlig neu erdacht werden. Dadurch entsteht ein hoher Aufwand zur Umstellung auf die neuen Prozesse und ein entsprechend hohes Risiko, jedoch ist das Potential höher. Ein weniger radikaler Ansatz ist das kontinuierliche Prozessmanagement. Hierbei werden bereits bestehende Prozesse auf Verbesserungsmöglichkeiten geprüft und schrittweise angepasst. 6

³ Vgl. (Gadatsch, 2008) S. 45ff

⁴ Vgl. (Langner, 2007) S. 23f

⁵ Vgl. (Gadatsch, 2008) S. 2f

⁶ Vgl. (Becker, et al., 2006) S. 299f

5

Workflows

3 WORKFLOWS

„Im Zeitalter des Computers haben wir es mit der Überwindung geistiger Entfernungen mittels der

Das vorherige Kapitel beschrieb was unter Geschäftsprozessen aus der Sicht des Managements und der Fachbereiche zu verstehen ist. Dieses Kapitel erläutert den technischen Blickwinkel. Schon aus der Definition des Begriffs „Workflow“ am Anfang dieses Kapitels ist ersichtlich, dass dieser zwar direkt mit dem Begriff Geschäftsprozess zusammen hängt, aber diesen noch um Aspekte der IT erweitert. Anschließend an die Definition des Begriffes wird gezeigt, wo Workflows in der IT zum Einsatz kommen. Mit der Beschreibung von serviceorientierten Architekturen wird ein Einsatzgebiet für Workflows näher erläutert.

3.1 Begriffsdefinition

Es existiert keine allgemein gültige einheitliche Definition für den Begriff „Workflow“. Tabelle 3-1gibt einen kurzen Überblick über verschiedene Definitionen:

⁷ (Gadatsch, 2008) S. 53

6

Workflows

Tabelle 3-1: Definitionen für Workflow

Für diese Arbeit gilt folgende Definition in Anlehnung an (Gadatsch, 2008) und (Fischer, et al., 2006):

Ein Workflow ist ein formal beschriebener, ganz oder teilweise durch ein IT-System automatisierter Geschäftsprozess. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatische Steuerung des Arbeitsablaufes durch ein Workflowmanagementsystem erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte sind zur Ausführung durch Mitarbeiter oder durch Anwendungsprogramme vorgesehen.

3.2 Workflowmanagement

Für Geschäftsprozesse gibt es das Geschäftsprozessmanagement, welches sich mit allen Tätigkeiten rund um Geschäftsprozesse befasst.

Analog dazu gibt es bei Workflows das Workflow-Management, das alle Tätigkeiten und Methoden zur Analyse, Planung, Simulation, Steuerung und Überwachung von Arbeitsabläufen beinhaltet. ¹¹ Da die Vorgänge des Workflowmanagement im Detail diese Arbeit nicht beeinflussen, werden sie hier nicht näher behandelt. Über die Ziele des Workflowmanagements kann mehr in (Gadatsch, 2008) in Erfahrung gebracht werden.

⁸ (Becker, et al., 2006) S. 56

⁹ (Fischer, et al., 2006) S. 104

¹⁰ (Gadatsch, 2008) S. 52

¹¹ Vgl. (Becker, et al., 2006) S. 377f

7

Workflows

3.3 Workflowmanagementsysteme

Workflowmanagementsysteme sind Software-Systeme zur Ausführung und Überwachung von Workflows. Sie können auch als Business Process Management Systeme bezeichnet werden. ¹² Der genaue Funktionsumfang eines Workflowmanagementsystems ist nicht genau definiert, ferner hat sich das Verständnis darüber im Lauf der Zeit verändert. Häufig wird ein Workflowmanagement mit einem Dokumentenmanagementsystem in Zusammenhang gebracht, oder es wird als Groupware-System verstanden, das Aktivitäten einzelner Mitarbeiter anhand eines Ablaufschemas steuert. ¹³ Diese Auffassungen beschreiben einzelne Einsatzmöglichkeiten für Workflowmanagementsysteme, es existieren jedoch noch weitere.

Gadatsch unterscheidet zwischen fünf Stufen von Workflowmanagementsystemen. In der ersten Stufe sind es einfach Applikationen, die Prozesse abwickeln und welche direkt in den Code der Applikation geschrieben sind. Diese Systeme wurden zum Beispiel in Versicherungen eingesetzt. Sie wurden zwar noch nicht als Workflowmanagementsysteme bezeichnet, stellen aber eine Vorstufe dar. Die zweite Stufe besteht darin die Prozesse von der Applikation zu trennen. In der dritten Stufe werden die Prozesse in eigenen Datenbanken gespeichert. Die vierte Stufe ermöglicht den Austausch von Prozessausführungsdaten zwischen verschiedenen Anwendungen verschiedener Hersteller. Möglich wird dies durch den Einsatz von Client-Server-Architekturen. Als fünfte Stufe nennt Gadatsch den Wechsel von Client-Server-Architekturen hin zu serviceorientierten Architekturen. ¹⁴ Ein Workflowmanagementsystem ist also eine Middleware, welche die Ausführung und das Überwachen von Prozessen in einer Anwendung bzw. Workflows unterstützt.

Weitere Funktionalitäten des Systems können Beispielsweise die Modellierung, die Simulation oder die Analyse von Workflows sein ¹⁵ . Workflowmanagementsysteme interpretieren Workflow-Beschreibungen und führen die einzelnen Aktivitäten aus indem sie die Tätigkeiten an Mitarbeiter oder andere Anwendungen weiterleiteten und hierbei gegebenenfalls vorhandene Informationen bereitstellen ¹⁶ .

3.4 Service Orientierte Architekturen

Serviceorientierte Architekturen (SOA) sind ein Paradigma, das nicht auf die IT abgrenzbar ist. ¹⁷ In dieser Arbeit wird SOA aus einer technischen Sicht beschrieben. Wie bereits unter Abschnitt 3.3 erwähnt sind serviceorientierte Architekturen ein mögliches Einsatzgebiet für Workflowmanagementsysteme.

¹² Vgl. (Strohmeier, 2008) S. 305

¹³ Vgl. (Gadatsch, 2008) S. 265f

¹⁴ Vgl. (Gadatsch, 2008) S. 268f

¹⁵ Vgl. (Strohmeier, 2008) S. 305 ff

¹⁶ Vgl. (Becker, et al., 2006) S. 191

¹⁷ Vgl. (Masak, 2007) S. 4

8

Workflows

Dieses Kapitel beschreibt welche Rolle Workflows bei SOA spielen. Dazu werden zunächst die Grundelemente einer SOA, die so genannten „Services“ kurz beschrieben, welche im Architekturprinzip Verwendung finden. Am Ende findet sich noch ein Ausblick über die Zukunft von SOA, der die Aktualität des Themas zum Inhalt hat.

3.4.1 Services

Services sind aus technischer Sicht fachlich orientierte Softwarekomponenten, von denen derjenige der Sie verwendet in der Regel nicht mehr als eine Beschreibung des Inhalts und der Schnittstelle hat. Informationen über die Implementierung und über die Plattform werden abstrahiert. Web-Services sind eine gängige Implementierung für Services in der IT, sie sind jedoch keine Voraussetzung für eine SOA. 18

3.4.2 Architekturprinzip SOA

SOA bezeichnet nun eine Architektur die vollständig aus Services aufgebaut ist. Die Kommunikation und der Aufruf der Services werden an einer zentralen Stelle koordiniert. 19

Die Services werden in der sogenannten Komposition zu Geschäftsprozessen zusammengefügt. ²⁰ Hierzu können Workflowmanagementsysteme eingesetzt werden. Diese koordinieren die Ausführung der einzelnen Services. Für serviceorientierte Architekturen werden bei Workflow-Engines Sprachen eingesetzt, die speziell für die Komposition von Services entwickelt wurden, zum Beispiel BPEL. 21

3.4.3 Zukunft von SOA

Auch wenn der Hype um serviceorientierte Architekturen bereits abgeklungen ist, wird SOA laut Ansicht von Beratungsunternehmen wie Gartner und IT-Verantwortlicher großer Unternehmen auch in Zukunft nicht verschwinden. Gerade wegen ihrer Prozessorientierung dürften serviceorientierte Strukturen in Zukunft weiter ausgebaut werden. 22

¹⁸ Vgl. (Nissen, et al., 2007) S. 77 f

¹⁹ Vgl. (Masak, 2007) S. 92

²⁰ Vgl. (Masak, 2007) S. 104

²¹ Vgl. (Masak, 2007) S. 212

²² Vgl. (Herrmann, 2008) S. 3

9

Prozessmodellierung

4 PROZESSMODELLIERUNG

Geschäftsprozesse können zwar verbal beschrieben werden, wesentlich häufiger ist jedoch eine grafische Darstellung. Das folgende Kapitel erläutert, wie Prozessmodelle grundsätzlich aufgebaut und gegliedert sind. Es beschreibt welche Eigenschaften und welchen Verwendungszweck fachliche Prozessmodelle im Unternehmen haben können.

In Folge werden Workflow-Modelle anhand ihrer Unterschiede zu Geschäftsprozessmodellen erklärt. Weiters wird darauf eingegangen, wo sich die beiden Modellarten schneiden und wo grundsätzliche Unterschiede bestehen.

Im letzten Teil des Kapitels werden kurz einige häufig verwendete Notationen genannt und nach ihrer Verwendung eingeteilt.

4.1 Aufbau von Geschäftsprozessmodellen

Zur Erfassung von Geschäftsprozessen haben sich graphische Darstellungsformen bewehrt. Diese Modelle bestehen aus einzelnen Elementen, deren Bedeutung durch eine Semantik definiert ist. Die Elemente sind mit so genannten Kanten verbunden, welche entweder einen Fluss, eine Reihenfolge oder eine Zugehörigkeit darstellen. 23

Abbildung 4-1 zeigt ein EPK-Modell. Die Elemente in dieser Abbildung sind so genannte Ereignisse - in Rot dargestellt - und Funktionen - hier in Grün -, welche durch Kanten, die den Kontrollfluss darstellen, verbunden sind.

²³ Vgl. (Rosenkranz, 2006) S. 1f

²⁴ Quelle; in Anlehnung an (Staud, 2006) S. 70

10

Prozessmodellierung

Geschäftsprozessmodelle im Unternehmen lassen sich nach Detaillierungs-Grad unterscheiden in strategische und fachliche Geschäftsprozessmodelle. Während strategische Geschäftsprozessmodelle abstrakt beschreiben wie das Unternehmen grundsätzlich einen Mehrwert erzeugt, beschreiben fachliche Prozessmodelle jeden einzelnen Arbeitsschritt, der benötigt wird um das Ergebnis zu erreichen. ²⁵ Prozessmodelle können jedoch noch weiter abgestuft werden. Eine Sub-Ebene entspricht dabei einer genaueren Beschreibung eines Elements der übergeordneten Ebene.

26 Abbildung 4-2: Prozessdetailierung

Abbildung 4-2 zeigt ein typisches Beispiel für eine solche Verfeinerung. Bei den Prozessen Einkauf, Wareneingang, Lagerhaltung, Auftragsbearbeitung und Versand handelt es sich um übergeordnete Prozesse, welche jedoch in einem weiteren Diagramm noch genauer detailliert sind. Dies bietet den Vorteil, dass das Management einerseits den Überblick behält, aber andererseits dennoch weiß wo im Unternehmen ein Prozess einzuordnen ist. Für das Management ist es nicht von Bedeutung wie ein Prozess operativ ausgeführt wird. Es reicht wenn der grundlegende Weg der Wertschöpfung im Unternehmen insgesamt erkennbar ist. Besonders wichtig wird die Detaillierung wenn Prozesse unternehmensübergreifend modelliert werden, um auch Lieferanten, Outsourcing-Unternehmen, Kooperationspartner oder andere Akteure in das Modell einzubeziehen. 27

4.2 Zweck fachlicher Prozessmodelle

Prozessmodelle können aus unterschiedlichen Gründen modelliert werden. Die folgende Tabelle gibt einen Einblick in die vielfältigen Gründe für die Modellierung von Prozessen.

²⁵ Vgl. (Rosenkranz, 2006) S. 15f

²⁶ Quell: in Anlehnung an (Fischer, et al., 2006) S 9

²⁷ Vgl. (Fischer, et al., 2006) S. 10f

11

Prozessmodellierung

²⁸ Vgl. (Becker, et al., 2006) S. 51-56, S. 190-193

²⁹ Vgl. (Andres, 2006) S. 233

12

Prozessmodellierung

4.3 Workflowmodellierung

Ein Modell ist eine Abstraktion eines komplexen Gegenstands. Doch während das fachliche Prozessmodell viele Details der Ausführung abstrahiert, enthält das Workflowmodell Spezifikationen, die für die Ausführung auf einem Workflow-Management-System erforderlich sind ³⁰ . Jedoch kann das Geschäftsprozessmodell auch Daten enthalten, die nicht für ein Workflowmodell interessant sind. Aus Tabelle 4-1 ist ersichtlich, dass der Einsatzbereich von Geschäftsprozessmodellen umfangreicher ist als jener von technischen Prozessmodellen. Dies führt dazu, dass nicht immer alle Teile eines fachlichen Prozessmodells in ein technisches Prozessmodell überführt werden, da das fachliche Modell auch Vorgänge außerhalb des Einflussbereichs der IT beschreiben kann. Darüber hinaus wird nicht immer ein gesamter Geschäftsprozess in einem Workflow abgebildet, sondern lediglich der Teil der IT-unterstützt ablaufen soll. ³¹ Ein Workflow kann also als ein Ausschnitt aus einem Geschäftsprozessmodell gesehen werden, der um Details erweitert wurde, womit er einer Sub-Ebene des Geschäftsprozessmodells entspricht.

Für Workflow-Modelle gibt es jedoch eine wichtige Einschränkung, die Geschäftsprozessmodelle so nicht kennen: Es gibt grafische und textuelle Beschreibungen für Workflows, wirklich ausgeführt werden können auf Workflow-Engines jedoch ausschließlich textuelle Beschreibungen. Grafische Modelle müssen also in eine textuelle Beschreibung umgewandelt werden können. 32

4.4 Notationen

Es existieren viele unterschiedliche Notationen für Geschäftsprozesse und Workflows. Teilweise haben Hersteller für Workflow-Management-System sogar eigene Modellierungs-Sprachen entwickelt. Die aktuell wichtigsten seien hier kurz beschrieben, wobei diese Liste keinesfalls Anspruch auf Vollständigkeit erhebt.

Zur Beschreibung von Geschäftsprozessen haben sich Ereignisgesteuere Prozessketten (EPK) durchgesetzt. ³³ Die Unified Modelling Languague (UML) wurde zur Beschreibung von Geschäftsprozessen um das Aktivitätsdiagramm erweitert und kann somit ebenfalls zur Geschäftsprozessmodellierung verwendet werden. 34

Die Business Process Modelling Notation (BPMN) ist ein Zwischenschritt zwischen Geschäftsprozessen und Workflows. Mit ihr können abstrakte als auch formale Prozesse beschrieben werden ³⁵ . Es gibt

³⁰ Vgl. (Nissen, et al., 2007) S. 86

³¹ Vgl. (Fischer, et al., 2006) S. 140 f

³² Vgl. (Nissen, et al., 2007) S. 62

³³ Vgl. (Staud, 2006) S. 59

³⁴ Vgl. (Seemann, et al., 2006) S. 27

³⁵ Vgl. (Masak, 2007) S. 256 f

13

Prozessmodellierung

Transformationsregeln um aus BPMN-Diagrammen formale Workflowbeschreibungen zu erzeugen. Das Mapping von BPMN auf BPEL ist im Standard zur BPMN (Object Management Group, 2008) direkt enthalten.

Die folgenden drei Sprachen sind formale, textuelle Sprachen und werden zur Ausführung von Workflows in Workflow-Engines verwendet:

Business Process Execution Languague (BPEL) ³⁶ Business Process Modelling Languague (BPML) XML Process Definition Language (XPDL)

³⁶ Spezifikation siehe (OASIS, 2007)

14

Ableitung von technischen Prozessmodellen

5 ABLEITUNG VON TECHNISCHEN PROZESSMODELLEN

„Ist es nicht sonderbar, daß eine wörtliche Übersetzung fast immer eine schlechte ist? Und doch

In diesem Kapitel wird zuerst darauf eingegangen warum es erstrebenswert ist, die im vorigen Kapitel beschriebenen technischen Modelle aus einer fachlichen Grundlage abzuleiten. Anschließend wird auf Probleme in diesem Zusammenhang eingegangen.

In der zweiten Hälfte des Kapitels wird erklärt, über welche Merkmale eine Unterscheidung der Ansätze vorgenommen wird. Im letzten Teil des Kapitels erfolgt die Beschreibung der zurzeit existierenden Ansätze.

5.1 Ziele

Technische Modelle könnten modelliert werden, ohne dass auf eventuell vorhandene Geschäftsprozessmodelle Rücksicht genommen wird. Daraus ergeben sich aber folgende Probleme: Wenn Geschäftsprozesse festgehalten werden und in der IT dann die Modellierung der Abläufe, unter Einbeziehung von Aspekten der Implementierung, neu erfolgt ist die Konsistenz der fachlichen Anforderungen nicht gewährleistet. Die mangelnde Durchgängigkeit von den fachlichen Anforderungen zur technischen Implementierung kann somit als „Top-Down-Problem“ bezeichnet werden. ³⁷ Umgekehrt kommt es wiederum vor, dass durchgeführte Änderungen an der technischen Implementierung nicht in den fachlichen Modellen abgebildet werden. Das bedeutet die tatsächlichen, in der IT implementierten, Prozesse entsprechen nicht mehr der fachlichen Dokumentation. Dieses Problem wird als „Bottom-Up-Problem“ bezeichnet. 38

Durch die Ableitung der technischen Modelle aus den Geschäftsprozessmodellen soll eine Durchgängigkeit gefördert werden, mit deren Hilfe beide Probleme vermieden werden.

5.2 Herausforderungen

Die größte Herausforderung bei der Überleitung ist, das fachliche Modelle in der Regel nicht alle Daten enthalten, die für die automatisierte Abarbeitung auf einem Workflow-Management-System benötigt werden. 39

³⁷ Vgl. (Thomas, et al., 2007) S. 6

³⁸ Vgl. (Thomas, et al., 2007) S. 6

³⁹ Vgl. (Gadatsch, 2008) S. 3

15

Ableitung von technischen Prozessmodellen

Weiters kommt hinzu, dass fachliche Beschreibungssprachen oft abstrakte Elemente enthalten, die technisch nicht umgesetzt werden können. Die Aussagekraft der unterschiedlichen Modelle ist also nicht deckungsgleich.

Für die Überleitung eines fachlichen Modells in einen technischen Workflow gibt es derzeit keine einheitliche Vorgehensweise. ⁴⁰ Es gibt jedoch Vorschläge, welche jeweils ein Beispiel anhand einer konkreten Implementierung zeigen, wie beispielsweise in (Allweyer, 2008) und in den unter Abschnitt 1.5 genannten Arbeiten.

5.3 Unterscheidungsmerkmale für Ableitungsmethoden

Um unterschiedliche Varianten differenzieren zu können, wird hier definiert, anhand welcher Faktoren die einzelnen Methoden unterschieden werden. Um eine möglichst aussagekräftige Antwort auf die Fragen zu stellen, die in Kapitel 1.2 genannt wurden, muss die Unterscheidung zwischen den Vorgehensweisen abgegrenzt werden.

Da diese Arbeit Fragen untersucht, welche sich mit der Ableitung eines technischen Modells aus einem fachlichen Modell befassen, wurden folgende Kriterien gewählt:

• Wie wird das technische Modell abgeleitet?

• In welches Modell werden die technischen Informationen hinzugefügt?

Es gibt auch Aspekte, welche zum Zweck der Verständlichkeit verallgemeinert wurden, und welche nicht unterschieden werden. Diese sind:

• Welche Modellierungssprache wird für das fachliche Modell verwendet?

• Welche Modellierungssprache wird für das technische Modell verwendet?

• Wie werden die einzelnen Objekte zwischen den Modellen übersetzt?

• Welches Tool wird verwendet?

• Welche Abteilung führt welche Tätigkeit durch?

⁴⁰ Vgl. (Allweyer, 2008) S. 5

16

Ableitung von technischen Prozessmodellen

5.4 Lösungsansätze

In diesem Kapitel sollen jene Lösungsansätze erklärt werden, die anhand der Faktoren zur Unterscheidung getrennt werden können. Die Ableitungsmethoden werden in diesem Kapitel theoretisch beschrieben, während Beispiele für ihre praktische Umsetzung in Kapitel 7 beschrieben werden.

5.4.1 Keine Ableitung

Es besteht die Möglichkeit Workflowmodelle zu erstellen, ohne diese aus Prozessmodellen abzuleiten. Der Grund dafür kann sein, dass es keine Geschäftsprozessmodelle gibt oder diese von der IT-Abteilung eines Unternehmens nicht beachtet werden.

Auf diese Möglichkeit wird nicht weiter eingegangen, da diese Arbeit sich mit der Ableitung von technischen Modellen befasst. Diese Vorgehensweise wird hier lediglich erwähnt um sie klar von der manuellen Transformation abzugrenzen.

5.4.2 Manuelle Transformation

Hierbei wird das Workflowmodell in einer technischen Notation neu modelliert. Als Basis dafür werden Geschäftsprozessmodelle verwendet. Es wird in den Workflowmodellen eine Referenz auf die fachlichen Modelle hinterlegt. Auf diese Weise kann jede Notation in jede andere übersetzt werden, da ein Mensch die Transformation vornimmt.

Technische Informationen, wie zum Beispiel Funktionsaufrufe in einem Dokumentenmanagementsystem oder Service-Definitionen in einer SOA, werden während der Erstellung des technischen Modells eingearbeitet.

5.4.3 Halbautomatische Transformation

Bei einer halbautomatischen Transformation werden aus dem fachlichen Modell so viele Informationen wie möglich direkt in ein technisches Modell übernommen.

Die technischen Informationen, die nicht aus dem fachlichen Modell übernommen werden können, müssen nach der Transformation manuell hinzugefügt werden.

5.4.4 Automatische Transformation

In dieser Variante wird das technische Modell komplett automatisiert aus dem fachlichen Modell generiert.

Damit dieser Schritt möglich wird, müssen sämtliche technischen Informationen vorab im fachlichen Modell enthalten sein. Alle Bedingungen müssen bereits so weit formalisiert sein, dass diese in einem Workflow überprüft werden können.

17

Ableitung von technischen Prozessmodellen

Weiters müssen alle Konstrukte der fachlichen Notation nahezu eindeutig sein. Sie dürfen also nur so wenig Interpretationsspielraum offen lassen, dass eine Workflow-Engine damit umgehen kann. Dies kann auch dadurch erreicht werden, dass die Möglichkeiten der fachlichen Notation eingeschränkt werden.

18

Bewertungskriterien

6 BEWERTUNGSKRITERIEN

„You will never know unless you ask.”

Jack Stack, amerikanischer Topmanager

In diesem Kapitel sind die Kriterien beschrieben, welche in Kapitel 8 für die Bewertung herangezogen werden.

In den Bewertungskriterien wird nicht darauf eingegangen, welche Abteilung welche Tätigkeiten durchführt, da darauf auch nicht bei der Unterscheidung der Lösungsansätze unter Punkt 5.3 Rücksicht genommen wurde.

Es wird also nicht bewertet, ob beispielsweise die fachliche Abteilung technische Details ins fachliche Modell einbringt, oder ob diese Details von den Mitarbeitern der IT eingebracht werden. Der Grund dafür ist, dass diese Vorgehensweise in jedem Unternehmen anhand der Rahmenbedingungen festgelegt werden kann. Es wird jedoch sehr wohl darauf Rücksicht genommen, ob technische Details in ein fachliches Modell eingebracht werden müssen oder nicht.

Jedes Kriterium besteht aus einer Bezeichnung, und der Fragestellung, die dadurch beantwortet wird.

Bewertungskriterien

Tabelle 6-1: Bewertungskriterien

20

Implementierung der Lösungsansätze

7 IMPLEMENTIERUNG DER LÖSUNGSANSÄTZE

„Worte sind Zwerge - Beispiele Riesen!“

Unbekannt

In Kapitel 5.4 wurden drei Ableitungs-Ansätze theoretisch unterschieden, in diesem Kapitel wird für jeden Ansatz ein Beispiel formuliert. Pro Ansatz wird aufgelistet welche Tools zur Erstellung eines Beispiels verwendet werden und wie der Ablauf ist um zu einem vollständigen Workflowmodell zu gelangen. Der Fokus bei der Beschreibung der Beispiele liegt auf den Bewertungskriterien, also den jeweiligen Stärken und Schwächen der einzelnen Varianten. Eine detailliertere Übersicht über jedes Beispiel kann dem Anhang entnommen werden.

Im letzten Teil dieses Kapitels gibt es eine Auflistung weiterer Tools, die für eine Transformation verwendet werden könnten.

7.1 Manuelle Transformation

7.1.1 Verwendete Tools

Für dieses Beispiel müssen die fachliche Notation und das technische Modell in keinem Zusammenhang stehen.

Das fachliche Modell wird in Microsoft Office Visio als EPK modelliert. Verwendet wird die Version 2007. Eine Testversion zu Microsoft Visio kann auf der Internet-Seite von Microsoft ⁴¹ nach einer kurzen Registrierung zu Testzwecken heruntergeladen werden. Die Trial-Lizenz von Microsoft Visio hat eine Gültigkeit von 60 Tagen.

Die technische Neumodellierung erfolgt in diesem Beispiel in BPEL, wobei bestehende Services direkt als BPEL-Elemente verwendet werden. Zur Modellierung und Ausführung des Workflowmodells wird das Tool ActiveVOS des Herstellers Active Endpoints verwendet. Die verwendete Version des Produktes ist die Version 6.0.2.1. Diese Software kann ebenfalls nach einer Registrierung auf der Webseite des Herstellers ⁴² zur Evaluierung bezogen werden. Die Evaluierungslizenz hat eine Gültigkeit von 30 Tagen. ActiveVOS ist ein Werkzeug mit Fokus auf Ausführung von BPEL-Prozessen. Es besitzt eine eigene Workflow-Engine. Neben der Modellierung von BPEL-Workflows unterstützt es auch noch die Transformation von BPMN-Diagrammen zu BPEL-Diagrammen. Die Generierung von BPMN-Diagrammen aus BPEL-Diagrammen ist ebenfalls möglich.

⁴¹ www.microsoft.com

⁴² www.activevos.com

21

Implementierung der Lösungsansätze

7.1.2 Verwendetes Beispiel

Das EPK-Modell zu diesem Beispiel wurde in Visio erstellt. Dies stellt keine große Herausforderung dar, da Visio intuitiv zu benützen ist.

Für die Erstellung des BPEL-Modells wurde das Tutorial von ActiveVOS verwendet. Im Tutorial ist eine detailierte Beschreibung der Schritte von der Erstellung des BPEL-Modells bis zum Test am Server enthalten. Das Tutorial kann über die Hilfe der Applikation aufgerufen werden. Alternativ ist das Tutorial auch unter der Internetseite des von Active Endpoints einsehbar.

7.1.3 Beschreibung

Als erstes wird ein fachliches Modell in Visio erstellt. In dem EPK-Modell sind keine technischen Informationen enthalten, jedoch sind bereits alle Vorgänge, die in BPEL als Webservices eingebunden sind, als Funktionen vorhanden. Die Modellierung in Visio ist sehr intuitiv und die Modelle unterliegen keinerlei Restriktionen.

Der zweite Schritt ist die Modellierung des Ablaufes in BPEL. ActiveVOS stellt hierzu einen Editor bereit. Bei der Modellierung des BPEL-Modells wird versucht, sich so weit als möglich an dem zuvor erstellten EPK-Modell zu orientieren.

Damit das BPEL-Modell in der Workflow-Engine von ActiveVOS verwendet werden kann, muss es bestimmte Regeln erfüllen. Die Einhaltung dieser Regeln wird automatisch geprüft. Wenn ein Fehler im Modell vorhanden ist, wird dieser in einer Liste hinterlegt.

Bevor man den Prozess letzten Endes auf die Workflow-Engine installiert sollte man ihn noch simulieren. Dies ist Notwendig um Fehler zu finden, die ansonsten zur Laufzeit auftreten würden, wie eine nicht initialisierte Variable.

7.2 Halbautomatische und Automatische Transformation

Diese beiden Ansätze sind in der Theorie getrennt, in der Praxis werden sie allerdings kombiniert verwendet. Der Grund dafür ist, dass technische Details sowohl vom fachlichen Modell ins technische Modell als auch vom technischen Modell ins fachliche Modell übernommen werden können. Das hier angeführte Beispiel wird diese Möglichkeit zeigen.

7.2.1 Verwendete Tools

Für dieses Beispiel wird das fachliche Modell in BPMN erstellt. Dazu wird der Oracle Business Process Architekt (BPA) in der Version 10.1.3.4 verwendet. Dieses Tool kann in einer 90 Tage gültigen Testversion von der Webseite des Herstellers ⁴³ bezogen werden.

⁴³ www.oracle.com

22

Implementierung der Lösungsansätze

Die technische Ergänzung der Modellierung erfolgt wie bei dem Beispiel zur manuellen Transformation in BPEL. Dazu wird der JDeveloper von Oracle in der Version 10.1.3.4 verwendet, welcher ebenfalls von Oracle online bezogen werden kann. Dieses Tool gibt es in unterschiedlichen Editionen, welche sich durch ihren Funktionsumfang unterscheiden. Die für diesen Test verwendete Edition trägt den Namen „Studio Edition“. Diese Edition enthält das Tool Oracle BPEL Process Designer, welches für die Bearbeitung von BPEL-Diagrammen ermöglicht.

Die beiden Tools sind sehr eng miteinander verbunden, was die Aufrechterhaltung einer Verbindung zwischen technischem und fachlichem Modell nach der Generierung des technischen Modells ermöglicht. Der Oracle Business Process Architekt ist aus einer Kooperation von Oracle mit IDS Scheer, dem Hersteller von ARIS, entstanden und enthält Teile von dessen Transformations-Logik. Es ist zum Beispiel auch möglich EPK-Modelle zu erstellen und diese zu BPEL-Workflows zu transformieren.

7.2.2 Verwendetes Beispiel

Das verwendete Beispiel kann von der Webseite von Oracle bezogen werden. In dem Packet enthalten ist eine detailierte Beschreibung, wie das BPMN-Modell modelliert wird. Weiters ist beschrieben, wie der Geschäftsprozess simuliert und für die IT freigegeben werden kann.

7.2.3 Beschreibung der Erstellung des fachlichen Modells

Im BPA wird das BPMN-Modell erstellt. Hierzu werden als erstes Fachbegriffe und Personentypen definiert. Fachbegriffe sind im beschriebenen Beispiel Datenstrukturen, welche jedoch noch nicht vollständig spezifiziert werden müssen.

Mit diesen Daten wird das fachliche BPMN-Modell erstellt. Wichtig bei der Erstellung des fachlichen Modells ist die Unterscheidung zwischen manuellen und automatisierten Aufgaben. Das bedeutet, dass bereits bei der fachlichen Modellierung bekannt sein muss, welche Prozessschritte von der IT als Services abgearbeitet werden, und welche manuell durch Personen ausgeführt werden sollen. Dies stellt jedoch keine große Herausforderung dar, da dies in der Regel bekannt ist.

An dieser Stelle kann man sich auch pro automatisierter Aufgabe entscheiden, ob diese automatisch oder halbautomatisch in das technische Modell übernommen werden soll: Wenn man eine Aufgabe als automatisierte Aufgabe in das Modell einfügt, kann man dieser Aufgabe auch eine Service-Beschreibung hinzufügen. Alternativ dazu kann man jedoch die automatisierte Aufgabe auch abstrakt belassen, was bedeuten würde, dass die Service-Beschreibung anschließend im technischen Modell hinzugefügt werden muss.

7.2.4 Ablauf bei der Generierung des technischen Modells

Wenn das BPMN-Modell vollständig modelliert wurde, kann dieses für die IT freigegeben werden. Im Rahmen der Freigabe sind zwei Schritte notwendig:

23

Implementierung der Lösungsansätze

• Als erstes wird das BPMN-Modell validiert. Der Grund dafür ist, dass nicht jeder in BPMN modellierte Ablauf zu einem eindeutigen BPEL-Modell transformiert werden kann. Wird bei der Validierung ein Konstrukt im BPMN-Modell gefunden, das nicht in BPEL abgebildet werden kann, bekommt der Benutzer einen Report darüber und muss das BPMN-Modell entsprechend anpassen.

• Im zweiten Schritt wird das Modell vollautomatisch in ein BPEL-Diagramm übergeführt. Vollautomatisch bedeutet jedoch nicht, dass das BPEL-Diagramm vollständig ist. Dies wird erst in einem weiteren Schritt sichergestellt.

7.2.5 Überprüfung und Nachbearbeitung des technischen Modells

Der nächste Schritt in der Erstellung des Workflows erfolgt mit dem JDeveloper. In diesem Tool wird der erstellte BPEL-Workflow importiert.

Im JDeveloper wird das BPEL-Modell automatisch validiert. Wenn es validierbar ist, kann es auf einem Applikationsserver eingesetzt werden. Ansonsten muss der Ablauf in BPEL angepasst werden. Sehr wichtig hierbei ist jedoch, dass der angepasste BPEL-Workflow mit dem BPMN-Modell synchronisiert wird. Nach der Vervollständigung des BPEL-Workflow können alle Änderungen in das BPMN-Diagramm übernommen werden. Wurden also technische Informationen im BPMN-Diagramm abstrahiert, können diese aus dem technischen Modell in das fachliche Modell übernommen werden.

7.2.6 Vorgehen bei Änderungen

Im vorigen Abschnitt wurde beschrieben, dass Änderungen am technischen Modell in das fachliche Modell übernommen werden können. Dies funktioniert auch umgekehrt. Wenn am BPMN-Diagramm eine Änderung vorgenommen wurde, kann dieses erneut für die IT freigegeben werden. Die sich daraus ergebenden Änderungen am BPEL-Modell werden im JDeveloper mit dem bestehenden BPEL-Workflow fusioniert. Es geht also keine Information verloren, solang nicht ein Prozessschritt im BPMN-Diagramm gelöscht wurde.

7.3 Weitere Transformationstools

Tools zur Modellierung von Geschäftsprozessen sind allgemein weit verbreitet. Die hier aufgeführten Tools sind in der Lage, fachliche Modelle in Workflowbeschreibungen zu transformieren oder zu exportieren. Diese Liste erhebt keinen Anspruch auf Vollständigkeit, soll jedoch zeigen, dass es noch weitere Umsetzungen des halbautomatischen und automatischen Ansatzes gibt, als die hier aufgeführten.

Implementierung der Lösungsansätze

Tabelle 7-1: Weitere Transformationstools

25

Bewertungsmatrix

8 BEWERTUNGSMATRIX

„Der gute Redner wird Vergleiche anwenden und Beispiele vorbringen.“

Marcus Tullius Cicero (106-43), römischer Redner und Schriftsteller

In der Bewertungsmatrix befinden sich die unter Abschnitt 6 definierten Bewertungskriterien und die in Kapitel 5.4 beschriebenen Ableitungs-Ansätze. In den Spalten ist jeweils eine Variante bewertet, in den Zeilen können die Varianten direkt verglichen werden. Die beiden Ansätze halbautomatische Transformation und automatische Transformation wurden in einem Praxisbeispiel vereint. Für die Bewertungsmatrix wird jedoch der jeweilige Extremfall beschrieben.

Tabelle 8-1: Bewertungsmatrix

26

Fazit der Bewertung

9 FAZIT DER BEWERTUNG

Es gibt in der Praxis derzeit zwei Vorgehensweisen, um einen Workflow aus einem Geschäftsprozessmodell abzuleiten.

Die erste Möglichkeit ist die manuelle Neuerstellung des Workflows auf Basis des zuvor erstellten Geschäftsprozessmodells. Die Stärken dieser Variante sind, dass das fachliche Modell keinen Einschränkungen unterliegt und in keiner speziellen Notation vorliegen muss. Darüber hinaus bleibt das fachliche Modell frei von technischen Einflüssen. Dass der Workflow manuell neu erstellt wird, ist jedoch nicht nur ein erhöhter Aufwand, sondern es kann auch, wenn das Geschäftsprozessmodell falsch interpretiert wird, zu Inkonsistenzen kommen. Ein weiterer Nachteil ist, dass jede Änderung des Geschäftsprozessmodells im Workflowmodell auch manuell nachgezogen werden muss. Neben einem organisatorischen Aufwand entsteht hierdurch auch eine Fehlerquelle, durch die Inkonsistenzen entstehen können.

Die zweite Möglichkeit zur Ableitung eines Workflowmodells aus einem Geschäftsprozessmodell ist eine automationsunterstützte Ableitung. Diese Variante hat zwei Extreme, die halbautomatische Ableitung und die automatische Ableitung. In der Praxis ist jeder Mittelweg zwischen diesen beiden Extremen möglich. Unternehmen, die eine automationsunterstützte Ableitung verwenden wollen, müssen selbst entscheiden, wie viele technische Informationen bei der Erstellung des fachlichen Modells sinnvoll sind. Dies kann von den technischen Kenntnissen des Modellierers abhängig gemacht werden.

Die automationsunterstützte Ableitung hat gegenüber der manuellen Ableitung den Vorteil, dass es technisch möglich ist, die Konsistenz zwischen dem fachlichen Modell und Workflow aufrecht zu erhalten. Veränderungen an einem Modell werden verhindert, solange Änderungen des anderen Modells noch nicht übernommen wurden. Weiters ist die Übernahme von Änderungen nur mit einem kleinen Aufwand verbunden, da das verwendete Tool diese übernimmt und im Zielmodell die betreffenden Stellen markiert. Der Nachteil des automationsunterstützten Ansatzes ist, dass das Ausgangsmodell Einschränkungen unterworfen ist und in einer bestimmten Form vorhanden sein muss. Dies ist in der Praxis immer dann ein Problem, wenn bei der Modellierung von Geschäftsprozessmodellen nicht an eine spätere Transformation gedacht wurde. So erstellte Geschäftsprozessmodelle müssen aufwendig angepasst werden.

Die Möglichkeit Änderungen zwischen fachlichem Modell und technischem Modell in beide Richtungen zu übernehmen, ist ein großer Fortschritt. Unternehmen sind nun nicht mehr gezwungen sich zwischen automatischer und halbautomatischer Ableitung zu entscheiden. Es ist dadurch Möglich ein fachliches Modell mit minimalen technischen Aspekten zu erstellen und dieses fachliche Modell von der IT um technische Informationen erweitern zu lassen. Dadurch wird verhindert, dass Änderungen nach der

27

Fazit der Bewertung

Ableitung durch einen halbautomatischen Ansatz, manuell vom fachlichen in das technische Modell übernommen werden müssten.

28

Zusammenfassung und Ausblick

10 ZUSAMMENFASSUNG UND AUSBLICK

In dieser Arbeit wurden drei theoretische Varianten zur Ableitung von Workflows aus Geschäftsprozessmodellen beschrieben. Diese drei Ansätze sind manuelle Transformation, halbautomatische Transformation und automatische Transformation.

Anschließend wurden für die theoretischen Varianten Implementierungen durchgeführt. Bei der Implementierung wurde festgestellt, dass der Übergang zwischen halbautomatischer Transformation und automatischer Transformation heute bereits fließend ist. Möglich wird dies durch eine Synchronisation des technischen Modells und des fachlichen Modells, welche in beide Richtungen funktioniert. Bei der Bewertung der Ansätze durch sechs zuvor definierte Kriterien hat sich gezeigt, dass ein automationsunterstützter Ansatz bei der fachlichen Modellierung einen höheren Aufwand und Einschränkungen bedingt. Diese Nachteile werden jedoch im Nachhinein durch die Vorteile, die eine automationsunterstütze Generierung des technischen Modells mit sich bringt, mehr als ausgeglichen. Die IT ist jedoch bereits an der Grenze des Möglichen, wenn es um die Interpretation von Geschäftsprozessmodellen geht. Es können nicht alle Konstrukte und nicht alle Notationen fachlicher Geschäftsprozessmodelle transformiert werden. Die automationsunterstützte Ableitung wird sich also nur dann endgültig gegen die manuelle Ableitung durchsetzten, wenn Unternehmen in Zukunft bei der Modellierung fachlicher Geschäftsprozessmodelle auf die Möglichkeit einer Implementierung durch die IT Rücksicht nehmen.

Eine wünschenswerte Entwicklung für die Zukunft wäre jedoch, dass die automationsunterstützte Ableitung und die daran anschließende Synchronisation bei Änderungen standardisiert werden. Bis jetzt ist eine automationsunterstütze Ableitung nur dann möglich, wenn IT und Fachabteilung mit Tools desselben Herstellers arbeiten. Das ist vor allem dann eine Einschränkung, wenn bei der Modellierung der fachlichen Modelle noch nicht mit Sicherheit gesagt werden kann, ob diese später für die IT transformiert werden. In weiteren Arbeiten könnten Möglichkeiten für den grundsätzlichen Aufbau einer solchen Schnittstelle entwickelt werden.

29

Modellierung des EPK-Modells

ANHANG A: BEISPIEL ZUR MANUELLEN

TRANSFORMATION

In diesem Anhang ist ein Auszug aus dem Beispiel zur manuellen Transformation enthalten. Der erste Teil beschreibt die Erstellung des EPK-Modells in Visio. Der zweite Teil beschreibt, wie der Workflow erstellt werden kann und was dabei beachtet werden muss.

(A) MODELLIERUNG DES EPK-MODELLS

In dem folgenden Screenshot ist die Oberfläche von Visio zur Modellierung des EPK-Modells zu sehen.

Abbildung A-1: Modellierung in Visio

Die Modellierung in Visio funktioniert, indem man die Elemente von der Palette auf das Zeichenblatt zieht und mittels Pfeilen verbindet. Dabei werden keinerlei Regeln überprüft, man muss daher bereits wissen, wie ein EPK-Modell auszusehen hat.

30

Modellierung des EPK-Modells

Abbildung A-2 zeigt das fertige EPK-Modell.

Abbildung A-2: -EPK-Modell zur manuellen Ableitung

Das EPK-Modell stellt einen vereinfachten Ablauf zur Kreditvergabe dar. Der Ablauf startet mit dem Einlangen einer Kredit-Anfrage. Je nach Höhe des angefragten Darlehens wird es entweder an die Risiko-Bewertung oder zur Begutachtung gegeben. Die Begutachtung und die Risiko-Bewertung sind hierbei Geschäftsbereiche außerhalb der Kreditvergabe. Je nach deren Antwort wird dem Kunden entweder eine Zusage oder eine Absage gesendet, womit der Prozess beendet wird. Im EPK-Modell sind keine technischen Informationen enthalten. Die Risiko-Bewertung und die Begutachtung werden später als Web-Services implementiert sein, doch dies ist hier nicht zwingend anzugeben.

31

Erstellung des Workflows

(B) ERSTELLUNG DES WORKFLOWS

In ActiveVOS kann man sich ein durch „File/New/Orchestration Project“ das Menü zur Erstellung eines neuen Projektes öffnen, das in Abbildung A-3 zu sehen ist.

Abbildung A-3: -Dialog zur Erstellung eines neuen Projektes

Durch Auswahl des Punktes „Tutorial“ erhält man ein Projekt, in dem bereits die Web-Service-Definitionen (WSDL-Dateien) für die beiden externen Abteilungen enthalten sind. Ebenfalls im Projekt enthalten ist ein XML-Schema, das die Definition der Datenstruktur eines Kreditantrags enthält. In der Praxis würde man diese Beschreibungen entweder von den jeweiligen Partnern zur Verfügung gestellt bekommen oder würde sie selbst erstellen.

Aus diesen Komponenten kann der Workflow in BPEL modelliert werden. Dazu müssen die Schritte des Tutorials befolgt werden. Die folgende Darstellung zeigt die Entwicklungsumgebung.

32

Erstellung des Workflows

Abbildung A-4: -ActiveVOS Entwicklungsumgebung

Links im Bild ist der Verzeichnisbaum, in dem das XML-Schema und einige WSDL-Dateien zu sehen sind. Rechts zu sehen ist die Palette, aus der die einzelnen Elemente auf das Modell gezogen werden können. Im unteren Bereich gibt es zwei wichtige Registerkarten. Die erste ist „Problems“, welche alle Gründe anzeigt, aus denen das Modell noch nicht installiert werden kann. Der zweite Punkt ist „Properties“. Hinter jedem Element auf der Oberfläche sind auf den ersten Blick nicht sichtbare Informationen hinterlegt, welche für den Ablauf benötigt werden. Abbildung A-5 zeigt den vollständig modellierten Workflow.

33

Erstellung des Workflows

Abbildung A-5: - BPEL-Workflow

Obwohl der Prozess in BPEL auf den ersten Blick dem EPK-Modell nicht sehr ähnelt, ist er doch nahezu ident. Nach dem Einlangen einer Kreditanfrage wird festgestellt, welcher Pfad als nächstes verfolgt wird. Hinter den Pfaden „small loan“ und „large loan“ ist in den Eigenschaften die jeweilige Bedingung zum Betrag hinterlegt.

Die Einbindung der Risiko-Bewertung und der Begutachtung ist über Invoke-Aktivitäten abgebildet, welche einen Webservice-Aufruf darstellen.

Dem Antrag wird am Ende entweder eine Zustimmung oder eine Ablehnung zugewiesen, oder es wird direkt von der Begutachtung der Wert für die Antwort gesetzt. Schließlich wird diese Antwort gesendet. Dem Prozess wurde jedoch auch etwas hinzugefügt, was im EPK-Modell nicht berücksichtigt wurde. In Abbildung A-6 ist die Fehlerbehandlung zu sehen, die im EPK-Modell abstrahiert wurde.

34

Erstellung des Workflows

Abbildung A-6: - BPEL-Fehlerbehandlung

In diesem Fall wird bei einem Fehler eine Fehlermeldung als Antwort gesendet. Bereits hier wird jedoch erkennbar, das es zu Inkonsistenzen zwischen dem fachlichen und dem technischen Modell kommen kann, wenn das fachliche Modell zu wenige Informationen enthält: Was wäre, wenn von der Fachabteilung hier eigentlich ein menschlicher Eingriff angedacht gewesen wäre? Bevor man den Prozess letzten Endes auf die Workflow-Engine installiert, sollte man diesen noch simulieren. Dies ist Notwendig um Fehler zu finden, die ansonsten zur Laufzeit auftreten würden, wie eine nicht initialisierte Variable. Die Schritte zur Installation auf dem Server sind ebenfalls im Tutorial enthalten. In Abbildung A-7 ist der ausführbare Workflow in der Engine von ActiveVOS zu sehen.

35

Erstellung  des Workflows  

Abbildung  A-7: - Ausführbarer BPEL-Prozess  

36

Modellierung des BPMN-Modells

ANHANG B: BEISPIEL ZUR

AUTOMATIONSUNTERSTÜTZTEN TRANSFORMATION

In diesem Anhang ist ein Auszug aus dem Beispiel zur halbautomatischen und automatischen Transformation enthalten.

Der Anhang ist in vier Abschnitte unterteilt. Im ersten Abschnitt wird die Erstellung des fachlichen BPMN-Modells gezeigt. Abschnitt B zeigt, wie das BPEL-aus dem BPMN-Diagramm generiert wird. Im dritten Teil wird gezeigt, wie das BPEL-Diagramm in den JDeveloper übernommen wird, verändert wird und wie die Änderungen wieder in das BPMN-Diagramm übernommen werden. Im letzten Teil wird gezeigt, wie Änderungen aus dem BPMN-Diagramm ins BPEL-Diagramm übernommen werden. Der Fokus dieser Beschreibung dient nicht der Implementierung, sondern der Demonstration der Transformationsfähigkeiten.

(A) MODELLIERUNG DES BPMN-MODELLS

Die Modellierung des BPMN-Modells erfolgt von Grund auf im BPA. Die nächste Abbildung zeigt die Oberfläche des Tools.

37

Modellierung des BPMN-Modells

Abbildung B-1: - Oracle BPA Oberfläche

Die Oberfläche des BPA ist in mehrere Module zerteilt. Links ist eine Leiste, in der man zwischen den Modulen wechseln kann. Für das Beispiel sind die Module Explorer und Designer relevant. Alle Daten, die im BPA erfasst werden können, sind in einem Menü-Baum gegliedert. Dieser kann im Explorer betrachtet werden. Der Designer dient dazu Modelle auf einer grafischen Oberfläche zu bearbeiten.

Vor der Modellierung des BPMN-Modells müssen gemeinsam genutzte Daten erstellt werden. Diese sind in der Abbildung B-1 markiert.

Nach der Erstellung der gemeinsam genutzten Daten wird das BPMN-Modell modelliert. Die nächste Abbildung zeigt den Modell-Editor von BPA.

38

Modellierung des BPMN-Modells

Abbildung B-2: - Oracle BPA Designer

In der Modellierungsoberfläche ist in der Mitte das Modell zu sehen. Rechts ist eine Palette, aus der die verwendbaren Elemente auf dem Modell abgelegt werden können.

Der Prozess der in diesem Modell abgebildet ist, ist eine Angebots-Verwaltung. Der Prozess besteht aus zwei Teilen. An dem markierten Symbol ist zu erkennen, dass hinter dem Element ein weiteres Modell hinterlegt ist.

Im ersten Teil-Prozess, „Process Quote“, wird eine Anfrage vom Kunden entgegengenommen und diesem ein Angebot erstellt, welches er annimmt oder ablehnt.

Der zweite Teil-Prozess, „Process Order“, wird gestartet, wenn der Kunde ein Angebot angenommen hat. Dieser Teilprozess ist in der Abbildung B-3 dargestellt.

39

Modellierung des BPMN-Modells

Abbildung B-3: - Process Quote-Teilprozess

Hier wird automatisch aus dem Angebot eine Bestellung erstellt, die Kundendaten abgefragt und weiters die Kreditwürdigkeit des Kunden ermittelt. Anschließend wird der Antrag manuell durch den Supervisor bestätigt oder abgelehnt. Bei Bestätigung wird der Auftrag außerdem noch ausgeführt. Die vier Aufgaben im grünen Bereich sind automatisierte Aufgaben. Während die beiden Aufgaben „Create Order“ und „Cancel Order“ abstrakt sind, ist hinter „Get Credit Information“ bereits ein Web-Service-Aufruf hinterlegt, wie in der Abbildung B-4 zu sehen ist.

40

Ableitung des Workflows

Abbildung B-4: -Hinterlegter Service-Aufruf

(B) ABLEITUNG DES WORKFLOWS

Der Geschäftsprozess für dieses Beispiel besteht aus drei BPMN-Modellen. Jedes Modell kann jedoch einzeln abgeleitet werden, da jedes Modell ein abgegrenzter Prozess ist, der auch eigenständig funktionieren kann.

In diesem Beispiel wird nur der Teilprozess „Process Quote“ abgeleitet. Dazu öffnet man das Diagramm und wählt im Menü „SOA“ den Menüpunkt „Entwurf für IT freigeben“. Hierdurch gelangt man zur Validierung des Modells.

Nach der Validierung wird im Browser der Bericht angezeigt, welcher alle Probleme beschreibt, die eine Konvertierung verhindern.

41

Ableitung des Workflows

Abbildung B-5: -Validierungs-Bericht

Gibt es, wie in diesem Beispiel, keine Regelverstöße, so wird das Modell konvertiert. Das generierte Modell kann anschließend im BPA betrachtet werden.

42

Ableitung  des Workflows  

Abbildung  B-6: -Generiertes BPEL-Modell  

43

Überprüfung und Nachbearbeitung des technischen Modells

(C) ÜBERPRÜFUNG UND NACHBEARBEITUNG DES

TECHNISCHEN MODELLS

Als nächstes wird der Workflow im JDeveloper geöffnet. Dabei lädt er alle Elemente, die bei der Transformation erstellt wurden. Anschließend wird das BPEL-Modell geöffnet. Der folgende Screenshot zeigt die Entwicklungsoberfläche des JDeveloper.

Abbildung B-7: -JDeveloper GUI

Links im Bild ist der Verzeichnisbaum, in dem alle Artefakte abgelegt sind. Links unten befindet sich eine Übersicht über den BPEL-Prozess gegliedert nach Typ der Artefakte.

Die beiden Buttons rechts oben führen zu zwei verschiedenen Ansichten des BPEL-Prozesses. Die „Blue Print View“ ist eine kompaktere, aber auch abstraktere Ansicht. Die BPEL View schließlich ist der komplett detailierte Prozess.

44

Überprüfung und Nachbearbeitung des technischen Modells

Das BPEL-Modell wird automatisch überprüft und validiert. Rechts unten sieht man die Ausgabe dieser Validierung. In diesem Modell gibt es noch Fehler, die behoben werden müssen, bevor das Diagramm auf dem Server installiert werden kann. Diese Anpassungen werden im JDeveloper vorgenommen. Nach dem das BPEL-Modell geändert wurde, müssen die Änderungen auch ins BPMN-Modell übernommen werden. Dazu muss das BPEL-Modell am Server aktualisiert werden, wie die Abbildung B-8 zeigt.

Abbildung B-8: -Änderungen in das BPMN-Diagramm übernehmen.

45

Überprüfung und Nachbearbeitung des technischen Modells

Sobald dies im JDeveloper geschehen ist wird am Server eine zweite Version des BPMN-Diagrammes angezeigt.

Abbildung B-9: -BPMN-Diagramm und geändertes Diagramm

Das Original-Modell am Server darf nun nicht verändert werden, bis die Änderungen aus dem technischen Modell entweder übernommen oder abgelehnt wurden.

Um die Änderungen zu übernehmen, muss am Server das Diagramm mit den Änderungen geöffnet werden und die Änderungen müssen angenommen werden, wie in Abbildung B-10 zu sehen.

46

Vorgehen bei Änderungen

Abbildung B-10: -Übernahme der Änderungen in das BPMN-Diagramm

(D) VORGEHEN BEI ÄNDERUNGEN

Wie in Punkt (c) erläutert können Änderungen am technischen Modell ins fachliche Modell übernommen werden. Dies funktioniert auch umgekehrt.

Dazu wird das Modell im BPA geändert und erneut freigegeben, womit es erneut validiert und transformiert wird. Im JDeveloper können diese Änderungen nun ebenfalls übernommen werden.

47

Vorgehen bei Änderungen

Abbildung B-11: -Übernahme des geänderten Prozesses

Abbildung B-11 zeigt den Report, den man vom JDeveloper erhält. In diesem Fall wurde am Server im BPMN-Modell der Kontrollfluss verändert. Diese Abbildung erhält man, wenn man den Button betätigt, der am oberen Ende in der Mitte des Screenshots markiert ist.

Wenn man den Button rechts betätigt, erhält man zum Vergleich den Prozess vor und nach der Änderung, wie die Abbildung B-12: -Prozessdifferenzen zeigt.

48

Vorgehen  bei Änderungen  

Abbildung  B-12: -Prozessdifferenzen  

49

Abkürzungsverzeichnis

ABKÜRZUNGSVERZEICHNIS

SOA Service Orientierte Architektur WFMS Workflow-Management-System BPEL Business Process Execution Language BPML Business Process Modelling Languague XML Extensible Markup Languague XPDL XML Process Definition Language BPA Oracle Business Process Architect EPK Ereignisgesteuerte Prozesskette BPA Oracle Business Process Architekt WSDL Web-Service Definition Languague IT Informationstechnologie ERP Enterprise Resource Planning ISO International Organisation for Standardisation DIN Deutsche Industrie Norm

50

Abbildungsverzeichnis   

Abbildungsverzeichnis   

Abbildung  4-1: Beispiel Prozessmodell  

Abbildung  4-2: Prozessdetailierung  

Abbildung  A-1: Modellierung in Visio  

Abbildung  A-2: -EPK-Modell zur manuellen Ableitung  

Abbildung  A-3: -Dialog zur Erstellung eines neuen Projektes  

Abbildung  A-4: -ActiveVOS Entwicklungsumgebung  

Abbildung  A-5: - BPEL-Workflow  

Abbildung  A-6: - BPEL-Fehlerbehandlung  

Abbildung  A-7: - Ausführbarer BPEL-Prozess  

Abbildung  B-1: - Oracle BPA Oberfläche  

Abbildung  B-2: - Oracle BPA Designer  

Abbildung  B-3: - Process Quote-Teilprozess  

Abbildung  B-4: -Hinterlegter Service-Aufruf  

Abbildung  B-5: -Validierungs-Bericht  

Abbildung  B-6: -Generiertes BPEL-Modell  

Abbildung  B-7: -JDeveloper GUI  

Abbildung  B-8: -Änderungen in das BPMN-Diagramm übernehmen.  

Abbildung  B-9: -BPMN-Diagramm und geändertes Diagramm  

Abbildung  B-10: -Übernahme der Änderungen in das BPMN-Diagramm  

Abbildung  B-11: -Übernahme des geänderten Prozesses  

Abbildung  B-12: -Prozessdifferenzen  

51

Tabellenverzeichnis   

TABELLENVERZEICHNIS   

Tabelle 3-1:  Definitionen für Workflow  7

Tabelle 4-1:  Zweck fachlicher Prozessmodelle  12

Tabelle 6-1:  Bewertungskriterien  20

Tabelle 7-1:  Weitere Transformationstools  25

Tabelle 8-1:  Bewertungsmatrix  26

52

Literaturverzeichnis

LITERATURVERZEICHNIS

Aalst, van der, Wil und van Hee, Kees. 2004. Workflow Management. s.l. : MIT Press, 2004. ISBN: 978-0262720465.

Allweyer, Thomas. 2008. Vom fachlichen Modell zum ausführbaren Workflow. Fachhochschule Kaiserslautern. 2008.

Andres, Thomas. 2006. Vom Geschäftsprozess zur Anwendung: Modellgetriebene Entwicklung betriebswirtschaftlicher Software. [Buchverf.] August-Wilhelm Scheer, et al. Agilität durch ARIS Geschäftsprozessmanagement. Berlin Heidelberg : Springer Verlag, 2006. Becker, Jörg, Kugeler, Martin und Rosemann, Michael. 2006. Prozessmanagement - Ein Leitfaden zur prozessorientierten Organisationsgestaltung. 5. Auflage. Berlin Heidelberg : Springer-Verlag, 2006. ISBN 3-540-23493-4.

Beer, Daniel, Dümmler, Jörg und Rünger, Gudula. 2007. Transformation von Prozessmodellen in Workflowbeschreibungen. Fakultät für Informatik, Technische Universität Chemnitz. Chemnitz : s.n., 2007.

Bischoff, Georg, Kersten, Roland und Vetter, Thorsten. 2005. Vergleich von BPEL-Workflow Modellierungstools. Softwaretechnik, Universität Stuttgart. 2005.

Fischer, Herbert, Fleischmann, Albert und Obermeier, Stefan. 2006. Geschäftsprozesse realisieren. Wiesbaden : Vieweg-Verlag, 2006. ISBN 3-8348-0053-8.

Gadatsch, Andreas. 2008. Grundkurs Geschäftsprozessmanagement. 5. Auflage. Wiesbaden : Vieweg-Verlag, 2008. ISBN 978-3-8348-0363-4.

Herrmann, Wolfgang. 2008. Was vom SOA-Hype übrig bleibt. Computerwoche. 3. Oktober 2008, 42, S. 3.

Kopp, Oliver. 2005. Abbildung von EPKs nach BPEL anhand des Prozessmodellierungswerkzeugs Nautilus. Institut für Architektur von Anwendungssystemen. Stuttgart : s.n., 2005. Kurbel, Karl, Nenoglu, Georg und Schwarz, Christian. 1997. Von der Geschäftsprozeßmodellierung zur Workflowspezifikation - Zur Kompatibilität von Modellen und Werkzeugen. HMD. November 1997, 198.

Langner, Matthias. 2007. Grundlagen der Personalwirtschaft und der Geschäftsprozessmodellierung. Ressourcenorientierte Arbeitswirtschaft. Wiesbaden : Deutscher Universitäts-Verlag, 2007. Masak, Dieter. 2007. SOA? Berlin Heidelberg : Springer-Verlag, 2007. ISBN 978-3-540-71871-0. Nissen, Volker, Petsch, Mathias und Schorcht, Hagen. 2007. Service-Orientierte Architekturen. Wiesbaden : Gabler-Verlag, 2007. ISBN 978-3-8350-0815-1.

OASIS. 2007. Web Services Business Process Execution Language Version 2.0. [Online] 11. April 2007. [Zitat vom: 21. November 2008.] http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf. Object Management Group. 2008. Business Process Modeling Notation, V1.1. [Online] 2008. [Zitat vom: 20. November 2008.] http://www.omg.org/spec/BPMN/1.1/PDF.

Österle, Hubert und Vogler, Petra. 1996. Praxis des Workflow- Managements. Grundlagen, Vorgehen, Beispiele. Wiesbaden : Vieweg+Teubner, 1996. 978-3528055325.

53

Rosenkranz, Friedrich. 2006. Geschäftsprozesse - Modell- und Computergestützte Planung. 2. Auflage. Berlin Heidelberg : Springer-Verlag, 2006. ISBN 3-540-28343-9.

Scheer, August Wilhelm. 2002. ARIS. Vom Geschäftsprozeß zum Anwendungssystem. Berlin : Springer Verlag, 2002. 978-3540658238.

Seemann, Jochen und Wolff von Gudenberg, Jürgen. 2006. Software-Entwurf mit UML 2. 2. Auflage. Berlin Heidelberg : Springer Verlag, 2006. ISBN 978-3-540-30949-9.

Staud, Josef. 2006. Geschäftsprozessanalyse. 3. Auflage. Berlin Heidelberg : Springer Verlag, 2006. ISBN 978-3-540-37976-8.

Stein, Sebastian und Ivanov, Konstantin. 2007. EPK nach BPEL Transformation als Voraussetzung für praktische Umsetzung einer SOA. IDS Scheer AG. 2007.

Strohmeier, Stefan. 2008. Business Process Management-Systeme. Informationssysteme im Personalmanagement. Wiesbaden : Vieweg+Teubner Verlag, 2008.

Thomas, Oliver, Leyking, Katrina und Florian, Dreifus. 2007. Serviceorientierte Architekturen: Gestaltung, Konfiguration und Ausführung von Geschäftsprozessen. Instituts für Wirtschaftsinformatik im Deutschen Forschungszentrum für Künstliche Intelligenz. Saarbrücken : s.n., 2007. Veröffentlichung. ISSN 1438 5678.

Wilhelm von Oldenbourg, Rudolf. 2007. Prozessorganisation. s.l. : Oldenburg, 2007. 978-3486583021.

54