Überführbarkeit ereignisgesteuerter Prozessketten in BPEL (Business Process Execution Language)

Inhaltsverzeichnis

1 Einleitung
1.1 Integrales Informationsmanagement als Befähiger für ein durchgängiges Geschäftsprozessmanagement
1.2 Aufbau der Diplomarbeit
1.3 Abgrenzung des DA Themas

2 Die Vision eines durchgängigen Geschäftsprozessmanagements
2.1 Die adaptive prozessorientierte Infrastruktur als Basis für den unternehmerischen Erfolg
2.2 Geschäftsprozessmanagement GPM und Serviceorientierte Architekturen SOA

3 Von der Geschäftsprozessanalyse zur Geschäftsprozessorchestrierung
3.1 Problemfelder für ein durchgängiges Geschäftsprozessmanagement
3.2 Vom Problem- zum Lösungsraum - Designebenen
3.3 Anforderungen an fachliche Spezifikationen (Customer-Requirements)
3.4 Das Konzept der ereignisgesteuerten Prozessketten EPK
3.5 Anforderung an technische Spezifikationen (Development-Requirements)
3.6 Der OASIS Standard: Business Process Execution Language
3.6.1 Die Kernidee von BPEL
3.6.2 Die Sprachelemente von BPEL
3.6.3 Berücksichtigung lang laufender Prozesse
3.6.4 Abstrakte und ausführbare Prozesse

4 Vergleich der Konzepte EPK und BPEL
4.1 Unterschiedliche Zielgruppen
4.2 Spezifikationsdefizite einer EPK aus der BPEL Perspektive
4.2.1 Fehlende technische Informationen in der fachlichen Beschreibung des Geschäftsprozess
4.2.2 Freiheitsgrade bei der fachlichen Modellierung
4.3 Spezifikationsdefizite von BPEL aus der EPK Perspektive
4.3.1 Fehlende fachliche Informationen in der technischen Spezifikation des Geschäftsprozess
4.3.2 Keine standardisierte graphische Notation bei BPEL
4.3.3 Darstellung der Kontrollflusslogik
4.3.4 Nicht transformierbare Workflow Patterns

5 Weitere Sachverhalte bei der Überführung einer EPK in BPEL
5.1 Technische Prozessschneidung
5.2 Modellinkonsistenzen
5.2.1 Manuelle Ergänzungen
5.2.2 Auslagerung potenzieller BPEL Funktionen
5.3 Modellabstraktionen
5.3.1 Aggregationen von Aktivitäten
5.3.2 Der SOA Aspekt „Geschäftsregeln“
5.4 Rücktransformation und Round-Trip Ansatz
5.5 Evolution des BPEL-Standards
5.6 Nichtfunktionale Aspekte
5.7 Funktionsorientierte Modellierung

6 Empfehlung zur Vorgehensweise bei der Überführung ereignisgesteuerter Prozessketten in BPEL
6.1 Verwendung eines Vorgehensmodells
6.2 Schwerpunkt auf fachliche Modellierung legen
6.3 Anforderungen an eingesetzte Werkzeuge zur Modellverwaltung
6.3.1 Gemeinsames Repository für fachliche und technische Spezifikation
6.3.2 Validierung überführbarer fachlicher EPK Modelle
6.3.3 Erhalt manueller Ergänzungen bei erneuter Transformation
6.4 Verwendung von Templates
6.5 Vermeiden proprietärer Lösungen
6.6 Sinnvoller Einsatz von Erweiterungen
6.7 Grenzen der Prozessorientierung
6.7.1 Nicht standardisierte Abläufe
6.7.2 Qualität von Funktionen und effiziente Nutzung von Informationen
6.7.3 Durchlaufzeiten
6.7.4 Informelle Strukturen

7 Fazit

8 Zusammenfassung

Literaturverzeichnis

Online-Quellen

Abbildungsverzeichnis

Abbildung 1: Adaptive Enterprise Computing

Abbildung 2: SOA-Konzept „Service“: Vergleich des SILO und des SOA Ansatzes

Abbildung 3: Problemfelder beim Aufbau einer Systemlandschaft für ein durchgängiges Prozessmanagement

Abbildung 4: Chaos Report 2006 der Standish Group

