Geschäftsprozessmodelle zur Unterstützung einer serviceorientierten Architektur

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Zielsetzung der Arbeit
1.2 Aufbau der Arbeit

2 Grundlegende Begrifflichkeiten
2.1 Geschäftsprozess
2.2 Geschäftsprozessmanagement
2.3 Geschäftsprozessmodelle
2.4 Geschäftsprozessmanagementkreislauf
2.4.1 Strategisches Prozessmanagement
2.4.2 Prozessentwurf
2.4.3 Prozessimplementierung
2.4.4 Prozesscontrolling
2.4.5 Zusammenhänge zwischen den Phasen
2.5 Funktionsorganisation versus Prozessorganisation
2.6 Serviceorientierte Architektur
2.7 Services
2.7.1 Servicearten und Servicehierarchie
2.7.2 Serviceeigenschaften
2.7.2.1.. Zentrale Merkmale
2.7.2.2.. Unterstützende Eigenschaften
2.7.3 Zusammenhänge zwischen den Merkmalen

3 Darstellung des untersuchten Unternehmens
3.1 Unternehmenssituation
3.2 Unternehmensorganisation
3.2.1 Organisationsbereiche des Kerngeschäfts
3.2.2 Unterstützende Organisationsbereiche
3.2.3 Unternehmensorganigramm

4 Gestaltung des Projektes zur Einführung von Geschäftsprozessmanagement
4.1 Vorbereitung
4.2 Projektorganisation
4.2.1 Einfluss-Projektorganisation
4.2.2 Reine Projektorganisation
4.2.3 Matrix-Projektorganisation
4.2.4 Modifizierte Matrixorganisation für Geschäftsprozessmanagementprojekte
4.3 Rollen im Projekt
4.3.1 Aufbauorganisation
4.3.2 Zuständigkeiten beim Geschäftsprozessmanagement
4.3.2.1.. Zuständige Personen für die gesamte Geschäftsprozesslandschaft
4.3.2.2.. Einzelrollen innerhalb von Geschäftsprozessen
4.3.2.3.. Gruppen und Gremien
4.3.3 Serviceverantwortlichkeiten
4.3.4 Beziehungen zwischen den Gremien und Rollen
4.4 Formulierung von Modellierungsgrundsätzen
4.4.1 Individuelle Grundsätze
4.4.2 Grundsätze ordnungsmäßiger Modellierung
4.4.3 Abhängigkeiten zwischen den Arten der Grundsatzformulierung

5 Analyse und Modellierung der Geschäftsprozesslandschaft
5.1 Bestimmung des Informationsbedarfs der Organisation
5.1.1 Domain-Level-Matrix
5.1.2 Metamodell
5.2 Bestimmung der Unternehmensabläufe
5.2.1 Existierende Dokumentationen
5.2.2 Workshops
5.2.3 Detaillierungsgrad der Analyseschritte
5.3 Modellierung der Geschäftsprozesslandschaft
5.3.1 Standardprozessmodell
5.3.1.1.. Festlegung der Prozessklassen und Prozessgruppen
5.3.1.2.. Festlegung der primären Geschäftsprozesse
5.3.1.3.. Bestimmung der sekundären Geschäftsprozesse
5.3.1.4.. Ermittlung der Bearbeitungsobjekte
5.3.1.5.. Geschäftsprozesslandschaft der ersten Ebene
5.3.1.6.. Bestimmung der Teilprozesse
5.3.1.7.. Prozessvarianten
5.3.1.8.. Prozessschritte
5.3.1.9.. Weitere geschäftsspezifische Detaillierungen
5.3.2 Geschäftsserviceorientierte Modellierung
5.3.2.1.. Geschäftsservices der ersten Ebene
5.3.2.2.. Festlegung des Serviceausschnitts
5.3.2.3.. Funktionale Verfeinerung des Serviceausschnitts
5.3.2.4.. Elementare Geschäftsservices festlegen
5.3.2.5.. Geschäftsobjekte bestimmen
5.3.3 Individuelle Geschäftsmodellentwicklung mittels vordefinierter Abstraktionsebenen
5.3.3.1.. Unternehmensinstanz
5.3.3.2.. Kernprozessinstanz
5.3.3.3.. Hauptprozessinstanz
5.3.3.4.. Unterprozessinstanz und Detailinstanz
5.3.4 Gegenüberstellung der Geschäftsprozessmodelle

6 Methoden zur Identifizierung von Services
6.1 Ableitung von Services aus ereignisgesteuerten Prozessketten
6.2 Serviceidentifizierung mittels spezieller Suchalgorithmen
6.3 Domänen und Komponenten als Basis einer serviceorientierten Architektur
6.3.1 Entwicklung von Domänen
6.3.2 Bestimmung der Anwendungsservice
6.3.3 Entwicklung von Komponenten der Anwendungslandschaft
6.3.4 Bewertung der Methode
6.4 Gegenüberstellung der Methoden zur Serviceidentifizierung

7 Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Tabellenverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Die fortschreitende Entwicklung der Informations- und Kommunikationstechnik führt dazu, dass der Markt zunehmend transparenter wird (Witt 2008, S. 89), wodurch der Wettbewerbsdruck für Unternehmen stetig steigt (Schmelzer und Sesselmann 2008, S. 1). Sie erkennen in diesem Zuge, dass die reine Produktion von Gütern nicht mehr ausreichend für den Geschäftserfolg ist, sondern Agilität und Flexibilität von ihnen gefordert sind (Sondermann et al. 2008). Daher werden neue Architekturkonzepte benötigt, welche die Anpassungsfähigkeit der Geschäftsprozesse (GP) eines Unternehmens sowie deren technische Umsetzung unterstützen.

Die Informationstechnik (IT) steht hierbei vor der Herausforderung, dass klassische Konzepte wie Mainframe- und Client-Server-Architekturen in Frage gestellt werden, da sie die GPs statisch abbilden und kaum Änderungen zulassen (Kriegel et al. 2008). Eine Realisierung von flexiblen technischen Architekturen ist daher mit ihnen nicht möglich.

Die aufgeführten Problematiken führen dazu, dass in Unternehmen serviceorientierte Architekturen (SOA) eine zunehmende Verbreitung finden. Dies zeigt sich anhand einer Studie von TechTarget, bei welcher 47,4% der befragten IT-Spezialisten angaben, dass innerhalb ihrer Unternehmen SOA-Projekte durchgeführt werden und 30,9% von ihnen sogar mehrere SOA-Projekte durchführen (2010). Des Weiteren messen einer Studie von Martin et al. zufolge 61% der befragten Unternehmen serviceorientierten Architekturen eine große oder sehr große Bedeutung zu (Martin et al. 2010, S. 7).

Der Erfolg von serviceorientierten Architektur ist nach Beckert et al. darin begründet, dass mittels ihr die Wertschöpfungskette durch die Einteilung in entsprechende Services effizienter und flexibler und damit attraktiver für das Management wird (2008). Ergänzend hierzu weisen Stähler et al. darauf hin, dass die Einbeziehung der GPs des Unternehmens bei der Entwicklung einer serviceorientierten Architektur unabdingbar ist. Ihnen zufolge ist eine SOA ohne Geschäftsprozessmanagement (GPM) als rein technische Lösung ohne direkten Bezug zu den Prozessen des Unternehmens zu sehen (2009, S. 17). Dass dieser Zusammenhang ebenfalls von den deutschen Unternehmen gesehen wird, zeigt sich daran, dass 65% von ihnen ganz oder teilweise ihre SOA-Projekte mit der Umsetzung von GPM verbinden (Martin et al. 2010, S. 10).

