Konzeption und prototypische Implementierung von Web …gcc.upb.de/www/WI/WI2/wi2_lit.nsf/0... · 2006. 9. 20. · Universität Paderborn Diplomarbeit Konzeption und prototypische

Universität Paderborn

Diplomarbeit

Konzeption und prototypische Implementierung von Web-Komponenten eines Groupware-basierten Ad-Hoc-

Workflow-Management-Systems

Prof. Dr. L. Nastansky

Sommersemester 2002

Betreuer:

Dipl.-Inform. Carsten Huth

vorgelegt von:

Numan Tas

Wirtschaftsinformatik H II

Matr.-Nr.: 3576045

Warburger Str. 59

33098 Paderborn

Danksagung

Mein herzlichster Dank gilt meiner Frau sowie allen Freunden und Bekannten, die

mit Rat und Tat zum Gelingen dieser Diplomarbeit beigetragen haben.

Namentlich möchte ich mich bei Herrn Prof. Dr. L. Nastansky und Dipl.-Inform.

Carsten Huth für ihre Unterstützung und hervorragende Betreuung bei der

vorliegenden Arbeit bedanken.

- III -

Inhaltsverzeichnis

1 Einleitung.................................................................................................................. 1

1.1 Szenario ................................................................................................................ 1

1.2 Zielsetzung der Arbeit .......................................................................................... 4

1.3 Vorgehensweise .................................................................................................... 6

2 Grundlagen und technologisches Umfeld der Arbeit ........................................... 7

2.1 Thematische Abgrenzung innerhalb der CSCW-Forschung ................................ 7

2.1.1 Groupware ................................................................................................... 8

2.1.2 Workflow Management ............................................................................. 10

2.2 Arbeitsumgebung der vorliegenden Aufgabenstellung ...................................... 14

2.2.1 Die Groupware-Umgebung Lotus Notes/ Domino.................................... 14

2.2.2 Das Office-Management-System PAVONE Enterprise Office................. 16

2.3 Technologien für die Entwicklung der Web-Lösung ......................................... 19

2.3.1 Die Programmiersprache Java ................................................................... 19

2.3.2 Die Auszeichnungs- und Metasprache XML ............................................ 20

3 Merkmale und Anforderungen eines Ad-hoc-Workflow-Management-Systems:

Das GroupProcess-Konzept .................................................................................... 22

3.1 Das GroupProcess-Kontinuum ........................................................................... 23

3.2 Spezielle konzeptionelle Ansätze für Ad-hoc-Workflow-Management............. 28

3.2.1 Fusion von Build Time und Run Time...................................................... 28

3.2.2 Partizipatives, verteiltes Design von Ad-hoc-Workflows ......................... 29

3.2.3 Übergang von konkreter zu abstrakter Prozessmodellierung.................... 29

3.3 Die GroupProcess-Architektur ........................................................................... 30

3.4 Technologieoptionen für die Umsetzung der Web-Lösung................................ 34

3.5 Einsatzszenarien für das GroupProcess-Konzept ............................................... 35

- IV -

4 Prototypische Realisierung eines Web-basierten Ad-hoc-Workflow-

Management-Systems............................................................................................ 39

4.1 Architektur des Web-basierten Systems............................................................. 40

4.2 Gestaltung und Funktionalität der Ad-hoc-Workflow-Applikation ................... 41

4.2.1 Usability der Benutzungsschnittstelle ....................................................... 42

4.2.2 Dokumentenmanagement innerhalb der Benutzungsschnittstelle............. 48

4.2.3 Phase 1: Initialisierung des Ad-hoc-Workflow-Modelers......................... 55

4.2.4 Phase 2: Modellierung und Ausführung von Ad-hoc-Workflows ............ 56

4.2.5 Phase 3: Rückspeicherung einer modifizierten Workflow-Struktur ......... 60

4.3 Spezielle technische Aspekte des Prototyps ....................................................... 61

4.3.1 Klassenhierarchie der Web-Variante des Ad-hoc-Workflow-Modelers ... 61

4.3.2 Sicherheitsaspekte der GroupProcess Web-Applikation........................... 63

4.3.3 Performance Betrachtung .......................................................................... 64

5 Aktueller Implementierungsstand und Ausblick................................................ 68

6 Zusammenfassung ................................................................................................. 70

7 Literaturverzeichnis .............................................................................................. 72

Anhang........................................................................................................................... 78

- V -

Abkürzungsverzeichnis

BPR Business Process Reengineering

CORBA Common Object Request Broker Architecture

CSCW Computer Supported Cooperative Work

DOM Document Object Model

DSL Digital Subscriber Line

DTD Document Type Definition

Email Electronic Mail

GUI Graphical User Interface

HTML Hypertext Markup Language

JVM Java Virtual Machine

OLE Object Linking and Embedding

LAN Local Area Network

PDF Portable Document Format

RMI Remote Method Invocation

SAX Simple API for XML

SGML Standard Generalized Markup Language

URL Uniform Resource Locator

W3C World Wide Web Consortium

WAGS Wide Area GroupFlow System

WfM Workflow Management

WfMC Workflow Management Coalition

WfMS Workflow-Management-System

WWW World Wide Web

XML Extensible Markup Language

XSL Exentible Stylesheet Language

- VI -

Verzeichnis der Abbildungen und Tabellen

Abbildungen:

Abbildung 1-1: Einordnung von GroupProcess in die Projektabfolge am GCC................... 4

Abbildung 2-1: Die Bereiche der CSCW-Forschung ............................................................ 8

Abbildung 2-2: Struktur von Workflow-Management-Systemen ....................................... 13

Abbildung 2-3: Beipielszenario für die Groupware-Architektur Lotus Notes/ Domino..... 14

Abbildung 2-4: Architektur der PAVONE Enterprise Office-Umgebung .......................... 17

Abbildung 2-5: Beispiel eines Ad-hoc-Workflows im Enterprise Office-System .............. 18

Abbildung 2-6: Transformationsebenen von Java-Code ..................................................... 19

Abbildung 2-7 Struktur eines XML-Dokuments ................................................................. 21

Abbildung 3-1: Struktur des GroupProcess-Ansatzes ......................................................... 30

Abbildung 3-2: Speicherung aller Workflow-Daten innerhalb eines Dokuments............... 31

Abbildung 3-3: Prototyp des GroupProcess-Systems für den Groupware-Client ............... 32

Abbildung 3-4: Gesamtarchitektur des GroupProcess-Systems.......................................... 33

Abbildung 3-5: Entwicklung von Internet-Hosts: 1995-2001 ............................................. 35

Abbildung 3-6: Verarbeitung eines Ad-hoc-Workflows in der Messaging-Lösung ........... 37

Abbildung 4-1: Architektur des Web-basierten GroupProcess-Systems............................. 40

Abbildung 4-2: GroupProcess im Web: Die Workflow-Management-Umgebung ............. 44

Abbildung 4-3: Anlegen eines Benutzerkontos ................................................................... 45

Abbildung 4-4: Ändern der Benutzerdaten.......................................................................... 45

Abbildung 4-5: Aufbau der Ad-hoc-Workflow-Modeler-Maske ........................................ 46

Abbildung 4-6: Beispiele für Systeminteraktionen ............................................................. 47

Abbildung 4-7: Die Ansichten der Workflow-Management-Umgebung ............................ 48

Abbildung 4-8: Die Ansicht designed ................................................................................. 49

Abbildung 4-9: Die Ansicht involved .................................................................................. 50

Abbildung 4-10: Die Ansicht team ...................................................................................... 51

- VII -

Abbildung 4-11: Die Ansicht archive.................................................................................. 52

Abbildung 4-12: Die Ansicht administration ...................................................................... 53

Abbildung 4-13: Suchfunktionalität der Ansichten............................................................. 54

Abbildung 4-14: Initialisierungsvorgang des Ad-hoc-Workflow-Modelers ....................... 55

Abbildung 4-15: Beispiel für eine Ansicht mit den Organisationsdaten von Personen ...... 55

Abbildung 4-16: Beispiel für die XML-Repräsentation einer Ansicht mit Personendaten. 56

Abbildung 4-17: Erster Abschnitt der Ad-hoc-Modellierung ............................................. 57

Abbildung 4-18: Zweiter Abschnitt der Ad-hoc-Modellierung........................................... 58

Abbildung 4-19: Abschluss der Ad-hoc-Modellierung ....................................................... 59

Abbildung 4-20: Speicherungsvorgang der Workflow-Struktur ......................................... 61

Abbildung 4-21: Struktur der Web-Klassenhierarchie ........................................................ 62

Abbildung 4-22: Login als Authentifizierungstechnik ...................................................... 64

Tabellen:

Tabelle 2-1: Groupware-Systeme in verschiedenen Interaktionsszenarien........................... 9

Tabelle 3-1: Workflow-Kontinuum des GroupProcess-Konzepts....................................... 24

Tabelle 3-2: Verteilung der Top Level Domainnamen nach Anzahl der Hosts .................. 36

Tabelle 4-1: Kriterien zur Reduzierung erzwungener Sequenzialität ................................. 43

Tabelle 4-2: Verarbeitungszeiten in Abhängigkeit von den Zugangstechniken.................. 66

Tabelle A-1: Konfiguration des Ad-hoc-Workflow-Management-Systems ....................... 81

Tabelle A-2: Angepasste Klassenhierarchie des Web-basierten Prototyps......................... 82

Tabelle A-3: Design-Elemente der Web-Datenbank ........................................................... 84

Tabelle A-4: Design-Elemente der diversen Datenbanken ................................................. 84

1 Einleitung - 1 -

1 Einleitung

1.1 Szenario

“Die Transformation ist nicht mehr aufzuhalten, wir befinden uns mitten in einer

schnell getakteten Evolution” [Neue Züricher Zeitung, September 1999]

Seit Ende der 80er Jahre ist eine beständige Zunahme der Wettbewerbsintensität der

Unternehmen und ein Trend zur Globalisierung der wirtschaftlichen Aktivitäten zu

verzeichnen. Diese Entwicklung führt zu einer steigenden Komplexität und einem

stetigen Veränderungsprozess im unternehmerischen Umfeld. Als Folge der erhöhten

Wettbewerbsintensität sind die Unternehmen genötigt, in immer kürzerer Zeit immer

hochwertigere Produkte zu entwickeln und diese möglichst kostengünstig zu

produzieren. Diese Dynamik äußert sich u.a. in einer Verkürzung der Produktlebens-

zyklen und damit einhergehenden kürzeren Innovationszeiten, sowie der Forderung

nach verkürzten Lieferzeiten (Just in Time Lieferung und Produktion). Um den

veränderten Anforderungen des Marktes gerecht werden zu können, müssen neue

Organisationsformen angestrebt werden. Die Konzepte des Lean Managements1 und

des Business Reengineerings verkörpern diese neuen unternehmerischen Philosophien.

Beide verlangen ein radikales Umdenken und eine Änderung der Unternehmenskultur.

Durch die Abkehr vom tayloristischen Arbeitskonzept hin zur Prozessorientierung wird

mit Hilfe von Geschäftsprozessanalysen und -modellierung versucht die Leistungser-

stellung zu optimieren. Diese als Business Process Reengineering (BPR) bezeichnete

Vorgehensweise hat das Ziel, leistungsfähige Organisationsstrukturen zu schaffen, die

sich den wandelnden Anforderungen anpassen. Die Modellierung aller betriebswirt-

schaftlichen Abläufe eines Unternehmens als Geschäftsprozesse schafft die

Voraussetzung für den Einsatz von Workflow-Management-Systemen (WfMS). Bereits

seit Mitte der 90er Jahre werden von den diversen Anbietern Software-Werkzeuge für

stark strukturierte Prozesse angeboten. Bisher basieren die Workflow-Paradigmen auf

der Existenz eines “optimalen Prozesses” oder zumindest ist der Ausgangspunkt ein Set

von gut analysierbaren Prozessen innerhalb einer einheitlichen und gut strukturierten

1 Mit Lean Management wird eine Form der Unternehmensführung bezeichnet, die durch den Abbau von hierarchischen Zwischenstufen, sowie durch größere Verantwortung für den einzelnen Mitarbeiter, Entscheidungsprozesse verkürzen und die Produktivität steigern will.

1 Einleitung - 2 -

Organisation. In der Büroumgebung von Unternehmen existiert noch eine weitere

Klasse von Prozessen, die bisher kaum unterstützt wird. Es handelt sich um flexible,

kurzlebige und schwach strukturierte Ad-hoc-Workflows2. Sie zeichnen sich u.a. durch

eine tendenziell geringere Komplexität, eine sehr hohe Kommunikationsintensität,

wechselnde Kooperationspartner und einem offenen Lösungsweg aus. Diese Art von

Workflow lässt sich nicht standardisieren, sondern muss ad hoc modelliert werden.

Aufgrund der Dynamik von Ad-hoc-Prozessen gelten diese bisher als nicht

beherrschbar oder es wird nicht als rentabel angesehen, für diesen Typ von

Geschäftsprozessen eine gezielte Unterstützung bereitzustellen3. Ausgehend von der

oben beschriebenen Unternehmenssituation ist jedoch eine zunehmende Bedeutung

dieses Workflow-Typs zu erwarten. Die Informationsflut sowie dynamische, wenig

strukturierte Aufgaben erfordern weltweite Kooperationen und eine Reaktion in Form

von Business Prozess Reengeering und virtuellen Unternehmen. In diesem

hochdynamischen Umfeld nehmen Ad-hoc-Prozesse immer mehr zu.

Neben Workflow-Management-Systemen zur Unterstützung von Ad-hoc-Prozessen

stellt das Internet eine weitere Schlüsseltechnologie für die Erweiterung der

Prozessunterstützung in aktuellen Organisationsansätzen dar4. Informationen werden

immer stärker zum kritischen Erfolgsfaktor von Unternehmen. In modernen

Unternehmen müssen sowohl Einzelpersonen als auch Gruppen schnell auf

Informationen zugreifen, sowie problemlos miteinander kommunizieren und

zusammenarbeiten können. Eine Folge dieser Anforderungen ist, dass Unternehmen

verstärkt das Internet und eigene Intranet nutzen. Heute sind nahezu alle Unternehmen

und jede Organisation im Internet vertreten. Die Unternehmen können sich einen

deutlichen Wettbewerbsvorteil verschaffen, indem sie das Internet als wichtige

Plattform zur externen Kommunikation nutzen, um auf Produkte, Neuheiten und

Serviceangebote hinzuweisen und so neue Kunden und Märkte gewinnen. Das Internet

beeinflusst nachhaltig die Art und Weise, in der Unternehmen mit ihren Kunden und

Partnern kommunizieren. Eine starke Web-Präsenz5 versetzt Firmen in die Lage, ihre

Kunden auf neuen und innovativen Wege zu erreichen und ihre Botschaft

2 [Nastansky/Riempp/Hilpert/Ehlers 1996] S.31 3 [Huth/Nastansky 2000a] 4 Vgl. [Lawrence 1997] S.157 5 In dieser Arbeit wird für den Internet-Dienst World Wide Web (WWW) die Abkürzung Web benutzt.

1 Einleitung - 3 -

kosteneffizient zu vermitteln. Der Einsatz von Internet-Technologien für das Intranet

kann durch Verbesserung der internen Kommunikation ähnlich große Wettbewerbsvor-

teile bringen. Wie kein anderes Medium hat deshalb das Internet in kürzester Zeit

seinen Siegeszug um die Welt angetreten und ist aus vielen Geschäftsbereichen nicht

mehr wegzudenken. Das Internet ist zu einem Massenmedium geworden. Neue

Technologien müssen im Internet bereitgestellt werden, um eine breite Akzeptanz zu

erlangen.

Die Integration von Workflow- und Internet-Technologien ist für ein zukunftorientiertes

Unternehmen notwendig 6 . Dieser Sachverhalt wird vom Industriekonsortium

Workflow Management Coalition (WfMC) 7 betont. Das WfMC sieht beide

Technologien als sich gegenseitig ergänzend an8. Es wird herausgestellt, dass Web-

Anwendungen in der Regel für kurzlebige Interaktionen zwischen dem Benutzer und

dem Anwendungssystem gut geeignet sind. Workflow-Systeme beherrschen dagegen

langlebige, prozessorientierte Anwendungen. Durch die Integration werden Web-

Anwendungen um Workflow-Funktionalitäten, wie z.B. die Repräsentation und

Interpretation von Prozessen, das Führen von Statistiken, Überwachungsfunktionen

oder das Alarmieren bei fehlerhaften Abläufen9, ergänzt. Hieraus resultieren Vorteile

für die Web-Anwendungen bzgl. Produktivität sowie Qualitäts- und Kostenkontrolle.

Für die Workflow-Technologie bringt das Internet wiederum die Vorteile einer

weltweiten Infrastruktur, Zero-Application-Deployment-Costs und die Möglichkeit der

Realisierung von virtuellen Unternehmen. Das Internet ist ein Medium mit einem hohen

Verbreitungsgrad und großen Zuwachsraten weltweit10. Durch diese Präsenz ist das

Internet für alle Kooperationspartner hervorragend geeignet, die Informationsverteilung

und Kommunikation innerhalb von Organisationen und über ihre Grenzen hinweg zu

unterstützen.

Zusammenfassend lässt sich sagen, dass insbesondere durch die Symbiose von Internet-

und Workflow-Technologie die notwendige Infrastruktur für das Business Process

Reengineering zur Verfügung gestellt wird, welches ein hohes Maß an Kommunikation

6 [WfMC 1998a] S.9-11 7 Das Industriekonsortium WfMC wurde 1993 gegründet und besteht heute aus mehr als 170 Mitgliedern

aus 24 Ländern. Der Fokus der Organisation ist darauf ausgerichtet die Entwicklung von Workflow-Management-Technologien und deren Einsatz in der Industrie zu fördern. Vgl. [Lawrence 1997] S. IX

8 [WfMC98b] 9 Vgl. [Tolksdorf 2000], [WfMC 1998a] 10 Siehe [Ott 1996]

1 Einleitung - 4 -

und Information erfordert. Eine ausführliche Darstellung der Vorteile durch den

gemeinsamen Einsatz von Workflow- und Internettechnologie ist in dem WfMC Papier

zu finden. Hier heißt es u.a.11:

“Together, Workflow and the Internet are set to provide us with some astonishing results [...]. By closely combining the unprecedented information communication capabilities of the Internet with the strategic business processes automation and integration capabilities of Workflow engines, significant changes will be realized. These will enable a real acceleration of productivity improvement within informa-tion related activities, and will pave the way for some totally new forms of work. These will include home work, mobile work and virtual enterprises.”

1.2 Zielsetzung der Arbeit

Am Groupware Competence Center (GCC) 12 unter der Leitung von Prof. Dr. L.

Nastansky wird die tägliche Arbeit in Workflow- und Office-Management-

Umgebungen, insbesondere in dem System PAVONE Enterprise Office ausgeführt.

Durch die praktische Erfahrung konnte die Feststellung gemacht werden, dass es sich

bei den anfallenden Prozessen hauptsächlich um einmalige, kurzlebige Ad-hoc-Prozesse

handelt. Aus dieser Erkenntnis heraus entstand das Forschungsprojekt GroupProcess.

Projektabfolge am GCC

1990

1992

1994

1996

1998

2000

kommerzielle Produkte

universitäre Forschung

PAVONE Enterprice

Office GroupProcess

ONEStone Prozessware PAVONE

Espresso

WAGS GroupOrga

GroupFlow

GroupProject

GroupOffice

Lotus Domino

Workflow

Abbildung 1-1: Einordnung von GroupProcess in die Projektabfolge am GCC13

11 [WfMC 1998a] S.4 12 Das GCC gehört zur Lehr- und Forschungseinheit Wirtschaftsinformatik 2 der Universität Paderborn. 13 [Huth/Nastansky 2000a]

1 Einleitung - 5 -

GroupProcess ist auf den speziellen Charakter von Ad-hoc-Prozessen ausgerichtet und

beinhaltet Ansätze zur deren Modellierung und Durchführung in einer teambasierten

Office-Umgebung14. Wie aus Abbildung 1-1 zu entnehmen ist, hat GroupProcess seinen

Ursprung in den universitären Forschungsprojekten GroupOrga 15 und GroupFlow 16

(bzw. WAGS17). Ebenso ist an der Entwicklung das kommerzielle Workflow- und

Office-Management-System PAVONE Espresso18 des Kooperationspartners PAVONE

AG beteiligt, welches in der aktuellen Version PAVONE Enterprise Office zusammen

mit der Groupware-Plattform Lotus Notes/ Domino der Firma IBM als Basis für die

prototypische Implementierung verwendet wird.

Das Ziel dieser Arbeit besteht darin, den existierenden Prototyp des GroupProcess Ad-

hoc-Workflow-Modelers auch für den Web Browser als Prototyp zur Verfügung zu

stellen. Der Ad-hoc-Workflow-Modeler dient zur Modellierung von Ad-hoc-Prozessen

und wurde bisher nur für den Groupware-Client Lotus Notes realisiert. Basierend auf

das beschriebene Szenario in Kapitel 1.1 sollen durch eine Anbindung an das Internet

Synergieeffekte genutzt und somit das Nutzenpotential für das GroupProcess-System

erhöht werden. Um dieses Ziel zu erreichen sind zwei Schritte erforderlich. Im ersten

Schritt wird die Unabhängigkeit des Prototyps vom Groupware-Client hergestellt. Der

Ad-hoc-Workflow-Modeler ist als Java-Applet 19 (im Folgenden als Web-

WorkflowModeler-Applet bezeichnet) realisiert, das die Domino Java-Klassen der

Groupware-Plattform nutzt. Um eine Web-basierte Lösung zu erhalten, müssen

insbesondere die für den Datenaustausch zwischen dem Ad-hoc-Workflow-Modeler

und der Groupware-Plattform zuständigen Komponenten der Java-Klassenhierarchie

modifiziert bzw. durch andere Klassen ersetzt werden. Im zweiten Schritt erfolgt die

Gestaltung einer grafischen Benutzungsschnittstelle für das Web. Zur Verwaltung von

Workflows bzw. von Workflow-Dokumenten in einer Web-Umgebung ist die

Entwicklung einer angepassten Ausführungs- und Kommunikationsstruktur in Form

einer Benutzungsschnittstelle erforderlich.

14 Siehe [Huth 2000], [Huth/Nastansky 2000a] 15 [Ott 1998] 16 [Riempp 1998] 17 Wide Area Groupflow System 18 Siehe Abschnitt 2.2.2 19 Applets sind Java-Programme, die einen Web-Browser als Ausführungsumgebung benötigen. Der so

genannte Applet Tag (<applet>) ist in einer HTML-Seite eingebunden und bezeichnet das auszuführende Programm (Applet).

1 Einleitung - 6 -

1.3 Vorgehensweise

Im Anschluss an dieses Kapitel folgt eine Einführung in die Grundlagen und eine

