Die Auswirkungen von Web Service-Technologien auf die Gestaltung von Geschäftsprozessen am Beispiel des Buchhandels

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1 Motivation
1.2 Ziele
1.3 Der Inhalt im Überblick

2. Geschäftsprozessmanagement
2.1 Grundlagen des Geschäftsprozessmanagements
2.1.1 Von der Funktions- zur Prozessorientierung
2.1.1.1 Funktionsorientierung
2.1.1.2 Prozessorientierung
2.1.2 Der Prozessbegriff
2.1.3 Geschäftsprozessmanagement
2.2 Herausforderungen für das Geschäftsprozessmanagement
2.2.1 Integration der Anwendungssysteme
2.2.1.1 Enterprise Application Integration (EAI)
2.2.1.2 Business-to-Business-Integration (B2B-Integration)
2.2.2 Annäherung zwischen IT- und Fachabteilungen
2.3 Zusammenfassung

3. Die Service-orientierte Architektur (SOA)
3.1 Grundlagen einer SOA
3.1.1 Service-Orientierung
3.1.2 Der Begriff SOA
3.2 Das Konzept einer SOA
3.2.1 Merkmale einer SOA
3.2.1.1 Lose Kopplung
3.2.1.2 Verwendung von Standards
3.2.1.3 Wiederverwendbarkeit
3.2.1.4 Komponierbarkeit
3.2.1.5 Quality-of-Service
3.2.2 Die Rollen in einer SOA
3.3 Zusammenfassung

4. Web Service-Technologien
4.1 Grundlagen
4.1.1 Der Web Service-Begriff
4.1.2 Der Web Service-Stapel
4.2 Web Service-Technologien
4.2.1 Basistechnologien
4.2.1.1 Kommunikation mit SOAP
4.2.1.2 Service-Beschreibung mit WSDL
4.2.1.3 Verzeichnisdienst UDDI
4.2.2 WS-*-Technologien
4.3 WS-BPEL
4.3.1 Service-Komposition mit BPEL
4.3.2 BPEL-Konzepte
4.3.2.1 Orchestrierung vs. Choreographie
4.3.2.2 Synchrones vs. Asynchrones Modell
4.3.2.3 Korrelation
4.3.2.4 BPEL-Aktivitäten
4.3.2.5 Partner Links
4.3.2.6 Variablen
4.3.2.7 Gültigkeitsbereich (Scope)
4.3.2.8 Fehlerbehandlung und Kompensation
4.3.3 Ablauf eines BPEL-Prozesses
4.3.4 BPEL User Interaction
4.4 Semantic Web Services
4.4.1 Semantic Web
4.4.2 Semantic Web Services
4.5 Zusammenfassung

5. Auswirkungen von Web Service-Technologien auf die Gestaltung von Geschäftsprozessen am Beispiel des Buchhandels
5.1. Geschäftsprozesse im Buchhandel
5.1.1 Der Buchhandel
5.1.2 Das Buchprodukt
5.1.3 Die Wertschöpfungskette des Buches im wissenschaftlichen Verlag
5.2 Besondere Merkmale von Geschäftsprozessen im wissenschaftlichen Verlag
5.2.1 Rolle der Informationssysteme für Geschäftsprozesse im wissenschaftlichen Verlag
5.2.2 Veränderungen der Geschäftstätigkeit im wissenschaftlichen Verlag
5.2.2.1 Veränderungen des Produktspektrums
5.2.2.2 Veränderungen der Wertschöpfung
5.2.2.3 Veränderungen des Umfeldes
5.2.2.4 Konsequenzen
5.3 Web Service-Technologien in Verlagsprozessen
5.3.1 Geschäftsprozessmodellierung mit ARIS
5.3.1.1 Das ARIS-Konzept
5.3.1.2 Die ARIS-Software
5.3.2 Web Services in den Phasen des Geschäftsprozessmanagements
5.3.2.1 Prozess-Strategie
5.3.2.2 Prozess-Design
5.3.2.3 Prozess-Implementierung
5.3.2.4 Prozess-Controlling
5.3.3 Zusammenfassung der Auswirkungen
5.4 Zusammenfassung

6. Schlussfolgerungen und Ausblick
6.1 Schlussfolgerungen
6.2 Ausblick

Literaturverzeichnis

Anhang

Eidesstattliche Versicherung

Einverständniserklärung

Abbildungsverzeichnis

Abb. 1: Prozessdurchlauf in einer funktionsorientierten Organisation

Abb. 2: Prozessdurchlauf in einer prozessorientierten Organisation

Abb. 3. Der Prozessbegriff

Abb. 4: Säulen des Geschäftsprozessmanagements

Abb. 5: Rollen in einer Service-orientierten Architektur

Abb. 6: Web Service-Stapel

Abb. 7: Aufbau einer SOAP-Nachricht

Abb. 8: Struktur eines WSDL-Dokuments

Abb. 9: Abbildung von WSDL in UDDI

Abb. 10: Ablauf eines BPEL-Prozesses

Abb. 11: Wertschöpfungskette für ein gedrucktes Buch

Abb. 12: Wertschöpfungskette der Buchherstellung im wissenschaftlichen Verlag

Abb. 13: Traditionelle Vertriebswege des Verlags

Abb. 14: Informations-Intensitäts-Matrix

Abb. 15: Vertriebswege des Verlags

Abb. 16: Kreislauf des Geschäftsprozessmanagements

Abb. 17: Wertkette des Buches im wissenschaftlichen Verlag

Abb. 18: Wertschöpfungsstufe „Verkauf und Distribution“ des Buches im wissenschaftlichen Verlag

Abb. 19: Wertschöpfungsstufe „Verkauf und Distribution“ des Buches im wissenschaftlichen Verlag - detailliertere Darstellung

Abb. 20: Geschäftsprozess „Buch-Verkauf über verlagseigenen Online-Shop“

Abb. 21: Ausschnitt aus dem Buch-Verkaufsprozess, der mit BPEL automatisiert werden soll

Abb. 22: BPEL-Prozess für den Buch-Verkaufsprozess aus Abbildung 21

Tabellenverzeichnis

Tab. 1: Elemente des WSDL-Dokuments

Tab. 2: Aktivitäten eines BPEL-Prozesses

Tab. 3: Wichtige Konzepte von BPEL4People

Tab. 4: Merkmale, die zu hoher Informationsintensität führen

Tab. 5: Realisierung der Funktionen des Geschäftsprozesses „Buchverkauf über verlagseigenen Online-Shop“

Tab. 7: Zusammenfassende Darstellung der Auswirkung von Web Service­Technologien auf die Geschäftsprozesse und Folgen für das Unternehmen...

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1 Motivation

Geschäftsprozesse sind das Herzstück eines jeden Unternehmens. Sie erzeugen einen Mehrwert für den Kunden und tragen daher maßgeblich zum Umsatz und Gewinn und damit zum langfristigen Erfolg eines Unternehmens bei, weshalb ihre effiziente und kundenorientierte Gestaltung von entscheidender Bedeutung ist.

Das Umfeld, in dem Unternehmen heutzutage agieren müssen, ist geprägt von dynamischen Märkten und verstärktem Wettbewerb. Um sich gegenüber der Konkurrenz zu behaupten, sind Unternehmen gefordert, ihre Geschäftsprozesse schnell und flexibel an veränderte Anforderungen anzupassen. Dies ist jedoch nur möglich, wenn sich Änderungen des Prozessablaufes auch unmittelbar in den prozessunter­stützenden Informationssystemen niederschlagen.

Bisherige Software-Architekturen können diese Anforderungen nicht erfüllen. Die Geschäftsprozesslogik liegt meist fest verzahnt in den Anwendungssystemen des Unternehmens. Auf Änderungen wurde in der Vergangenheit oft mit der Programmierung von neuen Funktionen reagiert, was zu einer hohen Komplexität der Systeme führte. Die Informationstechnologie (IT) entwickelte sich oft zum Flaschenhals und schränkte die Unternehmen mehr und mehr in ihrer Agilität ein anstatt diese zu fördern. So lassen sich heutzutage Änderungen, wie zum Beispiel die Anbindung eines neuen Lieferanten, meist nur unter erheblichem Zeit- und Kostenaufwand verwirkli­chen. Ein effizientes Management der internen und unternehmensübergreifenden Geschäftsprozesse wird unter diesen Aspekten unmöglich, was dazu führt, dass Unter­nehmen zunehmend ihre Reaktionsfähigkeit auf Veränderungen der Umfeldbedingun­gen verlieren.

