Workflow-Management und Prozessmodellierung für öffentlich-rechtliche Versicherer - Anforderungsdefinition, Realisierungsalternativen und Implementierungsempfehlung

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Wesen und Situation der öffentlichen Versicherer
1.1.1 Wesen eines öffentlichen Versicherers
1.1.2 Derzeitige Situation der öffentlichen Versicherer
1.2 Profil der Lippischen Landes-Brandversicherungsanstalt
1.3 Problemstellung dieser Arbeit
1.4 Zielsetzung dieser Arbeit
1.5 Aufbau der Diplomarbeit

2 Grundlagen
2.1 Geschäftsprozessmanagement
2.1.1 Begriffe des Geschäftsprozessmanagements
2.1.1.1 Geschäftsprozess
2.1.1.2 Business Reengineering
2.1.1.3 Geschäftsprozessoptimierung
2.1.1.4 Business Engineering
2.1.1.5 Geschäftsprozessmodellierung
2.1.1.6 Geschäftsprozessmanagement
2.1.1.7 Geschäftsprozessmanagementsystem
2.1.2 Geschichte der Geschäftsprozessmodellierung
2.1.3 Ansätze für die Geschäftsprozessmodellierung
2.1.3.1 Architektur integrierter Informationssysteme
2.1.3.2 Business-Process-Management Stack der BPMI
2.2 Workflowmanagement
2.2.1 Begriffe des Workflowmanagement
2.2.1.1 Aktivität
2.2.1.2 Workflow
2.2.1.3 Workflowmanagement
2.2.1.4 Workflowmanagement-System
2.2.2 Geschichte des Workflowmanagement
2.2.2.1 Erste Generation – Hard wired applications
2.2.2.2 Zweite Generation – Das explizite Vorgehensmodell
2.2.2.3 Dritte Generation – Einsatz von Datenbanksystemen
2.2.2.4 Vierte Generation – Interoperable Systeme
2.2.3 Abgrenzung des Workflowmanagement
2.2.3.1 Geschäftsprozessmanagements versus Workflowmanagement
2.2.3.2 Workflowmanagement versus Workgroup-Computing
2.2.4 Referenzmodell der Workflowmanagement-Coaliton
2.2.4.1 Kernkomponeten des WfMC-Referenzmodells
2.2.4.2 Weitere Komponenten des WfMC-Referenzmodells
2.2.4.3 Schnittstellen des WfMC-Referenzmodells

3 Anforderungsdefinition
3.1 Funktionale Anforderungen
3.1.1 Modellierung und Simulation von Workflows
3.1.2 Instanzierung und Ausführung von Workflows
3.1.3 Monitoring, Analyse und Administration
3.1.4 Bereitstellung standardisierter Schnittstellen
3.2 Nicht-funktionale Anforderungen

4 Modellierung eines Referenz-Geschäftsprozesses
4.1 Analyse des IST-Zustandes
4.1.1 Prozessablauf
4.1.2 Beteiligte Akteure
4.1.2.1 Mitarbeiter
4.1.2.2 Vorgesetzter
4.1.2.3 Sachbearbeiter der Personalabteilung
4.1.2.4 Mitarbeiter der Hauspost
4.1.3 Zusätzlich benötigte Ressourcen
4.1.3.1 Intranet der LLB
4.1.3.2 Abwesenheitsliste als Excel-Datei
4.1.3.3 Zeiterfassungssystem
4.1.4 Nachrichtenfluss
4.1.5 Verbesserungspotential
4.1.5.1 Medienbrüche im Arbeitsablauf
4.1.5.2 Zeitaufwand
4.1.5.3 Produktivitätssteigerung
4.2 Modellierung des geplanten SOLL-Prozesses
4.2.1 Prozessbeschreibung
4.3 Würdigung des Referenz-Geschäftsprozesses

5 Realisierungsalternativen
5.1 Kommerzielle Angebote
5.1.1 Wesen kommerzieller Angebote
5.1.2 Würdigung kommerzieller Angebote
5.1.2.1 Vorteile kommerzieller Angebote
5.1.2.2 Nachteile kommerzieller Angebote
5.2 Open-Source Projekte
5.2.1 Wesen von Open-Source Projekten
5.2.2 Würdigung von Open-Source Projekten
5.2.2.1 Vorteile von Open-Source Projekten
5.2.2.2 Nachteile von Open-Source Projekten
5.3 Nutzung bestehender Lizenz- und Wartungsverträge
5.3.1 Wesen dieser Nutzung
5.3.2 Würdigung dieser Nutzung
5.3.2.1 Vorteile dieser Nutzung
5.3.2.2 Nachteile dieser Nutzung
5.3.2.3 Beispiel einer möglichen Nutzung bei der LLB
5.4 Eigenentwicklung
5.4.1 Wesen einer Eigenentwicklung
5.4.2 Würdigung einer Eigenentwicklung
5.4.2.1 Vorteile einer Eigenentwicklung
5.4.2.2 Nachteile einer Eigenentwicklung

6 Evaluierungskandidaten
6.1 Verfahren für die Vorauswahl
6.1.1 Vorgehen bei der Nutzwertanalyse
6.1.2 Beurteilung der Nutzwertanalyse
6.2 Kommerzielle Angebote
6.2.1 Ergebnis der Vorauswahl der kommerziellen Angebote
6.2.2 COSA Business Process Management
6.2.2.1 Anbieter
6.2.2.2 Produkt
6.2.3 TIBCO Staffware Process Suite
6.2.3.1 Anbieter
6.2.3.2 Produkt
6.3 Open-Source Projekte
6.3.1 Ergebnis der Vorauswahl der Open-Source Projekte
6.3.2 ObjectWeb Bonita
6.3.2.1 ObjectWeb.org
6.3.2.2 ObjectWeb Bonita
6.4 Nutzung bestehender Lizenz- und Wartungsverträge
6.4.1 Die Business Process Execution Language for Web Services
6.4.2 Konzept der serviceorientierten Architektur
6.4.3 Einführung in den Oracle BPEL Process Manager
6.5 Eigenentwicklung eines WFMS
6.5.1 Lastenheft
6.5.2 Pflichtenheft
6.5.3 Fachkonzept
6.5.4 Systementwurf
6.5.5 Ausblick auf die weiteren Schritte einer Eigenentwicklung

7 Evaluierung der ausgewählten Realisierungsalternativen
7.1 Vorgehensweise bei der Evaluierung
7.1.1 Fachlicher Teil der Evaluierung
7.1.2 Betriebswirtschaftlicher Teil der Evaluierung
7.1.2.1 Kostenschätzung für Personentage
7.1.2.2 Implementierung
7.1.2.3 Migration von Geschäftsprozessen
7.1.2.4 Betriebskosten
7.2 Ergebnisse der Evaluierung
7.2.1 Ergebnis für das ObjectWeb Bonita Projekt
7.2.2 Ergebnis für den Oracle BPEL Process Manager
7.2.3 Ergebnis für die Eigenentwicklung
7.3 Gesamtbeurteilung der Evaluierungsergebnisse
7.3.1 Beurteilung des fachlichen Teils der Evaluierung
7.3.2 Beurteilung des betriebswirtschaftlichen Teils der Evaluierung

8 Schlussbetrachtung
8.1 Implementierungsempfehlung
8.2 Mögliche Vorgehensweise bei der Implementierung
8.3 Fazit

Anhangsverzeichnis

Quellenverzeichnis

Abbildungsverzeichnis

Abbildung 2-1 Standard BPM-Stack

Abbildung 2-2 Terminologieabgrenzung Geschäftsprozess und Workflow

Abbildung 2-3 Referenzmodell der WfMC

Abbildung 2-4 WfMC Meta-Modell

Abbildung 3-1 Relative Kosten für die Korrektur von Anforderungen

Abbildung 4-1 Einsparpotentiale durch WFMS

Abbildung 4-2 Anwendungsfälle beim Urlaubsantrag

Abbildung 4-3 Aktivitäten beim Urlaubsantrag

Abbildung 4-4 Nachrichtenfluss beim Urlaubsantrag

Abbildung 6-1 Aufbau des Oracle BPEL Process Managers

Tabellenverzeichnis

Tabelle 2-1 Gestaltungsebenen des Business Engineering

Tabelle 2-2 Modellierungssichten in ARIS

Tabelle 7-1 Systemkonfiguration des Evaluierungsrechners

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Diese Diplomarbeit beschäftigt sich mit der Geschäftsprozessmodellierung und dem Workflowmanagement für öffentlich-rechtliche Versicherer. Sie analysiert die vorliegenden Anforderungen, evaluiert und bewertet die möglichen Realisierungs­alternativen und gibt eine erste Implementierungsempfehlung. Die Begriffe öffentlich-rechtlicher Versicherer und öffentlicher Versicherer werden in der Praxis wie auch in dieser Diplomarbeit simultan verwendet.

1.1 Wesen und Situation der öffentlichen Versicherer

1.1.1 Wesen eines öffentlichen Versicherers

Ein öffentlicher Versicherer ist dadurch gekennzeichnet, dass seine Tätigkeiten regional begrenzt sind. Regionalität verbunden mit detaillierten Kenntnissen der lokalen Marktstruktur stellen eine der wichtigen Stärken dar. Regionalität bedeutet vor allem auch einen guten Zugang zu den Menschen und Machern vor Ort. Die hiermit verbundenen Kontakte eröffnen den öffentlichen Versicherern eine Wissens- und Informationsbasis, die den Global Playern der Versicherungs­branche nur bedingt zugänglich sind. Die Wurzeln dieser Versicherer liegen oft in der Feuerversicherung oder dem Lebensversicherungsbereich. Träger der öffentlichen Versicherungen sind in aller Regel die regionalen Sparkassen- und Giroverbände sowie Sparkassen und Landesbanken. Trotz der regionalen Orientie­rung und Beschränkung sind die öffentlichen Versicherer nach der Allianz die zweitstärkste Kraft im deutschen Versicherungsmarkt.^[2]

Die 13 öffentlichen Versicherer in Deutschland sind regional tätig und arbeiten als Gruppe eng zusammen. Im Verband öffentlicher Versicherer (VöV), einer gemein­nützigen Körperschaft des öffentlichen Rechts mit Sitz in Düsseldorf, haben sich die rechtlich selbständigen Unternehmen überregional organisiert. Als zentrale Dachorganisation hat der Verband wichtige Aufgaben. In ihm werden die gemein­samen Aktivitäten der Mitgliedsunternehmen zusammengeführt und gebündelt zur Geltung gebracht. Der Verband ist Berufsverband und Dienstleister, zugleich aber auch Rückversicherer seiner Mitglieder.