Abgrenzung des technologischen Umfelds dieser Arbeit. Aus dem Forschungsbereich

Computer Supported Cooperative Work (CSCW) werden die Begriffe Groupware,

Workflow Management und Workflow-Management-System abgegrenzt. Weiterhin

wird die Groupware-Plattform Lotus Notes/ Domino und das Office- und Workflow-

Management-System PAVONE Enterprise Office als Arbeitsumgebung vorgestellt.

Abschließend findet eine Erläuterung der für diese Aufgabenstellung eingesetzten

Internet-Technologien statt.

Im dritten Kapitel folgt zunächst eine Darstellung des aktuellen Systemstatus in den

Unternehmen und die daraus resultierenden Ziele des GroupProcess-Projekts.

Anschließend werden die Merkmale und Anforderungen eines Ad-hoc-Workflow-

Management-Systems anhand des GroupProcess-Konzepts herausgearbeitet. Dazu

werden aufbauend auf dem GroupProcess-Kontinuum die damit verbundenen

Paradigmenwechsel vorgestellt. Im dritten Unterkapitel findet die Präsentation der

bestehenden GroupProcess-Architektur statt. Abschließend werden verschiedene

Technologieoptionen für die Umsetzung der Web-Lösung diskutiert und Einsatzszena-

rien für das GroupProcess-System vorgestellt.

Aufbauend auf die vorangegangenen Kapitel wird im vierten Kapitel die Umsetzung der

prototypischen Lösung beschrieben. Die Ausführung ist in die drei Abschnitte

Architektur, Gestaltung und Funktionalität sowie spezielle technische Aspekte des

Prototyps untergliedert.

In den letzten beiden Kapiteln findet eine Schilderung des aktuellen Implementierungs-

standes und ein Ausblick sowie eine Zusammenfassung der Arbeit statt.

2 Grundlagen und technologisches Umfeld der Arbeit - 7 -

2 Grundlagen und technologisches Umfeld der Arbeit

Es findet in diesem Kapitel zunächst eine thematische Abgrenzung von relevanten

Termini basierend auf Konzepten der Computer Supported Cooperative Work (CSCW)

und der Workflow Management Coalition statt. Anschließend werden Architektur-

merkmale der zu Grunde liegenden Entwicklungsplattform Lotus Notes/ Domino und

des Office-Management-Systems PAVONE Enterprise Office, welches ebenfalls eine

Basistechnologie dieser Arbeit ist, vorgestellt. Das Grundlagenkapitel endet mit der

Darstellung von verschiedenen Technologien, die für die Web-Entwicklung des

Prototyps eingesetzt wurden. Es wird nicht eine umfassende Darstellung beabsichtigt,

sondern ausschließlich eine Einführung in die für diese Arbeit relevanten Bereiche, um

eine gemeinsame Ausgangsbasis zu gewährleisten.

2.1 Thematische Abgrenzung innerhalb der CSCW-Forschung

Das Akronym CSCW (Computer Supported Cooperative Work) wurde bereits 1984

eingeführt und geht auf einen Workshop am Massachusetts Institute of Technology

(MIT) zurück. CSCW bezeichnet einen interdisziplinären Forschungsbereich, in

welchem neben (Wirtschafts-) Informatik und Wirtschaftswissenschaften auch viele

andere Disziplinen wie Arbeits- und Organisationswissenschaften sowie Soziologie,

Anthropologie und Ethnographie vertreten sind20. Computer Supported Cooperative

Work dient als Oberbegriff für die verschiedenen Theorien und Methoden. Diese

wissenschaftliche Disziplin befasst sich einerseits mit Gruppenarbeit in Organisationen

und andererseits mit den Möglichkeiten der Computerunterstützung kooperativen

Arbeitens mit dem Ziel, durch den Einsatz von Informations- und Kommunikations-

techniken die Zusammenarbeit von Menschen zu verbessern 21 . Dabei sollen

Arbeitsprozesse nicht nur effizienter und flexibler, sondern auch humaner und sozialer

gestaltet werden22.

20 Vgl. [Koch/Zielke 1996] S.32,33 21 Vgl. [Geif 1988], [Greenberg 1991] S.2 und [Bornschein-Grass 1995] S.7 22 Vgl. [Nastansky/Fischer/ Herold/Dangelmaier/Suhl 2000] S.237 ff. und [Back/Seufert 2000] S.6 f.


Verständnisder

Teamarbeit

Entwicklung vonWerkzeugen undKonzepten für dieUnterstützung der

Teamarbeit

Bewertung vonWerkzeugen undKonzepten für dieUnterstützung der

Teamarbeit

CSCW

Abbildung 2-1: Die Bereiche der CSCW-Forschung23

Aus den Forschungsschwerpunkten der CSCW (siehe Abbildung 2-1) wird der

organisatorische Trend hin zu flexiblen und dynamischen Teams deutlich. Es werden

Merkmale und typische Eigenschaften kooperativen Arbeitens analysiert mit dem Ziel,

hierfür informationstechnologische Konzepte und Lösungen zu entwerfen24. Letztlich

sind die Bestrebungen der CSCW-Forschung dahingehend, computergestützte

Werkzeuge für die Unterstützung der Teamarbeit zu erstellen und progressiv zu

erweitern.

2.1.1 Groupware

In einer tayloristischen Organisation war es weitgehend ausreichend, wenn ein

Computersystem die Erledigung der individuellen Aufgaben erleichterte (Textverarbei-

tung, Tabellenkalkulation usw.). Mit der zunehmenden Orientierung hin zur Teamarbeit

müssen verstärkt die kooperativen Prozesse unterstützt werden 25 . „Groupware-

Umgebungen mit ihren besonderen Stärken in der Unterstützung von Kommunikations-

und Koordinationsaufgaben stellen ein leistungsfähiges Basis-Werkzeug zur Gestaltung

von Geschäftsprozessen dar 26 .“ Der Begriff Groupware stammt aus der CSCW-

Forschung und wie für viele Begriffe in der Wirtschaftsinformatik typisch, existiert

23 [Back/Seufert 2000] S.5-7 24 Vgl. [Bannon/Schmidt 1989] S. 358-372 25 Vgl. [Koch 1996] S.34,35 26 [Nastansky/Riempp/Hilpert/Ehlers 1996] S.2


auch hier keine eindeutige Definition. Stattdessen findet sich in der Literatur eine große

Anzahl unterschiedlicher Systematisierungsansätze27. Allgemein lässt sich Groupware

als die praktische Umsetzung der in der CSCW-Forschung gewonnenen Erkenntnisse in

ein Informations- und Kommunikationssystem, das die Teamarbeit unterstützt,

bezeichnen. Dieser Arbeit wird der Definitionsansatz von Nastansky zu Grunde

gelegt28:

"Groupware stellt computerunterstützte Konzepte für die Teamarbeit bereit. Insbesondere müssen dabei natürlich der Arbeitsfluss und das Vorgangsmanage-ment in den vielfältigen Kommunikations- und Arbeitsinteraktionen zwischen Mitarbeiterinnen und Mitarbeitern im Office-Bereich bzw. in Projektteams unterstützt werden."

Somit werden unter Groupware Applikationen verstanden, welche das computerunter-

stützte kooperative Arbeiten ermöglichen. Zur Klassifikation von Groupware-

Applikationen werden im Folgenden zwei populäre Ansätze aus der Literatur

aufgeführt. Das wohl bekannteste Schema teilt die Applikationen (siehe Tabelle 2-1) in

eine Raum-Zeit-Matrix ein. Die Unterscheidung erfolgt dabei nach der geographischen

und der zeitlichen Verteilung der beteiligten Personen29.

Zusammenarbeit der

Teammitglieder

gleichzeitig (synchron)

zu verschiedenen Zeiten

(asynchron)

am gleichen Ort (zentral)

• Systeme zur computerunterstützten Sitzungsmoderation

• Präsentationssysteme • Group Decision Support Systems

• Systeme zum Tgement für Gruppen

erminkalendermana-

• Projektmanagement-Systeme

an verschiedenen Orten (dezentral)

• Audio- und Videokonferenz-systeme

• Screen-Sharing-Systeme • Mehrautorensysteme

• Email-Systeme • Voice-Mail-Systeme • Systeme für Electronic Conferencing • Elektronische Bulletin Boards • Shared Information Systems • Workflow-Systeme

Tabelle 2-1: Groupware-Systeme in verschiedenen Interaktionsszenarien30

Groupware-Systeme lassen sich auch nach ihren Schwerpunkten bzgl. der

Unterstützung von Gruppenprozessen unterscheiden. Hierbei wird eine Einteilung nach

den Funktionen Kommunikation, Koordination und Kooperation vorgenommen. Diese

27 Vgl. [Greenberg 1991] S.1 28 [Nastansky 1993] S.239-249 29 Vgl. [Lehmann 1999] S.73-74 30 Siehe [Teufel/Sauter/Mühlherr/Bauknecht 1995] S. 24

http://www-stud.uni-essen.de/~sw0136/


Unterstützungsfunktionen werden in der einschlägigen Literatur hinreichend behandelt,

so dass hier die Ausführung auf die Nennung der drei Kategorien beschränkt wird31:

• Kommunikation stellt das zentrale Element von kooperativer Arbeit dar und bezeichnet den Austausch von Informationen zwischen mehreren Personen.

• Kooperation bezieht sich auf die Art von Kommunikation, die zur Abstimmung aufgabenbezogener Tätigkeiten erforderlich ist.

• Koordination umfasst alle Kommunikationsvorgänge, die zur Kooperation und zur Abstimmung dezentraler zielgerichteter Handlungen notwendig sind.

Je nach Ausprägung der Unterstützungsfunktionen lassen sich ähnliche Groupware-

Anwendungen zu Systemklassen32 zusammenfassen.

2.1.2 Workflow Management

Um den Gedanken des Lean Managements und des Business Process Reengineerings

gezielt durch Informationstechnologie zu unterstützen, werden u.a. Workflow-

Management-Systeme (WfMS) eingesetzt. Bevor geklärt wird, was unter solch einem

System zu verstehen ist, sollen zunächst die Begriffe Workflow und Workflow

Managemement inhaltlich abgegrenzt werden. Die Workflow Management Coalition

definiert den Begriff Workflow wie folgt33:

"The computerised facilitation or automation of a business process, in whole or part."

Diese Definition ist sehr allgemein gehalten und lässt viele Technologieansätze und

Ausführungsumgebungen zu. Nastansky34 versteht unter dem Begriff Workflow die

zeitlich-strukturelle Aneinanderreihung von einzelnen zur Bearbeitung eines

Gesamtvorgangs notwendigen Teilaufgaben. Dabei sind in der Regel Workflows

organisationsweite, arbeitsteilige Prozesse, in die eine Vielzahl von Beteiligten

einbezogen sind. Bei diesem Ansatz wird die Prozessorientierung in den Vordergrund

gestellt.

Um den Begriff Workflow Management zu fassen, wird von der allgemeinen

Auffassung des Begriffs Management ausgegangen, welche alle Handlungen wie

Organisieren, Planen, Entscheiden, Kontrollieren, Steuern und Führen beinhaltet.

31 Zur Vertiefung siehe [Huth/Nastansky 2000a] S.3 oder [Stahlknecht/Hasenkamp 1997] S.55 32 [Teufel 1996] S. 41 33 [Hollingworth 1994] S.6 34 Siehe [Nastansky/ Fischer/Herold/Dangelmaier/Suhl 2000] S.243


Dementsprechend kann die Ausübung dieser Handlungen im Zusammenhang mit

Arbeitsvorgängen beim Einsatz eines Workflow-Management-Systems als Workflow

Management bezeichnet werden. Allgemein umfasst Workflow Management die

Modellierung, die Simulation sowie die Ausführung und Steuerung (in zeitlicher und

örtlicher Hinsicht) von Geschäftsprozessen unter Bereitstellung der jeweils benötigten

Informationen und Werkzeuge 35 . Nach Hasenkamp wird der Begriff Workflow-

Management-System folgendermaßen definiert36:

"Workflow-Management-Systeme sind rechnergestützte Systeme, die arbeitsteili-ge Prozesse aktiv steuern. Sie koordinieren die Arbeitsschritte der Beteiligten, ermitteln den jeweils nächsten Bearbeiter, stellen die notwendigen Informationen bereit und überwachen die fristgerechte Erledigung."

Dieser Ansatz scheint nicht vollständig zu sein. Zusätzlich zu der genannten

Steuerungsfunktion werden von einem WfMS eine Reihe weiterer Aufgaben ausgeführt.

Insbesondere der Modellierungsaspekt wird hier nicht angesprochen. Der Ansatz der

Workflow Management Coalition ergibt eine umfassendere Betrachtung37:

"A system that completely defines, manages and executes workflows through the execution of software whose order of execution is driven by a computer representation of the workflow logic."

Hier wird deutlich, dass Workflow-Management-Systeme auch eine Modellierungs- und

Visualisierungsfunktion für die Workflows umfassen38. Nach Nastansky39 wird durch

Workflow-Management-Systeme der Arbeitsfluss abgebildet, den Informationsobjekte

(Dokumente) durchlaufen. Die Systeme übernehmen die Weiterleitung (Routing) der

Dokumente an die zuständigen Bearbeiter und informieren Beteiligte über den

Bearbeitungsstatus der Aufgaben bzw. Dokumente.

Workflow-Management-Systeme beabsichtigen eine möglichst umfassende

Unterstützung hinsichtlich Vorgangsgenerierung, -organisation und -steuerung sowie

Vorgangsverfolgung, -information und -terminierung. Workflow-Management-Systeme

lassen sich hinsichtlich ihrer Ausführungsumgebung differenzieren40:

35 Vgl. [Teufel 1996] S.42 und S.50 36 [Hasenkamp/Syring 1994] S. 107 37 [Hollingworth 1994] 38 Eine Auflistung der wichtigsten Komponenten eines Workflow-Management-Systems findet sich bei

[Huth 1998] S.9 39 [Nastansky/Fischer/Herold/Dangelmaier/Suhl 2000] S.243 40 Siehe [Huth 2002] S.19,20


• Messaging-based WfMS: Workflow-Funktionalitäten in Email-Systemen

• Document-oriented WfMS: Workflow-Funktionalitäten im Dokumenten-management

• Production WfMS: Unterstützung von komplexen Workflows, Kommunikation mit Corporate-Datenbanken und Mainframe Systemen etc.

Anhand ihrer Nutzungsmöglichkeiten und insbesondere ihrer Flexibilität in der

Vorgangssteuerung wird folgende Klassifizierung vorgenommen41:

• Transaktions-Workflow-Management-Systeme legen Prozessabläufe möglichst vollständig im voraus durch Regeln fest, so dass die Workflows während der Ausführung kaum mehr von den Bearbeitern beeinflusst werden können.

• Ad-hoc-Workflow-Management-Systeme eitern die Funktionalität transakti-onsorientierter Systeme um laufende Eingriffsmöglichkeiten, so dass Workflows während des Ablaufs durch die Bearbeiter verändert werden können.

erw

• Synergetische Workflow-Management-Systeme bieten auch differenzierte Zwischenformen dieser beiden Extremformen an.

Das in dieser Arbeit vorgestellte GroupProcess-Konzept hat seinen Fokus auf ein

Dokumenten-orientiertes Ad-hoc-WfMS. Des Weiteren wird als Konzeptgrundlage von

einem Workflow-Management-System ausgegangen, das sich an dem Referenzmodell

der WfMC orientiert. Das Referenzmodell beschreibt eine allgemeine Modellstruktur

für die Konstruktion von Workflow-Systemen und identifiziert die Beziehung von

verschiedenen alternativen Implementierungsansätzen zueinander. Auf einem hohen

Abstraktionsgrad ist für alle Workflow-Management-Systeme die Unterstützung der

folgenden drei funktionalen Bereiche charakteristisch42:

• “the Build-time functions, concerned with defining, and possibly modelling, the workflow process and its constituent activities”

• “the Run-time control functions concerned with managing the workflow processes in an operational environment and sequencing the various activi-ties to be handled as part of each process”

• “the Run-time interactions with human users and IT application tools for processing the various activity steps”

Abbildung 2-2 illustriert die grundsätzliche Struktur eines Workflow-Management-

Systems sowie die chronologische Abfolge und die Beziehung seiner Hauptfunktionen

zueinander.

41 Siehe [Nastansky/Fischer/ Herold/Dangelmaier/Suhl 2000] S.245 42 [Hollingworth 1994]


ProcessDefinition

Build Time Business Process Analysis,Modeling & Definition Tools

Run Time

Workflow EnactmentService

Process changesProcess Instantiation& Control

Applications& IT Tools

Run TimeInteraction withUsers & Application Tools

Process Design& Definition

Wor

Wor

App

Abbildung 2-2: Struktur von Workflow-Management-Systemen43

Die Process Definition ist eine Software zur Entwicklung von computergestützter

Prozessvisualisierung; sowohl automatisierter als auch manueller Prozesskomponenten.

Der Workflow Enactment Service stellt eine Run Time-Umgebung für die

Initialisierung, Ausführung und Kontrolle von Instanzen einer Prozessdefinition bereit.

Sie verteilt Aufgaben an die Workflow-Bearbeiter und startet erforderliche

Applikationen. Die Invoked Application-Software wird vom Workflow Enactment

Service entsprechend der Prozessdefinition gestartet, um eine Aktivität zu initialisieren

oder auszuführen. Die Software für die Echtzeitüberwachung, Kontrolle, Konfiguration

und Optimierung der Workflow-Ausführung stellt das Administration and Monitoring

Tool dar.

Im Folgenden werden einige zentrale Begriffe dieser Arbeit abgegrenzt. Es handelt sich

im Einzelnen um die Begriffe Workflow-Klasse/ -Modell, Workflow (-Instanz) sowie

den Begriff Prozess. Entsprechend dem objektorientierten Ansatz aus der Informatik

wird als Workflow-Klasse die Gesamtheit aller möglichen Ausprägungen dieser Klasse,

die eine Vielzahl ähnlicher Vorgänge ermöglicht, verstanden. Eine Workflow-Instanz

stellt hingegen durch Initialisierung eine einzige konkrete Ausprägung dar. In den

43 [WfMC 1999] S.39, [WfMC 1998a]


Ausführungen der WfMC findet sich für den Begriff Workflow-Klasse die Bezeichnung

Process Definition und für Workflow-Instanz die Bezeichnung Instance. Der Begriff

Workflow wird oft fälschlicherweise als Synonym für den Begriff Prozess verwendet.

Ein (Geschäfts-) Prozess liegt einem Workflow zu Grunde, das heißt der reale Prozess

in der Organisation ist die Grundlage für die Modellierung. Das Ergebnis der

Prozessmodellierung ist eine Workflow-Klasse.

2.2 Arbeitsumgebung der vorliegenden Aufgabenstellung

2.2.1 Die Groupware-Umgebung Lotus Notes/ Domino

Als Ausführungs- und Entwicklungsumgebung der prototypischen Implementierung

wird die Groupware-Plattform Lotus Notes/ Domino R5 eingesetzt. Die Groupware

basiert auf einer Server-Client-Architektur.

Abbildung 2-3: Beipielszenario für die Groupware-Architektur Lotus Notes/ Domino

Der Server mit der Bezeichnung Domino stellt eine integrierte Messaging- und Web-

Applikations-Plattform dar, die alle wichtigen Internetstandards wie HTML, SSL, Java,

HTTP etc. unterstützt. Als Clients stehen als Ausführungsumgebung Lotus Notes und

als Entwicklungsumgebung Lotus Domino Designer 44 zur Verfügung. Groupware

fungiert als Middleware systemplattform- und anwendungsunabhängig in einer

verteilten heterogenen Systemlandschaft als Kommunikations- und Informationsschnitt-

stelle. Die Integration unterschiedlicher Anwendungen wird z.B. durch Import- und

Export-Funktionen, Datei-Anhänge (Attachments), Objekt Einbettung (OLE 45 ),

44 Siehe [Lotus Dev. 1999] und [Lotus Dev. 1997] 45 Object Linking and Embedding


dynamische Anbindung an andere Anwendungen wie relationale Datenbanken per

ODBC 46 etc. unterstützt. Erst durch diese Integrationsfähigkeit der Groupware-

Plattform werden die in dieser Arbeit realisierten Lösungsansätze47 möglich.

Sämtliche Domino Applikationen bestehen aus einer oder mehreren Datenbanken. Die

Datenbanken enthalten sowohl die Daten als auch die Gestaltungselemente für das

Erzeugen und Verwalten dieser Daten. Im Folgenden werden einige für diese Arbeit

relevante Gestaltungselemente dieser Software beschrieben.

Masken (Forms)

Alle Notes-Dokumente (Verbunddokumente/ Compound Documents) innerhalb einer

Datenbank werden durch den Einsatz von Masken erstellt. Ein Dokument besteht aus

dem eigentlichen Datensatz (Note), der nicht sichtbar ist, und der Maske, welche zur

Strukturierung und Präsentation des Datensatzes dient. Die Daten werden innerhalb der

Maske über die Maskenfelder erfasst. Dabei besteht eine Stärke von Lotus Notes darin,

diverse Datentypen von hoch strukturierten Datenstrukturen bis hin zu nicht

strukturierten oder multimedialen Datenformaten, wie z.B. Graphiken, Dateien etc. in

einem Dokument aufnehmen zu können. Für die Aufnahme der letzteren Datentypen

werden sogenannte Rich Text-Felder verwendet.

Ansichten (Views)

Die Ansichten zeigen den vorhandenen Dokumentenbestand der Datenbank in

tabellarischer Form an. Durch ihre Funktionalität und Flexibilität können Ansichten so

gestaltet werden, dass der unterschiedliche Informationsbedarf des Anwenders im Sinne

eines Dokumentenmanagements berücksichtigt wird. Die eigentliche Navigationsstruk-

tur einer Datenbank besteht in der Regel aus mehreren dieser Ansichten mit jeweils

einer anderen Sicht auf den Dokumentenbestand.

Agenten (Agents)

Agenten stellen innerhalb der Datenbank autonome Programme dar, durch deren

Einsatz Routineaufgaben automatisiert werden können. Die Agenten lassen sich

ereignis- oder zeitgesteuert aktivieren und führen im „Hintergrund” diverse Aufgaben

aus, wie z.B. das Verschicken einer Abwesenheitsnachricht, das Archivieren von

Dokumenten oder das Suchen von Informationen in einer Datenbank. Zur

46 Open Data Base Connectivity 47 Vgl. [Nastansky/Fischer/ Herold/Dangelmaier/Suhl 2000] S.257


Programmierung von Agenten können die von Lotus eigens entwickelten Sprachen

Lotus Notes Formula Language oder LotusScript verwendet werden. Zusätzlich können

weitere Sprachen wie Java oder JavaScript eingesetzt werden.

Rollen (Roles)

Rollen sind Bestandteil des Sicherheitsmanagements der Datenbank. Sie werden in der

ACL48 der Datenbank definiert und können dann einzelnen Personen und Gruppen