Abbildung 5: Vom Problem- zum Lösungsraum

Abbildung 6: Designebenen in der SW-Entwicklung

Abbildung 7: "Order" Prozess als EPK

Abbildung 8: Order-Prozess in seiner standardisierten BPEL-Notation (XML)

Abbildung 9: Wesentliche Bestandteile einer EPK

Abbildung 10: Zeitstrahl der BPEL Historie

Abbildung 11: Allgemeine Grammatik eines WS-BPEL 2.0 Prozesses

Abbildung 12: Fachlicher Parameter

Abbildung 13: ODER Verknüpfung einer EPK mit semantischem Freiheitsgrad

Abbildung 14: In einer EPK modellierte Masche

Abbildung 15: Arbitrary Cyle

Abbildung 16: Trennung von Geschäftslogik und Entscheidungslogik

Abbildung 17: 10 Schritte vom fachlichen Prozess zur Business Driven SOA

Abbildung 18: Ereignisgesteuerte Prozesskette (EPK)

Abbildung 19: Automatisch generierter BPEL-Prozess

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Integrales Informationsmanagement als Befähiger für ein durchgängiges Geschäftsprozessmanagement

Unternehmen werden permanent dazu gezwungen nach Wegen zu suchen, die es ihnen ermöglichen, sich von anderen Marktteilnehmern zu differenzieren um sich erfolgreich gegen ständig ändernde Marktbedingungen, steigende Konkurrenz, hö- here Erwartungen der Kunden, Zwänge zur Internationalisierung und Globalisierung, kürzere Produktlebenszyklen und verkürzte „time to market“ Zeiten bei der Entwick- lung von Produkten und Dienstleistungen zu behaupten."Differenzierung entsteht, wo ein einmaliger Wert für den Abnehmer geschaffen wird."¹ Ein erfolgreiches Un- ternehmen kann mit angemessenen Produkt- und Dienstleistungsspektren schnell und flexibel auf sich ändernde Markteinflüsse reagieren. Um die sich ändernden Markteinflüsse rechtzeitig erkennen zu können, muss das Unternehmen die für das Kerngeschäft relevanten Informationen identifizieren und verarbeiten. Der Verarbei- tungsprozess bildet die Grundlage um auf Basis der gewonnen Informationen Wett- bewerbsvorteile zu generieren. Informationen können deshalb für Unternehmen als ein entscheidender Produktionsfaktor mit hoher strategischer Bedeutung angese- hen werden.

Die Information unterscheidet sich allerdings von den klassischen Produktionsfakto- ren Arbeit, Kapital und Boden in vielerlei Hinsicht. Ein materielles Wirtschaftsgut ver- liert beispielsweise bei Gebrauch an Wert, die Information hingegen, gewinnt bei Gebrauch an Wert. Ein materielles Wirtschaftsgut ist durch den individuellen Besitz gekennzeichnet, eine Information kann von vielen Interessenten gleichzeitig beses- sen werden.² Informationen sind somit anders zu verarbeiten als klassische Produk- tionsfaktoren. Welche Information das Unternehmen wie sammelt, wie es die Infor- mationen verwaltet und verwendet wird darüber entscheiden, ob das Unternehmen zu den Gewinnern oder Verlierern im betrachteten Markt zählt.³ Josuttis vergleicht das Phänomen der sich erhärtenden Marktbedingungen zum einen mit der Ablösung der sozialen Marktwirtschaft durch die globale Marktwirtschaft und darüber hinaus mit einer Renaissance des Darwinismus, nachdem weder die stärksten noch die intelligentesten Arten überleben, sondern die, die am schnellsten auf Veränderungen reagieren. Der entscheidende Punkt ist somit die Flexibilität der Informationsverar- beitung durch informationstechnische Systeme und dies macht das Management der Information zu einem entscheidenden Faktor des geschäftlichen Erfolgs.⁴ Sich än- dernde Marktbedingungen bestimmen die daraufhin anzupassenden Unternehmens- ziele und haben somit direkten Einfluss auf die notwendige Ausrichtung der Ge- schäftsprozesse. Dies fordert geradezu ein durchgängiges Geschäftsprozessmana- gement und integriertes Informationsmanagement:

"Erfolgreiches Informationsmanagement erfordert eine integrale Sicht - so kann ein Austausch der Anforderungen ('Requirement Analysis') und der Lösungsmöglichkei- ten ('Software Solution') erreicht werden, frei von Widersprüchen und Missverständ- nissen. Organisatoren, Wirtschaftsingenieure und Informatiker benötigen ein ge- meinsames Verständnis der unterschiedlichen Denk- und Modellansätze, um die Neukonzeption sowie Änderungen oder Erweiterungen von Softwaresystemen be- treiben zu können.“⁵

Diese Diplomarbeit beschäftigt sich abstrakt mit dem Ansatz eines durchgängigen Geschäftsprozessmanagements von der Anforderungsaufnahme bis hin zum aus- führbaren Software-Code. Konkret geht es um die Überführbarkeit ereignisgesteuer- ter Prozessketten (EPK), welche zur Analyse und Dokumentation von Geschäftspro- zessen eine weitverbreitete Verwendung finden, in die Business Process Execution Language (BPEL), die den ausführbaren SW-Code zur Orchestrierung von Ge- schäftsprozessen repräsentiert.

1.2 Aufbau der Diplomarbeit

Die Diplomarbeit gliedert sich in einen abstrakt-theoretischen Teil (Kapitel 1-3), ei- nem konkret-praktischen Teil (Kapitel 4-6) und einen zusammenfassenden Teil (Ka- pitel 7-8).

Kapitel 1 und 2 motivieren das Diplomarbeitsthema über die Herausforderun- gen, denen sich die im Wettbewerb befindlichen Unternehmen stellen müssen, um weiterhin wirtschaftlich erfolgreich zu sein. Es wird die Bedeutung eines integralen Informationsmanagements für ein durchgängiges Geschäftsprozessmanagement erörtert und der kontextuelle Zusammenhang zwischen serviceorientierten Architek- turen und einem durchgängigen Geschäftsprozessmanagement erklärt.

Kapitel 3 erläutert allgemeine Problemfelder für ein durchgängiges Geschäftsprozessmanagement, stellt allgemeine Anforderungen an fachliche und technische Spezifikationen und führt in die Konzepte der ereignisgesteuerten Prozessketten und der Business Process Execution Language ein.

In Kapitel 4 wird auf die wesentlichen Spezifikationsdefizite der beiden thematisierten Konzepte BPEL und EPK eingegangen. Die in diesem Kapitel genannten Punkte verhindern eine automatische Transformation einer EPK nach BPEL.

Der nächste Abschnitt -Kapitel 5- beschäftigt sich mit weiteren identifizierten kritischen Sachverhalten bei der Überführung der semi-formalen Modellierungsspra- che EPK in die formale Ausführungssprache BPEL. Die in diesem Abschnitt erwähn- ten Aspekte widersprechen jedoch nicht einer automatischen Transformation einer EPK nach BPEL.

Der konkret-praktische Teil der Diplomarbeit endet mit Kapitel 6. Dieser Abschnitt enthält Empfehlungen, die bei der Überführung ereignisgesteuerter Prozessketten in BPEL berücksichtigt werden sollten.

Der darauf folgende Abschnitt Kapitel 7 resümiert über die Abhandlung und Kapitel 8 fasst die Inhalte der Diplomarbeit zusammen.

1.3 Abgrenzung des DA Themas

In Abgrenzung zu anderen Arbeiten, die sich dem Thema der Transformierbarkeit ereignisgesteuerter Prozessketten in die Prozessorchestrierungssprache BPEL von einer technischen Perspektive nähern, wird das Thema dieser Arbeit motiviert über die Notwendigkeit eines durchgängigen Geschäftsprozessmanagements.

Die Diplomarbeit identifiziert Sachverhalte, die unbeachtet eine direkte Transformation verhindern würden und weitere allgemeine Sachverhalte, die bei einer Transformation beachtet werden sollten. Sie erhebt nicht den Anspruch Lösungen für identifizierte Transformationsprobleme bereitzustellen. Es werden jedoch Empfehlungen abgegeben, die bei der Überführung einer ereignisgesteuerten Prozesskette nach BPEL berücksichtigt werden sollten.