Die Verbindung zwischen GPM und SOA bilden die Geschäftsprozessmodelle, welche als Basis für die serviceorientierte Gestaltung der Organisation dienen. In der Literatur finden sich hierzu unterschiedliche Methoden der Geschäftsprozessmodellierung (vgl. Stähler et al. 2009, S. 79-98; Schmelzer und Sesselmann 2008, S. 230-238; Engels et al. 2008, S. 113-142) sowie hierauf aufbauende Vorgehensweisen zur Serviceidentifizierung (vgl. Stähler et al. 2009, S. 176-179; Engels et al. 2008, S. 142-174; Klose und Knackstedt 2007, S. 47-56). Unternehmen stehen somit vor der Herausforderung, dass sie ein für sich geeignetes Geschäftsprozessmodell finden müssen, welches ihre Anforderungen an eine SOA erfüllt.

Die vorgenannten Ausführungen und Studien lassen den Rückschluss zu, dass das Zusammenspiel zwischen GPM und SOA eine immer bedeutendere Rolle bei der Gestaltung der Wertschöpfungskette eines Unternehmens spielt. Für eine erfolgreiche Einführung ist das Wissen über Geschäftsprozessmodelle und ihre Eignung für eine serviceorientierte Umsetzung ein entscheidender Faktor. Gleichsam müssen nach Schmelzer und Sesselmann die hierfür erforderlichen organisatorischen Strukturen im Rahmen des Einführungsprojektes geschaffen werden, damit Schwachstellen in der Organisation nicht die Einführung von GPM (2008, S. 182) und somit der späteren SOA gefährden.

1.1 Zielsetzung der Arbeit

In dieser Arbeit werden bisher bekannte Ansätze für die Entwicklung und Umsetzung von Geschäftsprozessmodellen sowie deren Potentiale für die Identifizierung von Services einer serviceorientierten Architektur dargestellt. Dazu erfolgt zu Beginn eine Erarbeitung der theoretischen Grundlagen bezüglich GPM und SOA. Hierbei wird der Geschäftsprozessmanagementkreislauf erläutert und eine Gegenüberstellung von funktions- und prozessorientierten Organisationformen durchgeführt. Eine Kategorisierung sowie Hierarchisierung von Services schließt sich diesem Teil der Arbeit für die spätere Analyse der Serviceidentifizierungs­methoden an.

Im Anschluss werden die Projektschritte und –strukturen zur Einführung von GPM und SOA anhand eines Beispielsunternehmens erörtert. Den Hauptaspekt stellen hierbei eine systematische Darstellung der einzelnen Projektphasen sowie eine Erarbeitung der Projektrollen und ihrer Zusammenhänge dar.

Die entwickelte Projektorganisation bildet wiederum den Ausgangspunkt für die anschließende Erörterung verschiedener Formen der Geschäftsprozessanalyse. Die Ergebnisse der GP-Analyse bilden die Basis für die darauffolgende Gegenüberstellung von drei Geschäftsprozessmodellierungsmethoden. Die einzelnen Me­tho­den werden hierbei in Bezug auf ihre Stärken und Schwächen verglichen.

Für die Bewertung der Geschäftsprozessmodelle hinsichtlich ihrer Eignung für die Umsetzung einer SOA werden drei Methoden zur Serviceidentifizierung aufgeführt und in Bezug auf ihre Nutzbarkeit für die Modelle untersucht. Außerdem erfolgt ein Vergleich der Methoden anhand bestimmter Merkmale.

1.2 Aufbau der Arbeit

Das 1. Kapitel beinhaltet die Zielsetzung und den Aufbau der Arbeit. Im nachfolgenden Kapitel werden die grundlegenden Begrifflichkeiten in Bezug auf GPM und SOA erläutert. In diesem Zuge erfolgt eine Darstellung des Geschäftsprozessmanagementkreislaufes sowie eine Gegenüberstellung von prozessorientierten und funktionsorientierten Unternehmensorganisationen. Den Abschluss des Kapitels bildet eine Erarbeitung möglicher Kategorisierungen und Hierarchiestufen von Services.

Kapitel 3 befasst sich mit dem Aufbau des Beispielsunternehmens, welches die Grundlage für die späteren Kapitel bildet. Im Fokus stehen hierbei die innerbetrieblichen Abläufe des Unternehmens sowie seine Aufbaustruktur.

Im Anschluss erfolgen in Kapitel 4 eine Darstellung der Projektschritte zur Vorbereitung der Einführung von GPM und SOA sowie eine Erarbeitung und Gegenüberstellung möglicher Projektorganisationsformen. Des Weiteren werden die Rollen innerhalb eines GPM-SOA-Projektes ausgearbeitet und die Notwendigkeit einer Formulierung von Modellierungsgrundsätzen aufgezeigt.

Gegenstand des 5. Kapitels ist eine Erörterung unterschiedlicher Vorgehensweisen zur Geschäftsprozessanalyse. Die Ergebnisse der Geschäftsprozessanalyse bilden wiederum die Basis für die anschließende Gegenüberstellung verschiedener GP-Modelle, wobei sowohl ihre Stärken als auch ihre Schwächen herausgearbeitet werden. Die in Kapitel 5 entwickelten Geschäftsprozessmodelle stellen die Grundlage für die anschließende Serviceidentifizierung dar.

Kapitel 6 führt hierfür mögliche Formen auf und vergleicht sie miteinander. In diesem Zuge werden die Serviceidentifizierungsarten dahingehend untersucht, inwiefern sie sich für den Einsatz bei den entwickelten Geschäftsprozessmodellen eignen und anhand bestimmter Merkmale gegenübergestellt.

Das 7. Kapitel bildet den Abschluss der Arbeit und leitet aus den gewonnen Erkenntnissen entsprechende Schlussfolgerungen ab. In diesem Rahmen erfolgt eine Bewertung der betrachteten Geschäftsprozessmodelle und Serviceidentifizierungsmethoden.

2 Grundlegende Begrifflichkeiten

In diesem Kapitel werden die Begrifflichkeiten, welche mit der Thematik des Geschäftsprozessmanagements sowie von serviceorientierten Architekturen verbunden sind, näher definiert. Hierbei wird zu Beginn der Begriff des Geschäftsprozesses sowie des Geschäftsprozessmanagements erarbeitet. Im Anschluss erfolgen eine Darstellung des Geschäftsprozessmanagementkreislaufes sowie die Gegenüberstellung einer prozessorientierten zu einer funktionsorientierten Organisation. Zum Abschluss des Kapitels wird der Begriff einer serviceorientierten Architektur sowie des Services näher erläutert.

2.1 Geschäftsprozess

Die Begriffe Prozess und Geschäftsprozess werden in der Literatur oftmals gleichgesetzt oder synonym verwendet (Becker und Schütte 2004, S. 107). Wie schwierig diese Bezeichnungen zu unterscheiden sind, wird durch die nachfolgend aufgeführten Definitionen deutlich.