Der Verband wurde 1911 gegründet und verlegte 1949 seinen Hauptsitz nach Düsseldorf. 1963 erfolgte eine Umfirmierung des bisherigen Verbands öffentlicher Lebensversicherungsanstalten in Deutschland zum Verband öffentlicher Lebens- und Haftpflichtversicherer. Ab dem 1. Januar 1963 nahm der Verband auch das Rückversicherungsgeschäft in den Bereichen der allgemeinen Haftpflicht, Unfall­versicherung und der Kraftfahrzeugversicherung auf. Dadurch ersetzte der Verband den bisher tätigen Verband öffentlicher Unfall- und Haftpflichtversiche­rungsanstalten in Deutschland. Dieser Verband löste sich zum 31.12.1965 auf und übertrug sein Vermögen an den neuen Verband. Am 1. Januar 1996 übernahm der Verband die öffentlichen Feuer­versicherer und firmiert seitdem als Verband öffentlicher Versicherer. Seine Mitglieder decken mit ihren Leistungen und Produkten die gesamte Bandbreite an aktuellen Versicherungsprodukten ab. Zur Sicherung ihrer regionalen Selbständigkeit und zur Komplettierung des Angebotes und der Serviceleistungen haben die öffentlichen Versicherer gemeinsam Tochterunternehmen gegründet, die für die Gruppe tätig sind. Diese Tochterunternehmen bieten den einzelnen öffentlichen Versicherern versicherungstechnische als auch logistische Dienstleistungen an, mit deren Hilfe jeder öffentliche Versicherer für sich sein Angebotsportfolio komplettieren kann.

1.1.2 Derzeitige Situation der öffentlichen Versicherer

Durch die steigende Transparenz der Versicherungsmärkte und dem Wandel von einem Verkäufer- zum Käufermarkt Sehen sich auch die öffentlichen Versicherer vor der Herausforderung in diesem veränderten Marktumfeld erfolgreich zu sein. Mit einem Marktanteil von 10,8 Prozent sind die öffentlichen Versicherer die zweitstärkste Kraft im deutschen Versicherungsmarkt.^[3] Sowohl der Verband der öffentlichen Versicherer als auch die einzelnen öffentlichen Versicherer sind bestrebt, ihre Kräfte zu bündeln. Dies geschieht bereits durch die gemeinsamen Versicherungsunternehmen und Dienstleistungsunternehmen des Verbandes. Darüber hinaus schreitet die Konsolidierung im Lager der öffentlichen Versicherer auch in Zukunft weiter voran. Durch die Bildung gemeinsamer Holdings in den Bereichen Lebensversicherung, IT und Asset Management sollen Skaleneffekte im Back-Office genutzt werden und dabei trotzdem die Nähe zum Kunden bewahrt werden. Im Geschäftsjahr 2004 stellten sich die Lebensversicherungen als wichtiger Wachstumsträger heraus. Insgesamt ist das vergangene Geschäftsjahr trotz der schwierigen Rahmenbedingungen wie einer weiterhin pessimistischen gesamtwirtschaftlichen Stimmung und anhaltender Niedrigzinslage auf den Kapitalmärkten sehr erfolgreich verlaufen. Zum ersten Mal durchbrachen die öffentlichen Versicherer die 16 Milliarden-Euro-Marke bei den Bruttobeitragsein­nahmen. Auf dem Markt konnten sie ihre Position als zweit­größte Kraft hinter der Allianz behaupten.

Trotz einer ungebrochenen Nachfrage nach privater Altersvorsorge und dem steigenden Bedürfnis nach Sicherheit und Absicherung müssen auch die öffentlichen Versicherer versuchen, die Kostenseite zu optimieren. Der bereits eingeschlagene Weg, Synergieeffekte konsequent zu nutzen, wird sich in Zukunft noch verstärken. In einem Bereich, in dem Serviceorientierung und Kundenzufriedenheit wichtige Voraussetzungen für den Erfolg sind, kann es nur sinnvoll sein, die internen Abläufe der öffentlichen Versicherer zu betrachten, um hier verborgenes Potenzial erkennen und nutzen zu können.

1.2 Profil der Lippischen Landes-Brandversicherungsanstalt

Die Lippische Landes-Brandversicherungsanstalt (LLB) wurde 1752 gegründet und ist unter den öffentlich-rechtlichen Versicherungseinrichtungen Deutschlands eine der Ältesten. Bis 1925 durfte die LLB ausschließlich Brandschäden versichern und hielt bis 1994 in dieser Versicherungssparte das Monopol im Kreis Lippe. Ab 1925 trat die LLB auch als Kompositversicherer^[4] auf, d.h. sie bot nun auch weitere Versi­cherungssparten aktiv an. Das Geschäftsgebiet der LLB umfasst den Kreis Lippe mit über 360.000 Einwohnern^[5]. Derzeit betreibt die LLB in ihrem Geschäftsgebiet hauptsächlich folgende Versicherungszweige und -sparten:

- Feuer-Versicherung
- Einbruchdiebstahl-Versicherung
- Leitungswasser-Versicherung
- Glas-Versicherung
- Sturm-Versicherung
- Hausrat-Versicherung
- Wohngebäude-Versicherung
- Technische Versicherungen
- Transport-Versicherung
- Kraftfahrt-Versicherung
- Allgemeine Unfallversicherung
- Allgemeine Haftpflichtversicherung

Außerdem schließt die LLB Lebensversicherungen für die Westfälische Provinzial ab und vermittelt Rechtsschutz- und Krankenversicherungen.^[6]

Das ursprüngliche Kerngeschäft, die Gebäude-Feuer-Versicherung, stellt heute nur noch einen Anteil von weniger als 18% des Beitragsvolumens dar.^[7] 1948 übernahm der Landesverband Lippe die Verwaltung der LLB. Der Landesverband Lippe hat die Kernaufgabe „ außer der Deckung seiner eigenen Verwaltungskosten und der Bildung der erforderlichen Rücklagen die kulturellen Belange und die Wohlfahrt der Bevölkerung im Bezirk des ehemaligen Landes Lippe im Rahmen seiner Leistungsfä­higkeit [...] zu fördern. “^[8]

Die LLB arbeitet somit nicht primär profitorientiert. Sie schüttet Über­schüsse, die nicht den Rücklagen zufließen müssen, in Form von Beitragssenkungen wieder an die Versicherungsnehmer aus. Diese Arbeitsweise ist historisch bedingt, da die LLB in all ihren Aufgabengebieten „ le­diglich zum gemeinen Nutzen unter Ausschluss von Erwerbszwecken tätig sein “^[9] darf. Die LLB ist an der Deutschen Rückversicherungs-AG, Hamburg und dem als Rückver­sicherung tätigen Verband öffentlicher Versicherer, Düsseldorf beteiligt. Die LLB unterhält sechs Tochtergesellschaften, die in verschiedenen Geschäftsbereichen tätig sind:

- Mediawerkstatt GmbH
- Versicherungs- Vermittlungs GmbH (VVG)
- Hillgraf GmbH (Firmenkundenmakler)
- Informatik- und Consulting GmbH (ICL)
- Lippische Vermögensverwaltung- und Service GmbH (LVS GmbH)
- Lippische Pensionsfonds AG

2004 waren bei der LLB 456 Mitarbeiter und 13 Auszubildende beschäftigt. Der Kapitalanlagebestand lag bei 170,3 Millionen Euro^[10] und der Bestand von 510.000 Verträgen brachte Bruttobeitragseinnahmen in Höhe von 93 Millionen Euro^[11].

1.3 Problemstellung dieser Arbeit

Vergleicht man die öffentlichen Versicherer mit anderen Versicherungen wie beispielsweise der Allianz wird deutlich, dass sich ein Vorteil bei einer anderen Betrachtungsweise auch als Nachteil auswirken kann. Die Konzentration auf eine bestimmte Region führt dazu, dass ein einzelner öffentlicher Versicherer sich in seinem Markt einem wesentlich größeren Konkurrenten gegenüber sieht. Zwar wird diese Situation zu großen Teilen durch den VöV und seinen Leistungen ausgeglichen, trotzdem ist es für einen öffentlichen Versicherer lebenswichtig, konkurrenzfähig zu sein. Die regionale Begrenzung macht es unmöglich, seine Zukunft durch Expansion zu sichern. Wäre dies möglich, würden einzelne öffentliche Versicherer gegenseitig um Marktanteile konkurrieren. Daher muss die Orientierung auf dem gegebenen Markt liegen. Hierbei kommt den öffentlichen Versicherern die Nähe zur Region, den Menschen und Machern zu Gute. Genauso wichtig ist es in Zeiten von E-Business und Internet aber auch, ein reizvolles Onlineangebot machen zu können. Die angebotenen Leistungen müssen zu einem günstigen Preis angeboten werden können, ohne dass ein überzogener Preiskampf Reserven des Unternehmens aufzehrt.

Somit ist es notwendig, die betrieblichen Prozesse und Abläufe kontinuierlich auf den Prüfstand zu stellen, Potentiale zu erkennen und die darin enthaltenen Möglichkeiten zu nutzen.

1.4 Zielsetzung dieser Arbeit

Aufbauend auf der Anforderungsdefinition sollte ein öffentlicher Versicherer in seiner Region die folgenden Ziele anstreben:

- Erhöhung des Marktanteils
- Marktführerschaft auf dem regionalen Markt
- Hohe Kundenzufriedenheit sicherstellen
- Schlanke Strukturen im Unternehmen
- Effiziente Prozessabwicklung
- Konsequente Kostenkontrolle
- Kontinuierliche Kontrolle, Bewertung und Neuausrichtung der Prozesse

Diese Diplomarbeit wird sich auf Grund der Ausrichtung auf den Bereich Wirtschaftsinformatik nicht mit allen Zielen eingehend auseinandersetzen. Schwerpunkt wird die Prozessmodellierung bei öffentlichen Versicherern sowie deren effiziente Einbindung in das Unternehmen sein.

Zu diesem Zweck wird das Konzept des Workflowmanagement und dessen Realisierung in Form eines Workflowmanagement-Systems auf einen öffentlichen Versicherer angewendet. Es wird bewertet, wie hoch der geschätzte Aufwand ist und welche Potentiale zur Kostenersparnis sich bieten und wie sich diese nutzen lassen.

1.5 Aufbau der Diplomarbeit