Das Thema Workflow Patterns (Kapitel 4.3.4) wird nur in der Ausführlichkeit behandelt, die für das Betrachten der Problemstellung als angemessen erscheint.

Die Diplomarbeit hat zum Ziel die Überführbarkeit eines fachlichen EPK-Modells in ein technisches BPEL-Modell zu untersuchen. Es ist weder Inhalt der Diplomarbeit, die Möglichkeit einer Rücktransformation vom technischen BPEL-Modell in ein fach- liches EPK-Modell zu untersuchen, noch wird er Ansatz der Round-Trip- Modellierung untersucht.

Spezifikationsdefizite des BPEL-Standard 1.0 sind nicht Gegenstand der Betrach- tung. Die Untersuchung der Überführbarkeit referenziert den BPEL-Standard 2.0.

2 Die Vision eines durchgängigen Geschäftsprozess- managements

2.1 Die adaptive prozessorientierte Infrastruktur als Basis für den unternehmerischen Erfolg

Informationssysteme sollen die Geschäftsprozesse der Unternehmen optimal und situativ unterstützen, wobei notwendige Adaptionen vor allem schnell durchgeführt werden müssen. Hinsichtlich der geforderten Flexibilität der Informationsverarbeitung ist es nicht tragbar, dass die Umsetzung von neuen Geschäftsideen in eine Software lange Zeiträume beansprucht, und dass monolithische, unflexible und nicht transpa- rente Systeme, die aus Wartungszyklen herauslaufen, ein Risiko für den Unterneh- menserfolg darstellen. Ziel muss eine möglichst direkte Reaktionsfähigkeit auf Ände- rungswünsche jeglicher Art sein. Dabei kann es sich um neue Marktanforderungen, zu optimierende interne Prozesse, geänderte Gesetze und Verordnungen oder Fort- schritte in der Informationstechnologie handeln. Hier setzt die Vision einer adaptiven prozessorientierten Infrastruktur an (s.a. Abbildung 1 Adaptive Enterprise Compu- ting).

Die Vision beschreibt eine Idealwelt in der modellierte Geschäftsprozesse vorhanden und direkt ausführbar sind. Zudem existieren Regelkreise, die ein permanentes Mo- nitoren, Steuern und Optimieren der ablauffähigen Geschäftsprozesse erlauben.⁶

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Adaptive Enterprise Computing⁷

Die Idealvorstellung von der Anforderungsaufnahme bis zur lauffähigen Software wird von Josuttis folgendermaßen konkretisiert die:„Die dahinter stehende Vision ist, Geschäftsprozess einfach durch 'Plug-and Play'-Mechanismen zusammen zu klicken. Dazu bräuchte man auch gar keine IT-Architekten mehr. Fachliche Experten entwerfen, modifizieren, überwachen und debuggen Geschäftsprozesse oder Teile daraus mit selbsterklärenden Tools (..).“⁸

Das Paradigma der serviceorientierten Architektur (SOA) bietet zusammen mit den Fortschritten aus dem Umfeld der Web Services, einer akzeptierten und weit verbreiteten Methode zur Anforderungsanalyse (EPK) und der Möglichkeiten techno- logischer Lösungen zur Orchestrierung von Geschäftsprozessen (BPEL) eine gute Unterstützung auf dem Weg zum agilen Echtzeitunternehmen.⁹

2.2 Geschäftsprozessmanagement GPM und Serviceorientierte Architekturen SOA

In diesem Abschnitt wird erklärt, was sich hinter dem Begriff Geschäftsprozessmanagement verbirgt, welche Bedeutung eine serviceorientierte Architektur für ein durchgängiges Geschäftsprozessmanagement hat und wie die beiden Begriffe mit dem Diplomarbeitsthema in Zusammenhang gebracht werden können.