zugeteilt werden. Innerhalb der Datenbank kann die Zuordnung dieser Rollen bei

sicherheitsrelevanten Zugriffen überprüft werden. Durch diesen Mechanismus kann bei

der Entwicklung einer Applikation von konkreten Personen und Gruppen abstrahiert

werden. Bezogen auf die Ablaufstruktur kann somit auf die wachsende Komplexität der

Prozesse mit einem flexiblen Rollenkonzept reagiert werden. Durch das Abstrahieren

wird eine relative Zuordnung von Personen, Abteilungen und Arbeitsgruppen

ermöglicht, und vorhandene Restriktionen werden aufgehoben.

Für weitergehende Informationen zu der Groupware-Plattform Lotus Notes/ Domino

wird auf die diversen Dokumentationen der Firma IBM49 verwiesen.

2.2.2 Das Office-Management-System PAVONE Enterprise Office

PAVONE Enterprise Office basiert auf der im Kapitel 2.2.1 beschriebenen Groupware-

Plattform und stellt ein integriertes Office- und Workflow-Management-System zur

Unterstützung einer ganzheitlichen elektronischen Prozessverarbeitung in einer

verteilten Office-Umgebung dar. Bestandteil der Enterprise Office-Architektur sind vier

Datenbanken. Zusätzlich kann die Software um die beiden externen Programme

PAVONE OrganizationModeler und PAVONE ProcessModeler erweitert werden.

Sämtliche Komponenten der Enterprise Office-Umgebung sind in Abbildung 2-4 zu

sehen.

48 Die ACL (Access Control List) beinhaltet die Zugriffsrechte der Datenbank. Siehe [Lotus Dev. 1999] 49 Siehe z.B. [Lotus Dev. 1996], [Lotus Dev. 1997] und [Lotus Dev. 1999]


OfficeDatenbank

OrganizationDatenbank

ProcessDatenbank

SettingsDatenbank

Enterprise OfficeDatenbanken

Enterprise Officeexterne Tools

Abbildung 2-4: Architektur der PAVONE Enterprise Office-Umgebung50

Im Folgenden werden die einzelnen Komponenten in kurzer Form erläutert51:

PAVONE Office Database Das ist die zentrale Datenbank, in der das gesamte Office-Management abgewickelt

wird. Der Endanwender kommt in der Regel nur mit dieser Datenbank in Berührung.

PAVONE Organization Database Die Personen, Abteilungen, Arbeitsgruppen und Rollen der PAVONE Enterprise

Office-Umgebung werden in dieser Datenbank verwaltet. Diese Datenbank dient

hauptsächlich der Verwaltung aller Ressourcen, die im PAVONE Enterprise Office-

Umfeld eingesetzt werden. Eine Ressource ist z.B. eine Person, die durch einen Namen

repräsentiert wird.

PAVONE Process Database Die erstellten Geschäftsprozesse werden in dieser Datenbank gespeichert.

PAVONE Settings Database Listeneinträge und allgemeine Vorlagen, die allen Anwendern zur Verfügung stehen

sollen, werden in dieser Datenbank zentral gespeichert.

50 [Nastansky/Fischer/ Herold/Dangelmaier/Suhl 2000] S.261 51 [PAVONE 2001]


Der OrganizationModeler ist ein Softwaresystem, mit dem die Organisationsstruktur

(Aufbauorganisation) grafisch visualisiert und bearbeitet werden kann, um der

zunehmenden Anforderung an Flexibilität der Aufbauorganisationsstruktur gerecht zu

werden. Der ProcessModeler ist ein grafisches Modellierungswerkzeug zur Definition

von strukturierten Prozessen (Ablauforganisation). Ein modellierter Prozess kann

anschließend für eine Analyse als Simulation ausgeführt werden. Die gespeicherten

Prozessdefinitionen werden in der Datenbank Process abgespeichert und werden bei

einer Initialisierung einer neuen Workflow-Instanz in der Datenbank Office ausgeführt.

Neben feststrukturierten Workflows erlaubt das Enterprise Office-System auch die

Verarbeitung von Ad-hoc-Workflows. Diese werden direkt in der Datenbank Office

modelliert und initiiert.

Abbildung 2-5: Beispiel eines Ad-hoc-Workflows im Enterprise Office-System

Ad-hoc-Vorgänge können innerhalb des PAVONE Enterprise Office-Systems in jeder

Maske, selbst innerhalb eines vordefinierten Workflows initiiert werden. Obwohl

PAVONE Enterprise Office eine mächtige Office- und Workflow-Umgebung darstellt,

bietet die Ad-hoc-Workflow-Komponente dieses Systems analog zu aktuellen Ansätzen

anderer Anbieter nur eine eingeschränkte Modellierungs- und Ausführungsfunktionali-

tät. Auf diesen Sachverhalt wird in Kapitel 3 beim Vorstellen des GroupProcess-

Systems eingegangen.

Ausgehend von dem aktuellen Softwarestatus soll das GroupProcess-System als eine

Erweiterung von bestehenden Workflow-Management-Systemen (in dieser Arbeit dem


Enterprise Office-System) verstanden werden. Es ist nicht beabsichtigt, ein

vollständiges System neu zu implementieren52.

2.3 Technologien für die Entwicklung der Web-Lösung

In den folgenden beiden Unterkapiteln 2.3.1 und 2.3.2 werden die verwendeten

Standardtechnologien für die Entwicklung der Web-Lösung behandelt. Dabei geht es im

Wesentlichen darum, die Gründe und die Motivation für die Wahl dieser Technologien

plausibel zu machen. Eine programmiertechnische Einführung findet hingegen nicht

statt.

2.3.1 Die Programmiersprache Java

Web-Applikationen werden in vielen Umgebungen eingesetzt. Ein wesentlicher Aspekt

dabei ist das Verwenden offener Systeme und Standards, die sich an vorhandene

Standards anpassen und portable sind. Die Nutzung objektorientierter Tools ist in

hohem Grade wünschenswert. Dieses unterstützt eine Wiederverwendung in einer

heterogenen Umgebung mit unterschiedlichen Anwendungen. Das Ziel besteht darin,

Anwendungssysteme zu konzipieren und zu entwickeln, die die heutigen Anforderun-

gen nach hohem Wachstum und Dynamik, wie es in der Geschäfts- und Technologie-

welt zu beobachten ist, erfüllen und mit aktuellen Produkten und Technologien

koexistieren.

Die Programmiersprache Java, die von dem Unternehmen SUN Microsystems

entwickelt wurde und 1995 in der ersten Version vorlag, stellt die für Web-

Anwendungen geforderte Architektur zur Verfügung.

JAVA Quellcode

(ASCII) JAVA-Bytecode

Hardware (x86,PPC,EC…)

Java Compiler Java Virtual Machine

Abbildung 2-6: Transformationsebenen von Java-Code

Durch die Struktur von Java-Programmen besitzen diese eine ausgeprägte

52 Siehe [Huth/Nastansky 2000a] S. 5


Portierbarkeit53 und sind unabhängig von jeder Systemplattform, die die Java Virtual

Machine (JVM) implementiert. Durch diese Eigenschaften können Java-Programme auf

jeden Client verteilt und ausgeführt werden, der über einen Java-fähigen Web-Browser

verfügt. Die Java-Klassenbibliotheken wurden von Anfang an so ausgelegt, dass sie

eine einfache Implementierung verteilter Systeme über Netzwerke ermöglichen.

Ein weiterer Aspekt für die Wahl von Java für die Entwicklung des Prototyps stellt die

enge Verbindung der Sprache zum Internet und zum World Wide Web dar. Mit Hilfe

von Java ist es möglich Applets zu entwickeln, die über das Web verbreitet und mit

Hilfe eines Web-Browsers gestartet werden können. Dazu wurde die HTML-Sprache

um das APPLET-Tag erweitert. Sie bietet so die Möglichkeit, kompilierten Java-Code

in normale Web-Seiten einzubinden. Java hat sich zum WWW-Standard entwickelt und

wird in allen IT-Bereichen von Handel, Industrie und Verwaltung eingesetzt.

Des Weiteren stellt der Sicherheitsaspekt bei der Ausführung von Geschäftsprozessen

über das Internet eine besondere Herausforderung dar. Sicherheit war eines der

wichtigsten Designziele bei der Entwicklung von Java. Sämtliche Web-Applets laufen

in einer gesicherten Umgebung, der Sandbox, aus der heraus nur ein eingeschränkter

und kontrollierter Zugriff auf die Ressourcen des lokalen Clients möglich ist54. Diese

Sicherheit schafft Vertrauen und erhöht die Akzeptanz für den Einsatz und die Nutzung

von Java-Applikationen bei der Ausführung von Geschäftsprozessen.

Durch die Offenheit der Groupware-Plattform Lotus Notes/ Domino lassen sich Java-

Applets weiterhin in eine Notes-Applikation einbinden. Ein Vorteil, der es u.a.

ermöglicht, Java-Anwendungen sowohl im Groupware-Client Lotus Notes als auch in

einem Web Browser zu nutzen.

2.3.2 Die Auszeichnungs- und Metasprache XML

XML (Extensible Markup Language) wurde vom World Wide Web Consortium (W3C)

entwickelt und liegt seit 1998 in der Version 1.0 vor. XML basiert auf SGML (Standard

Generalized Markup Language), dem internationalen Standard zur Definition von

Beschreibungen für Strukturen und Inhalten von verschiedenen elektronischen Quellen.

XML ist wie HTML eine Auszeichnungssprache, wobei Erstere im Gegensatz zu

HTML keinen fest vorgegebenen Satz an Tags besitzt, sondern sich diese vom Benutzer

53 „Write once, run anywhere“


definieren lassen. Gleichzeitig ist XML eine Metasprache, mit deren Hilfe sich andere

Auszeichnungssprachen für spezielle Anwendungen definieren lassen. Die Struktur

solcher Sprachen lässt sich durch den Einsatz von DTDs (Document Type Definition)

oder XSL Schemata (Exentible Stylesheet Language) festlegen, die die Menge der

zulässigen Tags und deren Anwendung auf den Text bestimmen55.

XML-Dokument

Daten

(XML) Struktur

(DTD / XML Schema)

Layout

(XSL)

Abbildung 2-7 Struktur eines XML-Dokuments

Die XML-Technologie nimmt eine Trennung von Daten, Struktur und Repräsentation

(siehe Abbildung 2-7) vor. Durch diese strikte Trennung wird eine Quelle zur

Verfügung gestellt, die in viele Zielformate transformiert werden kann. So ist es z.B.

möglich, ein XML-Dokument zu einer HTML-, WML- oder PDF-Datei zu verarbeiten

oder auch als Datenaustauschformat in grafischen Benutzungsschnittstellen (GUI)

einzusetzen 56 . Durch diese Architektur wird die Definition und der Transfer von

komplexen Datenstrukturen erheblich vereinfacht. XML stellt im Moment die

wichtigste Standardisierungsbestrebung im Bereich der Dokumentenrepräsentation

durch Auszeichnungssprachen dar und setzt sich in zunehmenden Maße als Standard für

die Repräsentation und den Austausch von Daten über das Internet 57 durch. Der

Austausch von komplexen Datenstrukturen zwischen heterogenen Systemen über das

Internet ist Bestandteil dieser Arbeit.

54 Vgl. [Krüger 2000] und [WfMC 1998a] S.30 55 Vgl. [Jost 2001] 56 Siehe [Heflin/Hendler 2000] S.1 57 Vgl. [Bertino/Carminati/Ferrari 1999] S.44

3 Das GroupProcess-Konzept - 22 -

3 Merkmale und Anforderungen eines Ad-hoc-Workflow-Management-Systems: Das GroupProcess-Konzept

In diesem Kapitel werden zunächst die zentralen Aussagen des GroupProcess-Projekts

in Hinblick auf die Zielsetzung diskutiert, um anschließend auf die zu Grunde liegenden

technologischen Konzepte, sowie auf die Architektur und Einsatzszenarien eingehen zu

können. Der im Rahmen dieser Arbeit realisierte Web-basierte Prototyp ist Bestandteil

des GroupProcess-Systems. Um ihn im Text von dem Prototypen für den Groupware-

Client abgrenzen zu können, werden im Folgenden unter dem GroupProcess-System

sämtliche im Umfeld des Projekts entstandenen Lösungen verstanden. An Stellen, wo

eine Differenzierung zwischen den beiden Prototypen notwendig ist, wird explizit von

der Web- und der Groupware-Lösung gesprochen.

In vielen Unternehmen werden stark automatisierte Kernprozesse durch strukturierte

Workflows abgebildet. Obwohl Ad-hoc-Prozesse ebenfalls in allen Bereichen der

Unternehmenswelt unterschiedlich stark vertreten sind, verfügen heutige Systeme, die

zu deren Ausführung eingesetzt werden, nur über eine unzureichende Funktionalität und

Flexibilität. Sie sind ausschließlich für die Abbildung linearer Prozesse geeignet und

erlauben keine Verarbeitung von parallelen Prozessen, Alternativen und Schleifen.

Möglichkeiten für eine Modellierung und Visualisierung der Prozesse während der

Ausführung sind in den Systemen ebenfalls nicht vorhanden. Weiterhin werden bei der

Ausführung von Ad-hoc-Workflows die verschiedenen im Unternehmen genutzten

Medien eingesetzt. Neben der herausragenden Stellung von Email-Systemen kommen

andere Kommunikationsmittel wie Telefon, papierbasierte Korrespondenz, Video-

Konferenzsysteme etc. zum Einsatz. Durch die Nutzung unterschiedlichster Medien in

der Praxis entstehen einige Nachteile. Der verursachte Medienmix verhindert eine

vollständige, kontinuierliche Speicherung und Verarbeitung der Daten. Einhergehende

Medienbrüche lassen nur eine ineffiziente Ausführung von Ad-hoc-Prozessen zu. Die

verteilten und unvollständigen Informationen erlauben in den meisten Fällen weder eine

ex post Analyse zwecks einer Historie oder Dokumentation noch eine Planung der

nächsten Ausführungsschritte. Aufgrund dieser Restriktionen muss jeder Ad-hoc-

Prozess quasi vollständig neu modelliert werden. Bereits ausgeführte Prozesse können

nicht als Vorlage für weitere ähnliche Prozesse verwendet werden, obwohl dies auch

bei Ad-hoc-Prozessen in einem gewissen Ausmaß möglich ist.


Ad-hoc-Prozesse entwickeln sich häufig im Unternehmen aufgrund ihrer zunehmenden

Relevanz zu höher strukturierten und besser planbaren Prozessen. An dieser Stelle ist

der Einsatz von herkömmlichen Workflow-Management-Systemen möglich. Bisher

werden die Prozesse von Spezialisten analysiert und implementiert, die sich das Wissen

in der Regel durch Befragung von einzelnen Prozessverantwortlichen, anstatt

unmittelbar von den Beteiligten, verschaffen. Damit das Prozesswissen der Beteiligten

für den Prozessdesign erhalten bleibt und umgesetzt werden kann, ist hier eine

Unterstützung durch das Ad-hoc-WfMS für die Transformation in strukturierte

Workflows notwendig.

Der beschriebene Status in Unternehmen lässt die Verbesserungspotentiale des

GroupProcess Ad-hoc-Workflow-Management-Systems erkennen. Gleichzeitig lassen

sich daraus folgende drei Zielvorgaben für ein solches System ableiten58:

• Gezielte Unterstützung von Ad-hoc-Prozessen durch ein Ad-hoc-WfMS für eine

Groupware-basierte Office-Umgebung durch Integration der Ad-hoc-Workflow-

Komponenten in ein traditionelles Workflow- und Office-Management-System

für strukturierte Prozesse (Workflow-Management-Aspekt)

• Wandlung von impliziten, informalen Prozesswissen in Unternehmen in

explizites, formales Prozesswissen (Knowledge-Management-Aspekt)

• Vereinfachung des Übergangs von Ad-hoc-Prozessen zu vordefinierten,

strukturierten Prozessen

Somit kann durch die GroupProcess-Lösung „...zur Nutzung von synergetischen

Effekten aus prozessbezogener Sicht [...]die fehlende Verbindung zwischen Office-,

Workflow- und Knowledge-Management-Systemen hergestellt werden59.“

3.1 Das GroupProcess-Kontinuum

Die Konzeption des GroupProcess-Projekts sieht eine Lösung vor, die beide Haupttypen

von Prozessen unterstützt60:

„Wir betrachten die Konzepte des eher starren Workflow Managements im Sinne von Geschäftsprozessautomatisierung einerseits und dem flexibleren Team-getriebenen Ansatz andererseits nicht als grundsätzlich unterschiedlich

58 Siehe [Huth/Erdmann/Nastansky 2001] S.10 und [Huth/Nastansky 2000a] S.1-3 59 [Huth 2002] 60 [Huth/Nastansky 2000a] S.4


oder sogar entgegengesetzt. Vielmehr synthetisieren wir beide Ansätze durch die Benutzung von überlappenden Workflow-Substrukturen, um eine Basis für flexible und doch produktive Informationssysteme zu gestalten.“

Zwischen diesen beiden Idealtypen von vollständig strukturierten Prozessen bis hin zu

hochdynamischen und flexiblen Prozessen lassen sich feinere Abstufungen

differenzieren. Es entsteht ein Kontinuum von verschieden Workflow-Typen.

Tabelle 3-1: Workflow-Kontinuum des GroupProcess-Konzepts61

Ausgangspunkt dieses Kontinuums ist das GroupFlow-Kontinuum, welches

weiterentwickelt und den Anforderungen von GroupProcess angepasst wurde. Das

GroupProcess-Kontinuum zeigt die verschiedenen Workflow-Kategorien an, so dass

herausgearbeitet werden kann, welche Typen durch bestehende Workflow-

Management-Systeme unterstützt werden und welche durch den GroupProcess-Ansatz

zu unterstützen sind.

61 Siehe [Huth/Nastansky 2000a] S.4 ff. und [Huth/Erdmann/Nastansky 2001]


(1a) Ad-hoc-Workflows

Ad-hoc-Workflows zeichnen sich durch einen einmaligen und kurzlebigen Charakter

aus. Obwohl diese Prozesse typischerweise eine eher geringere Komplexität besitzen,

lassen sie sich aufgrund ihrer hohen Variation und dem offenen Ende nur in Teilen

vordefinieren und sind allgemein schwer zu strukturieren. Wie in Kapitel 1.1

beschrieben, wurde bis zu diesem Projekt die Automatisierung dieser Art von Prozessen

als nicht rentabel angesehen. In der Geschäftswelt sind Ad-hoc-Prozesse u.a. überall

dort zu finden, wo von den standardisierten Routineprozessen abgewichen werden muss

und eine Einzel- bzw. Ausnahmebehandlung stattfindet. Darunter fallen z.B. alle

Kundenanfragen in einem Unternehmen. Dieser Typ von reinen Ad-hoc-Prozessen wird

direkt durch das GroupProcess-System unterstützt. Hierfür steht ein spezielles

Modellierungs- und Visualisierungswerkzeug sowie eine Workflow-Engine 62 zur

Verfügung, die für die spezifischen Charakteristika von Ad-hoc-Workflows konzipiert

wurden.

(1b) Offene Gruppenbearbeitung innerhalb von Ad-hoc-Workflows

Offene Gruppenbearbeitung innerhalb von Ad-hoc-Workflows bezeichnet, dass

mindestens eine Teilaufgabe innerhalb des gesamten Workflows in Form von

Gruppenarbeit durchgeführt wird. Dabei kann Gruppenarbeit gemäß Kapitel 2.1.1 als

eine Aufgabe definiert werden, die von einem Team in kooperativer Weise ausgeführt

wird. Vor und nach der Gruppenaufgabe können diverse Ad-hoc-Aufgaben gelagert

sein. Als Beispiel wäre hier eine Kundenanfrage denkbar, für deren Weiterbearbeitung

die konkreten Arbeitsergebnisse eines Teams vorliegen müssen. Diese Art von

Prozessen wird durch das GroupProcess-System ebenfalls direkt unterstützt. Für die

Gruppenarbeit werden Funktionalitäten der zu Grunde liegenden Groupware-Plattform

genutzt (hier Lotus Notes/ Domino).

(1c) Ad-hoc-Workflows mit einem Unterprozess oder Cluster

Bei dieser Kategorie von Prozessen werden mehrere Aufgaben zu einem Unterprozess

oder Cluster zusammengefasst. Dieses kann aus zwei Gründen erfolgen. Damit in einem

zunehmend komplexer werdenden Ad-hoc-Workflow während der Modellierung eine

62 Die Workflow-Engine (Run Time) steuert und überwacht ein Workflow über den gesamten Zeitraum seiner Ausführung.


gute Übersicht und Lesbarkeit erhalten bleibt, werden mehrere Teilaufgaben zu einer

Gesamtaufgabe zusammengefasst. Dieses dient somit einer besseren Visualisierung.

Der zweite Grund tritt auf, wenn der Initiator oder der aktuelle Bearbeiter nicht über das

Wissen verfügt, um eine übergeordnete Aufgabe detaillierter zu strukturieren. In dem

Fall wird ebenfalls ein Cluster (Unter-/ Subworkflow) angelegt, der zu einem späteren

Zeitpunkt von anderen Personen weitermodelliert werden kann. Bezogen auf das oben

verwendete Beispiel könnte innerhalb der Kundenanfrage als Gesamtprozess eine

Teilaufgabe (z.B. „Analyse der Kundenhardware“), deren Strukturierung dem

Prozessinitiator nicht bekannt ist, als Subworkflow angelegt werden. Dieser Cluster

wird später von den zuständigen Mitarbeitern, die über die nötigen Kompetenzen

verfügen, weiter differenziert und zu Ende modelliert. Dieser Workflow-Typ wird

ebenfalls durch das GroupProcess-System unterstützt.

(2a) Offene Teambearbeitung innerhalb eines vordefinierten Workflows

Dieser Workflow-Typ gehört, wie die beiden nächsten Workflow-Typen, zu der

Kategorie der semistrukturierten Workflows. Die offene Teambearbeitung hier ist

vergleichbar mit dem in (1b) beschriebenen Typ. Im Unterschied zu (1b) existiert in

diesem Fall ein strukturierter, vordefinierter Prozess, und somit ist die offene

Teambearbeitung nicht ein Teil eines Ad-hoc-Prozesses. Ansonsten wird die offene

Teambearbeitung analog verwendet. Dieser Typ wird bereits durch die vorhandenen

Workflow-Management-Systeme (hier PAVONE Enterprise Office) beherrscht und

bedarf keiner weiteren Unterstützung durch das GroupProcess-System.

(2b) Ad-hoc-Unterprozess innerhalb eines vordefinierten Workflows

Hier liegt ein mit dem Fall (1c) vergleichbarer Workflow-Typ vor. Es ist ebenfalls ein

Cluster gegeben, dessen Struktur von dem jeweiligen Bearbeiter aufgebaut werden