Feldbrügge und Brecht-Hadrashek sehen in einem Prozess „eine Kette von zusammenhängenden Aktivitäten, die gemeinsam einen Kundennutzen schaffen“ (2008, S. 15). Prozesse bestehen demzufolge aus mehreren Aktivitäten und tragen direkt zum Kundennutzen bei (Feldbrügge und Brecht-Hadrashek, S. 16).

Bei den Kunden wird zwischen internen und externen Kunden unterschieden. Externe Kunden sind die potentiellen Abnehmer und Anwender der erstellten Güter, während ein Prozess im Rahmen eines Geschäftsprozesses interner Kunde des vorherigen Teilprozesses ist (Feldbrügge und Brecht-Hadrashek, S. 17). Die internen Kunden-Lieferanten-Beziehungen werden jedoch oftmals vernachlässigt, da das Verständnis dafür fehlt, den Kollegen als Kunden der eigenen Leistung zu sehen (Feldbrügge und Brecht-Hadrashek, S. 18).

Während Feldbrügge und Brecht-Hadrashek eine direkte Kundenbeziehung bei einem Prozess sehen, besteht er nach Schmelzer und Sesselmann aus einer Reihe von Inputs, welche nach dem Durchlauf von verschiedenen Schritten in einem Output umgewandelt werden (Schmelzer und Sesselmann 2008, S. 64). Der Output ist entweder ein Zwischenprodukt oder ein Endprodukt für den Abnehmer. In diesem Zuge wird keine Unterscheidung der Begrenzung, Reichweite, Struktur, des Inhalts sowie des Empfängers von einem Prozess durchgeführt (Schmelzer und Sesselmann 2008, S. 63).

Den Aspekt der Kundenorientierung bringen Schmelzer und Sesselmann bei ihrer Darstellung eines Geschäftsprozesses mit ein:

„Ein Geschäftsprozess besteht aus der funktions- und organisationsübergreifenden Verknüpfung wertschöpfender Aktivitäten, die von Kunden erwartete Leistungen erzeugen und dies aus der Geschäftsstrategie abgeleiteten Prozessziele umsetzen.“ (Schmelzer und Sesselmann 2008, S. 64)

Dementsprechend ist nach Schmelzer und Sesselmann ein Geschäftsprozess eine höhere Instanz, welche die einzelnen Aktivitäten derart verknüpft, dass die strategischen Ziele des Unternehmens erreicht und die Kundenbedürfnisse befriedigt werden können. In Anlehnung an Porter (vgl. 1992, S. 66–73) unterscheiden sie im Weiteren zwischen primären und sekundären Geschäftsprozessen (Schmelzer und Sesselmann 2008, S. 77-78).

Die primären Geschäftsprozesse erstellen und vermarkten die Güter für externe Kunden und dienen damit der originären Wertschöpfung. Sie haben daher einen entscheidenden Einfluss auf die Wettbewerbsfähigkeit des Unternehmens (Schmelzer und Sesselmann 2008, S. 78). Sekundäre Geschäftsprozesse agieren als unternehmensinterne Dienstleister für die primären Geschäftsprozesse, indem sie den notwendigen Management- und Infrastruktursupport für einen effizienten und effektiven Ablauf leisten (Schmelzer und Sesselmann 2008, S. 78-79).

Becker und Kahn schließen sich hinsichtlich der strategischen Bedeutung von Geschäftsprozessen Schmelzer und Sesselmann an und stellen sie als spezielle Prozesse heraus, welche Schnittstellen zu Marktpartnern besitzen (2005, S. 6-7). Becker und Kahn sehen jedoch die Unterscheidung in wertschöpfende und unterstützende Aktivitäten nicht bei den Geschäftsprozessen, sondern bei den Prozessen, welche sie in Kernprozesse zur Produktherstellung und Supportprozesse zur Unterstützung der Kernprozesse unterteilen (2005, S. 7).

Während die bisher aufgeführten Autoren stets eine Trennung zwischen Prozess und Geschäftsprozess vornehmen, sieht Allweyer diese Begriffe synonym. Ihm zufolge ist ein Geschäftsprozess „eine Abfolge von Funktionen (auch als Aktivitäten bezeichnet) zur Erfüllung einer betrieblichen Aufgabe, wobei eine Leistung in Form von Informations- und/oder Materialtransformation erbracht wird“ (2005, S. 8). Nach Allweyer unterscheiden sich demnach Leistungen eines Geschäftsprozesses darin, dass sie sich auf die Bearbeitung von notwendigen Informationen sowie Materialien beziehen können. Zusammenfassend werden für die weitere Arbeit an dieser Stelle die wesentlichen Charakteristika eines Geschäftsprozesses aufgeführt:

Geschäftsprozesse leisten als spezielle Form von Prozessen einen direkten oder unterstützenden Beitrag zur Wertschöpfung des Unternehmens und damit zur Erreichung der strategischen Ziele. Ihre Leistungen sind auf die Befriedigung von Bedürfnissen interner sowie externer Kunden hin ausgerichtet, wobei die einzelnen Aktivitäten funktions- und organisationsbereichsübergreifend ausgeführt werden.

2.2 Geschäftsprozessmanagement

Das Geschäftsprozessmanagement befasst sich nach Allweyer mit der Gestaltung, Steuerung und Kontrolle von Geschäftsprozessen und wird ihm zufolge wie folgt definiert:

„Geschäftsprozessmanagement bezweckt die systematische Gestaltung, Steuerung, Überwachung und Weiterentwicklung der Geschäftsprozesse eines Unternehmens. Es umfasst das strategische Prozessmanagement, den Prozessentwurf, die Prozessimplementierung und das Prozesscontrolling.“ (Allweyer 2005, S. 12)

Ausgehend von dieser Definition wird deutlich, dass GPM neben den bereits aufgeführten Aufgaben eine Prozesslandschaft gestaltet, welche die strategische Ausrichtung des Unternehmens wiederspiegelt. Stähler et al. fügen der prozessbezogenen Sichtweise von Allweyer eine organisationbezogene hinzu:

„Business Process Management umfasst alle Aktivitäten zur effektiven Organisationsgestaltung und –weiterentwicklung und zur Bearbeitung und zur Messung fachlicher Prozesse sowie die dazu eingesetzte informationstechnologische Unterstützung.“ (Stähler et al. 2009, S. 15)

Stähler et al. stellen die besondere Rolle der IT bei der Modellierung und Umsetzung von Geschäftsprozessen heraus und sehen in ihr einen Kernaspekt bei der Einführung von Geschäftsprozessmanagement. Neben den fachlichen und technischen Gesichtspunkten von GPM ist dessen Zielsetzung für den Einsatz in Unternehmen von Bedeutung. Vor diesem Hintergrund stellen Kiradjiev et al. die folgende Definition für das fachliche Geschäftsprozessmanagement auf:

„Business Process Management (BPM) ist ein betriebswirtschaftlicher Ansatz, der darauf abzielt, alle Aspekte einer Organisation auf Effizienz und Effektivität bei gleichzeitigem Streben nach Flexibilität, Innovation und enger Integration der Prozesse in Technologie auszurichten. BPM strebt nach einer kontinuierlichen Verbesserung der Prozesse und kann mit dieser Perspektive als der Prozess zur Optimierung der Prozesse beschrieben werden.“ (Kiradjiev et al. 2010a)

Unternehmen sind demnach bestrebt, durch den Einsatz von Geschäftsprozessmanagement eine höhere Flexibilität und Innovativität zu erreichen. Dies ist darin begründet, dass sich ständig ändernde Marktverhältnisse und Kundeninteressen eine uneingeschränkte Anpassungsfähigkeit von Unternehmen verlangt (Kiradjiev et al. 2010b). Unterstützt wird die Adaptivität durch den Einsatz von geeigneten informationstechnischen Instrumenten als technisches GPM, welche die Prozessumsetzung durchführen.

Schmelzer und Sesselmann sehen wie Kiradjiev et al. in der Bedürfnisbefriedigung beim Kunden einen Kernaspekt des GPM und sehen damit in ihm die Grundlage für die Umsetzung von strategischen und operativen Zielen (2008, S. 4-5). Strategie- und Kundenbezug müssen dabei derart aufeinander abgestimmt sein, dass die Konzentration auf die kurzfristigen Ziele nicht die langfristigen Erfolgspotentiale gefährdet und umgekehrt. Das GPM muss daher sicherstellen, dass die Geschäftsprozesse mit den strategischen Zielen sowie den Kundenzielen zusammenspielen (Schmelzer und Sesselmann 2008, S. 6-7).

Aus den aufgeführten Definitionen erschließt sich, dass GPM sowohl die fachliche als auch die technische Entwicklung und Umsetzung von Geschäftsprozessen unterstützt. Zielsetzung ist dabei die Schaffung einer flexiblen Prozesslandschaft, die Unternehmen eine zeitnahe Umsetzung von Innovationen ermöglicht.

2.3 Geschäftsprozessmodelle

Für die Abbildung von Geschäftsprozessen werden Geschäftsprozessmodelle verwendet. Nach Engels et al. ist ein Geschäftsprozessmodell „die Beschreibung und Darstellung aller relevanten Aspekte von Geschäftsprozessen in einer definierten Beschreibungssprache. Ziel und Ergebnis ist die modellhafte Nachbildung der Realität“ (2008, S. 121).

Geschäftsprozessmodelle bilden einen wichtigen Schlüssel für die Identifikation von möglichen Teilen des Geschäfts, welche durch die IT unterstützt werden können (Engels et al. 2008, S. 121). Des Weiteren fördern sie die Identifikation von Informationsflüssen, welche wiederum Rückschlüsse auf mögliche Anwendungsservices, Schnittstellen und Datenflüsse zulassen (Engels et al. 2008, S. 121).

Zusätzlich zu den vorgenannten Aspekten helfen Geschäftsprozessmodelle komplexe Prozesse, zum Beispiel durch die Bildung von Sichten, übersichtlicher zu gestalten und Zusammenhänge zu erkennen (Allweyer 2005, S. 129). Für das Verständnis des dargestellten Sachverhaltes spielt die Wahl der richtigen Modellierungsart eine bedeutende Rolle. Allweyer unterscheidet dabei die Formen der textuellen, tabellarischen und grafischen Darstellung (2005, S. 130), wobei die Auswahl der Methode vom jeweiligen Verwendungszweck abhängig ist (2005, S. 135).

Bei der grafischen Darstellung kann zusätzlich zwischen notationskonformen und nicht notationsgebundenen Darstellungen unterschieden werden (Allweyer 2005, S. 130). Die Visualisierungsformen, welche einer vorgegebenen Notation entsprechen, haben den Vorteil allgemein verständlich und maschinell interpretierbar zu sein. Aufgrund der vorgenannten Gegebenheiten ist es möglich, für diese Modelle Softwarekomponenten einzusetzen, welche eine automatisierte Optimierung und Weiterentwicklung des Modells durchführen (Allweyer 2005, S. 134).

Aus den vorherigen Erörterungen wird deutlich, dass die Geschäftsprozessmodellierung einen wesentlichen Beitrag zur Schaffung einer flexiblen und verständlichen Prozesslandschaft leistet. Bei der Auswahl der Modellierungsmethode sind der Zweck sowie das zugrundeliegende Abstraktionsniveau zu berücksichtigen.

2.4 Geschäftsprozessmanagementkreislauf

Wie aus dem Abschnitt 2.2 hervorgeht, werden mittels des Geschäftsprozessmanagements die Geschäftsprozesse eines Unternehmens abgebildet, gesteuert und weiterentwickelt. Für die Durchführung dieser Aufgaben ist ein Vorgehensmodell erforderlich, das den Entwicklungs-, Implementierungs- und Controllingprozess von Geschäftsprozessen strukturiert abbildet. Eine Möglichkeit zur phasenorientierten Darstellung der einzelnen Handlungen ist der Geschäftsprozessmanagementkreislauf. Nach Allweyer kann der Kreislauf folgende Phasen untergliedert werden:

- strategisches Prozessmanagement,
- Prozessentwurf,
- Prozessimplementierung und
- Prozesscontrolling (2005, S. 89-94).

2.4.1 Strategisches Prozessmanagement

Das strategische Prozessmanagement als erste Phase stellt die mittel- und langfristige Gestaltung des Unternehmens und seiner Beziehungen zur Umwelt in den Mittelpunkt. Hierbei werden die Leistungen des Unternehmens, seine Struktur sowie die Märkte auf denen es agiert, festgelegt (Allweyer 2005, S. 90). Ziel der strategischen Überlegungen ist die dauerhafte Sicherung von Wettbewerbsvorteilen durch eine geeignete Ausrichtung des Unternehmens (Schmelzer und Sesselmann 2009, S. 92).

Die herkömmliche strategische Unternehmensführung befasst sich jedoch eher mit finanziellen Kennzahlen, als dass sie ihre Prozesse überdenkt und weiterentwickelt. Das strategische Prozessmanagement hat daher die Verankerung des GPM in der Unternehmensstrategie sowie eine entsprechende Ausrichtung der Geschäftsprozesse zur Aufgabe. Hierzu gehören die Definition der wertschöpfenden Kernprozesse sowie die Entscheidung, welche Funktionen vom Unternehmen selbst und welche von anderen Marktteilnehmern durchgeführt werden (Allweyer 2005, S. 90-91). Schmelzer und Sesselmann bemerken hierzu, dass primäre Geschäftsprozesse im Unternehmen verbleiben müssen, jedoch sekundäre Prozesse auf eine mögliche Auslagerung hin zu überprüfen sind (2008, S. 92-95).

Eine weitere Aufgabe ist die Ausrichtung der Geschäftsprozesse an den Unternehmenszielen. Sie sind dahingehend zu untersuchen, welcher Einfluss ihnen auf die Erreichung der Zielstellungen zukommt. Zusätzlich zu den vorgenannten Aufgaben trägt das strategische Prozessmanagement dafür Sorge, dass der Grundgedanke der Prozessorientierung im gesamten Unternehmen verstanden und umgesetzt wird (Allweyer 2005, S. 92).

2.4.2 Prozessentwurf