„Geschäftsprozessmanagement ist ein Begriff, der sich auf alle Maßnahmen in Be- zug auf die Verwaltung und Verbesserung von Geschäftsprozessen bezieht.“¹⁰ Hier- zu gehört die Analyse des Business, die Auswahl und Implementierung geeigneter Business Strategien, das Überwachen und Optimieren von Geschäftsprozessen, die Etablierung entsprechender Werkzeuge und Unternehmenskulturen und generell der Abgleich der fachlichen Anforderungen mit der IT, dem sogenannten Business/IT- Alignement.¹¹ Natürlich steckt in dieser Definition auch implizit das Dokumentieren spezifizierter Geschäftsprozesse bzw. deren Modellierung. Das bedeutet, dass das Geschäftsprozessmanagement die Geschäftsprozessmodellierung beinhaltet. Diese verwendet wiederum Methoden und Werkzeuge um die Anforderungen an ein IT- System zu spezifizieren. Das IT-System wiederum realisiert Teile der in den Anfor- derungen beschriebenen Funktionalitäten durch ablauffähige Softwarecodes.

Was versteht man nun unter einer serviceorientierten Architektur und in wel- chem Zusammenhang stehen Geschäftsprozessmanagement und serviceorientierte Architekturen?

Im Groben wird unter einer serviceorientierten Architektur ein Management- und Architekturkonzept verstanden, welches flexibel auf die sich ändernden technischen sowie fachlichen Anforderungen an das Unternehmen reagiert. Josuttis und andere Autoren¹² bezeichnen in ihrer Definition eine SOA auch häufig als ein Paradigma:

"SOA ist ein Architektur-Paradigma (Denkmuster) für den Umgang mit Geschäfts- prozessen, die über eine große Landschaft von existierenden und neuen heteroge- nen Systemen verteilt werden, wobei die Systeme unterschiedliche Eigentümer ha- ben. Die wichtigsten technischen Konzepte von SOA sind Services, Interoperabilität und lose Kopplung.“¹³

Mit dem Konzept der losen Kopplung kann eine Reduktion der Abhängigkeiten zwi- schen den Systemen erreicht werden. Wenn dann ein System in einer SOA ausfällt sind im Idealfall keine Auswirkungen auf den Rest, der in der SOA integrierten Sys- teme zu befürchten.

Mit der Interoperabilität ist gemeint, dass SOA Einheiten wie Anwendungen, Kommunikationsstandards, Systeme, allgemeinunterschiedliche Architekturen (Java, .Net, etc.) über Middleware-Komponenten zur Zusammenarbeit befähigt werden und, dass insbesondere Services durch jedes System genutzt werden können.

Geschäftsprozesse bestehen aus zusammengesetzten Funktionen und Schritten wie Aktivitäten, Aufgaben und Ereignisse und können entsprechend dem SOA Konzept auf verteilten Systemen durchgeführt werden. Wiederverwendbare Aktivitäten können zu Services gebündelt werden, die sich den verschiedenen An- wendungen als IT-Baustein präsentieren. Sie werden in einem Repository verwaltet und können von verschiedenen Anwendungen und Geschäftsprozessen genutzt werden. Ein Service repräsentiert dabei den Abschnitt einer in sich abgeschlossenen fachlichen Funktionalität. Folgendes Bild vergleicht einen IT-Verbund heterogener nicht migrierter Altsystemen (Bezeichnet als SILO Ansatz) mit dem Ansatz der servi- ceorientierten Architektur. Bei dem SOA-Ansatz werden die wiederverwendbaren Funktionalitäten A und B als IT-Bausteine Service A und Service B den Anwendungen 1 bis 3 zur Verfügung gestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: SOA-Konzept „Service“: Vergleich des SILO und des SOA Ansatzes¹⁴

Ein Service soll so beschrieben sein, dass Fachleute der Domäne (des Fachgebiets), die den Service nutzen, diesen ohne technisches Detailwissen verstehen können.¹⁵ Damit ist gewährleistet, dass der Fachbereich die Leistung des Services durch Vergleich mit den an ihn gestellten Anforderungen validieren kann.

"In SOA sind Services typischerweise Teil eines oder mehrerer verteilter Geschäfts- prozesse. Die Hauptmotivation für Services kommt somit aus Geschäftsprozessen“¹⁶ Somit sollten Geschäftsprozessmanagement und SOA nicht getrennt voneinander betrachten werden.¹⁷