muss. Der Unterschied liegt darin, dass dieser Cluster in einem gut strukturierten

Workflow eingebettet ist. Eine Unterstützung für die vordefinierten Strukturen dieser

Art von Prozesse ist durch die herkömmlichen Workflow-Management-Systeme

gegeben. Das entwickelte Ad-hoc-Workflow-Management-System konzentriert sich

daher auf den Ad-hoc-Subworkflow. Zu diesem Zweck wird die Funktionalität des

GroupProcess-Systems in das zu Grunde liegende Basissystem eingebunden (hier

PAVONE Enterprise Office).


(2c) Ad-hoc-Modifikation und Ausnahmebehandlung eines vordefinierten Workflows

Bei diesem Typ von semistrukturierten Workflows handelt es sich um einen

vordefinierten Workflow, der Ad-hoc-Modifikationen zur Laufzeit umfasst. Im

Gegensatz zu (2b) ist dieser Workflow zunächst vollständig strukturiert und beinhaltet

keine undefinierten Stellen. Unvorhergesehene Situationen und Ausnahmen, die nicht

im vordefinierten Prozessverlauf berücksichtigt werden konnten, erfordern jedoch die

Möglichkeit einer Ausnahmebehandlung. Das Workflow-System muss daher die

Flexibilität besitzen, jederzeit die Modellierung von Ad-hoc-Vorgängen zuzulassen.

Solche Fälle sind im realen Geschäftsleben sehr wahrscheinlich und zwingen den

Benutzer bei einer fehlenden Unterstützung zum Verlassen des Systems. Durch die

Nutzung weiterer Systeme zur Lösungsfindung ist keine vollständige Protokollierung

für eine Dokumentation und Darstellung der Ausnahmebehandlung mehr möglich. Der

Fall der hier beschriebenen Ad-hoc-Modifikation wird ebenfalls durch das verwendete

Workflow- und Office-Management-System unterstützt. Dennoch können durch das

GroupProcess-System weitere Verbesserungen, wie z.B. bei der grafischen Darstellung,

erreicht werden.

(3) Vordefinierte Workflows

Die letzte Kategorie im GroupProcess-Kontinuum beinhaltet die etablierten, fest

strukturierten Workflow-Modelle, die von derzeit verfügbaren Standard Workflow-

Management-Systemen verarbeitet werden. Alle zur Ausführung notwendigen

Informationen sind in der Modellierungsphase verfügbar oder können wenigstens zur

Laufzeit automatisch ermittelt werden. Diese Workflow-Modelle werden in der Regel

für eine bestimmte Routinetätigkeit modelliert, um sie mit einer hohen Frequenz

unverändert ausführen zu können. Ein Beispiel für diese Art von Workflow-Modellen

ist eine standardisierte Bearbeitung von Kundenanfragen oder die Abwicklung eines

Kundenantrags für eine Kreditkarte bei einer Bank.


3.2 Spezielle konzeptionelle Ansätze für Ad-hoc-Workflow-Management

Aufbauend auf das GroupProcess-Kontinuum wird nun die technologische Konzeption

des GroupProcess-Systems vorgestellt. Um ein derartiges System zu realisieren, müssen

einige Paradigmen heutiger Workflow-Management-Systeme überdacht und

gegebenenfalls angepasst werden63.

3.2.1 Fusion von Build Time und Run Time

Die Trennung von Build Time und Run Time, also von Modellierungs- und

Ausführungsphase, ist ein Paradigma aktueller Workflow-Management-Systeme. Nach

diesem Verfahren wird während der Build Time zunächst ein Prozess definiert und

analysiert und mit einem Modellierungswerkzeug (hier PAVONE ProcessModeler)

vollständig entworfen. Erst wenn die Modellierung abgeschlossen ist und eine

Workflow-Klasse vorliegt, werden in der Run Time beliebig viele Workflow-Instanzen

von dieser Workflow-Klasse ausgeführt. Die Run Time bezeichnet die Ausführungs-

und Steuerungssoftware, dessen Kern die Workflow-Engine darstellt. Diese strikte

Trennung ist bei Ad-hoc-Workflows aufgrund der sich ständig abwechselnden

Modellierungs- und Ausführungsphasen nicht möglich. Stattdessen besteht die Lösung

bei Ad-hoc-Workflows in der Fusion von Build Time und Run Time. Dadurch

verschmelzen beide Phasen zu einer Einheit, die erst eine simultane Gestaltung und

Ausführung des Workflows ermöglicht.

Des Weiteren findet in den heutigen Workflow-Systemen eine Trennung von

Workflow-Modell und Workflow-Instanz statt. Für strukturierte, gut vordefinierbare

Prozesse ist diese Vorgehensweise sinnvoll. Eine Workflow-Klasse wird einmalig

modelliert, damit davon Workflow-Instanzen mit einer hohen Frequenz ausgeführt

werden können. Die hohe Dynamik und Kurzlebigkeit von Ad-hoc-Workflows

hingegen kann nicht in einem Modell festgehalten werden. Vielmehr bilden Modell und

Instanz eine Einheit. Das sich schrittweise entwickelnde „Workflow-Modell“ ist

gleichzeitig eine Instanz seiner selbst. Ein abgeschlossener Ad-hoc-Workflow kann

wiederholt genutzt werden. Dieser lässt sich als Vorlage (Schablone) für einen weiteren

Workflow einsetzen, der während der Laufzeit erneut modifiziert werden kann.

63 Vgl.[Huth/Nastansky 2000a] S.10 ff.


3.2.2 Partizipatives, verteiltes Design von Ad-hoc-Workflows

In der Einleitung dieses Kapitels wird darauf hingewiesen, dass Geschäftsprozesse zur

Zeit in Unternehmen von speziell ausgebildeten Workflow-Designern modelliert

werden. Die fertigen Workflow-Klassen werden von den Mitarbeitern für gleiche, sich

wiederholende Prozesse instanziert. Für Ad-hoc-Workflows ist dieses Verfahren aus

mehreren Gründen ungeeignet. Die Gestaltung eines vollständigen Prozessmodells für

die Ausführung von Ad-hoc-Workflows ist nicht möglich, da keine Person im

Unternehmen über das Wissen verfügt, um jeden Workflow während der Laufzeit unter

Berücksichtigung aktueller Daten ständig ad hoc zu modifizieren. Außerdem würde

diese Verfahrensweise zu einer Kostenexplosion führen. Aus diesem Grunde sollte ein

partizipatives, verteiltes Design von Ad-hoc-Workflows ermöglicht werden. Hieraus

resultieren zwei Vorteile. Zum einen entfällt eine kostenintensive und zeitraubende

Planungs- und Designphase. Zum anderen sammelt sich im Laufe der Zeit bei den

Prozessbeteiligten Wissen über die Ablaufstrukturen in der Organisation. Werden die

Prozessbearbeiter direkt an der Prozessmodellierung beteiligt, so kann implizites,

informelles Prozesswissen zu expliziten, formellen Prozesswissen umgewandelt

werden. Das Prozesswissen bleibt erhalten und kann im Sinne des Knowledge

Managements im Unternehmen genutzt werden. Erreicht wird das Ziel des

partizipativen Designs durch ein System, welches zu jedem Zeitpunkt den Bearbeitern

eine Anpassung und Weiterentwicklung der laufenden Workflows erlaubt64.

3.2.3 Übergang von konkreter zu abstrakter Prozessmodellierung

Unstrukturierte Workflows lassen sich in strukturierte Workflows transformieren.

Dadurch kann evaluiertes Prozesswissen zur Modellierung von standardisierten

Geschäftsprozessen im Unternehmen genutzt werden. Für die Transformation ist eine

Art von Abstraktion notwendig, die sich im Wesentlichen auf die Prozessbeteiligten

bezieht. Bei Ad-hoc-Workflows verlaufen die Prozesse vorwiegend im Kernteam des

Initiators und sind dementsprechend zumeist an konkrete Personen gebunden. In dem

abstrakten Workflow-Modell von strukturierten Prozessen wird hingegen weitgehend

mit Rollen, Abteilungen und Arbeitsgruppen gearbeitet. Für die Umwandlung von Ad-

hoc-Workflows muss von den konkreten Personen auf die organisatorischen Entitäten

64 Siehe [Huth 2000] und [Dongsoo/Jaeyong 2000]


geschlossen werden. Dabei entstehen oft zwischen einer Person und den Rollen,

Abteilungen und Arbeitsgruppen nicht eindeutige Relationen, die aufgelöst werden

müssen. Diese Arbeit kann durch eine Software unterstützt werden.

3.3 Die GroupProcess-Architektur

Nachdem die Konzepte des GroupProcess-Ansatzes theoretisch fundiert wurden, folgt

die Darstellung der praktischen Umsetzung dieser Konzepte innerhalb der

GroupProcess-Architektur. Das GroupProcess-System erlaubt die Veränderung des

Prozessgraphens während der Laufzeit. Eine Einteilung in eine Modellierungs- und

Ausführungsphase besteht im Gegensatz zu den Ansätzen herkömmlicher Workflow-

Systemen nicht. Daher muss für das GroupProcess-Konzept die Abbildung 2-3 aus

Kapitel 2.1.2 wie folgt modifiziert werden.

ProcessDefinition

Build Time Business Process Analysis,Modeling & Definition Tools

Run Time

Workflow EnactmentService

Process changesProcess Instantiation& Control

Applications& IT Tools

Run TimeInteraction withUsers & Application Tools

Process Design& Definition

Wor

Wor

App

Build Time = Run Time Process Definition and Process Instance as an Unit

Abbildung 3-1: Struktur des GroupProcess-Ansatzes65

Die Build Time (Gestaltung) und die Run Time (Ausführung) bilden nun eine Einheit.

Eine Differenzierung zwischen den beiden Phasen entfällt und somit existiert de facto

kein Unterschied mehr zwischen der Workflow-Klasse und der Workflow-Instanz.

Dieser Sachverhalt setzt das erstgenannte Konzept (Fusion der Modellierungs- und

65 [Huth 2002] S.29 angelehnt an [WfMC 1999] S.39, siehe Abbildung 2-2


Ausführungsphase) um. Analog zur Groupware-Lösung liegt der im Rahmen dieser

Arbeit realisierten Web-Lösung dieses Konzept ebenfalls zu Grunde.

Um die zweite Anforderung des partizipativen, verteilten Designs von Ad-hoc-

Workflows zu erfüllen, werden beim GroupProcess-Ansatz im Gegensatz zu anderen

Workflow-Systemen alle Informationen des Prozessgraphens, das Workflow-Protokoll

sowie alle weiteren Informationen, die bei der Ausführung des Workflows entstehen, in

einem Dokument gespeichert (siehe Abbildung 3-2).

Abbildung 3-2: Speicherung aller Workflow-Daten innerhalb eines Dokuments66

Durch die Einbettung des Workflow-Modellierungswerkzeugs als dynamisches

Message-Objekt 67 in einem Notes-Dokument ist die Gestaltung eines Workflow-

Modells nicht mehr auf den Workflow-Designer und die Ausführung der Workflows auf

die Prozessbearbeiter aufgeteilt. Allen Prozessbeteiligten steht das Modellierungs- und

Visualisierungswerkzeug während der gesamten Prozessausführung zur Verfügung, so

dass beide Funktionen jeweils vom aktuellen Vorgangsbearbeiter ausgeführt werden

können. Damit sind die Voraussetzungen für eine simultane Modellierung und

Ausführung gegeben.

66 [Huth 2002] 67 Elektronische Message-Objekte bestehen aus einem komplexen, formal beschreibbaren Behälter

(container), in dem sich aktuelle Inhalte (content), wie z.B. formatierte Datenelemente oder multimediale Datentypen, integrieren lassen. Sie unterstützen als Kommunikationselemente den Austausch, sowie die gemeinsame Nutzung von Daten, Informationen, Methoden und Verfahren.

Vgl. [Nastansky/Fischer/ Herold/Dangelmaier/Suhl 2000] S.251


An dieser Stelle stellt sich die Frage, wie eine konkrete Umsetzung der Benutzungs-

schnittstelle für ein Modellierungswerkzeug für Ad-hoc-Workflows aussehen könnte.

Abbildung 3-3 zeigt die GroupProcess-Lösung eines grafischen Modellierungs- und

Visualisierungswerkzeugs, das für den Groupware-Client entwickelt wurde. Weiterhin

ist ein tabellarischer, textueller Modeler mit der Bezeichnung Lean Workflow Modeler68

in der Entwicklung. Hierbei handelt es sich um eine alternative, ressourcensparende

Benutzungsschnittstelle für den Groupware-Client, in der die Ablaufstruktur in Form

eines Graphen miniaturisiert dargestellt wird.

Abbildung 3-3: Prototyp des GroupProcess-Systems für den Groupware-Client

Für den sinnvollen Einsatz des GroupProcess-Systems ist es erforderlich, dass allen

potentiellen Workflow-Bearbeitern die Nutzung des Systems ermöglicht wird. Der

Systemeinsatz sollte nicht durch die Abhängigkeit von einer bestimmten Plattform oder

durch die notwendige Installation einer Basissoftware auf dem Client-Rechner

erschwert oder verhindert werden. Um diesem Ziel einer maximalen Einsetzbarkeit

näher zu kommen, wurde im Rahmen dieser Arbeit zusätzlich zu der o.g. Lösung für

den Groupware-Client eine Web-basierte Lösung entwickelt. Das GroupProcess-System

68 [Peter 2002]


erfährt damit eine wesentliche Erweiterung seines Nutzungspotenials in Richtung

partizipatives, verteiltes Design von Ad-hoc-Workflows. Es ergibt sich eine neue

Gesamtarchitektur für das GroupProcess-System.

Ad hoc Workflow

Engine Application

DB Organization

DB Process

DB

Workflow Engine (predef. WF)

Office and Workflow Application

Email Tracking and Routing

Ad hoc Workflow Modeler and Viewer (Groupware Client)

Workflow Modeler (predef. WF)

Web Application

DB

Organization Modeler (Ad hoc and predef. WF)

Transformation Tool Ad hoc to predef. WF

Groupware Platform

Ad hoc Worklflow

Web Environment

Abbildung 3-4: Gesamtarchitektur des GroupProcess-Systems69

Die Abbildung zeigt die Komponenten des auf die Groupware-Plattform Lotus Notes/

Domino aufsetzenden Workflow- und Office-Management-Systems PAVONE

Enterprise Office und des GroupProcess-Systems. Die Bestandteile von Enterprise

Office werden im Kapitel 2.2.2 beschrieben. Für das GroupProcess-System werden in

der Abbildung die Komponenten des Groupware-Clients und des Web-Clients separat

aufgeführt. Die beiden Komponenten Ad hoc Workflow Web Environment und Web

Application DB stellen die in dieser Arbeit vorgenommene Erweiterung für das Web

dar. Durch den Einsatz der erstgenannten Komponente werden die Ad-hoc-Workflows

im Web in der zweiten Komponente Web Applikation DB erzeugt und ausgeführt. Der

Baustein Transformation Tool Ad hoc to predef. WF70 dient der Umsetzung des dritten

GroupProcess-Konzeptes (siehe Kapitel 3.2.3). Durch die Einbindung dieses Werkzeugs

69 Siehe [Huth 2002] 70 [Laumen, Leutnant 2001]


in die Enterprise Office-Umgebung lassen sich unstrukturierte Ad-hoc-Workflows in

strukturierte Workflow-Modelle umwandeln und dort nutzen. Die Ad-hoc-Workflows

der Web-Lösung können mit diesem Tool ebenfalls transformiert werden.

3.4 Technologieoptionen für die Umsetzung der Web-Lösung

Grundsätzlich können für die Umsetzung der Web-Lösung verschiedene Technologien

verwendet werden. Als Standardtechnologien kommen hier CORBA 71 , RMI 72 und

XML73 in Frage. Da es sich in der vorliegenden Arbeit um eine Web-Applikation

handelt und dem Anwender nicht lange Reaktionszeiten des Systems zugemutet werden

sollen, war die Entscheidung für eine bestimmte Technologie insbesondere von dem

Kriterium Performance abhängig.

Bei eigenen Performance Messungen am GCC, u.a. im Diplomarbeitsprojekt von Ingo

Erdmann74, hat sich herausgestellt, dass die Geschwindigkeit der Lotus Notes/ Domino

Implementation von CORBA für diese Anwendung nicht hinreichend ist. Das Auslesen

der Daten beansprucht bei Einsatz dieser Technologie eine nicht akzeptable Zeitdauer.

Daher wurde CORBA in dem Kontext dieser Arbeit nicht weiter berücksichtigt. Eine

Entscheidung zwischen den Technologien XML und RMI konnte nicht alleine aufgrund

von Differenzen in der Ausführungsgeschwindigkeit gefällt werden. Als zusätzliches

Kriterium wurde der Implementationsaufwand herangezogen. Auf der Client-Seite

besteht kein relevanter Unterschied. Beide Technologien müssen zusätzliche Java-

Klassen importieren. Auf der Server-Seite hingegen verlangt RMI die Installation eines

zusätzlichen Server-Tasks. Bei der Wahl von XML entfällt diese Installation, da der

Domino Server direkt einen XML-Export 75 anbietet. Des Weiteren wird diese

Technologie bereits im GroupProcess-System zur Verwaltung der Workflow-Struktur

eingesetzt, so dass keine weitere Technologie eingeführt werden muss. Weitere

Argumente, die für den Einsatz der Technologie XML sprechen, finden sich im Kapitel

2.3.2.

71 Siehe [OMG 2002] 72 Siehe [SUN 2002] 73 Siehe Kapitel 2.3.2 74 [Erdmann 2001] 75 Siehe Kapitel 4.2.3


3.5 Einsatzszenarien für das GroupProcess-Konzept

Die Notwendigkeit für den Einsatz von Workflow-Management-Lösungen für flexible

und dynamische Prozesse wurde im Kapitel 1.1 dieser Arbeit bereits herausgestellt und

wird in diesem Kapitel weiter vertieft. Es werden mögliche Einsatzszenarien für das

GroupProcess-System aufgezeigt. Zur Begründung der Notwendigkeit einer

GroupProcess-Lösung für das Web wird im ersten Szenario zunächst die Internet-

Entwicklung anhand aktueller Daten belegt.

Szenario 1

Das starke Wachstum des Internets und seiner Dienste, insbesondere des World Wide

Webs (WWW), lässt es immer interessanter werden, sich im WWW zu präsentieren,

Informationen anzubieten und weitergehende Anwendungen zu implementieren.

Abbildung 3-5: Entwicklung von Internet-Hosts76: 1995-200177

Dabei ist das starke Wachsen und die intensive Nutzung nicht in erster Linie auf

Privatpersonen zurückzuführen. Gerade für Firmen birgt das Internet große Potentiale in

sich. Die dargestellte Entwicklung in Abbildung 3-5 lässt vermuten, dass in der

Wirtschaft ein hoher Bedarf an Anwendungssystemen mit WWW-Integration besteht.

76 Ein Internet-Host stellt eine eindeutige Adresse dar, die über eine IP-Adresse oder den Hostnamen identifiziert ist (z.B. gcc.upb.de).

77 Siehe [Lottor 2001]


Weiterhin erstrecken sich das Wachstum und die allgemeine Akzeptanz auf immer

breitere Anwenderschichten und fördern die Motivation, das Internet für weitere

betriebliche Anwendungsbereiche zu nutzen. Die Unternehmen reagieren auf diesen

Sachverhalt. Dieses ist anhand des relativen Anteils der kommerziellen Web Domains78

(.com Domain) an der Gesamtzahl der Web Domains erkennbar.

Monat Anzahl der Hosts # .com Domain % .com Domain

Juli 2001 169491848 61225938 36 %

Juli 2000 103432319 38391519 37 %

Juli 1999 63019061 22461249 35 %

Juli 1998 42606144 13506865 32 %

Juli 1997 19540325 4501039 23 %

Tabelle 3-2: Verteilung der Top Level Domainnamen nach Anzahl der Hosts79

Aus Tabelle 3-2 lässt sich entnehmen, dass sich dieser Anteil bis 2001 bei ca. 33% aller

Internet-Angebote eingependelt hat, d.h. ungefähr ein Drittel aller Informationsangebote

im WWW sind kommerzieller Natur mit steigender Tendenz.

Herkömmliche Workflow-Management-Systeme ohne Nutzung des WWWs sind bereits

in vielen Unternehmen im Einsatz und weit ausgereift. Die verfügbaren Systeme mit

Internet-Integration beschränken sich wiederum auf die Ausführung von strukturierten,

vordefinierten Prozessen. Im Kapitel 1.1 dieser Arbeit wird herausgestellt, dass Ad-hoc-

Prozesse in allen Bereichen von Unternehmen anzutreffen sind und zunehmend an

Bedeutung gewinnen. Resultierend aus der oben aufgezeigten Internet-Entwicklung

wurde als konsequente Reaktion im Rahmen dieser Arbeit die Web-Integration des

GroupProcess-Systems realisiert. In diesem Einsatzszenario benötigt das Ad-hoc-

Workflow-Management-System gegenüber den anderen Szenarien keinen Groupware-

Client für die Ausführung. Gerade in verteilten Umgebungen stellt die Systemintegrati-

on über weltweit verteilte Standorte mit unterschiedlichen Systemen eine

Herausforderung dar. Durch die Interoperabilität der Internet-Technologie kann diese

Problematik gelöst werden.

78 Untergliederungseinheit des hierarchisch aufgebauten Computernamensystems DNS im Internet (Bsp: der Name www.knowledge.com enthält die Top Level Domain com) 79 [Internet Software Consortium 2002]


Szenario 2

In der GroupProcess-Architektur ist der Ad-hoc-Workflow-Modeler als Message-

Objekt in jedem Notes-Dokument einer Workflow-Instanz enthalten (vgl. Kapitel

3.2.2). Durch diese Struktur können Messaging- und Email-Systeme ebenfalls als

technischer Einsatzbereich genutzt werden. In dieser Umgebung wird das Message-

Objekt (genauer das Notes-Dokument mit dem enthaltenen Message-Objekt) von der

Workflow-Engine, die in einer zentralen Domino Datenbank (Intermediärdatenbank)

abgelegt ist, als Email von einem Workflow-Bearbeiter zum nächsten versendet

(Routing). In Abbildung 3-6 ist ein mögliches Beispielszenario abgebildet.

Mail-Datenbank LN

Mail-Datenbank MP

Mail-Datenbank NT

Mail-Datenbank CH

Intermediär- Datenbank

LN

MP NT

CH

LN 4

1a + 2a

1

2 3

5

4a 1b 2b

3a

3b 5a

4b + 5b Message-

Objekt

Workflow- Engine

Workflow- Graph

Messaging- System

Abbildung 3-6: Verarbeitung eines Ad-hoc-Workflows in der Messaging-Lösung

In der Abbildung ist im oberen Bereich die technische Struktur der beteiligten

Prozesskomponenten des Messaging-Systems und unterhalb der Graph des zugehörigen