Von der Struktur her wird sich diese Diplomarbeit zunächst mit den Begriffen der Geschäftsprozessmodellierung, des Workflows und des Workflowmanagements beschäftigen. Nachdem das Wesen dieser Konzepte definiert ist, werden Anforderungen an ein solches Konzept und dessen Implementierung erarbeitet. Hierbei werden zum einen allgemein gültige Anforderungen erhoben und zum anderen Anforderungen erhoben, die spezifisch für einen öffentlichen Versicherer sind. Für die Praxisnähe wird die LLB in dieser Diplomarbeit der öffentliche Versicherer der Wahl sein. Sollten sich bei der Erhebung der Anforderungen zeigen, dass die LLB in einigen Bereichen Eigenheiten zeigt, wird dies explizit kenntlich gemacht.

Auf Basis der Anforderungen wird nach möglichen Realisierungsalternativen gesucht. Dabei können grob vier Kategorien unterschieden werden. Zum einen gibt es am Markt kommerzielle Lösungen für das Feld des Workflowmanagement. Darüber hinaus gibt es Lösungen, die als „Open-Source“ gelten. Als dritte Alternative kommt eine umfassendere Nutzung bestehender Lizenzverträge in Frage. Die vierte Möglichkeit ist die Realisierung einer eigenen Lösung. Für die Evaluierung dieser vier Kategorien wird basierend auf den Anforderungen ein exemplarischer Geschäftsprozess modelliert, an dem sich die Realisierungsmöglichkeiten messen lassen müssen. Bei der Eigenentwicklung wird im Vorfeld ein Konzept aufgestellt und der Aufwand abgeschätzt.

Nachdem jede mögliche Realisierungsalternative vorgestellt, evaluiert und bewertet wurde, erfolgt eine abschließende Beurteilung der Ergebnisse unter betriebswirtschaftlichen Gesichtspunkten. Aufbauend auf diese Beurteilung wird eine Implementierungsempfehlung ausgesprochen. Ein kritisches Fazit samt Ausblick schließt die Diplomarbeit ab.

2 Grundlagen

2.1 Geschäftsprozessmanagement

In dieser Diplomarbeit nehmen Geschäftsprozesse eine wichtige Position ein. In diesem Kapitel werden die Grundlagen im Zusammenhang von Geschäftsprozes­sen, deren Modellierung und dem Management von Geschäftsprozessen genauer betrachtet. Neben der Definition der wichtigsten Begriffe werden die Geschichte der Geschäftsprozesse und deren betriebswirtschaftlicher Hintergrund beleuchtet. Anschließend erfolgt eine eingehendere Vorstellung von möglichen Ansätzen für die Geschäftsprozessmodellierung.

2.1.1 Begriffe des Geschäftsprozessmanagements

2.1.1.1 Geschäftsprozess

In der Betriebswirtschaftslehre versteht man unter einem Geschäftsprozess (Business Process, BP) einen Vorgang, der in einer Wirtschaftseinheit einen wesentlichen Beitrag zum Unternehmenserfolg leistet. Hierbei muss der Unternehmenserfolg nicht zwingend ökonomischer Natur sein. Der Geschäftsprozess ist in der Regel auf einen Kunden ausgerichtet. Hierbei erstreckt sich der Ablauf eines Geschäftsprozesses in der Regel über Funktionen, Standorte und Hierarchien hinweg und kann auch die Unternehmensgrenzen überschreiten. Dabei erzeugt er einen messbaren und direkten Nutzen für den Kunden.^[12] Von der Struktur her sind Kernprozesse den Geschäftsprozessen sehr ähnlich. Allerdings sind Kernprozesse in der Regel nicht zwingend auf externe Kunden ausgerichtet. Sie befassen sich mehr mit internen, administrativen Abläufen im Unternehmen. So trägt zum Beispiel die Urlaubsabwicklung in einem Unternehmen nicht zum Unternehmenserfolg bei und ist auf keinen externen Kunden ausgerichtet. In dieser Diplomarbeit werden Kernprozesse und Geschäftsprozesse gleichbehandelt.

Die Ansätze des Geschäftsprozessorientierten Denkens lassen sich je nach Standpunkt entweder in den 30er Jahren des letzen Jahrhunderts finden. So ist in Büchern von F. Nordsieck^[13] über die betriebliche Organisation die Rede von Geschäftsprozessen. Von dem konträren Standpunkt Oestereichs aus reichen die Wurzeln des Geschäftsprozess sogar bis in das 18. Jahrhundert zurück. Dabei sieht Oestereich bei den Werken von Frederick Winslow Taylor^[14] und Adam Smith^[15] die Wurzeln des prozessorientierten Denkens. Allerdings sprechen sowohl Smith als auch Taylor primär von der Aufteilung in einzelne Arbeitschritte und nicht von einer ganzheitlichen Betrachtung eines Geschäftsprozess und seinem Nutzen für den Unternehmenserfolg.

Der Begriff der Geschäftsprozesse ist auch in der Informatik zu finden. Beispielsweise lässt er sich an vielen wichtigen Punkten in der Architektur integrierter Informationssystem (ARIS) von August-Wilhelm Scheer finden. Mit der ARIS hat Scheer die Entwicklung der Geschäftsprozesse in Deutschland intensiv geprägt und vorangetrieben.

Der Begriff des Geschäftsprozess lässt sich nicht isoliert betrachten. Er ist mit vielen betriebswirtschaftlichen Strategien und auch in Konzepte der Informations­technologie (IT) verbunden. So sehen Business Reengineering und Geschäftspro­zessoptimierung den Geschäftsprozess als Möglichkeit, Verbesserungen in den Bereichen Kosten, Qualität, Service und Zeit zu erreichen^[16]. Diese beiden Konzepte des Qualitätsmanagements gehen dabei allerdings unterschiedliche Wege.

2.1.1.2 Business Reengineering

Michael Hammer und James Champy haben Mitte der 90er Jahre mit ihren Arbeiten und Büchern die Idee des Business Reengineering geschaffen. Derzeit wird das Konzept des Business Reengineering (BR) gleichbedeutend mit dem Konzept des Business Process Reengineering (BPR) verwendet. Das Konzept besteht aus einem Managementansatz, der eine vollständige Unternehmensum­strukturierung propagiert. Gekennzeichnet ist die Umstrukturierung durch die Schlagworte fundamental, radikal und dramatisch. Damit wird zum einen die Frage nach dem Sinn und Zweck jeder Tätigkeit in einer Unternehmung gestellt und wie diese Tätigkeit durchgeführt wird (fundamental)^[17]. Mit „radikal“ wird die Tatsache beschrieben, dass es beim BPR nicht um eine Optimierung der bestehenden Geschäftsabläufe geht, sondern um ein vollständiges Umdenken der Strukturen und um einen kompletten Neubeginn. Das Schlüsselwort „dramatisch“ beschreibt die Forderung nach einer Effizienzsteigerung in Quantensprüngen. Dabei weisen Hammer und Champy der Informationstechnologie eine wichtige Rolle bei der Erfüllung dieser Aufgaben zu. Der ursprüngliche Ansatz wurde im Laufe der Zeit weiterentwickelt. Im deutschsprachigen Raum ist der Ansatz insbesondere von Österle und Scheer aufgegriffen und weiterentwickelt worden. Business Reengineering ist ein Konzept, das durch seine radikale Ausrichtung große Chancen bietet, aber gleichzeitig hohe Risiken in sich birgt.^[18]

2.1.1.3 Geschäftsprozessoptimierung

Die Geschäftsprozessoptimierung (Business Process Improvement, BPI) greift ebenfalls die grundlegende Idee der Restrukturierung auf. Fälschlicherweise wird der Begriff häufig simultan mit dem zuvor genannten Business Reengineering genannt. Ziel der Geschäftsprozessoptimierung ist die konsequente Ausrichtung der Arbeitsabläufe im Unternehmen auf die Kundenanforderungen. Hierdurch wird die Wettbewerbsfähigkeit nachhaltig verbessert. Ein besonderes Augenmerk wird auf Arbeitsabläufe gelegt, die direkt durch eine Kundenreaktion ausgelöst werden. Aber auch in allen anderen Bereichen eines Unternehmens kann das Potential der Geschäftsprozessoptimierung genutzt werden.

Verglichen mit dem Business Reengineering setzt die Geschäftsprozessoptimierung auf Prozessanalyse, kontinuierliche Verbesserung der bestehenden Organisation und eine moderate Veränderung in kleinen Schritten. Dabei liefert die Analyse eine detaillierte Beschreibung, aus der sich mögliche Fehler und Probleme ablesen lassen. Die Geschäftsprozessoptimierung stellt danach die Frage nach den möglichen Gründen für die Fehler und Probleme und versucht anschließend, diese zu beheben.

Dieses Konzept zielt auf inkrementelle Veränderungen in überschaubaren Schritten und reduziert dadurch das Risiko, durch zu schnelle, radikale Veränderungen das Unternehmen zu schädigen. Auf betriebswirtschaftlicher Seite gibt es eine ganze Fülle von Konzepten, die sich mit der Verbesserung von Prozessen befassen. Einige der wohl prominentesten und auch am weitesten in der Wirtschaft verbreiteten Konzepte sind das Total Quality Management (TQM), der Kontinuierliche Verbesserungsprozess (KVP) oder Kaizen^[19].

2.1.1.4 Business Engineering

Unter Business Engineering versteht man den ganzheitlichen, systematischen Ansatz für die Entwicklung von sozio-technischen Geschäftslösungen im Kontext der Transformation von Unternehmen. Es handelt sich bei diesem Ansatz um einen ingenieurwissenschaftlichen Ansatz, was durch den Begriff des Engineering (engl. Ingenieurwesen) deutlich wird. Außerdem kommt dem Einsatz von Modellen und Methoden eine besondere Bedeutung zu. Business Engineering wird somit als Konstruktionslehre verstanden.^[20]

Auf der Ebene von Geschäftsprozessen, explizit bei deren Gestaltung, fungiert das Business Engineering als Verbindung zwischen Unternehmensstrategie und Informationssystemen / -techniken.

Beispielsweise trennt Österle den Übergang von der Neugestaltung des Unter­nehmens zur Weiterentwicklung der unterstützenden Informationstechnologie in vier unterschiedliche Ebenen. Dabei gründet sich eine Neugestaltung auf die Ebenen Geschäftsmodell, Geschäftsprozesse, Anwendungen und Anwendungsbau­steine.^[21]

Abbildung in dieser Leseprobe nicht enthalten^[22]

Tabelle 2-1 Gestaltungsebenen des Business Engineering^[23]