Im Anschluss an das strategische Prozessmanagement erfolgt der Prozessentwurf. Aufgabe des Prozessentwurfs ist die Identifizierung, Dokumentation und Analyse von Geschäftsprozessen. Des Weiteren werden innerhalb dieser Phase die GPs optimiert und beschrieben (Allweyer 2005, S. 92).

Als Arbeitsmittel für die Analyse und Dokumentation dient die Geschäftsprozessmodellierung. Zur besseren Beurteilung von Geschäftsprozessen werden unter Umständen weitere Kriterien wie beispielsweise die Prozesskostenrechnung eingesetzt, damit die tatsächlichen Kosten ermittelbar sind. Die darauffolgende dynamische Simulation ermöglicht den Vergleich und die Durchführung von unterschiedlichen Szenarien (Allweyer 2005, S. 92).

2.4.3 Prozessimplementierung

Die Umsetzung der entworfenen Prozesse gehört in die Phase der Prozessimplementierung. Im Vordergrund stehen dabei die organisatorischen Maßnahmen und die Implementierung der Informationssysteme (Allweyer 2005, S. 92).

Der Schlüssel für eine erfolgreiche Durchführung dieser Tätigkeiten liegt im Change-Management. Die Grundlage hierfür bildet die Mitarbeitermotivation, welche dadurch gestärkt wird, dass die Bedürfnisse von ihnen in den Changeprozess mit einfließen. Eine der schwierigsten Aufgaben in diesem Zusammenhang ist die Implementierung von Informationssystemen und gleichzeitige Integration in die bereits vorhandene Anwendungslandschaft (AL) des Unternehmens (Allweyer 2005, S. 92-93).

2.4.4 Prozesscontrolling

Die Aufgabe des Prozesscontrollings liegt in der Überwachung der umgesetzten Geschäftsprozesse. Mittels der erhobenen Ergebnisse sind etwaige Abweichungen von den vorgegebenen Prozesskennzahlen und gegebenenfalls Störungen zeitnah zu erkennen. Das Unternehmen definiert hierfür geeignete Kennzahlen und legt die Methoden für die Ermittlung und Auswertung von ihnen fest (Allweyer 2005, S. 93).

Bei der Festlegung der Prozesskennzahlen kann zwischen der strategischen und operativen Prozesskontrolle unterschieden werden. Die strategische Prozesskontrolle verfolgt die Unternehmensvision und überprüft die Zahlen beispielsweise mittels einer Balanced Scorecard^[1] (Schmelzer und Sesselmann 2008, S. 265). Bei der operativen Prozesskontrolle stellt hingegen den kontinuierlichen Effizienz- und Effektivitätsgewinn in den Vordergrund (Schmelzer und Sesselmann 2008, S. 308).

Die Überwachung der Prozesse und Ereignisse ist durch Business-Activity-Monitoring-Systeme möglich. Zusätzlich sind Mitarbeiterbefragungen ein wichtiges Instrument zur Steigerung der Mitarbeitermotivation und Feststellung von Prozessschwächen (Allweyer 2005, S. 93).

2.4.5 Zusammenhänge zwischen den Phasen

Die einzelnen Phasen des Geschäftsprozessmanagementkreislaufs bilden einen Zyklus ab, der wiederholt durchlaufen wird. Dabei bilden die Ergebnisse des Prozesscontrollings den Ausgangspunkt für das strategische Prozessmanagement und unterstützen damit die kontinuierliche Weiterentwicklung der Unternehmensprozesse. Änderungen an Prozessen von geringerem Ausmaß sollten jedoch auch ohne eine Beteiligung des strategischen Prozessmanagements möglich sein. Die im Prozesscontrolling ermittelten Resultate fließen in diesem Fall direkt in die Phase des Prozessentwurfs mit ein (Allweyer 2005, S. 93). Abbildung 2.1 stellt die Zusammenhänge zwischen den einzelnen Phasen grafisch dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Der Geschäftsprozessmanagementkreislauf nach Allweyer^[2]

Quelle: in Anlehnung an Allweyer 2005, S. 91

2.5 Funktionsorganisation versus Prozessorganisation

Die erfolgreiche Umsetzung von GPM steht in direkter Beziehung mit der Unternehmensorganisation. In diesem Zusammenhang lassen sich die beiden Formen funktionsorientierte und prozessorientiere Ablauforganisationen unterscheiden.

Funktionsorientierte Organisationen sind dadurch gekennzeichnet, dass bei ihnen relativ gleichartige Funktionen in Organisationseinheiten zusammengefasst werden (Allweyer 2005, S. 12). Die einzelnen Funktionen sind auf bestimmte Verrichtungen spezialisiert und bearbeiten lediglich Teile von Aufträgen. Schwierigkeiten ergeben sich bei der Durchführung von Aufträgen, welche innerhalb ihrer Prozesskette unterschiedliche Abteilungen oder mehrere Ebenen durchlaufen. Diese Aufträge haben während ihrer Durchführung unterschiedliche Prozess- und Verantwortungsbrüche zu bewältigen und Schnittstellen zu überwinden. Die genannten Schnittstellen führen wiederum zu einem Anstieg der möglichen Fehlerquote bei der Auftragsdurchführung und erhöhen die Wahrscheinlichkeit von Missverständnissen (Schmelzer und Sesselmann, S. 72-73).

In der Vergangenheit haben Unternehmen ihre Funktionsorganisation immer weiter perfektioniert und damit lokale Optima geschaffen. Zwar konnten die Koordinationskosten aufgrund von technologischen und organisatorischen Veränderungen, wie beispielsweise der Einrichtung eines Callcenters oder Interanets, reduziert werden, jedoch wurden die strukturellen Probleme nicht gelöst. Des Weiteren führen globale Abläufe und der daraus resultierende Kostendruck dazu, dass eine ganzheitliche Sichtweise auf die Prozesse und nicht auf einzelne Funktionen des Unternehmens erforderlich ist (Becker et al. 2009, S. 2).

Eine Alternative stellen prozessorientierte Aufbaustrukturen dar, bei denen die Bedürfnisse der Kunden und des Marktes die Leistungen der Geschäftsprozesse bestimmen. Die Geschäftsprozesse folgen dabei keinen konkreten strukturellen Grenzen, sondern binden, wenn nötig, sämtliche Abteilungen mit ein, damit die Wertschöpfung optimiert wird. Organisationseinheiten werden demzufolge nicht mehr nach funktionalen Gesichtspunkten gebildet, sondern setzen einen konkreten Prozess um (Schmelzer und Sesselmann 2008, S. 75; Allweyer 2005, S. 14).

Für die Mitarbeiter bietet nach Schmelzer und Sesselmann die prozessorientierte Ablauforganisation den Vorteil, dass sie sich im Gesamtkontext des Unternehmens wiederfinden und den Kundennutzen erkennen können. Im Gegensatz dazu sind mit der Einführung von prozessorientierten Organisationsformen Schwierigkeiten bei den Führungskräften der mittleren Managementebene zu erwarten, da ihre Tätigkeiten bei der Neustrukturierung besonders im Vordergrund stehen und grundlegend überdacht werden (2008, S. 75-76).