Workflows zu sehen. Der Workflow startet von dem Knoten LN und verzweigt in die

beiden Knoten CH und NT (Kante 1 und 2 im Prozessgraphen). Im Messaging-System

wird das Messaging-Objekt aus der Mail-Datenbank der Person LN zu der

Intermediärdatenbank geschickt (Pfeil 1a + 2a) und von dort zu den beiden Mail-

Datenbanken CH und NT verteilt (Pfeil 1b und Pfeil 2b). Dabei kommt es zur Teilung

(Split), d.h. das Messaging-Objekt wird kopiert und liegt somit mehrfach vor. Die

Nummerierung der Pfeile gibt die zeitliche Abfolge des Workflows wieder. Zusätzlich


zeigen die mit dem Buchstaben a bezeichneten Pfeile die Weiterleitung des Message-

Objekts zur Workflow-Engine hin, während die mit b bezeichneten Pfeile den Fluss von

der Workflow-Engine zu den Mail-Datenbanken der Workflow-Bearbeiter anzeigen.

Hieraus lässt sich bereits die Funktionsweise des Systems erkennen. Die Weiterleitung

des Messaging-Objekts von der Mail-Datenbank eines Bearbeiters zum nächsten erfolgt

stets über die zentrale Intermediärdatenbank, in der die Workflow-Engine die Steuerung

und Überwachung der Messaging-Objekte übernimmt.

Szenario 3

Eine weitere Einsatzmöglichkeit bilden sogenannte Shared Database-Umgebungen. Es

handelt sich hierbei um dokumentenorientierte, verteilte Datenbanken. Um das

GroupProcess-System in diesem Umfeld einzusetzen, muss das System in das Design

der jeweiligen Datenbank integriert werden. Auf diese Weise lässt sich z.B. das

Workflow- und Office-Management-System Enterprise Office um die Ad-hoc-

Workflow-Funktionalitäten des GroupProcess-Systems erweitern.

4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 39 -

4 Prototypische Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems

Nach der Abhandlung über das GroupProcess-Konzept wird darauf aufbauend in

diesem Kapitel die technische Umsetzung der Web-basierten GroupProcess-Lösung

thematisiert. Zuvor werden einige zentrale Begriffe der folgenden Ausführung

spezifiziert.

Ad-hoc-Workflow-Modeler

Unter dem Ad-hoc-Workflow-Modeler wird das alleinstehende Web-

WorkflowModeler-Applet verstanden. Gemeint ist also ausschließlich das

Modellierungs- und Visualisierungswerkzeug, welches in den verschiedenen Szenarien

(siehe Kapitel 3.5) eingesetzt werden kann.

Workflow-Management-Umgebung

Für den Einsatz des Ad-hoc-Workflow-Modelers im Web ist eine angepasste

Ausführungs- und Kommunikationsplattform notwendig. Dazu wurde im Rahmen

dieser Arbeit eine Benutzungsschnittstelle (User Interface) für eine Web-Umgebung

konzipiert und umgesetzt. Diese dient zum Erzeugen und zur Verwaltung der

Workflow-Dokumente und wird in dieser Arbeit als Workflow-Management-

Umgebung bezeichnet.

Ad-hoc-Workflow-Management-System

Unter dem Begriff Ad-hoc-Workflow-Management-System werden der Ad-hoc-

Workflow-Modeler, die Benutzungsschnittstelle sowie die Domino Datenbanken80 der

GroupProcess-Systemarchitektur zusammengefasst. Somit umfasst dieser Begriff den

Prototypen in seiner Gesamtheit.

Web-Datenbank

Von der Web-Datenbank wird gesprochen, wenn aus technischer Sicht die zentrale

Domino Datenbank 81 , in der der Ad-hoc-Workflow-Modeler und die Benutzungs-

schnittstelle enthalten sind, gemeint ist. Die anderen Domino Datenbanken der Web-

Lösung bleiben unberücksichtigt.

80 Siehe Abbildung 4-1 81 Siehe Kapitel 4.1


4.1 Architektur des Web-basierten Systems

Bei der Erläuterung der Gesamtarchitektur des realisierten Prototyps geht es nicht um

die Behandlung technischer Einzelheiten, vielmehr sollen die Zusammenhänge auf

einem hohen Abstraktionsniveau und die Interaktionen der beteiligten Komponenten

offengelegt werden.

Web-Datenbank

Organization Datenbank

Addresses Datenbank

Domino- Directory

Datenbank

Domino Server

1

2 3

4

Abbildung 4-1: Architektur des Web-basierten GroupProcess-Systems

Die zentrale Komponente der Gesamtstruktur ist die Web-Datenbank. In ihr finden sich

die Workflow-Management-Umgebung und die erstellten Workflow-Dokumente mit

dem integrierten Ad-hoc-Workflow-Modeler. Wie in Abbildung 4-1 zu sehen,

kommuniziert die Web-Datenbank mit drei weiteren Domino Datenbanken; der

Organization Datenbank, der Addresses Datenbank und der Domino-Directory

Datenbank (Namens- und Addressbuch-Datenbank des Domino Servers). Bei der


Organization Datenbank handelt es sich um eine Datenbank der PAVONE Enterprise

Office Architektur, die Bestandteil des GroupProcess-Systems ist. Die Addresses

Datenbank ist eine Standard Domino Namens- und Adressbuch-Datenbank. Beide

Datenbanken beinhalten Organisationseinheiten, die im Ad-hoc-Workflow-Modeler für

die Modellierung der Ad-hoc-Prozesse benötigt werden. In der Adresses Datenbank

finden sich Personen und Arbeitsgruppen. In der Organization Datenbank findet sich

zusätzlich die Organisationseinheit Abteilung. Für einen Modellierungsabschnitt (quasi

ein Speichervorgang) kann immer nur eine der Datenbanken ausgewählt werden

(exklusives Oder). Die Kommunikation zwischen der Web-Datenbank und diesen

beiden Datenbanken ist unidirektional (Abbildung 4-1: Pfeil 2 und 3). Es werden

Organisationsdaten ausgelesen, jedoch nicht zurückgeschrieben.

Die dritte Datenbank stellt das Domino-Directory des Servers dar. Hier werden

sämtliche Personen, Gruppen und Server für Authentifizierungszwecke verwaltet.

Personen bzw. Workflow-Bearbeiter, die sich über die Workflow-Management-

Umgebung registriert haben, werden ebenfalls in dieser Datenbank gespeichert. Die

Kommunikation zwischen der Web-Datenbank und der Domino-Directory Datenbank

findet bidirektional statt (Abbildung 4-1: Pfeil 1). Schreibzugriffe auf das Domino-

Directory erfolgen beim Anlegen neuer Benutzer (User) oder bei der Veränderung

bestehender Benutzerdaten.

Die Workflow-Management-Umgebung befindet sich in der Web-Datenbank. Diese

Benutzungsschnittstelle ermöglicht die Kommunikation zwischen dem Benutzer und

dem GroupProcess-System bzw. zwischen dem Web-Browser und Domino. Wie in

Abbildung 4-1 Pfeil 4 angezeigt, findet bei der Modellierung, Ausführung und

Verwaltung der Workflows im Web ein Datentransfer zwischen dem Web-Browser und

Domino in beide Richtungen statt (Lese- und Schreibzugriffe).

4.2 Gestaltung und Funktionalität der Ad-hoc-Workflow-Applikation

In diesem Kapitel erfolgt zunächst in den Unterkapiteln 4.2.1 und 4.2.2 eine detaillierte

Beschreibung der Gestaltung, Funktionalität und des Dokumentenmanagements des

Systems. In den letzten drei Unterkapiteln 4.2.3 – 4.2.5 wird die Funktionsweise des

Ad-hoc-Workflow-Modelers in Phasen untergliedert und anhand eines Fallbeispiels

veranschaulicht. Die Darstellung erstreckt jeweils von der Konzeption bis zur

technischen Implementierung.


4.2.1 Usability der Benutzungsschnittstelle

Der Begriff Usability adressiert die Beziehung zwischen der Anwendung und deren

Benutzern. Damit eine Applikation effektiv sein kann, muss den Anwendern ermöglicht

werden, ihre Aufgaben auf dem bestmöglichen Weg auszuführen82. Grundsätzlich gilt

dieses Prinzip nicht nur für Computer, Websites und andere Software, sondern ist

allgemein für sämtliche Gebrauchsgegenstände (Kühlschränke, Autos, Fernseher etc.)

gültig. Eine gute Usability hängt von einer Anzahl von Faktoren ab. Sie umfasst die

Fragen, wie gut die Funktionalität des Systems zu den Anforderungen der Benutzer

passt, wie gut die Systemführung die Aufgaben der Benutzer unterstützt und wie sehr

das Antwortverhalten der Anwendung den Benutzererwartungen entspricht. Dabei

existieren für Web-Applikationen besondere Rahmenbedingungen, die berücksichtigt

werden müssen83:

• Wegen der globalen Dimension des Netzes und der weitreichenden demografi-

schen Verteilung der Internet-Benutzer kann eine genaue Zielgruppe nur sehr

schwer definiert werden.

• Stark abweichende Endbenutzerkonfigurationen (Hardware, Software, Browser,

Zugangsmöglichkeiten zum Internet und Netzbandbreite) bedeuten, dass Benut-

zer sehr unterschiedliche Erfahrungen und Eindrücke von der gleichen Web-

Applikation bekommen können.

• Die hohe Dynamik des World Wide Webs resultiert in kurzen Entwicklungszei-

ten und erschwert den Einsatz von benutzerorientierten Entwicklungstechniken.

• Anders als bei Softwarepaketen hat der Benutzer bei Web-Applikationen

normalerweise keine Investition vorgenommen und kann sehr einfach auf andere

Optionen zurückgreifen.

Der Entwurf eines Systems mit einer hohen Usability stellt einen Prozess dar, der

idealerweise die Benutzer miteinbezieht. Somit bezeichnet Usability die Qualität eines

Systems, das sich durch eine einfache Erlernbarkeit, Verwendung, sowie eine

Fehlerrobustheit und subjektives Gefallen auszeichnet.

82 Vgl. [Keil-Slawik 2000] 83 Vgl. [Murray/Costanzo 1999]


Aus der Perspektive des Benutzers ist die Usability wichtig, da sie darüber entscheidet,

ob eine Aufgabe genau und vollständig ausgeführt werden kann oder ob der Prozess bei

der Ausführung statt Zufriedenheit Frustration hervorruft. Aus der Perspektive des

Entwicklers kann die Usability den Unterschied zwischen Erfolg oder Misserfolg eines

Systems bedeuten. Vom Gesichtspunkt des Managements aus betrachtet kann Software

mit schlechter Usability die Produktivität eines Teams auf ein niedrigeres

Leistungsniveau bringen. In allen Fällen kann ein Mangel an Usability Zeit und

Arbeitseinsatz kosten und bestimmt dadurch in hohem Maße über den Erfolg eines

Systems.

Um für die im Rahmen dieser Arbeit entwickelte Benutzungsschnittstelle eine adäquate

Usability zu erhalten, wurden Aspekte der Software-Ergonomie umgesetzt.

Präsentation

Interaktion

Konvention Prägnanz Grafik Schrift Farbe

Strukturiertheit

Lokalität

Orientierbarkeit

Rückmeldungen

Eingabeminimalität

Beeinflussbarkeit

Ausführbarkeit

Anpassbarkeit

Flexibilität

Systemkonsistenz

Plattformkonformität

Aufgabenkonformität

Kulturelle Kohärenz

Tabelle 4-1: Kriterien zur Reduzierung erzwungener Sequenzialität84

Tabelle 4-1 zeigt den Strukturierungsansatz von Ergonomiekriterien nach Keil-

Slawik 85 , die bei der Entwicklung der vorliegenden Benutzungsschnittstelle (siehe

Abbildung 4-2) berücksichtigt wurden.

84 Erzwungene Sequenzialität bezeichnet den Sachverhalt, dass das System dem Benutzer bei der Ausführung der Aufgaben keinen Aktionsraum zur Verfügung stellt, sondern ihn durch systeminhären-te Vorgaben zu bestimmten Aktionsfolgen zwingt. Siehe [Keil-Slawik 2000]

85 [Keil-Slawik 2000]


Abbildung 4-2: GroupProcess im Web: Die Workflow-Management-Umgebung

Bei der Konzeption der Workflow-Management-Umgebung (Benutzungsschnittstelle)

wurde eine möglichst einfache und intuitiv bedienbare Lösung angestrebt. Auch

bestanden beim Design die Bestrebungen, durch eine einheitliche und harmonische

Komposition von Grafik, Farbe und Schrift ein gewisses look and feel zu erzeugen. Die

Benutzungsschnittstelle ist in zwei Bereiche unterteilt, um durch die Trennung von

Navigation und Inhalt eine strukturierte übersichtliche Benutzung zu gewährleisten.

Eine Ausnahme bildet die Maske mit dem Ad-hoc-Workflow-Modeler, die über den

gesamten Bildschirm dargestellt wird (siehe Abbildung 4-6), um eine größere

Arbeitsfläche für die Modellierung zur Verfügung zu stellen. Beim Aufruf der Startseite

der Workflow-Management-Umgebung werden in der Navigation zunächst nur vier

Links (Verweise) angeboten. Über den Link home wird die in Abbildung 4-2 zu

sehende Startseite aufgerufen und unter dem Link GroupProcess stehen Informationen

zum GroupProcess-Projekt zur Verfügung. Um die eigentliche Navigationsstruktur zu

aktivieren, muss sich der Benutzer über den Link login gegenüber dem System

authentifizieren. Für den Fall, dass noch kein Benutzerkonto existiert, besteht unter dem

Punkt registration die Möglichkeit, eins anzulegen.


Abbildung 4-3: Anlegen eines Benutzerkontos

Neben den Standardangaben wie Name, Email, Passwort etc. kann in der Benutzerre-

gistrierung zusätzlich ein Teamname angegeben werden. Durch diese Angabe wird die

Person als Mitglied dieses Teams gespeichert und kann anschließend in der Workflow-

Management-Umgebung den gemeinsamen Arbeitsbereich des Teams86 nutzen.

Abbildung 4-4: Ändern der Benutzerdaten

86 Eine Erläuterung des Arbeitsbereiches sowie die Abgrenzung des Begriffs Team erfolgt in Kapitel 4.2.2


Sobald der Benutzer im System eingeloggt ist, wird im Navigator der Zugriff auf

weitere Einträge freigegeben (siehe Abbildung 4-4). Es handelt sich dabei um

verschiedene Ansichten, sowie um die beiden Links create workflow und user data. Die

Funktion und der Inhalt der einzelnen Ansichten werden im nächsten Kapitel

ausführlich beschrieben.

Über den Link user data hat der Benutzer die Möglichkeit, sich seine Benutzerdaten

anzeigen zu lassen und ggf. Modifikationen vorzunehmen. Es finden sich hier u.a.

Angaben zum Servernamen und zum Pfad der Organization und Addresses Datenbank,

die beim Anlegen eines neuen Benutzerkontos die Vorgabewerte der jeweiligen

Infrastruktur beinhalten. Diese können ebenfalls angepasst werden. Somit dient der

Link user data der Anpassbarkeit des Systems. Der Link create workflow ruft die

Maske zum Erstellen eines Workflows auf (Abbildung 4-5).

Modellierungs- und Visualisierungsbereich

Organisations-navigator

Funktionsknöpfe 1

Ad-hoc-Workflow-Modeler

Funktionsknöpfe 2

Maske

Abbildung 4-5: Aufbau der Ad-hoc-Workflow-Modeler-Maske

In dieser Maske ist der Ad-hoc-Workflow-Modeler eingebettet. Der Ad-hoc-Workflow-

Modeler selbst lässt sich in den Modellierungs- und Visualisierungsbereich, den

Organisationsnavigator und der Icon-Leiste „Funktionsknöpfen 1“ unterteilen. Mit

diesem Modellierungswerkzeug können ablauf- und aufbauorganisatorische

Bestandteile eines Ad-hoc-Workflows mit Drag&Drop-Techniken erzeugt werden. Die

Modellierung des Prozessgraphens erfolgt analog zu der von den vordefinierten


Workflows her bekannten graphischen Erzeugung von Prozessmodellen. Um die

Zuordnung von Personen zu Vorgängen möglichst einfach zu gestalten, werden im

Organisationsnavigator die Portraitbilder der Personen angezeigt. Bei der Modellierung

können diese Personen dann per Drag&Drop den Vorgängen zugeordnet werden.

Weiterhin sind in der Maske zwei Eingabefelder und die Button-Leiste „Funktionsknöp-

fe 2“ enthalten. In den Feldern kann der Titel des Workflows und ein Kommentar

eingegeben werden. Die Button-Leiste beinhaltet die Bearbeitungsfunktionen

(Speichern, Kopieren, Löschen) für das Dokument, in dem der Workflow gespeichert

wird.

Beim Design der Maske wurde Wert auf eine gute Strukturiertheit und Orientierbarkeit

gelegt. Sämtliche Elemente sind strukturiert angeordnet und befinden sich auf einer

Bildschirmseite. Dadurch wird die Maske für den Benutzer überschaubar. Um die

Bedienbarkeit zu vereinfachen, werden in der Maske die Funktionsknöpfe

kontextabhängig aktiviert. Nur die Funktionen, die in dem jeweiligen Systemstatus

ausführbar sind, werden auch angezeigt. Des Weiteren erfolgt nach jeder Benutzerakti-

on eine Rückmeldung des Systems, damit der Benutzer das Systemverhalten besser

kontrollieren und nachvollziehen kann. Da, wo es sinnvoll ist, werden Handlungsalter-

nativen (Kriterium Ausführbarkeit aus Tabelle 4-1 ) angeboten, um dem Benutzer die

Steuerung der Systemausführung zu ermöglichen (siehe Abbildung 4-6).

Abbildung 4-6: Beispiele für Systeminteraktionen

Sämtliche Fehlermeldungen werden in der Workflow-Management-Umgebung

abgefangen und differenziert behandelt (Kriterium Rückmeldung aus Tabelle 4-1),

soweit es von Domino unterstützt wird. Es besteht nicht die Gefahr, dass das System

durch Fehlermeldungen des Domino Servers verlassen wird. Der Benutzer bleibt so


weiterhin in der gewohnten Arbeitsumgebung und kann entsprechend auf die Fehler

reagieren. Weiterhin ist durch die Architektur der Web-Applikation eine Installation

von Softwarekomponenten auf dem Client-Rechner nicht erforderlich. Dies unterstützt

die Systemkonsistenz87 und fördert somit die Akzeptanz seitens der Benutzer.

4.2.2 Dokumentenmanagement innerhalb der Benutzungsschnittstelle

In diesem Kapitel wird das Dokumentenmanagement der Benutzungsschnittstelle

aufgrund seiner Relevanz separat behandelt. In einer Web-basierten, verteilten

Ausführungs- und Kommunikationsplattform stellt die Verwaltung der zahlreichen

Dokumente eine besondere Herausforderung dar. Eine Grundvoraussetzung für eine

angemessene Usability der Anwendung sind geeignete Strukturen und Mechanismen für

das effiziente Verarbeiten, Ablegen und Wiederfinden der Dokumente. In der

vorliegenden Lösung wurden verschiedene Ansätze realisiert, um auf diese

Anforderungen zu reagieren. Die Basis stellen die fünf Ansichten im Navigator dar, die

einen differenzierten personenspezifischen Zugriff auf die Workflow-Dokumente

erlauben.

Abbildung 4-7: Die Ansichten der Workflow-Management-Umgebung

Die Ansichten übernehmen im Wesentlichen zwei Funktionen. Zum einen erfüllen sie

eine Navigationsfunktion und präsentieren den Dokumentenbestand der Datenbank, um

87 In Systemumgebungen, insbesondere in Unternehmen, ist oft die Installation von weiterer Software unerwünscht, um die Systemkonsistenz nicht zu beinträchtigen.


einzelne Workflow-Dokumente möglichst schnell und einfach wiederzufinden. Die

Inhalte der Ansichten lassen sich dynamisch generieren und können daher, wie in der

vorliegenden Benutzungsschnittstelle, ebenfalls zum Überwachen des Fortschritts

(Status) der einzelnen Workflows genutzt werden. Zum anderen wird durch die

Architektur der Ansichten der Zugriff auf den Dokumentenbestand gesteuert. Es wird

aus sicherheitstechnischer Sicht eine Art Zugriffskontrolle bzw. ein Filter realisiert88,

um die einzelnen Workflow-Dokumente nur den autorisierten Benutzern zugänglich zu

machen. In der vorliegenden Workflow-Management-Umgebung lassen sich die

Ansichten in persönliche Ansichten, gemeinsame Ansichten und in eine Administrati-

onsansicht untergliedern. Unter dem Eintrag my workflows sind zwei persönliche

Ansichten zu finden.

Abbildung 4-8: Die Ansicht designed

Die Ansicht designed listet alle Workflow-Dokumente auf, die vom aktuell

authentifizierten Benutzer erstellt wurden. Gemeint ist damit, dass die Workflow-

Dokumente vom aktuellen Benutzer neu angelegt wurden und dieser somit der Autor

der Dokumente ist89. Die Ansicht besitzt vier Spalten. Der angezeigte Dokumentenbe-

stand kann nach dem Inhalt jeder Spalte aufsteigend oder absteigend sortiert werden,

88 Ansichten stellen im eigentlichen Sinne kein Sicherheitskonzept dar. 89 In dieser Arbeit wird zwischen dem Autor und dem Initiator eines Workflow-Dokuments

unterschieden. Der Autor ist die Person, die ein Workflow-Dokument erzeugt. Der Initiator hingegen benutzt ein existierendes Workflow-Dokument und startet den darin enthaltenen Workflow. Dabei kann der Initiator auch ein eigenes Workflow-Dokument benutzen. In dem Fall ist dieser gleichzeitig der Autor.


um dem Benutzer eine gewisse Flexibilität bei der Nutzung der Ansicht zu bieten. Die

Spalte subject zeigt den Titel der Workflow-Dokumente an. Auf Wunsch lassen sich die

Workflow-Dokumente in dieser Spalte kategorisieren (siehe Abbildung 4-8). Hierfür

sind bei der Titeleingabe in der Maske die Kategorien durch ein Backslash-Zeichen

vom Dokumententitel zu trennen (z.B. GCC\2002\Korrektur\Diplomarbeit_HI). Die

Spalte status beinhaltet den aktuellen Bearbeitungsstatus der Workflows. Die beiden

letzten Spalten created und last read or edit weisen das Datum und die Uhrzeit aus, an

denen die Workflow-Dokumente erstellt und zum letzten Mal gelesen bzw. bearbeitet

wurden.

Abbildung 4-9: Die Ansicht involved

Die zweite Ansicht mit der Bezeichnung involved führt alle Dokumente der Workflows

auf, in denen der Benutzer involviert ist. Das können selbst erzeugte Workflows oder