Die Ebenen eins und zwei sind der Gestaltung der Geschäftstätigkeit und den damit verbundenen Geschäftsprozessen zuzuordnen. Sie orientieren sich wie alle anderen Ebenen an der Unternehmensstrategie. Anders als die Ebenen drei und vier beziehen sich die oberen Ebenen auf betriebswirtschaftliche Konzepte. Der Gestaltung der Informationstechnologie sind die verbleibenden Ebenen drei und vier zuzuordnen. Auf jeder der vier Ebenen sind Geschäftsentscheidungen zu treffen, diese sind voneinander abhängig und müssen sich daher zwingend an der Unternehmensstrategie orientieren. Zwischen der Gestaltung auf betriebswirtschaftlicher bzw. fachlicher Ebene und der Gestaltung auf der informationstechnologischen Ebene findet eine enge bidirektionale Abstimmung statt. Wichtige Bestandteile dieser Abstimmung sind die Einigung über Ziele, Budgets und Anforderungen sowie die Klärung von möglichen Restriktionen und ein reger Inspirationsprozess.^[24] Durch das Business Engineering wird versucht, neue Herausforderungen und die damit einhergehenden Veränderungsprozesse besser zu bewältigen. Mittels Konvergenz zwischen der strategischen Geschäftsausrichtung und der Informationstechnologie soll dies ermöglicht werden.^[25]

2.1.1.5 Geschäftsprozessmodellierung

Bei der Definition des Begriffes der Geschäftsprozessmodellierung ist es wichtig, dass man sich der uneinheitlichen Definition des Begriffes des Geschäftsprozesses bewusst ist. Wie bereits beschrieben, ist die Definition eines Geschäftsprozesses vom jeweiligen Standpunkt abhängig. Eine Möglichkeit die Modellierung von Geschäftsprozessen zu definieren ist folgende:

„Die geschäftsprozessorientierte Modellbildung geht von den existierenden Geschäftsprozessen aus und versucht quer durch alle betrieblichen Funktionsbereiche alle relevanten Aspekte von aufeinander folgenden Aktivitäten (Geschäftsvorgänge) darzustellen. Des Weiteren berücksichtig sie die Aufgabenträger, die in die Ausführung der Geschäftsprozesse involviert sind und setzt ihren Schwerpunkt auf die Erneuerung (Reorganisation) bestehender Prozesse.“^[26]

Die Geschäftsprozessmodellierung orientiert sich an den in der Praxis etablierten Vorgehensweisen für die Modellierung. Logisch fügt sich die Geschäftsprozessmodellierung in den Bereich des Geschäftsprozessmanagement ein. Für die konkrete Modellierung von Geschäftsprozessen gibt es eine breite Palette von möglichen Verfahren sowie deren Unterstützung und Umsetzung in Form von Werkzeugen. Für eine mathematisch fundierte Darstellung von Geschäftsprozessen hat sich einzig und allein die Modellierung durch Petri-Netze^[27] erwiesen. Die Theorien der Petri-Netze verlangt allerdings äußerst umfangreiches Hintergrundwissen und wird in der Praxis nur selten angewendet. In der betrieblichen Praxis finden Verfahren wie beispielsweise ARIS oder der Business-Process-Management Stack^[28] der BPMG Anwendung. Diese beiden Ansätze werden an späterer Stelle in dieser Diplomarbeit eingehend vorgestellt.

2.1.1.6 Geschäftsprozessmanagement

Unter Geschäftsprozessmanagement (Business Process Management, BPM) versteht man ein Managementkonzept, welches sich im Wesentlichen mit der Automatisierung und Optimierung von Geschäftsprozessen beschäftigt.^[29] Ebenfalls mit dem Geschäftsprozessmanagement verbunden ist dessen Fortführung in Form von Geschäftsprozessmanagementsystemen. Das BPM gliedert sich für die Zielerreichung in drei Blö>2.1.1.7 Geschäftsprozessmanagementsystem

Im Kern sind Geschäftsprozessmanagementsysteme (Business Process Management System, BPMS) Systeme zur Prozesssteuerung, die um Komponenten zur Prozessmodellierung und zum Prozesscontrolling erweitert wurden. Ziel ist es, eine schnelle, flexible und ganzheitliche Anpassung von Prozessen auf sich ändernde Rahmenbedingungen mittels IT-Unterstützung zu ermöglichen. Technische Bausteine moderner BPMS sind EAI^[30] - und Workflowmanagement-Systeme für die Prozesssteuerung und -automatisierung, Modellierungswerkzeuge für Analyse und Design von Prozessen und Elementen von Business-Intelligence-Lösungen zur Ermittlung operativer Kennzahlen und zur Umsetzung von Performancemessungen.^[31] Derzeit sind BPMS eher als Kombination verschiedener Werkzeuge anzutreffen, statt als integriertes System, das die Gesamtheit aller Funktionalitäten umfasst.

2.1.2 Geschichte der Geschäftsprozessmodellierung

Die Geschichte der Geschäftsprozessmodellierung ist eng mit der Entstehung des Geschäftsprozessmanagements verbunden. Die Motivation ist hierbei nicht neu. Unternehmen haben schon lange den Wunsch, ihre Geschäftsprozesse adäquat managen zu können. Unabhängig davon, welcher Managementansatz verwendet wird, ist stets der Wunsch vorhanden, die Geschäftsprozess ohne Abhängigkeiten und Restriktionen der IT-Struktur verwalten zu können.

Die Bestrebungen im Bereich der Geschäftsprozesse lassen sich bis auf die Idee des Taylorismus von Frederick Winslow Taylor aus dem Jahr 1882 zurückführen. Taylor fasste Arbeitsabläufe als Machtkampf zwischen Management und Arbeitern auf, der von den Arbeitern gewonnen werde, solange sie nur ihre Arbeit beherrschen. Um eine Umverteilung der Machtverhältnisse – zugunsten des Managements – bewirken zu können, definierte Taylor drei grundlegende Prinzipien. Diese haben die Aussage, dass Arbeit auf präzisen Anleitungen des Managements basiert. Solche präzisen Anleitungen können nur dann gegeben werden, wenn die einzelnen Arbeitsschritte klein und übersichtlich sind. Außerdem muss Geld als wichtiger Motivationsfaktor wirken und auch als solcher eingesetzt wird. Wichtig für die Geschäftsprozessmodellierung ist beim Taylorismus die Bestrebung, Arbeitsabläufe zu beschreiben.

Bei der weiteren Entwicklung des Geschäftsprozessmanagements, welches die Geschäftsprozessmodellierung als Untermenge beinhaltet, zeigt die Literatur ein Wellenmuster auf, das die Entwicklung in drei große Wellen aufteilt. Derzeit bewegt sich das Geschäftsprozessmanagement in der dritten Welle dieser Entwicklung.

Die erste Welle umfasst die ersten Ansätze, die beim Taylorismus zu finden sind. Neben diesen Ansätzen wurden in den 1920er Jahren Methoden und Prozeduren für die Analyse von Arbeitsabläufen und Prozessen im Unternehmen entwickelt und eingesetzt. Die Automatisierung von Prozessen war in ihrem Umfang noch weitestgehend begrenzt. Die Einführung von Mechanismen und Konzepten des Qualitätsmanagements wie beispielsweise dem TQM in den 1980er Jahren und die zunehmende Bedeutung von Datenbankmanagementsystem (DBMS) in den 1970-90er Jahren zeichnen diese Welle der Entwicklung ebenfalls aus. Der Übergang zwischen erster und zweiter Welle lässt sich nicht exakt auf einen Zeitpunkt festlegen. Er wird in der Zeit der späten 1980er und der frühen 1990er gesehen. Zeitlich umfasste die zweite Welle der Entwicklung einen Zeitraum von zehn Jahren, bevor sie durch die dritte Welle der Entwicklung Anfang der 2000er abgelöst wurde.

Die zweite Welle ist durch drei wesentliche Neuerungen gekennzeichnet. Zum einen der betriebswirtschaftliche Ansatz von Michael Hammer und James Champy zum Reengineering als radikalen neuen Managementansatz. Des Weiteren entstand mit dem Enterprise Resource Planning (ERP) ein weiteres Managementkonzept, das sich mit der Aufgabe befasst, die vorhanden Ressourcen eines Unternehmen wie Beispielsweise Kapital, Personal oder Betriebsmittel möglichst effizient in die Arbeitsabläufe einzuplanen. Seitens der IT wurde das ERP mit entsprechender Software unterstützt. Ein äußerst bekannter Anbieter von ERP-Software war und ist SAP mit dem SAP R/3. Die dritte wesentliche Neuerung war auf der IT-Seite zu beobachten. Hier haben sich die Ansätze der verteilten Rechner und der verteilten Anwendungen etabliert. In der zweiten Welle stieg das Maß der IT-Unterstützung erheblich an.

Die derzeit dritte Welle der Entwicklung begann Anfang der 2000er und beschäftigt sich mit der Umsetzung des Prozessgedankens in der IT. Die Fokussierung auf Geschäftsprozesse und die Ausrichtung des Geschäftsprozessmanagements auf den gesamten Lebenszyklus der Geschäftsprozesse führte zur Entwicklung von Business Process Management Systemen (BPMS) deren Funktionalitäten eine ganzheitliche Betrachtung und Betreuung der Geschäftsprozesse ermöglicht.

2.1.3 Ansätze für die Geschäftsprozessmodellierung

Bei der Begriffsdefinition im Bereich der Geschäftsprozesse und deren Modellierung fällt auf, dass die Geschäftsprozessmodellierung eine Untermenge des Geschäftsprozessmanagements ist. Dieser Tatsache wird Rechnung getragen, in dem die beiden nachfolgenden Ansätze für die Geschäftsprozessmodellierung sich nicht ausschließlich mit der Modellierung beschäftigen, sondern darüber hinaus das ganze Spektrum des Geschäftsprozessmanagements involvieren. Es erfolgt nun eine genaue Betrachtung der Architektur integrierter Informationssystem (ARIS) und des Business-Process-Management Stack der BPMI.

2.1.3.1 Architektur integrierter Informationssysteme

Für die ganzheitliche Beschreibung eines Informationssystems unterteilt die Architektur integrierter Informationssystem, kurz ARIS, das Informationssystem in die Beschreibungssichten Daten-, Steuerungs-, Funktions-, Organisations- und Leistungssicht ein. Darüber hinaus gliedert sich jede Beschreibungssicht in die Beschreibungsebenen Fachkonzept, DV-Konzept und Implementierung. Diese Einteilung nimmt Bezug auf die Nähe zur Informationstechnik der jeweiligen Beschreibungssicht. Visualisiert man diese Aufteilungen, ergibt sich eine Grafik, die in der Literatur als das ARIS-Haus bekannt ist.^[32] Jede Beschreibungssicht stellt das Modell eines Geschäftsprozesses aus einem ganz bestimmten Blickwinkel dar. Die zentrale Sicht ist hierbei die Steuerungssicht. Die restlichen vier Sichten bilden die vier sekundären Sichten.