Mit der Einführung von GPM ist Schmelzer und Sesselmann zufolge stets die Umsetzung einer prozessorientierten Ablauforganisation verbunden. Zwar bietet das GPM Koordinationsinstrumente, welche die Einschränkungen einer funktionsorientierten Organisation überwinden können, jedoch geschieht dies zu Lasten der Effizienz. Sie ergänzen hierzu, dass die Struktur eines Unternehmens den Prozessen zu folgen hat und somit lediglich mit einer prozessorientierten Aufbaustruktur die volle Leistungsfähigkeit zu erreichen ist (2008, S. 76-77).

2.6 Serviceorientierte Architektur

Neben dem GPM stellt die serviceorientierte Architektur den zweiten Kernaspekt der weiteren Arbeit dar. Für die Definition einer serviceorientierten Architektur gibt es unterschiedliche Ansatzpunkte. MacKenzie et al. sehen eine serviceorientierte Architektur aus einem fachlichen Blickwinkel:

„Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.” (Mac­Kenzie et al. 2006, S. 8)

Die Umsetzung von Services ist damit nicht an eine IT-technische Realisierung gebunden, sondern kann durch fachliche Maßnahmen erfolgen (Stähler et al. 2009, S. 17). MacKenzie et al. verdeutlichen ebenfalls, dass die Nutzung von Services nicht an bestimmte Eigentümerverhältnisse gebunden ist, sondern ein domänenübergreifender Zugriff auf sie erfolgen kann.

Erl wird hierzu konkreter und beschreibt eine SOA als Architektur:

„SOA führt ein Architekturmodell ein, das Effizienz, Agilität und Produktivität eines Unternehmens dadurch steigern will, dass die Lösungslogik im Wesentlichen durch Services dargestellt wird. Dies erleichtert die Umsetzung der strategischen Ziele, die sich mit dem serviceorientierten Computing verbinden.“ (Erl 2008, S. 52)

Serviceorientierte Architekturen sind demnach bestrebt, die gesamte Wertschöpfungskette des Unternehmens leistungsfähiger zu gestalten, wobei eine Servicestruktur geschaffen wird, welche die Umsetzung der strategischen Ziele unterstützt. Beinhauer et al. bestätigen Erls Sichtweise, allerdings sehen sie in einer SOA ein IT-Konzept:

„Eine serviceorientierte Architektur ist ein IT-Konzept, das die Ausführung von Geschäftsprozessen durch fachliche Services unterstützt. Dabei sind Services informationelle Einheiten, die von Service-Anbietern bereitgestellt werden, einen klar formulierten funktionalen Umfang haben und über einen Vertrag mit einem Service-Nutzer verbunden sind. Ihre wesentlichen Eigenschaften sind: Wiederverwendbarkeit, Standardisierung und Attraktivität […]. Zu einer SOA gehören fachliche und technische Artefakte (z.B. Servicemodellierung, SOA Plattform), welche die sichere und effiziente Verwaltung des Lebenszyklus von Services ermöglichen, sowie die Einbindung von Services in beliebigen Geschäftsprozessen gestatten.“ (Beinhauer et al. 2008, S. 20)

Beinhauer et al. zeigen die unterschiedlichen Komponenten auf, welche für eine Servicenutzung erforderlich sind. Hierzu gehören der Serviceersteller, der Serviceverwalter sowie der Nutzer. Die bereitgestellten Services müssen derart fachlich und technisch konzipiert sein, dass sie in beliebige Geschäftsprozesse mit eingebunden werden können. Bei der Nutzung von Services geht der Konsument einen Vertrag mit dem Anbieter ein, der ihm den funktionalen Umfang garantiert.

Eine spezifischere Darstellung wählen Krafzig et al. und definieren eine SOA anhand ihrer Bestandteile:

„Eine Serviceorientierte Architektur ist eine Softwarearchitektur, die auf den folgenden Schlüsselkonzepten basiert: Anwendungs-Frontend, Service, Service-Repository und Service Bus. Ein Service besteht aus einem Vertrag, einer oder mehreren Schnittstellen und einer Implementierung.“ (Krafzig et al. 2007, S. 77)

Das Anwendungs-Frontend ermöglicht die Interaktion mit dem Enterprise-System, wobei es als grafische Benutzeroberfläche, Batch-Programm oder langlebiger Prozess umgesetzt sein kann. Ein Service ist hierbei eine Softwarekomponente, welche eine bestimmte funktionale Bedeutung besitzt und ein Geschäftskonzept höherer Ebene einkapselt (Krafzig et al. 2007, S. 78). Für die Erkennung von Services stellt das Service-Repository die notwendigen Informationen bereit und ergänzt sie, sofern es erforderlich ist (Krafzig et al. 2007, S. 80). Die Verbindung zwischen Service und Anwendungs-Frondend wird durch den Service-Bus hergestellt, welcher die Durchführung eines Serviceaufrufs ermöglicht (Krafzig et al. 2007, S. 83).

Aus den vorherigen Ausführungen erschließt sich, dass serviceorientierte Architekturen der Flexibilisierung von Geschäftsprozessen dienen. Der Schlüssel hierzu sind Services, die eine bestimmte Geschäftslogik kapseln und über wohldefinierte Schnittstellen aufgerufen werden können. Die Zielsetzung ist es, eine technologieunabhängige Architektur zu schaffen, welche die Services in den Mittelpunkt stellt (Tilkov und Starke 2007, S. 12). Bestätigt wird dies durch Krafzig et al., welche bei SOA die Aufgabe sehen, die Geschäftsanwendungen von den technischen Services zu entkoppeln und von einer konkreten technologischen Umsetzung unabhängig zu machen (2007, S. 77).

2.7 Services

Aus den im vorherigen Abschnitt aufgeführten Definitionen geht hervor, dass Services das Kernstück einer serviceorientierten Architektur bilden. Services sind durch unterschiedliche Merkmale charakterisiert und besitzen individuelle Fähigkeiten. Ziel dieses Abschnittes ist es, in der Literatur aufgeführte Servicearten zu erläutern und vergleichend in einer Hierarchie darzustellen.

2.7.1 Servicearten und Servicehierarchie

Nach Krafzig et al. können Services in Abhängigkeit von ihrem Typus den Abstraktionsebenen Enterpriseschicht, Prozessschicht, Zwischenschicht und Basisschicht zugordnet werden (Krafzig et al. 2007, S. 99-100). In Anlehnung an Krafzig et al. ergänzt Freitag das Ebenenmodell um eine technologische Ebene, welche ihm zufolge die unterste Schicht darstellt (2009, S. 5).

Erl, Krafzig et al. sowie Hess et al. zeigen unterschiedliche Servicearten auf, die im Folgenden den unterschiedlichen Ebenen zugeordnet werden. Bei der Erörterung der einzelnen Servicearten werden die Gemeinsamkeiten sowie Unterschiede zwischen ihnen herausgestellt.

Enterpriseschicht