Workflows anderer Personen sein, die diese Person als Workflow-Bearbeiter

eingetragen haben. Diese Ansicht besitzt zusätzlich zu den vier Spalten der ersten

Ansicht noch die Spalte current editor und team. In der Spalte current editor werden

die Workflow-Dokumente nach den Personen kategorisiert, die diese zuletzt bearbeitet

haben. Die Spalte team zeigt den Teamnamen der Person an, die den Workflow

initialisiert hat. Die Ansicht involved gibt dem Benutzer einen Überblick über alle

offenen Arbeitsprozesse und kann somit als eine Art Arbeitsplan (To Do Liste)

angesehen werden. Analog zur Ansicht designed kann hier eine Sortierung der

Dokumente nach den verschiedenen Inhalten vorgenommen werden.

Als Nächstes folgen in der Navigation unter dem Eintrag all workflows mit team und

archive die gemeinsamen Ansichten.


Abbildung 4-10: Die Ansicht team

Bevor auf die Abbildung 4-10 eingegangen wird, soll die Verwendung der Begriffe

Arbeitsgruppe und Team im Rahmen dieser Arbeit von einander abgegrenzt werden.

Unter einer Arbeitsgruppe wird die in der PAVONE Organization Datenbank

verwaltete Entität verstanden. Es handelt sich um eine Organisationseinheit, die als

solche explizit in der Organization Datenbank angelegt werden muss. Ein Team

bezeichnet hingegen eine Gruppe, die lediglich durch einen gleichen Eintrag im Feld

team des Benutzerkontos (siehe Abbildung 4-3 in Kapitel 4.2.1) entsteht. Somit wird

unter dem Begriff Team keine organisationstheoretische Entität verstanden, sondern

inhaltlich ein in sich abgeschlossener, gemeinsamer Arbeitsraum 90 für die

Teammitglieder. Durch die Unterstützung des Teamkonzepts in der Workflow-

Management-Umgebung wird den Benutzern die Möglichkeit an die Hand gegeben

spontan, flexibel und selbstverwaltend eine Gruppenbildung vorzunehmen.

Die Ansicht team in Abbildung 4-10 zeigt ausschließlich die Workflow-Dokumente

eines Teams an. Sämtliche Dokumente in der Ansicht wurden von Personen erzeugt

(genauer initialisiert), die Mitglieder im Team des aktuellen Benutzers sind. Bei der

Ansicht team kommen die beiden Spalten initiator und involved hinzu. Die erste Spalte

beinhaltet den Initiator eines Workflows. Die Spalte involved zeigt an, ob der aktuelle

Benutzer in dem Workflow involviert ist. Ein Benutzer ist in einem Workflow

involviert, sobald dieser in einem Workflow-Vorgang als Bearbeiter eingetragen wird.

90 Der Arbeitsraum wird über die Ansicht team realisiert.


Abbildung 4-11: Die Ansicht archive

Die gemeinsame Ansicht archive listet alle Workflow-Dokumente der Datenbank auf,

die bereits abgeschlossen sind. Dabei werden die Dokumente nach dem Initiator

kategorisiert und in der Spalte end das Datum angezeigt, an dem die Workflows beendet

wurden. Diese Ansicht wurde konzipiert, um Aspekte aus dem Bereich Knowledge

Management umzusetzen. Im operativen Einsatz sammelt sich mit der Zeit in der

Datenbank ein wachsendes Depot von Workflow-Dokumenten an, die die in der

Organisation angefallenen Ad-hoc-Prozesse abbilden. Diese Workflows können als

Schablonen für die Ausführung zukünftiger Ad-hoc-Prozesse genutzt werden. Sie lassen

sich neu initiieren und starten. Während der Ausführung können dann ggf. Anpassungen

ad hoc vorgenommen werden. Diese Vorgehensweise spart Zeit und Arbeit bei der

Prozessmodellierung. Weit wichtiger ist die Möglichkeit, diese Ad-hoc-Workflows

analysieren zu können, um daraus explizites Wissen zu generieren. Dieses Wissen kann

für die Konzeption neuer Prozesse genutzt werden. Bedingt durch den Sinn und Zweck

dieser Ansicht wird sie dem allgemeinen Benutzerkreis im Navigator nicht angezeigt.

Um diese Zugangsbeschränkung zu realisieren, wird mit einem Rollenkonzept

gearbeitet. Einzelne Personen oder Gruppen können durch die Zuordnung der Rolle

KnowledgeOffice durch den Administrator Zugriff auf diese Ansicht erhalten.


Abbildung 4-12: Die Ansicht administration

Die Ansicht administration ist für die zentrale Pflege des Dokumentenbestandes

gedacht. Sie zeigt sämtliche Workflow-Dokumente der Datenbank an. Der

Administrator der Datenbank kann die Dokumente öffnen und ggf. löschen. Um ein

oder mehrere Dokumente zu löschen, müssen diese selektiert (siehe Abbildung 4-12)

und über die Funktion move to trash (oberhalb der Ansicht) als zu löschen markiert

werden. Über die Funktion empty trash wird der Vorgang abgeschlossen und die

Workflow-Dokumente endgültig gelöscht. Diese Ansicht steht nur Personen zur

Verfügung, welche die Rolle administrator besitzen. Unabhängig von der Ansicht

administration haben auch die einzelnen Benutzer die Möglichkeit, ihre Workflow-

Dokumente zu löschen. Innerhalb der Workflow-Dokumente kann der Funktionsknopf

delete document benutzt werden, um das geöffnete Workflow-Dokument zu löschen.

Der Funktionsknopf wird nur angezeigt, wenn es sich nicht um ein neues Workflow-

Dokument handelt und der Benutzer der Autor ist.


Abbildung 4-13: Suchfunktionalität der Ansichten

In einer Umgebung mit einem großen Bestand an Dokumenten ist es wichtig, Techniken

anzubieten, die ein einfaches Wiederfinden der gewünschten Dokumente erlauben. Ein

manuelles Durchforsten des Dokumentenbestandes ist sehr zeitintensiv und nur

eingeschränkt möglich. In der Workflow-Management-Umgebung kann in allen

Ansichten über die Verknüpfung search eine Suchfunktion aufgerufen werden. Die in

Abbildung 4-12 dargestellte Suchmaske bietet eine schnelle und flexible Suche nach

einem oder mehreren Stichworten innerhalb einer Ansicht. Eine Konfiguration des

Suchverfahrens und dessen Ergebnisliste ist ebenso möglich. Diese Suchfunktionalität

wird von der Groupware-Umgebung zur Verfügung gestellt und wurde in dem

umgesetzten Prototyp integriert.

Somit lassen sich in der Workflow-Management-Umgebung folgende Aspekte des

Dokumentenmanagements festhalten:

• Differenzierte Ansichten auf den Workflow-Dokumentenbestand

• Unterstützung eines abgegrenzten Arbeitsbereiches mit den Workflow-

Dokumenten der jeweiligen Teams

• Unterstützung der Workflow-Dokumenten-Administration

• Flexible Suchfunktionalität für den Workflow-Dokumentenbestand

• Rollenkonzept mit verschiedenen Benutzerebenen als Zugangssteuerung für den

Workflow-Dokumentenbestand


4.2.3 Phase 1: Initialisierung des Ad-hoc-Workflow-Modelers

Bevor der Ad-hoc-Workflow-Modeler für die Modellierung der Prozesse genutzt

werden kann, ist eine Initialisierung notwendig. Bei diesem Initialisierungsvorgang

werden die Daten der Organisationseinheiten aus der Organization oder Addresses

Datenbank ausgelesen (siehe Abbildung 4-1), um sie im Organisationsnavigator

darstellen zu können (siehe Abbildung 4-5). Hierbei tritt eine technologische

Problemstellung auf. Es müssen Daten verschiedener Datentypen (Text und Grafik) aus

einer Lotus Notes/ Domino Datenbank in das Web-WorkflowModeler-Applet

transferiert werden. Die Erarbeitung eines Lösungskonzepts für diese Aufgabe und

dessen Umsetzung sind ein wesentlicher Bestandteil der vorliegenden Arbeit und

werden in diesem Kapitel erläutert.

Import der

Organisations-daten als

XML-String

XML-String

parsen Applet

Initialisierung

Darstellung im

Organisations- navigator

Abbildung 4-14: Initialisierungsvorgang des Ad-hoc-Workflow-Modelers

Abbildung 5-14 visualisiert den umgesetzten Lösungsansatz. Bei der Initialisierung

schickt das Web-WorkflowModeler-Applet zunächst eine Anfrage (Request) über das

URL-Kommando91 readViewEntries an den Domino Server. Für jede Organisations-

einheit wurde eine Ansicht entwickelt, die alle für die Darstellung im Organisationsna-

vigator notwendigen Daten enthält.

Abbildung 4-15: Beispiel für eine Ansicht mit den Organisationsdaten von Personen

91 Für eine ausführliche Behandlung der URL-Kommandos siehe [Lotus Dev. 1999]


Mit dem Request wird der Server veranlasst, eine Repräsentation der Ansicht in Form

einer XML-Zeichenkette zu generieren, wie sie in Abbildung 4-16 zu sehen ist. Das

Ergebnis wird an das Web-WorkflowModeler-Applet übermittelt.

Abbildung 4-16: Beispiel für die XML-Repräsentation einer Ansicht mit Personendaten

Die Portraitbilder der Organisationseinheiten sind Grafiken (Bitmaps) und lassen sich

nicht ohne weiteres als XML-Zeichenkette abbilden. Dieses Problem wird gelöst, indem

nicht die Grafikdateien übermittelt werden, sondern deren Pfadangaben (siehe letzten

Eintrag unter dem Tag <text> in Abbildung 4-16). Dieser ist ebenfalls vom Datentyp

Text und lässt sich somit problemlos in XML abbilden. Nachdem die XML-

Zeichenkette eingelesen wurde, kann sie im Web-WorkflowModeler-Applet von dem

implementierten XML-Parser 92 analysiert werden, um aus der Zeichenkette die

einzelnen Daten für die Weiterverarbeitung zu extrahieren. Im letzten Schritt des

Initialisierungsvorgangs werden die aufbereiteten Daten aus der XML-Zeichenkette im

Organisationsnavigator angezeigt.

4.2.4 Phase 2: Modellierung und Ausführung von Ad-hoc-Workflows

Nach Abschluss des Initialisierungsvorgangs steht der Ad-hoc-Workflow-Modeler für

die Modellierung und Ausführung von Ad-hoc-Prozessen zur Verfügung. Die

Funktionsweise des Prototyps wird im folgenden zum besseren Verständnis schrittweise

92 Die XML-Parser Klassen werden im Abschnitt 4.3.1 erläutert.


anhand eines überschaubaren Fallbeispiels dargestellt. Hierfür wird ein Prozess „Poster

Presentation“ modelliert, der die Fertigstellung einer Lehrstuhlpräsentation abbildet.

Workflow-Kante

Workflow-Knoten

Complete current task

Abbildung 4-17: Erster Abschnitt der Ad-hoc-Prozessmodellierung

In Abbildung 4-17 ist der erste Modellierungsschritt des Beispielprozesses zu sehen. In

diesem Beispiel initiiert Person LN den Workflow und bestimmt die Person CH als

Vorgangsbearbeiter für den nächsten Workflow-Knoten93 mit der Bezeichnung manage

job. An dieser Stelle beendet die Person LN die Modellierung. Die Gründe können z.B.

sein, dass die weitere Prozessmodellierung an Person CH delegiert werden soll oder

dass der Person LN zu diesem Zeitpunkt nicht hinreichend Informationen für eine

weitere Modellierung vorliegen. Sobald die Person LN ihren Vorgang Poster

Presentation als beendet markiert (siehe Abbildung 4-17, Funktionsknopf Complete

current task), wird dieses mit einem Häkchen angezeigt und der nächste Workflow-

Knoten aktiviert. Gleichzeitig wird der Bearbeiter CH per Mail 94 darüber

benachrichtigt, dass er der nächste Vorgangsbearbeiter ist. In den Ansichten der

Workflow-Management-Umgebung wird dieser Sachverhalt folgendermaßen

abgebildet. Nachdem Person LN den Workflow abgespeichert und initiiert hat, erscheint

das Workflow-Dokument jeweils in seinen Ansichten designed, involved und team mit

dem Status In Process. Die Person CH bekommt das Workflow-Dokument zu diesem

Zeitpunkt nur in der Ansicht team zu sehen95. Sobald der Vorgang abgeschlossen wird,

93 Aus Prozesssicht bildet ein Workflow-Knoten jeweils einen Prozessvorgang ab. 94 Die Benachrichtigung per Mail ist optional und kann durch die Angabe einer Mailadresse bei der

Registrierung aktiviert werden. 95 Es wird davon ausgegangen, dass beide Personen im selben Team sind.


verschwindet das Workflow-Dokument bei Person LN aus der Ansicht involved und

taucht stattdessen in derselben Ansicht des neuen Vorgangsbearbeiters CH auf.

Abbildung 4-18: Zweiter Abschnitt der Ad-hoc-Modellierung

Bei der weiteren Modellierung und Ausführung des Prozesses kommt es zu einer

Vorgangsteilung (Split). Person CH definiert die Aufgaben marketing presentation und

technical presentation und bestimmt die Personen JP und ML als deren Bearbeiter. An

dieser Stelle hat der Bearbeiter CH die Möglichkeit, seinen Vorgang abzuschliessen und

die weitere Modellierung und Ausführung den nächsten Vorgangsbearbeitern zu

überlassen. Aufgrund der Verantwortlichkeiten im Team und dem Wissen von Person

CH über den Gesamtprozess, modelliert dieser jedoch den Prozess im voraus

vollständig zu Ende.


Abbildung 4-19: Abschluss der Ad-hoc-Modellierung

Wie in Abbildung 4-19 zu sehen, erfolgt nach der Vorgangsteilung bei der Person CH

wieder eine Vorgangszusammenfassung (Merge) und eine abschliessende Weiterleitung

der Aufgabe zu der Person HN. Der endgültige Prozessgraph visualisiert die

Ablaufstruktur des Gesamtprozesses „Poster Presentation“. Mit dem Abschluss der

Modellierung hat der Workflow-Bearbeiter CH seine aktuelle Aufgabe abgeschlossen

und beendet daher den Vorgang manage job. Dadurch werden die beiden folgenden

Workflow-Knoten aktiviert und die Bearbeiter per Mail benachrichtigt. Zu diesem

Zeitpunkt ist das Workflow-Dokument bei der Person CH nur noch in der Ansicht team

zu sehen. Bei den beiden Bearbeitern JP und ML findet es sich zusätzlich in der Ansicht

involved wieder. Um die durchgeführte Vorgangsteilung anzuzeigen, wird der

Workflow-Status von der Engine auf den Wert SplitArchive gesetzt. Die beiden

Vorgangsbearbeiter JP und ML erledigen ebenfalls ihre Aufgaben und markieren ihren

Vorgang anschließend als abgeschlossen. Alternativ haben sie als aktuelle Bearbeiter

die Möglichkeit, Ad-hoc-Modifikationen am Workflow vorzunehmen, falls dieses

erforderlich sein sollte. Durch die Weiterleitung zum Bearbeiter CH bekommt dieser

das Workflow-Dokument in der Ansicht involved erneut angezeigt. Bei den Personen JP

und ML verschwindet es hingegen aus der selbigen Ansicht. Der Status des Workflows

hat sich während der Weiterleitung zu Person CH zweimal verändert. Solange nur einer

der beiden Bearbeiter seinen Vorgang abgeschlossen hat, muss die Person CH auf den

Abschluss des zweiten Vorgangs warten. Der Status wird solange auf den Wert On Wait

gesetzt. Mit dem Abschluss des zweiten Vorgangs erhält der Workflow-Status den Wert

In Process. Erst jetzt kann auch die Person CH ihre Aufgabe Review erledigen. Mit dem


Abschluss des Vorgangs wird das Workflow-Dokument bei der Person CH aus der

Ansicht involved entfernt und beim letzten Bearbeiter HN in dieser Ansicht angezeigt.

Der Bearbeiter HN führt ebenfalls seine Aufgabe aus und markiert den Vorgang als

beendet. Wie jeder andere Bearbeiter hat auch die Person HN die Möglichkeit ggf.

Modifikationen am Workflow vorzunehmen. Es ist z.B. denkbar, dass Person HN den

Workflow um einen weiteren Vorgang erweitert, da vor dem Druck Informationen über

Stückzahlen und Preise der Poster von einer anderen Person eingeholt werden sollen.

Sobald der letzte modellierte Vorgang abgeschlossen wird, bekommt der jeweilige

Bearbeiter vom System eine Rückmeldung mit der Frage, ob der Workflow

weitergestaltet oder abgeschlossen werden soll. Im vorliegenden Fallbeispiel

entscheidet sich die Person HN für die Beendigung des Workflows und gibt dieses dem

System entsprechend an. Dadurch wird das Workflow-Dokument aus der Ansicht

involved des Bearbeiters HN entfernt und findet sich abschließend in der Ansicht

archive mit dem Status completed.

Parallel zu der Darstellung in den anderen Ansichten wird das Workflow-Dokument

vom Zeitpunkt der Initialisierung bis zum Abschluss in der Ansicht administration

unter den wechselnden Bearbeitern geführt.

4.2.5 Phase 3: Rückspeicherung einer modifizierten Workflow-Struktur

Sobald ein Vorgang von einem Bearbeiter beendet wird oder sonstige Veränderungen

am Workflow-Dokument vorgenommen werden, müssen diese Änderungen gespeichert

werden, um nicht beim Schließen des Workflow-Dokuments verloren zu gehen. Bei der

Speicherung ist zwischen zwei Arten von Daten zu unterscheiden. Zum einen handelt es

sich um Kontextdaten des Workflows wie dem Titel, dem Kommentar, dem Autor des

Workflow-Dokuments etc. Zum anderen geht es um die XML-Zeichenkette im

Dokumentenfeld wBody, die die Workflow-Struktur beinhaltet (siehe Kapitel 3.4). Im

ersten Fall wird bei der Rücksendung des Workflow-Dokuments an den Domino Server

die Speicherung der Kontextdaten automatisch durchgeführt. Eine weitere Behandlung

ist daher nicht notwendig. Das Verfahren für die Speicherung der Workflow-Struktur ist

in Abbildung 4-20 dokumentiert.


Änderungen in der Workflow-

Struktur ermitteln

Änderungen im Dokumenten-feld festhalten

Speichern des modifizierten Dokuments

Speicherung starten

Abbildung 4-20: Speicherungsvorgang der Workflow-Struktur

Beim Anstoß des Speicherungsvorgangs werden zunächst die Änderungen in der

Workflow-Struktur ermittelt. Dazu wird über JavaScript eine Java-Funktion aufgerufen,

die die aktuelle Struktur des Workflows als XML-Zeichenkette zurückliefert.

Ermöglicht wird diese Verfahrensweise durch den Standard LiveConnect96, welcher von

Domino unterstützt wird. Um die Änderungen festzuhalten, wird die alte XML-

Zeichenkette im Feld wBody durch die neue ersetzt. Anschließend findet analog zu der

Speicherung der Kontextdaten die eigentliche Speicherung der Workflow-Struktur im

Dokument statt.

4.3 Spezielle technische Aspekte des Prototyps

4.3.1 Klassenhierarchie der Web-Variante des Ad-hoc-Workflow-Modelers

In diesem Kapitel wird die Web-Klassenhierarchie des Ad-hoc-Workflow-Modelers

behandelt. Die entwickelten Java-Klassen dienen der Verarbeitung der XML-

Zeichenketten aus den Domino Datenbanken. Sämtliche Klassen, die direkt an diesem

Prozess beteiligt sind, finden sich in dem Java Package readNotesData (siehe

Abbildung 4-21).

96 LiveConnect ist ein Standard für die Verbindung von HTML-Elementen, Java und JavaScript und eignet sich insbesondere für die Kommunikation mit Java Applets via JavaScript.


Abbildung 4-21: Struktur der Web-Klassenhierarchie

In der Abbildung werden die Klassen hervorgehoben, die im Rahmen dieser Arbeit

entwickelt wurden. Die drei Klassen NamesData, NamesGroupHandler und

NamesPersonHandler verarbeiten die Daten aus der Addresses Datenbank. Wie in

Kapitel 4.2.4 Abbildung 4-14 beschrieben, werden zunächst die Daten der

Organisationseinheiten (Personen und Gruppen) aus den speziellen Ansichten der

Addresses Datenbank als XML-Zeichenkette eingelesen. Diese Aufgabe übernimmt die

Klasse NamesData. Anschließend wird die gegebene XML-Zeichenkette geparst.

Grundsätzlich können dafür SAX- oder DOM-Parser eingesetzt werden. In dieser

prototypischen Implementierung wird im Wesentlichen aufgrund der höheren

Verarbeitungsgeschwindigkeit ein SAX-Parser verwendet97. Der Parser analysiert die

XML-Zeichenkette und erlaubt, auf bestimmte Elemente innerhalb der Zeichenkette zu

reagieren. In der vorliegenden Lösung besteht diese Reaktion in der Zuordnung der

gewonnenen Einzelwerte wie Vorname, Nachname etc. zu den jeweiligen Objekten

einer Organisationseinheit. Das Parsen der XML-Zeichenkette übernimmt bei den

Personendaten die Klasse NamesPersonHandler und bei den Daten der Arbeitsgruppen

die Klasse NamesGroupHandler.

97 Vgl. [Sosnoski 2002] S.2 ff.


Die Verarbeitung der XML-Zeichenketten aus der Organization Datenbank erfolgt

analog. Hierfür werden die Klassen OrganizationData, OrganizationPersonHandler,

OrganizationGroupHandler und OrganizationUnitHandler eingesetzt. Für die

Organization Datenbank steht eine Klasse mehr zur Verfügung, da hier zusätzlich die

organisatorische Einheit Abteilung zu verarbeiten ist.

4.3.2 Sicherheitsaspekte der GroupProcess Web-Applikation

Der Begriff Sicherheit ist sehr vielschichtig und kann im Rahmen dieser Arbeit nicht

umfassend behandelt werden. Der Fokus dieser Arbeit liegt bei der Datensicherheit98 in

einer Web-Applikation. Die Datensicherheit umfasst alle Maßnahmen und

Einrichtungen, die Daten vor Beeinträchtigung durch Verlust, Zerstörung oder

Verfälschung bewahren. In dieser Arbeit werden der Zugang zum System und eine

differenzierte Zugriffskontrolle für den Datenbestand einer Web-Applikation als

besonders relevant betrachtet. Daher wurden aus dem Bereich Datensicherheit

insbesondere die Aspekte Authentifizierung und Autorisierung berücksichtigt99.

Bei der Authentifizierung muss sich der Benutzer als die Person ausweisen, die er

vorgibt zu sein. Eines der hierfür meist eingesetzten Techniken sind Login-Verfahren.

Der Benutzer gibt einen registrierten Namen an und weist sich durch die Eingabe des