Das Geschäftsprozessmanagement als ganzheitliche Herangehensweise für die Gestaltung und Überwachung von Geschäftsabläufen stellt die Basis für ein agiles Unternehmen dar. Ziel ist es, den automatisierten Ablauf sowie die effiziente und flexible Umsetzung der Geschäftsprozesse zu realisieren. Dabei sollen nicht nur die Informationssysteme innerhalb des Unternehmens geschäftsprozessgetrieben integriert werden, sondern auch die Systeme der Partner.

Seit einiger Zeit macht ein neues Architektur-Paradigma von sich reden, das den technischen Rahmen für das Geschäftsprozessmanagement bietet und mit seinen Konzepten dabei helfen soll, die Ziele des Geschäftsprozessmanagements zu verwirkli­chen: die Service-orientierte Architektur (SOA). Web Services sind nach dem heutigen Kenntnisstand die am besten geeignete Technologie, eine solche Architektur umzu­setzen. Sie versprechen Plattformunabhängigkeit, Sprachneutralität und die automati­sierte Zusammenarbeit verteilter Anwendungskomponenten. Geschäftsprozesse sollen nicht mehr in monolithischen Anwendungssystemen abgebildet, sondern durch lose gekoppelte, standardisierte Services umgesetzt werden, um dem Unternehmen auf diese Weise zu größtmöglicher Flexibilität und Agilität zu verhelfen.

1.2 Ziele

Diese Arbeit beschäftigt sich damit, wie sich Web Service-Technologien auf die Gestaltung der Geschäftsprozesse von Unternehmen auswirken. Es wird gezeigt, wie Web Services die Konzepte einer Service-orientierten Architektur umsetzen und diese auf Geschäftsprozesse anwenden. Am Beispiel von Prozessen im Verlagsbuchhandel sollen die erarbeiteten Sachverhalte verdeutlicht werden.

Folgende Kernaussagen werden im Verlaufe der Arbeit näher erörtert :

- Unternehmen brauchen ein effektives ganzheitliches Geschäftsprozessmanagement, um im Wettbewerb bestehen zu können.
- Web Services, die entsprechend den Prinzipien einer Service-orientierten Architek­tur eingesetzt werden, bieten den technischen Rahmen für ein effektives Geschäfts­prozessmanagement und sind damit die Basis für ein agiles Unternehmen.
- Eine (Web) Service-orientierte Architektur realisiert die flexible, geschäftsprozessgetriebene Integration von Anwendungssystemen ent­lang der gesamten Wertschöpfungskette.
- Eine (Web) Service-orientierte Architektur schafft eine Brücke zwischen den betriebswirtschaftlichen Prozessanforderungen und der technischen Prozess-Realisierung.
- Eine Service-orientierte Architektur betrifft als Konzept den gesamten Geschäfts­prozessmanagement-Kreislauf mit den Phasen Prozess-Strategie, Prozess-Design, Prozess-Implementierung und Prozess-Controlling. Web Services haben als tech­nische Komponente zur Realisierung einer Service-orientierten Architektur Auswirkungen auf das Prozess-Design und die Prozess-Implementierung.

1.3 Der Inhalt im Überblick

Kapitel 1 gibt zunächst eine kurze Einführung in das Thema und stellt die Ziele und den inhaltlichen Aufbau der Arbeit vor.

Kapitel 2 beginnt mit den Grundlagen des Geschäftsprozessmanagements und erläutert in diesem Zusammenhang Entwicklungen, Begriffe und Herausforderungen des Geschäftsprozessmanagements.

Da Web Services den größten Nutzen für ein Unternehmen darstellen, wenn sie im Sinne einer Service-orientierten Architektur eingesetzt werden, beschreibt das Kapitel 3 zunächst wesentliche Konzepte dieses neuen Architektur-Paradigmas.

Kapitel 4 widmet sich daraufhin den Web Service-Technologien. Es werden wichtige Standards vorgestellt, die in den letzten Jahren im Zusammenhang mit Web Services entstanden sind, wobei eine Technologie aufgrund ihrer großen Bedeutung für Geschäftsprozesse besonders hervorgehoben wird: die Business Process Execution Language (BPEL), auch unter dem Akronym BPEL4WS (BPEL for Web Services) oder WS-BPEL (Web Service-BPEL) bekannt.

Kapitel 5 verfolgt das Ziel, die Auswirkungen von Web Service-Technologien auf die Gestaltung von Geschäftsprozessen explizit darzustellen und erläutert diese am Beispiel von Geschäftsprozessen des Verlagsbuchhandels. Es wird das schrittweise Vorgehen bei der Realisierung des Geschäftsprozessmanagement-Kreislaufes beschrieben und gezeigt, welche Anforderungen und welchen Nutzen die Umsetzung einer (Web) Service-orientierten Architektur im einzelnen mit sich bringt.

Kapitel 6 fasst schließlich die wesentlichen Ergebnisse dieser Arbeit im Hinblick auf die in Kapitel 1.2 formulierten Kernaussagen zusammen und gibt einen Ausblick auf zukünftige Entwicklungen.

2. Geschäftsprozessmanagement

Eine effiziente und flexible Gestaltung der Geschäftsprozesse kann heute für ein Unternehmen überlebenswichtig sein. Diese Aufgabe übernimmt das Geschäftsprozess­management (GPM) bzw. das Business Process Management (BPM). Kapitel 2.1 geht zunächst auf die Grundlagen des Geschäftsprozessmanagements ein und erklärt in diesem Zusammenhang Begriffe wie Prozessorientierung, Geschäftsprozess und Geschäftsprozessmanagement. Im Kapitel 2.2 werden die aktuellen Herausforderungen dargestellt, die sich für das Geschäftsprozessmanagement ergeben, womit zum einen die Integration der am Geschäftsprozess beteiligten Anwendungssysteme gemeint ist und zum anderen die Verständigung zwischen Fach- und IT-Abteilungen. Das Kapitel 2.3 fasst zum Abschluss die wichtigsten Aussagen zusammen.

2.1 Grundlagen des Geschäftsprozessmanagements

2.1.1 Von der Funktions- zur Prozessorientierung

Lange herrschte in Unternehmen die funktionale Organisation vor. Dies war in Zeiten mit überschaubaren und stabilen Märkten und Technologien sowie langen Produkt­lebenszyklen durchaus berechtigt, doch die Bedingungen haben sich geändert. Das Kapitel 2.1.1.1 zeigt auf, warum Unternehmen sich von der Funktionsorientierung abwenden und die Prozessorientierung verwirklichen sollten. Anschließend werden im Kapitel 2.1.1.2 wesentliche Merkmale der Prozessorientierung beschrieben.

2.1.1.1 Funktionsorientierung

Traditionelle funktionale Organisationen nehmen eine Spezialisierung nach Verrichtun­gen vor. Ihr Kennzeichen ist eine stark hierarchische vertikale Ausrichtung, bei der Weisungen streng von oben nach unten erteilt werden. Das damit verbundene Prinzip der Arbeitsteilung bzw. Spezialisierung, welches sich an den Taylorismus anlehnt und auf den effizienten Einsatz von Ressourcen abzielt, kann sich jedoch nur positiv auf die Produktivität eines Unternehmens auswirken, solange sich dessen Prozesse wenig bzw. gar nicht ändern. Die Abbildung 1 stellt den Prozessdurchlauf in einer vertikalen Organisation dar. (Vgl. [SEI02] S. 1, [KUG05] S. 234)

Solche Organisationsformen führten in den letzten Jahrzehnten zu einer eingeschränkten Sichtweise der Funktionsabteilungen bezüglich des Prozessablaufes, wodurch die Prozesseffizienz vernachlässigt wurde. Abteilungen konzentrierten sich überwiegend auf die Optimierung der durch sie verrichteten Tätigkeiten, so dass der Gesamt­zusammenhang der betrieblichen Funktionen zunehmend in den Hintergrund rückte. Dies hatte zur Folge, dass die im Unternehmen genutzten Informationssysteme der Prozesssicht nicht entsprachen. Es entstand ein erheblicher Koordinationsaufwand, der sich mit der wachsenden Autonomie der Funktionsbereiche noch vergrößerte. (Vgl. [BEC05] S. 4, [SEI02] S. 1)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Prozessdurchlauf in einer funktionsorientierten Organisation ([SEI02] S. 2)

