Universität-Gesamthochschule Paderborn
Diplomarbeit
Konzeption und Entwicklung einer prototypischen Workflow-Engine für Group-basierte Ad-hoc-Workflows im Projektbereich GroupProcess
Prof. Dr. L. Nastansky
Sommersemester 2001
Betreuer:
Dipl.-Inform. Carsten Huth
vorgelegt von:
Claudius Niebiossa
Wirtschaftswissenschaften H II
Matr.-Nr.: 3061586
Wachtelweg 9
33758 Schloß Holte-Stukenbrock
Danksagung
Mein Dank gilt allen, die zum Gelingen dieser Diplomarbeit beigetragen haben.
Besonders bedanken möchte ich mich bei Herrn Prof. Nastansky und Dipl.-Inform.
Carsten Huth für ihre Unterstützung und Betreuung bei der vorliegenden Arbeit.
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig und
nur unter Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden
Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich
gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch
nicht veröffentlicht.
Schloß Holte-Stukenbrock, 27.04.2001
(Claudius Niebiossa)
Inhaltsverzeichnis Seite I
Inhaltsverzeichnis
1 EINLEITUNG........................................................................................................ 1
1.1 Szenario.......................................................................................................... 1
1.2 Zielsetzung ..................................................................................................... 2
1.3 Vorgehensweise.............................................................................................. 3
2 GRUNDLAGEN..................................................................................................... 4
2.1 CSCW-Forschung und Groupware ................................................................ 4
2.2 Workflow-Terminologie ................................................................................ 8
2.3 Groupware-Umgebung Lotus Notes............................................................. 12
2.4 Office- und Workflow-Management-System PAVONE Espresso .............. 18
2.4.1 Espresso Umgebung............................................................................ 18
2.4.2 Espresso und Ad-hoc-Workflow-Management................................... 20
3 MERKMALE UND ANFORDERUNGEN AN EIN AD-HOC-WORKFLOW-
MANAGEMENT-SYSTEM; DAS GROUPPROCESS-KONZEPT .............. 23
3.1 GroupProcess-Kontinuum............................................................................ 23
3.2 Simultane Ausführung.................................................................................. 28
3.3 Partizipatives, verteiltes Design ................................................................... 30
3.4 Übergang von konkreter zu abstrakter Prozessmodellierung....................... 32
3.5 Anforderungen an eine Ad-hoc-Workflow-Engine...................................... 33
Inhaltsverzeichnis Seite II
4 REALISIERUNG EINER AD-HOC-WORKFLOW-ENGINE FÜR
GROUPWARE-BASIERTE AD-HOC-WORKFLOWS................................. 34
4.1 Architektur GroupProcess ............................................................................ 34
4.1.1 Aufbau GroupProcess-Repository....................................................... 35
4.1.1.1 Application Database .................................................................... 36
4.1.1.2 Organization Database .................................................................. 38
4.1.2 Ad-hoc-Workflow-Document ............................................................. 40
4.1.3 Aufbau der Ad-hoc-Workflow-Engine ............................................... 42
4.2 Funktionalität der Engine ............................................................................. 45
4.2.1 Workflow initialisieren ....................................................................... 45
4.2.2 Weiterleitung....................................................................................... 46
4.2.2.1 Aufgaben aufteilen und zusammenführen (Split/Join).................. 49
4.2.2.2 Auswahl exklusive/mehrfach (Choice single/multiple) ................ 55
4.2.2.3 Berechnete Weiterleitung (Condition/Else) .................................. 56
4.2.2.4 Verarbeitung von Schleifen........................................................... 57
4.2.3 Ausnahmebehandlung ......................................................................... 59
4.2.4 Workflow abschließen ........................................................................ 60
5 AKTUELLER IMPLEMENTIERUNGSSTAND UND AUSBLICK............. 62
6 ZUSAMMENFASSUNG..................................................................................... 64
LITERATURVERZEICHNIS ................................................................................ 65
ANHANG .................................................................................................................. 70
Verzeichnis der Abbildungen und Tabellen Seite III
Verzeichnis der Abbildungen und Tabellen Abbildungen:
Abbildung 2-1: Groupware-Typen und -Werkzeuge................................................. 5
Abbildung 2-2: Klassifikationschema nach Unterstützungsfunktionen .................... 7
Abbildung 2-3: Workflow Reference Model............................................................. 9
Abbildung 2-4: Aufbau Verbunddokument............................................................. 13
Abbildung 2-5: Ansicht einer Lotus Notes Datenbank............................................ 14
Abbildung 2-6: Sicherheitsebenen........................................................................... 16
Abbildung 2-7: Entwicklungsumgebung von Lotus Notes...................................... 17
Abbildung 2-8: Kompanenten der Espresso-Umgebung......................................... 19
Abbildung 2-9: Hinzufügen von Ad-hoc-Aufgaben im Espresso-System .............. 22
Abbildung 3-1: Charakteristika herkömliche WfMS und GroupProcess ................ 28
Abbildung 4-1: Architekturmodell von GroupProcess............................................ 35
Abbildung 4-2: GroupProcess-Repository und die Schnittstellen zur Ad-hoc-
Workflow-Engine........................................................................... 36
Abbildung 4-3: Persönliche Ansicht in der Application Database.......................... 37
Abbildung 4-4: Beispiel für einen Ad-hoc-Prozess im Prototyp des
Modellierungswerkzueges des GruopProcess-Systems ................. 38
Abbildung 4-5: Ansicht der Organization Database................................................ 39
Abbildung 4-6: Ad-hoc-Workflow-Dokument........................................................ 40
Abbildung 4-7: Struktur des Ad-Hoc-Workflow-Objektmodells............................ 41
Abbildung 4-8: Aufbau Ad-hoc-Workflow-Engine ................................................ 44
Abbildung 4-9: Weiterleitungsarten ........................................................................ 46
Abbildung 4-10: Fallbeispiel „Erneuerung des EDV-Systems“, Phase 1.................. 48
Abbildung 4-11: Hierarchische Splits und deren Verwaltung................................... 50
Inhaltsverzeichnis Seite IV
Abbildung 4-12: Fallbeispiel „Erneuerung des EDV-Systems“, Phase 2.................. 52
Abbildung 4-13: Fallbeispiel „Erneuerung des EDV-Systems“, Phase 3.................. 54
Abbildung 4-14: Promptbox „Mehrfachauswahl“ am Beispiel der Erstellung einer
WWW-Präsenz............................................................................... 55
Abbildung 4-15: Promptbox "exklusive Auswahl" ................................................... 55
Abbildung 4-16: Beispiel einer Prozessstruktur mit berechneter Weiterleitung ....... 57
Abbildung 4-17: Fallbeispiel „Erstellung einer Webseite mit Produktinformationen
in englischer Sprache“.................................................................... 58
Abbildung 4-18: Promptbox Ausnahmebehandlung ................................................. 59
Abbildung 4-19: Bestätigung, Aufgabe als „Endaufgabe“ spezifizieren................... 60
Abbildung 4-20: Entscheidungsbaum der Engine bei der Weiterleitung eines
Vorganges ...................................................................................... 61
Tabellen: Tabelle 2-1: GroupFlow-Kontinuum.......................................................................... 21
Tabelle 3-1: Das GroupProcess-Kontinuum .............................................................. 24
Tabelle 3-2: Entstehung eines Ad-hoc-Workflow-Modells ....................................... 31
Tabelle 4-1: Dimensionen der Verwaltung von Splits ............................................... 51
Abkürzungen Seite V
Abkürzungen
API Application Programming Interface
BPR Business Process Reengineering
CSCW Computer Supported Cooperative Work
E-Mail Electronic Mail
HTML Hyper Text Markup Language
LAN Local Area Network
MO Message Objekt
ID Identifikation
JVM Java Virtual Machine
OLE Object Linking and Embedding
WFM Workflow Management
WfMC Workflow Management Coalition
WFMS Workflow Management System
WAN Wide Area Network
WWW World Wide Web
XML Extensible Markup Language
1 Einleitung Seite 1
1 Einleitung
1.1 Szenario
Die Marktsituation der letzten Jahren ist durch eine stetig wachsende und sich
verschärfende Konkurrenz geprägt. Hauptursache hierfür ist die permanent
fortschreitende Globalisierung der unternehmerischen Tätigkeit verbunden mit der
Verkürzung der Produktlebenszyklen. Lagen Optimierungsmöglichkeiten bislang in
einer funktionalen, tayloristischen Arbeitsteilung bei gleichzeitiger Aufteilung von
Aufgabe und Kompetenz, so werden diese heute in der Beschleunigung der
wertschöpfenden Kernprozesse bei gleichzeitiger Qualitätssteigerung gesehen.
Die in den Mittelpunkt rückende Kundenorientierung von Geschäftsprozessen führte
Mitte der 90er Jahre zur Entwicklung von Dokumenten- und Workflow-
Management-Systemen, die durch Reduzierung der Durchlaufzeiten und durch
Steigerung der Bearbeitungsqualität eine kontinuierliche Optimierung von
Geschäftsprozessen erlauben. Diese Systeme wurden in erster Linie zur
Unterstützung von stark strukturierten Prozessen konzipiert (z.B. Flow Mark von
IBM, WorkFLow von CSE und Espresso von Pavone).
Neben derart stark strukturierten Prozessen existiert aber auch noch die Klasse der
flexiblen, kurzlebigen, schwach strukturierten Prozesse, die bisher noch nicht
ausreichend unterstützt werden. Man kann davon ausgehen, dass diese Klasse von
Ad-hoc-Prozessen, bedingt durch die hohe Dynamik und Komplexität der heutigen
Unternehmensumwelt, an Bedeutung gewinnt.1
Die heutige Ausführung von Ad-hoc-Prozessen ist besonders durch die Vielfalt der
verwendeten Kommunikationsmedien gekennzeichnet. Obwohl dem Einsatz von E-
Mail eine zunehmende Relevanz zukommt, werden weiterhin Medien wie
beispielsweise Brief, Fax und Telefon verwendet. Dieser Medien-Mix macht eine
Ex-post-Analyse der Prozesse und deren Verwendung als Vorlage für andere
unmöglich.
1 vgl. [Huth/Nastansky 2000a]
1 Einleitung Seite 2
Der Einsatz eines Ad-hoc-Workflow-Management-Systems würde die lückenlose
Dokumentation der Durchführung von Ad-hoc-Prozessen übernehmen und damit
eine Ex-post-Analyse der Prozesse mittels geeigneter Software-Werkzeuge
ermöglichen. Die analysierten Prozesse könnten sodann als Vorlage für ähnliche Ad-
hoc-Prozesse verwendet werden, so dass sich der Übergang von Ad-hoc-Prozessen
zu vordefinierten, strukturierten Prozessen vereinfacht.
Bei aktuellen Workflow-Management-Systemen werden Prozesse von Spezialisten
analysiert und als Prozessmodell im System implementiert. Die Analysemethode
beschränkt sich meistens auf die Befragung der Prozessverantwortlichen und lässt
das Prozesswissen der einzelnen Beteiligten bzw. der Anwender ungenutzt.2 Ein
System, das die Modifizierung des Prozessmodells während der Laufzeit durch
dessen Benutzer erlaubt, könnte das Prozesswissen aller Beteiligten nutzen und somit
Zeit und Kosten der herkömmlichen Analysemethoden ersparen. Die Umwandelung
von implizitem, informellem Prozesswissen in explizites, formelles Prozesswissen
würde durch dieses System in einem höheren Maße unterstützt, als dies die heutigen
Workflow-Management-Systeme vermögen.
1.2 Zielsetzung
Am GROUPWARE COMPETENCE CENTER (GCC) der Lehr- und
Forschungseinheit Wirtschaftsinformatik 2 der Universität-Gesamthochschule
Paderborn wurde das Workflow-Management-System GroupFlow entwickelt. Der
GCC-Partner Pavone entwickelte darauf aufbauend das kommerzielle Office- und
Workflow-Management-System Espresso. Espresso basiert auf der Groupware-
Plattform Lotus Notes/Domino und stellt Möglichkeiten der Modellierung und
Durchführung von vordefinierten Bürovorgängen zur Verfügung. Um insbesondere
die Unterstützung von Ad-hoc-Workflows zu verbessern, ist das GroupProcess-
Projekt entstanden. Das dort entwickelte GroupProcess-System, das als Erweiterung
aktueller Workflow-Management-Systeme gesehen wird, stellt vor allem
Möglichkeiten der Modellierung und Durchführung von Ad-hoc-Workflows zur
Verfügung.
2 vgl. [Huth/Nastansky 2000a]
1 Einleitung Seite 3
Das Ziel der vorliegenden Diplomarbeit ist das Herausarbeiten der wesentlichen
Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System aus
der Sicht der Ausführungsebene. Zu diesem Zweck ist mit Hilfe der Groupware-
Plattform Lotus Notes/Domino eine prototypische Entwicklung einer Workflow-
Engine für Groupware-basierte Ad-hoc-Workflows zu realisieren. Diese
Laufzeitumgebung soll als Erweiterung bestehender Workflow-Management-
Systeme insbesondere eine „Just in time“-modellierte Vorgangsbearbeitung erlauben.
1.3 Vorgehensweise
Im Anschluss an diese Einleitung folgt das Kapitel Grundlagen, in dem technische
und konzeptionelle Grundlagen und Termini definiert werden, die in der
vorliegenden Arbeit verwendet werden.
Das dritte Kapitel grenzt das Ad-hoc-Workflow-Management vom herkömmlichen
Workflow-Management ab und stellt das GroupProcess-Konzept vor. Neben dem
GroupProcess-Kontinuum werden Merkmale und Anforderungen an ein Ad-hoc-
Workflow-Management vorgestellt. Abschließend wird ein Anforderungskatalog für
eine Ad-hoc-Workflow-Engine erarbeitet.
Die prototypische Realisierung der Ad-hoc-Workflow-Engine wird im vierten
Kapitel dargestellt. Neben der Architektur vom GroupProcess und deren
Bestandteilen wird In diesem Zusammenhang auch der Aufbau der Workflow-Engine
vorgestellt. Danach folgt eine detaillierte Beschreibung der gesamten Funktionalität
der Engine anhand von Fallbeispielen.
Das fünfte Kapitel stellt den aktuellen Implementierungsstand sowie künftige
Erweiterungsmöglichkeiten der Ad-hoc-Workflow-Engine dar.
In der abschließenden Zusammenfassung werden die Vorgehensweise dieser Arbeit
sowie die wichtigsten Gedanken und Überlegungen skizziert.
2 Grundlagen Seite 4
2 Grundlagen Wie bereits in der Einleitung erwähnt, werden in diesem Kapitel zum besseren
Verständnis grundlegende Begriffe von Groupware und Workflow-Management
erklärt. Als Basis hierfür dienen Konzepte des Computer Supported Cooperative
Work und der Workflow Management Coalition. Im weiteren Verlauf werden die
zugrunde liegende Entwicklungsumgebung Lotus Notes und das als Ausgangspunkt
genommene Workflow-Management-System Pavone Espresso vorgestellt.
2.1 CSCW-Forschung und Groupware
Das Forschungsgebiet der Computer Supported Cooperative Work (CSCW, dt.
Computerunterstützte Gruppenarbeit) entstand Mitte der achtziger Jahre. Im
Vordergrund dieser Forschung steht die Unterstützung des Arbeitsumfeldes von
Personen und Gruppen durch den Einsatz von Computern. Das vorrangige Ziel der
CSCW-Forschung ist es,
„die Zusammenarbeit von Menschen durch den Einsatz von Informations- und
Kommunikationstechniken zu verbessern, d.h. effizienter und flexibler, aber auch
humaner und sozialer zu gestalten.“ [Hasenkamp/Syring 1994, S.15]
Ein weiteres Charakteristikum ist die Interdisziplinarität dieses Forschungsgebietes,
das sich u.a. mit Wirtschaftsinformatik, Arbeitswissenschaft, Psychologie und
Kommunikationswissenschaften beschäftigt. Computer Supported Cooperative Work
(CSCW) bezeichnet also das gesamte Forschungsgebiet, das sich mit der
systematischen Unterstützung der Teamarbeit durch Informations- und
Kommunikationstechniken befasst.
Im Gegensatz zur CSCW-Forschung, die als wissenschaftliche Disziplin beschrieben
wird, fällt es schwerer, den Begriff Groupware zu definieren, da dieser sich noch
stark im Wandel befindet [vgl. Nastansky/Bruse/Haberstock/Huth/Smolnik 2000, S.
239]. In der Literatur werden unter dem Begriff Groupware Softwaresysteme bzw.
Applikationen bezeichnet, die in ihrer Konzeption berücksichtigt haben, dass mehr
als ein Anwender an einem Problem beschäftigt ist [vgl. Koch/Zielke 1996]. In
diesem Sinne wird der Begriff Groupware auch in dieser Arbeit verstanden, d.h. als
2 Grundlagen Seite 5
Groupware werden Applikationen bezeichnet, die computerunterstütztes
kooperatives Arbeiten ermöglichen.
Nastansky [1993, S. 6] beschreibt Groupware folgendermaßen: „Groupware stellt
computergestützte Konzepte für die Teamarbeit bereit. Insbesondere müssen
dabei, natürlich, der Arbeitsfluss und das Vorgangsmanagement in den
vielfältigen Kommunikations- und Arbeitsinteraktionen zwischen
Mitarbeiterinnen und Mitarbeitern im Office Bereich bzw. in Projektteams
unterstützt werden.“
Groupware-Applikationen lassen sich anhand der zeitlichen und örtlichen Verteilung
von Gruppenarbeit aufteilen. Es entsteht so eine Raum-Zeit-Matrix
[Teufel/Sauter/Mühlherr/Bauknecht 1995, S. 24 ] in der sich Groupware-
Applikationen klassifizieren lassen (Abbildung 2-1).
Zusa
mm
enar
beit
der T
eam
mitg
liede
r
an v
ersc
hied
enen
Orte
n
am
gle
iche
n O
rt
(dez
entra
l)
(zen
tral)
Zusammenarbeit der Teammitglieder
zu gleichen Zeit zu verschiedenen Zeiten (synchron) (asynchron)
• Audio- und Videokonferenzsysteme
• Screen-Sharing-Systeme • Mehrautorensysteme
• Systeme Zur Terminkalendermanagement für Gruppen
• Projektmanagement-Systeme
• Systeme zur computerunterstützten Sitzungsmoderation
• Präsentationssysteme • Group Decision Support
Systems
• E-Mail-Systeme • Voice-Mail-Systeme • Systeme für Electronic
Conferencing • Elektronische Bulletin Boards • Shared Information Systems • Workflow-Systeme
Abbildung 2-1: Groupware-Typen und -Werkzeuge3
Im klassischen Verständnis der Gruppenarbeit fand das Zusammenarbeiten immer
zur gleichen Zeit am gleichen Ort statt. Die zentrale und synchrone Gruppenarbeit
wurde insbesondere durch Systeme zur computergestützten Sitzungsmoderation
sowie Präsentationssystemen unterstützt. Das zeitliche und örtliche Zusammenfallen
3 vgl. [Teufel/Sauter/Mühlherr/Bauknecht 1995, S. 24]
2 Grundlagen Seite 6
der Gruppenarbeit erwies sich oftmals als schwierig. Terminüberschneidungen sowie
verschiedene Arbeitszyklen waren hierfür oft verantwortlich. Durch die Entwicklung
immer leistungsstärkerer Hardware und den Einsatz von CSCW-Systemen, wie E-
Mail-Systeme oder elektronische Bulletin Boards, wird das zeitliche und räumliche
Zusammenfallen von Gruppenarbeit entzerrt (Abbildung 2-1), was letztlich zu einer
Flexibilitätssteigerung der Gruppe führt.
Eine weitere Klassifizierung von Groupware-Applikationen, unabhängig von der
eingesetzten Technologie, kann in ihrer Unterstützungsfunktion der Gruppenarbeit
gesehen werden.
„Um aber eine feinere und von der Technologie unabhängige Einteilung von
CSCW-Applikationen zu erhalten, müssen als Charakteristika die
Unterstützungsfunktionen der Gruppenarbeit – Kommunikation, Koordination und
Kooperation – verwendet werden.“ [Teufel 1996, S. 40]
Die Kommunikation umfasst die Weiterleitung bzw. Übermittlung von Informationen
zwischen Personen, Personen und Applikationen sowie zwischen Applikationen.
Darüber hinaus informieren sich die Beteiligten fortlaufend über den Zustand ihrer
Zusammenarbeit. Klassische Kommunikationsunterstützungssysteme sind E-Mail-
Systeme zur elektronischen Nachrichtenweiterleitung.
Die Kooperation stellt den Informationsaustausch mit einen gemeinsamen Ziel dar.
Sie baut auf der Dimension der Kommunikation auf und bedingt mindestens zwei
Personen, die kooperativ an einem Ziel zusammenarbeiten. Klassische Systeme zur
Unterstützung der Kooperation sind Datenbanken, auf die gemeinsam zugegriffen
werden kann. Die Veränderung und Erweiterung des Datenbestandes folgt keinem
Ablaufschema und geschieht nicht notwendigerweise sequenziell.
Die Koordination baut auf der Kommunikation und Koordination auf und stellt die
effiziente Ressourcenverteilung dar. Koordination ist somit die Abstimmung von
Handlungen und Entscheidungen zwischen den beteiligten Personen bzw.
Organisationseinheiten zur optimalen Zielerreichung.
[vgl. Nastansky/Bruse/Haberstock/Huth/Smolnik 2000, S. 240-243]
2 Grundlagen Seite 7
Das Klassifikationsschema nach der Unterstützungsfunktion der Kommunikation,
Kooperation und Koordination sowie die einzelnen Positionierungen verschiedener
Groupware-Anwendungen werden in Abbildung 2-2 dargestellt.
Kommunikations-unterstützung
Koordinations-unterstützung
Kooperations- unterstützung
Gruppen- editoren
Verteilte Hypertext- Systeme
Entscheidungs- und Sitzungs-
unterstützungs- systeme
Planungs- Systeme
Workflow Management- Werkzeuge
spez. Daten- banken
Video- konferenz- systeme
Bulletin Board-
Systeme
Systemklassen:
Kommunikation
Gemeinsame Informationsräume
Workgroup Computing
Workflow Management
Abbildung 2-2: Klassifikationschema nach Unterstützungsfunktionen4
Je nach Ausprägung der Unterstützungsfunktionen lassen sich ähnliche Groupware-
Anwendungen zur Systemklassen zusammenfügen.
Systeme des Workflow-Management unterstützen bei räumlich und zeitlich verteilten
Arbeitsgruppen die Zusammenarbeit nach genau definierten Methoden und Regeln.
Als Workflow
„wird die zeitliche-strukturelle Aneinanderreihung von einzelnen, zur Bearbeitung
eines Gesamtvorgangs notwendigen Teilaufgaben verstanden.“
[Nastansky/Bruse/Haberstock/Huth/Smolnik 2000, S. 239]
Zu den Aufgaben des Workflow-Managements gehören die Modellierung, die
Simulation sowie die Ausführung und Steuerung von Workflows.
4 vgl. [Teufel/Sauter/Mühlherr/Bauknecht 1995, S. 154] und [Teufel 1996, S. 41]
2 Grundlagen Seite 8
Unter Workgroup Computing wird die Unterstützung von zeitlich befristeten
Arbeitsgruppen, meist Projektgruppen, mit dem Ziel einer selbstständigen
Gruppenarbeit verstanden.
In der Systemklasse der gemeinsamen Informationsräume lassen sich Anwendungen
zusammenfassen, die der Verteilung von Informationen dienen. Hier wird der Zugriff
auf gemeinsame Informationsbestände ermöglicht.
Die letzte Systemklasse ist die der Kommunikation. Hier werden vor allem Systeme
der elektronischen Nachrichten- bzw. Dokumentenübermittlung zusammengefasst.
Die hier vorgestellten Klassifikationsschemata sollen die Positionierung von
Workflow-Management innerhalb der CSCW-Forschung wiedergeben. Eine
ausführliche Darstellung der CSCW-Forschung findet sich z.B. bei
[Hasenkamp/Syring 1994] oder [Teufel/Sauter/Mühlherr/Bauknecht 1995].
2.2 Workflow-Terminologie
In diesem Abschnitt werden zentrale Termini, die zum Verständnis der vorliegenden
Arbeit benötigt werden, näher definiert. Hierfür wird auf das Workflow-
Referenzmodell der Workflow Management Coalition (WfMC) zurückgegriffen. Der
WfMC wurde im Jahr 1993 gegründet; ihr gehören wichtige Hersteller und große
Anwender von WfMS sowie einige Beratungsunternehmen und Forschungsinstitute
an. Es sind mehr als 100 Organisationen, die dieses Gremium tragen.
„Die WfWC hat das Ziel, die Verbreitung von WFMS zu fördern, indem
Standards für die Terminologie des Workflow Management im Allgemeinen
sowie Schnittstellen von WFMS im Speziellen entwickelt und etabliert werden.“
[Sauter/Morger 1996, S 228]
Wie bereits erwähnt, entwickelte die WfMC ein Workflow Reference Model, das hier
im Einzelnen vorgestellt werden soll (Abbildung 2-3). Die WfMC definiert das
Workflow Reference Model wie folgt:
„An architectural representation of a workflow management system, identifying
the most important system interfaces, developed by the Workflow Management
Coalition.” [WfMC 1996, S. 21]
2 Grundlagen Seite 9
Workflow-Management-Systeme werden wie folgt definiert:
„A system that, defines, creates and manages the execution of works through the
use of software, running on or more workflow engines, which is able to interpret
the process definition, interact with participants and, where required, invoke the
use of IT tools and applications.“ [WfMC 1996 S. 8]
Workflows sind zentrale Objekte von Workflow Management Systemen, diese
definiert die WfMC wie folgt:
„The automation of business process, in whole or part, during which documents,
information or tasks are passed from one participant to another for action,
according to set of procedural rules.” [WfMC 1996 S. 7]
Workflow API and Interchange formats
Process Defination Tools
Invoked Application
WorkflowClient
Application
Administration& Monitoring
Tools
Workflow Enactment Service
Workflow Engine(s)
Other Workflow Enactment Service(s)
Workflow Engine(s)
Interface 1
Interface 5
Interface 4
Interface 2 Interface 3
Abbildung 2-3: Workflow Reference Model5
Das Workflow Reference Model definiert also die wichtigsten Schnittstellen
(Interface), die ein Workflow Management System beschreiben und ermöglicht somit
die konzeptionelle Betrachtung dieser Bestandteile.
Zu diesen Schnittstellen gehören:
• Die Process Definition Tools (Modellierungswerkzeuge) unterstützen die
Analyse, das Modellieren sowie die Simulation von Geschäftsprozessen. Mit
2 Grundlagen Seite 10
ihnen werden Workflows erstellt und in geeigneter Form abgelegt, wo sie für
die Ausführung zur Verfügung stehen.
• Unter Administration & Monitoring Tools (Administrations- und
Überwachungswerkzeuge) werden Werkzeuge verstanden, die zum Zwecke
der Analyse während der Laufzeit Daten auswerten.
• Der Workflow Enactment Service (Workflow Laufzeitumgebung) interpretiert
die von Process Definition Tools zur Verfügung gestellten
Modellierungsdaten mittels einer oder mehrerer Workflow Engines, steuert
und kontrolliert die Ausführung der Workflows nach den dort definierten
Regeln und Methoden während der Laufzeit.
• Die Workflow Client Applications (Workflow Client Applikationen) bilden
die Schnittstelle des Systems zum Bearbeiter. Erst durch sie wird die
Interaktion zwischen der Anwendung und dem Benutzer möglich.
• Als Invoked Application (Aufrufbare Applikationen) werden Anwendungen
genannt, die teilweise oder vollständig die Bearbeitung von Arbeitsschritten
durchführen oder den Anwender unterstützen.
Als Workflow-Management-Systeme werden rechnergestützte Systeme bezeichnet,
die die Ausführung von Workflows überwachen und aktiv steuern. Dabei ermitteln
sie nach bestimmten Regeln und Methoden, die in der Prozessdefinition festgelegt
sind, den jeweiligen nächsten Arbeitsschritt sowie den nächsten Bearbeiter. Sie
stellen weiterhin alle notwendigen Informationen zur Verfügung und überwachen die
termingerechte Erledigung.
Ein Workflow ist das Abbild eines Geschäftsprozesses, in seiner Gesamtheit oder
auch in einem Teilbereich, das aus verschiedenen Arbeitsschritten, die nach
bestimmten Regeln zu einem Netzwerk zusammengefügt sind, besteht und den
Zweck der Erreichung gemeinschaftlicher Geschäftsziele verfolgt.
Da im Allgemeinen unter Workflow sowohl der zur Ausführung stehende Vorgang
als auch das elektronische Abbild des Geschäftsprozesses verstanden wird, werden
5 vgl. [WfMC 1994, S. 20] und [WfMC 1996, S. 21]
2 Grundlagen Seite 11
die Termini Workflow-Klasse und Workflow-Instanz eingeführt und abgegrenzt. Die
hier verwendeten Begriffe Klasse und Instanz sind dem Konzept der
Objektorientierung in der Informatik entnommen. Als Workflow-Klasse wird in
dieser Arbeit somit die Gesamtheit aller möglichen Arbeitspfade dieser Klasse, die
eine Vielzahl ähnlicher Vorgänge ermöglicht, verstanden. Als Workflow-Instanz
wird die durch Initialisierung und Bearbeitung eines Workflows realisierte
Untermenge aller vorhandenen bzw. möglichen Arbeitspfade einer Workflow-Klasse
verstanden.
Wenn wir uns beispielsweise die „Erstellung eines Angebotes über einen Pkw“ mit
all seinen Ausprägungen als Workflow-Klasse vorstellen, so wäre die konkrete
Ausprägung „Erstellung eines Angebotes über einen VW Polo für Herrn Meier“ die
realisierte Workflow-Instanz.
Die WfMC bezeichnet die Workflow-Klasse als Process Definition und definiert
diese wie folgt:
„The representation of a business process in a form which supports automated
manipulation, such as modelling, or enactment by a workflow management
system. The Process definition consists of a network of activities and their
relationships, criteria to indicate the start and termination of the process, and
information about the individual activities, such as participants, associated IT
applications and data, etc.” [WfMC 1996, S. 10]
Die Definition der Workflow-Instanz findet sich unter dem Begriff Instance (as in
Process or Activity Instance) der WfMC wieder:
„The representation of a single enactment of a process, or activity within a
process, including its associated data. Each instance represent a separate thread of
execution of the process or activity, which may be controlled independently and
will have its own internal state and externally visible identity, which may be used
as a handle…” [WfMC 1996, S. 13]
Im weiteren Verlauf dieser Arbeit werden die Begriffe Vorgangsstruktur, Workflow-
Modell synonym für Workflow-Klasse und die Termini Vorgang, Workflow
synonym für Workflow-Instanz verwendet.
2 Grundlagen Seite 12
Weitere ausführliche Informationen zur WfMC finden sich unter anderen in [WfMC
1994] und [WfMC 1996] sowie in [WfMC 2000].
2.3 Groupware-Umgebung Lotus Notes
Als Basis für die Realisierung der prototypischen Workflow-Engine wurde die
Groupware-Plattform Lotus Notes gewählt, die zum Zeitpunkt dieser Arbeit in der
Version 5.05 vorlag. Dieser Abschnitt gibt einen Überblick über die wichtigsten
Architekturmerkmale dieser Entwicklungsplattform.
Client-Server Architektur
”Bei einer Client-Server-Architektur halten die Server den Datenbankkern und
übernehmen das Datenbankmanagement. Die dezentralen Arbeitsstationen (Clients)
stellen Anfragen an die Datenbank und führen die Bearbeitung und Präsentation
(Grafik, Windowing) der Daten gegebenenfalls mit anderen Anwendungssystemen
durch.“ [Herold/Fischer 1994, S. 183]
Durch die große Anzahl von unterstützten Betriebssystemen sowohl auf der Server-
als auch auf der Client-Seite lässt sich Lotus Notes hervorragend in heterogenen
WAN/LAN-Umgebungen einsetzen.
Verbunddokument (Compound Documents)
Das Verbunddokument dient als Container für alle Arten von Informationen. Es kann
strukturierte, sogenannte harte Daten, wie Text, Zahl, Zeitangaben als auch
unstrukturierte, sogenannte weiche Daten, wie Multimedia-Daten, in sich aufnehmen.
Dies wird durch den Einsatz von Rich-Text-Feldern ermöglicht, die formatierte
Texte, Grafiken, OLE-Objekte und sogar ganze Dateien als Anhänge (Attachment)
sowie Dokumentenverknüpfungen (Doclinks) und Schaltflächen (Buttons), die
bestimmte Funktionalitäten enthalten, beinhalten können. Verbunddokumente
werden in Datenbanken verwaltet. Eine Lotus Notes Datenbank besteht aus Masken,
Ansichten und Ordnern, Aktionen und Navigatoren bzw. Seiten mit eingebetteter
Gliederung.
2 Grundlagen Seite 13
"Compound Document"
Print Send
Verbund-Dokumente
Auftrags-Nr.a/34747-96Budget-Sum me100.000,- DM
Bedienelemente und Verarbeitungslogik
Feldorientierte Daten
Frei formatierbare Bereiche mit Informationsobjekten
Grafische Repräsentation
Abbildung 2-4: Aufbau Verbunddokument6
Masken (Forms) und Seiten
Die Ausgabe dieser Verbunddokumente auf Bildschirm bzw. Drucken, also die
grafische Präsentation, übernehmen Masken (Abbildung 2-5, Bereich 1). Masken
haben unter anderem die Aufgabe, Informationen zu filtern, Eingaben zu erläutern
und diese nach bestimmten Regeln zu validieren. Die Informationsfilterung geschieht
durch den Einsatz verschiedener Masken für ein und dasselbe Verbunddokument. So
können diese Masken unterschiedliche Felder beinhalten und dementsprechend nur
diese Informationen anzeigen. Auch der Einsatz sogenannter Teilmasken (Subforms)
kann zur Informationsfilterung genutzt werden. Masken können nämlich Teilmasken
beinhalten, die fest oder nach bestimmen Regeln eingebunden werden. Seiten sind
ein Gestaltungselement, das erst ab der Version 5 zur Verfügung steht. Sie können
Text, Grafiken, eingebettete Elemente, OLE-Objekte, Anhänge, Java-Applets,
Aktionen und Verknüpfungen enthalten. Seiten können - im Gegensatz zu Masken -
keine Informationen erfassen. Felder, Teilmasken, Layout-Bereiche sowie einige
eingebettete Steuerelemente können ausschließlich in Masken verwendet werden.
Ansichten (Views) und Ordner (Folder)
Zur strukturierten Darstellung der Dokumente einer Datenbank werden Ansicht und
Ordner benutzt (Abbildung 2-5, Bereich 2). Diese stellen die Informationen
kategorisiert in Listenform dar und erlauben so ein schnelles Auffinden der
6 vgl. [Media Center, 1 Materialien\3 Groupware, 03. Aufbau von Verbunddokumenten]
2 Grundlagen Seite 14
gewünschten Daten. Ansichten können entweder alle Dokumente anzeigen oder nur
eine Teilmenge, die durch Auswahlkriterien bestimmt wird. Der Ordner ist eine
besondere Form von Ansichten, der nicht notwendigerweise alle Dokumente einer
Datenbank enthalten muss. Der Inhalt dieser Ordner wird von den Benutzern selbst
gestaltet und ist mit traditionellen Ablagefächern zu vergleichen. Da Datenbanken
von einer Vielzahl von Anwendern benutzt werden, gibt es zusätzlich die
Möglichkeit, persönliche Ansichten anzulegen. Diese Ansichten sind nur für den
individuellen Benutzer sichtbar und benutzbar.
Abbildung 2-5: Ansicht einer Lotus Notes Datenbank
Aktionen (Actions)
Eine spezielle Form der Interaktion bilden die Aktionen (Actions) (Abbildung 2-5,
Bereich 3). Diese befinden sich sichtbar oberhalb der Maske bzw. der Ansicht oder
des Ordners in einer Aktionsleiste und bieten dort ihre Funktionen an. Sie sind
entweder immer sichtbar oder werden nach bestimmten Kriterien ein- und
ausgeblendet, z.B. nur sichtbar im Bearbeitungsmodus oder nur sichtbar im
Lesemodus.
Navigatoren und Gliederungen
Da eine Datenbank eine Vielzahl von Ansichten und Ordnern enthalten kann, werden
zur Organisation dieser Ansichten Navigatoren bzw. Seiten mit eingebetteten
2 Grundlagen Seite 15
Gliederungen (Abbildung 2-5, Bereich 4) eingesetzt. Eine Datenbank verfügt
mindestens über einen Standardnavigator, der die Ansichten in alphabetischer
Reihenfolge auflistet. Weiterhin lassen sich neue Navigatoren erstellen, die grafisch
aufbereitet werden können, um beispielsweise die Navigation durch die Datenbank
zu erleichtern. Ab der Version 5 können zusätzlich auf Seiten eingebettete
Gliederungen eingefügt werden, die auch eine grafische Aufbereitung der Navigation
zulassen.
Agenten (Agents)
Agenten ermöglichen die ereignis- oder zeitgesteuerte Ausführung von Funktionen.
Bei der ereignisgesteuerten Ausführung von Agenten handelt es sich entweder um
manuell ausgelöste Aktionen durch den Benutzer oder um Events (Ereignisse), die
unter anderem beim Öffnen, Speichern und Einfügen von Dokumenten ausgelöst
werden. Die zeitgesteuerte, meist periodische, Ausführung von Agenten ist vor allem
zu Statistikzwecken und zur Terminüberwachung geeignet. Agenten können sowohl
auf der Client- als auch auf der Serverseite aufgeführt werden. Sie können alle
Dokumente einer Datenbank oder nur eine Teilmenge automatisch bearbeiten.
Sicherheitsmechanismus
Um sensible Daten zu schützen, verfügt Lotus Notes über einen differenzierten
Sicherheitsmechanismus, der vom Serverzugriff über Datenbank- und
Dokumentenzugriff bis hin zur Feldebene greift (Abbildung 2-6). Dabei kommen
verschiedene Konzepte zum Einsatz. Beim Zugriff auf den Server wird die
Authentizität der Nutzer über die Benutzer-ID sichergestellt. Den Zugriff auf
Datenbanken steuern Zugriffskontrolllisten (Access Control List, ACL). Die ACL
unterscheidet folgende Zugriffsrechte auf eine Datenbank: Manager, Designer,
Editor, Autor, Leser und Kein Zugriff. Weiterhin lässt sich der Zugriff auf Ansichten
und Masken einschränken. Sogenannte Leser-Felder steuern den Zugriff auf der
Dokumentenebene. Außer der Zugriffskontrolle besteht die Möglichkeit der
Datenverschlüsselung, die mittels RSA-Verfahren7 realisiert wird.
7 RSA-Syteme (R. Rivest, A. Shamir, L. Adleman, 1978) sind Kryptosysteme , bei denen die Verschlüsselung über öffentliche Schlüssel (Public-Key), die frei zugänglich sind, und die Entschlüsselung über private Schlüssel (Private-Key), die geheim sind, sichergestellt wird. Diese Verfahren werden auch als Zwei-Schlüssel-Verfahren bezeichnet.
2 Grundlagen Seite 16
Abbildung 2-6: Sicherheitsebenen8
Replikation
Die dezentrale Datenhaltung wird bei Lotus Notes durch das Replikationssystem
ermöglicht. Bei Lotus Notes können viele Repliken einer Datenbank räumlich verteilt
auf Servern bzw. Clients existieren. Diese Repliken sind eigenständige Datenbanken,
die durch eine Replik-ID miteinander verknüpft sind. Bei der Replikation werden
Datenänderung auf Feldebene und Gestaltungsänderung unter den Repliken
synchronisiert. So wird der mobile Einsatz der Datenbanken sichergestellt, d.h. um
mit diesen Datenbanken zu arbeiten, muss nicht zwangsläufig eine Verbindung zum
Server bestehen.
Integriertes Kommunikationssystem
Das integrierte Kommunikationssystem von Lotus Notes ermöglicht das Empfangen
und Senden von elektronischen Mitteilungen. Außerdem kann auch jede Datenbank
Dokumente empfangen und versenden.
Einfache Aktionen (Simple Actions)
Lotus Notes stellt zur Erstellung von Anwendungen eine integrierte
Entwicklungsumgebung, auf die im weiteren eingegangen werden soll. Einfache
Aktionen bestehen aus einer Liste vorgegebener Funktionen, die sich besonders an
ungeübte Benutzer richten. Mit ihnen lassen sich einfache Aufgaben lösen.
8 vgl. [Media Center, 1 Materialien\3 Groupware, 04.02 Sicherheitsebenen]
2 Grundlagen Seite 17
@Funktionen (@Functions)
Diese hochentwickelten Funktionen und Befehle richten sich vor allem an erfahrene
Benutzer. Mit ihrer Hilfe können mittelschwere Aufgaben in kürzester Zeit gelöst
werden. Diese @Funktionen und @Befehle bilden die Grundlage der Makrosprache
von Lotus Notes.
Abbildung 2-7: Entwicklungsumgebung von Lotus Notes
LotusScript
LotusScript ist eine objektorientierte Programmiersprache, die plattformunabhängig
das Verhalten von Lotus Notes beeinflussen kann. Sie verfügt über eine Reihe von
Objektklassen, die von der Datenbankebene über Ansichten- und Masken- bis hin zur
Feldebene einsetzbar sind. Es lassen sich Script-Bibliotheken (Script Libraries)
erstellen, die das Wiederverwenden von Funktionen und Prozeduren bzw.
Programmcode-Teilen ermöglichen. Neben der oben vorgestellten Makrosprache
bildet LotusScript einen Grundpfeiler der Programmierumgebung.
Java
Seit der Version 5 stellt Lotus Notes als einen weiteren Grundpfeiler seiner
Entwicklungsumgebung Java-Klassen zur Verfügung. Auch diese Objektklassen
ermöglichen eine weitreichende Beeinflussung des Verhaltens von Lotus Notes und
sollen die Plattformunabhängigkeit des Systems unterstützen.
2 Grundlagen Seite 18
API-Schnittstellen
C-API und C++-API sind nur einige der Schnittstellen, die Lotus Notes zu
Verfügung stellt. Entwickler externer Anwendungen können über diese auf dem
gesamten Funktionsbereich von Lotus Notes zurückgreifen.
Durch die hier beschriebenen Architekturmerkmale lassen sich mit Lotus Notes
Anwendungen von klassischen Diskussionsforen bis hin zu Workflow Management
Systemen realisieren.
Ausführliche Informationen über Lotus Notes finden sich in [Lotus Dev. 2000a,
2000b, 2000c, 2000d und 2000e].
2.4 Office- und Workflow-Management-System PAVONE Espresso
PAVONE Espresso ist ein gruppenbasiertes Office-, Knowledge- und Workflow-
Management-System auf Basis von Lotus Notes. Das System umfasst vier
Datenbanken und zwei externe Werkzeuge, die für die Planung und Ausführung von
Workflows verantwortlich sind (vgl. Abbildung 2-8). Die externen Werkzeuge
OrganizationModeler und ProcessModeler sind für die Gestaltung der Aufbau- und
Ablaufstruktur zuständig und können auch als Planungsmodule bezeichnet werden.
Als Ausführungsmodul kann die Datenbank Anwendung bezeichnet werden, indem
die Laufzeitumgebung des Systems integriert ist. Weiterhin arbeitet auch der
Benutzer der Anwendung mit dieser Datenbank.
2.4.1 Espresso Umgebung
Espresso Anwendung
Die Datenbank Anwendung kann als zentrales Modul des Systems gesehen werden.
Der Endanwender kommt in der Regel nur mit dieser Datenbank in Berührung. Die
Espresso Anwendung dient der Aufzeichnung und Verwaltung sämtlicher
Geschäftsvorfälle und Dokumente, der Kommunikation zwischen den
Organisationsmitgliedern, dem Management von Vorgängen und der Überwachung
der termingerechten Ausführung von einzelnen Aufgaben. Diese Datenbank
beinhaltet ein Adress- und Korrespondenzmanagement, das die Verwaltung von
Kundenadressen sowie die elektronische Kommunikation ermöglicht. Das
2 Grundlagen Seite 19
implementierte Workflow-Management-System ermöglicht dem Benutzer neue
Vorgänge zu initialisieren und zu bearbeiten, die dann durch das System (Runtime-
Engine) an den nächsten Bearbeiter weitergeleitet werden. Dabei greift die Runtime-
Engine auf die anderen Datenbanken zurück. Aus der Datenbank Vorgangstyp
werden die benötigten ablauforganisatorischen Informationen (nächste Aufgaben)
und aus der Datenbank Organisation die aufbauorganisatorischen Informationen
(nächster Bearbeiter) entnommen. Die Datenbank kann auch als die operative
Datenbank dieses Systems betrachtet werden.
Espresso Datenbanken
Espresso Externe Tools
ProcessModeler OrganizationModeler
Abbildung 2-8: Kompanenten der Espresso-Umgebung9
Espresso Vorgangstyp
Hier werden die Vorgangsstrukturen der einzelnen Workflows gespeichert und
verwaltet. Eine Struktur beschreibt den Ablauf eines Workflow in seiner gesamten
Komplexität. Sie wird mit Hilfe des externen Programms PAVONE ProcessModeler
erstellt und weiterentwickelt. In der Datenbank Vorgangstyp werden sowohl aktive
Vorgänge als auch sogenannte "eingefrorene" und im Design befindliche Vorgänge
verwaltet.
9 vgl. [Nastansky/Bruse/Haberstock/Huth/Smolnik 2000, S. 261]
2 Grundlagen Seite 20
Espresso Organisation
In dieser Datenbank werden alle Ressourcen, d.h. Personen und Sachressourcen, der
Espresso-Umgebung verwaltet.
Eine Person wird durch einen Namen repräsentiert. Sie kann zu Abteilungen,
Arbeitsgruppen und Rollen zugeordnet werden. Diese Zuordnungen werden während
der Laufzeit, z.B. zur Festlegung des nächsten Bearbeiters, benötigt. Weiterhin
werden hier auch Sachressourcen verwaltet, die für bestimmte Aufgaben notwendig
sind.
Espresso Vorlagen
In der Datenbank Vorlagen werden vorgefertigte Dokumententypen, Listeneinträge
und Briefköpfe hinterlegt. Diese werden zur Laufzeit von der Datenbank Anwendung
nach Bedarf ausgelesen und verarbeitet.
2.4.2 Espresso und Ad-hoc-Workflow-Management
Das GroupFlow-Kontinuum [Nastansky/Hilpert 1994, S. 5] stellt ein breites
Spektrum möglicher Ausprägungen von Vorgängen dar. Dieses Kontinuum (vgl.
Tabelle 2-1) unterscheidet Vorgangsarten angefangen von flexiblen, offenen, ad-hoc-
entstandenen Vorgängen über semi-strukturierte Abläufe bis hin zu feststrukturierten
Workflows.
Beim Ad-hoc-Workflow handelt es sich um unstrukturierte Vorgänge, die sich aus
dem laufenden Geschäft ergeben, nur einmal auftreten oder so variieren, dass sie
nicht vorhersehbar sind. Der Benutzer kann den Ablauf weitgehend selbst definieren.
Ein solcher einmaliger, meist kurzlebiger Prozess in einer Organisation wäre z.B.
eine spezielle Kundenanfrage.
Bei Task-Force sind die Aufgaben stärker strukturiert und spezifiziert. Die jeweilige
Bearbeitungsreihenfolge bleibt jedoch offen, so dass die Gruppenmitglieder die
Arbeitsabläufe eigenverantwortlich organisieren.
Semi-strukturierte Workflows sind durch eine vordefinierte Vorgangsstruktur
gekennzeichnet. Sie lassen sich nach Art der Abweichung weiter differenzieren.
2 Grundlagen Seite 21
Das GroupFlow-Kontinuum
Ad-hoc-Workflow
Task Force Semi-strukturierter Workflow Standard-Workflow
E-Mail basiert
Nicht vorher- bestimmter Workflow
Offene Teambearbeitung
im vorgegebenem Vorgang
Kontrollierte Teambearbeitung
im vorgegebenem Vorgang
Ad-hoc-Ausnahme
eines vorgegebenen
Vorgangs
Fest strukturierter Workflow
Nutzung v on E-Mail, „Store-and-f orward“-Sy stemen
Gemeinsame Daten-bank mit wahlweisem Zugrif f
Kombination v on v or-gegebenem Vorgang mit of f enen Gruppen-prozess
Teilweise f reie Wahl-möglichkeit in sonst v orgegebenen Vorgang
Vorgegebener Vor-gang mit Möglichkei-ten f ür Ausnahmen
Prinzipielle Vorgabe des nächsten Bearbeiters
• dringend • kurzlebig • in Ausnahmef ällen • v ertraulich
• gemeinsamer Zugrif f • gemeinsame
Auf gabe
• def inierter Eingang • def inierter Ausgang • dazwischen keine Ablauf regeln
• eine v orgegebene Anzahl v on Gruppen-mitglieder
• n v on m Mitglieder müssen bearbeiten, aber nicht auf best. Personen
• Regeln f ür Ausnah-men f estgelegt
• Flexiblere Reaktion auf Besonderheiten
• Of t wiederholte Vorgänge
• Wohl strukturiert • Vorhersehbare Situation
Beispiel: Neuartiger Auf trag
Beispiel: Gemeinsame Gestal-tung eines Buches
Beispiel: Gemeinsame Erstel-lung eines Berichtes in lauf endem Vorgang
Beispiel: Mehrf ache Abzeich-nung erf orderlich
Beispiel: Bearbeitung eines Kreditantrages bei Sonderwünschen
Beispiel: Bearbeitung eines Kreditantrages
flexibel, veränderlich, einmalig vorgegeben, strukturiert, wiederkehrend
Tabelle 2-1: GroupFlow-Kontinuum10
Ein Standard-Workflow ist ein vollständig fest vordefinierter Vorgang. Er weist eine
hohe Wiederholrate und einen hohen Formalisierungsgrad auf.
Das Espresso-System unterstützt die Vorgangsbearbeitung sowohl in dem Bereich
Standard-Workflow als auch im Ad-hoc-Workflow-Bereich. Somit werden zwei
Workflow-Arten des oben vorgestellten Workflow-Kontinuums direkt unterstützt.
Bei den Standard-Workflows wird zuerst mit Hilfe des ProcessModelers ein
Workflow-Metamodell grafisch modelliert, zur Analyse simuliert und in der
Datenbank Vorgangstyp gespeichert. Der dort gespeicherte Vorgangstyp wird dann
beim Initialisieren einer neuen Workflow-Instanz in der Datenbank Anwendung
verwendet.
Die Ad-hoc-Vorgänge werden im Gegensatz zu Standard-Workflows auch ohne
vorherige Modellierung direkt in der Datenbank Anwendung unterstützt. Sie können
jederzeit auf alle Arten von Dokumenten und innerhalb von strukturierten
Workflows zum Einsatz kommen. Hierzu werden während der Laufzeit weitere
10 vgl. [Nastansky/Hilpert 1994, S. 5]
2 Grundlagen Seite 22
Aufgaben hinzugefügt. Diese enthalten neben der Bezeichnung eine Beschreibung
und den zuständigen Bearbeiter (Abbildung. 2-9).
Abbildung 2-9: Hinzufügen von Ad-hoc-Aufgaben im Espresso-System
Die Workflow-Engine überprüft generell beim Initialisieren des nächsten
Vorgangsknoten, ob Aufgaben des Typs Ad hoc vorhanden sind und arbeitet diese
zuerst ab, und zwar solange, bis keine Ad hoc Aufgaben mehr vorhanden sind. Die
Verarbeitung wird ausschließlich linear vollzogen. Eine Spaltung (Split) der Aufgabe
auf mehrere Bearbeiter, um eine parallele Bearbeitung zu ermöglichen, wird zur Zeit
nicht unterstützt.
Das hier im weiteren Verlauf vorzustellende GroupProcess-Konzept und die damit
verbundene prototypische Realisierung soll als eine Erweiterung von bestehenden
Workflow Management Systemen (in dieser Arbeit dem Espresso-System)
verstanden werden.
„Wir sind der Meinung, dass bestehende und in der Praxis bewährte Systeme
genutzt und um die hier vorgestellten neuen Aspekte ergänzt werden sollen, statt
ein vollständiges System neu zu implementieren.“
[Huth/Nastansky 2000b, S. 5]
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 23
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System; das GroupProcess-Konzept
In diesem Kapitel wird zuerst das GroupProcess-Kontinuum vorgestellt, um im
weiteren Verlauf auf die einzelnen konzeptionellen Ansätze, Merkmale und
Anforderungen eines Ad-hoc-Workflow-Management-Systems besser eingehen zu
können.
3.1 GroupProcess-Kontinuum
Ausgangspunkt des GroupProcess-Kontinuums ist das im vorherigen Kapitel
vorgestellte GroupFlow-Kontinuum [Nastansky/Hilpert 1994, S. 5]. Um den
Anforderungen des GroupProcess-Konzeptes zu genügen, wurde dieses Kontinuum
entsprechend ergänzt und weiterentwickelt. Das Kontinuum soll darstellen, welche
Arten von Workflows durch bestehende Workflow-Management-Systeme und
welche durch den GroupProcess-Ansatz unterstützt werden sollen.
Das GroupProcess-Kontinuum umfasst verschiedene Workflow-Arten, die im
Folgenden in ihren Details und Sub-Strukturen betrachtet werden. Tabelle 3-1 gibt
eine Übersicht über die Basistypen und deren Sub-Strukturen.
(1a) Ad-hoc-Workflows
Bei Ad-hoc-Workflows handelt es sich um kurzlebige, üblicherweise einmalige
Vorgänge. Diese sind ihrer Natur nach kaum zu strukturieren und variieren stark in
ihrer Komplexität. In der Praxis zeigt sich aber, dass solche Prozesse eher von
geringer Komplexität sind. Derartige Workflows ergeben sich aus dem laufenden
Geschäft und sind in der Regel spontan sowie dringend und im einzelnen auch
vertraulich. Die Automatisierung von Workflows dieser Art wurde bis zum
GroupProcess-Ansatz als nicht lohnenswert angesehen. Es ist aber durchaus möglich,
dass Ad-hoc-Workflows in Teilen oder insgesamt in ähnlicher Form erneut auftreten
können. Ein Beispielszenario aus der Praxis wäre die Erneuerung der Computer-
Hardware für ein 10 Personen großes Team. Ein solcher Vorgang tritt etwa alle drei
bis fünf Jahre auf. Zu den Aufgaben dieses Workflows gehören das Einholen der
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 24
Angebote, die Kalkulation und die Finanzierung. Dazu können auch Änderungen in
der Netzwerkinfrastruktur kommen. Der Vorteil eines Ad-hoc-Workflow-
Management-Systems wäre in diesem Beispielszenario nicht nur die
Wiederverwendbarkeit des Workflows, sondern auch deren Dokumentation. Die
Dokumentation kann für spätere Rückfragen sowie zur Analyse und Rationalisierung
verwendet werden. Diese reinen Ad-hoc-Workflows (Tabelle 3-1, Spalte 1a) werden
durch das GroupProcess-System unterstützt. Hierfür stehen dem System ein
Prozessmodellierungswerkzeug sowie eine Workflow-Engine (Bestandteil dieser
Arbeit) zur Verfügung, bei deren Entwicklung die spezifischen Charakteristika von
Ad-hoc-Prozessen berücksichtigt wurden.
Das GroupProcess-Kontinuum
1. Ad-hoc-Workflow 2. Semi-strukturierter Workflow
a) Ad-hoc-Workflows
b) Offene Team-
bearbeitung
innerhalb von Ad-hoc-
Workflow s
c) Ad-hoc-Workflows
mit einem Subw orkflow oder Cluster
a) Offene Team-
bearbeitung
innerhalb eines strukt. Workflow s
b) Ad-hoc-Sub-
Workflow
innerhalb eines strukt. Workflow s
c) Ad-hoc-Modifikation
eines strukt. Workflow s
3. Struktu-rierte vor- definierte Workflows
E-Mail, „Store-and-f orward“
oder
teilweise v ordef iniert
Kombination v on Ad-hoc- und Teambearbeitung in einem Ad-hoc-Workf low
Integration eines Sub-Workf lows innerhalb eines Ad-hoc-Workf lows
Kombination v on Teambearbeitung und v ordef iniertem Workf low inner-halb eines Workf lows
Vordef inierter Workf low mit einem Ad-hoc-geplanten und ausgef ührten Bestandteil
Vollständig v ordef inierter Workf low mit Ausnahme
Vollständig v ordef inierter Workf low
• dringend • kurzlebig • schwach strukturiert • v ertraulich
• hohe Wiederholungsf requenz • v ordef iniert • Ad hoc Änderungen / Re-Routing
• Hohe Wiederholungs-f requenz
• gut strukt. • v erdef iniert
Beispiel: neuer Ty p v on Anf rage
Beispiel: Co-Autorenschaf t eines Artikels
Beispiel: Delegierung, einer Auf gabe, Details der Auf gabenaus-f ührung sind aber unbekannt
Beispiel: Lösung v on Sof tware-Problemen
Beispiel: Co-Editierung eines Jahresberichts
Beispiel: Kreditantrag mit indiv idueller Anf rage des Kunden
Beispiel: Standard-Kreditantrag
flexibel, veränderlich, einmalig vorgegeben, strukturiert, wiederkehrend
Tendenz der zeitlichen Entwicklung von Prozessen
Tabelle 3-1: Das GroupProcess-Kontinuum11
11 vgl. [Huth/Nastansky 2000b, S. 5]
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 25
(1b) Offene Gruppenbearbeitung innerhalb von Ad hoc Workflows
Diese Art von Workflows enthält mindestens eine Teilaufgabe, die in Form von
Gruppenarbeit durchgeführt werden muss. Vor und nach der Gruppenarbeit befinden
sich ad-hoc-definierte Teilaufgaben. Eine Gruppenarbeit kann als Aufgabe definiert
werden, die von einem Team in kooperativer Weise erledigt wird [vgl. Abschnitt 2.1.
CSCW-Forschung und Groupware]. Workflows dieser Art (Tabelle 3-1, Spalte 1b)
werden durch GroupProcess ebenfalls direkt unterstützt. Für die Gruppenarbeit
werden Funktionalitäten der zugrunde liegenden Groupware-Plattform genutzt (hier
Lotus Notes/Domino).
(1c) Ad hoc Workflows mit einem Unterprozess oder Cluster
Für die Verwendung von Unterprozessen oder Cluster (Tabelle 3-1, Spalte 1c) gibt es
zwei Gründe. Zum einen kann die Komplexität von Workflow-Modellen reduziert
werden, indem man inhaltlich zusammenhängende Prozessbestandteile als eine
Aufgabe definiert. Diese Aufgabe wird dann später in einem Sub-Workflow-Modell
(Cluster) detaillierter und präziser festgelegt. Zum anderen können Ad-hoc-
Workflows Aufgaben beinhalten, die im Verantwortungsbereich von anderen
Abteilungen des Unternehmen liegen. Hier ist es meistens unbekannt, wie die andere
Organisationseinheit das Ziel der Aufgabenbearbeitung erreicht.
Jeder Knoten eines Workflow-Modells kann zum Unterprozess bzw. Cluster
umgewandelt werden. Durch den Einsatz dieser Technik können also komplexe
Workflow-Strukturen entstehen, für deren Modellierung durch herkömmliche
Workflow-Management-Systeme ein viel höherer Aufwand nötig gewesen wäre.
Auch dieser Typ von Workflows wird direkt durch GroupProcess unterstützt.
Die vorgestellten drei Kategorien von Workflows werden im GroupProcess
Kontinuum zur der Hauptkategorie Ad-hoc-Workflows zusammengefasst. Eine
weitere Hauptkategorie stellen die semistrukturierten Workflows dar. Hier werden
die Kombinationsmöglichkeiten aus vordefinierten Workflows, offener
Teambearbeitung und Ad-hoc-Modifikationen von Workflows zusammengefasst.
(2a) Offene Teambearbeitung innerhalb eines vordefinierten Workflows
Workflows dieses Typs integrieren Gruppenbearbeitung innerhalb eines fest
strukturierten Vorganges (Tabelle 3-1, Spalte 2a). Sie sind mit dem Typ (1b)
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 26
vergleichbar, außer dass hier die Gruppenarbeit Teil eines vordefinierten und nicht
eines Ad-hoc-Workflows ist. Exemplarisch könnte hier eine regelmäßig stattfindende
Besprechung genannt werden, die in Teambearbeitung durchgeführt wird und deren
Vor- und Nachbereitungsaufgaben gut strukturierbar sind. Vordefinierte Workflows
sind bereits in den bestehenden Workflow-Management-Systemen (hier Pavone
Espresso) implementiert und brauchen nicht vom GroupProcess-System unterstützt
zu werden.
(2b) Ad hoc Unterprozess innerhalb eines vordefinierten Workflows
Bei einem Unterprozess bzw. Cluster wird von dem Bearbeiter der Aufgabe erwartet,
dass dieser die fehlende bzw. unbekannte Struktur selbst aufbaut. Der ansonsten fest
strukturierte Workflow beinhaltet also Teilaufgaben, deren Struktur nicht
vorhersehbar ist oder stark variiert, d.h. jede Prozessinstanz verläuft in diesem
Teilbereich (Cluster) anders und kann nicht antizipiert werden. Ein mögliches
Szenario in der Praxis könnte die Meldung eines Softwarefehlers an den Hersteller
sein. Die vordefinierten Aufgaben dieses Workflows könnten die Annahme der
Fehlermeldung, die Weiterleitung an den zuständigen Projektleiter, die Zuweisung an
bestimmte Entwickler bzw. Teams und das Veröffentlichen der Lösung des
Software-Problems an die Kundschaft sein. Die eigentliche Problemlösung variiert in
diesen Beispiel zu stark und kann daher nicht strukturiert bzw. vordefiniert werden.
Diese Art von Sub-Prozessen (Cluster) dient weiterhin der Aufzeichnung bzw. der
Dokumentation der Problemlösungsfindung und kann bei später auftretenden,
ähnlichen Problemen herangezogen werden. Die Unterstützung solcher Workflows
(Tabelle 3-1, Spalte 2b) beschränkt sich auf den Ad-hoc-Unterprozess, da der
vordefinierbare Teil des Workflows durch die bereits bestehenden Workflow-
Management-Systeme unterstützt wird.
(2c) Ad hoc Modifikation und Ausnahmebehandlung eines vordefinierten Workflows
Bei dieser Art von Workflows handelt es sich um vordefinierte Workflows, die
während der Laufzeit Ad-hoc-Modifikationen (Tabelle 3-1, Spalte 2c) zulassen.
Solche Workflows sind vollständig definiert, es gibt keine undefinierten Schritte und
keine Unklarheiten im Workflow-Ablauf. Doch lassen diese Workflows in
Ausnahmefällen bzw. bei speziellen Umständen, die nicht durch das Workflow-
Modell antizipiert wurden, das Hinzufügen von Ad-hoc-Aufgaben zu, um dessen
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 27
Flexibilität zu erhöhen. Ein System, das diese Flexibilität nicht besitzt, zwingt den
Anwender in Ausnahmesituationen, dieses zu verlassen. Dadurch ist die
Dokumentation der Lösung der Ausnahme und deren spätere Verwendung nicht
gegeben. Das als Basis verwendete Workflow-Management-System Espresso verfügt
bereits über die Möglichkeit, Ad-hoc-Aufgaben jederzeit in vordefinierten
Workflow-Strukturen hinzuzufügen.
Diese Funktionalität soll durch das GroupProcess-System verbessert werden. Hierzu
werden nochmals zwei Varianten der Ad-hoc-Modifikation unterschieden:
1. „Rückfragen“: Der ad-hoc-modifizierte Teil eines Workflows beginnt und
endet im gleichen Knoten. Der Prozess kann nach Ablauf der Ad-hoc-
Modifikation normal fortgesetzt werden.
2. „Umleitung“: Im Gegensatz zur Rückfrage wird hierbei der vordefinierte
Übergang zum nächsten Knoten nicht beachtet. Die Ad-hoc-Modifikation
endet nicht in ihren Ausgangsknoten, sondern in einem der nachfolgenden
Knoten des Workflow-Modells. Von dort aus wird der Workflow normal
fortgesetzt.
Beide Ausnahmen können von ihrer Ausgangsposition bis zum Wiedereintritt in das
vordefinierte Workflow-Modell als Ad-hoc-Workflows betrachtet werden. Die Ad-
hoc-Modifikationen werden durch das GroupProcess-System in das Workflow-
Protokoll eingetragen und können auch grafisch angezeigt werden.
(3) Vordefinierte Workflows
Die Kategorie der vordefinierten Workflows stellt die bekannten Standard-
Workflows dar, wie sie durch die bereits bestehenden Workflow-Management-
Systeme unterstützt werden. Sie zeichnen sich unter anderem durch Routine-
Tätigkeiten und einer hohen Frequenz aus. Solche Workflow-Modelle antizipieren
den vollständigen Ablauf der einzelnen Aufgaben und Aktivitäten. Ein Beispiel
hierfür wäre der Standard-Kreditantrag, der stark formalisiert ist. Diese Art von
Workflows unterstützt insbesondere Vorgänge mit hohem Formalisierungsgrad. Die
Unterstützung derartiger Workflows durch das GroupProcess-System ist nicht
notwendig, da sie bereits durch die bestehenden Workflow-Management-Systeme
unterstützt werden.
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 28
3.2 Simultane Ausführung
Aktuelle Workflow-Management-Systeme weisen einige Charakteristika bzw.
Paradigmen auf. Eines dieser Paradigmen ist die Trennung von Build-Time und Run-
Time, mit anderen Worten die Trennung von der Gestaltungs- und
Ausführungsphase. Auch in der Literatur wird die Unterstützung folgender
Funktionsbereiche als Charakteristikum von Workflow-Management-Systemen
genannt [vgl. Lawrence 1997, S 244]:
• Die Build-Time (Gestaltungsphase) dient der Definition sowie der Gestaltung
von Workflow-Modellen einschließlich ihrer Aktivitäten.
• Die Run-Time (Ausführungsphase) dient einerseits der Kontrolle und aktiven
Steuerung von Prozessen und deren Aufgaben,
• anderseits unterstützt die Run-Time auch die Interaktion zwischen den
Anwendern und den Anwendungen, um die verschiedenen Aufgaben
ausführen zu können.
Build Time
Business Process Analysis,Modelling & Definition Tools
Workflow Enactment Service
Applications & IT Tools
Process Design & Definition
Process Defination
Run Time
Interaction with Users & Application Tools
Process Instanciation & Control
Build Time = Run Time Process Definition =Process Instance
Abbildung 3-1: Charakteristika herkömlicher WfMS und GroupProcess12
Aus der Build-Time, der Gestaltungsphase, resultiert das elektronische Abbild eines
Geschäftsprozesses. In dieser Phase wird ein Geschäftsprozess aus der realen Welt in
eine Form übersetzt, die von rechnergestützten Systemen verarbeitet werden kann.
12 angelehnt an [Lawrence 1977, S. 245] & [WfMC 1996, S. 39]
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 29
Dies geschieht durch Analyse und Modellierung bzw. Definition des Prozesses mit
entsprechenden Analyse- und Modellierungswerkzeugen. Das so entstandene Abbild
wird als Workflow-Modell bzw. Workflow-Klasse bezeichnet. Der Struktur einer
Workflow-Klasse liegt ein gerichteter Graph zugrunde, der auf den beiden
Grundelementen Knoten und Kanten basiert. Die Knoten beschreiben dabei jeweils
einen Vorgangsschritt (Task, Aufgabe) und sind durch Kanten, die den
Informationsfluss darstellen, miteinander verbunden. Da die Vorgangsschritte
(Aufgaben) sehr umfangreich sein können, werden diese in Aktivitäten (Activities)
weiter aufgegliedert.
In der Run-Time, der Ausführungsphase, wird dann dieses Workflow-Modell von der
Software interpretiert und zur Kontrolle und aktiven Steuerung der arbeitsteiligen
Prozesse verwendet. In dieser Phase werden beliebig viele Workflow-Instanzen der
Workflow-Klasse ausgeführt. Der Kern einer solchen Workflow-Management-
Kontrollsoftware wird als Engine bezeichnet. Solche Engines „koordinieren die
Arbeitsschritte der Beteiligten, ermitteln den jeweils nächsten Bearbeiter, stellen die
notwendigen Informationen bereit und überwachen die fristgerechte Erledigung.“
[Hasenkamp/Syring 1993, S. 107]. Weiterhin ist die Engine für die Interaktion
zwischen Anwender und der Anwendung zuständig.
Eine solche Trennung der Gestaltungsphase und der Ausführungsphase ist für ein
Ad-hoc-Workflow-Management-System, wie das GroupProcess-System, nicht
geeignet, da gerade bei Ad-hoc-Workflows eine vorherige Strukturierung und
Definition nicht möglich ist. Daraus ergibt sich, dass bei Ad-hoc-Workflow-
Management-Systemen die Build-Time und Run-Time verschmelzen müssen
(Abbildung 3-1). Der GroupProcess-Ansatz kennt diese Trennung von Build-Time
und Run-Time nicht und erlaubt auch während der Ausführung von Prozessen
weiterhin die Modellierung deren Verlaufs. Eine solche „Just in time“-Modellierung,
bei der die nächsten Prozessschritte erst kurz von ihrer Ausführung hinzugefügt
werden, ist eines der wichtigsten Merkmale von Ad-hoc-Workflow-Management-
Systemen.
Eine weiteres Charakteristikum heutiger Workflow-Management-Systeme ist die
Trennung von Workflow-Klasse und Workflow-Instanz. Wie bereits im Kapitel 2.2.
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 30
abgegrenzt, wird in der vorliegenden Arbeit unter einer Workflow-Klasse die
Gesamtheit aller möglichen Arbeitspfade eines Workflows verstanden. Workflow-
Instanz meint die durch Initialisierung und Bearbeitung des Workflows realisierte
Untermenge aller möglichen Arbeitspfade. Die Trennung von Klasse und Instanz ist
bei Standard-Prozessen durchaus sinnvoll. Im Bereich der Ad-hoc-Prozesse, die sich
durch eine hohe Änderungsdynamik und durch ihre Einmaligkeit auszeichnen, sind
das Workflow-Modell und die Workflow-Klasse eher als eine Einheit zu sehen, da
jede Workflow-Instanz ihr eigenes Workflow-Modell besitzt und während der
Laufzeit dieses sogar modifiziert. Sollte ein ähnlicher bzw. gleicher Ad-hoc-
Workflow ein zweites Mal genutzt werden, so wird der zuvor ausgeführte Ad-hoc-
Prozess als Vorlage verwendet, die wiederum dann derart modifiziert werden kann,
dass auch der neue Prozess seine eigene Workflow-Klasse erhält.
Zusammenfassend lassen sich also zwei Merkmale von Ad hoc Workflow
Management Systemen unter dem Begriff „simultane Ausführung“ aufzählen:
• die Verschmelzung von Build-Time und Run-Time
• Workflow-Klasse und Workflow-Instanz bilden eine Einheit.
3.3 Partizipatives, verteiltes Design
Bei den aktuellen Workflow-Management-Systemen werden Workflows von speziell
ausgebildeten Workflow-Designern modelliert und implementiert. Diese Investition
scheint angesichts der hohen Wiederholfrequenz der standardisierten Workflows
durchaus gerecht. Die Modellierung von Ad-hoc-Workflows durch einen einzelnen
Workflow-Designer würde die Kosten in die Höhe treiben, denn er müsste während
der gesamten Laufzeit des Prozesses das Workflow-Modell ad-hoc-modifizieren. Bei
jeder weiteren Wiederholung müsste das Workflow-Modell wiederum neu modelliert
und implementiert werden. Ein weiterer Grund, der gegen einen einzelnen
Workflow-Designer spricht, ist die Tatsache, dass meistens keine einzelnen Personen
das Wissen über den gesamten Prozess besitzen. Eine Analyse der Ad-hoc-Prozesse
würde soviel Zeit in Anspruch nehmen, dass die Workflow-Klasse bereits bei ihrer
Implementierung veraltet wäre. Daher ist ein partizipatives, verteiltes Design ein
weiteres Merkmal von Ad-hoc-Workflow-Management-Systemen. Unter
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 31
partizipativem, verteiltem Design wird die Möglichkeit verstanden, dass jeder
Beteiligte zu jedem Zeitpunkt des laufenden Prozesses Veränderungen am
Workflow-Modell vernehmen kann. Bei dieser Art der partizipativen Modellierung
entsteht mit der Zeit ein Wissen über Ablaufstrukturen in Organisationen, für dessen
Analyse viel Zeit und Geld nötig gewesen wäre.
1. S E
2. S E
S E
3.
S E
S E
4. S E
S E
ES
5.
S E
S E
ES
6.
S E
Tabelle 3-2: Entstehung eines Ad-hoc-Workflow-Modells
Tabelle 3-2 soll die Ad-hoc-Entstehung eines Workflow-Modells mittels des
Einsatzes von Clustern bzw. Unterprozessen (vgl. GroupProcess-Kontinuum, Spalte
1c) verdeutlichen. Ausgangspunkt ist ein einfacher linearer Workflow mit drei
Vorgangsschritten (Tabelle 3-2, Zelle 1.). Beim Bearbeiten der nächsten Teilaufgabe
entschließt sich deren Bearbeiter, diese in einen Unterprozess bzw. Cluster zu
gestalten und zu implementieren (Tabelle 3-2, Zelle 2. und 3.). Dies soll der
Reduzierung der Komplexität des Workflow-Modells dienen. Der so entstandene
Cluster weist eine Spaltung der Teilaufgabe in zwei parallele Vorgangsschritte auf.
Da einer der Bearbeiter der beiden neuen Vorgangsschritte eine Abteilung ist, und
deren Weg der Vorgangsbearbeitung unbekannt ist, kommt auch bei deren
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 32
Bearbeitung ein neuer Unterprozess zum Einsatz (Tabelle 3-2, Zelle 4. und 5.).
Dieses Cluster teilt die Teilaufgabe in zwei neue auf, die parallel von zwei
Mitarbeitern dieser Abteilung bearbeitet werden. Tabelle 3-2, Zelle 6 stellt das fertige
Workflow-Modell dar. Die hier beschriebenen Modifikationen werden während der
Laufzeit der Prozesse durchgeführt. Vergleicht man Zelle 1 mit Zelle 6 der Tabelle 3-
2, so erkennt man, wie das Workflow-Modell von Bearbeiter zu Bearbeiter immer
komplexer wurde. Hier ist also ein Workflow-Modell entstanden - auch ohne
vorherige Analyse und Implementierung. Weiterhin wurde hier implizites,
informelles Prozesswissen zu explizitem, formellem Prozesswissen umgewandelt.
Zielsetzung des GroupProcess-Ansatz ist es, informelle Strukturen zu formellen
Strukturen umzuwandeln, und zwar in einem höheren Maße, als dies die heutigen
Workflow-Management-Systemen vermögen.
3.4 Übergang von konkreter zu abstrakter Prozessmodellierung
Strukturierten Workflows liegt ein abstraktes Workflow-Modell zugrunde. In den
meisten Fällen werden bei solchen Workflows abstrakte organisatorische Entitäten
(z.B. Rollen, Arbeitsgruppen und Abteilungen) und nicht konkrete Personen als
Bearbeiter der Vorgangsknoten eingesetzt. Bei Ad-hoc-Workflows verlaufen die
Prozesse vorwiegend im Kernteam des Initiators und sind dementsprechend zumeist
an konkrete Personen gebunden. Um nun solche Ad-hoc-Workflows in
feststrukturierte Workflows zu überführen, wird eine Ex-post-Analyse bzw. eine Art
von Abstraktion notwendig. Mit Hilfe dieser Abstraktion soll dann von den
konkreten Bearbeitern bzw. Personen auf die organisatorischen Entitäten geschlossen
werden. Es werden Relationen von der prozessbearbeitenden Person zu ihrer Rolle,
Arbeitsgruppe und Abteilung verwendet. Solche Relationen sind nicht immer
eindeutig, so dass bei der Abstraktion gezielt analysiert werden muss, welche Rolle,
Abteilung oder Arbeitsgruppe einer Person für die Ausführung der entsprechenden
Vorgangsschritte ausschlaggebend war. Die Entwicklung eines geeigneten
Analysewerkzeuges ist zu einem späteren Zeitpunkt des GroupProcess-Projektes
vorgesehen.
3 Merkmale und Anforderungen an ein Ad-hoc-Workflow-Management-System Seite 33
3.5 Anforderungen an eine Ad-hoc-Workflow-Engine
Auf Basis der im vorherigen Abschnitt beschriebenen Merkmale von Ad-hoc-
Workflow-Management-Systemen ergeben sich verschiedene Anforderungen an die
Gestaltung einer Laufzeitumgebung für eine Ad-hoc-Vorgangsbearbeitung.
Die Hauptanforderung an eine Ad-hoc-Workflow-Engine ist die Unterstützung ganz
oder teilweise definierter Workflow-Modelle. Ihre Kernaufgabe liegt in der
Ermittlung der nächsten Aufgaben und der Weiterleitung dieser Aufgaben an die
zuständigen Bearbeiter. Es ist Angelegenheit der Workflow-Engine, in einer
Workflow-Instanz den Übergang von einer Aufgabe und deren Bearbeiter(n) auf die
nächste aktiv zu steuern.
Bei dieser aktiven Steuerung hat die Workflow-Engine zu berücksichtigen, dass sich
die Workflow-Klasse, aus denen die Workflow-Instanz hervorgegangen ist, jederzeit
ändern kann. Somit nimmt neben der Weiterleitung der Aufgaben die
Ausnahmebehandlung an Bedeutung zu. Das Exception Management umfasst neben
der Standardausnahme, wie beispielsweise. eine „Rückfrage“ oder „Umleitung“, vor
allem die Ausnahmenbehandlung beim Erreichen des letzten Vorgangsknotens bei
nur teilweise definierten Workflow-Modellen. In diesem Fall ist eine Interaktion mit
dem Anwender unumgänglich.
Des Weiteren muss auch eine Ad-hoc-Workflow-Engine das Spalten einer Aufgabe
in mehrere parallele Aufgaben sowie das spätere Zusammenführen der Ergebnisse
unterstützen. Hierbei entsteht das Problem, dass während der Spaltung der Aufgaben
der Zeitpunkt der Zusammenführung noch unbekannt sein kann und dieser im
weiteren Verlauf zur Laufzeit ermittelt werden muss.
Um den Bereich der interorganisatorischen Kooperation ebenfalls zu unterstützen,
muss die Ad-hoc-Workflow-Engine in der Lage sein, Teilaufgaben oder ganze
Unterprozesse auch an andere Organisationen weiterzuleiten. Dies geschieht vor
allem durch das Versenden von sogenannten Message-Objekten. Diese
standardisierten Message-Objekte enthalten alle relevanten Informationen des
Workflow-Modells und alle Informationen zum aktuellen Workflow-Status.
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 34
4 Realisierung einer Ad-hoc-Workflow-Engine für Groupware-basierte Ad-hoc-Workflows
Dieses Kapitel beschreibt zunächst die Architektur des GroupProcess-Systems und
stellt dann die Ad-hoc-Workflow-Engine vor. Die Funktionalität der Workflow-
Engine wird anhand von Beispielen näher beschrieben.
Weiterhin ist zu erwähnen, dass die hier zur prototypischen Implementierung
verwendete Groupware-Plattform Lotus Notes/Lotus Domino sowie das verwendete
Office- und Workflow-Management-System Espresso der Firma Pavone
grundsätzlich austauschbar sind. Sie dienen hier als mögliche Umgebungen für die
praktische Umsetzung von GroupProcess und sind durch vergleichbare
Systemumgebungen ersetzbar [vgl. Huth/Nastansky 2000, S. 13].
4.1 Architektur GroupProcess
Als Basis des GroupProcess-Systems - dessen Architekturmodell in Abbildung 4-1
grafisch dargestellt ist - dient die Groupware-Plattform Lotus Notes/Domino Version
5.05, die auf der heterogenen technologischen Umgebung von Hardware,
Betriebssystemen und Netzwerken eine homogene Infrastruktur für das Workflow-
Management zur Verfügung stellt. Weiterhin werden wichtige Funktionen für zeitlich
und räumlich verteiltes Informationsmanagement von dieser Groupware-Plattform
erfüllt (dezentrales Datenbankmanagement, Zugriffskontrollmechanismen, E-Mail
usw., vergleiche Kapitel 2.3).
Auf der Groupware-Plattform setzt nun das Workflow-Management-System auf.
Hierzu gehört das gesamte Workflow-Repository von Espresso, das aus den
Datenbanken Organisation und Vorgangtyp besteht, welche die Aufbau- und
Ablauforganisation enthalten und der Datenbank Anwendungen, in der die
Workflow-Engine enthalten ist. Die Modellierungswerkzeuge ProcessModeler und
OrganizationModeler sind weitere Bestandteile des Espresso Systems (Abbildung 4-
1, gestrichelte Linie).
Da GroupProcess eine Erweiterung der aktuellen Workflow-Management-Systeme
und keine neue Implementierung darstellt, werden das Management und die
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 35
Modellierung der Aufbauorganisation von Espresso übernommen. Als neue
Bestandteile des Systems kommen der Ad-hoc-Workflow-Modeler und die Ad-hoc-
Workflow-Engine hinzu, die beide in der Datenbank Anwendungen enthalten sind.
Transformation Tool (Ad hoc to predef. WF)
Office- and Workflow-Application
Groupware platform
Process DB
OrganizationDB
Application DB
Workflow Engine
(predef. WF)
Ad hoc Workflow
Engine
Workflow Modeler (predef. WF)
Organization Modeler (predef. And Ad hoc WF)
Ad hoc Workflow Modeler and Viewer
EMail Tracking
and Routing
Abbildung 4-1: Architekturmodell von GroupProcess13
4.1.1 Aufbau GroupProcess-Repository
Das eigentliche GroupProcess-Repository, das nur einen Teil des gesamten
Workflow-Repository eines Workflow-Management-Systems darstellt, besteht aus
den Datenbanken Organisation und Anwendungen. Abbildung 4-2 stellt die
Zusammensetzung des GroupProcess-Repository dar und zeigt die Art und Richtung
der Kommunikation mit der Ad-.hoc-Workflow-Engine auf. Die nächsten Abschnitte
werden detailliert auf die Intentionen und Strukturen dieser Datenbanken eingehen.
Eine Besonderheit stellt der „Ad hoc Workflow Modeler and Viewer“ dar. Denn
dieses Modellierungswerkzeug wurden bei GroupProcess mit Hilfe der
Programmiersprache Java in die Datenbank Anwendungen implementiert.
13 vgl. [Huth/Erdmann/Nastansky 2001, S. 7]
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 36
GroupProcess-Repository
Application DB
Organization DB
Organization-Modeler Ad-hoc-Workflow-Modeler
Ad-hoc-Workflow-Engine
Abbildung 4-2: GroupProcess-Repository und die Schnittstellen zur Ad-hoc-Workflow-Engine
4.1.1.1 Application Database
Die Application Database (dt. Anwendungsdatenbank) ist die zentrale
Benutzerschnittstelle des Workflow-Management-Systems. Im Normalfall kommt
der Benutzer nur mit dieser Datenbank in Berührung. In persönlichen Ansichten
werden alle zu bearbeitenden Workflows, an denen der Anwender beteiligt ist,
aufgezeigt. Diese Auflistung (vgl. Abbildung 4-3) kann nach verschiedenen
Kategorien bzw. Kriterien sortiert sein. Nachdem der Anwender einen Workflow
ausgewählt und geöffnet hat, kann er diesen nicht nur bearbeiten, speichern und
weiterleiten, sondern auch deren Workflow-Modell bzw. Workflow-Klasse während
der Laufzeit verändern bzw. modifizieren. Dies ist der gravierendste Unterschied der
Ad-hoc-Workflow-Engine von GroupProcess gegenüber einer herkömmlichen
Workflow-Engine. Wie bereits im Kapitel 2.3 beschrieben, kennt das GroupProcess-
System keine zeitliche Trennung der Build-Time und Run-Time. Dieses Merkmal ist
auch bei der prototypischen Realisierung der Engine berücksichtigt worden.
Für die Bearbeitung der Vorgänge nutzt die Ad-hoc-Workflow-Engine verschiedene
Informationen des GroupProcess-Repository. Um zum Beispiel einen Vorgang zum
nächsten Bearbeiter zu leiten, liest die Workflow-Engine die nötigen Informationen
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 37
aus der Datenstruktur des Dokumentes aus, leitet den Vorgang weiter und setzt bzw.
verändert die aktuellen Werte und den Status des Workflows in der Datenstruktur.
Der Aufbau eines Ad-hoc-Workflow-Dokumentes wird im Kapitel 4.1.2. detaillierter
beschrieben.
Abbildung 4-3: Persönliche Ansicht in der Application Database
Sollte ein Vorgang nur teilweise modelliert sein und das Ende des Arbeitspfades
erreichen, so fragt die Workflow-Engine den Anwender nach der weiteren
Vorgehensweise. Eine der möglichen Optionen wäre das weitere Modellieren des
Workflow-Modells durch den Ad-hoc-Workflow-Modeler. Dieses
Modellierungswerkzeug zeichnet sich durch einfache Bedienung und einer Art
Favoritenliste für aufbauorganisatorische Elemente aus. Die Abbildung 4-4 zeigt
einen Screenshot des aktuellen Prototyps. Dieser Modeler wird auch zur reinen
Visualisierung der aktuellen Position bzw. des Forschrittes der Vorgangsbearbeitung
im Workflow-Modell genutzt.
Da die Anwendungsdatenbank die Schnittstelle zum Anwender bildet, findet hier
auch die gesamte Kommunikation bzw. Interaktion zwischen dem System und seinen
Benutzern statt.
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 38
Zusammenfassend können folgende Funktionen der Application Database genannt
werden:
• Initialisieren, weiterleiten und beenden von Ad-hoc-Workflows
• Modellierung sowie Modifizierung der Workflow-Modelle während der
Laufzeit mittels eines Modellierungswerkzeuges
• Jegliche Art von Interaktion zwischen der Anwendung und dem Anwender
dieses Systems
Abbildung 4-4: Beispiel für einen Ad-hoc-Prozess im Prototyp des Modellierungswerkzeuges
des GroupProcess-Systems14
4.1.1.2 Organization Database
Die Organization Database (dt. Organisationsaufbaudatenbank) bildet die
aufbauorganisatorische Struktur einer Organisation ab. Sie setzt sich aus den Daten
der Einzelpersonen zusammen, die in hierarchisch gegliederten Abteilungen oder
organisationsweiten Arbeitsgruppen unterteilt sein können. Personen mit ähnlichen
14 vgl. [Huth/Nastansky 2000a, S. 18]
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 39
Aufgabenbereichen können zusätzlich noch in Rollen zusammengefasst werden (vgl.
Abbildung 4-5).
Bei der Modellierung des Workflow-Modells werden den einzelnen Vorgängen die
für die Bearbeitung zuständigen organisatorischen Entitäten (Person, Abteilung,
Arbeitsgruppe oder Rolle) zugewiesen. Dabei greift der Ad-hoc-Workflow-Modeler
auf diese Datenbank zu und legt die gewählte Entität sowie deren Einzelpersonen im
Workflow-Modell ab. Die Workflow-Engine ermittelt bei der Weiterleitung der
Vorgänge wiederum die für die Bearbeitung verantwortliche organisatorische
Einheit. Sie greift dabei auch auf diese Datenbank und löst die Entität in ihre
Einzelpersonen auf. Somit wird den Veränderungen der Mitglieder einer Abteilung,
Abteilsgruppe oder Rolle Rechnung getragen.
Abbildung 4-5: Ansicht der Organization Database
Da die Organization Database vom Espresso-System übernommen wurde, kann zu
deren Modellierung der OrganizationModeler von Espresso benutzt werden. Das
Modellierungswerkzeug ermöglicht die grafische Modellierung und Visualisierung
der Positionen der einzelnen Mitarbeiter innerhalb des Unternehmens bzw. der
Organisation.
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 40
4.1.2 Ad-hoc-Workflow-Document
Das Ad-hoc-Workflow-Dokument ist in einen Frontend- und einen Backend-Bereich
aufgeteilt. Im Frontend-Bereich, der für den Anwender sichtbar ist, befindet sich zum
einen das Modellierungswerkzeug und zum anderen der eigentliche Inhalt (Content)
des Dokumentes.
Der Ad-hoc-Workflow-Modeler ist als Java-Applet [vgl. Bäsner, Kühn, Stork 2000]
in der Standardmaske des Ad-hoc-Workflow-Dokumentes eingebettet und kann
somit jederzeit geöffnet und benutzt werden.
Frontend Fields (sichtbar)
Backend Fields (nicht sichtbar)
Anzeige des aktuellen Zustandes und Möglichkeit zur Modellierung des Prozessmodells zur Laufzeit
Inhalt des Workflow-Anwendungsfalls. Im Office-Umfeld Rich-Text, aber Informationen in strukturierten Feldern sind möglich.
Speicherung des Prozessmodells und weiterer Routing Informationen
Abbildung 4-6: Ad-hoc-Workflow-Dokument15
Die Standardmaske eines Ad-hoc-Workflow-Dokumentes enthält ein Rich-Text-Feld.
Dieses Feld kann formatierten Text, Grafiken, OLE-Objekte und ganze Dateien als
Anhänge enthalten. In einer Office-Umgebung sollte diese Technologie den Hauptteil
der Anwendungsfälle ermöglichen. Um aber auch strukturierte Daten, wie Text, Zahl
oder Zeit verarbeiten zu können, besteht die Möglichkeit Teilmasken einzubetten.
Solche strukturierten Daten werden vor allem bei der berechneten Weiterleitung, die
von der Ad-hoc-Workflow-Engine auch unterstützt wird, verwendet. Die Angabe,
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 41
welche Teilmasken in welchen Vorgangsknoten benutzt werden, wird im Workflow-
Modell festgehalten.
Das Content eines Ad-hoc-Workflow-Dokumentes kann also sowohl sogenannte
weiche als auch harte Daten beinhalten (vgl. Verbunddokument im Kapitel 2.3).
Im Backend-Bereich, der für den Anwender in der Regel nicht sichtbar ist, befinden
sich spezielle Workflow-Felder, die das kategorisierte Anzeigen der Workflow-
Instanzen in Ansichten ermöglichen (siehe Anhang A.2.1). Weitaus wichtiger aber ist
die Tatsache, dass die gesamte Ad-hoc-Datenstruktur in diesem Bereich des Ad-hoc-
Workflow-Dokumentes gespeichert ist. Zu dieser Datenstruktur gehören das
Workflow-Modell sowie der aktuelle Fortschritt der Vorgangsbearbeitung. Die Ad-
hoc-Datenstruktur wird mittels des Ad-hoc-Workflow-Klassenmodells [vgl. Goos,
Laumen, Schramm 2001] im XML-Format in ein einziges Textfeld gespeichert.
Sowohl der Ad-hoc-Workflow-Modeler als auch die Ad-hoc-Workflow-Engine
greifen bei ihren Aktionen auf dieses Klassenmodell zurück. Die Klassenstruktur
dieses Objektmodells ist in Abbildung 4-7 dargestellt.
AdHocWorkflow
AdHocDatabaseProperties AdHocNamesDatabase
AdHocTaskCollection
AdHocOrganizationDatabase
AdHocTask
AdHocEditor
AdHocConnectionCollection
AdHocConnection
Abbildung 4-7: Struktur des Ad-Hoc-Workflow-Objektmodells
15 vgl. [Huth/Erdmann/Nastansky 2001, S. 8]
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 42
Durch die Verwendung von XML als Format zur Speicherung der Ad-hoc-
Workflow-Datenstruktur, wird das Versenden des Ad-hoc-Workflow-Dokumentes
als Message-Objekt möglich. Das versendete Message-Objekt enthält neben dem
Content auch das Workflow-Modell sowie die aktuelle Position des Vorganges im
Workflow-Modell.
4.1.3 Aufbau der Ad-hoc-Workflow-Engine
Bei der Funktionsweise von Workflow-Engines werden in Groupware-basierten
Workflow-Management-Systemen zwei Möglichkeiten unterschieden:
1. Workflow-Engine als periodischer Agent: Bei dieser Art von Workflow-Engine
wird in bestimmten Zeitzyklen geprüft, ob eine Aufgabe abschlossen ist und
weitergeleitet werden kann. Ist dies der Fall, wird die Weiterleitung durchgeführt.
2. Event-orientierte Workflow-Engine: Bei diesen ereignisgesteuerten Workflow-
Engines wird die Aktion durch Eingabe des Benutzers aufgelöst. Das heißt, der
Anwender löst nach Abschluss seiner Aufgabe durch Anklicken einer
Schaltfläche das Weiterleiten aus. Danach wird der nächste Bearbeiter ermittelt
und der Vorgang weitergeleitet. Die Ermittlung des nachfolgenden Bearbeiters
kann berechnet oder durch Abfrage des Benutzers durchgeführt werden.
Im vorliegenden GroupProcess-Projekt wurde die ereignisorientierte Workflow-
Engine zur Realisierung gewählt.
Wie der Ad-hoc-Workflow-Modeler befindet sich auch die Ad-hoc-Workflow-
Engine in der Application Database. Die Funktionalität der Workflow-Engine stützt
sich auf zwei Säulen, die auf der einen Seite aus Lotus Script Libraries und auf der
anderen Seite aus dem Ad-hoc-Workflow-Dokument mit seinen Aktionsschaltflächen
bestehen. Die Grundelemente der Engine und deren Beziehungen sind in Abbildung
4-8 grafisch veranschaulicht.
Lotus Script Bibliotheken als eine Säule der Workflow-Engine ermöglichen die
zentrale Pflege und die einfache Erweiterung der Laufzeitumgebung. Außerdem
lassen sich die Funktionalitäten der Lotus Script Libraries auch aus anderen Design-
Elementen heraus aufrufen (z.B. Aktionsschaltflächen). Logisch zusammengehörige
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 43
Methoden und Funktionen sind zur besseren Strukturierung in folgenden Script
Bibliotheken zusammengefasst:
• Die Script Library DataExchange bildet das Fundament für alle
nachfolgenden Script Libraries. Hier ist das Klassenmodell der Ad-hoc-
Workflow-Datenstruktur nach dem GroupProcess-Konzept hinterlegt (vgl.
Abbildung 4-7). Das Klassenmodell ist sowohl in LotusScript als auch in Java
implementiert [vgl. Goos, Laumen, Schramm 2001]. Somit stellt diese
Bibliothek die Schnittstelle zwischen der Ad-hoc-Workflow-Engine und dem
Ad-hoc-Workflow-Modeler dar. Auch andere Tools, wie das geplante
“Transformation Tool Ad hoc to predef. Workflow“, werden auf die
Methoden und Funktionen dieses Klassenmodells zugreifen. Die Bibliothek
DataExchange enthält auch die Methoden zum Setzen und Auslesen der
Datenstruktur im Ad-hoc-Workflow-Dokument sowie deren Übersetzung ins
XML.
• Die beiden Script Bibliotheken AdHocWorkflow und AdHocWorkflowUI
bilden den Kern der Funktionalität der Ad-hoc-Workflow-Engine. Dazu
gehören das Ermitteln des nächsten Vorgangsknoten und dessen Bearbeiters,
das Weiterleiten des Vorganges und die Protokollierung dieser Ereignisse.
Die Ad-hoc-Workflow-Library benutzt ausschließlich LotusScript Backend-
Klassen (z.B. NotesDocument) und ist deshalb sowohl auf der Client- als
auch auf der Serverseite einsetzbar. Anders ist es bei der Ad-hoc-Workflow-
UI-Library die nicht nur die LotusScript Backend- sondern vor allem die
LotusScript Frontend-Klassen nutzt. Die Methoden der Frontend-Klassen
(z.B. NotesUIDocument) ermöglichen das Manipulieren der vom Benutzer
sichtbaren Objekte und sind deshalb nur auf der Clientseite einsetzbar. Diese
Bibliothek bildet die Grundlage der Kommunikation zwischen der
Anwendung und des Anwenders.
• Die Script Library ContentManagement enthält die Funktionen, die für die
Durchführung des Content Management benötigt werden. Das Content
Management umfasst in dieser Implementierungsphase vor allem das
Zusammenführen der Dokumenteninhalte beim Zusammenführen von
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 44
gespaltenen und somit parallel zu bearbeitenden Dokumenten. In einer
späteren Implementierungsphase werden hier auch Methoden und Funktionen
zur Verfügung gestellt, die eine Weiterleitung von selektiven Inhalten
beispielsweise im Message Objekt möglich machen.
• Die Script Library ExceptionsHandling umfasst die Methoden der
Ausnahmebehandlung. In einem Workflow-Management-System, bei dem die
Build-Time und Run-Time eine Einheit bilden, kann das Workflow-Modell
unvollständig sein. In solchen Fällen ist eine Ausnahmenbehandlung
unumgänglich. Die Umsetzung und Steuerung der während der Laufzeit
auftretenden, unterschiedlichen Ausnahmesituationen wird hierdurch
verwirklicht.
• Die Script Library GenericFunctions beinhaltet Funktionen, die nicht
unmittelbar auf dem Bereich des Workflow-Managements beschränkt sind.
Application Database
DataExchange Ad-hoc-Workflow-Dokument
Actionschaltflächen Teilmasken
Spezielle WF-Felder
AdHocWorkflow AdHocWorkflowUI ExceptionHandling
ContentManagement
Ad-hoc-Workflow-Engine
Abbildung 4-8: Aufbau Ad-hoc-Workflow-Engine
Die andere Säule der Ad-hoc-Workflow-Engine besteht auf dem Ad-hoc-Workflow-
Dokument. Dieses enthält nicht nur den Content, sondern auch das gesamte
Workflow-Modell sowie den aktuellen Status des Workflows [vgl. Kapitel 4.1.2]. In
der Standardmaske des Ad-hoc-Workflow-Dokumentes befinden sich
Aktionsschaltflächen, die Methoden und Funktionen der workflow-spezifischen
Script-Bibliotheken aufrufen. Mit Hilfe dieser Schaltflächen werden Ereignisse
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 45
aufgelöst, die zur Prüfung des aktuellen Workflows führen und das Weiterleiten
veranlassen. Außer den Aktionsschaltflächen befinden sich in der Standardmaske
auch noch Kontrollkästchen, die im Workflow-Modell festgelegte Aktivitäten
darstellen. Je nach Einstellung der Engine müssen eventuell alle Aktivitäten als
erledigt abgehakt sein, bevor das Weiterleiten veranlasst wird. Weiterhin werden für
die berechnete Weiterleitung von Dokumenten strukturierte Daten benötigt. Da die
Standardmaske nur ein Rich-Text-Feld enthält, sind hierfür gesonderte Teilmasken
mit Feldern der Art Text, Nummer bzw. Zeit erforderlich. Als letztes Element der
Ad-hoc-Workflow-Engine sind spezielle Workflow-Felder im Ad-hoc-Workflow-
Dokument zu erwähnen. Diese Felder (siehe Anhang A.2.1) dienen der
kategorisierten Darstellung der Dokumente in Ansichten, haben jedoch keinen
Einfluss auf die Funktionsweise der Engine.
4.2 Funktionalität der Engine
Um die Funktionalität der Ad-hoc-Workflow-Engine zu verdeutlichen, wird diese
anhand von Beispielen beschrieben, welche die Möglichkeiten der Ad-hoc-
Bearbeitung von Workflows sowie die Ausnahmenbehandlung aufzeigen.
4.2.1 Workflow initialisieren
In dem vorliegenden GroupProcess-System werden nur Dokumente mit einem
Workflow-Modell zur Verarbeitung durch das System akzeptiert. Alle anderen
Dokumente lassen sich aber durch Hinzufügen eines Workflow-Modells in ein Ad-
hoc-Workflow-Dokument umwandeln.
Das Initialisieren eines neuen Workflows kann somit in bestehenden sowie auch in
neu erstellten Dokumenten vorgenommen werden. Dazu wird die Schaltfläche
„Vorgang initialisieren“ ausgeführt. Daraufhin wird der Ad-hoc-Workflow-Modeler
geöffnet, so dass das Workflow-Modell bearbeitet werden kann. Nach der
Bearbeitung wird das Modell im Dokument mittels XML gespeichert. Wird nun die
Startaufgabe erledigt und die Schaltfläche „Vorgang weiterleiten“ angeklickt, so wird
der Vorgang anhand der im Modell gespeicherten Regeln weitergeleitet. Wird diese
Schaltfläche ohne Workflow-Modell ausgelöst, so erscheint eine Hinweismeldung,
die erklärt, dass es sich hierbei um kein Vorgangsdokument handelt.
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 46
4.2.2 Weiterleitung
Bevor die Funktionsweise der Weiterleitung detailliert beschrieben wird, werden
zuerst die Transitionstypen, die vom GroupProcess-System unterstützt werden,
dargestellt. Die Abbildung 4-9 veranschaulicht die Weiterleitungsarten und deren
Mischformen.
1. Einfaches Weiterleiten 2. Split/Join
4. Mehrfachauswahl 3. Exklusive Auswahl
3. Bedingung/Sonst-Fall
a1
a1
a1 a1
a1 b1
b1
b1
b1 b1
b2
b2
b2 b2
b3
b3
b3 b3
c1
always
else
A?
always
always
always
A?
B? B?
C? C?
X > 10.000
X > 1.000 AND X <=10.000
Abbildung 4-9: Weiterleitungsarten
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 47
1. Immer („Always“)
Falls nur genau eine Transition dieses Typs von einer Aufgabe zur nächsten
existiert, so handelt es sich um eine einfache Weiterleitung ohne Bedingung
(vgl. Abbildung 4-9, Punkt 1.). Hier wird der Vorgang auf jeden Fall von dem
ersten Vorgangsknoten (a1) zum nächsten Vorgangsknoten (b1) übergeben.
Falls von einer Aufgabe mehr als eine Transition zu mehr als einer Aufgabe
besteht, entsteht als Weiterleitungsart ein „Split“ des Workflows (vgl.
Abbildung 4-9, Punkt 2.). Bei einem Split findet die Bearbeitung von diesem
Vorgangsknoten (a1) aus parallel an mehreren Arbeitspfaden (b1, b2, b3) statt.
Dies geschieht so lange, bis die parallelen Zweige des Workflow-Graphen in
einem „Join“ (c1) wieder zusammengeführt werden. Die Verarbeitung solcher
Splits und Joins durch die Ad-hoc-Workflow-Engine wird im Kapitel 4.2.2.2
detaillierter beschrieben.
2. Auswahl exklusiv/mehrfach („Choice single/multiple“)
Bei der Transition „Auswahl“ entscheidet nach dem Abschließen der Aufgabe
dessen aktueller Bearbeiter, an welchen der nächsten Vorgangsknoten der
Workflow zur Bearbeitung weitergeleitet wird. Im Falle der exklusiven
Auswahl wird nur genau eine der folgenden Aufgaben ausgewählt (vgl.
Abbildung 4-9, Punkt 3.). Hierbei handelt es sich wiederum um eine einfache
Weiterleitung zum nächsten Vorgangsknoten. Für den Fall der mehrfachen
Auswahl kann der aktuelle Bearbeiter der Aufgabe mehr als eine der nächsten
Aufgaben auswählen. Werden mehr als eine der nächsten Vorgangsknoten zur
Weiterleitung gewählt, so entsteht auch hier ein Split des Vorganges (vgl.
Abbildung 4-9, Punkt 4.).
3. Bedingung/Sonst-Fall (“Condition/Else”)
Bei der Transition vom Typ „Bedingung/Sonst-Fall“ werden nach dem
Abschließen der aktuellen Aufgaben die Bedingungen, die für die
Transitionen definiert sind, ausgewertet. Für alle Transitionen, deren
Bedingungen gültig sind, d.h. dessen logische Bedingung den Wert „Wahr“
ergibt, wird die Aufgabe, zu der diese Transition führt, als nächste zu
bearbeitende Aufgabe ausgewählt. Für den Fall, dass die Bedingungen von
mehr als einer Transition gültig sind, entsteht auch an dieser Stelle ein Split
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 48
des Workflows. Für den Fall, dass die Bedingung von nur genau einer
Transition gültig ist, entsteht eine einfache Weiterleitung zu der Aufgabe
dieser Transition. Sollte keine der Bedingungen der Transitionen den Wert
„Wahr“ ergeben, so tritt die Transition des „Sonst-Falls“ in Kraft. Auch
hierbei wird die Aufgabe ohne Bedingungen an die Aufgabe dieser Transition
weitergeleitet (vgl. Abbildung 4-9, Punkt 5.).
Die Entstehung eines Ad-hoc-Workflows und deren Verarbeitung durch die Ad-hoc-
Workflow-Engine soll anhand des folgenden Fallbeispiels verdeutlicht werden.
Das zehnköpfige Vertriebsteam eines mittelständischen Unternehmens der
Metallindustrie ist für die Ausstattung seines abteilungsinternen EDV-Systems selbst
verantwortlich. Da das Team durch zwei neue Mitarbeiter verstärkt wird und die
vorhandenen EDV-Komponenten teilweise bis zu fünf Jahren alt sind, wird eine
Erneuerung des EDV-Systems durch den Abteilungsleiter beschlossen. Dazu erstellt
er einen neuen Vorgang und modelliert das Prozessmodell. Aufgrund mangelnder
Erfahrungen in einem solchen Bereich, modelliert er zuerst nur die Erfassung des
EDV-Bedarfs, teilt ihn in zwei parallele Teilaufgaben (Erfassung der benötigten
Hard- und Software) auf und weist sie zweien seiner Mitarbeiter zur Bearbeitung zu
(vgl. Abbildung 4-10). Die Ergebnisse sollen dann wieder an ihn geleitet werden.
0
12
3
Erneuerung des EDV-Systems
Erfassung der benötigten Hardware
Erfassung der benötigten Software
Erfassung des gesamten EDV-Bedarfs
always
always always
always
Abbildung 4-10: Fallbeispiel „Erneuerung des EDV-Systems“, Phase 1
Wie in Abbildung 4-10 erkennbar, enthält der Startknoten zwei gültige Transitionen
zu zwei weiteren Aufgaben, was zu einer Spaltung (engl. Split) des Vorganges führt.
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 49
Die Ergebnisse der Parallelbearbeitung werden zu einem späteren Zeitpunkt wieder
zusammengeführt (engl. Join bzw. Merge).
4.2.2.1 Aufgaben aufteilen und zusammenführen (Split/Join)
Die Ad-hoc-Workflow-Engine unterstützt neben der Verarbeitung von linear
verlaufenden Vorgängen (einfaches Weiterleiten) vor allem auch die Aufteilung
(Split) eines Vorganges. Dies führt zu einer parallelen Bearbeitung von Teilen diese
Vorganges durch mehrere Bearbeiter.
Aufgrund der Dynamik von Ad-hoc-Workflows unterstützt das GroupProcess-
System und somit auch die Engine nur die Verarbeitung von hierarchischen Splits.
Das bedeutet, dass zuerst Split-Dokumente der niedrigsten Hierarchieebene
zusammengeführt werden müssen, bevor Split-Dokumente der darüber liegenden
Hierarchieebene zusammengeführt werden können. Querverbindungen zwischen
Knoten verschiedener Splithierarchien bzw. Splits verschiedener Verlaufszweige
werden nicht unterstützt und können somit vom System nicht verarbeitet werden.
Abbildung 4-11 zeigt ein mögliches Workflow-Modell, das nach diesen Regeln
modellierte Splits enthält.
Für die datentechnische Verwaltung der Split-Dokumente mussten folgende
Überlegungen berücksichtigt werden:
Bei jedem Split erfolgt eine Aufteilung des Workflows in mehrere Dokumente, in
denen nicht nur die Position innerhalb des Workflow-Modells verwaltet werden
muss, sondern auch deren Zugehörigkeit zu einem Split. Außerdem müssen für das
spätere Zusammenführen solcher Split-Dokumente Informationen über die anderen
Dokumente der gleichen Split-Hierarchieebene bekannt sein.
Aus diesen Überlegungen resultiert folgende Speicherungstechnik:
Für die Verwaltung von Splits wird ein Stapel (Stack) verwendet, der mit Split-
Identifikationen (Split-ID) gefüllt wird. Auf der untersten Ebene dieses Stapels
befindet sich der erste und somit hierarchisch oberste Split. Weitere Split-IDs werden
jeweils oben auf diesem Stapel hinzugefügt. Eine Split-ID besteht aus den
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 50
eindeutigen Dokumenten-IDs (Document Universal ID16) der zugehörigen Split-
Dokumente. Die einzelnen Dokumenten-IDs werden durch einen vorher bestimmten
Separatoren-Zeichen – wie beispielsweise # – getrennt. Die erste Position einer Split-
ID ist mit der Dokumenten-ID des originalen Dokumentes (Master-Dokument)
besetzt. Alle anderen Positionen sind mit den Dokumenten-IDs der Kopiedokumente
(Slave-Dokumente) gefüllt. Eine Split-ID aus drei Dokumenten könnte somit
folgendermaßen aussehen:
„3BBA4F89174A5F27C1256A17005037FE#1B1DA2800EC6678CC1256A170050
3FBC#8171285C2715B113C1256A1700503FBD“
UNID1
UNID1
UNID1
UNID1
UNID1
UNID2
UNID3
UNID2
UNID3
UNID3
UNID4
UNID5
UNID6
(0) UNID1#UNID2#UNID3 (1) UNID1#UNID4#UNID5 (0) UNID1#UNID2#UNID3
(1) UNID3#UNID6 (0) UNID1#UNID2#UNID3 (0) UNID1#UNID2#UNID3
Kein Stapel vorhanden, da kein Split Kein Stapel vorhanden,
da alle Splits wieder zusammengeführt
Abbildung 4-11: Hierarchische Splits und deren Verwaltung
Anhand dieser Split-IDs können jederzeit die anderen zum gleichen Split
zugehörigen Dokumente ermittelt werden. Die Unterscheidung zwischen Master- und
Slave-Dokument eines Splits ist für das spätere Zusammenführen relevant, da
während dieses Vorgangs die Inhalte der Slave-Dokumente direkt hintereinander in
das Rich-Text-Feld des Master-Dokuments eingefügt werden, wodurch gewährleitet
16 Die „Document Universal ID“ ist eine 32stellige hexadezimale Zahl, die ein Dokument innerhalb sämtlicher Repliken einer Datenbank eindeutig identifiziert. Zwei Dokumente sind dann Repliken, wenn ihre eindeutige ID übereinstimmt.
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 51
wird, dass die Universal ID eines Dokument sowohl vor dem Aufteilen als auch nach
dem Zusammenführen identisch bleibt (vgl. Abbildung 4-11). Hieraus ergibt sich,
dass bestehende Verknüpfungen (DocLinks) auf dieses Dokument auch beim
Durchlaufen eines Splits ihre Gültigkeit beibehalten. Nach jedem Zusammenführen
wird die jeweils oben befindliche Ebene des Stapels von Split-IDs gelöst.
Die eben vorgestellte datentechnische Verwaltung von Splits lässt sich also in zwei
Dimensionen aufteilen. Die erste Dimension bildet der Stapel (Stack) mit den Split-
IDs, der die Hierarchieebene eines Splits verwaltet. Als zweite Dimension sind die
Split-IDs selbst zu sehen. Diese verwalten alle Dokumente eines Split der gleichen
Hierarchieebene anhand deren eindeutiger Dokumenten-IDs, wobei die erste Position
immer durch die Dokumenten-ID des Master-Dokumentes belegt ist (vgl. Tabelle 4-
1).
Eben
en d
es S
tape
ls (S
tack
s),
jede
Ebe
ne e
nthä
lt ei
ne S
plit-
ID
Dokumenten-IDs verwaltet in Split-IDs
Master (0)
Slave(1)
Slave (2)
Slave (m)
...
(0)
(n)
...
(2)
(1)
UNID1
UNID1
UNID1
UNID3 UNID2
UNID4
UNID6 UNID5
UNID1#UNID2#UNID3
= Split-ID
UNID1#UNID4
UNID1#UNID5#UNID6
Tabelle 4-1: Dimensionen der Verwaltung von Splits
Kommen wir nun wieder zurück auf das im vorherigen Kapitel vorgestellte
Fallbeispiel. Nachdem nun ein Teil des Prozessmodells durch den Abteilungsleiter
gestaltet wurde (vgl. Abbildung 4-10), leitet er den Vorgang weiter. Die Workflow-
Engine ermittelt dabei alle gültigen Transitionen von dem Vorgangsknoten 0. Im
vorliegenden Fall sind zwei Transitionen des Typs „Always“ zu den Aufgaben 1 und
2 vorhanden. Das Originaldokument wird zum Vorgangsknoten 1 (Erfassung der
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 52
benötigten Software) und die Kopie zum Vorgangsknoten 2 (Erfassung der
benötigten Hardware) weitergeleitet.
Der Bearbeiter der Aufgabe 1 entschließt sich nach der Erfassung des Bedarfs, auch
Informationen zu alternativen Software-Produkten anderer als des bisherigen
Herstellers einzuholen. Aus diesem Grund modifiziert er das Prozessmodell und fügt
drei weitere Aufgaben hinzu (vgl. Abbildung 4-12). Die Aufgabe 4 und 5 („Info
bisherigen Software-Hersteller“ und „Entscheidung für Hersteller“) will er selber
bearbeiten. Aufgabe 3 („Info alternative Hersteller“) soll ein Kollege von ihm
übernehmen. Bei der Weiterleitung durch die Engine wird wiederum das
Originaldokument an den Vorgangsknoten 3 und eine Kopie an den Vorgangsknoten
4 weitergeleitet.
0
3
1 2
6
4
5
7
Erneuerung des EDV-Systems
Erfassung der benötigten Hardware
Erfassung der benötigten Software
Informationen zu Software-
Produkten des bisherigen Herstellers
Informationen zu Software-Produkten alternativer Hersteller
Entscheidung, welche Software eingesetzt wird
Erfassung der benötigten Netzwerk-
Komponenten
Erfassung des gesamten
EDV-Bedarfs
always
always
always
always
always
always
always always
always
Abbildung 4-12: Fallbeispiel „Erneuerung des EDV-Systems“, Phase 2
Wird jetzt eine der Aufgaben 4 oder 3 abgeschlossen und die Weiterleitung
ausgelöst, prüft die Engine zuerst, ob der nächste Vorgangsknoten ein möglicher
Join-Knoten ist. Diese Prüfung wird nur vorgenommen, wenn das aktuelle Dokument
ein Split-Dokument ist und nur genau eine Transition des Typs „Always“ zur
nächsten Aufgabe besteht. Normalerweise würde die Engine bei nur einer Transition
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 53
das Dokument linear an den nächsten Vorgangsknoten weiterleiten. Handelt es sich
bei dem nächsten Knoten um einen Join-Knoten, so müssen die Split-Dokumente
dort so lange verweilen, bis alle Dokumente eines Split an diesen Vorgangsknoten
angekommen sind. Erst dann wird die Zusammenführung der Inhalte vorgenommen.
Bei der Prüfung wird die folgende Definition eines Join-Knotens berücksichtigt:
Der nächste Vorgangsknoten ist nur dann ein möglicher Join-Knoten, also ein
Knoten an dem die Dokumente eines Splits wieder zusammengeführt werden, wenn
der Verlauf eines der anderen Dokumente des gleiches Splits auch diesen Knoten
kreuzt.
Technisch gesehen holt sich die Engine alle anderen Dokumente des gleichen Splits
und prüft von ihrer Position aus rekursiv alle möglichen Verläufe innerhalb des
Prozessmodells. Liegt die Task-ID des nächsten Vorgangsknoten auf dem Verlauf
eines der anderen Split-Dokumente, so ist dieser Knoten ein Join-Knoten.
Im vorliegenden Fallbeispiel ergibt die Prüfung den Wert „Wahr“, so dass das
Dokument mit der zuerst abgeschlossenen Aufgabe zum Vorgangsknoten 5
weitergeleitet wird. Diese Dokument erhält den Status „Warten“, da noch nicht alle
anderen Dokumente der gleichen Split-Hierarchie dort angekommen sind. Wird
daraufhin auch die andere Aufgabe abgeschlossen und an den Vorgangskonten 5
weitergeleitet, stellt die Engine fest, dass alle Dokumente des gleichen Splits dort
vorhanden sind und führt die Inhalte der Dokumente zusammen.
Auf der linken Seite der Prozessstruktur wird die Aufgabe 2 (Erfassung der
benötigten Hardware) von einem anderen Teammitglied bearbeitet. Um sicher zu
gehen, dass die Anzahl der Netzwerkkomponenten (z.B. Anschlussdosen) für die
beiden neuen Arbeitsplätze ausreichend ist, fügt der Anwender die Aufgabe 6
(Erfassung der benötigten Netzwerkkomponenten) in die Prozessstruktur ein und
setzt als Bearbeiter einen Kollegen ein, der sich in der Netzwerktechnologie besser
auskennt. Durch die erneute Modifizierung des Prozessmodells entsteht die in
Abbildung 4-12 abgebildete Prozessstruktur.
Löst der Bearbeiter der Aufgabe 2 nun die Weiterleitung aus, so prüft die Engine
zuerst, ob der nächste Vorgangsknoten ein Join-Knoten ist. Im vorliegenden Beispiel
ist das nicht der Fall, so dass eine lineare Weiterleitung zur Aufgabe 6 stattfindet.
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 54
Nach Abschließen der Aufgaben 6 und 5 werden die Ergebnisse der beiden Aufgaben
in Vorgangsknoten 7 zusammengefasst und dem Abteilungsleiter zur Bearbeitung
zugewiesen. Um den Vorgang abzuschließen, fügt er weitere Aufgaben in die
Prozessstruktur ein. Dazu gehören die Einholung von Angeboten zweier
ortsansässiger EDV-Unternehmen und die Entscheidung der Auftragserteilung an
eines der Unternehmen. In Abbildung 4-13 ist das gesamte Prozessmodell grafisch
dargestellt. Die Weiterleitung des Vorgangs von Knoten 7 bis 9 erfolgt wiederum
linear. Die Weiterleitung am Vorgangsknoten 9 wird im nächsten Kapitel detaillierter
beschrieben.
0
3
1 2
6
4
5
7
Erneuerung des EDV-Systems
Erfassung der benötigten Hardware
Erfassung der benötigten Software
Informationen zu Software-
Produkten des bisherigen Herstellers
Informationen zu Software-Produkten alternativer Hersteller
Entscheidung, welche Software eingesetzt wird
Erfassung der benötigten Netzwerk-
Komponenten
Erfassung des gesamten
EDV-Bedarfs
always
always
always
always
always
always
always always
always
8
10
9
Einholung von Angeboten der
Unternehmen A und B
Auftragserteilung an Unternehmen A
Auftragserteilung an Unternehmen B
SingleChoice SingleChoice
always
Entscheidung für ein Angebot
always
11
Abbildung 4-13: Fallbeispiel „Erneuerung des EDV-Systems“, Phase 3
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 55
4.2.2.2 Auswahl exklusive/mehrfach (Choice single/multiple)
Für die Verarbeitung des Transitionstypen „Choice“ ist die Interaktion mit dem
Anwender des Systems erforderlich. Hierzu werden Promptboxen, die eine Eingabe
durch den Benutzer erfordern, verwendet. Handelt es sich bei dem Transitionstypen
um eine Mehrfachauswahl (multiple Choice), so kann der Benutzer auch
dementsprechend mehr als eine Aufgabe in der Promptbox zur Weiterleitung
markieren (vgl. Abbildung 4-14). Sollte das der Fall sein, so führt die Workflow-
Engine eine Aufteilung (Split) des Vorganges auf die ausgewählten Aufgaben. Ist der
Transitionstyp eine exklusive Auswahl (single Choice), so kann der Anwender genau
nur eine Aufgabe zur Weiterleitung des Vorganges markieren. Der Vorgang wird
dann linear an den nächsten Vorgangsknoten weitergeleitet.
Abbildung 4-14: Promptbox „Mehrfachauswahl“ am
Beispiel der Erstellung einer WWW-Präsenz
Bezugnehmend auf das Beispiel der Erneuerung des EDV-Systems wird der
Abteilungsleiter, nachdem er die Weiterleitung im Vorgangsknoten 9 auslöst hat,
abgefragt, an welches Unternehmen der Auftrag für die Erneuerung des EDV-
Systems erteilt werden soll (vgl. Abbildung 4-15).
Abbildung 4-15: Promptbox "exklusive Auswahl"
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 56
Abhängig davon, wie sich der Abteilungsleiter entscheidet, wird der Vorgang
entweder zu Aufgabe 10 oder 11 weitergeleitet. Dort angekommen, kann er dann
durch die Auftragserteilung beendet werden.
4.2.2.3 Berechnete Weiterleitung (Condition/Else)
Bei der Verarbeitung von Transitionen des Typs „Condition/Else“ werden vorher
definierte Bedingungen durch die Ad-hoc-Workflow-Engine ausgewertet. Für die
Definition von Bedingungen werden @Funktionen benutzt, mir deren Hilfe sich
Makros programmieren lassen. Die Verarbeitung dieser Makros wird durch die Lotus
Script Funktion „Evaluate“ gewährleistet. Doch sind bei deren Benutzung einige
Restriktionen zu beachteten, denn nicht alle @Funktionen17 werden von Evaluate
unterstützt.
Technisch gesehen, prüft die Workflow-Engine die Gültigkeit der logischen
Bedingungen von Transitionen. Ergibt die Evaluierung der Bedingung den Wert
„Wahr“, so wird der Vorgang an die Aufgabe, zu der diese Transition führt, zur
Weiterleitung markiert. Ergibt die Evaluierung den Wert „Falsch“ oder einen Fehler
(z.B. bei Syntax-Fehlern der Bedingungen), so wird der nächste Vorgangsknoten bei
der Weiterleitung nicht mit einbezogen.
Sind die Bedingungen von mehr als einer Transitionen gültig, so wird der Vorgang in
mehrere Aufgaben aufgeteilt (Split). Sollte die Bedingung keiner Transitionen gültig
sein, so tritt der „Sonst-Fall“ zu, d.h. der Vorgang wird nur an die Aufgabe
weitergeleitet, zu der die Transition vom Typ „Else“ führt.
Die Abbildung 4-16 zeigt eine mögliches Prozessmodell mit den Transitionen des
Typs „Condition/Else“. Die dort verwendeten Makros (Bedingungen) beziehen sich
auf das numerische Feld mit der Bezeichnung „Ausgabe“ und ergeben den Wert
„Wahr“ oder „Falsch“. Je nachdem, wie groß der numerische Wert des Feldes ist,
wird der Vorgang an einer der nachfolgenden Aufgaben weitergeleitet.
17 Folgende @Funktionen werden von Evaluate nicht unterstützt: @Command, @DbManager, @DbName, @DbTitle, @DDEExecute, @DDEInitiate, @DDEPoke, @DDETerminate, @DialogBox, @PickList, @PostedCommand, @Prompt und @ViewTitle
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 57
1
0 2
3
0
4
2
3
4
5
1
@If( Ausgabe >= 10000; @True; @False)
@If( Ausgabe > 1000 & Ausgabe < 10000; @True; @False)
Else
Always
Always
Always
Abbildung 4-16: Beispiel einer Prozessstruktur mit berechneter Weiterleitung
4.2.2.4 Verarbeitung von Schleifen
Da es in der realen Geschäftswelt genügend Situationen gibt, die eine Rückfrage oder
weitere Informationen erfordern, unterstützt die Ad-hoc-Workflow-Engine auch das
Verarbeiten von Schleifen im Prozessmodell. Die Verarbeitung wird anhand des
Fallbeispiels „Erstellung einer Webseite mit Produktinformationen in englischer
Sprache“ erklärt (vgl. Abbildung 4-17). Obwohl auch in diesem Beispiel eine Ad-
hoc-Entstehung des Prozessmodells denkbar wäre, soll jenes bereits vor der
Ausführung modelliert worden sein.
Als Schleife kann man einen rückwärts verlaufenden bzw. gerichteten
Prozessgraphen bezeichnen. Das heißt, die Transition der aktuellen Aufgabe führt zur
einen Aufgabe, die bereits zu einem früheren Zeitpunkt bearbeitet wurde. Von dieser
früheren Aufgabe führt der Prozessverlauf direkt oder indirekt wiederum zur
aktuellen Aufgabe.
Im vorliegenden Fallbeispiel ist die Transition von der Aufgabe 3 zur Aufgabe 1 für
die Bildung der Schleife verantwortlich. Wird in dem Startvorgangsknoten der
Vorgang weitergeleitet, so wird dieser zuerst auf die zwei nachfolgenden Aufgaben
aufgeteilt (Split). Nach dem Erstellen der Grafiken (Vorgangsknoten 2) wird der
Vorgang zum Knoten 5 weitergeleitet, wo er solange verbleibt, bis alle Dokumente
des Splits dort angekommen sind. Die beiden Bearbeiter der Aufgaben „Verfassen
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 58
der Produktinformation in deutscher Sprache“ und „Übersetzung der
Produktinformation in die englische Sprache“ können den Vorgang nach Bedarf
zwischen sich hin- und herleiten. Eine solche Vorgehensweise kann im vorliegenden
Fall sehr nützlich sein, da dem Übersetzer möglicherweise das technische Wissen
fehlen kann und er deshalb häufig rückfragen muss. Ist die Übersetzung gelungen, so
kann sie entweder vom Vorgangsknoten 1 oder 3 an der Knoten 4 weitergeleitet
werden. Ist die Festlegung der Eingliederung der Produktinformation in die
bestehende WWW-Präsenz beschlossen, so trifft der Vorgang in Knoten 5 ein, wo er
zusammengeführt und dem Webprogrammierer zur Bearbeitung vorgelegt wird.
0
3
1
4
5
Erstellung einer Webseite mit Produktinformationen in
englischer Sprache
Verfassen der Produktinformation in
deutscher Sprache
Übersetzung der Produktinformation in die englische Sprache Erstellen der
Grafiken (Fotos)
always
always
always
2
Programmierung der Webseite
SingleChoice
SingleChoice
always
Festlegen der Eingliederung in die bestehende WWW-Präsenz
SingleChoice
SingleChoice
Abbildung 4-17: Fallbeispiel „Erstellung einer Webseite mit Produktinformationen in
englischer Sprache“
Bei der Modellierung von Schleifen muss die folgende Restriktion berücksichtigt
werden:
Innerhalb einer Schleife (gestrichelter Bereich der Abbildung 4-17) darf keine
weitere Aufteilung (Split) der Aufgaben stattfinden.
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 59
Dafür gibt es folgende zwei Gründe: Zum einen könnte das weitere Aufteilen von
Aufgaben innerhalb einer Schleife zu einer großen Vielzahl von Split-Dokumenten
führen, mit deren Verwaltung die Workflow-Engine im jetzigen
Implementierungszustand überfordert wäre. Zum anderen wird bei der Prüfung, ob
der nächste Knoten ein Join-Knoten ist, die Struktur von der aktuellen Position der
anderen Split-Dokumente rekursive durchlaufen. Da jedes Dokument innerhalb einer
Schleife jeden Vorgangsknoten durchlaufen kann, wäre somit jeder Knoten ein
möglicher Join-Knoten. Die Feststellung des Vorgangsknoten, an denen der Vorgang
wieder zusammengeführt werden müsste, wäre nicht möglich.
4.2.3 Ausnahmebehandlung
Da ad-hoc-entstandene Workflow-Modelle bis zu ihrer abschließenden Modellierung
eine offene bzw. unvollständige Struktur enthalten, kann während ihrer Ausführung
der Vorgang das offene Ende der Prozessstruktur erreichen. In solchen Fällen führt
die Workflow-Engine eine Ausnahmenbehandlung durch, bei der dem Benutzer eine
Promptbox mit drei Auswahlmöglichkeiten angezeigt wird (vgl. Abbildung 4-18).
Wählt der Anwender die Option „Weitermodellieren“, so wird der Ad-hoc-
Workflow-Modeler gestartet, um das Prozessmodell zu modifizieren und eventuell
weitere Aufgaben hinzuzufügen.
Abbildung 4-18: Promptbox Ausnahmebehandlung
Sollte der Anwender aufgrund fehlender Kenntnisse die Situation nicht einschätzen
können oder an dieser Stelle keine Entscheidung treffen wollen, so kann er auch die
Option „Weiß nicht. Initiator wird benachrichtigt.“ auswählen. Bei dieser Auswahl
wird der Initiator des Workflows über die Ausnahme informiert. Er sollte dann durch
Bearbeiten des Workflows entscheiden, wie an der aktuellen Position weiter
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 60
verfahren wird. Bei der letzten Option „Aufgabe als Endaufgabe/Endtask markieren“,
wird die aktuelle Aufgabe als Endaufgabe spezifiziert. Handelt es sich bei der
Aufgabe um keine aufgeteilte Aufgabe (kein Split-Dokument), so ist diese auch das
einzige Dokument im Workflow-Modell. In diesem Fall wird der Workflow beendet.
Ist die aktuelle Aufgabe aber eine vorher aufgeteilte, also ein Split-Dokument, wird
der Anwender nochmals um Bestätigung gebeten (vgl. Abbildung 4-19), denn das
Herausnehmen eines Dokumentes aus einem Split bedeutet auch, dass dessen Inhalte
respektive Ergebnisse nicht mehr mit den anderen Split-Dokumenten
zusammengeführt werden können. Die Workflow-Engine muss in diesem Fall die
Verwaltung des Splits neu organisieren, indem der Split-Stack mit den neu
berechneten Split-IDs gefüllt wird (vgl. Kapitel 4.2.2.1).
Abbildung 4-19: Bestätigung, Aufgabe als „Endaufgabe“ spezifizieren
Neben dieser automatischen Ausnahmenbehandlung, die beim Erreichen des letzten
Knotens einer offenen Workflow-Struktur gestartet wird, hat jeder Anwender die
Möglichkeit, die aktuelle Aufgabe als Endaufgabe zu spezifizieren. Dies führt wie
oben bereits beschrieben bei Split-Dokumenten zu deren Herausnahme aus dem Split
und bei Nicht-Split-Dokumenten zur Beendigung des Workflows.
Eine weitere Ausnahme ist das sofortige Beenden des Workflow, das auch jederzeit
durch den Benutzer eingeleitet werden kann. Sollten sich Split-Dokumente im
Workflow befinden, so werden deren Inhalte in das Hauptdokument
zusammengeführt.
4.2.4 Workflow abschließen
Ist das Ende einer Prozessstruktur erreicht und wird die letzte Aufgabe
abgeschlossen, so bekommt der Workflow den Status „Abgeschlossen“. Außerdem
werden erst an dieser Stelle alle durch die Bearbeitung dieses Workflows
entstandenen Split-Dokumente gelöst, denn bei der Zusammenführung (Join) von
4 Realisierung einer Workflow-Engine für Groupware-basierte Ad-hoc-Workflows Seite 61
Dokumenten werden die sogenannten Slave-Dokumente, deren Inhalte in das Master-
Dokument übernommen werden, nur als abgearbeitet markiert. Sie sind also bis zum
Abschließen des Vorganges in der Datenbank vorhanden, werden aber nicht mehr zur
Bearbeitung angezeigt.
Die folgende Abbildung soll abschließend nochmals den gesamten
Entscheidungsbaum der Ad-hoc-Workflow Engine bei der Weiterleitung einer
Aufgabe darstellen und verdeutlichen.
Aktuelle Aufgabe
Prüfung der Gültigkeit von Transitionen
Nur genau eine gültige Transition
Mehr als eine gültige Transition Aufgabe aufteilen (Split)
Ist aktuelles Dokument ein Split-Dokument ?
Ja
Nein
Ist nächsten Vorgangsknoten ein Join-Knoten ?
Nein
Ja
Lineares Weiterleiten
Lineares Weiterleiten
Kein Zusammenführen Nein
Sind alle anderen Dokumente des Splits vorhanden ?
Ja Inhalte der Dokumente zusammenführen (Join)
keine gültige Transition
Ist Aufgabe „EndTask“ ?
Nein
Ja Workflow beenden
Ausnahmebehandlung
Abbildung 4-20: Entscheidungsbaum der Engine bei der Weiterleitung eines Vorganges
5 Ausblick Seite 62
5 Aktueller Implementierungsstand und Ausblick Der aktuelle Stand der Implementierung erlaubt neben der linearen Weiterleitung von
Vorgängen insbesondere das Aufteilen (Split) eines Vorganges. Ein solcher Split
führt zu mehreren Aufgaben, die parallel von verschiedenen Anwendern bearbeitet
werden. Im Anschluss an diese Bearbeitung werden die Ergebnisse durch die Engine
wieder zusammengeführt (Join) und der Vorgang entsprechend des Workflow-
Modells zum nächsten Vorgangsknoten weitergeleitet. Der Verarbeitungslogik liegt
ein hierarchisches Modell des Aufteilens und Zusammenführens vom Vorgängen
zugrunde, das im Kapitel 4.2.2.1 detailliert beschrieben wurde. Dieses hierarchische
Modell unterstützt keine Querverbindungen zwischen Knoten verschiedener
Splithierarchien bzw. Splits verschiedener Verlaufspfade und stellt deshalb eine
mögliche Erweiterung der Workflow-Engine dar.
Neben der Verarbeitung der Transitionstypen „Always“ und „Choice single/multiple“
unterstützt die Engine auch die Verarbeitung des Transitionstyps „Condition/Else“,
der berechneten Weiterleitung (vgl. Kapitel 4.2 ff.). Die Implementierung der
berechneten Weiterleitung erfolgte durch die Verwendung der Lotus Script Funktion
„Evaluate“ (vgl. Kapitel 4.2.2.3). Da diese Funktion nur einen Teil der @Funktionen
von Lotus Notes evaluieren kann, ist hier eine Weiterentwicklung der Workflow-
Engine vorstellbar.
Das zur Zeit implementierte Exception Management umfasst die wichtigsten
Ausnahmebehandlungen, die sich aus dem GroupProcess-Konzept ergeben (vgl.
Kapitel 4.2.3). Eine Weiterentwicklung des Exception Managements wird angesichts
der hohen Änderungsdynamik von Ad-hoc-Workflows als sinnvoll gesehen. Dazu
gehören beispielsweise das Zurückleiten des Vorganges zum vorherigen
Vorgangsschritt sowie das Umleiten des Vorganges an einen beliebigen Knoten
innerhalb des Workflow-Modells.
Als einer der nächsten Implementierungsschritte ist das Weiterleiten von
Teilaufgaben bzw. ganzen Unterprozessen an andere Organisationen zu sehen. Die
Unterstützung einer solchen interorganisatorischen Kooperation kann durch das
Versenden von Message-Objekten realisiert werden, die in standardisierter Form alle
5 Ausblick Seite 63
relevanten Informationen des Workflow-Modells beinhalten. Bei GroupProcess wird
das Workflow-Modell inklusive aller zusätzlich relevanten Informationen als Ad-
hoc-Workflow-Objekt in ein einziges Textfeld mittels der Beschreibungssprache
XML gespeichert. Diese Tatsache erleichtert die Umwandlung der Vorgänge in
formalisierte Message-Objekte und macht damit den Einsatz in verschiedenen Ad-
hoc-Workflow-Management-Systemen möglich.
Um die Stabilität der Laufzeitumgebung zu erhöhen, sollte vor dem Weiterleiten
eines Vorgangs eine Validierung des Prozessmodells durch die Workflow-Engine
durchgeführt werden. Zum aktuellen Zeitpunkt wird diese Validierung durch den Ad-
hoc-Workflow-Modeler übernommen.
Damit die Workflow-Engine im operativen Umfeld getestet werden kann, sollte der
Prototyp des Ad-hoc-Workflow-Modelers fertiggestellt werden. Eine Integration der
Ad-hoc-Workflow-Engine in ein aktuelles Workflow Management System wie dem
Espresso System ist in dieser Testphase sinnvoll.
In einer späteren Implementierungsphase von GroupProcess sollte die Entwicklung
eines „Transformation Tool“ (Ad hoc to predef. WF) vorgenommen werden. Dieses
Werkzeug dient der Transformation von Ad-hoc-Workflows in standardisierten
Workflows. Damit wird die Zielsetzung, informelle Strukturen zu formellen
Strukturen umzuwandeln, von GroupProcess unterstützt.
6 Zusammenfassung Seite 64
6 Zusammenfassung Im Rahmen dieser Diplomarbeit ist eine Groupware-basierte Ad-hoc-Workflow-
Engine für das GroupProcess-System entstanden. Das GroupProcess-System ist eine
Erweiterung bestehender Workflow-Management-Systeme, die insbesondere das
Verarbeiten von Ad-hoc-Workflows unterstützt.
Nach der Vorstellung der CSCW-Forschung und der Abgrenzung von Groupware
wurden zentrale Termini, die der vorliegenden Arbeit zugrunde liegen, beschrieben.
Anschließend folgte eine Darstellung der zur prototypischen Realisierung
verwendeten Groupware-Plattform Lotus Notes. Dazu wurden die wichtigsten
Architekturmerkmale dieser Plattform aufgezeigt. Weiterhin wurde das Espresso-
System von Pavone als eines der aktuellen Workflow-Management-Systeme
vorgestellt. Unter anderem wurde hier auch das GroupFlow-Kontinuum beschrieben,
das als Ausgangspunkt für die Entwicklung des GroupProcess-Kontinuums diente.
Auf Basis des GroupProcess-Kontinuums, das die Zuständigkeit von herkömmlichen
WfMS und Ad-hoc-WfMS abgrenzt, wurde dann das GroupProcess-Konzept
vorgestellt. Hierbei wurden Anforderungen und Merkmale eines Ad-hoc-Workflow-
Management-Systems aufgezeigt und erläutert. Die simultane Ausführung von Build-
Time und Run-Time und das partizipative, verteilte Design sind in diesem
Zusammenhang besonders zu erwähnen. Abschließend wurde in diesem Abschnitt
eine Anforderungsliste für eine Ad-hoc-Workflow-Engine erarbeitet.
Aufbauend auf diese Anforderungsliste wurde dann die Ad-hoc-Workflow-Engine
entwickelt, die als wichtigstes Ergebnis dieser Diplomarbeit zu sehen ist. Ihre
Funktionsweise setzt die konzeptionellen Grundlagen von GroupProcess um und
unterstützt insbesondere die Verarbeitung von Ad-hoc-Workflows. Zum besseren
Verständnis wurde die Funktionalität der Engine anhand von Fallbeispielen
dargestellt.
Um Aussagen über das Verhalten der Workflow-Engine sowie den Effizienzgewinn
durch den Einsatz des Ad-hoc-Workflow-Management-Systems machen zu können,
sollte im nächsten Schritt der operative Einsatz von GroupProcess in einer
Testumgebung erfolgen.
Literaturverzeichnis Seite 65
Literaturverzeichnis [Bäsner, Kühn, Stork 2000]
Bäsner, Jörg; Kühn, Peter; Stork, Thorsten: Entwicklung eines Java-basierten
Modellierungswerkzeuges für Ad-hoc-Workflows im Projektbereich GroupProcess,
in: Seminararbeit, Universität-GH Paderborn Lehrstuhl Wirtschaftsinformatik 2,
2000
[Goos, Laumen, Schramm 2001]
Goos, Carl; Laumen, Christian; Schramm, Stephan: Konzeption und prototypische
Implementation einer Datenstruktur zur Speicherung von Ad hoc Workflows nach
dem GroupProcess Konzept in Dokumenten, in: Seminararbeit, Universität-GH
Paderborn Lehrstuhl Wirtschaftsinformatik 2, 2001
[Hasenkamp/Syring 1993]
Hasenkamp, Ulrich; Syring, Michael: Workflow-Management, in: Office
Management, Juni 1993
[Hasenkamp/Syring 1994]
Hasenkamp, Ulrich; Syring, Michael: CSCW in Organisationen - Grundlage und
Probleme, in: Hasenkamp, U. et al. (Hrsg.): CSCW - Computer Supported
Cooperative Work, Informationssysteme für dezentralisierte
Unternehmensstrukturen, Addison-Wesley, Bonn etc., 1994, pp. 15 - 37.
[Herold/Fischer 1994]
Herold, Werner; Fischer, Joachim; Komponenten von Informationssystemen, in:
Fischer, J.; Herold W.; Dangelmeier, W.; Nastansky, L.; Wolff, R. (Hrsg.): Bausteine
der Wirtschaftsinformatik, S + W Steuer- und Wirtschaftsverlag, Hamburg, 1994, S.
59-186
[Huth/Erdmann/Nastansky 2001]
Huth, Carsten; Erdman, Ingo; Nastansky, Ludwig: GroupProcess: Using Process
Knowledge from the Practical Operation of Ad Hoc Processes for the Participative
Literaturverzeichnis Seite 66
Design of Structured Workflows, Thirty-Fourth Annual Hawaii International
Conference on System Sciences , Hawaii 2001
[Huth/Nastansky 2000a]
Huth, Carsten; Nastansky, Ludwig: GroupProcess: Partizipatives, verteiltes Design
und simultane Ausführung von Ad hoc Geschäftsprozessen - Eine Erweiterung eines
...; in: Herrad Schmidt (Ed.): Modellierung betrieblicher Informationssysteme,
Proceedings der MobIS-Fachtagung 2000, 11. und 12. Oktober 2000, Rundbrief der
GI-Fachgruppe 5.10, 7. Jahrgang, Heft 1
[Huth/Nastansky 2000b]
Huth, Carsten; Nastansky, Ludwig: GroupProcess: Partizipatives, verteiltes Design
und simultane Ausführung von Ad hoc Geschäftsprozessen; in: Engelien, Martin;
Neumann, Detlef (Eds.): GeNeMe 2000: Gemeinschaften in Neuen Medien; TU
Dresden 5. und 6. Oktober 2000, S. 319-334
[Johansen 1988]
Johansen, Robert: Groupware, Computer Support for Business Teams, New York,
1988
[Lawrence 1997]
Lawrence, Peter: Workflow Handbook, John Wiley & Sons Ltd, Chichester, England,
1997.
[Media Center]
Media Center Office Systeme, in LernSpace-Umgebung, Fachbereich
Wirtschaftsinformatik 2, Universität-Gesamthochschule Paderborn
[Lotus Dev. 1995]
Lotus Dev.,: Groupware - Communication, Collaboration, Coordination, November,
1995.
[Lotus Dev. 2000a]
Lotus Dev.,: Notes 5 Manuals - Application Development with Domino Designer,
Lotus Development, 2000.
Literaturverzeichnis Seite 67
[Lotus Dev. 2000b]
Lotus Dev.,: Notes 5 Manuals - Domino Designer Programming Guide Vol. 1
Formula Language, Lotus Development, 2000.
[Lotus Dev. 2000c]
Lotus Dev.,: Notes 5 Manuals - Domino Designer Programming Guide Vol. 2
LotusScript Classes, Lotus Development, 2000.
[Lotus Dev. 2000d]
Lotus Dev.,: Notes 5 Manuals - Domino Designer Programming Guide Vol. 3 Java
Classes, Lotus Development, 2000.
[Lotus Dev. 2000e]
Lotus Dev.,: Notes 5 Manuals - LotusScript Language Guide, Lotus Development,
2000.
[Nastansky 1993]
Nastansky, Ludwig (Hrsg.): Workgroup Computing: Computergestützte Teamarbeit
(CSCW) in der Praxis; Neue Entwicklungen und Trends ; S + W Steuer- und
Wirtschaftsverlag, Hamburg 1993
[Nastansky/Bruse/Haberstock/Huth/Smolnik 2000]
Nastansky, Ludwig; Bruse, Thomas; Haberstock, Philipp; Huth, Carsten; Smolnik,
Stefan: Büroinformations- und Kommunikationssysteme: Groupware, Workflow-
Management, Organisationsmodellierung und Messaging-Systeme; in: Fischer, J.;
Herold W.; Dangelmaier, W.; Nastansky. L.; Suhl, L. (Hrsg.): Bausteine der
Wirtschaftsinformatik; Berlin 2000; S. 235-322
[Nastansky/Hilpert 1994]
Nastansky, Ludwig; Hilpert, Wolfgang: The GroupFlow System: A Scalable
Approach to Workflow Management between Cooperation and Automation, in:
Wolfinger, Bernd (Ed.): Innovationen bei Rechen- und Kommunikationssystemen -
Eine Herausforderung an die Informatik, Proceedings of 24th Anual Konference of
the German Computer Society during 13th World Computer Congress, IFIP '94,
Springer Verlag, Berlin, Heidelberg etc., 1994, pp. 473 - 479.
Literaturverzeichnis Seite 68
[Nastansky/Huth 2000]
Nastansky, Ludwig; Huth, Carsten: Groupware zur Unterstützung neuer
Organisationsformen in der Industrie: Aufbau- und Prozeßorganisation im virtuellen
Unternehmen, in: Industrie Management 6/2000, GITO mbH Verlag für Industrielle
Informationstechnik und Organisation, Berlin, Juni 2000, S. 69-73
[Rathgeb 1994]
Rathgeb, Michael: Einführung von Workflow-Management-Systemen, in:
Hasenkamp, U.; Kirn, S.; Syring, M. (Hrsg.): CSCW - Computer Supported
Cooperative Work, Informationssysteme für dezentralisierte
Unternehmensstrukturen, Addison-Wesley, Bonn etc., 1994, pp. 45 - 66.
[Sauter/Morger 1996]
Sauter, Christian; Morger, Othmar: Die Workflow Management Coalition, in:
Wirtschaftsinformatik, Nr. 2, April, 1996, pp. 228-229.
[Teufel 1996]
Teufel, Stefanie: Computerunterstützte Gruppenarbeit - eine Einführung, in: Österle,
H.; Vogler, P. (Hrsg.): Praxis des Workflow Managements, Vieweg, Braunschweig,
Wiesbaden, 1996, pp. 35-63.
[Teufel/Sauter/Mühlherr/Bauknecht 1995]
Teufel, Stefanie; Sauter, Christian; Mühlherr, Thomas; Bauknecht, Kurt:
Computerunterstützung für die Gruppenarbeit, Addison-Wesley, Bonn, 1995
[WfMC 1994]
Workflow Management Coalition: The Workflow Reference Model, Document
Number TC00-1003 Document Status - Issue 1.1, by David Hollingworth, Nov 29,
1994.
[WfMC 1996]
Workflow Management Coalition: Terminology & Glossary, Document Number
WFMC-TC-1011 Document Status - Issue 2.0, June, 1996.
Literaturverzeichnis Seite 69
[WfMC 2000]
Workflow Management Coalition: Workflow Standard - Interoperability Wf-XML
Binding, Document Number WFMC-TC-1023 Document Status – Official 1-May-
2000, 2000.
Anhang Seite 70
Anhang
A.1 Installationsanweisung
Zur Installation der prototypischen Ad hoc Workflow-Engine ist die
Anwendungsdatenbank aus dem Archiv gprocess.zip (nur in elektronischer
Version vorhanden) in das Lotus Notes/Domino Daten-Verzeichnis zu kopieren. Eine
Server-/Client-Umgebung ist nicht notwendig. Da die Engine in einer eigenen
Anwendungsdatenbank implementiert wurde, ist auch das Espresso System von
Pavone nicht erforderlich.
Mit der Aktionsschaltfläche „Prozessmodell“ lassen sich bis zur Fertigstellung des
Ad-hoc-Workflow-Modelers einige einfache Prozessmodelle zu Testzwecken in das
aktuelle Dokument einfügen.
A.2 Dokumentation
A.2.1 Felder in einem Workflow-Dokument
Workflow-Klassen-Abschnitt
Feldname (Typ) Beschreibung
AdHocWf (Text)
gesamtes Ad hoc Workflow Objekt im XML-Format
Protokoll-Abschnitt
Feldname (Typ) Beschreibung
WfProtocol (Text)
Verlauf der Workflow-Instanz z.B. 200104201530#CN=Claudius Niebiossa/O=NIC#1#2:3:4#Split
Anhang Seite 71
Workflow-Abschnitt
Feldname (Typ) Beschreibung
WfDescription (Text)
Beschreibung des Workflows
WfID (Text)
Eindeutige ID des Workflows bestehend aus dem Usernamen und der aktuelle Zeit z.B. CN=Claudius Niebiossa/O=NIC#20.04.01 15:34:16
WfInitiator (Text)
Der Name der Workflow-Initiators z.B. CN=Claudius Niebiossa/O=NIC
WfName (Text)
Der Name des Workflows
WfSplits (Text-Liste)
Liste aller Split-Hierarchien mit den Dokumenten-IDs der jeweiligen Splits
WfStatus (Text)
Status des Workflows Werte: „Neu“, „In Arbeit“, „Warten“, „SplitArchiv“, „Abgeschlossen“
Task-Abschnitt
Feldname (Typ) Beschreibung
WfTask (Text)
Name der aktuellen Aufgabe
WfTaskActivities (Text-Liste)
Liste aller zu erledigenden Aktivitäten der aktuellen Aufgabe
WfTaskCompletedActivities (Text-Liste)
Liste aller erledigten Aktivitäten der aktuellen Aufgabe, die vom Bearbeiter abgehakt wurden
WfTaskDescription (Text)
Beschreibung der aktuellen Aufgabe
WfTaskEditors (Text-Liste)
Liste aller Editoren der aktuellen Aufgabe
WfTaskID (Text)
Die eindeutige ID der Aufgaben innerhalb des Prozessmodells
Anhang Seite 72
A.2.2 Prozeduren und Funktionen der Script Libraries
AdHocWorkflowUI
Prozedur bzw. Funktion Beschreibung
Sub NextTask Eingangsprozedur, die beim Weiterleiten aufgerufen wird. Sie dient der Interaktion mit dem Anwender und entscheidet entsprechend des Prozessmodells, welche Art der Weiterleitung aufgerufen wird. Der Entscheidungsbaum ist grafisch in Abbildung 4-20 dargestellt.
AdHocWorkflow
Prozedur bzw. Funktion Beschreibung
Sub SetAllWfFieldsValues Wird beim Speichern des Dokumentes aufgerufen und aktualisiert alle Wf-Felder mit den Werte des Ad hoc Workflow Objektes.
Sub Msg Zeigt eine bestimmte Mitteilung an, die sich aus einer ID ergibt.
Sub GetAllNextTasksIDs Diese Prozedur durchsucht ab einen gegebenen Task rekursiv das Prozessmodell und setzt die Variable "AllPosibleTasksIDList" mit den gefundenen TasksIDs (wird für die Ermittlung von Join-Knoten verwendet).
Sub RouteSimple Einfaches, lineares Weiterleiten
Sub RouteSplitWfDoc Weiterleiten mit Aufteilung des Vorganges auf mehrere parallele Aufgaben.
Sub RouteMergeWfDoc Zusammenführen von Ergebnissen des Split-Dokumente
Sub WfTerminate Workflow-Instanz abschließen
Function CreateWfID Erzeugt eine eindeutige ID, bestehend aus dem Usernamen und dem aktuellen Zeitpunkt
Function IsMergeTask Stellt fest, ob der nächste Knoten eine möglicher Join-Knoten ist
Function GetAllSplitDocs Erzeugt ein Dokumenten-Array mit allen Dokumenten der gleichen Split-Hierarchieebene
ContentManagement
Prozedur bzw. Funktion Beschreibung
Sub MergeContent Führt den Content der Split-Dokumente wieder zusammen
Anhang Seite 73
ExceptionManagement
Prozedur bzw. Funktion Beschreibung
Sub WfTaskTerminate Die aktuelle Aufgabe wird zur Endaufgabe (EndTask) deklariert. Bei einfachem Weiterleiten (es existiert nur ein Dokument im Workflow) führt dies auch zur Beendigung des Workflows. Bei Splits (mehrere Dokumente im Workflow) wird nur die ausgewählte Aufgabe beendet und die Dokumenten-ID aus dem Stack der SplitIDs gelöst. Es wird also nur der aktuelle Vorgangspfad beendet. Alle anderen Arbeitspfade sind weiterhin aktiv und werden auch von der Engine abgearbeitet.
Sub WfTerminate Hierbei wird der Workflow sofort beendet. Sind Split-Dokumente vorhanden, werden deren Ergebnisse in das Master-Dokument übernommen und der Workflow beendet (WfStatus: Abgeschlossen)
Sub MailToWfInitiator Sendet eine E-Mail an den Initiator des Workflows mit der Bitte um Hilfe bei der weiteren Vorgehensweise
GenericFunction
Prozedur bzw. Funktion Beschreibung
Function StringToArray Wandelt einen String in einen Array