Abbildung in dieser Leseprobe nicht enthalten^[33]

Tabelle 2-2 Modellierungssichten in ARIS^[34]

Die weitergehende Dreiteilung der einzelnen Sichten in Fachkonzept, Datenverarbeitungskonzept und Implementierungsebene bewirkt eine sinnvolle Trennung von fachlichen und technischen Aspekten. Im Fachkonzept geschieht die Modellierung über DV-fremde Beschreibungsmodelle. Das Datenverarbeitungskonzept sieht eine Modellierung in DV-nahen Beschreibungsmodellen vor und die Implementierungsebene beschreibt die konkrete DV-technische Umsetzung der einzelnen Prozessteile.

Bezogen auf Software-Werkzeuge ist das ARIS-Toolset der Firma IDS Scheer AG einer der bekanntesten Vertreter. Seit 2004 unterstützt dieses Werkzeug auch Standards wie BPMN, BPML und BPEL.

2.1.3.2 Business-Process-Management Stack der BPMI

Der Business-Process-Management Stack ist ein Konzept der Business Process Management Initiative. Sie selbst definiert sich wie folgt:

„BPMI.org (the Business Process Management Initiative) is a non-profit corporation that aims to empower companies of all sizes, across all industries, to develop and operate business processes that span multiple applications and business partners, behind the firewall and over the internet.^[35] “

Die von der BPMI verfolgte Mission, jedes beliebige Unternehmen zu befähigen, Geschäftsprozesse über mehrere Applikationen und Geschäftspartner hinaus einfach entwickeln und betreiben zu können, äußert sich im Kernziel der Organisation. Zielsetzung ist die Entwicklung und Förderung von offenen, vollständigen und lizenzfreien Standards basierend auf XML^[36], die das Geschäftsprozessmanagement in der Wirtschaft ermöglichen und unterstützen. Die BPMI wurde im August 2000 gegründet und besteht derzeit aus über 45 Mitgliedsunternehmen, darunter Firmen wie Adobe, IDS-Scheer, Oracle oder SAP. Ihrerseits ist die BPMI Mitglied der OMG^[37] und der WfMC^[38]. Darüber hinaus ist sie Mitglied der OASIS^[39]. Seit Mai 2005 gibt es Überlegungen einer Fusion der BPMI und der WfMC. In Bereichen mit fehlenden Standards versucht die BPMI, solche Standards zu entwickeln und den kompletten Lebenszyklus des Geschäftsprozessmanagement - vom Prozessdesign, deren Umsetzung, Ausführung, Wartung und Optimierung - zu unterstützen. Bei ihrer Arbeit sieht die BPMI die Geschäftsprozesse als Nahtstelle zwischen Geschäftsumgebung und Technologieimplementierung. Sie zielt darauf ab, einen nahtlosen Übergang der beiden zuvor genannten Bereiche zu ermöglichen und ein interdisziplinäres Verständnis von Geschäftsprozessen zu schaffen. Die Zielgruppe der BPMI erstreckt sich vom Strategieberater, über Analysten, Prozessdesigner, Systemarchitekten bis hin zu Softwareentwicklern über weite Bereiche eines Unternehmens. Dabei deckt sie von der Modellierung bis zur Ausführung alle beteiligten Gruppen ab. Im Business Process Management Stack lässt sich diese Zielgruppenausrichtung ebenfalls erkennen. Dieser Stack arbeitet sich von der graphischen Modellierung, über das semantische Modell hin zur Ausführung von Geschäftsprozessen. Dabei lehnen sich die einzelnen Standards der BPMI in Teilbereichen an ähnliche Standards der OMG an. Im Bereich der Ausführung können wiederum verschiedene Standards zum Einsatz kommen. Abbildung 2-1 veranschaulicht die einzelnen Schichten des Stack.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1 Standard BPM-Stack^[40]

Nach Ansicht der BPMI besteht ein Geschäftsprozess zwischen zwei Geschäftspartnern aus drei Teilen, einem öffentlichen Interface und zwei privaten Implementierungen. Das öffentliche Interface ist beiden Partnern gemein und wird durch Protokolle unterstützt. Die privaten Implementierungen sind für jeden Partner individuell und können durch beliebige ausführbare Sprachen beschrieben werden. Eine mögliche Sprache an dieser Stelle ist die Business Process Modelling Language (BPML). Die BPMI definiert ihre Spezifikation so:

„The Business Process Modeling Language (BPML) is a meta-language for the modeling of business processes, just as XML is a meta-language for the modeling of business data. BPML provides an abstracted execution model for collaborative & transactional business processes based on the concept of a transactional finite-state machine.”^[41]

Der Standard BPM Stack liefert ein Verfahren für eine zufriedenstellende Modellierung von Geschäftsprozessen. Das Ergebnis ist die genaue Beschreibung eines Geschäftsprozesses in Form eine sog. Execution Language. Diese Beschreibung wird anschließend in ein Geschäftsprozessmanagementsystem überführt, um die produktive Ausführung des Geschäftsprozesses zu gewährleisten.

2.2 Workflowmanagement

Neben den Geschäftsprozessen, die wir zuvor näher betrachtet haben, wird dem Workflowmanagement in dieser Diplomarbeit ebenfalls eine wichtige Bedeutung beigemessen. Das Workflowmanagement setzt als Teil des Geschäftsprozessmanagements einen modellierten Geschäftsprozess um und sorgt für die Ausführung in einer Engine. Dieses Kapitel klärt die Begriffe im Zusammenhang mit Workflowmanagement, grenzt das Workflowmanagement gegenüber dem Geschäftsprozessmanagement ab, beleuchtet seine Geschichte und befasst sich mit einigen Architekturansätzen für Workflowmanagement und beschreibt abschließend das Referenzmodell der WfMC.

2.2.1 Begriffe des Workflowmanagement

2.2.1.1 Aktivität

Die deutsche Wikipediaseite als renommierte freie Enzyklopädie im Internet definiert eine Aktivität wie folgt:

„Eine Aktivität in einem Workflow bildet die kleinste Ausführungseinheit. Ihr sind typischerweise eine Tätigkeit, ausführende Ressourcen (Personen, Maschinen), zu benutzende Ressourcen (Werkzeuge, Maschinen oder anderweitige Betriebsmittel) und zeitliche Abhängigkeit (Reihenfolge, Ausführungsdauer usw.) zugeordnet“.^[42]

2.2.1.2 Workflow

Der Begriff des Workflow wird in der Literatur auf verschiedene Weise definiert. Die Ansicht, dass ein Workflow eine technische Verfeinerung des betriebswirtschaftlichen Geschäftsprozesses ist vertreten Galler und Scheer.^[43] Hierbei ist der Workflow Input und Regelwerk für die Steuerung eines Workflowmanagementsystems. Galler und Scheer ordnen den Workflow im ARIS dem DV-Konzept zu, während sie den Geschäftsprozess dem Fachkonzept zuordnen. Für den Grad der Verfeinerung dient ihnen die Automatisierbarkeit. Österle verfolgt einen ähnlichen Ansatz, indem er den Workflow als einen verfeinerten Geschäftsprozess ansieht. Dabei wird ein Geschäftsprozessentwurf (Makro-Ebene) sukzessive in Teilprozesse zerlegt, bis die Mikro-Ebene erreicht ist. Dies ist der Fall, wenn die Teilprozesse so detailliert sind, dass sie von Mitarbeitern als Arbeitsanweisung umgesetzt werden können. Dabei ist ein Workflow eine detaillierte Form des Mikroprozesses.^[44] Die WfMC definiert einen Workflow folgendermaßen: „The computerised facilitation or automation of a business process, in whole or part.“^[45] Sie sieht den Workflow als komplette oder teilweise computerunterstützte Erleichterung oder Automatisierung eines Geschäftsprozesses.

Hinsichtlich der Strukturierung und der Computerunterstützung lässt sich ein Workflow verschiedenen Kategorien zuordnen. Nach dem Grad der Strukturierung sind drei Formen zu unterscheiden^[46].

Allgemeiner Workflow

Der allgemeine Workflow ist durch einen hohen Grad der Strukturierung gekennzeichnet. Er weist darüber hinaus einen hohen Wiederholungscharakter auf und zeigt eine detaillierte Spezifikation aller Arbeitsschritte. In der betrieblichen Praxis fallen Reisekostenabrechnungen, Urlaubsanträge oder die Einstellung neuer Mitarbeiter in diese Kategorie.

Fallbezogener Workflow

Neben den weitestgehend strukturierten Arbeitsabläufen enthält ein fallbezogener Workflow auch unstrukturierte Teilaufgaben. Hier beeinflussen individuelle Entscheidungen den Arbeitsablauf, so dass einzelne Arbeitsschritte ggf. übersprungen werden können. Vorgänge bei der Schadensabwicklung in Versicherungsunternehmen oder bei der Bearbeitung von Kundenreklamationen weisen häufig diesen Fallbezug auf.

Ad-hoc Workflow

Der ad-hoc Workflow zeigt einen geringen Grad der Stukturierung und zeichnet sich außerdem durch einen spontanen Einmal-Charakter aus. Seine Aufgaben sind wenig strukturiert und im Voraus nicht exakt zu spezifizieren.

In Bezug auf Automatisierung und Computerunterstützung eines Workflow lassen sich ebenfalls drei Kategorien unterscheiden, den freien, teilautomatisierten bzw. automatisierten Workflow^[47].

Freier Workflow

Der freie Workflow wird vollständig manuell durch einen personellen Bearbeiter durchgeführt.

Teilautomatisierter Workflow

Der teilautomatisierte Workflow wird von einem personellen Bearbeiter durchgeführt, der dabei durch IT-Systeme unterstützt wird.

Automatisierter Workflow

Der automatisierte Workflow wird vollständig ohne den Eingriff von personellen Bearbeitern durchgeführt.

2.2.1.3 Workflowmanagement

Zum Begriff des Workflowmanagement finden sich in der Literatur ebenfalls verschiedene Definitionen.