Die heutigen radikalen Veränderungen des Unternehmensumfeldes wie andauernde Deregulierungen, die Globalisierung des Marktes, steigende Kundenansprüche, kürzere Produktlebenszyklen und die Homogenisierung der Produkte führen zu einem steigen­den Wettbewerb und machen deutlich, dass die klassische funktionale Organisation den Anforderungen an ein Unternehmen von heute nicht mehr gerecht wird. Der Wandel fordert von Unternehmen unmittelbares Reagieren. Mittlerweile kann den immer schneller eintretenden Änderungen auf strategischer Planungsebene kaum noch begegnet werden, was zur Folge hat, dass sich Entscheidungen zunehmend auf das operative Geschäft verlagern. Merkmale einer klassischen funktionalen Organisation wie die starke Integration von Fachwissen und Verantwortlichkeiten in Abteilungen und lange Informations- und Entscheidungswege, wirken in diesem Zusammenhang eher hemmend. Folgen sind lange Durchlaufzeiten, hohe Produktionskosten und minimale Flexibilität. Durch die fehlende Gesamtprozesssicht kann es darüber hinaus zu Doppel­arbeiten oder Bearbeitungsfehlern kommen. (Vgl. [SCH06a] S. 1, [SEI02] S. 2, [FRE04a])

Zudem verhindert die Funktionsorientierung eine optimale Kundenbetreuung. So verlieren Unternehmen mit einer traditionell stark ausgerichteten Funktions- und Produktorientierung oft den Blick für die Wünsche und Probleme des Kunden. Sie erkennen nicht, dass Kundenorientierung und Kundenbindung umfassende, über den Produktverkauf hinausgehende Lösungsprozesse erfordert. (Vgl. [VAN00] S. 28, [GRI01] S. 57)

Die Organisation nach Geschäftsbereichen, auch als divisionale Organisation bzw. Spartenorganisation bekannt, ist letztlich auch inhärent funktionsorientiert, da die Geschäftsbereiche selbst wieder funktional gegliedert sind. Erst die Prozessorientierung stellt einen wirklichen Wandel und damit eine Chance für Unternehmen dar, agiler und kundenorientierter zu handeln, um so im Wettbewerb erfolgreich zu sein. (Vgl. [SCH06a] S. 71)

2.1.1.2 Prozessorientierung

Im Gegensatz zur vertikalen hierarchischen Sichtweise, die stark an der Aufbauorganisation des Unternehmens ausgerichtet ist, rückt die Prozessorientierung die Prozesse in den Mittelpunkt des Interesses. Nachdem sich Unternehmen Anfang der 90er Jahre im Rahmen der Welle des Business Process Reengineering (BPR) auf die unternehmensinterne Prozessgestaltung und -optimierung konzentriert hatten, begannen sie mit dem Aufkommen der Internet- und E-Business-Welle um die Jahrtausendwende, Absatz- und Zuliefererprozesse und somit die gesamte Wertschöpfungskette in die Betrachtung mit einzubeziehen. Obwohl der Gedanke der Prozessorientierung nicht neu ist und Fritz Nordsieck sogar schon im Jahre 1931 die Bedeutung der Gestaltung der Abläufe erläuterte, konnte das Prozessthema erst durch BPR richtig an Popularität gewinnen. Abbildung 2 zeigt den Prozessverlauf in einer prozessorientierten Organisation. (Vgl. [JOS06] S. 9, [KRC05] S. 336)

Ziel ist es, den horizontalen ganzheitlichen Blick auf das Unternehmen zu wahren. Dazu bedarf es der Identifizierung und Modellierung der Unternehmensprozesse, welche dann die Basis für organisatorische Gestaltungsmaßnahmen darstellen. Der Fokus der Betrachtung liegt zwar auf der Ablauforganisation, wobei die organisatorischen Aufbau­strukturen jedoch auch weiterhin von essentieller Bedeutung sind. Die Aufbauorga­nisation soll nun aber an den Prozessabläufen ausgerichtet sein und diese bestmöglich unterstützen. [SEI02] beschreibt die Prozessorganisation als eine Organisationsform, „bei der die Strukturierung von organisatorischen Einheiten, insbesondere Prozessteams bzw. Funktionsbereichen, den Kern- und Unterstützungsprozessen folgt.“^[1] (Vgl. [KUG05] S. 237, [SEI02] S. 3 ff.)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Prozessdurchlauf in einer prozessorientierten Organisation (in Anlehnung an [SCH06a] S. 59 ff.)

Die prozessorientierte Gestaltung wirkt dem Prinzip des Taylorismus entgegen und versucht, die strikte funktionale Zerlegung der betrieblichen Aufgaben wieder aufzuheben. Für einen Prozess soll die Verantwortlichkeit in Form eines Prozessverant­wortlichen klar definiert werden. Im Gegensatz zur funktionalen Organisation, in der Abteilungsgrenzen bedingen, dass für unterschiedliche Prozessschritte jeweils andere Personen verantwortlich sind, entsteht so ein geringerer Koordinationsaufwand und höhere Transparenz. Abstimmungsprobleme und unnötige Fragen nach Zuständigkeiten können auf diese Weise vermieden werden. (Vgl. [KRC05] S. 336 ff., [SCH06a] S. 70)

Für eine erfolgreiche Umsetzung der Prozessorientierung ist es entscheidend, nicht nur den organisatorischen Rahmen zu schaffen, sondern auch die technische und die soziale Komponente in die Betrachtung mit einzubeziehen. Prozesse müssen optimal durch die Informationssysteme (technische Komponente) im Unternehmen unterstützt werden. [KRC05] spricht in diesem Zusammenhang von einer „Parallelisierung der IT-Prozesse mit den physischen Arbeitsabläufen“ (S. 337), was bedeutet, dass die Informationen am Ort ihrer Entstehung verarbeitet werden und für die Aktivitäten, welche die Informationen benötigen, unmittelbar zur Verfügung stehen sollen. Es werden Anwendungssysteme gebraucht, welche die notwendigen Eigenschaften mitbringen, um permanente Anpassungen zu unterstützen und nicht auszubremsen. (Vgl. [KAM05])

Das Personal als soziale Komponente spielt ebenfalls eine wesentliche Rolle. Es ist von enormer Wichtigkeit, dass die Mitarbeiter ein Verständnis für die Prozesssicht entwickeln und sich dieses auch in ihrem Denken und Handeln widerspiegelt. Zusammenhänge betrieblicher Entscheidungen zu verstehen ist dabei wichtiger als das detaillierte Wissen über die einzelnen Prozessschritte. Die Suche nach Lösungen für betriebliche Problemstellungen sollte unabhängig von den gegebenen betrieblichen Strukturen erfolgen, da dies zu einer eingeschränkten Betrachtungsweise führen kann. Idealerweise wird die Prozesswahrnehmung von der Unternehmensleitung vorgelebt und überträgt sich auf diese Weise auf die Mitarbeiter. (Vgl. [KRC05] S. 338 ff.)

Zusammenfassend lässt sich sagen, dass die prozessorientierte Organisation die effiziente Ausführung der Prozesse in den Mittelpunkt stellt. Im Gegensatz zur funktionalen Organisation, welche ihren Fokus fast ausschließlich auf die Ressourceneffizienz legt, werden bei der Prozessorientierung neben der Prozess­effizienz auch andere Effizienzkriterien stark berücksichtigt. Ziel ist es, Prozesse in kurzer Zeit, hoher Qualität und mit geringen Kosten auszuführen. Durch die Übertragung von Entscheidungen auf die operativen Stellen können Prozesse schlanker und damit schneller gemacht werden, da lange Informations- und Entscheidungswege zu den übergeordneten Stellen wegfallen oder auf ein Minimum reduziert werden (Delegationseffizienz). Damit wird auch die schnellere Anpassung an neue Gegebenheiten ermöglicht (Anpassungseffizienz). Größere Verantwortungsbereiche für Mitarbeiter sowie die abwechslungsreicheren Aufgaben in einer Prozessorganisation wirken sich positiv auf die Mitarbeitermotivation aus (Motivationseffizienz). Auch die Ressourceneffizienz gerät in einer Prozessorganisation nicht in Vergessenheit, da das Ziel der Kostenminimierung letztendlich nur erreicht werden kann, wenn die Ressourcen wirtschaftlich eingesetzt werden. (Vgl. [KUG05] S. 237)

