Konzeption und Entwicklung einer prototypischen Workflow ...gcc.uni-paderborn.de/www/WI/WI2/wi2_lit.nsf... · Diplomarbeit Konzeption und Entwicklung einer prototypischen Workflow-Engine

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-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]


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]


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


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]


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]


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

E-Mail

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]


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]


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


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]


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.


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.


"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]


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


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.


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]


@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.


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


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]


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.


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]


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


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 vordefinierte 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]


(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)


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


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.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]


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.


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


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


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.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


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]


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


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.


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]


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.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,


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]


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


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


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


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.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


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


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.


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


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.


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


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




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


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


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.


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




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



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"


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


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


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.


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


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


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


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.


[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.


[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.


[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


WfProtocol (Text)

Verlauf der Workflow-Instanz z.B. 200104201530#CN=Claudius Niebiossa/O=NIC#1#2:3:4#Split

Anhang Seite 71

Workflow-Abschnitt


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


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


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


Sub MergeContent Führt den Content der Split-Dokumente wieder zusammen

Anhang Seite 73

ExceptionManagement


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


Function StringToArray Wandelt einen String in einen Array