Schulze prägte die Definition „ Management umfasst nach allgemeiner Auffassung Handlungen wie Organisieren, Planen, Entscheiden, Kontrollieren, Steuern und Führen. Die Ausübung dieser Handlungen im Zusammenhand mit Arbeitsvorgängen wird beim Einsatz eines Workflowmanagementsystems Workflowmanagement genannt. Dabei ist die Frage, inwieweit Handlungen wie Organisieren, Planen, Entscheiden, Kontrollieren, Steuern und Führen durch ein (technisches) System ausgeübt oder unterstützt werden können, durch den Entwicklungsstand von Workflowmanagementsystemen [...] bestimmt. “^[48]

Nach Gadasch umfasst das Workflowmanagement alle Aufgaben, die bei der Modellierung, Spezifikation, Simulation sowie bei der Ausführung und Steuerung der Workflows erfüllt werden müssen.^[49] Darüber hinaus bestehen enge Verbindungen zu nebengeordneten Konzepten wie dem Workgroup-Computing. Ein Unternehmen verbindet mit dem Workflowmanagement eine Reihe von Erwartungen, die sich durch die nachfolgenden Ziele beschreiben lassen.^[50]

Verbesserung der Prozesstransparenz

Die Tatsache, dass Workflowmanagementsysteme Informationen über geplante und ausgeführte Unternehmensabläufe beinhalten, führt zur Überlegung, diese Informationen jederzeit für eine bessere Information des Unternehmensmanage­ments nutzen zu können. So kann das Unternehmensmanagement Informationen über aktive Prozesse, Kapazitätsauslastung, Ressourcenverfügbarkeit oder Unter­brechungen erhalten. Außerdem können ausgeführte Unternehmensabläufe nach­träglich analysiert werden und für die Optimierung der Geschäftsprozesse in deren Lebenszyklen verwendet werden. Der Lebenszyklus eines Geschäftsprozesses beginnt mit seiner Modellierung. Der Modellierung folgen die Simulation und die produktive Ausführung des Geschäftsprozesses. Die Analyse der Ausführung des Geschäftsprozesses liefert Informationen für ein ggf. nötiges Redesign, um den Geschäftsprozess zu optimieren. Das Redesign kann als erneute Modellierung be­trachtet werden. Der Lebenszyklus eines Geschäftsprozesses ist somit ein geschlossener Kreislauf^[51].

Verbesserung der Prozessqualität und permanente Qualitätssicherung

Die Qualität, der dem Kunden gegenüber erbrachten Leistung, soll durch die Reduzierung von Fehlern gesteigert werden. Ein ständiger Vergleich der Ergebnisse ausgeführter Prozess mit den Sollergebnissen aus der Prozessmodellierung soll die im Modell definierte Leistungsqualität sicherstellen und ggf. steigern.

Reduktion der Prozesskosten

Eine optimierte Durchführung der Prozesse soll zu einer Reduktion der Kosten führen. Häufig wird dabei die Verkürzung von Durchlaufzeiten bei gleichzeitiger Produktivitätssteigerung angestrebt, um so die Kosten des Prozesses reduzieren zu können. Die Modellierung der Prozesse und die damit verbundene Bewertung der Prozessleistungsmengen ermöglicht hierbei erst die Ermittlung der Prozesskosten. Somit stellen die bewerteten Prozessmodelle eine Informationsbasis für die Darstellung der Kosten eines Prozesses bereit.^[52]

Automatisierung der Prozesssteuerung

Ein grundlegender Wunsch ist eine prozessorientierte Ausrichtung der Informationstechnologie in Bezug auf die (teil)automatisierte Unterstützung der Geschäftsprozesse. Hierbei fasst das Workflowmanagement logisch zusammenhängende Funktionen zusammen und soll auch die Nutzung von verschiedenen Systemen für einzelne Funktionen ermöglichen. Damit stellt das Workflowmanagement dem Benutzer den jeweils passenden Arbeitsablauf zur Verfügung, ohne dass der Benutzer die vollständige Aufbauorganisation kennen muss.

Prozessflexibilität

Ein stetiger Wandel der Zielmärkte und der Kundenanforderungen bedingt Geschäftsprozesse, die sich den veränderten Rahmenbedingungen und Anforderungen kontinuierlich anpassen. Diese permanente Adaption muss durch das Workflowmanagement unterstützt werden, indem es in der Lage ist, die Modelle der betroffenen Geschäftsprozesse anzupassen. Eine hohe Prozessflexibilität ist auch beim Einsatz von Qualitätsmanagementmethoden wie beispielsweise dem kontinuierlichen Verbesserungsprozess oder Kaizen unerlässlich.

Steigerung der Kundenzufriedenheit

Die Steigerung der Kundenzufriedenheit ist ein in der Praxis häufig gefordertes Ziel, das sich auch in Konzepten wie dem CRM finden lässt. Die Erreichung dieses für ein Unternehmen essentiellen Zieles wird durch das Workflowmanagement unterstützt. Mittels beschleunigter Auskunftsfähigkeit, reduzierter Durchlaufzeiten und höherer Prozesstransparenz soll die Kundenzufriedenheit verbessert werden.

Verkürzung der Durchlaufzeiten

Mit der Verkürzung der Durchlaufzeiten als Ziel greift das Workflowmanagement den Ansatz des ERM auf, indem es versucht, die Ressourcen und Teilprozesse optimal miteinander zu verbinden. Teilprozesse sollen so angestoßen werden, dass die Durchlauf- und Lagerzeiten möglichst gering sind. Parallelisierung von Einzelaktivitäten und dynamische Zuordnung freier Ressourcen tragen hierzu bei.

Integration heterogener Informationstechniken

Die gegenwärtigen IT-Architekturen der Unternehmenspraxis bestehen aus gewachsenen Systemen. Diese sind häufig durch eine heterogene Hard- und Softwareumgebung gekennzeichnet. Auffällig sind hier die Legacy-Systeme,^[53] die technologisch veraltet sind aber eine sehr große Rolle bei der Unterstützung der Geschäftsprozesse spielen. Aus technischer und wirtschaftlicher Sicht müssen neue Technologien diese ersetzen, kurz- bis mittelfristig werden sie jedoch weiterverwendet. Workflowmanagement bindet diese Systeme durch geeignete Konzepte ein und ist auch in der Lage, neue Komponenten einzubinden, die als Ersatz für Legacy-Systeme fungieren.

Einheitliche Benutzeroberflächen

Eine häufige Begleiterscheinung einer heterogenen IT-Landschaft sind uneinheitliche Benutzeroberflächen und Medienbrüche.^[54] Das Workflowmanagement soll in seiner Umsetzung als Workflowmanagementsystem nach Möglichkeit eine einheitliche Benutzeroberfläche für Geschäftsprozesse bieten und Medienbrüche vermeiden. Auf diese Weise kann auch Aspekten der Softwareergonomie^[55] Rechnung getragen werden.

Bei der Umsetzung des Workflowmanagement in Form eines Workflowmanagementsystems muss die Frage geklärt werden, welche Ziele relevant sind und wie sie erfüllt werden sollen. Bei der Messung der Zielerreichung ist es wichtig, geeignete Messgrößen für die jeweiligen Ziele zu definieren und ein entsprechendes Zielmonitoring zu verwenden. Idealer weise können die Messwerte, die auf der Ebene des Workflowmanagement gesammelt werden in hochverdichteter Form auch eine Aussage über den Erfolg der strategischen Unternehmensziele geben, die mit dem Workflowmanagement unterstützt werden.

2.2.1.4 Workflowmanagement-System

Der Begriff des Workflowmanagement-Systems ist in der Literatur nicht durchgehend einheitlich definiert. Je nach Autor schwankt die Definition zwischen Groupware-Systemen, die kooperative Arbeitsabläufe unterstützen bis hin zu einem verteilten, integrierten Informationssystem mit Client-Server-Architektur.

Die Definition der WfMC beschreibt ein Workflowmanagement-System folgendermaßen:

„ A system that completely defines, manages and executes “workflows” through the execution of software whose order of execution is driven by a computer representation of the workflow logic. “^[56]

Zusammenfassend lässt sich ein WFMS als Instrument für die Umsetzung des Workflowmanagement-Konzeptes beschreiben. Es bietet die Möglichkeit zur Modellierung, Simulation, Ausführung und Kontrolle von Workflows. Ein solches System kann auf verteilten Maschinen betrieben werden, interpretiert Workflowmodelle und agiert mit den Teilnehmern eines Workflows. Bei der Unterstützung von Geschäftsprozessen kann ein WFMS andere IT-Tool und Anwendungen nutzen und integrieren.

2.2.2 Geschichte des Workflowmanagement

Die Herkunft von WFMS lässt sich aus unterschiedlichen Ursprüngen ableiten. Hierzu zählen unter anderem Document-Management-Systeme, E-Mail-Systeme und Groupware Anwendungen. Die Verbreitung von WFMS war in der Vergangenheit gering und nur wenige Unternehmen setzten WFMS in größerem Umfang ein. Nach Gadatsch liegen die Gründe hierfür in noch fehlenden theoretischen Grundlagen und vermeintlichen Schwächen bei den existierenden WFMS. Dies hat dazu geführt, dass häufig nur ein Einsatz zu Evaluierungszwecken oder für erste Pilotprojekte erfolgte. Die Entwicklungsphasen der WFMS können nach einem Ansatz von Schule und Böhm in ein Generationenmodell mit vier Generationen dargestellt werden.^[57]

2.2.2.1 Erste Generation – Hard wired applications

WFMS der ersten^[58] Generation wurden weder von deren Anwendern noch von deren Herstellern als WFMS bezeichnet. Ursache dieser Handlungsweise war die Tatsache, dass diese Anwendungen jeweils auf ein spezielles Prozessmodell ausgelegt waren, das fest in der Anwendung verankert war. Die Anwendung diente somit einem ganz speziellen Zweck und musste bei einer geänderten Anforderungssituation neu konzipiert und realisiert werden. Dedizierte^[59] Systeme zur Schadensbearbeitung in Versicherungsunternehmen sind typische Vertreter dieser Generation.

2.2.2.2 Zweite Generation – Das explizite Vorgehensmodell

In der zweiten Generation der WFMS erfolgte die Trennung von Anwendungslogik und Prozess-Spezifikationen. Die Prozess-Spezifikation erfolgt unter Verwendung einer beschreibenden Sprache (workflow definition language). Vorteile der Trennung und der Prozess-Spezifikation mittels einer beschreibenden Sprache sind eine wesentlich höhere Flexibilität in Bezug auf die Einsatzmöglichkeiten und gebiete einer solchen Anwendung und die Prozessmodellierung.

2.2.2.3 Dritte Generation – Einsatz von Datenbanksystemen