2.1.2 Der Prozessbegriff

Ein Prozess ist eine wiederholbare, inhaltlich abgeschlossene, zeitliche und sach- logische Folge von Aktivitäten mit einem klar definierten Input und Output. Beispiele sind „Telefonat führen“, „Termin vereinbaren“ oder „Antrag ausfüllen“. Streng betrachtet sind nicht alle betrieblichen Prozesse auch Geschäftsprozesse. In der wissenschaftlichen Literatur findet man oft eine Differenzierung zwischen Geschäfts- bzw. Kemprozessen und Unterstützungs- bzw. Supportprozessen. (Vgl. [SEI02] S. 3, [BEC05] S. 6)

Schon Michael Porter hat in seinem Modell der Wertkette zwischen primären und unterstützenden Unternehmensaktivitäten unterschieden. Dabei beschreibt er primäre Aktivitäten als wertschöpfende Tätigkeiten, da sie einen unmittelbaren Bezug zur erstellten Leistung (Produkt, Dienstleistung) besitzen und daher zum wirtschaftlichen Ergebnis des Unternehmens beitragen. Dazu gehören Tätigkeiten in den Bereichen Eingangslogistik, Operationen, Marketing und Vertrieb, Ausgangslogistik und Kundendienst. Unterstützende Aktivitäten hingegen weisen keinen direkten Bezug zu den vom Unternehmen hergestellten Produkte und Dienstleistungen auf, sind jedoch notwendig, um die primären Aktivitäten durchzuführen. Solche Tätigkeiten findet man unter anderem in den Bereichen Rechnungswesen, Personalwirtschaft, Recht, Informationsverarbeitung und Beschaffung von Material für den unternehmensinternen Verbrauch. (Vgl. [BEC05] S. 7, [POR99] S. 85)

Diese Sichtweisen lassen sich auf den Prozessbegriff übertragen und werden in Abbildung 3 veranschaulicht. Ein Geschäftsprozess besteht laut [ELL05] demnach „aus der funktionsüberschreitenden Verkettung wertschöpfender (primärer) Aktivitäten und erzeugt von Kunden und anderen Anspruchsgruppen erwartete Leistungen, wobei er die Umsetzung der Strategien und Ziele des eigenen Unternehmens unterstützt.“ Ein Unterstützungsprozess ist im Vergleich dazu ein Prozess, der die Durchführung von Geschäftsprozessen unterstützt und dabei keine oder nur eine indirekte Wertschöpfung für das Unternehmen erzielt. (Vgl. [SEI02] S. 3, [BEC05] S. 7 ff.)

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Der Prozessbegriff (in Anlehnung an [KRC05] S. 340, [POR99] S. 85)

Manche Autoren wie zum Beispiel [KRC05] unterscheiden daneben auch noch Unternehmenssteuerungsprozesse, wozu sie Prozesse im Bereich Strategie, Controlling, Organisation und Informationsmanagement zählen. Da diese Dreiteilung des Prozessbegriffes jedoch Schwierigkeiten bei der Abgrenzung von Steuerungs- und Unterstützungsprozessen mit sich bringt, wird sie hier nicht weiter berücksichtigt. (Vgl. [KRC05] S. 340, [SCH06a] S. 74)

2.1.3 Geschäftsprozessmanagement

„Geschäftsprozessmanagement (GPM) steht für die kontinuierliche Anpassung der Geschäftsprozesse und damit der Organisation und der IT-Landschaft an die Anforderungen des Marktes“ ([SCH07c] S. 2).

Es geht darum, die Prozesse ganzheitlich zu betrachten, also alle Phasen von ihrer strategischen Planung über die Ausführung bis hin zum Monitoring zu berücksichtigen. Kernaufgabe des Geschäftsprozessmanagements ist es, die Umsetzung der Prozess­orientierung Wirklichkeit werden zu lassen, also „die Zerstückelung der Geschäfts­prozesse aufzuheben und die auf viele Abteilungen verteilten Einzelteile wieder zu einem Ganzen zusammenzufügen“ ([WEI05]). (Vgl. [KAM05])

Geschäftsprozesse beginnen und enden beim Kunden. Die Kundenwünsche müssen identifiziert und die Geschäftsprozesse auf die Erfüllung dieser Wünsche ausgerichtet werden. Schließlich wird den Kunden das Prozessergebnis in Form von Produkten oder Dienstleistungen zum Kauf angeboten. Das GPM misst der Kundenzufriedenheit daher eine entscheidende Bedeutung bei. Neben den Kunden stellen natürlich auch andere Interessengruppen (sogenannte Stakeholder) wie Lieferanten, Kapitalgeber, Partner­Unternehmen, Mitarbeiter und die Gesellschaft Anforderungen an das Unternehmen und seine Geschäftsprozesse. (Vgl. [SCH06a] S. 61, [FRE04a])

Mit dem GPM wollen Unternehmen Prozesseffektivität und Prozesseffizienz erreichen. Laut [SCH06a] sind Geschäftsprozesse effektiv, „wenn ihre Ziele und Ergebnisse die Bedürfnisse und Erwartungen der externen Kunden erfüllen und gleichzeitig dazu beitragen, die Unternehmensziele zu erreichen (,die richtigen Dinge tun’)“. Geschäftsprozesseffizienz wird darüber hinaus erzielt, „wenn die Kundenleistungen mit möglichst geringem Ressourceneinsatz, das heißt wirtschaftlich erzeugt werden (,die Dinge richtig tun’)“ (S. 62 ff.). Durch das zeitnahe Bereitstellen von Informationen für alle Entscheidungen durch die Unternehmens-Applikationen - man spricht hier auch vom Echtzeit-Unternehmen bzw. Real Time Enterprise^[2] - sollen Unternehmen in die Lage versetzt werden, diese Ziele zu erreichen. Ein aktives GPM soll das Unternehmen der Vision des Echtzeit-Unternehmens Stück für Stück näher bringen. (Vgl. [QUA05], [SPA04] S. 13 ff., [ALT04] S. 5)

Das abgestimmte Zusammenspiel der Effizienzziele Prozessqualität, Prozesszeit und Prozesskosten, welche von [GAI94] als die drei Säulen des Geschäftsprozess­managements genannt werden, soll letztendlich zu einer hohen Kundenzufriedenheit führen. In Abbildung 4 ist dieser Zusammenhang grafisch dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Säulen des Geschäftsprozessmanagements (in Anlehnung an [GAI94] S. 16)

Geschäftsprozessmanagement sollte jedoch keine einmalige Aktivität bleiben. Es ist vielmehr ein in sich geschlossener, ständig ablaufender Kreislauf, wodurch kontinuierliche Anpassungen und Verbesserungen der Abläufe erreicht werden können - man spricht in diesem Sinne auch von Continuous Process Improvement (CPI). Die an der Unternehmens-Strategie orientierte Prozess-Strategie bildet dabei den Ausgangs­punkt für die weiteren Phasen des GPM. Es folgt zunächst das Design, also die fachliche Modellierung der Geschäftsprozesse, und daran anschließend deren Implementierung in softwaretechnische Lösungen. Im Rahmen des Controlling werden die Prozesse und deren Leistungskennzahlen dann gemessen und bewertet, um eventuelle Anpassungen im Hinblick auf die Anforderungen des Marktes vorzunehmen.

Erst die konsequente Umsetzung des gesamten Kreislaufes stellt echtes Geschäfts­prozessmanagement dar. Viele Unternehmen haben in der Vergangenheit bereits damit begonnen, ihre Prozesse zu analysieren und mit Hilfe eines entsprechenden Designtools in fachliche Prozessmodelle abzubilden. Die ganzheitliche Unterstützung der Geschäftsprozesse kann jedoch erst erreicht werden, wenn darüber hinaus eine technische Lösung generiert wird und der Prozessablauf entsprechend überwacht und bewertet wird. (Vgl. [SCH07c] S. 2 ff., [STR06], [ADA07])

2.2 Herausforderungen für das Geschäftsprozessmanagement