Passwortes als diese Person aus. In der vorliegenden Lösung wird ebenfalls ein

derartiges Verfahren eingesetzt, das von der Groupware-Plattform bereitgestellt wird.

98 Der Begriff Datensicherheit wird analog zur DIN 44 300, Teil 1 verwendet. 99 Vgl. [WfMC 1998b] und [Bertino/Carminati/Ferrari 1999] S.44 ff.


Abbildung 4-22: Login als Authentifizierungstechnik

Durch die erfolgreiche Authentifizierung erhält der Benutzer Zugriff auf die Navigation

und somit auf den Inhalt der Workflow-Management-Umgebung. Durch die

Identifizierung des Benutzers im System kann der Autorisierungsmechanismus greifen.

In der Workflow-Management-Umgebung wird ein Rollenkonzept eingesetzt, mit dem

drei Benutzerebenen differenziert werden. Dieser Mechanismus regelt über die

Ansichten den Zugriff auf den Dokumentenbestand. So sind die beiden Ansichten

archive und administration ausschließlich für Benutzer sichtbar, die über die Rolle

KnowledgeOffice bzw. Administrator verfügen. Weiterhin ist jeder Benutzer innerhalb

der Ansicht team autorisiert, nur die Dokumente seines Teams einzusehen. In einem

Workflow-Dokument liegen ebenfalls Zugriffsbeschränkungen vor. Der Benutzer hat

nicht die Möglichkeit, jedes Workflow-Dokument, das er öffnen darf, auch zu löschen.

Außer dem Autor ist das Löschen des Workflow-Dokuments nur dem Administrator der

Workflow-Management-Umgebung erlaubt. Letzterer ist berechtigt, über die Ansicht

administration jedes Workflow-Dokument zu öffnen, zu bearbeiten und zu löschen.

4.3.3 Performance Betrachtung

Bei der Entwicklung einer Web-Applikation sollte der Performance eine besondere

Aufmerksamkeit geschenkt werden. Zur Zeit nutzen die meisten Web-Benutzer noch

Modems für den Internetzugang, die nur relativ geringe Übertragungsraten (max. 56

KB/s) erlauben. Aus diesem Grund ist die Akzeptanz einer Web-Anwendung


entscheidend von ihren Lade- und Verarbeitungszeiten abhängig. Lange Wartezeiten

kann und will man selten tolerieren.

Vor diesem Hintergrund ist in der vorliegenden Arbeit die Performance ausschlagge-

bend bei der Konzeption des Prototyps gewesen. Sie begründet u.a. die Entscheidung

für den Einsatz der Technologie XML für den Datentransfer. Des Weiteren wurde in der

Workflow-Management-Umgebung aus Gründen der Performance auf den Einsatz von

aufwendigen Grafiken, Audiodateien und Animationen verzichtet. Durch den Einsatz

eines Framesets100 werden bei Aktionen nur der jeweilige Teilbereich des Bildschirms

aktualisiert. Das spart ebenfalls Ladezeit. Weiterhin wurde weitgehend auf die Nutzung

von zusätzlichen Java-Code verzichtet. Die Groupware-Umgebung bietet die

Möglichkeit, bei der Entwicklung einer Applikation verschiedene Java-Applets zu

nutzen. Diese bieten eine höhere Funktionalität, erfordern jedoch längere Ladezeiten.

Aus diesem Grunde werden in der Workflow-Management-Umgebung diese Java-

Applets ausschließlich in der Ansicht administration verwendet, da hier die

Funktionalität eine Nutzung erforderlich macht. Die Maske mit dem integrierten Ad-

hoc-Workflow-Modeler ist so strukturiert, dass alle Elemente auf einer Seite

untergebracht werden können. Dadurch entfällt das Nachladen von Elementen, die sonst

auf der aktuellen Seite nicht verfügbar wären.

Um das Resultat dieser Ansätze in der praktischen Anwendung zu überprüfen, wurden

Performance-Messungen am Prototyp durchgeführt. Die Ergebnisse der Verarbeitungs-

geschwindigkeit des Web-basierten Ad-hoc-Workflow-Management-Systems in

Abhängigkeit von den verschiedenen Zugangstechniken für das Internet sind in Tabelle

4-2 festgehalten.

100 Ein Frameset ist ein Designelement der Domino Datenbanken und erlaubt die Einteilung des Bildschirms in mehrere unabhängige Bereiche.


ErstinitialisieZweitinitialisiSpeicherung

n

Tabelle 4-2: Ver

Bei der Messung w

bezeichnet das erstmali

Web Browser-Sitzung.

Workflow-Modeler inn

Weiterhin wurde der

betrachtet.

Wie erwartet finden

Erstinitialisierung bean

DSL-Zugang beanspru

Zeitdauer, die die beide

der Erstinitialisierung m

die Zeiten für die Erst

des Ad-hoc-Workflow-

hier die Zeiten für ein

Client und Server wäh

Dieser Sachverhalt wür

5 Sekunden wesentlich

zwei Gründen. Erstens

mit 35 Sekunden akzep

101 Das Routing bezeichnet

Sekunde

00:00

00:07

00:14

00:21

00:28

00:36

rung 00:35 00:30 00:05erung 00:15 00:04 00:02svorgang 00:10 00:02 00:01

Modem 56 kBit/s

DSL 1 Mbit/s

Netzwerk 100 Mbit/s

arbeitungszeiten in Abhängigkeit von den Zugangstechniken

urden drei Vorgänge unterschieden. Die Erstinitialisierung

ge Initialisieren des Ad-hoc-Workflow-Modelers während einer

Jedes weitere Öffnen der Maske mit dem integrierten Ad-hoc-

erhalb einer Sitzung stellt hingegen eine Zweitinitialisierung dar.

Speicherungsvorgang eines Workflow-Dokuments separat

sich beim Modem die längsten Verarbeitungszeiten. Die

sprucht mit 35 Sekunden deutlich die meiste Zeit. Selbst beim

cht die Erstinitialisierung mit 30 Sekunden ein Vielfaches der

n anderen Vorgänge benötigen. Durch den Vergleich der Zeiten

it denen der Zweitinitialisierung kann gefolgert werden, dass

initialisierung nicht auf die reine Übertragungsdauer (Volumen

Modelers) zurückzuführen sind. Vielmehr ist anzunehmen, dass

e einmalige „IP-Initialisierung“ für das Routing101 zwischen

rend der Web Browser-Sitzung deutlich zu Buche schlagen.

de auch erklären, warum die Erstinitialisierung im LAN mit nur

schneller statt findet. Das Ergebnis relativiert sich jedoch aus

ist die Zeitdauer für die Erstinitialisierung selbst beim Modem

tabel.

die Weiterleitung von Datenpaketen zwischen einzelnen Netzwerken.


Zweitens findet dieser Vorgang während der gesamten Web Browser-Sitzung

nur einmal statt und besitzt daher kaum eine quantitative Relevanz. Ausschlag-

gebend sind die Zeiten der Zweitinitialisierung und des Speicherungsvorgangs

Diese betragen bei allen Zugangstechniken nur ein Bruchteil der Erstinitialisierung

Selbst beim Modem laufen die Zweitinitialisierungen mit 15 Sekunden und die

Speicherungsvorgänge mit 10 Sekunden relativ zügig ab. Der realisierte Prototyp wurde

in erster Linie für eine Office-Umgebung entwickelt. Die hier vorherrschenden

Netzwerkstrukturen mit Übertragungsraten bis zu 100 Mbit/s benötigen für die

Erstinitialisierung gerade 5 Sekunden. Alle anderen Verarbeitungsvorgänge sind

innerhalb von 1-2 Sekunden beendet. Bei den Privatanschlüssen geht die technische

Entwicklung immer mehr in Richtung DSL. Mit dieser Zugangstechnik werden mit 4

Sekunden für die Zweitinitialisierung und 2 Sekunden für den Speicherungsvorgang

ähnliche Zeiten erreicht.

Die Ergebnisse der Messungen können als sehr zufriedenstellend bezeichnet werden.

Sie belegen die performante Einsatzmöglichkeit des realisierten Prototyps mit allen

Zugangstechniken. Das gilt insbesondere für die beiden relevanten Techniken DSL und

LAN.

5 Aktueller Implementierungsstand und Ausblick - 68 -

5 Aktueller Implementierungsstand und Ausblick

Der aktuelle Stand der Implementierung ermöglicht die Modellierung und

Visualisierung von Ad-hoc-Prozessen über einen Web-Browser im Sinne des

GroupProcess-Konzepts. Dazu wurden für die Web-basierte Lösung spezielle Java-

Klassen entwickelt. Diese ermöglichen den Einsatz der Organisationseinheiten im Ad-

hoc-Workflow-Modeler, ohne die Domino Java-Klassen zu benutzen. Weiterhin wurde

für die Verwaltung der Workflow-Dokumente eine Workflow-Management-Umgebung

entwickelt. Sie bietet über verschiedene Ansichten Navigations- und Administrations-

funktionalitäten. Die Benutzungsschnittstelle verfügt ebenfalls über einen

Authentifizierungs- und Autorisierungsmechanismus. Insgesamt konnte für den

realisierten Prototyp eine adäquate Usability und Performance erzielt werden.

Die im Rahmen dieser Arbeit gestellten Aufgaben konnten alle erfüllt werden. Dennoch

lassen sich weitere Ansätze finden, um die Funktionalität und Einsetzbarkeit des

Systems zu erweitern. Im Folgenden werden einige Ansatzpunkte genannt, die

insbesondere für den Web-basierten Prototypen sinnvoll erscheinen.

• Die in Kapitel 4.2.4 beschriebene Email-Benachrichtigung ist zwar angedacht,

die Implementierung steht jedoch noch aus.

• In der Groupware-Lösung kann für eine Aufgabe ein Enddatum angegeben

werden, bis zu dem der Workflow abzuschließen ist. Diese Möglichkeit sollte

auch für die Web-Lösung zur Verfügung stehen.

• Gerade in einer verteilten Office-Umgebung ist es sinnvoll, die Dringlichkeit

von Aufgaben mitteilen zu können. Dieses kann durch die Unterstützung von

Prioritätenangaben realisiert werden.

• Der Prototyp wurde auf Basis der Groupware-Plattform Lotus Notes/ Domino

R5 umgesetzt. Die aktuelle Version R6 bietet zusätzliche Möglichkeiten und

Funktionalitäten. Lotus Notes/ Domino R6 unterstützt z.B. den Einsatz der Java

Swing 102 -Klassen. Damit steht eine umfangreiche Funktionsbibliothek zur

Verfügung, die für die Weiterentwicklung des grafischen User Interfaces des

Ad-hoc-Workflow-Modelers genutzt werden kann.

102 Die Java Swing-Klassen dienen der Entwicklung von grafischen Benutzungsschnitten nach dem aktuellen Stand der Technik.

5 Aktueller Implementierungsstand und Ausblick - 69 -

• Der Prototyp wurde bisher nur für den Internet Explorer 5 optimiert. Anpassun-

gen und Tests für die ebenfalls verbreiteten Browser Netscape Navigator und

Opera sind zu empfehlen.

Bei der Implementierung dieser und anderer Funktionen muss bei einer Web-

Applikation immer zwischen Funktionalität, Bedienbarkeit und Performance

abgewogen werden.

Die in dieser Arbeit entwickelte Web-basierte Workflow-Management-Umgebung ist

als solche für die Integration anderer Applikationen geeignet. Eine Einsatzmöglichkeit

stellt z.B. der in Kapitel 3.3 genannte Lean Workflow Modeler103 dar. Dieser Prototyp

wurde ebenfalls im Rahmen des GroupProcess-Projekts für die Groupware-Umgebung

entwickelt. Durch die modulare Struktur der Workflow-Management-Umgebung ist es

möglich, den integrierten Ad-hoc-Workflow-Modeler gegen den Lean Workflow

Modeler auszutauschen. Die für den Datenaustausch entwickelte Lösung (XML-

Klassen) kann hier grundsätzlich ebenso verwendet werden. Damit würde dieser

Prototyp ebenfalls für eine Web-basierte Nutzung zur Verfügung stehen.

103 [Peter 2002]

6 Zusammenfassung - 70 -

6 Zusammenfassung Im Rahmen dieser Diplomarbeit ist das Web-basierte Ad-hoc-Workflow-Management-

System entstanden. Es ermöglicht eine plattformunabhängige, verteilte Modellierung

von Ad-hoc-Geschäftsprozessen über das Internet.

Zunächst wurden die Grundlagen und das technologische Umfeld der Arbeit behandelt.

Es wurden zentrale Termini der CSCW-Forschung abgegrenzt und relevante Aspekte

der Groupware-Umgebung Lotus Notes/ Domino sowie des Office- und Workflow-

Management-Systems PAVONE Enterprise Office vorgestellt. Darüber hinaus wurden

die eingesetzten Technologien für die Web-Entwicklung erläutert. Anschließend

wurden die Merkmale und Anforderungen eines Ad-hoc-Workflow-Management-

Systems anhand des GroupProcess-Konzepts thematisiert. Als Ausgangspunkt diente

das GroupProcess-Kontinuum, das die Einsatzbereiche von herkömmlichen WfMS und

Ad-hoc-WfMS abgrenzt. Darauf aufbauend wurden spezielle Ansätze des

GroupProcess-Konzepts vorgestellt. Es folgte dann die Erläuterung der GroupProcess-

Architektur und die Nennung möglicher Einsatzszenarien für das GroupProcess-

Konzept. Resultierend aus den gegebenen Anforderungen wurde die prototypische

Realisierung des Web-basierten Ad-hoc-Workflow-Management-Systems aufgezeigt.

Es wurde die angepasste Architektur des Systems erklärt und die Gestaltung und

Funktionalität der entwickelten Workflow-Management-Umgebung anhand eines

Fallbeispiels erläutert. Die Darstellung endete mit der Analyse spezieller technischer

Aspekte des Prototyps.

Im Rahmen dieser Arbeit wurde die Bedeutung von Ad-hoc-Prozessen und die

wachsende Relevanz einer Web-basierten Unterstützung hervorgehoben. Die verteilte

Prozessmodellierung durch alle Prozessbeteiligten wurde dabei als ein zentraler

Gesichtspunkt herausgearbeitet. Bisher waren die Mitarbeiter eines Unternehmens nur

in relativ geringer Intensität an der Prozessmodellierung beteiligt. Es war wegen

technischen und organisatorischen Schwierigkeiten sowie Kostengründen nicht

möglich, die Mitarbeiter mit entsprechenden Werkzeugen auszustatten. In der

vorliegenden Arbeit wurde eine Web-basierte Lösung erarbeitet, um die Unterstützung

für eine verteilte Prozessmodellierung durch das GroupProcess-System zu erweitern.

Die realisierte Lösung hat aufgrund der Interoperabilität und der guten

Verteilungsmöglichkeiten über das Inter- und Intranet das Potential, drastische

Einsparungen im Bereich der Wartungs- und Installationskosten zu erzielen. Insgesamt

erfüllt das GroupProcess Ad-hoc-Workflow-Management-System die Voraussetzungen

6 Zusammenfassung - 71 -

für einen verteilten organisationsweiten Einsatz und ermöglicht damit den im

GroupProzess-Konzept vertretenen Ansatz der Beteiligung aller Prozessbearbeiter

an der Prozessgestaltung.

7 Literaturverzeichnis - 72 -

7 Literaturverzeichnis

[Back/Seufert 2000] Back, Andrea; Seufert, Andreas; Computer Supported Cooperative Work (CSCW)- State-of-the-Art und zukünftige Herausforderungen, in: Praxis der Wirtschaftsinformatik, CSCW-Workflow und Groupware, 37. Jahrgang, Heft 213, Dpunkt Verlag, Juni 2000, S. 5-11.

[Bertino/Carminati/Ferrari 1999] Bertino, Elisa; Carminati, Barbara; Ferrari, Elena (1999): XML Security, in: Information Security Technical Report, Vol 6, No. 2, 2001, Elsevier Science Ltd, S. 44-58.

[Bornschein-Grass/Picot/Reichwald 1995] Bornschein-Grass, Carin; Picot, Arnold (Hrsg.); Reichwald, Ralf (Hrsg.): Groupware und computerunterstützte Zusammenarbeit - Wirkungsbereiche und Potentiale, Gabler Edition Wissenschaft, Wiesbaden, 1995.

[Erdmann 2001] Erdmann, Ingo: Konzeption und prototypische Realisierung eines generischen Werkzeugs zur graphischen Darstellung und dynamischen Modifikation von Datenobjekten in groupwarebasierten Systemumgebungen, Diplomarbeit, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsinformatik 2, Paderborn, 2001.

[Gray 1996] Gray, M. (1996): Internet Statistics – Growth and Usage of the Web and the Internet, aus: http://www.mit.edu/people/mkgray/net/printable/web-growth-summary.html/ aktuell am 10.04.2002.

[Greenberg 1991] Greenberg, Saul (Hrsg.): Computer-supported Cooperative Work and Groupware, Academic Press Ltd, London, 1991.

[Greif 1988] Greif, Irene: Computer-Supported Cooperative Work - A Book of Readings, Morgan Kaufmann Publishers, San Mateo, 1988.

[Han/Shim 2000] Han, Dongsoo; Shim, Jaeyong (2000): Connector-oriented Workflow System for the Support of Structured Ad hoc Workflow, in: Sprague, R. H. (Ed.): Proceedings of the 34th Hawaii International Conference on System Sciences, Maui, Hawaii, Paper (2000), School of Engineering, Information and Communications University, Korea, p. 2-3.

[Hasenkamp/Syring 1994] Hasenkamp, U.; Syring, M. (Hrsg.): CSCW - Computer Supported Cooperative Work: Informationssysteme für dezentralisierte Unternehmensstrukturen, Addison-Wesley, Bonn etc., 1994.

[Heflin/Hendler 2000] Heflin, Jeff; Hendler, James: Semantic Interoperability on the Web, Paper, University of Maryland, Maryland, 2000.


[Herrmann/Scheer/Weber 1998] Herrmann, Thomas; Scheer August-Wilhelm; Weber, Herbert (Hrsg.): Verbesserung von Geschäftsprozessen mit flexiblen Workflow-Management-Systemen 1: Von der Erhebung zum Sollkonzept, Veröffentlichungen des Forschungsprojekts MOVE, Physica-Verlag, Heidelberg, 1998.

[Hollingworth 1994] Hollingworth, David (1994): Workflow Management Coalition - The Workflow Reference Model, Version 1.1., Workflow Management Coalition, 1994, aus: http://www.aiai.ed.ac.uk/WfMC/ am 04.05.2002.

[Huth 1998] Huth, Carsten: Plattform- und werkzeugübergreifende verteilte Organisationsmo-dellierung für Workflow Management: Entwicklung einer Werkzeugunterstützung zur Modellierung von Organisationssubsystemen für die Arbeit verteilter Teams, Diplomarbeit, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsin-formatik 2, Paderborn, 1998.

[Huth 2000] Huth, Carsten: GroupProcess: Partizipative, verteilte Gestaltung und simultane Ausführung von Ad hoc Workflows: Eine Erweiterung eines Groupware-basierten Workflow-Management-Systems, Präsentation zum Doktorandenkolloquium, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsinformatik 2, Paderborn, Mai 2000.

[Huth 2002] Huth, Carsten: GroupProcess: Groupware-basiertes Ad-Hoc-Workflow-Management, Präsentation zum Doktorandenkolloquium, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsinformatik 2, Paderborn, April 2002.

[Huth/Erdmann/Nastansky 2001a] Huth, Carsten; Erdmann, Ingo; Nastansky, Ludwig: GroupProcess: Using Process Knowledge from the Practical Operation of Ad Hoc Processes for the Participative Design of Structured Workflows, in: Sprague, R. H. (Ed.): Proceedings of the 34th Hawaii International Conference on System Sciences, Maui, Hawaii, CD-ROM, Los Alamitos, Washington, Brussels, Tokyo, January 2001.

[Huth/Erdmann/Nastansky 2001b] Huth, Carsten; Erdmann, Ingo; Nastansky, Ludwig: Using Process Knowledge from the Practical Operation of Ad Hoc Processes for the Participative Design of Structured Workflows, in: Proceedings, Thirty-Fourth Annual Hawaii International Conference on System Sciences, January 2001.

[Huth/Nastansky 2000a] 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, Josef Eul Verlag, Lohmar, Oktober 2000.


[Huth/Nastansky 2000b] Huth, Carsten; Nastansky, Ludwig: GroupProcess: Partizipatives, verteiltes Design und simultane Ausführung von Ad hoc Geschäftsprozessen, in: Herrad Schmidt (Ed.): Modellierung betrieblicher Informationssysteme, Proceedings der MobIS-Fachtagung 2000, Rundbrief der GI-Fachgruppe 5.10, 7. Jahrgang, Heft 1, Universität Siegen, Siegen, Oktober 2000.

[Internet Software Consortium 2002] Internet Software Consortium (2002): Web Growth Summary, aus: http://www.isc.org/ds/ am 01.07.2002.

[Jost 2001] Enderle, Jost: XML in relationalen Datenbanken, in: Informatik Spektrum, Band 24, Heft 6, Dezember 2001, S.357-368.

[Keil-Slawik 2000] Keil-Slawik, Reinhard (2000): Software-Ergonomie, Universität Paderborn, Informatik und Gesellschaft, Paderborn, aus: http://iug.uni-paderborn.de/iug/lehre/ergonomie/ws0001 am 01.04.2002.

[Kobielus 1997] Kobielus, James G.: Workflow Strategies, IDG Books Worldwide, Foster City, 1997.

[Koch/Zielke 1996] Koch, Olaf G.; Zielke, Frank: Workflow Management: Prozessorientiertes Arbeiten mit der Unternehmens-DV, Markt&Technik, Haar bei München, 1996.

[Koulopoulos 1995] Koulopoulos, Thomas M.: The workflow imperative: building real world business solutions, Van Nostrand Reinhold, New York, 1995.

[Krüger 2000] Krüger, Guido(2000): Go to Java 2, 2. Auflage, aus: http://www.javabuch.de am 02.11.2001.

[Laumen/Leutnant 2001] Laumen, Andreas; Leutnant, Christian: Transformation Ad hoc Workflow to structured Workflow, GroupProcess-Projekt, Projektarbeit, Lehr- und Forschungs-einheit Wirtschaftsinformatik 2, Universität Paderborn, 2001.

[Lawrence 1997] Lawrence, Peter: Workflow Handbook 1997, John Wiley & Sons Ltd, Chichester, 1997.

[Lehmann 1999] Lehmann, Frank R.: Fachlicher Entwurf von Workflow-Management-Anwendungen, B.G.Teubner (Teubner-Reihe Wirtschaftsinformatik), Stuttgart, Leipzig, 1999.

[Lottor 2001] Lottor, M. (2001): Internet Software Consortium, source data: www.isc.com, aus: http://navigators.com/statall.gif am 01.05.2002.

