konzeption und prototypische implementierung von web...
Post on 27-Aug-2019
217 Views
Preview:
TRANSCRIPT
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.
2 Grundlagen und technologisches Umfeld der Arbeit - 8 -
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
2 Grundlagen und technologisches Umfeld der Arbeit - 9 -
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
2 Grundlagen und technologisches Umfeld der Arbeit - 10 -
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
2 Grundlagen und technologisches Umfeld der Arbeit - 11 -
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
2 Grundlagen und technologisches Umfeld der Arbeit - 12 -
• 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]
2 Grundlagen und technologisches Umfeld der Arbeit - 13 -
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]
2 Grundlagen und technologisches Umfeld der Arbeit - 14 -
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
2 Grundlagen und technologisches Umfeld der Arbeit - 15 -
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
2 Grundlagen und technologisches Umfeld der Arbeit - 16 -
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]
2 Grundlagen und technologisches Umfeld der Arbeit - 17 -
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]
2 Grundlagen und technologisches Umfeld der Arbeit - 18 -
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
2 Grundlagen und technologisches Umfeld der Arbeit - 19 -
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
2 Grundlagen und technologisches Umfeld der Arbeit - 20 -
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“
2 Grundlagen und technologisches Umfeld der Arbeit - 21 -
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.
3 Das GroupProcess-Konzept - 23 -
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
3 Das GroupProcess-Konzept - 24 -
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]
3 Das GroupProcess-Konzept - 25 -
(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.
3 Das GroupProcess-Konzept - 26 -
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).
3 Das GroupProcess-Konzept - 27 -
(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 Das GroupProcess-Konzept - 28 -
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 Das GroupProcess-Konzept - 29 -
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]
3 Das GroupProcess-Konzept - 30 -
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
3 Das GroupProcess-Konzept - 31 -
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
3 Das GroupProcess-Konzept - 32 -
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]
3 Das GroupProcess-Konzept - 33 -
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]
3 Das GroupProcess-Konzept - 34 -
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 Das GroupProcess-Konzept - 35 -
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]
3 Das GroupProcess-Konzept - 36 -
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]
3 Das GroupProcess-Konzept - 37 -
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
3 Das GroupProcess-Konzept - 38 -
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 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 40 -
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
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 41 -
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 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 42 -
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]
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 43 -
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]
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 44 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 45 -
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
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 46 -
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
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 47 -
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
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 48 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 49 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 50 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 51 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 52 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 53 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 54 -
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 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 55 -
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]
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 56 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 57 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 58 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 59 -
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
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 60 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 61 -
Ä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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 62 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 63 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 64 -
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
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 65 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 66 -
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.
4 Realisierung eines Web-basierten Ad-hoc-Workflow-Management-Systems - 67 -
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.
7 Literaturverzeichnis - 73 -
[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.
7 Literaturverzeichnis - 74 -
[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.
7 Literaturverzeichnis - 75 -
[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.
7 Literaturverzeichnis - 76 -
[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.
7 Literaturverzeichnis - 77 -
[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
top related