Noch sind Unternehmen weit entfernt davon, das Konzept des Echtzeit-Unternehmens zu verwirklichen, was laut [SPA04] vor allem auf „die Heterogenität der Geschäfts­prozesse, der Informationssysteme, der Daten-Schnittstellen, der Stammdaten und der Semantik im zwischenbetrieblichen Bereich“ zurückzuführen ist. Für das Geschäfts­prozessmanagement ergeben sich in diesem Zusammenhang Herausforderungen, welche in zwei wesentlichen Punkten zusammengefasst werden können und in den Kapiteln 2.2.1 und 2.2.2 erläutert werden: die geschäftsprozessgetriebene Integration der Anwendungssysteme und die Verständigung zwischen Fachanwendern und IT- Experten.

2.2.1 Integration der Anwendungssysteme

Das Ziel eines Unternehmens ist, dass seine Prozesse optimal von den verwendeten Anwendungssystemen unterstützt werden. Die Effizienz von Geschäftsprozessen soll durch deren Automatisierung erhöht werden. Da das Unternehmensumfeld ständig in Bewegung ist, wird es zum entscheidenden Wettbewerbsfaktor für das Unternehmen, unmittelbar auf unvorhersehbare Änderungen zu reagieren. Die erforderlichen Anpassungen von Prozessen müssen sich auch schnell und effizient in den unterstützenden Informationssystemen niederschlagen. Von enormer Wichtigkeit ist dabei die geschäftsprozessgetriebene Integration von unternehmensinternen sowie unternehmensexternen IT-Systemen. (Vgl. [JUR06a] S. 6, [SCH04] S. 7)

Welche Schwierigkeiten sich im Rahmen solcher Integrationsbemühungen in der Praxis ergeben, soll im folgenden näher erläutert werden. Das Kapitel 2.2.1.1 geht dabei zunächst auf die unternehmensinterne Anwendungsintegration ein, die auch unter dem

Begriff Enterprise Application Integration (EAI) bekannt ist. Im Kapitel 2.2.1.2 wird der EAI-Begriff dann auf den Business-to-Business (B2B)-Bereich ausgedehnt, was auch die Integration von IT-Systemen der Unternehmenspartner mit einschließt.

2.2.1.1 Enterprise Application Integration (EAI)

Die Funktionsorientierung führte dazu, dass viele Applikationen, die heute in den Unternehmen genutzt werden, nicht der Prozesssicht entsprechen, da sie ursprünglich dafür entwickelt wurden, nur ganz bestimmte Funktionen zu unterstützen. So entstanden neben Enterprise Resource Management (ERP)-Systemen unter anderem auch Customer Relationship Management (CRM)-Systeme oder Supply Chain Management (SCM)- Systeme. Um Geschäftsprozesse optimal zu unterstützen, muss ein Informationssystem in der Lage sein, Funktionalitäten anderer Applikationen in einer koordinierten und integrierten Art und Weise zu nutzen. Nur so kann es einen Mehrwert für das Unternehmen erzeugen, sei es durch Unterstützung der betrieblichen Entscheidungs­findung, unmittelbares Bereitstellen von benötigten Informationen oder Wahrung der Datenintegrität. (Vgl. [JUR06a] S. 6 ff.)

Man denke beispielsweise an einen Bestellprozess. Der Kunde fragt zunächst nach, welchen Preis das gewünschte Produkt hat und ob es lieferbar ist. Anschließend bestellt er eventuell das Produkt. Die Bestellausführung umfasst Beschaffung, Lieferung und Bezahlung (vom Kunden und an den Lieferanten). Jeder dieser Schritte kann durch ein anderes Informationssystem implementiert werden, wobei die Informationssysteme durchaus unterschiedlicher Natur sein können. Es handelt sich dabei in der Regel um Standardsoftware, Eigenentwicklungen oder auch um Systeme, die durch frühere Integrationsbemühungen entstanden sind. Infolgedessen unterscheiden sich die Informationssysteme eventuell hinsichtlich des Betriebssystems, auf dem sie laufen und bezüglich der Schnittstellen, Funktionalitäten, Datenformate, Sicherheitsanforderungen und Protokolle, die sie unterstützen. Eine Automatisierung der Geschäftsprozesse ist nur möglich, wenn all diese Systeme integriert werden. (Vgl. [ALO04] S. 69 ff.)

Integrationsbemühungen gibt es schon seit Jahrzehnten, anfangs in Form der Application-to-Application (A2A)-Integration, also der direkten Verknüpfung zweier Anwendungen. Solche Punkt-zu-Punkt-Integration ist jedoch mit viel Aufwand verbunden und äußerst kostspielig, wenn man bedenkt, dass die Integrationskosten proportional zur Anzahl der zu integrierenden Systeme steigen. Dazu kommt eine eingeschränkte Flexibilität, da die Modifikation eines Systems umfangreiche Anpassungen bei den über die Punkt-zu-Punkt-Verbindungen angeschlossenen Systemen nach sich zieht. (Vgl. [BER03] S. 16, [THI06])

EAI-Lösungen versprachen hier Abhilfe. Durch die Einführung von Middleware als zentrale Komponente von EAI-Plattformen wurde eine drastische Reduzierung der Schnittstellen erreicht, da nicht mehr jede Anwendung mit jeder anderen Anwendung direkt integriert werden musste. Die Applikationen des Unternehmens sind entweder direkt oder über Adapter mit der Middleware verbunden. Die Middleware bietet Funktionalitäten, die durch die Verteiltheit der Anwendungen erforderlich werden, was die Arbeit der Programmierer enorm erleichtert. So kümmert sich Middleware beispiels­weise um die Anbindung der auszutauschenden Nachrichten an ein konkretes Kommunikationsprotokoll, um das Routing der Nachrichten, um die Transformation der ausgetauschten Daten zwischen den proprietären Formaten der einzelnen Anwendungen sowie um Transaktionsprinzipien und Fehlerbehebung. Remote Procedure Calls (RPC)^[3] sind ein gutes Beispiel dafür. Neben RPC-basierten Systemen sind auch TP-Monitore, Object-Broker (zum Beispiel CORBA und DCOM), Message-Oriented Middleware (MOM), Message-Broker, Application-Server, Web-Portal-Software und Workflow- Engines Beispiele für EAI-Produkte. (Vgl. [ALO04] S. 29 ff., [BER03] S. 11 ff., [SCH04] S. 11 ff.)

Mit EAI-Werkzeugen wurde durch wenige standardisierte Schnittstellen zwar die Gesamtanzahl der Schnittstellen bei der Integration reduziert, diese waren jedoch herstellerspezifisch. Es fehlte noch immer ein allgemeingültiger, breit akzeptierter Standard. „EAI-Lösungen befreiten die Unternehmen nicht wirklich von proprietären Integrations-Architekturen“ ([THI06]).

Ein weiteres Problem äußerte sich darin, dass innerhalb von Unternehmen die Anzahl der LANs (Local Area Network) wuchs und zudem die jahrzehntelange Funktions­orientierung „begünstigte“, dass einzelne Unternehmensbereiche ihre „eigenen“ an sie angepassten Middleware-Lösungen einsetzten. Es wurde dringend nötig, dass die verschiedenen Middleware-Plattformen miteinander kommunizieren können. Besonders deutlich wird dies, wenn neben der unternehmensinternen auch die zwischenbetriebliche Integration betrachtet wird. (Vgl. [ALO04] S. 113)

2.2.1.2 Business-to-Business-Integration (B2B-Integration)

Durch elektronischen B2B-Austausch soll die Zusammenarbeit zwischen Unternehmen automatisiert werden. Firma A könnte direkt eine Bestellung bei Firma B aufgeben, bei B würde die Bestellung sofort bearbeitet und eine Bestätigung zu A geschickt werden, wobei das ganze ohne Papier und damit schneller und kostengünstiger abzuwickeln wäre. Außerdem würden sich weniger Fehler einschleichen und die Daten könnten anderweitig verwendet werden. Dafür ist es notwendig, die Informationssysteme zweier oder mehrerer Unternehmen zu integrieren. Die dadurch unabdingbare Einbindung von Systemen der Zulieferer und Absatzkanäle stellte die Unternehmen vor neue Herausforderungen. Das Fehlen von Standards erwies sich bereits bei der innerbetrieb­lichen Anwendungsintegration als Problem, die Integration über Unternehmensgrenzen hinweg brachte darüber hinaus noch zusätzliche erschwerende Bedingungen mit sich. (Vgl. [ALO04] S. 113, [JUR06a] S. 12, [BER03] S. 17)