Die oberste Schicht beinhaltet Services, welche die Endpunkte der Architektur repräsentieren. Nach Krafzig et al. sind dies öffentliche Unternehmens-Services sowie Anwendungsfrontends (2007, S. 99). Öffentliche Unternehmens-Services stehen dem Unternehmen und seinen Partnern zur Verfügung. Aufgrund des daraus resultierenden unbekannten Benutzerkreises müssen sie besondere Anforderungen in Bezug auf die Entkopplung zu Geschäftspartnern, der rechtlichen Verbindlichkeit der übertragenen Dokumente sowie der eingesetzten Sicherheitsmechanismen realisieren. Des Weiteren sind Besonderheiten hinsichtlich der Rechnungsstellung zu beachten, da zuverlässige Mechanismen einen sicheren Cashflow zu gewährleisten haben (Krafzig et al. 2007, S. 99-100).

Hess et al. bezeichnen die aufgeführte Serviceart in angepasster Form als Interaktionskomponente (vgl. 2006, S. 5), welche ebenfalls der Enterpriseschicht zugeordnet werden können (Freitag 2009, S. 8). Interaktionskomponenten beinhalten zusätzlich die Schnittstellen zu den internen Anwendungen (vgl. Hess et al. 2006, S. 5), welche Krafzig et al. separiert als Anwendungsfrontend (vgl. 2007, S. 87) aufführen. (Freitag 2009, S. 8).

Prozessschicht

Auf der Prozessschicht sind Services angesiedelt, welche einen Prozessablauf direkt repräsentieren (Krafzig et al. 2007, S. 99). Krafzig et al. bezeichnen sie als prozesszentrierte Dienste, welche das Wissen über Geschäftsprozesse beinhalten und stellen aus technischer Sicht die komplexeste Serviceklasse dar. Sie verwalten und kontrollieren ihren eigenen Status, damit die Geschäftsprozesse durchgeführt werden können (2007, S. 96-97).

Der Prozessschicht gehören ebenfalls die Task-Services sowie orchestrierten Task-Services nach Erl (vgl. 2008, S. 59-60) und die Prozesskomponenten von Hess et al. (vgl. 2005, S. 5) an (Freitag 2009, S. 8-10). Task-Services und Prozesskomponenten sind ähnlich den prozesszentrierten Services definiert (Freitag 2009, S. 8), wobei Task-Services zu orchestrierten Task-Services zusammengefasst werden können (Erl 2008, S. 60).

Zwischenschicht

Services der Zwischenschicht agieren als Fassaden, Technologie-Gateways, Adapter oder funktionsergänzende Services (Krafzig et al 2007, S. 99). Technologie-Gateways bilden das Bindeglied zur Überbrückung von technologischen Lücken. Sie sind die Grundlage von Integrationsprojekten bei Altanwendungen, da die neuen Komponenten nicht in die Altanwendungen integriert werden, sondern sie erweitern. Adapter bilden im Vergleich dazu einen speziellen Zwischenservice für die Verbindung eines Clients mit einem Service, indem sie die Signaturen und Nachrichtenformate entsprechend abbilden. Fassaden bieten die Möglichkeit, unterschiedliche Ansichten auf Services zu realisieren. Funktionsergänzende Services fügen bisher nicht vorhandene Funktionalitäten bei Bestandsdiensten hinzu (Krafzig et al. 2007, S. 91-96).

Basisschicht

Die Basisschicht bildet nach Krafzig et al. die Grundlage einer serviceorientierten Architektur (2007, S. 99). Basis-Services stellen bei ihr die Daten und die Geschäftslogik zur Verfügung und werden dementsprechend in daten- und logikzentrierte Services untergliedert. Datenzentrierte Services beinhalten Funktionalitäten zum Laden und Speichern von Daten und realisieren die notwendigen Sperr- und Transaktionsmechanismen. Algorithmen für komplexe Algorithmen oder Geschäftsregeln sind in den logikzentrierten Services gekapselt (Krafzig et al. 2007, S. 88-90).

Freitag zufolge gehören der Basisschicht ebenfalls die Entity-Services von Erl (vgl. 2008, S. 58) sowie die Funktions- und Bestandskomponenten nach Hess et al. (vgl. 2006, S. 5) an, welche ähnliche Funktionszwecke besitzen (2009, S. 8‑9). Unterschiede ergeben sich lediglich im Aufbau der Services nach Hess et al. und Krafzig et al. Während bei Krafzig et al. die Daten- und Logikverwaltung innerhalb des Basis-Services stattfindet, werden diese Funktionen bei Hess et al. als eigene Bestands- bzw. Funktionskomponenten abgebildet. Hierdurch ergibt sich im Vergleich zu Krafzig et al. eine Hierarchie der Komponenten, da die Funktionskomponente auf die Bestandskomponente zurückgreift (Freitag 2009, S. 7).

Technologieebene

Die Technologieebene beinhaltet die Utility-Services (Freitag 2009, S. 9-10), welche einen funktionalen Kontext realisieren, der an keinen konkrete Geschäftsprozess gebunden sind. Utility-Services erreichen damit eine höhere Wiederverwendbarkeit und verfolgen die Zielstellung möglichst mehrere Unternehmenssysteme und –ressourcen nutzen zu können (Erl 2008, S. 61). Die aufgeführten Ebenen und Servicearten werden in der Abbildung 2.2 zusammenfassend dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Vergleich der Servicearten^[3]

Quelle: in Anlehung an Freitag 2009, S. 10

2.7.2 Serviceeigenschaften

Services müssen als Kernkomponente von serviceorientierten Architekturen unterschiedliche Merkmale erfüllen, damit sie organisations- und unternehmensübergreifend nutzbar sind. In den folgenden beiden Abschnitten werden in Anlehnung an Freitag die zentralen und unterstützenden Eigenschaften eines Service dargestellt (2009, S. 11-15).

2.7.2.1 Zentrale Merkmale

Die zentralen Merkmale eines Service bilden die Basis für dessen bestmögliche Eingliederung in eine serviceorientierte Architektur. Hierzu zählen die Wiederverwendbarkeit, Kompositionsfähigkeit und lose Kopplung (Freitag 2009, S. 11‑12). Ergänzend hierzu wird der Servicevertrag als zentrales Merkmal aufgeführt, da er die nach Erl die Basis für den Serviceentwurf ist (2008, S. 139).

Serviceverträge

Ein Servicevertrag besteht aus unterschiedlichen Servicebeschreibungen, welche das Verhalten des Dienstes zur Laufzeit wiedergeben. Die Beschreibungen sind vorwiegend technische Dokumente, welche gegebenenfalls durch fachliche Dokumente ergänzt werden (Erl 2008, S. 140).

Zielstellung der Dokumente ist die Darstellung des Zwecks und der Fähigkeiten der einzelnen Services. Des Weiteren können mittels der Dokumente bei einer konsistenten Beschreibung der Servicefähigkeiten die Serviceendpunkte und damit die Schnittstellen des gesamten Serviceinventars besser identifiziert und vorhergesagt werden (Erl 2008, S. 144). Serviceverträge sind damit ein Schwerpunkt beim Dienstentwurf und bilden die Grundlage für die Erfüllung der anderen Merkmale.

Lose Kopplung