Das Geschäftsprozessmanagement stellt Methoden im Sinne der Geschäftspro- zessmodellierung bereit um Geschäftsprozesse auf einer abstrakten Ebene zu be- schreiben. Des Weiteren werden wichtige Kompetenzen beschrieben um die Ge- schäftsprozesse zu monitoren und schrittweise zu optimieren. Services stellen die Funktionalitäten zur Unterstützung der Prozesse bereit. Mit einer SOA können diese Services kombiniert werden, um das Unternehmen in seiner Agilität und Flexibilität zu unterstützen.¹⁸ Hinsichtlich Ihrer Zieldomäne sind beide Ansätze komplementär, da das Geschäftsprozessmanagement in erster Linie eine Methode in der Organisa- tionsarchitektur darstellt, Serviceorientierung hingegen meist als Architekturprinzip für die IT betrachtet wird. Beide Ansätze weisen jedoch Überschneidungen auf. Neri stellt ebenso "(…) :Wechselwirkungen zwischen den Designaspekten der Service- orientierung und des Geschäftsprozessmanagements(..)insbesondere der Prozess- orientierung "¹⁹ und "Wechselwirkung der Methoden der Serviceorientierung und des Geschäftsprozessmanagements."²⁰ fest.

Nach Rosen lauten die Schlüsselfragen um Geschäftsprozessmanagement in Zu- sammenhang mit einer serviceorientierten Architektur zu bringen wie folgt: "So the key question to achieving BPM and enterprise SOA is how do we get from here to there? How do we bridge the tasks of our business process definition and the opera- tional systems that implement our enterprise capabilities, and how do we do so while creating a reusable set of well defined business services?"²¹, d.h. wie kann der Übergang zwischen der notwendigen Modellierung der Geschäftsprozesse und den operationalen Systemen, welche die modellierten Geschäftsprozesse implementie- ren, gestaltet werden und wie können wir gleichzeitig ein wiederverwendbares Set an gut definierten Geschäftsprozessen erhalten? Von einer abstrakten Perspektive betrachtet beschäftigt sich diese Diplomarbeit mit der ersten Aussage von Neri und der kommentierten Fragestellung von Rosen. Konkret geht es um die Frage, ob sich ereignisgesteuerte Prozessketten in die Business Process Execution Language überführen lassen.

3 Von der Geschäftsprozessanalyse zur Geschäftspro- zessorchestrierung

3.1 Problemfelder für ein durchgängiges Geschäftsprozessma- nagement

"Noch immer gibt es zwei unterschiedliche Sichtweisen auf das Geschäftsprozess- management. Die eher fachlich-betriebswirtschaftliche Management-Sicht und die softwaretechnisch geprägte IT-Sicht. So sind die fachlich orientierten Prozessmodel- le und -beschreibungen, wie sie etwa im Rahmen des Qualitätsmanagements oder zur Erfüllung von Compliance-Anforderungen (Sarbanes.Oxly, Basel II, u.ä.) erstellt werden, nicht präzise genug, um als Spezifikation für die zur Prozessabwicklung benötigte Software zu dienen. Andererseits lassen sich die von einem Workflow- oder Business Process Management System (BPMS) ausführbaren Prozessmodelle der IT-Sicht in der Praxis nicht ohne weiteres dazu verwenden, manuell durchgeführ- te Prozessschritte und komplexe organisatorische Aspekte zu beschreiben, oder ein unternehmensweites Prozesskostenmanagement darauf aufzubauen."²²

Am Beispiel von ereignisgesteuerten Prozessketten wird das von Diegel folgendermaßen bestätigt: „Die mit den EPKs definierten Anforderungen sind deshalb für die Entwickler von Softwaresystemen nicht detailliert genug und müssen oft mit den Methoden des Requirements Engineering präzisiert werden.“²³

Allweyer identifiziert fünf wesentliche Problemfelder, die den Aufbau einer Systemlandschaft für ein durchgängiges Prozessmanagement erschweren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Problemfelder beim Aufbau einer Systemlandschaft für ein durchgängi- ges Prozessmanagement²⁴

Das erste Problemfeld entsteht durch die Mächtigkeit und Nicht-Eindeutigkeit der Notationen zur Prozessmodellierung. Es werden bei der Prozessmodellierung meistens Notationen eingesetzt, die sich nur auf einen bestimmten Einsatzzweck konzentrieren. Dadurch werden andere relevante Aspekte für ein durchgängiges Prozessmanagement nicht beachtet. Speziell ereignisgesteuerte Prozessketten bie- ten einen großen Freiheitsgrad bei der Modellierung. EPKs müssen für Simulations- zwecke anders strukturiert sein, als z.B. für Customizing-Aufgaben von SAP.