Durch den Einsatz der im Laufe der 1980er aufkommenden Datenbank-Managementsysteme in WFMS unterscheidet sich die dritte Generation von der vorhergehenden zweiten Generation. Anstelle einfacher Dateisysteme für die Speicherung von Prozessmodellen und Prozessausführungsdaten zu verwenden kamen nun Datenbank-Managementsysteme zum Einsatz.

2.2.2.4 Vierte Generation – Interoperable Systeme

In der heutigen vierten Generation bieten die Systeme eine Unterstützung für den Austausch von Prozessmodellen und Prozessausführungsdaten zwischen Produktion verschiedener Hersteller. WFMS sind hierbei weitestgehend durchgehend auf Basis von Client-Server-Architekturen konzipiert. Dabei fügen sich WFMS der vierten Generation in Geschäftsprozessmanagementsysteme ein oder entwickeln sich weiter zu ganzheitlichen Systemen für die Geschäftsprozessmodellierung, die über die reine Steuerung und Automatisierung des Arbeitsflusses hinausgehen.

2.2.3 Abgrenzung des Workflowmanagement

Bei den Begriffsdefinitionen des Workflowmanagement hat sich gezeigt, dass sich keine allgemeingültige Trennlinie ziehen lässt. Das Workflowmanagement zeigt Ähnlichkeiten und Gemeinsamkeiten zu anderen Konzepten. Für das weitere Vorgehen in dieser Diplomarbeit ist es notwendig, eine genaue Abgrenzung der Begriffe vorzunehmen. Dazu wird zum einen das Geschäftsprozessmanagement gegen das Workflowmanagement abgegrenzt und zum anderen das Workflowmanagement vom Workgroup-Computing.

2.2.3.1 Geschäftsprozessmanagements versus Workflowmanagement

Beide Konzepte befassen sich mit betrieblichen Arbeitsabläufen. Dabei verfolgen die Konzepte aber unterschiedliche Ziele. Im Kontext der Geschäftsprozesse geht es vereinfacht darum, “was“ gemacht wird. Ziel ist die inhaltliche Gestaltung der Arbeitsabläufe und deren Einsatz für die Umsetzung der strategischen Unternehmensziele. Das Geschäftsprozessmanagement sieht seinen Aufgabenschwerpunkt hierbei auf der Neugestaltung, Modellierung und Optimierung von Geschäftsprozessen. Das Werkzeug des Geschäftsprozessmanagements ist dabei ein Geschäftsprozessmanagementsystem. Das Workflowmanagement befasst sich mit der Fragestellung, “wie“ die Arbeitsabläufe durchgeführt werden. Es spezifiziert die technische Ausführung von Arbeitsabläufen. Durch den Aufgabenschwerpunkt einer weitestgehend automatisierten Umsetzung der Geschäftsprozesse innerhalb der strategischen Ziele befindet sich das Workflowmanagement auf einer operativen Ebene und hat eine enge Verbindung zur unterstützenden Technologie. Mit dem WFMS unterstützt es die Geschäftsprozessmanagementsysteme bei der Umsetzung der Geschäftsprozesse.^[60]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2 Terminologieabgrenzung Geschäftsprozess und Workflow

2.2.3.2 Workflowmanagement versus Workgroup-Computing

Bei der Abgrenzung von Workflowmanagement gegenüber dem Workgroup-Computing ist der Grad der Strukturierung ausschlaggebend. Unter Workgroup-Computing versteht man die computerunterstützte Steuerung von Gruppenarbeitsprozessen. Dies kann zum Beispiel die Bearbeitung eines Projektes sein. Hierbei kommt das Workgroup-Computing meist bei ad-hoc Workflows zum Einsatz. Das Workflowmanagement deckt im Gegensatz dazu das ganze Spektrum in Bezug auf den Grad der Strukturierung ab.^[61] Nicht von der Hand zu weisen ist die Tatsache, dass das Workgroup-Computing bei der Evolution der Workflowmanagementsysteme involviert ist.^[62]

2.2.4 Referenzmodell der Workflowmanagement-Coaliton

Im Bereich des Workflowmanagement und der Geschäftsprozessmodellierung spielt die Referenzarchitektur der Workflow Management Coalition (WfMC) eine wichtige Rolle. Die WfMC ist eine internationale non-profit Organisation. Sie wurde im August 1993 gegründet und besteht aus Software-Häusern, Anwendern, Beratern und Forschungsinstituten, die sich mit Workflowmanagement befassen. Aktuell hat die WfMC mehr als 220 Mitglieder. Die Kernarbeit der WfMC ist es, eine Standardisierung des Workflowmanagement zu erarbeiten.^[63] Hierbei liegt ein Hauptaugenmerk auf Glossar, Referenzmodell und Interoperabilität. Organisatorisch gliedert sich die WfMC in drei Hauptbereiche auf. Das Technical Comittee ist verantwortlich für die Entwicklung der WfMC-Spezifikationen und gliedert sich in mehrere Arbeitsgruppen auf, die sich mit bestimmten Teilbereichen des Referenzmodells befassen. Das External Relations Committee ist dafür verantwortlich, dass die erarbeiteten Standards präsentiert und publiziert werden. Die beiden zuvor genannten Committees werden vom Steering Committee, einer Art Aufsichtsrat gelenkt. Dieses Committee achtet auf die Integrität und Konsistenz der Arbeit der WfMC. Laut der WfMC sind drei Elemente essentiell für ein Workflowmanagementsystem. Eine Modellierungsumgebung für die Geschäftsprozesse, eine Laufzeitumgebung für die modellierten Prozesse und eine Administrationsumgebung nebst Monitoringtool für das komplette System.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3 Referenzmodell der WfMC^[64]

Nachfolgend wird in dieser Diplomarbeit das Referenzmodell der WfMC in drei Schritten betrachtet. Zuerst der Kern des Modells mit Workflow-Engine, Workflow Enactment Service und Workflow Application Programming Interface (WAPI). Danach werden die weiteren Systemkompontent betrachtet, die den Kern des Systems umgeben und ergänzen. Abschließend erfolgt eine nähere Betrachtung der fünf Schnittstellen zwischen Kern und umgebenden Komponenten.

2.2.4.1 Kernkomponeten des WfMC-Referenzmodells

Workflow Engine

Eine Workflow-Engine ist ein Softwaredienst, der eine Laufzeitumgebung für Workflowinstanzen bereitstellt. Dabei interpretiert die Engine die Prozessdefinition und kontrolliert die laufenden Prozessinstanzen. Außerdem ist die Engine für die Navigation zwischen einzelnen Prozessaktivitäten zuständig. Neben den Prozessen kümmert sich die Engine auch um die Verwaltung der für den Workflow relevanten Daten und kontrolliert die Kommunikation zwischen Benutzern und Prozessen.^[65]

Im Referenzmodell der WfMC befinden sich die Workflow Engines im Workflow Enactment Service. Im Workflow Enactment Service können mehrere Workflow Engines gleichzeitig vorhanden sein und arbeiten.

Workflow Enactment Service

Die WfMC definiert einen Workflow Enactment Service als Softwaredienst, der aus einer oder mehreren Workflow Engines besteht und sich um Anlage, Verwaltung und Ausführung von Workflow-Instanzen kümmert. Der Workflow Enactment Service kommuniziert mit Anwendungen seiner Umgebung mittels des Workflow Application Programming Interface.^[66] Der Workflow Enactment Service kann mit einem Zustandsautomaten verglichen werden, in dem individuelle Prozessinstanzen ihre Zustände durch den Erhalt externer Ereignisse oder Anweisungen einer Workflow Engine ändern.^[67]

Workflow Application Programming Interface (WAPI)

Das WAPI ist eine Sammlung von Funktionen (API-Calls), die ein Workflow Enactment Service an seinen Grenzen zur Verfügung stellt. Ziel ist die Kommunikation und der Datenaustausch mit anderen Ressourcen oder Anwendungen. Das Referenzmodell benennt fünf Schnittstellen im WAPI. Dabei handelt es sich nicht um fünf Schnittstellendefinitionen, die unabhängig voneinander existieren. Vielmehr bildet das WAPI einen gemeinsamen Kern, der bei jeder der fünf Schnittstellen um spezifische Funktionalität erweitert wird.^[68]

2.2.4.2 Weitere Komponenten des WfMC-Referenzmodells

Neben diesen drei Kernkomponenten definiert das Referenzmodell fünf weitere Systemkomponenten für ein vollständiges Workflowmanagementsystem. Deren Aufgaben variieren von der Prozessmodellierung über Administration und Monitoring, Einbindung weiterer Workflow Enactment Services bis hin zur Interaktion mit Benutzern und anderen Anwendungen. Nachfolgend werden diese Systemkomponenten vorgestellt.

Process Definition Services

Für die Analyse, Modellierung, Beschreibung und Dokumentation von Geschäftsprozessen bietet der Markt eine breit gestreute Auswahl an Software-Tools. Die Auswahl reicht von eher informativen Ansätzen bis hin zu anspruchsvollen hochformalen Lösungen. Solche Tools können in ein Workflowmanagementsystem integriert sein oder als separate Anwendung auftreten. Das Ergebnis eines solchen Tools ist eine Prozessdefinition, die von einer Workflow Engine innerhalb eines Workflow Enactment Service interpretiert werden kann. Der Transfer einer Prozessdefinition vom Process Definition Service in die Workflow Engine geschieht über das Workflow Definition Interface. Diese Schnittstelle wird später noch genauer erläutert.^[69]

Workflow Client Applications

Die Workflow Client Applications beschreiben alle Anwendungen, bei denen eine Interaktion mit personellen Bearbeitern notwendig ist. Diese Anwendungen können durch ein komplettes Workflowmanagementsystem vorgegeben sein, durch die Anwender programmiert sein oder in bestehende Anwendungen integriert werden. Aus diesem Grund ist hier ein flexibler Mechanismus für die Kommunikation zwischen Workflow Client Applications und Workflow Enactment Service notwendig. Dieser Mechanismus wird im Referenzmodell durch das Workflow Client Application Interface repräsentiert.^[70]

Invoked Applications