Die lose Kopplung stellt eine der bedeutendsten Richtlinien bei der Serviceimplementierung dar, da sie die Voraussetzung dafür ist, dass Services in heterogenen Umgebungen miteinander kooperieren können (Röder 2007, S. 245) und somit wiederverwendbar sind. Serviceverträge sind hierfür derart zu gestalten, dass sie eine größtmögliche Unabhängigkeit von der Implementierung gewährleisten und damit spätere Modifizierungen der Dienste bei den Vertragsparteien ermöglichen. Außerdem ist der funktionale Servicekontext nach Möglichkeit unabhängig von der Logik der Außenwelt zu entwickeln, um die Bindung an bestimmte Kunden zu minimieren (Erl 2008, S. 179).

Die lose Kopplung ist zwar eine der Kerneigenschaften von Services, jedoch ist mit ihr stets ein hoher Aufwand für die entsprechende Pflege der AL verbunden. Josuttis weist daher darauf hin, dass der Aufwand für die Realisierung der Eigenschaft in einem ausgewogenen Verhältnis mit dem Nutzen stehen muss (2007, S. 652).

Wiederverwendbarkeit

Aus der losen Kopplung von Services resultiert deren Wiederverwendbarkeit. Wiederverwendung ist die Voraussetzung für Unternehmen, eine einmal entworfene Logik in verschiedenen Anwendungen nutzen und somit die Anfangsinvestitionen wieder amortisieren zu können. Der Schlüssel zu dieser Eigenschaft sind umgebungsneutrale Services, welche als agnostisch bezeichnet werden. Agnostische Dienste realisieren die ihnen zugrundeliegende Logik unabhängig von Geschäftsprozessen, proprietären Technologien und Anwendungsplattformen (Erl 2008, S. 264-273).

Der Unterschied in den Begriffen Wiederverwendbarkeit und Agnostik liegt in der Nutzbarkeit der Dienste. Ist ein Dienst für mehr als einen Geschäftsprozess nutzbar, dann besitzt er zwar das Merkmal der Wiederverwendbarkeit, jedoch nicht unbedingt der Agnostik. Erst wenn eine einschränkungsfreie Nutzbarkeit für alle Geschäftsprozesse gegeben ist, besitzt er agnostische Eigenschaften (Erl 2008, S. 264-273).

Serviceverträge haben dabei einen direkten Einfluss auf das Nutzbarkeitspoten­tial, da sie die gekapselte Logik beschreiben und somit die Einsetzbarkeit eines Dienstes bestimmen. Außerdem spezifizieren sie die möglichen Ein- und Ausgabedaten, wodurch sie wiederum auf die Verwendbarkeit für unterschiedliche Nutzergruppen einwirken (Erl 2008, S. 160).

Roth sieht im Gegensatz zu Erl im Entwurf von agnostischen Services die Gefahr, dass die konzeptionierten Schnittstellen sehr parametrisiert und somit wartungsintensiv sind (2007, S. 90). Hieraus wird deutlich, dass eine universelle Nutzbarkeit von Services nicht allein mit Vorteilen verbunden ist, sondern mögliche Nachteile mit bedacht werden müssen.

Nach Krafzig et al. ist eine Lösung für die aufgeführte Problematik die Zuordnung eines Grades der Wiederverwendbarkeit zu den unterschiedlichen Servicearten. Basis-Services und öffentliche Unternehmens-Services sind ihnen zufolge möglichst generisch zu implementieren. Im Gegensatz dazu ist bei der Erstellung von Zwischen-Services und prozesszentrierten Services der Wiederverwendbarkeit ein geringeres Gewicht beizumessen (Krafzig et al. 2007, S. 87). Dienste auf niedrigerer Ebene besitzen demnach mehr generische Merkmale als höher angesiedelte Services, welche teilweise sehr spezifische Prozesse umsetzen müssen.

Die vorhergehenden Erläuterungen zeigen, dass die Wiederverwendbarkeit eines der Hauptargumente für den Einsatz einer SOA ist. Bei der Umsetzung besteht jedoch die Gefahr, dass das Augenmerk lediglich auf diesen Aspekt fällt und damit die Dienste kaum mehr zu warten sind. Bei der Entwicklung von Services spielt daher die Abstraktionsebene für die anzustrebende Agnostik eine entscheidende Rolle.

Kompositionsfähigkeit

Die Zielstellung einer serviceorientieren Architektur ist die Flexibilisierung von Geschäftsprozessen durch den Einsatz von Services. Die Kompositionsfähigkeit von Services bildet hierfür die Basis, da sie beliebige Verbindungen zwischen den Diensten ermöglicht (Hack 2010, S. 133).

Nach Erl sind sämtliche Services unter dem Gesichtspunkt einer größtmöglichen Kompositionsfähigkeit zu implementieren, damit die Dienste uneingeschränkt miteinander verbunden werden können. Eine Voraussetzung hierfür ist ein flexibler Servicevertrag, welcher unterschiedliche Datenaustauschformate zulässt, wodurch wiederum die Wiederverwendbarkeit der Services deutlich gesteigert wird. Die Kompositionsfähigkeit unterstützt somit die Wiederverwendbarkeit von Diensten und trägt zur Flexibilisierung der Prozesslandschaft bei (Erl 2008, S. 393).

2.7.2.2 Unterstützende Eigenschaften

Die Kernaspekte von Services werden durch mehrere Merkmale unterstützt. Hierzu zählen die

- Abstraktion,
- Autonomie,
- Zustandslosigkeit und
- Auffindbarkeit (Freitag 2009, S. 13-14).

Autonomie

Die durch einen Service bereitgestellte Funktionalität wird von ihm explizit und vollständig innerhalb der für ihn festgelegten Grenzen kontrolliert (Röder 2007, S. 245). Dadurch wird die Autonomie unterstützt und Services können über ihre eigenen Ressourcen selbstständig bestimmen (Erl 2008, S. 301). Die Autonomie kann dabei in unterschiedlichen Ausprägungen auftreten, je nachdem welche Maßstäbe an sie in Bezug auf die zugrundeliegende Funktionalität, Logik und Datenressourcen angewendet werden. Der Servicevertrag stellt die funktionale Autonomie sicher, während die Programmierung für die Eigenständigkeit hinsichtlich der Logik und Datenressourcen verantwortlich ist (Erl 2008, S. 306).

[...]

---

^[1] Eine Balanced Scorecard setzt die Strategie und Ziele eines Unternehmens in vier Perspektiven um: die finanzwirtschaftliche Perspektive, die Kundenperspektive, die interne Prozessperspektive sowie die Lern- und Entwicklungsperspektive. Die Finanzperspektive liefert einen Überblick über die finanziellen Kennzahlen des Unternehmens, während die Kundenperspektive die relevanten Markt- und Kundensegmente von ihm identifiziert. Die Prozessperspektive unterstützt die Organisation bei der Analyse und Optimierung ihrer Prozesse. Der langfristige Erfolg wird durch die Lern- und Entwicklungsperspektive unterstützt, mittels derer die hierfür optimale Infrastruktur gefunden werden kann (Norton und Kaplan 1997, S. 23-27).

^[2] Die in der Originaldarstellung aufgeführten Informationssysteme in der Phase der Prozessimplementierung werden hier nicht aufgeführt, da sie nicht Gegenstand der vorhergehenden Beschreibung sind.

^[3] Die grafischen Elemente wurden verändert übernommen. Des Weiteren wurde die Schreibweise der Begriffe an die Schreibweise innerhalb dieser Arbeit angepasst.