Das zweite von Allweyer beschriebene Problemfeld behandelt die fehlende Standardisierung und Austauschbarkeit von Prozessmodellen. Im Bereich ausführ- barer Prozessdefinitionen ist der BPEL-Standard so gut wie etabliert, im Bereich der Prozessmodellierung auf fachlicher Ebene ist man von einem eindeutigen Standard jedoch noch entfernt. Selbst die weitverbreiteten ereignisgesteuerten Prozessketten sind in ihrer Struktur und den vorhandenen Elementen nicht eindeutig formalisiert: Erweiterte ereignisgesteuerte Prozessketten (eEPKs) erweitern das Modell der EPK um weitere Objekte. Dies sind Objekte der Organisation (Rolle, die die Aktivität aus- führt), der Information (Informationsobjekte aus denen Informationen gelesen wer- den oder in die Informationen geschrieben werden) und Systeme (z.B. ERP- Systeme, Servicekomponenten, etc.), die Aktivitäten unterstützen. Die eEPKs unter- scheiden sich wiederum von anderen alternativen Vorschlägen wie z.B. den service- orientierten ereignisgesteuerten Prozessketten (sEPKs), die zum Ziel haben, EPKs durch zusätzliche spezifische Elemente weiter an das Thema SOA anzunähern.²⁵ Mit den möglichen Erweiterungen der Standard EPK werden die Prozessketten zwar weiter formalisiert, die Alternativen der Erweiterungen erschweren es jedoch, EPK- Modelle zwischen Modellierungswerkzeugen unterschiedlicher Hersteller auszutau- schen. Ein Hersteller favorisiert z.B. ein Geschäftsmodell, welches extrem kunden- spezifische EPK-Bibliotheken unterstützt, während ein anderer Hersteller eher davon absieht und sich an den ursprünglichen Basisstrukturen der EPK orientiert. Beide Tools erstellen gültige EPK-Notationen, eine direkte Austauschbarkeit und Weiter- verwendung im jeweils anderen Tool ist jedoch nicht möglich.

Die generell schwierige Umsetzung von fachlichen in technische Modelle ist das dritte Problemfeld, das Allweyer identifiziert. Geschäftsprozessmodelle orientie- ren sich an betriebswirtschaftlichen Aspekten und funktionalen Anforderungen der Fachabteilungen. Im Zuge der Überführung von EPK-Modellen in ausführbare BPEL Beschreibungen müssen technische Details spezifiziert werden, die für ein fachli- ches Modell keine Relevanz besitzen. Auf der anderen Seite enthalten die fachlichen Modelle Informationen, die in einem Implementierungskontext nicht genutzt werden. Die Praxis bestätigt die Aussage von Allweyer, dass die fachlichen Modelle im Rah- men der Software-Entwicklung oftmals nur als Hintergrundinformation genutzt wer- den und softwarebezogene Modelle von Grund auf neu erstellt werden. Dadurch entsteht ein Medienbruch, der es erschwert fachliche und technische Modelle kon- sistent zu halten.

Ein durchgängiges Geschäftsprozessmanagement hat u.a. zum Ziel, dass sich die auf Ebene der Unternehmensführung definierten strategische Ziele hier- archieübergreifend und transparent mit messbaren Kennzahlen auf operativer Ebene (Ebene der Geschäftsprozesse) verknüpfen lassen. Das vierte von Allweyer definierte Problemfeld beschreibt das Fehlen praktisch handhabbarer durch Werkzeuge unterstützte Vorgehensweisen zur Definition von Kennzahlen. Manche Modellierungstools bieten die Möglichkeit, eine Zuordnung zwischen Kennzahlen und Prozessen zu dokumentieren. Bei der späteren Implementierung jedoch, d.h. ab dem Zeitpunkt, ab dem entsprechende Daten gemessen werden müssen, wird das Fehlen von Werkzeugen und Vorgehensweisen offensichtlich.