Bei zwischenbetrieblichen Interaktionen gibt es zunächst einmal keine klar ersichtliche Stelle, an der die Middleware platziert werden könnte. Die beteiligten Partner müssten sich zudem auf eine bestimmte Middleware-Technologie einigen, diese gemeinsam managen und darauf einen „globalen Workflow“ implementieren. Dies widerspricht dem Wunsch von Unternehmen, die eigenen Geschäftsoperationen zu kontrollieren und so die Autonomie zu bewahren. Unternehmensinterne Anwendungssysteme sollen zwar mit denen der Partner-Unternehmen kooperieren, aber allein schon aus wettbewerbs­technischen Gründen nicht nach außen hin offen gelegt werden. So würde also die Vertraulichkeit verloren gehen, wenn die Middleware bei einer der Firmen oder einer dritten Firma vorgehalten wird. Die alternative Möglichkeit, das Integrationsproblem über Punkt-zu-Punkt-Verbindungen mit jedem Partner anzugehen, würde hingegen dazu führen, dass ein Unternehmen aufgrund fehlender Standards viele heterogene Middleware-Systeme unterstützen muss. So wäre zwar die Vertraulichkeit gewahrt, der Aufwand in den Unternehmen jedoch immens hoch. (Vgl. [ZWI02] S. 173,190 ff., [ALO04] S. 19,127)

Konventionelle Middleware scheint also ungeeignet zu sein, eine B2B-Integration perfekt zu machen. Neben dem Vertrauensproblem und dem Wunsch der Unternehmen nach Unabhängigkeit spielen auch noch weitere Faktoren eine Rolle. So dauern unternehmensübergreifende Interaktionen in der Regel wesentlich länger als innerbetriebliche Prozesse, da es aufgrund der Integration mehrerer Partner zu Verzögerungen kommen kann, zum Beispiel wenn der Zulieferer auf seine bestellten Waren wartet. Deshalb ist hier ein asynchroner Informationsaustausch typisch und somit können Protokolle wie das „Two-Phase-Commit“ (2PC) nicht angewendet werden, da sie Ressourcen für sehr lange Zeit blockieren würden.^[4] Es werden Mechanismen benötigt, die trotzdem Transaktionskonzepte und entsprechende Kompensationsmöglichkeiten anbieten, indem sie „durchgeführte Aktionen persistent protokollieren, auftretende Fehler möglichst schnell melden und im Fehlerfall zu Unrecht durchgeführte Aktionen rückgängig machen“ ([BER03] S. 25).

Bei der B2B-Integration kommt außerdem erschwerend hinzu, dass entfernte Clients auf das System via Internet zugreifen und demzufolge Firewalls von Unternehmen passiert werden müssen. Für ältere Middleware-Technologien mit ihren spezifischen Transportprotokollen stellt dies ein Problem dar. Man könnte zwar beispielsweise CORBA-Requests, die das CORBA-spezifische IIOP-Transportprotokoll^[5] nutzen, in HTTP-Aufrufe einbetten (man nennt dies auch Tunneling), dies würde aber proprietäre Encoding- bzw. Decoding-Layer auf Client- und Serverseite notwendig machen. (Vgl. [ALO04] S. 113, 129)

Wie man sieht, ergeben sich viele Fragen bei dem Versuch, B2B-Integration umzusetzen. In den meisten Unternehmen werden daher Geschäftsprozesse, sobald sie Unternehmensgrenzen überschreiten, noch manuell bearbeitet, auch wenn sie innerbetrieblich schon automatisiert ablaufen. Mitarbeiter suchen beispielsweise Informationen in Systemen heraus und füllen für eine Bestellung Web-Formulare aus. Die Vorteile einer Automatisierung sind hier die gleichen wie vorher bei der unternehmensinternen Integration: effizientere Prozesse und damit geringere Kosten sowie Möglichkeiten der Überwachung und der Verfolgung der Prozessausführung. Der Lösungsansatz muss jedoch ein anderer sein. (Vgl. [ALO04] S. 126 ff.)

Trotz der Schwierigkeiten wurde B2B-Integration in den vergangenen Jahren schon mehr oder weniger erfolgreich umgesetzt. Es entstanden zum Beispiel Broker­Unternehmen wie Ariba und Commerce One, die ähnliche Aufgaben übernommen haben wie Middleware für die Integration innerhalb von Unternehmen. Sie ermöglichten zum Beispiel das Nachrichten-Routing und das Management von Transaktionen zwischen den beteiligten Partnern. Broker wurden jedoch wenig akzeptiert. Zum einen spielte das Vertrauensproblem eine Rolle und zum anderen wurden die Formate und Protokolle der Broker von großen Software-Herstellern unzureichend unterstützt. (Vgl. [ALO04] S. 115 ff.,130, [BER03] S. 18)

Auch mit dem EDI-Standard ist B2B-Integration gelungen. EDI (Electronic Data Interchange) hatte allerdings auch seine Probleme, eine breite Akzeptanz zu finden. Der Aufbau von EDI-Systemen ist mit einem hohen Zeit- und Kostenaufwand^[6] verbunden, welcher sich erst bei einer gewissen Mindestanzahl von Übertragungen rechnet. So konnten sich meist nur die großen Unternehmen EDI-Systeme leisten. Außerdem mangelt es dem Standard aufgrund seiner umfangreichen und oft unnötig komplizierten Formulare an Flexibilität. EDI ist vor allem für gleichartige Prozesse geeignet. Jede zusätzliche, noch nicht durch die Templates abgedeckte Information, macht Ad hoc- Entwicklungen auf den Systemen notwendig, die integriert werden. So stoßen EDI- Systeme auch an ihre Grenzen, wenn es um „die Möglichkeit einer flexiblen Integration unterschiedlicher Unternehmen geht, zwischen denen nicht unbedingt langfristige Geschäftsbeziehungen existieren. EDI erfordert bilaterale Vereinbarungen und erschwert dadurch flexible Formen der Anwendung“ ([PIC04] S. 43). EDI wird heute trotzdem noch genutzt und zwar häufig von den Unternehmen, die früh in das E­Business eingestiegen sind und schon vor langer Zeit eine EDI-Struktur aufgebaut haben. Heute existieren auch schon XML-basierte Varianten des EDI-Standards. (Vgl. [ALO04] S. 115 ff.,130, [BER03] S. 18)

Das Web hat bezüglich der Anwendungs-Integration einen wichtigen Beitrag geleistet. Es brachte Standard-Interaktions-Protokolle wie HTTP und Datenformate wie XML

hervor, die sehr schnell von vielen Unternehmen angenommen wurden und dadurch die Basis für eine einheitliche Middleware-Infrastruktur bilden. Web Services wollen durch das Anknüpfen an die bereits bewährten Technologien des Internets sowie durch die Schaffung allgemeingültiger Standards und die Umsetzung der Konzepte einer Service­orientierten Architektur eine flexiblere und effizientere Lösung für das Integrationsproblem anbieten. (Vgl. [JUR06a] S. 12, [BER03] S. 11, [ALO04] S. 131)

2.2.2 Annäherung zwischen IT- und Fachabteilungen

Nicht nur die Integration der Anwendungssysteme stellt eine große Herausforderung für das Geschäftsprozessmanagement dar, sondern auch die Überwindung des Verstän­digungsproblems zwischen Fach- und IT-Experten. Die fehlenden Informationsflüsse schränken die Unternehmen ebenfalls in ihrer Flexibilität und Reaktionsfähigkeit bezüglich der Anpassung von Geschäftsprozessen ein.

Die effektive und effiziente Umsetzung der fachlichen Prozessanforderungen in Anwendungssoftware erweist sich für Unternehmen schon lange als schwierige Aufgabe. Viel zu oft entwickeln Programmierer Software, welche die Geschäfts­prozesse nicht in der gewünschten Art und Weise unterstützt, wodurch aufwendige und damit kostspielige Anpassungen notwendig werden. Es mangelt vor allem an einer gemeinsamen Prozesssicht von Fachanwendern und IT-Profis und damit am gegenseitigen Verstehen. [SCH06c] spricht in diesem Zusammenhang von einer „,semantischen Lücke’, die zwischen der abstrakten Beschreibung eines Geschäfts­prozesses und dem Programmcode klafft“ (S. 10 ff.). (Vgl. [VOL05] S. 38 ff.)