[Lotus Dev. 1996] Lotus Development Corporation: Lotus Notes Release 4: In a Multiplatform Environment, Cambridge, Massachusetts, 1996.


[Lotus Dev. 1997] Lotus Development Corporation: Lotus Notes: An Enterprise Application Platform, SG24-4837-00, Cambrigde, Massachusetts, 1997.

[Lotus Dev. 1999] Lotus Development Coporation: Lotus Domino Release 5.0 - A Developer’s Handbook, Cambridge, Massachusetts, 1999.

[Macaulay 1995] Macaulay, Linda: Human-Computer Interaction for Software Designers, International Thomson Computer Press, London etc., 1995.

[Murray/Costanzo 1999] Murray, George; Costanzo, Tania: Usability and the Web: An Overview, Publication, Network Notes #61, National Library of Canada, Information Technology Services, Canada, 1999, aus: http://www.nlc-bnc.ca/9/1/p1-260-e.html am 12.06.2002.

[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/Fischer/ Herold/Dangelmaier/Suhl 2000] Nastansky, Ludwig; Fischer, Joachim; Herold, Werner; Dangelmaier, Wilhelm; Suhl, Leena: Bausteine der Wirtschaftsinformatik, 2. Auflage, Erich Schmidt Verlag, Berlin, 2000.

[Nastansky/Riempp/Hilpert/Ehlers 1996] Nastansky, Ludwig; Riempp, Gerold; Hilpert, Wolfgang; Ehlers, Peter: Analyse, Planung, operative Unterstützung und Optimierung von Geschäftsprozessen mit GroupFlow und GroupProject, Arbeitspapier, Vorabversion 23.4.96, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsinformatik 2, Paderborn, 1996.

[Needleman 1999] Needleman, Mark H.: XML, Report, Vol. 25, No.1. Data Research Associates, St. Louis, 1999.

[Niebiossa 2001] Niebiossa, Claudios: Konzeption und Entwicklung einer prototypischen Workflow-Engine für Groupware-basierte Ad-hoc-Workflows im Projektbereich GroupProcess, Diplomarbeit, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsin-formatik 2, Paderborn, 2001.

[OMG 2002] Object Management Group (2002): CORBA Basics, aus: http://www.omg.org/gettingstarted/corbafaq.htm am 10.07.2002.

[Ott 1996] Ott, Markus: Groupware Informationssysteme mit Internet/WWW Technologie: Anforderungen an ein universitäres World Wide Web Informationssystem basierend auf einem Groupware Informationsbestand, Projektgruppe Groupware und WWW, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsinformatik 2, Paderborn, 1996.


[Ott 1998]

Ott, Markus: Organization Design as a Groupware-supported Team Process - GroupOrga - Participative and Distributed Organization Design for Office Information and Workflow Management Systems, Dissertation, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsinformatik 2, Paderborn, 1998.

[PAVONE 2001] PAVONE AG (2001): PAVONE Enterprise Office Hilfe, Dokumentation, Version 5.5, aus: http://www.pavone.de/web/de/support/hilfe/es_hap_d.nsf am 12.05.2002.

[Peter 2002] Peter, Marion: GroupProcess-Modeler Light – Konzeption und prototypische Realisierung eines Modellierungs- und Ausführungswerkzeuges für Ad-hoc-Workflows, Diplomarbeit, Universität Paderborn, Lehr- und Forschungseinheit Wirtschaftsinformatik 2, Paderborn, 2002.

[Reich 1997] Reich, Siegfried: De Modo Operandi: Towards the interoperability of workflow information, Dissertationen, Universität Wien, Band 34, WUV-Universitätsverlag, Wien, 1997.

[Riempp 1998] Riempp, Gerold: Wide Area Workflow Management - Creating Partnerships for the 21st Century, Springer Verlag, Berlin, London etc., 1998.

[Poyssick/Hannaford 1996] Poyssick, Gary; Hannaford, Steve: Workflow Reengineering, Adobe Press, Mountain View California, 1996.

[Schael 1998] Schael, Thomas: Workflow Management Systems for Process Organisations, 2. Auflage, Springer, Berlin etc., 1998.

[Schröder 1997] Schröder, Ralf: Realisierung von Diensten zur Anpassung von Workflows während der Laufzeit, Diplomarbeit, Universität Stuttgart, Fakultät Informatik, Institut für Parallele und Verteilte Höchstleistungsrechner, 1997.

[Smolnik /Huth/ /Nastansky 2001] Smolnik, Stefan; Huth, Carsten; Nastansky, Ludwig: Distribution of Workflow Process Knowledge in Organizations, in: 2. Oldenburger Forum Wissensmanage-ment, Oldenburg, Aachen, Juni 2001.

[Sosnoski 2002] Sosnoski, Dennis M. (2002): XML documents on the run, Part 1, aus: http://www.javaworld.com/javaworld/jw-02-2002/jw-0208-xmljava_p.html am 02.06.2002.

[Stahlknecht/Hasenkamp 1997] Stahlknecht, P.; Hasenkamp, J: Einführung in die Wirtschaftsinformatik, Springer Verlag, 8. Auflage, Berlin, 1997.

[SUN 2002] SUN Microsystems (2002): Java Remote Method Invocation (RMI), aus: http://java.sun.com/products/jdk/rmi/ am 10.07.2002.


[Teufel 1996]

Teufel, Stefanie: Computerunterstützte Gruppenarbeit - eine Einführung, in: Österle, H.; Vogler, P. (Hrsg.): Praxis des Workflow Managements, Vieweg, Braunschweig, Wiesbaden, 1996, S. 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.

[Tolksdorf 2000] Tolksdorf, Robert: Coordinating Work on the Web with Workspaces, in: IEEE Computer Society, Press: Proceedings of the IEEE Ninth International Workshops on Enabling Technologies, Infrastructure for Collaborative Enterprises WET ICE, 2000.

[WfMC 1998a] Workflow Management Coalition (1998): Workflow and Internet: Catalysts for Radical Change, White Paper, aus: http://www.wfmc.org am 12.05.2002.

[WfMC 1998b] Workflow Management Coalition (1998): Workflow Security Considerations, White Paper, Issue 1.0, Document Number WFMC-TC-1019, aus: http://www.wfmc.org am 12.05.2002.

[WfMC 1999] Workflow Management Coalition (1999): Terminology & Glossary, White Paper, Issue 3.0, Document Number WFMC-TC-1011, aus: http://www.wfmc.org am 17.05.2002.

Anhang - 78 -

A.1 Herstellung der Einsatzbereitschaft des Prototyps

A.1.1 Systemvoraussetzungen und Installation

Für den in Kapitel 4 beschriebenen Prototypen sind an die Software gewisse

Mindestanforderungen zu stellen. Der Ad-hoc-Workflow-Modeler wurde in der Java

Version 1.1 erstellt. Für die Ausführung ist daher ein Internet-Browser nötig, der eine

Java Virtual Machine (JVM) enthält, die mindestens die Version 1.1 des Java-

Sprachstandards unterstützt. Geeignet ist insbesondere der Microsoft Internet Explorer

Version 5 oder höher104, da die Workflow-Management-Umgebung für diesen Web

Browser bereits getestet wurde. Des Weiteren ist die Groupware-Plattform Lotus/

Domino in der Version R5 oder höher erforderlich.

Zum Installationsumfang des Systems gehören folgende Lotus Notes/ Domino

Datenbanken:

• Web-Datenbank

• Domino-Directory Datenbank

• Organization Datenbank und/ oder Addresses Datenbank

Die Datenbanken müssen auf einem Domino Server verfügbar sein. Wird für

Testzwecke eine lokale Installation benötigt, so sind die Datenbanken im Notes Data-

Verzeichnis des Client-Rechners abzulegen.

A.1.2 Konfiguration

Im Folgenden werden die Einstellungen erläutert, die speziell für den Web-basierten

Prototyp vorzunehmen sind. Zwecks besserer Übersicht werden alle notwendigen

Konfigurationsschritte tabellarisch aufgeführt. Die linke Spalte der Tabelle enthält die

Stelle und die Art der Einstellung. In der rechten Spalte findet dazu eine nähere

Beschreibung statt. Der Inhalt der Parameter des Web-WorkflowModeler-Applets wird

entweder durch Textkonstanten oder durch den Einsatz von Formeln definiert. Die

zulässigen Eingaben für die Textkonstanten werden an der entsprechenden Stelle

aufgelistet. Formeln sind hingegen nicht angegeben, können jedoch bei Bedarf in dem

vorliegenden Prototyp nachgesehen werden.

104 Grundsätzlich kann der Prototyp ebenfalls mit dem Netscape Navigator oder mit dem im Lotus Notes in der Version R5 integrierten Internet Browser ausgeführt werden.

Anhang - 79 -

Parameter des Web-WorkflowModeler-Applets WebServerName Dieser Parameter enthält den Namen der Server Domain.

(z.B. „GCC.Uni-Paderborn.de“ oder „131.234.164.41“)

AppletType Dieser Parameter definiert die Umgebung, in der der Ad-hoc-

Workflow-Modeler ausgeführt wird.

Zulässiger Eingabewert (case sensitiv):

• „Web“

• „Notes“

DBType Dieser Parameter bestimmt aus welcher Datenbank die

Organisationseinheiten für die Darstellung im Navigationsbrowser

ausgelesen werden sollen.

Zulässiger Eingabewerte (case sensitiv):

• "NamesDB" (Addresses Datenbank)

• "OrgaDB" (Organization Datenbank)

OrgaDBServer

Dieser Parameter speichert den Namen des Servers, auf dem die

Organization Datenbank abgelegt ist. In der Regel ist es der gleiche

Server, auf dem auch die Web-Datenbank zu finden ist. Der Wert

wird aus dem Domino-Directory berechnet, wobei davon

ausgegangen wird, dass dieses den Standardnamen names.nsf

besitzt und im Stammverzeichnis des Servers abgelegt ist.

Ansonsten sind entsprechende Anpassungen der Formel notwendig.

Schlägt die Berechnung fehl, so wird auf einen Vorgabewert

zurückgegriffen. Dieser ist an die Infrastruktur anzupassen.

OrgaDBPath Dieser Parameter speichert den Pfad für die Organization

Datenbank. Es gelten die gleichen Annahmen und Regelungen, wie

für den Parameter OrgaDBServer.

AddressDBServer Dieser Parameter speichert den Namen des Servers, auf dem die

Addresses Datenbank abgelegt ist. Es gelten die gleichen Annahmen

und Regelungen wie für den Parameter OrgaDBServer

AddressDBPath Dieser Parameter speichert den Pfad für die Addresses Datenbank.

Es gelten die gleichen Annahmen und Regelungen wie für den

Parameter OrgaDBServer

OverwriteDBParam Dieser Parameter bestimmt die Reihenfolge in der die Datenbank-

pfade ausgelesen werden sollen. Die Priorisierung findet anhand

folgender Fallunterscheidung statt:

1. Parameter ist leer (OverwriteDBParam = „“)

1.1 Datenbankangaben aus der XML-Zeichenkette sind leer

Verwende Angaben aus den Applet-Parametern und

speichere nicht die Pfade.

Anhang - 80 -

1.2 Datenbankangaben aus der XML-Zeichenkette sind nicht leer

Verwende Pfade aus XML-Zeichenkette (und ignoriere

Datenbankangaben in den Applet-Parametern).

2. Parameter ist nicht leer

2.1 OverwriteDBParam = "force" Überschreibe Datenbankangaben aus der XML-

Zeichenkette mit den Datenbankangaben aus den Applet-

Parametern und verwende diese.

2.2 OverwriteDBParam = "if empty" Überschreibe Datenbankangaben aus der XML-

Zeichenkette nur dann mit Datenbankangaben aus den

Applet-Parametern, wenn die Datenbankangaben aus der

XML-Zeichenkette leer sind.

ACL-Einstellungen UserManager Diese Rolle ist für den Autorisierungsmechanismus notwendig. Der

Administrator der Web-Datenbank und der Domino Server

bekommen diese Rolle zugeteilt.

administrator Diese Rolle bestimmt den Administrator der Workflow-Management-

Umgebung. Personen, denen diese Rolle zugeteilt ist, bekommen im

Navigator der Workflow-Management-Umgebung zusätzlich die

Ansicht administration angezeigt.

KnowledgeOffice Diese Rolle aktiviert die View archiv im Navigator der Workflow-

Management-Umgebung. Für die Rolle müssen in der ACL der Web-

Datenbank zwei Gruppen angelegt werden:

• InKnowlegdeOffice

• OutKnowledgeOffice

Die Gruppe InKnowledgeOffice bekommt die Rolle KnowlegdeOffice

zugeteilt, die Gruppe OutKnowledgeOffice hingegen nicht.

Einstellungen in den Design-Elementen Datenbank:

Web-Datenbank

Maske: Appletform

Masken-Tag:

HTML Attributes

An dieser Stelle ist der Pfad der XML-Klassen nach dem folgenden

Schema anzugeben:

"archive=http://131.234.164.45/xml.jar"

Datenbank:

Web-Datenbank

Element:

Modifiable Constants

In der Scriptbibliothek ist in der Deklaration dieser Konstante der

Name der Domino-Directory Datenbank anzugeben. Die Standard-

einstellung lautet names.nsf.

Anhang - 81 -

Datenbank:

Web-Datenbank

Maske: ChPW

Feld: serverAdr,

pathAdr, serverOrg,

pathOrg

Die Inhalte dieser Felder werden berechnet. Falls die Berechnung

fehlschlägt, werden die vorgegebenen Werte verwendet. Diese

Vorgabewerte sind an die jeweilige Infrastruktur anzupassen.

Datenbank:

Domino-Directory

Maske: Person

Tab: Work/Home - Work

- Company Information

Sobald eine eigene Domino-Directory Datenbank verwendet werden

soll, sind an dieser Stelle in der Domino-Directory Datenbank

folgende vier editierbare Textfelder anzulegen:

• serverAdr

• pathAdr

• serverOrg

• pathOrg

Datenbank:

Web-Datenbank

Agent:

(Handle New Account

Request)

Der Servername und die Datenbankpfade sind im Agenten der

jeweiligen Infrastruktur anzupassen.

Sonstige Einstellungen Datenbank:

Organization Datenbank

Addresses Datenbank

Für den Fall, dass im Dokument einer Organisationseinheit mehrere

Icons für die Darstellung im Organisationsnavigator des Ad-hoc-

Workflow-Modelers vorhanden sind, kann die Auswahl des ge-

wünschten Icons nur sichergestellt werden, wenn es einen der

aufgeführten Namen besitzt:

• WorkflowIcon.gif

• WorkflowIcon.jpg

• WorkflowIcon.jpeg

Datenbank:

Web-Datenbank

Tab: Datenbank -

Eigenschaften -

Full Text

Für die Suchfunktionalität in den Ansichten der Workflow-

Management-Umgebung ist es notwendig, die Web-Datenbank

vorher zu indizieren.

xml.jar Diese Datei ist in das Verzeichnis Lotus\domino\data\domino\html auf

den Domino Server zu kopieren.

Sicherheitseinstellungen Für die Ausführung des Ad-hoc-Workflow-Modelers müssen in den

Sicherheitseinstellungen des Web-Browsers folgende Punkte

aktiviert sein:

• Java JIT-Compiler

• Scripting (Acitve Scripting, Scripting of Java applets)

Tabelle A.1.2-1: Konfiguration des Ad-hoc-Workflow-Management-Systems

Anhang - 82 -

A.2 Quelldateien und Gestaltungselemente im Überblick

A.2.1 Java-Quelldateien zur Anpassung des Web-basierten GroupProcess-Modelers

Tabelle A.2.1-2 beinhaltet aus dem Package readNotesData nur die Klassen, die im

Rahmen dieser Arbeit für die Web-basierte Lösung entwickelt wurden.

Package: readNotesData NamesData

NamesPersonHandler NamesGroupHandler

In dieser Klasse werden die Organisationsdaten aus den Ansichten der Addresses Datenbank eingelesen. Es liegen zwei XML-Zeichenketten vor, die zur Weiterverarbeitung an die Parser-Klassen NamesPersonHandler und NamesGroup Handler übergeben werden.

Diese Klasse erhält die XML-Zeichenkette mit den Personendaten der Addresses Datenbank. Die XML-Zeichenkette wird analysiert und für jede enthaltene Person ein Objekt angelegt. Dieses Objekt wird mit den Daten der Person gefüllt. Der Rückgabewert an die Klasse NamesData ist ein Vektor mit sämtlichen Personenobjek-ten.

Diese Klasse erhält die XML-Zeichenkette mit den Arbeitsgruppendaten der Addresses Datenbank. Der Rückgabewert der Klasse ist ein Vektor mit sämtlichen Arbeitsgruppenobjekten.

OrganizationData OrganizationPersonHandler OrganizationUnitHandler OrganizationGroupHandler

In dieser Klasse werden die Organisationsdaten aus den Ansichten der Organization Datenbank eingelesen. Die drei erhaltenen XML-Zeichenketten werden zur Weiterverarbei-tung an die Parser-Klassen OrganizationPersonHandler, NamesUnitHandler und OrganizationGroupHandler übergeben.

Diese Klasse erhält die XML-Zeichenkette mit den Personendaten der Organization Datenbank. Die XML-Zeichenkette wird analysiert und für jede enthaltene Person ein Objekt angelegt. Dieses Objekt wird mit den Daten der Person gefüllt. Der Rückgabewert an die Klasse OrganizationData ist ein Vektor mit sämtlichen Personen-objekten.

Diese Klasse erhält die XML-Zeichenkette mit den Abteilungsdaten der Organization Datenbank. Der Rückgabewert der Klasse ist ein Vektor mit sämtlichen Abteilungsobjekten.

Diese Klasse erhält die XML-Zeichenkette mit den Arbeitsgruppendaten der Organization Datenbank. Der Rückgabewert der Klasse ist ein Vektor mit sämtlichen Arbeitsgruppenobjekten.

Tabelle A.2.1-2: Angepasste Klassenhierarchie des Web-basierten Prototyps

Anhang - 83 -

A.2.2 Gestaltungselemente der Benutzungsschnittstelle

In diesem Kapitel werden alle Gestaltungselemente (Design-Elemente), die in dieser

Arbeit entwickelt wurden, erläutert. Die Tabelle A.2.2-3 umfasst die Elemente der Web-

Datenbank. Die Tabelle A.2.2-4 fasst die Elemente der Domino-Directory sowie der

Organization und Addresses Datenbank zusammen.

Gliederungen (Outlines)

Navigation Die Gliederung beinhaltet die Ansichten für die Navigation.

Fensterrahmen (Framesets)

WebFrameSet Das ist der Fensterrahmen für das Web.

Seiten (Pages)

administration

allarchive

frame3

mydesign

myinvolved

Die Seite enthält die Ansicht administration.

.

.

.

Die Seite enthält die Ansicht archiv

Die Startseite als Inhalt des rechten Frames.

Die Seite enthält die Ansicht mydesign

Die Seite enthält die Ansicht myinvolved

Masken (Forms)

AppletForm New Account ChangeData frame1 frame2 TeamView $$ReturnAuthenticatioFailure

n-

espeichert.

.

.

.

.

.

i .

.

e

.

$$ReturnDocument-Deleted $$ReturnGeneralError

In dieser Maske ist der Ad-hoc-Workflow-Modeler integriert. In dem Feld wbody der Maske wird die XML-Zeichenkette mit der Workflow-Struktur g

Die Maske dient dem Erstellen eines Benutzerkontos

Die Maske dient dem Anpassen des Benutzerkontos

Die Maske enthält den Kopf der Startseite

Die Maske enthält den Navigationsbereich für den linken Frame

Die Maske enthält die Ansicht allteam

Die Maske dient zur Behandlung von Fehlermeldungen beAuthentifizierungsproblemen

Die Maske dient der Behandlung des Löschvorgangs

Die Maske dient zur Behandlung sämtlicher Fehlermeldungen, dinicht weiter differenziert behandelt werden

Ansichten (Views)

administration allarchive allteam mydesign

Die Ansicht dient der Administration der Workflow-Dokumente.

.

.

.

Die Ansicht zeigt alle archivierten Workflow-Dokumente an

Die Ansicht zeigt alle Dokumente des jeweiligen Teams an

Die Ansicht zeigt alle Workflow-Dokumente, die vom jeweiligen Benutzer erzeugt wurden, an

Anhang - 84 -

myinvolved Die Ansicht zeigt alle Dokumente mit den Workflows an, in die der jeweilige Benutzer involviert ist.

Agenten (Agents)105

Set Groups to Alpha U

ser

etTeamField

andle Change Passwor

andel New Account

t .

s Initiators ein.

.

.

s Der Agent gehört zum Authentifizierungsmechanismus und fügregistrierte Benutzer in das Feld GroupsToJoin ein

S (H d Der Agent setzt die Änderungen an den Benutzerdaten umRecuest) (HRequest)

Der Agent fügt in einem neuen Workflow-Dokument den Teamnamen de

Der Agent legt ein neues Benutzerkonto an

Gemeinsame Felder (Shared Fields)

GroupsToJoin

ewPassword

die registrierten Benutzer

Das Feld enthält das Benutzerpasswort.

N

Das Feld enthält die Gruppen, in denenim Domino-Directory eingetragen werden.

Skript-Bibilioteken (Script Libraries)

Modifiable Constants

equest Utilities

smechanismus und enthält

Das Skript gehört zum Authentifizierungsmechanismus und enthält

R

Das Skript gehört zum Authentifizierungden Namen und die Pfade für das Domino-Directory.

verschiedene Funktionen.

Tabelle A.2.2-3: Design-Elemente der Web-Datenbank

Domino-Directory: Masken (Forms)

Person Die ursprüngliche Maske wurde um weitere Felder mit den Datenbankpfaden ergänzt (siehe Tabelle A.1.2-1).

Organization Datenbank: Ansichten (Views)

($PersonsXML)

UnitXML)

WorkgroupXML)

XML-Zeichenkette

ie Ansicht enthält die Daten der Abteilungen, die als XML-

ie Ansicht enthält die Daten der Arbeitsgruppen, die als XML-

($ ($

Die Ansicht enthält die Personendaten, die alsexportiert werden. DZeichenkette exportiert werden. DZeichenkette exportiert werden.

Addresses Datenbank: Ansichten (Views)

ContactsXML |

roupsXML

s XML-Zeichenkette

ie Ansicht enthält die Daten der Arbeitsgruppen, die als XML-

PeopleXML G

Die Ansicht enthält die Personendaten, die alexportiert werden. DZeichenkette exportiert werden.

Tabelle A.2.2-4: Design-Elemente der diversen Datenbanken

105 Agenten müssen mit einer ID unterzeichnet sein, die das Recht besitzt, Agenten auf dem Server auszuführen.

Anhang - 85 -

Eidesstattliche Erklärung

Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbstä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.

Paderborn, 01. September 2002 _______________________________________

Numan Tas