Bestimmte Aktivitäten innerhalb der Workflow Engine erfordern die Nutzung externer Anwendungen. Es ist davon auszugehen, dass ein Workflowmanagementsystem nicht die erforderliche Logik beinhaltet um alle potentiellen Anwendungen in einer heterogenen IT-Landschaft anzusprechen. Eine solche Logik müsste in der Lage sein, mit beliebigen Anwendungen auf beliebigen Plattformen und beliebigen Netzumgebungen umzugehen. Die meisten WFMS unterstützen daher nur eine stark eingeschränkte Anzahl von Anwendungen oder verwenden einen Application Agent als Mittler zwischen Workflow Enactment Service und den möglichen Anwendungen. Ähnlich wie bei den Workflow Client Applications ist auch hier eine flexible Lösung erforderlich, um eine standardisierte Schnittstelle zu schaffen. Das WAPI sieht für diesen Bereich das Invoked Applications Interface vor.^[71]

Other Workflow Enactment Services

Das Prinzip der Interoperabilität hat sich die WfMC mit zur Hauptaufgabe gemacht. WFMS verschiedener Anbieter sollen über einen definierten Standard nahtlos zusammenarbeiten. Die WfMC hat zu diesem Zweck vier verschiedene Szenarien mit verschiedenem Leistungsvermögen entwickelt. Der Umfang reicht von einer einfachen Verarbeitung in Form von verketteten Aktivitäten, über verschachtelte Subprozesse und Peer-to-Peer Kommuniktaion bis hin zur parallelen Synchronverarbeitung. Die WAPI Interoperability Functions sind darauf ausgelegt, diese vier Szenarien der Kommunikation zu unterstützen.^[72]

Administration and Monitoring Services

Im Bereich der Administration und der Überwachung von WFMS sind verschiedene Konstellationen möglich. Ein umfassendes WFMS beinhaltet Funktionen zur Administration und Überwachung. Ebenso ist es denkbar, die Workflow Enactment Services eines oder verschiedener Anbieter mit der Software eines dritten Anbieters zu steuern. Dabei umfassen solche Anwendungen in der Regel Benutzermanagement, Rollenmanagement, Ressourcenkontrolle und Prozessüberwachung. Das Administration and Monitoring Interface liefert hier den notwendigen Standard für Kommunikation und Datenaustausch.^[73]

2.2.4.3 Schnittstellen des WfMC-Referenzmodells

Die beschriebenen Systemkomponenten sind, wie bereits erwähnt, durch fünf Schnittstellenausprägungen der WAPI mit dem Workflow Enactment Service verbunden. Wie diese Ausprägungen im einzelnen Aussehen und welche Aufgaben sie erfüllen müssen, wird nachfolgend betrachtet.

Workflow Definition Interchange

Diese Schnittstelle verbindet den Workflow Enactment Service mit dem Process Definition Service. Somit hat diese Schnittstelle die Aufgabe, eine zuvor modellierte Prozessdefinition in die Workflow Engine zu überführen. Dabei stellt diese Schnittstelle eine Trennung zwischen der Modellierung (Build-Time) und der Laufzeitumgebung (Runtime) dar. Die WfMC konzentriert ihre Arbeit hier auf zwei Aspekte. Zum einen stellt sie ein einfaches Meta-Modell für die Modellierung zur Verfügung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4 WfMC Meta-Modell^[74]

Dieses Meta-Modell besteht aus sechs Komponenten und kann mittels der XPDL^[75] im XML-Format abgebildet werden. Bei der Modellierung und der Darstellung der Definition kann auch auf Formate wie UML oder BPEL zurückgegriffen werden, solange sie das Meta-Modell der WfMC verwenden. Der zweite Aspekt ist eine entsprechende API, mit deren Hilfe sich ein definierter Workflow in XPDL von der Build-Time in die Run-Time übertragen lässt.^[76]

[...]

---

^[1] vgl. [WP2005c]

^[2] vgl. [VÖV2005] S. 43ff

^[3] vgl. [VÖV2005] S. 6ff

^[4] Ein Kompositversicherer bietet ein umfassendes Spektrum von Versicherungsleistungen an, während beispielsweise eine Brandversicherung die Marktnische der Feuerversicherungen abdeckt.

^[5] vgl. [WP2005j]

^[6] vgl. [LLB2005]

^[7] vgl. [LLB2004] S. 11f

^[8] vgl. [LLB2005]

^[9] vgl. [LLB2005]

^[10] vgl. [LLB2004] S. 4

^[11] vgl. [LLB2004] S. 9f

^[12] vgl. [SCHULZE 1997] S. 486

^[13] F. Nordsieck gilt als einer der frühen Wegbereiter der Betriebswirtschaftslehre.

^[14] Frederick Winslow Taylor war ein US-amerikanischer Ingenieur und Arbeitswissenschaft­ler, der mit seinen Lehren der wissenschaftlichen Betriebsführung den Taylerismus begründet hat.

^[15] Adam Smith, amerikanischer Philosoph und Ökonom, veröffentlichte das Buch „An Inquiry into the Nature an Causes of the Wealth of Nations“ und gilt dadurch als Mitbe­gründer des Grundsatzes der Arbeitsteilung.

^[16] vgl. [EBEL 2003] S. 101ff

^[17] vg. [GADATSCH2001] S. 19ff

^[18] vgl. [GADATSCH2001] S. 19ff

^[19] (Kaizen jap. kai = ändern; zen = das Gute; wörtl. Verbesserung) Japanische Managementkonzept, dessen Philosophie eine ständige Veränderung zum Besseren ist. Es bezieht Führungskräfte und Mitarbeiter gleichermaßen ein. vgl. [KAMISKE2002a] S. 37f

^[20] vgl. [HDI241] S.107

^[21] vgl. [SCHIENMANN2002] S. 305ff

^[22] [SCHIENMANN2002] S. 307

^[23] vgl. [SCHIENMANN2002] S. 306-307

^[24] vgl. [SCHIENMANN2002] S. 306ff

^[25] vgl. [SCHIENMANN2002] S. 310f

^[26] [PERNUL/UNLAND2001] S. 114

^[27] Ein Petri-Netz ist eine mathematische Repräsentation von verteilten Systemen. (vgl. [WP2005a])

^[28] Stack von engl. stack = Stapel

^[29] vgl. [HDI2004] S. 107f

^[30] Enterprise Application Integration ist ein Ansatz zur Integration von verschiedenen Anwendungen (Applikationen) auf unterschiedlichen technischen Plattformen zu Geschäftsprozessen.

^[31] vgl. [HMD241a] S.107

^[32] siehe Anhang 2-1

^[33] Erweiterte Ereignisgesteuerte Prozessketten (eEPK) sind eine Weiterentwicklung von Petri-Netzen. Ein Petrinetz ist eine mathematische Repräsentation von verteilten Systemen. (vgl. [WP2005a]) Gegenüber Petri-Netzen sind eEPKs weniger formal und genau, dadurch aber auch leichter zu handhaben. (vgl. [WP2005b])

^[34] vgl. [GADATSCH2001] S. 96

^[35] [BPMI2005a]

^[36] Die Extensible Markup Language (XML) stellt einen weit verbreiteten Standard zur Erstellung von maschinen- und menschenlesbaren Dokumenten dar. Sie wird vom W3C standardisiert und weiterentwickelt. [W3C2005]

^[37] Die Object Management Group (OMG) ist eine non-profit Organisation, die sich das Ziel gesetzt hat Standards für die objektorientierte Programmierung zu entwickeln. Sie ist maßgeblich an der Entwicklung von Projekten wie UML, MDA und CORBA beteiligt. [OMG2005a]

^[38] Die Workflow Management Coalition (WfMC) ist ebenfalls eine internationale non-profit Organisation. Sie besteht aus Anbietern und Nutzern von Workflowmanagement-Lösungen sowie Analysten und Forschungseinrichtung. Ihr Ziel ist, die Potentiale von Workflowmanagement zu steigern, die Risiken zu senken und Workflow-Technologie zu stärken. Sie arbeitet ebenfalls an mehreren Standards für diesen Bereich. [WFMC2005a]

^[39] Als internationale non-profit Organisation befasst sich die Organization for the Advancement of Structured Information Standards (OASIS) mit der Weiterentwicklung von Standards in den Bereichen e-Business und Web Services. [OASIS2005]

^[40] [BPMI2005a]

^[41] [BPMI2005b]

^[42] [WP2005e]

^[43] vgl. [GADATSCH2001] S.31

^[44] vgl. [GADATSCH2001] S. 30f

^[45] [WFMC2005b] S. 6

^[46] vgl. [GADATSCH2001] S. 31ff

^[47] vgl. [GADATSCH2001] S. 33f

^[48] [SCHULZE1997] S. 491

^[49] vgl. [GADASCH2001] S. 36ff

^[50] vgl. [GADATSCH2001] S. 38ff

^[51] vgl. [GADATSCH2001] S. 82ff

^[52] vgl. [GADATSCH] S. 39

^[53] Legacy bedeutet Altlast oder Erbe.

^[54] Ein prominentes Beispiel für Medienbrüche ist das manuelle Erfassen einer Liste mit Daten in einem EDV-System, die zuvor aus einem anderen EDV-System erzeugt wurde.

^[55] Software-Ergonomie ist die Wissenschaft von der Benutzbarkeit und Gebrauchstauglichkeit von Computer-Programmen. Von griechisch ergon (= Mühe, Arbeit, Werk) und nomos (= Lehre, Gesetz, Regel). Sie ist ein Teilgebiet der Mensch-Computer-Interaktion. [WP2005f]

^[56] [WFMC2005b] S. 6

^[57] vgl. [GADATSCH2001] S. 44

^[58] Hard wired applications bedeutet übersetzt „fest verdrahtete Anwendungen“ und spielt auf den starren unflexiblen Charakter dieser Form von Anwendung an.

^[59] dediziert von Dedizierung (Widmung oder Schenkung) bezeichnet im Computerumfeld ein System, dass eine einzige spezielle Aufgabe erfüllt. vgl. [WP2005d]

^[60] vgl. [SCHULZE1997] S. 7ff

^[61] vgl. [GADATSCH2001] S. 41f

^[62] vgl. [WFMC2005b] S. 10

^[63] vgl. [WFMC2005a]

^[64] vgl. [WFMC2005b] S. 20

^[65] vgl. [WFMC2005b] S. 22

^[66] vgl. [WFMC2005b] S. 21

^[67] vgl. [WFMC2005b] S. 23

^[68] vgl. [WFMC2005b] S. 25

^[69] vgl. [WFMC2005b] S. 28

^[70] vgl. [WFMC2005b] S. 31f

^[71] vgl. [WFMC2005b] S. 35ff

^[72] vgl. [WFMC2005b] S. 37ff

^[73] vgl. [WFMC2005b] S. 44f

^[74] vgl. [WFMC2005b] S. 30

^[75] XPDL ist die Abkürzung für XML Process Definition Language

^[76] vgl. [WFMC2005b] S. 28ff