Die Geschäftslogik liegt meist fest verdrahtet im Programmiercode, der für Nicht-IT- Experten unverständlich ist, weshalb sich die Nutzer der Anwendungsprogramme völlig auf die Software-Entwickler verlassen müssen, um auch nur geringste Änderungen vorzunehmen. Anstatt schnell reagieren zu können, müssen sie Änderungen der Geschäftsprozesse bei den IT-Experten anfordern, was wahrscheinlich darin mündet, dass diese weiteren Code generieren bzw. neue komplexe Programme schreiben. Die IT entwickelt sich auf diese Weise mehr und mehr zum Flaschenhals und damit zur Bremse der Unternehmensagilität, dabei ist gerade heutzutage der Druck, schneller und flexibler zu werden, unheimlich groß. (Vgl. [ARM06] S. 30, [BER03] S 23 ff.)

Laut [JOS06] bedarf es dringend einer Methode, „die genügend Semantik besitzt, um Geschäftsprozesse für Fachanwender verständlich darzustellen, und gleichzeitig den formalen Ansprüchen genügt, diese Prozesse in der Software abzubilden“ (S. 7). Es wird eine Umgebung benötigt, „in der die Beteiligten fortlaufend ihre Arbeitsumgebung (kritisch) überwachen und (konstruktiv) verbessern, ohne dabei selbst für sogar kleinste Änderungen die Dienste der IT-Abteilung nachzufragen“ ([ARM06] S. 30).

Nachdem Konzepte wie das Datenmodell es nicht geschafft haben, eine „semantische Brücke“ zwischen Prozess-Modellierung und Prozess-Implementierung zu schlagen^[7], erreichten prozessorientierte Modelle wie ARIS zumindest, eine für IT-Experten und Fachanwender gemeinsame Diskussionsbasis zu schaffen. Der Geschäftsprozess, also die betriebswirtschaftliche Sicht, bildete nun den Ausgangspunkt für alle weiteren Betrachtungen. Durch die Darstellung der einzelnen Prozessaktivitäten und der zwischen ihnen bestehenden Zusammenhänge konnte auch die Dynamik eines Geschäftsprozesses im Modell abgebildet werden. Was man jetzt noch brauchte, war die automatische Überführung der fachlichen Modellbeschreibung in technische Abläufe, ohne die Mitarbeit der Softwarehersteller. Oft werden die Prozesse heute zunächst mit Tools wie ARIS fachlich modelliert. Später werden dann - wiederum händisch - die Software-Modelle erstellt, wobei aufgrund der fehlenden semantischen Deckung auch einige Kompromisse eingegangen werden müssen. Diese Vorgehensweise ist mit einem Mehraufwand verbunden, der sich einsparen ließe, wenn man das fachliche Prozessmodell direkt für die Erstellung des Softwaremodells verwenden könnte. (Vgl. [SCH06c] S. 10 ff., [JOS06])

Das Konzept der Service-orientierten Architektur verspricht, die Lücke zwischen Prozess-Modellierung und Prozess-Implementierung zu schließen. Web Services als Realisierung einer SOA bieten Technologien, wie zum Beispiel die Prozess­beschreibungssprache BPEL, mit denen ein automatisches Mapping der fachlichen Geschäftsprozesse auf technische Service-Modelle ohne Informationsverlust möglich wird. Darüber hinaus sollen die Prozessverantwortlichen in die Lage versetzt werden, kleine Änderungen im Prozessablauf selbstständig vorzunehmen. (Vgl. [JOS06], [PEI06] S. 14 ff.)

2.3 Zusammenfassung

In diesem Kapitel wurden wichtige Begriffe im Zusammenhang mit Geschäftsprozessen erläutert und aufgezeigt, welche Anforderungen an ein Unternehmen von heute gestellt werden.

Geschäftsprozesse erzeugen einen Wert für das Unternehmen, indem sie Kunden­erwartungen und Unternehmens-Strategien realisieren. Ihr effektives und effizientes Management ist daher der Schlüssel für den langfristigen Erfolg eines Unternehmens. Wichtige Voraussetzung dafür ist die optimale Unterstützung der Prozesse durch die vorhandenen Informationssysteme. Die Anwendungslandschaft der Unternehmen ist heute allerdings von einer starken Heterogenität und Komplexität geprägt, was darauf zurückzuführen ist, dass sich die Unternehmen in den vergangenen Jahrzehnten zu sehr auf die lokale Optimierung von einzelnen Funktionsbereichen konzentriert haben und so der Gesamtzusammenhang der betrieblichen Prozesse in den Hintergrund rückte.

Zudem waren Prozesse für Fachanwender nicht „greifbar“, da sich die Geschäftslogik im Programmcode der Anwendungssysteme „versteckte“ und so die IT und die Prozesse praktisch zu einem einzigen untrennbaren Geflecht zusammen wuchsen. Die fehlende Transparenz führte dazu, dass die Fach-Experten bei der kleinsten Änderung eines Prozesses auf die IT-Experten angewiesen waren. Zudem hatten Änderungen im Prozessablauf oft umfangreiche Modifikationen der Anwendungssysteme zur Folge, wodurch sich die Komplexität und Unübersichtlichkeit der IT-Landschaft noch vergrößerte. Die IT entwickelte sich eher zum „Bremser“ anstatt zum „Enabler“ von Flexibilität und Agilität. Für die Realisierung von automatisierten Geschäftsprozessen und B2B-Austausch sowie der damit notwendigen effizienten Integration der Anwendungssysteme im Unternehmen und sogar über die Unternehmensgrenzen hinaus, sind diese Bedingungen untragbar.

Das Geschäftsprozessmanagement versucht, die Probleme mit einer konsequenten Prozessausrichtung und einem ganzheitlichen Vorgehen im Sinne des GPM-Kreislaufes zu bewältigen. Experten sind sich darüber einig, dass eine (Web) Service-orientierte Architektur die Ziele des Geschäftsprozessmanagements am besten unterstützt und deshalb den technischen Rahmen dafür bilden sollte. Die folgenden Kapitel werden zeigen, wodurch sich das Konzept einer solchen Architektur auszeichnet und welchen Nutzen sie dem Unternehmen bringt.

3. Die Service-orientierte Architektur (SOA)

Das Konzept der Service-orientierten Architektur adressiert die in Kapitel 2 dargestellten Herausforderungen des Geschäftsprozessmanagements. Die Einführung des Service-Begriffes revolutioniert die Gestaltung der Anwendungslandschaft eines Unternehmens. Das Versprechen einer SOA ist die Umsetzung einer effizienten, flexiblen und vor allem prozessorientierten Integration der Informationssysteme.

Kapitel 3.1 definiert zunächst die Begriffe Service-Orientierung und Service-orientierte Architektur und im Kapitel 3.2 werden anschließend die Merkmale und Rollen einer SOA vorgestellt. Eine kurze Zusammenfassung folgt im Kapitel 3.3.

3.1 Grundlagen einer SOA

3.1.1 Service-Orientierung

Der Begriff „Service-Orientierung“ ist nicht neu und kann je nach Kontext unterschiedlich ausgelegt werden. Die grundsätzliche Betrachtungsweise ist jedoch immer dieselbe: es geht darum, Dinge zu separieren. Ein komplexes Problem lässt sich besser lösen, wenn man es zuvor in mehrere sinnvolle Einzelprobleme aufteilt. Man kann so zunächst nach Lösungen für die kleineren Einzelprobleme suchen und die gefundenen Teillösungen zu einer Lösung für das Gesamtproblem zusammensetzen. Die Umsetzung der Teillösungen soll durch die Nutzung von Services (Dienstleistungen) erreicht werden. Die Gesamtlösung erhält man dann durch die Aneinanderreihung bzw. Komposition der Services. (Vgl. [ERL05] S. 32)

Laut [DOS04] handelt es sich bei einem Service bzw. einem Dienst um „eine Leistung, die ein Dritter für uns erbringt, von der wir vor der Inanspruchnahme wissen, was sie uns bringt, was sie kostet und in welchem Zeitraum sie erbracht wird“. Die ganze Geschäftswelt ist service-orientiert. Wir alle nutzen täglich Services, welche von verschiedenen Unternehmen angeboten werden, sei es das Fahren in öffentlichen Verkehrsmitteln, der Arztbesuch oder eine Beratungsleistung unserer Bank. (Vgl. [DOS04] S. 53)