Das fünfte von Allweyer beschriebene Problemfeld beschreibt den Umstand, dass Geschäftsprozesse in den wenigsten Fällen in einem zentralen Business Pro- cess Management System (BPMS) integriert sind. Teilweise wird Geschäftspro- zessmanagement auch nur in einem Teilbereich des Unternehmens durchgeführt. Andere exkludierte Teilbereiche eines Unternehmens mit ähnlichen Prozessen kön- nen somit nicht durch ein BPMS überwacht werden. Die Leistungsfähigkeit ähnlicher Geschäftsprozesse aus unterschiedlichen Unternehmensbereichen kann dann nicht in Beziehung gesetzt werden, Synergien können schwierig identifiziert und nicht ge- nutzt werden. Die an sich sinnvolle Vorgehensweise, existierende Systeme zu kap- seln und mit einer Webservice-Schnittstelle zu versehen, führt ebenfalls dazu, dass in einem BPMS nicht die kompletten Prozessmodelle vorhanden sind und damit kein lückenloses Prozessmonitoring stattfinden kann. Genauso wenig können gekapselte Funktionen eines monolithischen Altsystems überwacht werden.

Anhand des folgenden Kapitel 3.2 soll der Übergang zwischen fachlichem Modell und technischem Modell genauer beschrieben werden.

3.2 Vom Problem- zum Lösungsraum - Designebenen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Chaos Report 2006 der Standish Group

Ein wesentlicher Grund für das Scheitern von Software-Projekten ist nach dem Chaos Report der Standish Group die fehlende Einbindung der Nutzer des Zielsys- tems. In der bisherigen fast noch überall anzutreffenden Zusammenarbeit zwischen Fachabteilungen und IT-Abteilung wird der sogenannte „Business-IT Gap“ dadurch ersichtlich, dass interpretierbare fachliche Anforderung zu einer Software Lösung führen, die kaum die Erwartungen der Nutzer/des Kunden trifft. Oft liegt das daran, dass fachliche Anforderungen zu wenig formal dokumentiert werden, so dass die nachfolgenden Schritte der technischen Spezifizierung und Umsetzung in ein ablauf- fähiges Programm zu einer Lösung führen, die nicht mehr zu dem ursprünglichen Problem passt. „One of the major problems with most business engineering efforts, is that the software engineering and the business engineering community do not communicate properly with each other. This leads to that the output from business engineering is not being used properly as input to the software development effort, and vice-versa.”²⁶ Die folgende sicher vielen bekannte Abbildung beschreibt das Problem humorvoll und aus der Erfahrung nachvollziehbar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Vom Problem- zum Lösungsraum²⁷

Abbildung 6 zeigt an welcher Stelle ein BPEL-Prozess dabei unterstützen kann den „Business-IT Gap“ zwischen fachlich definierten Geschäftsprozess und technischen Service zu überwinden.

[...]

---

¹ Porter1989, S.201

² vgl. Hildebrand 2001, S.2

³ vgl. Gates1999, S.23

⁴ vgl. Josuttis2008, S.1

⁵ Schönsleben 2001, zitiert von Buchrückseite

⁶ vgl. Winterberg 2006, Abs. 1

⁷ Winterberg2006, Abb. 1

⁸ Josuttis2008, S.112

⁹ vgl. Winterberg2006, Fazit

¹⁰ Josuttis2008, S.103

¹¹ vgl Josuttis 2008, S.105

¹² vgl. Höß2007, S.40

¹³ Josuttis 2008, S.30

¹⁴ vgl. Winterberg [2007a], Folie Nr. 6

¹⁵ vgl. Josuttis2008, S.34

¹⁶ Josuttis2008, S.103

¹⁷ vgl. Neri2007, S. 115, Rosen2006, S.4, Josuttis2008, S. 105

¹⁸ vgl. Rosen2006, S.3

¹⁹ Neri2007, S.115

²⁰ Neri2007, S.115

²¹ Rosen 2006,S.2

²² Allweyer2006, S.68

²³ Diegel 2006, S.5

²⁴ vgl. Allweyer 2006, S.72-75

²⁵ vgl. Huth 2007, Einleitung

²⁶ Rational Unified Process1998, S.10

²⁷ "o.V.", "o.J.".