Auch in der IT-Welt existiert der Begriff „Service-Orientierung“ schon eine Weile. Objektorientierte und komponentenbasierte Programmier-Paradigma beispielsweise versuchen die im Sinne der Service-Orientierung gewünschte Dekomposition des Gesamtproblems durch Objekte, Klassen und Komponenten umzusetzen (vgl. [ERL05] S. 291). Die Bedeutung des Begriffes „Service-Orientierung“ im Sinne einer SOA wird im nächsten Kapitel erläutert.

3.1.2 Der Begriff SOA

Eine Service-orientierte Architektur stellt keine radikale Neuentwicklung dar. Vielmehr ist sie die Weiterentwicklung von bereits bekannten Architekturen und Integrations­methoden. Der Begriff „Service-orientierte Architektur“ beschreibt ein Modell, bei dem die Programmlogik in kleinere, unabhängige logische Einheiten aufgeteilt wird. Diese kleinen logischen Einheiten stellen Services dar, welche bestimmte Funktionalitäten anbieten und dabei auch auf bestehende Anwendungssysteme zugreifen können. Durch die Aneinanderreihung bzw. Komposition dieser Services werden ganze Geschäfts­prozesse umgesetzt. Im Unterschied zu bisherigen Softwarearchitekturen wird die Ablauflogik nun also nicht mehr im Quellcode vorgehalten, sondern verteilt sich über mehrere unabhängige Services, welche erst während der Ausführungszeit zu einem komplexen Geschäftsprozess zusammengesetzt werden. (Vgl. [ERL05] S. 33, [JOS06] S. 10)

Eine SOA legt den Fokus auf die Wiederverwendung existierender Anwendungs­systeme, auf effiziente Interoperabilität und Integration von Anwendungen sowie auf die Komposition von Geschäftsprozessen aus Services. Ziel einer SOA ist es, eine IT- Infrastruktur zu erhalten, welche die Geschäftsprozesse in den Mittelpunkt stellt und schnell auf veränderte Anforderungen im Unternehmensumfeld reagieren kann. (Vgl. [JUR06a] S. 12)

[DOS05] definiert eine SOA als „eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenun­abhängige Nutzung und Wiederverwendung ermöglicht“ (S. 11).

Entgegen mancher Annahmen handelt es sich bei einer SOA nicht um eine konkrete Technologie, sondern um ein Architekturkonzept. Web Services stellen den zurzeit aussichtsreichsten Kandidaten dar, eine solche Architektur zu realisieren, was jedoch nicht bedeutet, dass man eine SOA nicht auch mit anderen Technologien, zum Beispiel mit CORBA, umsetzen könnte. Warum sich Web Services jedoch am besten dazu eignen, soll im Verlaufe dieser Arbeit herausgearbeitet werden.

Die Trennung des Architekturkonzeptes von seiner konkreten Umsetzung mit bestimmten Technologien bringt Vorteile. So spielt die Architektur im Unternehmen eine weitaus dauerhaftere Rolle, während sich einzelne Technologien schnell ändern können und auch sollen. Vielleicht gibt es irgendwann andere Technologien, die eine SOA besser umsetzen können als Web Services es heute tun. (Vgl. [DOS05] S. 8, [WIN06])

3.2 Das Konzept einer SOA

3.2.1 Merkmale einer SOA

3.2.1.1 Lose Kopplung

Eine SOA setzt auf das Prinzip der losen Kopplung von Services, was bedeutet, dass die Services gegenseitig ihre Funktionalitäten nutzen können, dabei aber trotzdem ihre Unabhängigkeit bewahren. Dies wird zum einen durch die Trennung von Service­Schnittstelle und Service-Implementierung erreicht, wobei nur die Service-Schnittstelle, also die angebotenen Funktionalitäten und die entsprechenden Parameter, nach außen hin sichtbar gemacht wird. Das zweite wichtige Kriterium der losen Kopplung besteht darin, dass zwischen den Services nur Nachrichten ausgetauscht werden und kein Programmcode. Services sind zustandslos und sollten daher bei gleichem Input immer das gleiche Ergebnis liefern. Eine lose Kopplung wird zusätzlich dadurch unterstützt, dass die zwischen den Services ausgetauschten Nachrichten Informationen für den Empfänger bezüglich ihrer Verarbeitung enthalten können. (Vgl. [ERL05] S. 297 ff., [JUR06a] S. 42)

Die durch die lose Kopplung erreichte minimale Abhängigkeit zwischen Services hat den Vorteil, dass die Änderung eines Services andere Services nur minimal oder bei gleichbleibender Schnittstelle sogar gar nicht betrifft (vgl. [JUR06a] S. 12). Zusätzlich ermöglicht die lose Kopplung, dass „Funktionalitäten von Anwendungen oder andere Dienste bei Bedarf dynamisch gesucht, gefunden und eingebunden werden können“ ([DOS05] S. 9).

3.2.1.2 Verwendung von Standards

Um die Interaktion zwischen Services und deren gegenseitige Nutzung zu ermöglichen, ist es notwendig, einheitliche und allgemein akzeptierte Standards zu verwenden. So wird es den Unternehmen leichter gemacht, sich auf ihre Kernkompetenzen zu konzentrieren und in ihre Prozesse zusätzlich Services von entsprechend spezialisierten Anbietern einzubinden. Außerdem führt die Standardisierung zu einer gewissen Flexibilität bei der Auswahl der Anbieter. Ist man mit einem Anbieter nicht zufrieden, kann man auf andere ausweichen. Erst die Abstützung auf offene, plattformunabhängige und verbreitete Standards ermöglicht die Interoperabilität eines Dienstes und seine Verwendung in unterschiedlichem Kontext. Die Nutzung von Standards ist zudem der erfolgversprechendste Weg, eine breite Akzeptanz für die Architektur zu finden. (Vgl. [DOS05] S. 9, [DOS04] S. 54)

3.2.1.3 Wiederverwendbarkeit

Services sollten so gestaltet werden, dass ihre Wiederverwendbarkeit möglichst hoch ist. Das Prinzip der losen Kopplung (siehe Kapitel 3.2.1.1) und die Verwendung von Standards (siehe Kapitel 3.2.1.2) spielen hierbei eine wesentliche Rolle. Wichtig ist auch die gewählte Granularität der Services, wobei man jedoch nicht die Performance außer Acht lassen sollte. So gilt die Granularität als zu fein gewählt, wenn die Services einer SOA-Anwendung gut wiederverwendbar, deren Antwortzeiten jedoch zu lang sind. Der Aufwand, der bei jedem Aufruf des Services entstehen würde^[8], wäre in Relation zum Umfang der angebotenen Funktionalität zu hoch. Stimmt dagegen die Performance, aber die Wiederverwendbarkeit ist stark eingeschränkt, sind die Services zu grob granular. Hier gilt es, das richtige Mittelmaß zu finden. (Vgl. [KUE07] S. 3, [HOF03] S. 28)

[...]

---

^[1] Kern- und Unterstützungsprozesse werden im Kapitel 2.1.2 erklärt.

^[2] In einem Echtzeit-Unternehmen stellt nie ein Informationssystem den Grund für Verzögerungen in der Reaktionszeit dar, sondern immer Abläufe der realen Welt, zum Beispiel wenn der Prozess erst fortgeführt werden kann, nachdem ein Mensch eine bestimmte Tätigkeit ausgeführt hat (vgl. [ALT04] S. 5).

^[3] Ein RPC ist eine durch Middleware implementierte Programmabstraktion, welche den Kommuni­kationskanal hinter einer Schnittstelle verbirgt, die genauso aussieht wie ein normaler Prozeduraufruf (vgl. [ALO04] S. 29 ff.).

^[4] Hat eine Komponente die Durchführung einer Aktion zugesichert, darf sie nichts tun, was diese Durchführbarkeit gefährden könnte (vgl. [BER03] S. 25).

^[5] IIOP steht für Internet Inter ORB Protocol

^[6] EDI erforderte die Installation teurer Software zur Kommunikation und Interpretation der Daten.

^[7] Sie schafften es zwar, die Funktionalität besser zu verstehen, stellten aber immer noch IT-technische Modelle dar, die den Prozessfluss nur unzureichend abbilden konnten (vgl. [JOS06]).

^[8] Umwandlung in XML, Versenden der Nachricht, Interpretation durch Empfänger, Anlegen der Parame­ter in Laufzeitumgebung