Unified Business Activity Management:
Architekturentwurf für das integrierte Management von
individuellen und kollaborativen Tätigkeiten
in Unternehmen
Dissertation
zur Erlangung des akademischen Grads
des Doktors der Wirtschaftswissenschaften
(Dr. rer. pol.)
Eingereicht an der Fakultät für Wirtschaftswissenschaften
der Universität Paderborn
von
Dipl.-Wirt.-Inform. Ingo Erdmann
Paderborn, Oktober 2011
Für Sandra, Lara und Jonah
II
Danksagungen
Ich habe in den vergangenen Jahren im privaten und im beruflichen Umfeld viel Unter-
stützung erfahren, um dieses Dissertationsprojekt fertig zu stellen. Einigen gebührt mein ganz
besonderer Dank. Dies ist zunächst mein Doktorvater und Mentor Prof. Dr. Ludwig
Nastansky, der mit der Einrichtung des Groupware Competence Centers (GCC) an der
Universität Paderborn eine einzigartige und inspirierende Lehr- und Forschungseinheit
geschaffen hat, die neben Exzellenz in Lehre und Forschung immer sehr viel Praxisbezug
ermöglicht hat. Die Zusammenarbeit war mir stets eine große Freude. Ich habe sie immer
auch als Privileg empfunden.
Ganz besonders möchte ich meiner lieben Frau Sandra danken. Ohne die unendliche Geduld,
Unterstützung und Ermutigung über viele Jahre wäre die Fertigstellung dieser Arbeit nicht
möglich gewesen. Ich freue mich unvorstellbar auf viel mehr Zeit mit euch! Mein Dank gilt
außerdem meinen Eltern und meinen Schwiegereltern, die mich immer großartig unterstützt
haben.
Beim gesamten Team des GCC möchte ich mich für den Teamgeist, die Freundschaft und den
spannenden Diskurs in unserer gemeinsamen Zeit bedanken. Auch den Mitgliedern der
Projektgruppe Contextual Collaborative Workplaces gebührt mein Dank für viele erfolgreiche
Projekte und spannende Diskussionen im Forschungsumfeld dieses Dissertationsprojektes.
Ebenfalls möchte ich herzlich meinen Korrekturlesern Klaus Dohrmann, Sandra Erdmann, Dr.
Olaf Hahnl und Martin Rosenberg danken, die ihre ohnehin knappe Freizeit geopfert haben,
um viele wertvolle Kommentare und Korrekturen zu dieser Arbeit beizutragen.
III
Abstract
Ein Großteil der Dokumente, die im Kontext eines kollaborativen Arbeitsplatzes bearbeitet
werden, liegt heute in elektronischer Form vor. Sie befinden sich in E-Mail-Datenbanken,
Content-Management-Systemen oder verschiedenen anderen Unternehmensrepositories.
Innerhalb des jeweiligen Repository findet die Bearbeitung, Strukturierung und Organisation
der Dokumente in Geschäftskontexte statt, z. B. durch ein Customer-Relationship-Manage-
ment-System. Die Art der Anwenderinteraktion mit diesen Dokumenten ist abhängig vom
Repository und dem Dokumententyp, orientiert sich aber in der Regel stark am Bearbei-
tungswerkzeug, das für die Modifikation eines Dokuments benötigt wird.
Bei der Bearbeitung von Tätigkeiten am kollaborativen Arbeitsplatz ist häufig der Zugriff auf
eine größere Anzahl von Dokumenten notwendig, die verteilt über verschiedene Repositories
vorliegen. Bei einem signifikanten Teil dieser Tätigkeiten handelt es sich um schwach struk-
turierte Ad-hoc-Tätigkeiten. Der Wissensarbeiter wird jedoch heute bei der Bearbeitung
dieser Tätigkeiten und der damit korrespondierenden Organisation und Strukturierung dieser
unterschiedlichen Dokumente und Dokumenttypen nicht hinreichend durch Software-Werk-
zeuge unterstützt. Die am kollaborativen Arbeitsplatz zur Verfügung stehende Informations-
technologie ist vielmehr nicht an die kognitiven Bedürfnisse des Menschen angepasst, son-
dern führt zu einer Werkzeug-zentrischen Vorgehensweise.
Aktivitätenmanagement ist die Bezeichnung für einen Ansatz, der dieses Szenario adressiert.
Der Ansatz basiert auf der Tätigkeitstheorie (Activity Theory), einem psychologischen
Erklärungsansatz für menschliches Verhalten. Übertragen auf die Interaktion mit kollaborati-
ven IT-Systemen leiten sich aus der Tätigkeitstheorie Ansätze für eine besser an die Bedürf-
nisse des Menschen angepasste Werkzeugunterstützung am kollaborativen Arbeitsplatz ab.
Ziel der vorliegenden Arbeit ist der Entwurf einer Architektur für ein Software-System zur
Unterstützung einer Form des Aktivitätenmanagements, die sowohl die Strukturierung und
Planung individueller, als auch kollaborativer geschäftlicher Tätigkeiten ermöglicht. Das
Konzept wird als Unified Business Activity Management (UBAM) bezeichnet.
IV
Inhaltsübersicht
Abstract ....................................................................................................................................III
Inhaltsübersicht ......................................................................................................................... V
Inhaltsverzeichnis.....................................................................................................................VI
Abbildungsverzeichnis.............................................................................................................. X
Tabellenverzeichnis.................................................................................................................XII
Abkürzungsverzeichnis......................................................................................................... XIII
1 Einleitung ........................................................................................................................... 1
1.1 Szenario...................................................................................................................... 1
1.2 Zielsetzung ................................................................................................................. 6
1.3 Ausrichtung und Aufbau der Arbeit........................................................................... 8
2 Grundlagen und Definitionen........................................................................................... 11
2.1 Relevante ökonomische Konzepte ........................................................................... 11
2.2 Informationstechnologie als Artefakt....................................................................... 15
2.3 Etablierte Kollaborationskonzepte und -technologien.............................................29
2.4 Aktivitäten-zentrische Ansätze ................................................................................ 48
3 Charakteristika des kollaborativen Arbeitsplatzes........................................................... 56
3.1 Unternehmen in der Wissensgesellschaft................................................................. 56
3.2 Kollaborative Arbeit in Teams................................................................................. 65
3.3 IT-Infrastrukturen für Kollaborations-Informationssysteme ...................................72
3.4 Werkzeugunterstützung des Wissensarbeiters ......................................................... 77
3.5 Forschungs- und Praxislücke ................................................................................... 88
4 Entwurf eines Unified Business Activity Management Framework................................91
4.1 Betrachtungsgegenstand des UBAM .......................................................................91
4.2 Nutzen von Unified Business Activity Management............................................. 101
4.3 Explikation des Aktivitätskontextes.......................................................................108
4.4 Funktionale Anforderungsanalyse.......................................................................... 115
4.5 Technische Anforderungsanalyse ..........................................................................144
4.6 Architekturentwurf................................................................................................. 149
4.7 Bewertung von Merkmalen der erweiterten Architektur ....................................... 184
5 GCC-AM: Umsetzung der Architektur für ein Beispielszenario................................... 196
5.1 Einführung.............................................................................................................. 196
5.2 Basisarchitektur des GCC-AM............................................................................... 203
5.3 Erweiterte Module und Dienste des GCC-AM ...................................................... 207
6 Schlussbetrachtungen und Ausblick............................................................................... 210
6.1 Zusammenfassung und kritische Würdigung......................................................... 210
6.2 Ausblick ................................................................................................................. 212
7 Literaturverzeichnis........................................................................................................ 215
V
Inhaltsverzeichnis
Danksagungen.......................................................................................................................... III
Abstract ....................................................................................................................................IV
Inhaltsübersicht ......................................................................................................................... V
Inhaltsverzeichnis.....................................................................................................................VI
Abbildungsverzeichnis.............................................................................................................. X
Tabellenverzeichnis.................................................................................................................XII
Abkürzungsverzeichnis......................................................................................................... XIII
1 Einleitung ........................................................................................................................... 1
1.1 Szenario...................................................................................................................... 1
1.2 Zielsetzung ................................................................................................................. 6
1.3 Ausrichtung und Aufbau der Arbeit........................................................................... 8
2 Grundlagen und Definitionen........................................................................................... 11
2.1 Relevante ökonomische Konzepte ........................................................................... 11
2.1.1 Produktivität..................................................................................................... 11
2.1.2 Transaktionskosten........................................................................................... 12
2.1.3 Arbeitsverhalten in Teams ...............................................................................13
2.2 Informationstechnologie als Artefakt....................................................................... 15
2.2.1 Artefakte........................................................................................................... 15
2.2.2 Elektronische Dokumente ................................................................................ 18
2.2.2.1 Eigenschaften ............................................................................................... 18
2.2.2.2 Speicherung in Repositories.........................................................................19
2.2.2.3 Identifikation................................................................................................22
2.2.2.4 Summary-Daten ...........................................................................................24
2.2.2.5 Navigation mit Ansichten.............................................................................26
2.3 Etablierte Kollaborationskonzepte und -technologien.............................................29
2.3.1 Grundkonzepte des kollaborativen Arbeitsplatzes........................................... 30
2.3.2 Kollaborations-Informationssysteme ............................................................... 33
2.3.2.1 Interaktionsparadigmen von Applikationen................................................. 33
2.3.2.2 Persönliches Informationsmanagement........................................................ 35
2.3.2.3 Informations- und Wissensmanagement ...................................................... 36
2.3.2.4 Social Software ............................................................................................ 39
2.3.2.5 Workflow- und Projektmanagement............................................................ 42
2.3.3 Zentraler Zugriffsbereich ................................................................................. 46
2.3.3.1 Portale........................................................................................................... 46
2.3.3.2 Kontextuelle Kollaboration.......................................................................... 47
2.4 Aktivitäten-zentrische Ansätze ................................................................................ 48
2.4.1 Kontextmanagement......................................................................................... 48
2.4.2 Tätigkeitstheorie...............................................................................................50
3 Charakteristika des kollaborativen Arbeitsplatzes........................................................... 56
3.1 Unternehmen in der Wissensgesellschaft................................................................. 56
3.1.1 Wissen als Produktionsfaktor...........................................................................56
3.1.2 Interorganisationale Kooperation..................................................................... 57
3.1.3 Fähigkeiten und Erwartungen von Anwendern................................................ 59
3.1.3.1 Funktionsvorsprung privater Kollaborationssysteme................................... 59
3.1.3.2 Situationsbezogene Applikationen und partizipatives Design..................... 61
3.1.3.3 Partizipation durch Social Software............................................................. 63
3.1.3.4 Ad-hoc-Aktivitäten....................................................................................... 64
VI
3.2 Kollaborative Arbeit in Teams................................................................................. 65
3.2.1 Virtualität und Verteiltheit ............................................................................... 66
3.2.2 Interorganisationalität....................................................................................... 67
3.2.3 Heterogenität und Interdisziplinarität............................................................... 68
3.2.4 Individualität und Vielstimmigkeit .................................................................. 69
3.2.5 Unterbrechungen und Kontextwechsel ............................................................ 70
3.3 IT-Infrastrukturen für Kollaborations-Informationssysteme ...................................72
3.3.1 Komplexität von Systemlandschaften..............................................................72
3.3.2 Isolierte Repositories........................................................................................74
3.3.3 Portale und Mashups........................................................................................ 75
3.3.4 Interorganisationale CIS................................................................................... 76
3.4 Werkzeugunterstützung des Wissensarbeiters ......................................................... 77
3.4.1 Werkzeugzentrierung .......................................................................................78
3.4.2 Spektrum der E-Mail-Nutzung.........................................................................79
3.4.3 Isolierte und dezentrale Repositories ............................................................... 80
3.4.4 Werkzeugunterstützung für Kontextmanagement............................................ 82
3.4.4.1 Management physischer Kontextdimensionen............................................. 82
3.4.4.2 Management von Geschäftsprozesskontexten .............................................84
3.4.4.3 Individuelle Dokumentenkontexte............................................................... 86
3.4.4.4 Klassifizierung von Dokumenten anhand von Kontextinformationen......... 87
3.5 Forschungs- und Praxislücke ................................................................................... 88
3.5.1 Fehlende Werkzeugunterstützung für Aktivitätenmanagement....................... 88
3.5.2 Fehlende Explikation werkzeugübergreifender Geschäftsprozesskontexte..... 89
4 Entwurf eines Unified Business Activity Management Framework................................91
4.1 Betrachtungsgegenstand des UBAM .......................................................................91
4.1.1 Aktivitäten und Aufgaben................................................................................ 91
4.1.2 Abbildung einer Aktivität durch Projektion..................................................... 93
4.1.3 Individual- und Teamaktivitäten...................................................................... 95
4.1.4 Aktivitätenmanagement ...................................................................................96
4.1.5 Abgrenzung von etablierten CSCW Konzepten...............................................97
4.2 Nutzen von Unified Business Activity Management............................................. 101
4.2.1 Produktivitätssteigerung................................................................................. 101
4.2.2 Unterstützung der organisationalen Wissensmanagement Prozesse.............. 103
4.2.3 Kostensenkung ............................................................................................... 106
4.2.4 Linderung des Agenturproblems.................................................................... 107
4.3 Explikation des Aktivitätskontextes.......................................................................108
4.3.1 Anwendung der Tätigkeitstheorie..................................................................108
4.3.2 Elemente einer Aktivitätsstruktur................................................................... 109
4.3.3 Individualität der Aktivitätsstruktur............................................................... 112
4.3.4 Unterstützung von Teamaktivitäten ............................................................... 113
4.4 Funktionale Anforderungsanalyse.......................................................................... 115
4.4.1 Effizienz ......................................................................................................... 115
4.4.2 Darstellung von Aktivitäten ........................................................................... 116
4.4.3 Navigation, Orientierung und Suche.............................................................. 119
4.4.4 Aktivitätsvorlagen..........................................................................................122
4.4.5 Elemente der Aktivitätsstruktur als Dokument.............................................. 123
4.4.5.1 Meta-Daten................................................................................................. 124
4.4.5.2 Planung und Organisation der Aufgabenbearbeitung ................................ 127
4.4.5.3 Sicherheit....................................................................................................129
4.4.5.4 Inhaltsbeschränkung auf Kontextinformationen........................................ 130
4.4.5.5 Management von Meta-Daten.................................................................... 132
VII
4.4.6 Zentraler Zugriffsbereich ............................................................................... 134
4.4.6.1 Erfassung aller Interaktionspartner ............................................................ 134
4.4.6.2 Erfassung aller Dokumente........................................................................ 135
4.4.6.3 Posteingang für Aktivitäten........................................................................137
4.4.6.4 Management von Notifications..................................................................138
4.4.6.5 Vermeidung erzwungener Kontextwechsel ............................................... 139
4.4.6.6 Kontextuelle Kollaboration........................................................................ 141
4.4.7 Verfügbarkeit ................................................................................................. 141
4.4.7.1 Inhalte in lokalen und privaten Repositories.............................................. 141
4.4.7.2 Offline-Fähigkeit........................................................................................ 142
4.4.7.3 Mobile Geräte.............................................................................................143
4.5 Technische Anforderungsanalyse ..........................................................................144
4.5.1 Speicherung von Aktivitätsstrukturen............................................................ 144
4.5.2 Modularisierung und Portalkonzept............................................................... 145
4.5.3 Schnittstellen und API....................................................................................147
4.6 Architekturentwurf................................................................................................. 149
4.6.1 Grundlegende Architekturmerkmale.............................................................. 149
4.6.1.1 Trennung von Aktivitäten- und Ziel-Repository........................................149
4.6.1.2 Verwaltung des Client Status..................................................................... 151
4.6.1.3 Ansichten von Aktivitäten..........................................................................152
4.6.2 Datenmodell ...................................................................................................155
4.6.3 Vorlagen und Schablonen für Aktivitätsstrukturen........................................ 158
4.6.4 Architektur im Kontext von ECM.................................................................. 159
4.6.5 Erweiterbarkeit des Framework ..................................................................... 161
4.6.5.1 API und Event Manager............................................................................. 163
4.6.5.2 Gemeinsame Nutzung von Inhalten........................................................... 165
4.6.5.3 Statusmanagement und Synchronisation von Meta-Daten......................... 167
4.6.5.4 Notifications............................................................................................... 170
4.6.5.5 Integration interorganisationaler Aktivitäten ............................................. 172
4.6.5.6 Mobile Verfügbarkeit.................................................................................175
4.6.6 Architekturmerkmale des UI.......................................................................... 176
4.6.6.1 Layout des UI............................................................................................. 176
4.6.6.2 Plugins........................................................................................................ 178
4.6.6.3 Posteingang für Aktivitäten........................................................................180
4.6.6.4 Place Awareness......................................................................................... 181
4.6.6.5 Alternative Geschäftsprozesskontexte ....................................................... 182
4.7 Bewertung von Merkmalen der erweiterten Architektur ....................................... 184
4.7.1 Szenario-unspezifisch zu bewertende Module und Dienste........................... 184
4.7.1.1 Module und Dienste mit hoher Priorität zum Projektstart .........................186
4.7.1.2 Module und Dienste mit hoher Priorität optional zum Projektstart ........... 186
4.7.1.3 Module und Dienste mit geringer Priorität in allen Szenarien...................187
4.7.2 Szenario-spezifisch zu bewertende Module und Dienste............................... 188
4.7.2.1 Anteil der Wissensarbeit am Produktionsprozess...................................... 189
4.7.2.2 Einfluss interorganisationaler Kooperation................................................ 190
4.7.2.3 Organisatorische Rahmenbedingungen...................................................... 191
4.7.2.4 Vorhandene Infrastruktur........................................................................... 192
VIII
5 GCC-AM: Umsetzung der Architektur für ein Beispielszenario................................... 196
5.1 Einführung.............................................................................................................. 196
5.1.1 Szenario und Anforderungen ......................................................................... 196
5.1.2 Projekthistorie und angrenzende Projekte...................................................... 198
5.2 Basisarchitektur des GCC-AM............................................................................... 203
5.2.1 Aktivitätenmanagement mit dem UBAM UI................................................. 203
5.2.2 Harvesting ...................................................................................................... 205
5.2.3 Repository und Offline-Fähigkeit .................................................................. 206
5.2.4 Konfiguration und Sicherheit......................................................................... 207
5.3 Erweiterte Module und Dienste des GCC-AM ...................................................... 207
6 Schlussbetrachtungen und Ausblick............................................................................... 210
6.1 Zusammenfassung und kritische Würdigung......................................................... 210
6.2 Ausblick ................................................................................................................. 212
7 Literaturverzeichnis........................................................................................................ 215
IX
Abbildungsverzeichnis
Abbildung 2-1: Beispiel für eine hybride Datenbank Technologie ......................................... 22
Abbildung 2-2: Inhalt, Kontext-Daten und Meta-Daten von Dokumenten ............................. 25
Abbildung 2-3: Referenzmodell Visualisierung ......................................................................28
Abbildung 2-4: Kollaboration..................................................................................................32
Abbildung 2-5: Wichtigste Führungsqualitäten der nächsten fünf Jahre................................. 38
Abbildung 2-6: GroupProcess Workflow Kontinuum............................................................. 44
Abbildung 2-7: Klassifizierung von Projekt- und Workflowmanagement-Systemen ............. 45
Abbildung 2-8: Hierarchische Ebenen einer Tätigkeit.............................................................51
Abbildung 2-9: Struktur einer Tätigkeit...................................................................................53
Abbildung 3-1: Kontinuum organisationaler Gestaltungsformen............................................59
Abbildung 3-2: Barrieren der Zusammenarbeit ....................................................................... 69
Abbildung 3-3: Beispiel für eine ECM-Architektur ................................................................ 73
Abbildung 3-4: Portal Architektur ........................................................................................... 76
Abbildung 3-5: Größte Herausforderungen für das eigene Geschäft.......................................78
Abbildung 3-6: Beispiel für eine CIS-Infrastruktur................................................................. 79
Abbildung 3-7: Geschäftsprozesskontextdimensionen und übliche Kontextbeziehungen ...... 85
Abbildung 4-1: Mögliches Ergebnis der Projektion einer Aktivität........................................ 94
Abbildung 4-2: Ablagestrukturen administrativer und kreativer Disziplinen..........................96
Abbildung 4-3: Beispiel für eine Aktivitätsstruktur mit expliziten Aktivitätskontexten.......111
Abbildung 4-4: Projektion zweier Aktivitäten mit gemeinsamer Teilaktivität...................... 112
Abbildung 4-5: Unterschiedliche Projektion einer Aktivität durch zwei Individuen ............ 113
Abbildung 4-6: Aktivität als Meta-Ebene etablierter CSCW Konzepte................................ 100
Abbildung 4-7: Aktivitäten mit verknüpfter Teilaktivität......................................................116
Abbildung 4-8: Aktivitätsnetzwerk........................................................................................ 117
Abbildung 4-9: Hierarchische Aktivitätsstrukturliste ............................................................ 118
Abbildung 4-10: Vereinfachte Darstellung von Teilaktivitäten durch Aufgaben.................. 119
Abbildung 4-11: Zieldokumente in der Suche nach Elementen der Aktivitätsstruktur......... 125
Abbildung 4-12: Kontinuum für Kontextexplikation.............................................................126
Abbildung 4-13: Darstellung von Teilaktivitäten ohne Aufgabe........................................... 129
Abbildung 4-14: Alternativen der Ablage von Dokumenten.................................................132
Abbildung 4-15: Beispiel für Integration externer Dokumente .............................................136
Abbildung 4-16: Alternativen des gemeinsamen Zugriffs auf private Dokumente............... 142
Abbildung 4-17: Einbettung von Dokumenten in den UBAM Client ................................... 150
Abbildung 4-18: Offline-Architektur..................................................................................... 151
Abbildung 4-19: Beispiel für Standard- und Privat-Hierarchie sowie Aufgabenliste ...........154
Abbildung 4-20: ERM Modell eines UBAM System mit den wichtigsten Attributen.......... 156
Abbildung 4-21: Aktivitätsvorlagen: Beispiel für Abstraktion und Kopie............................ 159
Abbildung 4-22: Beispiel für die Integration von UBAM in eine ECM Architektur ............ 160
Abbildung 4-23: Lebenszyklus einer Aktivität......................................................................161
Abbildung 4-24: Erweiterte UBAM Architektur ................................................................... 162
Abbildung 4-25: Sequenzdiagramm Ablage eines Dokuments mit dem Sharing Manager .. 166
Abbildung 4-26: Beispielimplementierung Notification und Event Manager....................... 171
Abbildung 4-27: Schattendokument für externe Zugriffe auf Dokumenteninhalte............... 174
Abbildung 4-28: Beispiel für eine Kosten-Nutzen Analyse alternativer Implementierungen193
X
Abbildung 5-1: GCC-AM Architektur Überblick.................................................................. 198
Abbildung 5-2: Screenshot des GCC Activity Manager auf Basis des WMC....................... 201
Abbildung 5-3: Screenshot GCC-AM auf Basis von Notes 8.5 mit Eclipse Portlet.............. 202
Abbildung 5-4: Harvesting Dialog......................................................................................... 205
Abbildung 5-5: Offline-Architektur GCC-AM...................................................................... 206
Abbildung 5-6: Beispiel für Meta-Daten Synchronisation .................................................... 209
XI
Tabellenverzeichnis
Tabelle 2-1: Beispiele für Summary-Daten ............................................................................. 26
Tabelle 2-2: Klassifizierung der Unterstützungsmöglichkeiten von Aktivitäten durch IT...... 54
Tabelle 4-1: Anwendung der Prinzipien der Tätigkeitstheorie auf den Kontext der Arbeit.. 108
Tabelle 4-2: Übersicht Szenario-unspezifischer Module und Dienste...................................185
Tabelle 4-3: Übersicht des Nutzens von Modulen in speziellen Szenarien........................... 189
XII
Abkürzungsverzeichnis
BPEL Business Process Execution Language
CA Composite Application
CAM Collaborative Activity Management
CAMS Collaborative Activity Management System
CCW Contextual Collaborative Workplaces
CIS Collaboration Information System
CRM Customer Relationship Management
CSCW Computer Supported Cooperative Work
DOI Digital Object Identifier
EAI Enterprise Application Integration
ECM Enterprise Content Management
EDA Event Driven Architecture
ERM Entity Relationship Modell
GCC Groupware Competence Center, Universität Paderborn
GCC-AM GCC Activity Manager
HCI Human Computer Interaction
ID Identifikationsnummer
IPC Inter-Portlet Communication
IT Informationstechnologie
JCR Java Content Repository
CoMS Context Management System
PMS Projektmanagement-System
RCP Rich Client Platform
SOA Serviceorientierte Architektur
SSO Single-Sign-On
UAM Unified Activity Management
UBAM Unified Business Activity Management
UI User Interface
UMEA User-Monitoring Environment for Activities
URI Uniform Resource Identifier
WfMS Workflowmanagement System
WMC Workplace Managed Client
WMS Wissensmanagement System
XIII
1 Einleitung
1.1 Szenario
Der Prozess der Globalisierung sowie die technischen Möglichkeiten Internet-basierter
Informationssysteme stellen Unternehmen, deren Mitarbeiter und die Gesellschaft vor neue
Herausforderungen. Der Wettbewerb findet zunehmend nicht nur zwischen einzelnen Unter-
nehmen, sondern zwischen Unternehmensnetzwerken statt, in denen auch Unternehmen
kooperieren, die in Teilbereichen ihrer geschäftlichen Aktivitäten wiederum im Wettbewerb
zueinander stehen.1 Um die Infrastrukturkosten für Informationstechnologie (IT) möglichst
gering zu halten und die zunehmend komplexeren Systemlandschaften beherrschbar zu
machen, stehen serviceorientierte Konzepte und auf Standards basierende Technologien bei
der Umsetzung von IT-Architekturen im Vordergrund.2
Aufgrund beschleunigter Produktlebens- und Entwicklungszyklen, welche insbesondere eine
Folge des intensivierten Wettbewerbs sind, ist eine kontinuierliche Weiterentwicklung und
Flexibilisierung der Aufbau- und Ablauforganisation von Unternehmen notwendig.3
Etablierte Bürokonzepte werden daher in vielen Bereichen durch das Konzept des
kollaborativen Arbeitsplatzes4 abgelöst. Es ist gekennzeichnet durch flexible,
selbstorganisierende, zum Teil interorganisationale Teams, die unabhängig von physischen
Büroumgebungen arbeiten. Synchrone sowie asynchrone Kommunikationstechnologien
unterstützen die mobile, verteilte Arbeitsweise.
Informationstechnologie ist sowohl in Unternehmen, als auch im privaten Bereich zu einer
allgegenwärtig verfügbaren und zugleich unverzichtbaren Infrastrukturkomponente (engl.
Commodity5) geworden. Unter dem Einfluss von Social Software und Web-2.0-Technologien,
die u. a. reichere Interaktionsmöglichkeiten als traditionelle Web-1.0-Technologien zur
Verfügung stellen, entwickelt sich eine Wissensgesellschaft mündiger „e-Bürger“, die verfüg-
bare Kollaborationswerkzeuge wie E-Mail, Instant Messaging und asynchrone Informations-
räume wie Themen-orientierte Foren konsequent auch im privaten Umfeld nutzen. Das
Kollaborationsverhalten ist durch Trends wie Weblogs, Wiki’s und soziale Netzwerke ge-
kennzeichnet. Diese werden als Social-Software-Konzepte bezeichnet. Im Kontext der da-
1 Vgl. etwa [Karnani 2001], S. 112ff.
2 Vgl. etwa [Dostal et al. 2005], [Plattner 2007].
3 Vgl. etwa [Österle 2007], S. 75f.
4 Für eine Definition des kollaborativen Arbeitsplatzes vgl. Abschnitt 2.3.1.
5 Hinweis: Im Verlauf der Arbeit wird stets der im Fachgebiet übliche Terminus verwendet. Ist die englische
Variante gebräuchlich, wird die deutsche Übersetzung beim erstmaligen Auftreten des Terminus in
Klammern angegeben. Steht eine übliche, deutsche Übersetzung zur Verfügung, wird diese verwendet und
die englische Übersetzung in Klammern angegeben.
1
durch induzierten Meinungsbildungsprozesse, die direktes Kundenfeedback liefern sowie die
öffentliche Meinung über Produkte und Marken in kurzer Zeit und mit globaler Wirkung
signifikant beeinflussen können, wird es für Unternehmen zunehmend wichtiger, schnell und
mit hoher Informationsqualität auf Anforderungen des Markts und auf öffentliche Dis-
kussionen zu reagieren.
Das Bewusstsein über die Bedeutung der Ressource Wissen hat in den vergangenen Jahren
erheblich zugenommen. Wissen wird als ein zentraler Faktor für die Wettbewerbsfähigkeit
eines Unternehmens gesehen.6 Aufgrund fortgeschrittener Digitalisierung des kollaborativen
Arbeitsplatzes stehen in der Regel alle relevanten Informationen zu jeder Zeit digital zur
Verfügung.7 Häufig wird sogar von einer Informationsüberflutung des Wissensarbeiters
ausgegangen, die seine Produktivität beeinträchtigen kann.8 Die Herausforderung des
Unternehmens besteht daher darin die Mitarbeiter dabei zu unterstützen, relevante Informa-
tionen in der großen Menge verfügbarer Informationen zu identifizieren, zu extrahieren und
diese in Geschäftskontexte zu bringen, um sie dann nutzbringend einzusetzen. Diese Heraus-
forderung wird durch Wissensmanagement-Ansätze adressiert.
Durch Wissensmanagement wird versucht, eine verbesserte Vernetzung und Nutzung der
Fülle vorhandener Informationsressourcen, organisationalem Gedächtnis und individuellem
Wissen der Mitarbeiter herbeizuführen. Dies dient kann zur Senkung von Transaktionskosten
führen, etwa von Messkosten bei der Bewertung von Informationen, von Kosten für die
Informationsbeschaffung sowie Kommunikationskosten im Allgemeinen. Neben Kosten-
senkung ist die Verbesserung der Qualität von Prozessen, Produkten und Informationen ein
wichtiges Ziel, um Wettbewerbsvorteile zu erzielen. Im Zuge dieser Bestrebungen unterstüt-
zen Wissensmanagement Systeme (WMS, engl. Knowledge Management Systems) die
Mitarbeiter beim Wissenserwerb, der Bereitstellung und Nutzung relevanter Informationen
für die Bearbeitung von Tätigkeiten und dem Vorschlagen von semantischen Zusammen-
hängen in Unternehmensrepositories.9
Um die arbeitsteilige Verarbeitung von Informationen zu koordinieren, Diskussionen zu
unterstützen und Kommunikation zu ermöglichen werden diese kollaborativen Tätigkeiten
durch Kollaborations-Informationssysteme (engl. Collaboration Information Systems, CIS)
unterstützt. Übliche Systemklassen sind beispielsweise Workflow-, Projekt-, Dokumenten-
und Web-Content-Management-Systeme. Diese dienen etwa der Erhöhung der Prozessge-
6 Vgl. [Probst/Raub/Romhardt 2006], S. 3.
7 Vgl. [Picot/Reichwald/Wigand 2003], S. 6.
8 Vgl. etwa [Simpson/Prusak 1995], [Whittaker/Sidner 1996], [Denning 2006].
9 Vgl. [Smolnik 2006], [Probst/Raub/Romhardt 2006].
2
schwindigkeit, der Reduzierung der Anzahl von Medienbrüchen und der Teilautomatisierung
von Prozessen am kollaborativen Arbeitsplatz.10 Die Arbeit am kollaborativen Arbeitsplatz ist
heute weitgehend Werkzeug-zentrisch geprägt. Im Verlauf der Bearbeitung einer Tätigkeit
wird ein Mix von Spezialwerkzeugen der genannten Systemklassen eingesetzt, um einzelne
Aufgaben zu bearbeiten. Ein ganzheitlicher Ansatz, der an den Tätigkeiten des einzelnen
Mitarbeiters orientiert ist, wird nicht oder nur unzureichend durch Software-Werkzeuge
unterstützt. So ist es häufig für die Bearbeitung einer Tätigkeit notwendig auf Dokumente
zuzugreifen, die in verschiedenen nicht integrierten Repositories (dt. Repositorium) abgelegt
sind, etwa dezentrale, abteilungsweite Systeme. Aufgrund der fehlenden Integration werden
diese Repositories als isoliert bezeichnet. Isolierte Repositories können aber auch durch
dezentrale Systeme in Abteilungen entstehen, die nicht in ein unternehmensweites Enterprise
Content Management (ECM) System eingebunden sind.11
Isolierte Repositories erfordern eine manuelle Aggregation von verteilten Informationen
durch die Anwender dieser Systeme, die häufig mehrfach, z. B. nach einer Unterbrechung,
ausgeführt wird. Auch die Navigation in unterschiedlichen Systemen, die zum Zugriff auf die
benötigten Informationen notwendig wird, erfordert zusätzlichen Aufwand. Da Wissensarbeit
wie die Aggregation, Relation und Assoziation von Informationen nicht durch Werkzeuge
unterstützt wird, kann sie zudem eine mental und kognitiv höhere Beanspruchung des Mitar-
beiters darstellen als mit Unterstützung durch entsprechende Werkzeuge.
Soll beispielsweise in einem Unternehmen ein Angebot über eine Soft- und Hardware Instal-
lation für einen Kunden erstellt werden, so muss der Vertriebsmitarbeiter zunächst auf die
Kontaktdaten des Kunden zugreifen. Diese befinden sich z. B. in einem System zum Kunden-
beziehungsmanagement (engl. Customer Relationship Management, CRM). Um die Anforde-
rungen an die Hardware zu bestimmen wird Zugriff auf die technische Dokumentation der
Software benötigt, die sich in einem Dokumentationssystem der Entwicklungsabteilung
befindet. Aus dem WMS des Unternehmens erfährt der Mitarbeiter, dass ein Kollege aus der
Beratungsabteilung bereits ein Projekt bei einem Kunden mit der Software durchgeführt hat.
Per E-Mail fragt der Vertriebsmitarbeiter den Kollegen nach seiner Einschätzung für den
Installationssaufwand. Der Kollege verweist ihn auf einen Bericht über das entsprechende
Projekt in einer Projektmanagement-Applikation.
Der Vertriebsmitarbeiter muss auf diese Vielzahl unterschiedlicher Repositories in mehreren
manuellen Schritten zugreifen. Es gibt keinen zentralen Zugriffsbereich auf alle, für die
10 Vgl. etwa [Hilpert 1992], S. 129 oder [Krcmar 2005], S. 510 ff.
11 Vgl. [O'Hanlon 2005].
3
auszuführende Tätigkeit benötigten, Dokumente. Für den Zugriff auf die unterschiedlichen,
nicht integrierten Repositories stehen in der Regel spezialisierte Werkzeuge zur Bearbeitung
und Strukturierung der jeweils verwalteten Dokumententypen zur Verfügung. Die Art der
Interaktion mit diesen Dokumenten ist dabei abhängig vom Repository und dem Typ eines
Dokuments. Sie orientiert sich aus Anwendersicht in der Regel stark am jeweiligen Bearbei-
tungswerkzeug. Hinzu kommt, dass es sich bei einem signifikanten Teil von Tätigkeiten am
kollaborativen Arbeitsplatz um wenig strukturierte Tätigkeiten handelt, die ad hoc auftreten.
Aus der Sicht des Wissensarbeiters steht jedoch zur individuellen, an der ausgeführten Tätig-
keit orientierten Organisation und Strukturierung dieser Fülle verteilter Dokumente und
Dokumententypen keine hinreichende Werkzeugunterstützung durch Software zur Verfügung.
Die Notwendigkeit der Werkzeugunterstützung liegt darin begründet, dass das allein in der
Vorstellung des Individuums existierende Strukturierungsmerkmal Aktivität12 ohne Explika-
tion für den Menschen nicht zugänglich, schwer wahrnehmbar, und nicht manipulierbar ist.
So ist etwa die Reflexion von Abläufen und die Diskussion von Zusammenhängen mit
Kollegen nur sehr begrenzt möglich. Reflexion ist eine Voraussetzung für die Verbesserung
der Bearbeitung von Tätigkeiten. Um dafür zugänglich zu sein ist es notwendig, ein externes
Gedächtnis zu schaffen. Dies geschieht durch die Schaffung von künstlichen Objekten
(Artefakten), die eine Explikation der Aktivitätsstruktur darstellen und als externes Gedächtnis
fungieren („Artifacts as external memory“13). Auch die arbeitsteilige Koordination von
Aktivitäten ist ohne vorherige Explikation der Struktur sowie deren Abbildung z. B. innerhalb
eines Team-orientierten Software-Werkzeugs nur schwer möglich.
Die zuvor beschriebene Werkzeug-zentrische Vorgehensweise und die fehlende Unter-
stützung für die Planung und Strukturierung von Ad-hoc-Tätigkeiten führen dazu, dass der
typische kollaborative Arbeitsplatz die Möglichkeiten der Unterstützung kognitiver Vorgänge
bei der Wissensarbeit nur unzureichend bereitstellt. In Ermangelung eines spezialisierten
Werkzeugs setzt der Anwender daher häufig ein von ihm gut beherrschtes Werkzeug zu
diesem Zweck ein, etwa seinen E-Mail-Client.14 So werden unternehmensrelevante
Informationen per E-Mail weitergeleitet um Prozesse zu koordinieren, statt ein Workflow-
Management-Werkzeug einzusetzen. Informationen werden in E-Mail-Ordnerstrukturen
abgelegt statt ein gemeinsames Repository zu verwenden, in dem sowohl das Dokument, als
auch die Strukturierungsmerkmale allen Teammitgliedern als Informationsquelle zugänglich
12 Die Begriffe Tätigkeit und Aktivität werden an dieser Stelle noch synonym verwendet. Umfassende
Ausführungen finden sich in 2.4.2.
13 Vgl. [Keil-Slawik 1992], S. 179 ff.
14 Vgl. [Ducheneaut/Bellotti 2001].
4
wären. Durch die Weiterleitung entstehen zudem Kosten durch Mehrfachspeicherung großer
Dateianhänge sowie der Notwendigkeit der mehrfachen, individuellen Strukturierung durch
jeden der Informationsempfänger. Hinzu kommen fehlende Versionierung, Probleme mit
Backups und Herausforderungen im Bereich von regulatorischen und gesetzlichen Anforde-
rungen (engl. Compliance) an die Aufbewahrungspflicht unternehmensrelevanter Dokumente.
Die verbreitete Nutzung von E-Mail für die genannten Tätigkeiten weist darauf hin, dass der
einzelne Mitarbeiter Eigenschaften wie den zentralen Zugriffsbereich auf einen Großteil der
benötigten Informationen und die an seine individuellen Bedürfnisse bei der Tätigkeitsbear-
beitung angepassten Strukturierungsmerkmale gegenüber spezialisierten, aber nicht integrier-
ten Werkzeugen bevorzugt. Und dies obwohl Unternehmen in den vergangenen Jahren massiv
zur Nutzung kollaborativer Systeme anregen, um die genannten Herausforderungen der
gegenwärtigen Art der E-Mail-Nutzung zu adressieren.
Heute üblicherweise eingesetzte E-Mail-Clients sind funktional nicht dafür konzipiert, Struk-
turierungs-, Planungs- und Koordinationsunterstützung zu leisten. Dies führt neben den
genannten Herausforderungen für das Unternehmen dazu, dass Tätigkeiten nicht effizient
durchgeführt werden und die Basis wertvollen Unternehmenswissens in den für Teamarbeit
nicht zugänglichen E-Mail-Umgebungen der Mitarbeiter gespeichert ist. Dies führt zu einer
Fragmentierung von Unternehmenswissen, was dem Unternehmen signifikanten Schaden
zufügen kann. Zudem fehlt Transparenz, es sind keine Informationen über den Bearbeitungs-
status und die durchgeführten Tätigkeiten für Vorgesetzte verfügbar, was die Informations-
asymmetrie zwischen Mitarbeiter und Vorgesetztem zum Nachteil des Vorgesetzten verstär-
ken kann15. Daher besteht hier Verbesserungspotenzial für Unternehmensabläufe und das
Management individueller Ad-hoc-Tätigkeiten, und somit ein Potenzial für Produktivitätsstei-
gerungen am kollaborativen Arbeitsplatz.
Um dieses Potenzial zu nutzen wurden Konzepte zur Planung und Koordination von Tätig-
keiten entwickelt. Diese Konzepte werden unter dem Begriff Aktivitätenmanagement zusam-
mengefasst. Die Aktivitätenmanagement-Konzepte basieren auf der Tätigkeitstheorie (engl.
Activity Theory), einem Erklärungsansatz für menschliches Verhalten, der durch den Psy-
chologen Leont’ev zwischen den 1930er und den 1970er Jahren geprägt wurde.16 Danach
werden Tätigkeiten von Menschen bewusst durchgeführt, sind abhängig von seiner Persön-
lichkeit und seinem sozialen Umfeld und werden durch Motive für die Tätigkeit beeinflusst.
Übertragen auf die Interaktion mit kollaborativen IT-Systemen liefert die Tätigkeitstheorie
15 Vgl. Pricipal-Agent-Theorie in 2.1.3.
16 Charakteristisch ist [Leont’ev 1977].
5
Ansätze für eine besser an die Bedürfnisse und kognitiven Fähigkeiten des Menschen ange-
passte Arbeitsweise am kollaborativen Arbeitsplatz. Um Aktivitäten-zentrisches Arbeiten zu
unterstützen, wurde die Tätigkeitstheorie bereits in zahlreichen Veröffentlichungen unter dem
Aspekt der Mensch-Computer-Interaktion (engl. Human Computer Interaction, HCI) auf das
Design von spezialisierten Software-Werkzeugen angewendet.17 Im Rahmen dieser Arbeit
soll die Tätigkeitstheorie Anwendung bei der Konzeption eines Systems zum Management
von Ad-hoc-Tätigkeiten erfahren.
1.2 Zielsetzung
Die Zielsetzung der vorliegenden Arbeit besteht darin ein Konzept und einen Architekturent-
wurf für ein System zu erarbeiten, das Mitarbeiter am kollaborativen Arbeitsplatz bei der
Verwaltung und Strukturierung von elektronischen Dokumenten im Kontext ihrer betrieb-
lichen Tätigkeiten unterstützt. Dabei sollen alle Dokumente berücksichtigt werden die sie
benötigen, um diese Tätigkeiten erfolgreich zu erledigen. Die Schaffung eines zentralen
Zugriffbereichs (engl. Single Point of Access) ist dabei von großer Bedeutung für ein mög-
lichst produktives Arbeiten, um Kontextwechsel, Medienbrüche und Mehrfachsuche zu
vermeiden. Die Mitarbeiter sollen außerdem durch dieses System bei der Planung der Bear-
beitung und der Koordination von arbeitsteiligen Tätigkeiten unterstützt werden.
Dabei soll sowohl eine Orientierung an den kognitiven Fähigkeiten des Menschen, als auch an
den Anforderungen von Unternehmen in der globalisierten Wirtschaft erfolgen. Das
Aktivitätenmanagement-Werkzeug soll dabei nicht isoliert zum Einsatz kommen, sondern in
die bestehende CIS-Infrastruktur des Unternehmens integrierbar sein. Der Einsatz im Unter-
nehmen stellt zudem besondere Anforderungen in Bezug auf Sicherheit, Archivierung,
Compliance, Skalierbarkeit, Datenintegration usw. Es ist daher notwendig, vor der Konzep-
tion einer Architektur eine umfassende Anforderungsanalyse durchzuführen. Darauf basierend
kann ein Konzept und eine Architektur entworfen werden die hinreichend offen spezifiziert
sind, um auf Basis verschiedener Technologien, in heterogenen Systemlandschaften, imple-
mentiert zu werden.
Insbesondere die Integration in spezialisierte kollaborative Systeme, die etablierte Konzepte
des Computer Supported Cooperative Work (CSCW, dt. Computer unterstützte Gruppen-
arbeit) unterstützen, wie z. B. E-Mail-, Workflow- oder Projektmanagement-Werkzeuge, ist
notwendig. Eine Abgrenzung zwischen den etablierten CSCW-Konzepten und den Aktivitä-
17 Vgl. etwa [Kuutti 1991], [Nardi 1996], [Engeström/Miettinen/Punamäki 1999], [Geyer et al. 2003],
[Bertelsen/Korpela/Mursu 2004], [Moran 2005] oder [Kaptelinin/Nardi 2006].
6
ten-zentrischen Konzepten ist vorzunehmen. Die vollständige Integration aller notwendigen
Werkzeuge soll zu einer Überwindung der vorherrschenden Werkzeug-zentrischen Wahr-
nehmung des kollaborativen Arbeitsplatzes beitragen. Der Wandel zu einer Aktivitäten-
zentrischen Wahrnehmung erlaubt es den Anwendern, ihre Aufmerksamkeit der Strukturie-
rung und der Verbesserung der sie betreffenden Geschäftsabläufe sowie dem Bearbeiten ihrer
Aktivitäten widmen zu können. Dazu muss die Struktur der Aktivitäten zunächst expliziert
werden können. Dies ermöglicht neben dem Management von Aktivitäten die Reflexion von
Ad-hoc-Tätigkeiten und eröffnet Verbesserungspotenzial bei der Bearbeitung. Auch beim
Explikationsprozess ist eine Werkzeugunterstützung notwendig. Diese soll die notwendige
Zeit zur Explikation der Aktivitätsstruktur soweit wie möglich reduzieren und maximiert
damit die Arbeitszeit, die für die eigentliche Bearbeitung der zur Aktivität gehörenden Doku-
mente zur Verfügung steht.
Einige Funktionalitäten der zu entwickelnden Architektur werden nicht für alle Anwendungs-
fälle notwendig sein. In Abhängigkeit vom Einsatzszenario sollen daher außerdem Entschei-
dungshilfen für den Unternehmenseinsatz bereitgestellt werden, um bei der Festlegung
benötigter Funktionalitäten, in Abhängigkeit von individuellen Rahmenbedingungen des
Unternehmens, zu unterstützen. Die zu entwickelnden Szenarien sollen so zeigen, wie das
Konzept und die entworfene Architektur für den Praxiseinsatz anzuwenden sind. Für ein
Beispielszenario soll die Architektur außerdem exemplarisch auf Basis der Entscheidungshilfe
prototypisch umgesetzt werden.
Die Ziele der Arbeit lassen sich wie folgt zusammenfassen:
• Diskussion der Tätigkeiten am kollaborativen Arbeitsplatz unter besonderer
Berücksichtigung der Tätigkeitstheorie und betriebswirtschaftlicher Rahmen-
bedingungen.
• Anforderungsanalyse für ein Framework zum individuellen und kollaborativen
Aktivitätenmanagement unter besonderer Berücksichtigung von Ad-hoc-Tätigkeiten.
• Entwurf eines ganzheitlichen Modells zur Explikation von Aktivitätsstrukturen, um
Verbesserungspotenzial bei der Bearbeitung von Aktivitäten zu erschließen sowie
deren Planung und Koordination zu ermöglichen.
• Entwurf einer Architektur zur Unterstützung des individuellen und kollaborativen
Aktivitätenmanagements und Schaffung eines zentralen, personalisierten Zugriffsbe-
reichs (Single Point of Access) zu allen für eine Aktivität relevanten Dokumenten.
7
• Diskussion des entwickelten Modells und der Architektur anhand von Beispiel-
szenarien, als Leitfaden zur praktischen Anwendung der Ergebnisse der Arbeit.
• Implementierung eines Werkzeugs zum individuellen und kollaborativen
Aktivitätenmanagement für ein ausgewähltes Beispielszenario.
1.3 Ausrichtung und Aufbau der Arbeit
Die vorliegende Arbeit ist im Forschungsfeld der gestaltungsorientierten Wirtschaftsinforma-
tik positioniert. Die gestaltungsorientierte Wirtschaftsinformatik ist die Lehre von der Erklä-
rung und Gestaltung betrieblicher Informationssysteme.18 Als Realwissenschaft mit starkem
Praxisbezug ist sie in der Schnittmenge zwischen den Wirtschaftswissenschaften und der
Informatik angesiedelt. Ein Ziel der Forschungstätigkeit ist die Verbesserung betriebswirt-
schaftlicher Abläufe und die Unterstützung unternehmerischer Entscheidungen durch Infor-
mations- und Kommunikationstechnologien, um den Erfolg und die Wettbewerbsfähigkeit
von Unternehmen zu steigern. Häufig geschieht dies durch die Senkung von Kosten bei der
Herstellung von Gütern, Informationen oder Dienstleistungen oder durch die Steigerung deren
Qualität.
Fischer et al. unterscheiden drei Anwendungsfelder betrieblicher Informationssysteme:
betriebswirtschaftliche Informationssysteme, Büro-Informationssysteme und technische
Informationssysteme.19 Diese Arbeit befasst sich mit Systemen im Umfeld von Büro-
Informationssystemen. Aufgrund der abnehmenden Bedeutung klassischer, physischer
Büroumgebungen in Unternehmen wird diese Systemklasse im Kontext der Arbeit als Kolla-
borations-Informationssystem (engl. Collaboration Information Systems, CIS) bezeichnet
(vgl. Abschnitt 2.3.2).
Zentrale Einflussgrößen der Wirtschaftsinformatik sind Menschen, Tätigkeiten und
Maschinen.20 Der Schwerpunkt der vorliegenden Arbeit liegt im Forschungsbereich
Computer Supported Cooperative Work (CSCW). Die spezifischen Einflussgrößen sind hier
die Aufgabenbearbeitung von Menschen im Kontext betrieblicher Tätigkeiten und die dafür
notwendige Verwaltung und Nutzung geschäftsrelevanter Dokumente in CIS.
Methodisch steht im Rahmen der Arbeit ein operationsanalytisches Forschungskonzept im
Vordergrund. Statt der Falsifizierbarkeit21 tritt dabei das Kriterium der praktischen Umset-
18 Vgl. [Mertens et al. 2005], S. 3 und [Fischer et al. 2002], S. 5.
19 Vgl. [Fischer et al. 2002], S. 5.
20 Vgl. etwa [Mertens et al. 2005], S. 5 oder [Heinrich 2001], S. 16.
21 Zur Notwendigkeit der Falsifizierbarkeit von Hypothesen vgl. etwa [Lakatos 1982], S. 7 ff., oder [Ulrich/Hill
1979], S. 175 ff.
8
zung von Hypothesen als Kriterium in den Vordergrund. Diese so genannte Aktionsforschung
(engl. Action Research) stellt eine enge Verbindung aus empirischer Forschung und prakti-
schem Handeln dar.22 Charakteristisch für Aktionsforschung sind u. a. die Verbindung von
Wissenschaft und Praxis, die Partizipation von Praktikern und Anwendern sowie der zykli-
sche Prozess der Forschungstätigkeit.23 Der Zugang zum Erkenntnisobjekt erfolgt dabei über
die Modellierung und eine evolutionäre Verbesserung des Modells durch Zyklen aus prototy-
pischer Implementierung und Modifikation. Die Implementierung dient der Verifikation der
Realisierbarkeit und der vereinfachten Identifikation von Verbesserungspotenzial des
Modells.
Die Modellbildung erfolgt durch Abgrenzung relevanter Systeme unter Berücksichtigung der
aktuellen Situation von Unternehmen als Ausgangslage und bezieht insbesondere die ursäch-
lichen psychologischen Zusammenhänge menschlicher Tätigkeiten im betrieblichen Umfeld
sowie organisatorische Rahmenbedingungen und ökonomische Ziele mit ein. Daher bilden
Veröffentlichungen im Umfeld von CSCW, HCI, Tätigkeitstheorie, Organisationslehre und
Institutionenökonomik im Rahmen von Sekundärforschung eine Fundierung der Modellbil-
dung. Die vorliegende Arbeit stellt das Ergebnis des evolutionären Modellbildungsprozesses
im Laufe des Forschungsprojekts dar, das am Forschungsprozess in der handlungsorientierten
Betriebswirtschaftslehre nach Ulrich/Hill24 orientiert ist.
Im Anschluss an dieses Einführungskapitel stellt Kapitel 2 das Ergebnis der terminologisch-
deskriptiven Studien dar. Es dient der Entwicklung eines Begriffsapparats für ein als Unified
Business Activity Management (UBAM) bezeichnetes Konzept-Framework sowie der Ab-
grenzung zu etablierten Kollaborationskonzepten. Diese sind Werkzeug-zentrisch, da sie für
spezielle Klassen kollaborativer Tätigkeiten jeweils spezialisierte Werkzeuge vorschlagen.
Daher wird in Kapitel 3 die im Unternehmensumfeld heute typischerweise vorhandene
Werkzeugunterstützung von Tätigkeiten am kollaborativen Arbeitsplatz diskutiert. Die
Diskussion erfolgt empirisch-induktiv25, aufbauend auf dem Ergebnis der Literaturstudie,
zahlreichen Projekterfahrungen mit kollaborativen Technologien am Groupware Competence
Center der Universität Paderborn (GCC)26 und der Kenntnis des Marktes für kollaborative
Technologien. Das Ergebnis der Diskussion, in der aktuelle Unternehmenstrends und gesell-
22 Vgl. [Ulrich/Hill 1979], S. 178 ff.
23 Vgl. [Probst/Raub 1995], [McNiff/Whitehead 2005], S. 111 ff. oder [Kock 2007].
24 Vgl. [Ulrich/Hill 1979], S. 181 ff.
25 Empirische Untersuchungen erfolgen lediglich im Sinne der Beobachtbarkeit und Überprüfbarkeit von
Hypothesen an der Wirklichkeit. Statistisch-empirische Untersuchungen werden nicht vorgenommen.
26 Leitung: Prof. Dr. Ludwig Nastansky.
9
schaftliche Entwicklungen Berücksichtigung finden, ist die Identifikation von Lücken in der
Werkzeugunterstützung kollaborativer Arbeit.
Die Kenntnis dieser Lücken ermöglicht die Formulierung der Forschungs- und Praxislücke,
die zum zentralen Konzeptkapitel 4 der Arbeit überleitet. Nach der Diskussion von Nutzendi-
mensionen der Werkzeugunterstützung und der Herleitung von Grundannahmen für kollabo-
ratives Aktivitätenmanagement erfolgt eine Analyse der Anforderungen an eine UBAM
Architektur unter funktionalen und technischen Gesichtpunkten. Basierend auf den Anforde-
rungen erfolgen analytisch-deduktiv die Konstruktion des Modells und der Architekturent-
wurf für ein UBAM Framework. Die Architektur stellt das Ergebnis eines evolutionären
Forschungsprozesses im Rahmen des am GCC durchgeführten Forschungsprojektes
Contextual Collaborative Workplaces (CCW) dar.
Als Abbildung der diskutierten Anforderungen ist die im Rahmen des Forschungsprojekts
entwickelte Architektur als Maximalmodell anzusehen. Eine vollständige Implementierung
der Architektur ist nicht in allen Unternehmensszenarien ökonomisch sinnvoll. Daher findet
in Unterkapitel 4.7 eine Transformation des Maximalmodells in Szenario-spezifische Hand-
lungsanweisungen statt, indem eine Auswahl von Funktionen sowie deren Priorisierung
vorgenommen wird. Dies gibt für die Anwendung des Modells in der Praxis Hilfestellung bei
der Frage, welche Architekturmerkmale in Abhängigkeit von einem konkreten Szenario
bevorzugt berücksichtigt werden sollten.
In Kapitel 5 erfolgt die Beschreibung der Implementierung ausgewählter Architekturmerk-
male für ein spezifisches Einsatzszenario eines Aktivitätenmanagement-Werkzeugs. Die
Überprüfung des Modells erfolgt empirisch-induktiv und dient der Verifikation der Realisier-
barkeit des Modells. Da keine vollständige Implementierung durchgeführt wurde, erfolgte die
evolutionäre Modellverbesserung lediglich für die implementierten Architekturmerkmale. Das
abschließende Kapitel 6 fasst die Ergebnisse der Arbeit zusammen, unterzieht sie einer
kritischen Würdigung und bietet einen Ausblick auf mögliche zukünftige Forschungsfelder.
10
2 Grundlagen und Definitionen
Dieses Kapitel fasst die Ergebnisse der terminologisch-deskriptiven Studien zusammen, die
während des Forschungsprojekts durchgeführt wurden. Es schafft eine Abgrenzung des
Forschungsgebietes der vorliegenden Arbeit in Bezug auf etablierte CSCW-Konzepte. Es
umfasst außerdem die Definition relevanter Begriffe wie Aktivität, Werkzeug und Ansichten
und zeigt die Entwicklung von auf Tätigkeitstheorie basierenden Forschungsansätzen auf.
Zudem erfolgt eine Erläuterung weiterer relevanter Begriffe wie Wissen, Informationen und
Kontexte sowie die Definition und Erläuterung der Bedeutung von IT-Artefakten, insbeson-
dere von Dokumenten.
2.1 Relevante ökonomische Konzepte
Bei der Produktion von Gütern und Dienstleistungen in Unternehmen ist es stets das Ziel, den
Gewinn aus der unternehmerischen Tätigkeit (Residualeinkommen) zu maximieren. Für die
Durchführung von Produktionsprozessen sind Produktionsfaktoren notwendig. Klassische
Produktionsfaktoren sind z. B. menschliche Arbeit, Betriebsmittel und Werkstoffe. Das
Ergebnis des Prozesses stellen die Produkte dar. Der Begriff Produkt wird im Weiteren als
unspezifischer Überbegriff für Güter, Dienstleistungen, Informationen und ähnliches verwen-
det. In den folgenden Abschnitten werden die Aspekte der Produktions- und Kostentheorie
sowie der Teamproduktion erläutert, die für den Kontext dieser Arbeit relevant sind.
2.1.1 Produktivität
Eine wichtige Kennzahl für die Bewertung von Produktionsprozessen in der Produktionswirt-
schaft ist die Produktivität. Die Produktivität „[…] stellt das Verhältnis zwischen der
Ausbringungsmenge und der Faktoreinsatzmenge dar […].“27 Da die Produktivität lediglich
auf eine Faktorart Bezug nimmt, können unterschiedliche Produktivitätskennzahlen berechnet
werden, wie z. B. die für den Kontext dieser Arbeit besonders relevante Arbeitsproduktivität.
Als Mengen-orientierte Kennzahlen haben Produktivitätskennzahlen jedoch eine geringe
Aussagekraft, da die Qualität des Produkts nicht berücksichtigt wird. Qualitativ höherwertige
Produkte können potenziell einen höheren Verkaufserlös erzielen.28 Daher wird häufig die
Produktivität im weiteren Sinne auch als Mengen/Wert-Relation beschrieben.
Nach dieser Betrachtung tritt eine Produktivitätsverbesserung ein, wenn sich der Wert eines
Produkts als Ergebnis der Tätigkeit geteilt durch den betrachteten Faktor steigern lässt. In
Bezug auf die Arbeitsproduktivität bedeutet dies, dass eine Tätigkeit gegenüber einem Aus-
27 Vgl. [Bloech 2004], S. 10.
28 Vgl. [Zahn/Schmid 1996], S. 74 f.
11
gangszustand bei konstanter Qualität des Produktes in geringerer Zeit durchgeführt werden
kann, oder dass die Qualität des Produktes je eingesetzter Arbeitszeit zunimmt. Maßgebliche
Faktoren bei der Berechnung von Arbeitsproduktivität sind also Arbeitseinsatz, Ausbrin-
gungsmenge und Qualität der hergestellten Produkte. Wird die Faktoreinsatzmenge verändert,
so ändert sich auch das Ergebnis und somit der Ertrag. Das Verhältnis zwischen Ertragszu-
wachs und Faktoreinsatzänderung an der Grenze des Faktoreinsatzes wird als Grenz-
produktivität bezeichnet.29
Da Produktionswirtschaft nicht im Fokus dieser Arbeit steht, soll eine möglichst einfache
Definition für Produktivität gewählt werden. Die Qualität wird daher als konstant definiert.
Eine Verbesserung der Produktivität eines Produktionsprozesses liegt demnach immer dann
vor, wenn im Vergleich zu einem Ursprungsprozess die gleiche Menge eines Produkts bei
gleicher Qualität, unter Einsatz einer geringeren Arbeitsmenge produziert wird.30 Ist eine
andere Produktivitätskennzahl gemeint, die beispielsweise eine Qualitätssteigerung als
Variable berücksichtigt, wird explizit darauf hingewiesen.
2.1.2 Transaktionskosten
Unter Transaktionskosten werden im Rahmen dieser Arbeit die Kosten der Anbahnung und
Durchsetzung von Verträgen verstanden.31 Kosten für die Anbahnung können durch die
Suche nach Informationen über ein bestimmtes Produkt, oder den Aufwand des Vergleichs
verschiedener ähnlicher Produkte im Vorfeld der Durchführung einer Leistungsübertragung
entstehen. Auch evtl. notwendige Verhandlungen über den Preis oder die Gestaltung weiterer
Vertragsbedingungen für die Übertragung einer Leistung verursachen Kosten, etwa durch die
aufgewendete Arbeitszeit oder Reisetätigkeiten zum Verhandlungsort. Beim Kauf eines Autos
sind dies etwa Kosten für die Suche nach geeigneten Fahrzeugmodellen und möglichen
Verkäufern, die Durchführung von Probefahrten und das Einholen von alternativen
Angeboten. Nach Vollzug der Transaktion ist diese durchzusetzen, es entstehen Durch-
setzungskosten. Dieser Vorgang umfasst etwa Kontrollkosten, Änderungskosten, Gewähr-
leistungsdurchsetzungskosten und Abwicklungskosten. Auf das konkrete Beispiel Autokauf
bezogen umfasst dies die Lieferung des Autos, die Prüfung ob das Fahrzeug dem gekauften
entspricht und die Prüfung der Funktionsfähigkeit des Fahrzeugs. Eine Transaktion wird als
effizient bezeichnet wenn die Vertragspartner sie so gestalten, dass die kumulierten Trans-
aktionskosten minimiert werden.
29 Vgl. [Gutenberg 1983], S. 306 ff.
30 Vgl. auch Produktivitätsdefinition von [Krcmar 2005], S. 397 ff.
31 Die Transaktionskostentheorie geht auf [Coase 1937] zurück.
12
Wichtige Charakteristika für Transaktionen sind die Spezifität und die Transaktionshäufigkeit.
Der Spezifitätsgrad einer Transaktion ist umso höher, je größer der Wertverlust von zur
Vertragserfüllung erforderlichen Ressourcen ist, wenn der Vertrag beendet wird. Wenn
beispielsweise zwei Unternehmen im Rahmen einer Kooperation eine spezielle Individual-
software entwickeln müssen, die den elektronischen Austausch von Daten zwischen den
Vertragspartnern ermöglicht, wird die Software wertlos, wenn die Kooperation endet. Die
Transaktion hat also einen hohen Spezifitätsgrad. Ist es zur Durchführung der Kooperation
hinreichend, den Datenaustausch mit einer Standardsoftware durchzuführen, die zudem auf
einem standardisierten Synchronisationsprotokoll basiert, kann diese Software mit jedem
beliebigen Kooperationspartner eingesetzt werden. Die Spezifität der Transaktion ist somit
gering.
Neben der Spezifität hat die Transaktionshäufigkeit Einfluss auf die ökonomische Vorteil-
haftigkeit von vertraglichen Beziehungen. Wird eine gleiche oder sehr ähnliche Leistungs-
übertragung zwischen Vertragspartnern sehr häufig durchgeführt, so ergeben sich Möglich-
keiten der Vertragsgestaltung durch die die kumulierten Transaktionskosten aller
Transaktionen verringert werden können. Bei einer fallweisen Abwicklung über den Markt
würden Transaktionskosten für jede einzelne Transaktion entstehen, während es etwa durch
Rahmenverträge ermöglicht wird, dass lediglich einmal ein Großteil der Transaktionskosten
anfällt. So kann auch eine ggf. höhere Spezifität der Transaktion in Kauf genommen werden.
Die Transaktionskostentheorie liefert Empfehlungen für die Abwicklung von Leistungsüber-
tragungen und die Gestaltung von Verträgen. Sie ist auch geeignet für die Betrachtung des
Einflusses von Informationstechnologie auf die Durchführung von Transaktionen. So kann
Informationstechnologie etwa durch die effiziente Bereitstellung von Informationen die
Kosten für die Durchführung von Transaktionen senken. Durch den Einsatz von Standard-
software kann die Spezifität gesenkt werden. Für weiterführende Informationen zur Transak-
tionskostentheorie siehe [Coase 1937], [Williamson 1975], [Picot/Dietl/Franck 2005], S. 56
ff. oder [Erlei/Leschke/Sauerland 1999], S. 69 ff.
2.1.3 Arbeitsverhalten in Teams
Bei industriellen Produktionsprozessen steht eine hohe Wiederholung von Tätigkeiten,
Arbeitsteilung in gut strukturierten Prozessen und die exakte Beschreibbarkeit von Tätigkei-
ten im Vordergrund. Die Problemlösungskompetenz der Arbeiter steht in diesem Umfeld für
qualitativ hochwertige Arbeitsergebnisse nicht im Vordergrund. Dies gilt nicht für den
kollaborativen Arbeitsplatz. Insbesondere die exakte Beschreibung von Tätigkeiten ist in den
13
Profilen moderner Arbeitsplätze häufig nicht gegeben. Wenn die Tätigkeiten spontan anfallen
und sich nicht häufig wiederholen, setzen sie eine hohe Entscheidungskompetenz der Mitar-
beiter voraus. Eine exakte Beschreibung und fremdbestimmte Planung dieser Tätigkeiten ist
dann nicht wirtschaftlich.
Es gibt zudem Prozesse die eine höhere Produktivität aufweisen, wenn die Tätigkeiten nicht
auf einzelne Individuen verteilt werden, sondern wenn die Produktion kooperativ32 im Team
stattfindet. Insbesondere zur Verbesserung der Qualität von Leistungen in kreativen Prozessen
ist Teamarbeit wichtig. Durch Brainstorming oder Techniken wie Open Space33 wird die in
Teamprozessen entstehende Kreativität genutzt. Diese Art von Produktionsprozessen steht im
Kontext dieser Arbeit im Vordergrund. Das Produkt wird durch mehrere Personen produziert
und der wertmäßige Einsatz des Produktionsfaktors menschliche Arbeit überwiegt gegenüber
anderen Produktionsfaktoren. Als Teamproduktion wird ein Produktionsprozess bezeichnet,
wenn mindestens zwei Individuen an der Produktion beteiligt sind und mehrere Arten von
Produktionsfaktoren mit unterschiedlichen Faktoreigentümern eingesetzt werden, z. B.
spezifisches Wissen oder besondere Kreativität eines Individuums.
Charakteristisch für Teamproduktion ist zudem, dass die Leistung des Teams nur als Ganzes
gemessen werden kann. Die Bestimmung einer Summe aus Einzelleistungen der Faktor-
eigentümer ist nicht möglich, da „[…] die Grenzproduktivität des Einsatzes eines Faktors von
der eingesetzten Menge eines anderen Faktors abhängt.“34 Auch ist eine exakte Bestimmung
des Faktoreinsatzes der Teammitglieder nicht wirtschaftlich möglich, da die exakte Messung
durch Beobachtung der anderen Teammitglieder Kosten verursacht. Diese Kosten werden als
Messkosten bezeichnet, sie mindern die Gesamtproduktivität des Teams. Da keine exakte
Messung erfolgt liefert die Beobachtung anderer Teammitglieder daher lediglich Indikatoren
für den tatsächlichen Faktoreinsatz.
Wird Opportunismus unterstellt führt die unvollkommene Kontrolle dazu, dass einzelne
Teammitglieder zum Nachteil des Teams Arbeit gezielt vermeiden. Dieses Verhalten wird als
Shirking bezeichnet. Alchian und Demsetz schlagen zur Lösung dieser Problematik vor, dass
sich ein Teammitglied auf die Überwachung der Faktoreinsätze spezialisiert.35 Um Shirking
beim Überwacher vorzubeugen, erhält dieser die Nettogewinne der Teamproduktion (Residu-
aleinkommen) und wird damit zum Unternehmer. Zwischen dem Überwacher und den
Teammitgliedern werden formelle oder informelle Verträge mit Sanktionsmöglichkeiten für
32 Auf kooperative Arbeit wird detaillierter in Abschnitt 2.3.1 eingegangen.
33 Vgl. [Owen 2001].
34 Vgl. [Erlei/Leschke/Sauerland 1999], S. 70 ff.
35 Vgl. [Alchian/Demsetz 1972] S. 781 ff.
14
beobachtetes Shirking geschlossen. Die Überwachungstätigkeit kann der Unternehmer durch
Beauftragung an Mitarbeiter übertragen. So wird das Wesen der Firma durch Alchian und
Demsetz als ein Netzwerk von Verträgen erklärt.
Auch in der Agenturtheorie stehen Verträge im Fokus der Betrachtung. Die Agenturtheorie
erklärt arbeitsteilige Beziehungen zwischen Auftraggeber (Principal) und Auftragnehmer
(Agent). Da der Principal über das Verhalten des Agenten nur unvollkommen informiert ist,
entsteht eine Informationsasymmetrie, die Spielraum für opportunistisches Verhalten des
Agenten eröffnet.36 Die Informationsasymmetrie kann durch verschiedene Maßnahmen, wie
dem Einsatz von Informationstechnologie, reduziert werden. Principal-Agent-Beziehungen
bestehen z. B. zwischen Teamleiter und Team. Handelt es sich beim Agenten um ein Team,
hat die Agenturtheorie auch für die Teamproduktion Relevanz.
Die Erklärung des Verhaltens von Individuen bei der Leistungsübertragung oder der kollabo-
rativen Teamproduktion durch implizite oder explizite Verträge spielt im Kontext dieser
Arbeit eine wichtige Rolle. Insbesondere die Reduzierung von Transaktions- und Messkosten
sowie der Abbau von Informationsasymmetrie und weitere Maßnahmen zur Reduzierung des
Agenturproblems sollen durch den Einsatz von Werkzeugen zum Aktivitätenmanagement
unterstützt werden.
2.2 Informationstechnologie als Artefakt
2.2.1 Artefakte
Ein Artefakt ist ein von Menschen geschaffenes Objekt. Artefakte dienen dazu, die physi-
schen und kognitiven Fähigkeiten von Menschen zu erweitern, und das Wissen um die
Unterstützungsmöglichkeiten an andere Menschen und nachfolgende Generationen weiter-
zugeben. Artefakte deren Zweck es ist, Informationen zu bewahren, anzuzeigen oder mit
ihnen zu interagieren werden als kognitive Artefakte bezeichnet.37 Sie ermöglichen komplexe
Operationen, indem mit ihrer Hilfe Zustandsinformationen expliziert werden. Keil-Slawik
spricht von der Verwendung von Artefakten als externes Gedächtnis38. Nur mit Hilfe kogniti-
ver Artefakte ist es dem Menschen möglich, Informationen über größere Handlungssequenzen
miteinander in Beziehung zu setzen.
Soll beispielsweise eine komplexe mathematische Berechnung durchgeführt werden, so muss
der Rechenvorgang verschriftlicht werden. Das erzeugte kognitive Artefakt „beschriebenes
36 Vgl. [Picot/Reichwald/Wigand 2003], S. 55 ff.
37 Vgl. [Norman 1991].
38 „Artifacts as external memory“, vgl. [Keil-Slawik 1992], S. 179 ff.
15
Blatt Papier“ dient dazu, Zwischenergebnisse festzuhalten. Dies ermöglicht es dem Menschen
zudem, den Rechenweg zu reflektieren sowie die Vorgehensweise mit anderen Menschen zu
diskutieren. So können Möglichkeiten zur Verbesserung der Vorgehensweise identifiziert,
oder ein intersubjektiver Konsens erreicht werden, um erprobte und bewährte Vorgehens-
weisen zu standardisieren. Durch die Explikation von mentalen Vorgängen in Form eines
Artefakts wird auch die Übertragung von Informationen zwischen Subjekten ermöglicht,
wenn eine direkte Kommunikation etwa durch Sprache nicht möglich ist. Informationsüber-
tragung ist die Voraussetzung für die effiziente Konstruktion von Wissen39.
Wird ein Artefakt als Mediator für die Transformation eines Objektes verwendet, so wird es
als Werkzeug bezeichnet. Erfolgt beispielsweise die Explikation von Gedanken eines Men-
schen durch das Beschriften eines Blattes Papier, so wird das leere Blatt mithilfe des Werk-
zeugs „Stift“ in ein beschriftetes Blatt transformiert. Das transformierte Objekt dient wie-
derum als externes Gedächtnis zur Konservierung kultureller Errungenschaften, ist also durch
die Transformation zum kognitiven Artefakt geworden. Auch wenn prinzipiell jedes Artefakt
als Werkzeug eingesetzt werden kann, so gibt es doch Artefakte deren primärer Zweck eine
Verwendung als Werkzeug ist, z. B. ein Hammer oder ein Stift. Ein Artefakt wird durch die
mit ihm durchgeführte Tätigkeit zu einem Werkzeug.
Die Interaktion mit Artefakten erfolgt in Abhängigkeit von kulturellen, zeitlichen und lokalen
Parametern. Das bedeutet, dass sich die Funktion eines Werkzeugs einem Betrachter u. U. nur
durch Kenntnis des Anwendungskontextes sowie durch Beobachtung der bestimmungs-
gemäßen Anwendung erschließt. Dies ist etwa der Fall wenn Handlungen durchgeführt
werden, die einem spezifischen Kulturkreis oder einer bestimmten Epoche zugehörig sind.40
Ein Beispiel ist die Verwendung von Holzstäbchen als Esswerkzeug in asiatischen Kultur-
kreisen. Ohne vorherige Beobachtung erschließt sich die Bestimmung der Holzstäbchen in
anderen Kulturkreisen nicht.
Ein kognitives Artefakt, das primär als Informationsträger dient, wird im Kontext dieser
Arbeit als Dokument bezeichnet. Dokumente werden in der Regel nicht als Werkzeug einge-
setzt. Beispiele für Dokumente sind ein Foto, ein beschriftetes Blatt Papier oder eine Datei41
in einem Informationssystem. Auch für Dokumente gilt die Abhängigkeit vom sozio-
kulturellen Kontext. So können explizierte Informationen nur verstanden werden, wenn sie in
einer Sprache kodifiziert sind, die der aktuelle Rezipient der Information verstehen kann. In
39 Auf die Kontruktion von Wissen wird detailliert in Abschnitt 2.3.2.3 eingegangen.
40 Vgl. [Bannon/Bødker 1991], S. 237 f.
41 Gemeint ist eine Datei mit Informationen, die für Anwender gedacht sind, etwa ein PDF Dokument oder die
Datei einer Tabellenkalkulation.
16
der Regel ist neben der Sprache für das Verstehen von Informationen auch die Kenntnis nötig,
in welchem zeitlichen und kulturellen Kontext diese verfasst wurden. Kontexte haben für
Dokumente also eine wichtige Bedeutung. Für die Konservierung von Informationen über
zeitliche und kulturelle Grenzen hinweg ist es daher hilfreich, auch Informationen über diesen
Kontext zu explizieren, da die Bedeutung der Informationen sonst unter Umständen durch den
Rezipienten nicht wieder hergestellt werden kann. Auch macht die Verfügbarkeit von
Kontextinformationen das Verständnis der Informationen einfacher und effizienter.
Bei der Übertragung dieser Ausführungen auf Informationssysteme ist die Granularität der
Betrachtungsweise des Informationssystems von Bedeutung. In der wissenschaftlichen
Literatur wird der Computer vielfach als monolithische Einheit aus Hard- und Software
angesehen.42 Dieses Prinzip der „Black-Box“ ist jedoch nicht zielführend, wenn die Inter-
aktion zwischen Mensch und Maschine Gegenstand der Untersuchung ist. Vielmehr muss
eine dedizierte Betrachtung einzelner Elemente des Gesamtsystems erfolgen, mit denen
Interaktion möglich ist. So lässt sich die Arbeitsumgebung, die der Computer visualisiert als
virtuelle Umwelt beschreiben, in der Menschen bei der Interaktion ihre tradierten Erfahrungen
aus der physischen Umwelt im Umgang mit elektronischen Artefakten einsetzen können. Der
Umgang mit Werkzeugen und Dokumenten erfolgt also in einer virtuellen Umgebung zu-
nächst analog zur physischen. Es existieren elektronische Artefakte, die Werkzeugcharakter
aufweisen, elektronische Dokumente, und eine virtuelle Umwelt mit inhärenten Objekt-
charakteristika. Die genannten Elemente werden als IT-Artefakte bezeichnet.
Die Annahmen über die Abhängigkeit von kulturellen, zeitlichen und lokalen Kontextpara-
metern bei der Interaktion mit Artefakten treffen auch auf IT-Artefakte zu. Daraus resultiert
insbesondere die Annahme, dass Informationstechnologie nicht weltweit mit der gleichen
Interpretation von Eigenschaften eingesetzt wird, und somit an unterschiedlichen Orten und in
verschiedenen kulturellen Kontexten, unterschiedlich verwendet, und eine Funktion von
verschiedenen Personen auch unterschiedlich interpretiert werden kann.43 Beispielsweise
kann ein Pfeil nach links für die Operation „Rückgängig“ falsch interpretiert werden, wenn im
Kulturkreis des aktuellen Anwenders eine linksläufige Schrift üblich ist. Auch der Grad der
Ausbildung und der Übung des Anwenders bestimmt den Umgang mit Artefakten, so dass
auch Personen des gleichen Kulturkreises in Abhängigkeit von ihrem Wissensstand mit
Artefakten unterschiedlich agieren, und auch unterschiedliche Bedürfnisse an Werkzeuge
42 Vgl. [Orlikowski/Lacono 2001], S. 122.
43 „[…] technologies such as the Internet and other distributed applications do not provide the same material
and cultural properties in each local time or context of use.“ Vgl. [Orlikowski/Lacono 2001], S. 132.
17
haben. Hinzu kommen zeitliche Parameter, die ebenso die Bedeutung von Informationen und
die durch den Anwender antizipierten Charakteristika von Werkzeugen bestimmen.
2.2.2 Elektronische Dokumente
2.2.2.1 Eigenschaften
Anders als beispielsweise ein beschriebenes Blatt Papier sind elektronische Dokumente für
den Anwender nur mittelbar zugänglich. Sie werden in der virtuellen Umwelt gespeichert, die
der Anwender nicht unmittelbar wahrnehmen kann. Es werden spezielle Werkzeuge als
Vermittler (Mediator) benötigt, um Objekte in der virtuellen Umgebung zu deponieren, zu
identifizieren, zu visualisieren oder zum Zweck der Modifikation zugreifbar zu machen.
Werkzeuge, die einen oder mehrere der genannten Zwecke erfüllen werden als Anwendungs-
programm oder Applikation bezeichnet. Die visuelle Komponente einer Applikation, die etwa
die Darstellung und Modifikation von Dokumenten ermöglicht, ist die Benutzungsschnitt-
stelle (engl. User Interface, UI) der Applikation. Die Komponente des UI, mit der ausschließ-
lich Inhalte eines Dokuments dargestellt und bearbeitet werden können wird als Editor
bezeichnet.
Dokumente sind, wie in Abschnitt 2.2.1 beschrieben, Träger von Informationen. Informa-
tionen entstehen, wenn syntaktisch geordnete Zeichen (Daten) in einen Bedeutungskontext
gestellt werden. Die Kontextualisierung von Daten führt also zur Entstehung von Informa-
tionen. Sind Informationen in Form eines Artefakts als Informationsträger expliziert, liegen
sie in Form von Dokumenten vor.44 Bei der Präsentation eines elektronischen Dokuments am
Bildschirm handelt es sich um eine Montage aus generischen Layoutinformationen, Kon-
textualisierungsregeln und gespeicherten Daten. Die Daten werden durch die Montage in
einen Kontext mit anderen Daten gestellt und erhalten so eine Bedeutung, die durch den
Anwender des Dokuments zuerkannt wird. Die gespeicherten Daten, die Träger dieser Infor-
mationen sind, werden als Dokumenteninhalt oder kurz als Inhalt (engl. Content) bezeichnet.
Die Layoutinformationen bestimmen den Dokumententyp. Charakteristisch für Dokumente
gleichen Typs ist, dass diese im gleichen Bearbeitungsstatus von der gleichen Person als
ähnliche Dokumente erkannt werden, sie sich also außer durch die Daten visuell nicht we-
sentlich von anderen Dokumenten gleichen Typs unterscheiden. Dokumententypen weisen
Charakteristika von gedruckten Formularen auf. Beispiele für unterschiedliche Dokumenten-
typen sind Adressdokumente, Kalendereinträge, Berichte oder eine Steuererklärung. Die
44 Zu weiteren Ausführungen zur Unterscheidung von Daten und Informationen vgl. etwa
[Probst/Raub/Romhardt 2006], S. 15 ff. und [Davenport/Prusak 1998], S. 2 ff.
18
Layoutinformationen können separat verwaltet werden, sie werden dann als Maske bezeich-
net. Die Kontextualisierungsregeln sind in der Maske oder im Werkzeug, das zum Zugriff auf
das Dokument verwendet wird, hinterlegt. Die Rekonstruktion eines Dokuments, und somit
die Kontextualisierung der gespeicherten Daten erfolgt durch Regeln, die bei der Anzeige des
Dokuments Verwendung finden. Regeln können beispielsweise Maskenfelder sein, deren
Position auf der Maske die Kontextinformation für anzuzeigende Daten darstellt. Eine Regel
kann aber auch die Transformation von Daten bewirken. So können beispielsweise mehrere
Zahlen vor der Anzeige summiert, oder ein Datum für einen gegebenen kulturellen Kontext in
eine korrekte Darstellung transformiert werden.
Häufig ist der Inhalt eines Dokuments nur für eine bestimmte Personengruppe innerhalb eines
Unternehmens bestimmt. Während der Zugriff auf Papierdokumente durch physische
Sicherungsmaßnahmen wie Aktenschränke und Büroschlüssel geregelt wird, ermöglicht ein
elektronisches Repository (vgl. Abschnitt 2.2.2.2) üblicherweise dediziertere Zugriffsregeln
für Dokumente. Rechtemechanismen legen fest, wer Zugriff auf das Dokument haben darf,
und welche Operationen dieser mit dem Dokument durchführen darf. Üblicherweise werden
in Repositories etwa die Zugriffsstufen, ‚Kein Zugriff’, ‚Lesezugriff’, ‚Bearbeitungszugriff’
und ‚Recht zu Löschen’ unterschieden.
2.2.2.2 Speicherung in Repositories
Die Speicherung von Dokumentendaten erfolgt in einem Repository. In der Realwelt handelt
es sich dabei um ein spezielles Artefakt, das der Aufbewahrung von Objekten und Artefakten
dient. Im Kontext dieser Arbeit werden ausschließlich elektronische Repositories betrachtet,
die mittelbar und unmittelbar der Aufbewahrung von Daten dienen. Ein elektronisches
Repository, das Dokumente mit für betriebliche Prozesse relevanten Informationen speichert,
wird als Unternehmensrepository bezeichnet. Verkürzt wird im Folgenden für das Unter-
nehmensrepository der Begriff Repository verwendet. Beispiele für Repositories sind ein
Dateisystem eines Computers oder ein Datenbanksystem. Eine Applikation zum Zugriff auf
Dokumente im Dateisystem ist beispielsweise der Windows Explorer, bei einem Datenbank-
system liefert in der Regel der Hersteller des Systems eine entsprechende Applikation. Für
den Zugriff existieren Schnittstellen, etwa ODBC45. So haben Softwarehersteller die Möglich-
keit, dass von ihnen entwickelte Applikationen eine Vielzahl an Repositories verwenden
können, um Daten zu speichern.
45 Open Database Connectivity. Siehe etwa [Bullinger et al. 2002], S. 32.
19
Daten von Dokumenten werden in Feldern gespeichert. Felder dienen beispielsweise der
Speicherung des Namens oder Geburtsdatums einer Person, oder dem Preis eines Produkts.
Felder können einen strukturierten oder einen unstrukturierten Datentyp aufweisen. Struktu-
rierte Datentypen sind beispielsweise Text, Zahl oder Datum. Inhaltsdaten sind jedoch häufig
so kontextreich, dass die Bildung von Kontextualisierungsregeln zur Wiederherstellung der
Informationen aus strukturierten Daten nicht oder nur schwer möglich ist. Diese werden dann
in Kontexteinheit mit den Daten in Feldern gespeichert, die einen generischen Datentyp
aufweisen. Diese Daten werden als unstrukturierte Daten bezeichnet. Beispiele sind Text-
formatierungen, Grafiken oder Dateianhänge. Dokumente können aus einer Kombination von
strukturierten und unstrukturierten Daten bestehen, wobei ein strukturierter Teil notwendig,
und ein unstrukturierter Teil optional ist. Sind beide Typen von Daten enthalten, wird das
Dokument als Verbunddokument (engl. Compound Document)46 bezeichnet.
In der Realwelt besteht ein Dokument in der Regel aus einer physischen Einheit, z. B. einem
Buch oder einer Aktenmappe mit verschiedenen beschrifteten Seiten Papier. In der virtuellen
Umgebung wird dieses Paradigma in gängiger Standardsoftware beibehalten. Ein Dokument
wird dem Anwender als Einheit präsentiert, häufig wird auch das vom Buch her bekannte
Konzept von Buchseiten als Strukturierungsmerkmal erhalten. Die am Bildschirm visuali-
sierten Informationen müssen jedoch nicht in physischer Einheit gespeichert sein. Die Mon-
tage aus Maske und Daten ermöglicht es etwa, ein Dokument aus Daten verschiedener Repo-
sitories zusammenzustellen. Ein elektronisches Dokument kann auch zum Zeitpunkt des
Zugriffs aufgrund von Regeln generiert werden. Wenn die Inhaltsdaten eines Dokuments
nicht in Form eines Datensatzes gespeichert sind, oder wenn der überwiegende Teil von
Inhaltsdaten des Dokuments zum Zeitpunkt der Anzeige dynamisch berechnet wird, wird es
im Kontext dieser Arbeit als virtuelles Dokument bezeichnet.
Für die Speicherung von Informationen eines Dokuments stehen verschiedene Klassen von
Datenbanksystemen zur Verfügung. Übliche Klassen sind relationale Datenbanken, Objekt-
Datenbanken und Dokument-Datenbanken. Relationale Datenbanken speichern Dokumente
nicht in ihrer Gesamtheit, sondern verteilen die in einem Dokument enthaltenen Daten über
mehrere zueinander in Beziehung stehende Tabellen (Relationen). Einer der Gründe für die
Aufteilung auf mehrere Relationen ist das Ziel der redundanzfreien Speicherung. Weisen
mehrere Datensätze gleiche Daten auf, müssen diese nur einmalig gespeichert werden.
Aufgrund der verteilten Speicherung ist die Kontextualisierung der Daten komplex. Zudem
handelt es sich bei Dokumenten, deren Daten in relationalen Datenbanken gespeichert sind,
46 Vgl. [Riempp 1998], S. 20.
20
zumeist um virtuelle Dokumente. Relationale Datenbanken eignen sich besonders gut für die
Speicherung der Daten von Dokumenten mit überwiegend strukturiertem Inhalt.
Objekt-Datenbanken ermöglichen eine umfassende und effiziente Abbildung der Realwelt
und sind daher für die Unterstützung des Objekt-Konzepts von objektorientierten
Programmiersprachen sehr gut geeignet. Sie ermöglichen die einfache Speicherung von
Objekten47 mit komplexen Datenstrukturen und zugehörigen Zustandsinformationen. Es lässt
sich eine direkte Zuordnung von abgebildetem Realwelt-Objekt und dem Objekt in der
Datenbank vornehmen. Wie in der Realwelt können Objekte zueinander in Beziehung stehen,
so dass sich Änderungen an Objekten automatisch auf andere Objekte auswirken können.
Objekte können von anderen Objekten Eigenschaften erben, oder andere Objekte beinhalten.
Je komplexer die abzubildenden Objekte sind, umso komplexer ist die Abbildung in relatio-
nalen Datenbanken umzusetzen. Diese Schwierigkeiten wirken sich unter Anderem auf die
Geschwindigkeit (engl. Performance) der Datenbankzugriffe aus. Objekt-Datenbanken sind
für die effiziente Speicherung und Verwaltung von komplexen und verschachtelten Objekten
entwickelt und optimiert worden.48
Bestimmte Informationstypen eignen sich mit aktuell verfügbaren Technologien nicht für die
redundanzfreie Speicherung, da die Kontextualisierung zu reichhaltig und die Regeln zur
Verteilung auf Relationen zu komplex sind. In Dokument-Datenbanken wird daher das
komplette Artefakt mit allen zugehörigen Daten als Einheit gespeichert. Die dem Dokument
zugrunde liegenden Daten werden also nicht auf Relationen verteilt wie in relationalen
Datenbanken. Bezugnehmend auf die für relationale Datenbanken typische Abfragesprache
SQL werden daher Dokument-Datenbanken auch als No-SQL Datenbanken bezeichnet. Auch
stehen die Dokumente einer Dokument-Datenbank in keiner physischen Beziehung zueinan-
der, wie Objekte in Objekt-Datenbanken.49
Ein Vorteil dieses Datenbanktyps ist die Möglichkeit einer flexiblen Datenstruktur, die in
jedem Dokument unterschiedlich sein kann. Dies führt zu einer großen Flexibilität bei der
Kontextualisierung von Daten. Dokument-Datenbanken eignen sich daher besonders für die
Speicherung kontextreicher Informationen.50 Auch das Dateisystem gängiger Desktop
47 Der Begriff „Objekt“ wird hier im Sinne der objektorientierten Programmierung verwendet. Bei den zu
speichernden „Objekten“ handelt es sich um IT-Artefakte im Sinne von 2.2.1.
48 Für detaillierte Informationen zu relationalen und Objekt-Datenbanken sowie Vergleiche zwischen den
Datenbanktypen vgl. [Smith/Zdonik 1987] oder [Staud 2005].
49 Eine Beziehung zwischen den Dokumenten kann durch Werkzeuge jedoch in der Regel programmatisch
hergestellt werden.
50 Für weitere Ausführungen zu Dokument-Datenbanken vgl. [Kawell et al. 1988] und [Moore 1995] sowie
http://couchdb.apache.org [07.10.2011].
21
Betriebssysteme ist konzeptionell Dokumenten-orientiert. Das Dokument wird als Datei in
einer Einheit gespeichert.
Abbildung 2-1: Beispiel für eine hybride Datenbank Technologie51
Außerdem existieren hybride Systeme als Mischformen der zuvor genannten Datenbank-
formen wie z. B. eine Mischung aus relationaler und Dokument-Datenbank. Abbildung 2-1
illustriert, wie sich durch eine hybride Technologie die Vorteile zweier Datenbankklassen
nutzen lassen. A und B sind Dokument-Datenbanken, die kein SQL unterstützen. Wenn nun
Daten aus mehreren Repositories in einer Art kombiniert werden sollen, die nur in SQL
möglich ist, wird eine Hybridtechnologie benötigt. Durch die teilweise redundante Spei-
cherung von Daten aus A und B in der relationalen Datenbank lässt sich beispielsweise eine
SQL-JOIN-Operation durchführen. Für weitere Ausführungen zu der verwendeten Technolo-
gie siehe [Monson et al. 2006]52.
2.2.2.3 Identifikation
Ein generelles Problem bei der Identifikation von Artefakten stellt die Ähnlichkeit dar. So ist
es etwa für einen Autobesitzer schwierig, auf einem Parkplatz mit mehreren Fahrzeugen
gleicher Bauart sein eigenes Fahrzeug zu identifizieren. Ist die genaue Position sowie der
Weg bekannt, wie der Besitzer zu dieser Position gelangen kann, ist die Lokalisierung trivial.
Der Weg von der aktuellen Position des Suchenden bis zur Position des gesuchten Artefakts
wird als Navigationspfad bezeichnet. Ist der Navigationspfad unbekannt, weil der Besitzer
sich nicht mehr an die genaue Abstellposition erinnert, oder das Fahrzeug von jemand
Anderem abgestellt wurde, muss das Auto gesucht werden. Erleichtert wird die Identifikation
51 Modifiziert aus [Nastansky/Erdmann 2005], S. 40.
52 Vgl. [Monson et al. 2006], S. 7 ff.
22
durch Fahrzeugmerkmale wie Farbe und Fabrikat. Sind auch diese und weitere
Ausstattungsmerkmale gleich, ist eine eindeutige Identifikationsnummer (ID) notwendig.
Beim Fahrzeug ist dies beispielsweise die Fahrgestellnummer oder das Autokennzeichen.
Eine solche eindeutige Kennnummer wird als Artefakt-ID bezeichnet. Die Artefakt-ID kenn-
zeichnet ein Artefakt jedoch lediglich innerhalb einer bestimmten Domäne, sie ist also nicht
eindeutig über die Menge aller Artefakte. So umfasst etwa die Domäne Autokennzeichen
einen Großteil aller PKW und LKW, die weltweit zum Straßenverkehr zugelassen wurden. In
einer anderen Domäne kann ein Kennzeichen wie „D-PB-GC-221“ aber vielleicht ein Contai-
nerschiff oder eine Ausweisnummer darstellen. Implizit wird das eindeutige Identifikations-
merkmal für eine Suche also aus der Domäne und der dedizierten Artefakt-ID gebildet. Wenn
ein Mensch ein Fahrzeugkennzeichen wahrnimmt, ist die Domäne „zugelassenes Fahrzeug“
implizit klar. Sie muss also nicht stets explizit angegeben werden.
Beim Zugriff auf ein Artefakt ist es für eine effiziente Lokalisierung hilfreich, mehrere
Informationen wie Navigationspfad, Domäne und ID zu kennen. Ist der Navigationspfad
bereits so präzise, dass eine Position lokalisiert werden kann, an der sich lediglich ein Arte-
fakt befindet, ist weder die Kenntnis einer dedizierten ID, noch der Domäne notwendig. In der
Regel gibt es eine Vielzahl von Navigationspfaden, über die ein Artefakt erreicht werden
kann. Ist kein Navigationspfad bekannt, muss wiederum eine Suche nach dem Artefakt
durchgeführt werden. Unter Kenntnis der Domäne können alle Autos identifiziert werden.
Jedes Auto kann dann auf das gesuchte Kennzeichen überprüft werden, bis das gesuchte
Artefakt identifiziert ist. Eine ID muss nicht dediziert in Form eines speziellen Datums
vergeben werden, sie kann auch aus einer Kombination von Eigenschaftsdaten bestehen
sofern sichergestellt werden kann, dass es kein weiteres Artefakt gibt, das die gleiche Eigen-
schaftskombination aufweist.
Jede Kombination aus Navigationspfad, Domäne oder ID, die ein IT-Artefakt eindeutig
adressiert wird als Uniform Resource Identifier (URI)53 bezeichnet. Dabei kann ein IT-Arte-
fakt durch eine oder mehrere unterschiedliche URI adressiert werden, wenn z. B. unterschied-
liche Navigationspfade zum Artefakt möglich sind oder unterschiedliche IDs in verschiedenen
Domänen das Artefakt kennzeichnen. Auch wenn die Vergabe einer ID keine Voraussetzung
für die eindeutige Adressierbarkeit eines IT-Artefakts ist, so ist es dennoch insbesondere in
Repositories üblich, eine dedizierte ID zu vergeben, da dies die Repository-interne Verwal-
tung des Artefakts erleichtert. Diese ID wird als Dokument-ID bezeichnet. Jedes Dokument
53 Für Informationen zu Syntax und weiteren Details vgl. [Berners-Lee/Fielding/Masinter 2005].
23
muss über mindestens einen URI eindeutig adressierbar sein. Ist ein Artefakt nicht über einen
URI adressierbar, handelt es sich im Kontext dieser Arbeit nicht um ein Dokument.
Da Repositories in der Regel viele Dokumente enthalten, kann es sich bei der Dokument-ID
um eine komplexe Zeichenkombination handeln. Diese kann vom Anwendungssystem
verwendet werden, um das Dokument eindeutig zu adressieren. Als Unterscheidungsmerkmal
von Dokumenten ist sie jedoch in der Regel nicht besonders gut für menschliche Anwender
geeignet. Daher ist es wichtig, dass ein elektronisches Dokument neben dem Inhalt und der ID
hinreichend viele beschreibende, strukturierte Daten aufweist, um das Dokument für den
Anwender nach verschiedenen eingängigen Kriterien identifizierbar zu machen, und so das
Auffinden zu ermöglichen.
2.2.2.4 Summary-Daten
Strukturierte Daten, die entweder nicht primär der Bewahrung von Inhalten dienen, oder die
redundant den unstrukturierten Inhalt des Dokuments beschreiben, werden als Meta-Daten
bezeichnet. Während der Inhalt eines Dokuments sowohl in Form von strukturierten, als auch
von unstrukturierten Informationen gespeichert sein kann, werden Meta-Daten im Kontext
dieser Arbeit als grundsätzlich strukturiert definiert. Es werden zwei Arten von Meta-Daten
unterschieden: Administrative Meta-Daten dienen primär der technischen Verwaltung der
Dokumente innerhalb des Repositories. Dies sind z. B. die ID des Dokuments oder die Namen
von Anwendern, die Zugriff auf das Dokument haben. Primär inhaltsbeschreibende Meta-
Daten werden als deskriptive Meta-Daten bezeichnet. Beispiele sind ein Stichwort (engl.
Keyword, Tag), das den Inhalt beschreibt, oder ein kurzer Satz, der den Inhalt zusammenfasst.
Deskriptive Meta-Daten sind per Definition redundant, denn sie beschreiben einen bereits
gespeicherten Teil des Inhalts.
Des Weiteren enthalten Dokumente in Unternehmensrepositories in der Regel Daten, die
Informationen über den Geschäftskontext des Inhalts enthalten. Diese Daten werden als
Kontext-Daten bezeichnet. Kontext-Daten beschreiben beispielsweise, in welchem Bearbei-
tungsstatus sich ein Dokument befindet, welchem Projekt oder welchem Geschäftsprozess es
zugeordnet ist. Aus Sicht des Anwenders eines Dokuments können Kontext-Daten auch die
anstehenden Tätigkeiten in Bezug auf das Dokument beschreiben, wie z. B. „Redigieren“.
Während Meta-Daten per Definition nicht dem Inhalt zuzurechnen sind, können Kontext-
Daten sowohl implizit im Inhaltsbereich eines Dokuments, als auch expliziert als strukturierte
Daten auftreten (siehe Abbildung 2-2).
24
Abbildung 2-2: Inhalt, Kontext-Daten und Meta-Daten von Dokumenten
Die einzelnen Typen von Daten lassen sich inhaltlich nicht klar voneinander abgrenzen. Es
gibt es administrative Meta-Daten, die gleichzeitig deskriptive Meta-Daten sind, und admi-
nistrative Meta-Daten, die gleichzeitig Kontext-Daten sind. So kann beispielsweise ein Feld,
das den Namen des Dokumententyps speichert sowohl den Inhalt beschreiben, als auch für die
Auswahl einer Maske zur Darstellung (administrativ) verwendet werden. Und der aktuelle
Zugriffsberechtigte für ein Dokument kann auch gleichzeitig eine Bedeutung für den
Geschäftsprozesskontext haben, etwa wer der aktuell vorgesehene Bearbeiter des Dokuments
im Rahmen eines Workflows ist. Eine Überschneidung besteht auch zwischen Kontext-Daten
und Inhalt. Ein Feld, das eine Projekt-ID speichert und so die Zugehörigkeit eines Dokuments
zu einem bestimmten Projekt kennzeichnet, kann auch inhaltlich relevant sein. Weitere
Beispiele sind in Tabelle 2-1 aufgelistet.
Deskriptive Meta-Daten, explizierte, strukturierte Kontext-Daten sowie strukturierte Inhalts-
daten werden als Summary-Daten (engl. summary data) bezeichnet, da sie eine Zusammen-
fassung von Inhalt, Zustand und Kontext eines Dokuments darstellen (vgl. grüner Bereich in
Abbildung 2-2 und grauer Bereich in Tabelle 2-1). Summary-Daten können von Anwendern
eines Repositories verwendet werden, um durch Navigationsmechanismen Zugriff auf das
Dokument zu erlangen. Der Navigationspfad kann neben dem direkten Zugriff auf ein Doku-
ment auch dazu dienen, dem Anwender bisher unbekannte Dokumente mit ähnlichen
Kontexten auffindbar zu machen, oder Dokumente nach bestimmten Kriterien zu klassi-
fizieren, zu filtern, zu visualisieren oder automatisiert auszuwerten.
25
Administrative
Meta-Daten Deskriptive Meta-
Daten Kontext-Daten Strukturierte
Inhaltsdaten
Admin.
Meta-Daten
• ID
• Physischer
Speicherort
• Dokumententyp
• Autor des Dokuments
• Aktueller Bearbeiter
und
Zugriffsberechtigter
Deskriptive
Meta-Daten
• Dokumententyp
• Autor des Doku-
ments
• Abstract
• Stichwort zum Inhalt
des Dokuments
• Kategorie, in der das
Dokument abgelegt
ist
• Dokumententitel
Kontext-
Daten
• Aktueller
Bearbeiter und
Zugriffsberechtig-
ter
• Mitglieder im
Projektteam
• Bearbeitungsstatus
• Aktuelle Aufgabe
• Arbeitsanweisung
• Vertriebsregion
• Ablaufdatum eines
Lizenzvertrages
• Wiedervorlagedatum
einer Telefonnotiz
• Art des Erstkontakts
• Projekt ID
• Zugehöriger Kunde
zu einem Lizenz-
vertrag
Strukturierte
Inhaltsdaten • Vertriebsregion
• Ablaufdatum eines
Lizenzvertrages
• Wiedervorlagedatum
einer Telefonnotiz
• Art des Erstkontakts
• Zugehöriger Kunde
zu einem Lizenz-
vertrag
• Name der Person bei
einem Adress-
dokument
• Umsatz in einem
Quartalsbericht
Tabelle 2-1: Beispiele für Summary-Daten (grau hinterlegt)
2.2.2.5 Navigation mit Ansichten
Neben dem Editor (vgl. Abschnitt 2.2.2.1) wird eine weitere Komponente zum Arbeiten mit
elektronischen Dokumenten benötigt. Diese ermöglicht die Navigation innerhalb eines
Repository und den Zugriff auf die Dokumente. Da die Komponente eine oder mehrere
Sichten auf die Dokumente eines Repository ermöglicht, wird sie als Ansicht (engl. View)
bezeichnet. Ansichten können innerhalb der gleichen Applikation mit dem Editor, oder als
eigenständige Applikation ausgeführt sein. Da die Anzahl an Dokumenten in Repositories
groß sein kann, werden häufig, zur besseren Orientierung für den Anwender, Daten aus den
Dokumenten aggregiert und grafisch aufbereitet, oder nach übereinstimmenden Summary-
Daten klassifiziert dargestellt. Auch Kombinationen aus visueller Aufbereitung und der
klassifizierten Präsentation von Summary-Daten kommen in Standardsoftware häufig zum
Einsatz.
Eine Dokumentenmenge kann etwa durch ein navigierbares Diagramm visualisiert werden.
Die Umsatzzahlen eines Unternehmens könnten in Form eines Tortendiagramms visualisiert
werden, das als Tortenausschnitte jeweils die Vertriebsregionen des Unternehmens darstellt.
Per Mausklick auf das Tortendiagramm kann nun eine neue Darstellung der Dokumenten-
26
menge geöffnet werden, die sich nur auf die ausgewählte Vertriebsregion bezieht. Dieser
Vorgang wird als drill-down bezeichnet. Ist der Anwender durch die Aggregationslevel bis
zur letzten Ebene navigiert, die als flache Liste einzelne Dokumente darstellt, so könnte eine
grafische Visualisierung aus verkleinerten Darstellungen der Dokumentenanzeige (engl.
Thumbnail) bestehen. Die grafische Aufbereitung hat Software-ergonomische Gründe, da
visuelle Reize vorteilhaft für effiziente Navigation sein können und sich die grafische Reprä-
sentation gut für große Dokumentenmengen eignet.54
Neben der grafischen Aufbereitung ist eine einfache tabellarische sowie eine klassifizierte
tabellarische Darstellung üblich. Die klassifizierte Darstellung wird als Kategorie- oder
Ordnerstruktur bezeichnet. Welche Art der Darstellung für die Aufbereitung von Struktur-
informationen in Repositories verwendet wird ist für den Kontext dieser Arbeit nicht relevant.
Aufgrund der Fülle möglicher grafischer Visualisierungen wird daher im Folgenden aus-
schließlich die klassifizierte tabellarische Darstellung von strukturierten Daten betrachtet.
Eine weitere Vereinfachung des Problemraums wird durch die Beschränkung auf textuelle
Summary-Daten vorgenommen. Datumswerte, Zeitwerte, Zahlen und andere Summary-Daten
führen bei der Navigation zu einer sehr ähnlichen Darstellungsweise und werden daher nicht
gesondert betrachtet. Bei der klassifizierten Darstellung wird üblicherweise eine hierarchische
Klassifizierung vorgenommen55. Beispiele für die hierarchische Klassifizierung von Doku-
menten sind Ordnerstrukturen in Dateisystemen, Ordnerstrukturen in E-Mail-Umgebungen
oder Inhaltsverzeichnisse (engl. Sitemaps) auf Websites. Auch wenn es eine Vielzahl von
Anwendungsfällen gibt, in denen eine Navigation von zueinander in Beziehung stehenden
Dokumenten in Form eines Netzwerks sinnvoll wäre, hat sich bisher kein Visualisierungs-
und Navigationskonzept für Netzwerke in der Praxis durchsetzen können.56
Bei der Visualisierung von Daten aus Dokumentenrepositories ist für den Anwender unerheb-
lich, wie die Daten physisch gespeichert, oder wie sie innerhalb des Repositories organisiert
oder strukturiert sind. Es ist also nicht relevant, ob es sich bei dem Repository um ein Datei-
system, eine relationale Datenbank oder eine Dokument-Datenbank handelt. Vielmehr sorgt
die Ansicht dafür, dass die Dokumente klassifiziert dargestellt werden und so eine Navigation
zum benötigten Dokument ermöglicht wird. Da es unterschiedliche Darstellungen und Klassi-
fizierungshierarchien des gleichen Repositories geben kann, stellt eine Darstellung eines
Dokumentenbestands also lediglich eine von vielen möglichen Sichten auf die in dem
54 Vgl. [Card/Mackinlay/Shneiderman 1999], S. 1-34.
55 Vgl. [Furnas 1999].
56 Smolnik/Erdmann schlagen daher vor, Netzwerkstrukturen durch Projektion in eine hierarchische Struktur zu
überführen. Vgl. [Smolnik/Erdmann 2003], S. 272 ff.
27
Repository enthaltenen Dokumente dar. Auf diese Weise ist es möglich, passend zum
jeweiligen Rollen- und Aufgabenkontext die relevanten Schlüsselinformationen in hoher
Prägnanz bereitzustellen.
Abbildung 2-3: Referenzmodell Visualisierung57
Manche Anwendungen ermöglichen es dem Anwender, Ansichten interaktiv zu manipulieren.
Abbildung 2-3 zeigt in Form eines Referenzmodells für Visualisierung die verschiedenen
Transformationen der Daten und die konzeptionell möglichen Interaktionen des Anwenders.
In Applikationen, die auf Datenbanksysteme zugreifen wird die Fülle der Interaktions-
möglichkeiten jedoch üblicherweise nicht vollständig genutzt. So ist die Datentransformation
in der Regel vordefiniert, damit Anwender sich nicht mit technischen Details der Daten-
quellen auseinandersetzen müssen. Sie finden vordefinierte Tabellen vor. Das gleiche gilt für
das visuelle Mapping. Die Datentabelle wird üblicherweise auf vordefinierte Darstellungs-
formen der Applikation des Anwenders projiziert.
Zudem gibt es jeweils unterschiedliche Datentabellen für strukturierte Inhaltsdaten, deskrip-
tive Meta-Daten und strukturierte Kontext-Daten, so dass Anwender sowohl inhaltsorientiert,
als auch anhand von Statusinformationen zu einem Dokument navigieren können. Aber auch
innerhalb der Klassen von strukturierten Dokumentendaten stehen häufig spezialisierte
Datentabellen zur Verfügung. So können Adress-Dokumente in einem CRM System häufig
sowohl nach dem Namen der Person, nach der Organisation, nach der Klassifizierung des
Kunden anhand des zu erwartenden Auftragvolumens oder nach der Art des Erstkontakts mit
der Person klassifiziert dargestellt werden. Durch die Möglichkeit der Mehrfach-
klassifizierung existieren in der Regel mehrere Navigationspfade zu dem gleichen Dokument
(vgl. Abschnitt 2.2.2.1).
57 In Anlehnung an [Card/Mackinlay/Shneiderman 1999], S. 17.
28
Um effizient navigieren zu können ist es für den Anwender einer Ansicht wichtig, dass die
Art der Klassifizierung seinen individuellen Informationsbedürfnissen entspricht. Häufig
werden daher spezielle Ansichten für bestimmte Anwendergruppen bereitgestellt. Einen
Vertriebsbeauftragten interessieren beispielsweise primär die Kunden, die sich in seinem
Vertriebsgebiet befinden. Eine Klassifizierung nach Städten kann die Planung seiner Reise-
tätigkeit vereinfachen. Der Vorgesetzte des Vertriebsbeauftragten interessiert sich hingegen
z. B. für alle Kunden oberhalb eines gewissen Auftragsvolumens, oder für Kunden, von denen
Beschwerden vorliegen. Eine Klassifizierung von Kunden nach Vertriebsgebieten oder von
Beschwerden nach zuständigem Vertriebsbeauftragten kann sinnvoll sein. Neben der semanti-
schen Sinnhaftigkeit der Klassifizierung ist es für die effiziente Navigation wichtig, dass die
Klassifizierungsstruktur so gewählt ist, dass die Navigationspfade zum gesuchten Dokument
möglichst kurz sind.58
Das Beispiel zeigt, dass neben der unterschiedlichen Klassifizierung, verschiedenen Ziel-
gruppen auch verschiedene Dokumentenmengen angezeigt werden können. Die Kriterien, die
zu einer Selektion einer Untermenge aller in einem Repository befindlichen Dokumente
führen, werden als Filter bezeichnet. Es gibt verschiedene Filter, die auch gemeinsam wirken
können, etwa der vom Entwickler der Ansicht gewählte Selektionsfilter und ein durch den
Anwender eingegebener Suchtext. Ein Sicherheitsfilter muss zudem dafür sorgen, dass die
Zugriffsberechtigung auf Dokumente vor der Darstellung der Ansicht überprüft wird, damit
der Anwender keinen unberechtigten Zugriff auf Dokumente erhält.
Auch die visuellen Strukturen sind häufig vorgegeben und müssen nicht mehr vom Anwender
definiert werden. Die Manipulation der visuellen Strukturen obliegt jedoch in der Regel dem
Anwender selbst. Durch Anwender-definierte Filter kann die Menge dargestellter Daten
reduziert werden, durch Umsortierung der Daten oder der Spalten der Ansicht kann der
Anwender die Darstellung seinen individuellen Bedürfnissen anpassen, und durch Möglich-
keiten der Konfiguration können visuelle Strukturen, z. B. durch veränderte Farbgebung oder
Zoomfunktionen, den eigenen Bedürfnissen angepasst werden.
2.3 Etablierte Kollaborationskonzepte und -technologien
Es folgt ein Überblick über in Unternehmen etablierte Kollaborationskonzepte und
-technologien. Zunächst werden die Grundkonzepte Kommunikation, Kooperation und
Koordination abgegrenzt. Anschließend werden die Technologien vorgestellt, auf deren Basis
diese Konzepte implementiert werden. Abschließend werden in einem Abschnitt Ansätze und
58 Vgl. [Furnas 1999]).
29
Technologien diskutiert, die darauf ausgerichtet sind, einen zentralen Zugriffsbereich zu allen
benötigten IT-Artefakten herzustellen.
2.3.1 Grundkonzepte des kollaborativen Arbeitsplatzes
Der Begriff CSCW bezeichnet ein interdisziplinäres Forschungsfeld an der Schnittstelle
zwischen Wirtschaftsinformatik, Arbeitswissenschaft, Psychologie und Kommunikations-
wissenschaft. Die CSCW-Forschung hat zum Ziel, das Wesen von Tätigkeiten am kollabora-
tiven Arbeitsplatz zu erklären und computerunterstützte Konzepte und Methoden zu ent-
wickeln, um die Produktivität bei der Durchführung dieser Tätigkeiten zu verbessern oder die
Durchführung humaner und sozialer zu gestalten59.
Ein kollaborativer Arbeitsplatz ist die konzeptionelle Umgebung, in der Menschen primär
betriebliche Tätigkeiten ausführen, zu deren Erledigung Kommunikation mit anderen Men-
schen notwendig ist. Dies kann ein physischer Büroarbeitsplatz sein, aber auch eine elektro-
nische Arbeitsumgebung auf einem mobilen Endgerät wie z. B. einem Laptop, Tablet oder
Mobiltelefon. Ein Schwerpunkt der Tätigkeiten am kollaborativen Arbeitsplatz liegt in der
Nutzung und Bearbeitung von Dokumenten. Die Umgebung dient demzufolge weder primär
der Verarbeitung von Massendaten, noch der Produktion physischer Güter, sondern der
Transformation und Verteilung von Informationen. Im Kontext dieser Arbeit wird zudem
davon ausgegangen, dass alle Dokumente, die Träger der zu transformierenden Informationen
sind, in elektronischer Form vorliegen.
Die zur Erledigung von Tätigkeiten notwendige Kommunikation bezeichnet den Prozess des
Informationsaustausches zwischen Interaktionspartnern. Dies können sowohl Menschen, als
auch Maschinen oder Applikationen sein. Kommunikation kann asynchron, etwa durch
E-Mail, oder synchron, z. B. durch Telefon oder Video-Konferenzen, durchgeführt werden.
Sie kann spontan stattfinden ohne gemeinsame Ziele zu verfolgen. Werden mit der Kommu-
nikation gemeinsame Ziele der Kommunizierenden verfolgt, wird dies als Kooperation
bezeichnet.60
Die gemeinsame Zielverfolgung resultiert in einem weiteren Charakteristikum kooperativer
Arbeit, der gegenseitigen Abhängigkeit der Tätigkeiten einzelner Interaktionspartner vonein-
ander.61 Die Abstimmung der individuellen Tätigkeiten findet häufig in Form eines informel-
len, spontanen und unstrukturierten sozialen Prozesses statt, z. B. die Einigung auf eine
bestimmte Vorgehensweise oder die Auswahl alternativer Methoden zur Zielerreichung. Liegt
59 Vgl. [Nastansky et al. 2002], S. 238.
60 Vgl. [Nastansky et al. 2002], S. 241.
61 „interdependence in work“, vgl. [Schmidt/Bannon 1992], S. 14.
30
Teamproduktion vor, steht das Team als Einheit in einer Principal-Agent-Beziehung zum
Auftraggeber, Teamleiter oder Vorgesetzten. Auch innerhalb des Teams kann eine Principal-
Agent-Beziehung bestehen, z. B. wenn über die Aufgabenverteilung verhandelt wird. Da
zwischen Aufgaben Interdependenzen bestehen, nimmt das Teammitglied, das auf das Ergeb-
nis eines anderen Mitglieds angewiesen ist, die Rolle des Principals ein.
Werden Tätigkeiten nicht-kooperativ durchgeführt, und fehlt daher die Abhängigkeit von
Tätigkeiten Dritter, handelt es sich um individuelle Arbeit. Schmidt und Bannon führen aus,
dass sich individuelle und kooperative Arbeit sowohl in Theorie als auch in der Praxis unter-
scheiden und deutlich unterschiedliche Charakteristika aufweisen.62 Es erscheint naheliegend,
dass für beide Arten von Arbeit daher auch unterschiedliche Bedürfnisse an die Werkzeug-
unterstützung existieren. So ist bei der kooperativen Arbeit aufgrund der Notwendigkeit der
Abstimmung untereinander wichtig, dass ein intersubjektiver Konsens über die Strukturierung
von gemeinsam benötigten Dokumentenmengen herrscht, so dass eine effiziente Auffindbar-
keit für alle Teammitglieder gewährleistet ist und die Kommunikation über Dokumente
vereinfacht wird. Dabei müssen aus Sicht des Individuums Zugeständnisse gegenüber der
Gemeinschaft gemacht werden. Nur bei individueller Arbeit kann die Strukturierung von
Dokumenten so stattfinden, wie es den individuellen Bedürfnissen am meisten entspricht, also
anders als in gemeinsam genutzten Repositories. Individuelle Bedürfnisse zeigen sich beim
Blick auf die Schreibtische verschiedener Personen. Die Ablage von Papierdokumenten
erfolgt üblicherweise individuell unterschiedlich, z. B. in Form von Papierbergen, der saube-
ren Ablage in Mappen und Aktenschränken oder in Form von gelben Haftnotizen am Monitor
des Computers.63
Findet der kooperative Abstimmungsprozess von gegenseitig abhängigen Tätigkeiten mehre-
rer Akteure nicht informell, spontan und unstrukturiert, sondern strukturiert und geplant statt,
wird diese Art der Kooperation als Koordination im Team bezeichnet. In einer Untersuchung
zu den Charakteristika koordinierter Arbeit stellen Malone und Crowston fest, dass ihrer
Erfahrung nach koordinierte Arbeit auch dann vorliegen kann, wenn nicht mehrere Akteure
beteiligt sind. Daher definieren sie Koordination als „the act of managing interdependencies
between activities performed to achieve a goal“.64 Lediglich die aus dem Kooperations-
62 Vgl. [Schmidt/Bannon 1992], S. 14.
63 Dies ist lediglich ein einführendes Beispiel. Die Individualität der Strukturierung von Dokumenten am
Arbeitsplatz ist wichtig für den Kontext dieser Arbeit und wird detaillierter in den Abschnitten 2.3.2.2, 3.2.4,
4.1.3 und 4.3.3 diskutiert.
64 Vgl. [Malone/Crowston 1990], S. 361.
31
konzept abgeleitete Zielorientierung und die Planung gegenseitiger Abhängigkeiten zwischen
Tätigkeiten sind ausschlaggebend.
Dieser Argumentation folgend erscheint es sinnvoll, eine Klassifizierung in Koordination
kooperativer Tätigkeiten sowie Koordination nicht-kooperativer Tätigkeiten, also indi-
vidueller Arbeit, vorzunehmen. Es ist offensichtlich, dass auch eine hinreichend komplexe
individuelle Arbeit, die aus mehreren abhängigen Tätigkeiten des Individuums besteht,
Planung und somit Koordinationsarbeit erfordert. Die Unterstützung der Koordination von
Tätigkeiten für individuelle Arbeit wird per Definition nicht im Rahmen von CSCW-
Konzepten erforscht. Diese Unterscheidung ist im Kontext der vorliegenden Arbeit von
Bedeutung, da alle Tätigkeiten am kollaborativen Arbeitsplatz unterstützt werden sollen,
sowohl individuelle als auch kooperative.
Abbildung 2-4: Kollaboration65
Die Gesamtheit aller drei beschriebenen Interaktionsformen (Kommunikation ohne gemein-
same Zielverfolgung, Kooperation und Koordination im Team) wird als Kollaboration
bezeichnet. Alle Formen können am kollaborativen Arbeitsplatz auftreten. Computer-
anwendungen, die mindestens eine der Interaktionsformen unterstützen, werden unter dem
Begriff kollaborative Applikationen zusammengefasst. Abbildung 2-4 verdeutlicht den
Zusammenhang der Kommunikationsformen Kooperation und Koordination im Team als
echte Untermengen von Kommunikation, und die Vereinigung aller Mengen unter dem
Begriff der Kollaboration.
65 In Anlehnung an [Rosenberg 2005], S. 10.
32
2.3.2 Kollaborations-Informationssysteme
Kollaborations-Informationssysteme (engl. Collaboration Information Systems, CIS) sind
eine Klasse von Informationssystemen, welche die Arbeit am kollaborativen Arbeitsplatz für
die in Abschnitt 2.3.1 genannten Kollaborationsformen unterstützen. Häufig wird CIS mit
dem Begriff Groupware synonym verwendet. Im Kontext dieser Arbeit wird jedoch davon
ausgegangen, dass ein CIS immer aus mindestens einer Applikation und einem Repository
besteht, da der Fokus auf dem Arbeiten mit Dokumenten liegt. Groupware hingegen umfasst
auch Systeme, die nicht über ein Repository verfügen, wie z. B. Videokonferenzsysteme.
2.3.2.1 Interaktionsparadigmen von Applikationen
CIS werden von einer großen Bandbreite unterschiedlicher Anwendergruppen eingesetzt.
Viele dieser Anwendergruppen haben unterschiedliche Bedürfnisse an Darstellung, Orientie-
rung, Navigation, Eingabegeräte wie Tastatur oder Maus, Interaktionsmöglichkeiten und
Kontextualisierungsoptionen. Bei der Entwicklung von Applikationen muss daher berück-
sichtigt werden, dass ein fortschreitender Erfahrungsgrad bei der Nutzung der Applikation zu
sich ändernden Anforderungen in Bezug auf die Interaktionsmöglichkeiten führen kann. So
arbeiten mit der Applikation oder der speziellen Tätigkeit nicht vertraute Anwender eher
explorativ, während erfahrene Anwender gezielt IT-Artefakte ansteuern die sie benötigen, um
ihre Tätigkeit erledigen können. Beispielsweise bevorzugen erfahrene Anwender Tastatur-
kürzel (engl. Hotkey oder Keyboard-Shortcut), während unerfahrene Anwender eher visuell
agieren, Bereiche auf dem Bildschirm absuchen, Menüstrukturen und Symbole nutzen und
bevorzugt mit der Maus arbeiten. Weitere Faktoren wie die Qualifikation des Anwenders zur
Durchführung einer Tätigkeit, die Anzahl der Wiederholungen der Tätigkeit, Persönlich-
keitsmerkmale oder kulturelle Unterschiede bilden im Rahmen von Software-ergonomischen
Untersuchungen weitere zu berücksichtigende Faktoren. Details zu Software-ergonomischen
Anforderungen und Untersuchungen im Bereich von Mensch-Computer-Interaktion finden
sich in der Literatur, etwa in [Bødker 1991], [Norman 1998] oder
[Card/Mackinlay/Shneiderman 1999].
Applikationen am kollaborativen Arbeitsplatz werden als Client-Server-Architektur oder als
Standalone-Applikation ausgeführt.66 Eine Standalone-Applikation kann Dokumente nur auf
dem lokalen Rechner des Anwenders speichern. In einer Client-Server-Umgebung nutzt die
Client-Applikation (kurz: Client) Dienste der Server-Applikation (kurz Server). Dies sind
z. B. Dienste wie Kommunikation mit anderen Anwendern, oder die Bereitstellung von
66 Peer-to-peer Architekturen werden als Sonderform einer Client-Server Architektur betrachtet, in der der
Client auch Aufgaben eines Servers wahrnimmt.
33
Repositories zur Speicherung von Dokumenten, auf die mehrere Anwender Zugriff haben
sollen.
Um die Dienste eines Servers nutzen zu dürfen muss der Anwender dem Server gegenüber
üblicherweise eine Authentifizierung durchführen und so seine Identität nachweisen. Dies
kann z. B. durch die Eingabe einer Kombination aus Benutzername und Passwort erfolgen.
Der Server verfügt über ein Verzeichnis aller bekannten Anwender und vergleicht die einge-
gebenen Authentifizierungsmerkmale mit den im Verzeichnis gespeicherten Daten. Das
Verzeichnis wird als Directory bezeichnet. Ist ein Anwender authentifiziert kann der Server
feststellen, ob er Zugriff auf bestimmte Dienste oder Ressourcen, z. B. ob er Zugriff auf ein
bestimmtes angefordertes Dokument hat (vgl. Abschnitt 2.2.2.1). Dies wird als Autorisierung
bezeichnet.
Standalone-Applikationen gehören zur Klasse der Desktop-Applikationen. Desktop bezeichnet
die grafische Benutzungsschnittstelle (engl. User Interface, UI) eines Computers. Bei Desk-
top-Applikationen wird die Applikationssoftware lokal auf dem Computer des Anwenders
installiert. Auch ein Client kann als Desktop-Applikation ausgeführt sein. Beispiele für
Desktop-Applikationen sind Textverarbeitungsprogramme, Bildbearbeitungsprogramme,
Browser oder E-Mail-Clients. Daneben sind heute die Browser-basierten Applikationen weit
verbreitet, die nur in Client-Server-Umgebungen vorkommen. Eine Browser-basierte Appli-
kation wird basierend auf Web-Technologien innerhalb des Browsers ausgeführt. Üblicher-
weise übernimmt der Rechner des Anwenders dabei lediglich die Darstellung der
Benutzungsschnittstelle, während ein Großteil der Geschäftslogik sowie die Speicherung von
Dokumenten auf einem Server erfolgt. Das UI Browser-basierter Applikationen wird als
Browser UI bezeichnet.
Ein Nachteil dieser Applikationsklasse ist, dass die Interaktions- und Kontextualisierungs-
optionen häufig eingeschränkt sind.67 So stehen üblicherweise für erfahrene Anwender etwa
keine Tastaturkürzel zur Verfügung. Ein Vorteil dieser Client-Art ist, dass die Ausführung im
Browser einen schnellen und kostengünstigen Einstieg ermöglicht, da keine zusätzliche
Software auf lokalen Rechnern installiert werden muss. Ein Backup der Daten muss zudem
lediglich auf dem Server erfolgen und nicht auf jedem Rechner der Anwender. Browser-
basierte Applikationen eignen sich daher unter anderem, wenn sie durch die entsprechende
Anwendergruppe nur selten eingesetzt werden und die zu erledigenden Tätigkeiten keine
hohen Anforderungen an die Interaktionsmöglichkeiten stellen.
67 Vgl. etwa [Silver 2006].
34
Bei einer Desktop-Applikation wird ein Großteil oder die gesamte Geschäftslogik auf dem
Rechner des Anwenders ausgeführt. Nur die Ergebnisse von Berechnungen werden zum
Server gesendet, oder lokal auf dem Rechner des Anwenders gespeichert. Sie zeichnen sich
durch einen hohen Spezialisierungsgrad in Bezug auf einen konkreten Anwendungszweck
und reiche Interaktionsmöglichkeiten mit Dokumenten aus. Zudem ist es vorteilhaft, dass
ohne einen Server gearbeitet werden kann, z. B. wenn der Server ausfällt oder am aktuellen
Arbeitsort (z. B. im Zug oder in einer geschützten Umgebung bei einem Kundenbesuch) keine
Verbindung zum Internet verfügbar ist. Es existieren Bestrebungen, die Vorteile beider
Client-Arten zu vereinigen. So wird über neue Web-Technologien wie Dynamic HTML,
XML, JavaScript oder Flash versucht, die Interaktionsmöglichkeiten von Browser-basierten
Applikationen zu erhöhen. Gleichzeitig wird versucht, durch automatische Softwareverteilung
und Aktualisierung von Desktop-Applikationen die Nachteile in Bezug auf Installations- und
Aktualisierungsaufwand sowie Backup zu minimieren. Beide Ansätze sind sehr erfolgreich,
bei Desktop-Applikationen in Form der Smart-Clients, und im Bereich des Internets primär
durch eine Kombination von JavaScript und XML, der AJAX-Technologie68.
2.3.2.2 Persönliches Informationsmanagement
Der Begriff persönliches Informationsmanagement (engl. Personal Information Management,
PIM) bezeichnet Strategien von Individuen, ihre persönlichen Informationen zu organisieren.
Dies kann sowohl private, als auch dienstliche Informationen umfassen. Anwendungen, die
das persönliche Informationsmanagement unterstützen werden als PIM-Applikationen
bezeichnet. Im Allgemeinen fasst der Begriff PIM-Applikationen die Anwendungen E-Mail,
Kalender, persönliche Adressverwaltung und Aufgaben zusammen. Auch ein persönliches
Journal zur Ablage von Notizen kann als PIM-Applikation bezeichnet werden. Ebenso
können weitere Informationen wie Lesezeichen für Dokumente (engl. Bookmarks) oder
Dateien auf der lokalen Festplatte des persönlichen Arbeitscomputers unter die zu verwal-
tenden persönlichen Informationen fallen.
Im Unternehmensumfeld ist es üblich, dass Applikationen für Kalender- und Aufgaben-
management kollaborative Funktionalitäten enthalten, so dass eine Aufgabe auch anderen
Mitarbeitern zugewiesen, oder eine Besprechung durch den Verantwortlichen geplant, und in
die Kalender weiterer Teilnehmer verteilt werden kann. Üblicherweise werden PIM-Applika-
tionen als integrierte Anwendung oder in Form einer aufeinander abgestimmten Applikations-
familie (engl. Application-Suite) eingesetzt, so dass Koordinationsfunktionen zwischen den
68 Vgl. [Garrett 2005].
35
Applikationen optimal aufeinander abgestimmt sind. Oft ist es möglich, die in den PIM-
Applikationen organisierten Dokumente mit mobilen Geräten wie einfachen Mobiltelefonen
oder Smartphones abzurufen oder zu synchronisieren, so dass diese Informationen für den
Anwender unabhängig vom klassischen Arbeitsplatzrechner verfügbar sind.
Wie der Name suggeriert, ist es charakteristisch für PIM-Applikationen, dass es sich um eine
durch den Anwender als persönlich wahrgenommene Umgebung handelt. Der Anwender ist
für die Ablage, Strukturierung und Planung, also das Management seiner Informationen,
selbst verantwortlich. Die Möglichkeit des Zugriffs auf die entsprechenden PIM-Repositories
anderer Anwender, etwa durch Vorgesetzte oder enge Mitarbeiter wie einen persönlichen
Assistenten ist häufig nur eingeschränkt vorgesehen. Das hat Konsequenzen für die Verfüg-
barkeit dieser Informationen im Unternehmen. Dokumente, die z. B. ausschließlich in E-Mail-
Umgebungen verwaltet werden, stehen dem Unternehmen als Wissensressource nicht zur
Verfügung.
2.3.2.3 Informations- und Wissensmanagement
Die Begriffe Daten, Informationen und Wissen werden häufig in einer Kontextualisierungs-
hierarchie eingeordnet. Daten sind geordnete Zeichen ohne Bedeutungskontext. Durch die
Kontextualisierung von Daten mithilfe von Regeln entstehen Informationen. Werden
Informationen durch einen Menschen rezipiert, interpretiert und mit anderen Informationen in
Bedeutungszusammenhänge gesetzt, kann der Mensch neues Wissen konstruieren. „Wissen
ist die Gesamtheit der Kenntnisse und Fähigkeiten, die Personen zur Lösung von Problemen
einsetzen.“69 Dabei werden üblicherweise eine implizite und eine explizite Wissensdimension
unterschieden.70 Die implizite Wissensdimension kann durch das Individuum nicht erklärt
oder aufgeschrieben werden. Es handelt sich um Erfahrungen, Fähigkeiten oder spezielle
Talente. Die explizite Wissensdimension kann in Form von Information durch Kommunika-
tion direkt oder indirekt an andere Individuen approximativ weitergegeben werden.
Beim Empfang von Informationen findet eine Neuinterpretation durch das empfangende
Individuum statt. Die Interpretation findet durch Kontextualisierung mit eigenem Wissen statt
und ist abhängig von Faktoren wie Ausbildung, kulturellem und sozialem Hintergrund und
auch dem Zeitpunkt der Aufnahme der Information. Der Prozess der Interpretation und
Kontextualisierung von Informationen, und somit der Prozess der Wissenskonstruktion ist
daher bei jedem Individuum notwendigerweise unterschiedlich. Daraus folgt direkt, dass
69 Vgl. [Smolnik 2006], S. 21.
70 Vgl. [Polanyi 1985].
36
Wissen nicht objektiviert werden kann. Damit ist es insbesondere nicht in einer virtuellen
Arbeitsumgebung abbildbar. Durch die Explizierung des explizierbaren Wissensanteils
entstehen Informationen. Die Weitergabe kann etwa in Form von mündlicher Kommunikation
erfolgen, oder auch indirekt mithilfe von Dokumenten.71
Unter Informationsmanagement wird im Kontext dieser Arbeit verstanden, Dokumente in
gemeinsam nutzbaren Repositories zu verwalten, zu Klassifizieren und den Zugriff darauf zu
ermöglichen. Unter Wissensmanagement werden Prozesse verstanden, die Menschen bei der
Konstruktion neuen Wissens, üblicherweise auf Basis von Dokumenten, unterstützen.
Informationssysteme, welche die Wissensmanagement Prozesse aktiv unterstützen werden als
Wissensmanagement Systeme (WMS) bezeichnet. Das bedeutet dass die Anwender, die ihr
Wissen teilen möchten, bei der Explikation von Wissen durch die Erstellung von Dokumenten
und deren Kontextualisierung unterstützt werden müssen. Die durch Kontextualisierung ent-
stehenden semantischen Netze werden als Wissensstrukturen bezeichnet. Sie müssen etwa
durch den Entwurf einer Taxonomie geplant, aufbereitet und navigierbar gemacht werden.
Dies versetzt den Anwender von Dokumenten in die Lage benötigte Dokumente zu finden,
auf sie zuzugreifen und sie wiederum in neue Geschäftskontexte zu bringen, in denen sie
benötigt werden.
Informationen bedürfen stets der Interpretation. Kommunikation kann dabei helfen, Falsch-
interpretationen zu vermeiden, indem der Autor eines Dokuments den Anwender etwa bei der
Wissenskonstruktion unterstützt. Um die Kommunikation direkt aus dem Kontext eines
Dokuments starten zu können, kann ein WMS etwa auch Unterstützungsfunktionen für
synchrone Kommunikation bereitstellen. Wissensstrukturen können auch durch WMS auto-
matisch erzeugt werden, z. B. indem semantische Zusammenhänge zwischen Dokumenten
automatisiert erkannt und navigierbar gemacht werden. Auch das Management von Wissens-
strukturen muss unterstützt werden, um die Degeneration von Wissensstrukturen zu ver-
hindern und eine effiziente Navigation zu ermöglichen (vgl. Abschnitt 2.2.2.5).
Typischerweise gehört der Mitarbeiter am kollaborativen Arbeitsplatz zu den Wissens-
arbeitern (engl. Knowledge Worker). Ein Wissensarbeiter ist dadurch gekennzeichnet, dass
sein primärer Produktionsfaktor nicht die physische Arbeit, sondern sein Wissen umfasst.
Hinzu kommt, dass die durchgeführten Tätigkeiten in der Regel nicht darin bestehen, gleich-
artige Prozesse mit einer hohen Anzahl an Wiederholungen durchzuführen. Vielmehr bringt
er durch kreative Ad-hoc-Tätigkeiten, Teamarbeit und Projekte seine persönliche Entschei-
71 Zu weiteren Ausführungen zum Thema Wissen vgl. [Polanyi 1985], [Davenport/Prusak 1998],
[Probst/Raub/Romhardt 2006] und [Smolnik 2006].
37
dungskompetenz ein und entwickelt und ergänzt sein Wissen kontinuierlich. Die Wichtigkeit
dieser Kompetenzen zeigt etwa die globale Studie der IBM unter 1500 CEOs, in der
Kreativität als die wichtigste Führungsqualität der nächsten fünf Jahre genannt wird (vgl.
Abbildung 2-5).
Abbildung 2-5: Wichtigste Führungsqualitäten der nächsten fünf Jahre72
Um dieser Anforderung gerecht zu werden benötigt er Zugriff auf Dokumente. Dabei sind
Inhalt und Ablageort der Dokumente zunächst häufig unbekannt. Beispielsweise könnte es bei
der Planung eines Projekts nötig sein herauszufinden, ob ein ähnliches Projekt bereits im
Unternehmen durchgeführt wurde. Dann ist es wichtig, dass er Zugriff auf die Repositories
des Unternehmens hat, und über Navigations- und Suchmechanismen verfügt, die ihm das
Auffinden der gewünschten Dokumente ermöglichen. Gleichzeitig benötigt er Mechanismen,
um von ihm erzeugte Dokumente abzulegen und so zu kontextualisieren, dass andere
Wissensarbeiter von dem in diesen Dokumenten explizierten Wissen profitieren können. Die
Arbeitsumgebung für Wissensarbeiter ist demzufolge ein WMS mit reichen Navigations- und
Suchmechanismen, Interaktionsmöglichkeiten und vielfältigen Kontextualisierungsoptionen.
Reichhaltige Kontextualisierung durch Summary-Daten ist vorteilhaft für die Konstruktion
neuen Wissens.73
72 Vgl. [Berman et al. 2010], S. 24.
73 Vgl. [Smolnik 2006], S. 92 ff.
38
2.3.2.4 Social Software
Bei Social Software handelt es sich um einen globalen Trend, mithilfe Web-basierter Appli-
kationen die Kollaboration zwischen Individuen zu verbessern. Kennzeichnend für diesen
Trend ist die Vernetzung von Kommunikationspartnern sowie die kooperative Erstellung und
Verbesserung von Dokumenten. Einige Konzepte und deren Verfügbarkeit in Form von
kostenfreien Webdiensten haben Social Software maßgeblich zum weltweiten Durchbruch
verholfen.
Ein Weblog, kurz Blog, ist eine Website zur Veröffentlichung kurzer, nicht redaktionell
bearbeiteter Artikel zu beliebigen Themenbereichen persönlicher, geschäftlicher oder fach-
licher Natur. Es ist üblich, dass diese Artikel von den Lesern in Form von Kommentaren im
Blog, oder in Form von Artikeln im eigenen Blog diskutiert werden. Die Beiträge sind rück-
wärts chronologisch sortiert, so dass Leser eines Blogs immer zunächst die aktuellsten Bei-
träge sehen und selten auf ältere Beiträge stoßen, sofern sie nicht explizit danach suchen. Dies
bewirkt, dass Informationen in Blogs automatisch altern. Es existieren zahlreiche Dienste, auf
denen sich Anwender kostenfrei ein eigenes Blog einrichten können.
Ein Wiki ermöglicht die kooperative Erstellung und Bearbeitung von Dokumenten. Dabei
haben üblicherweise alle Anwender nicht nur lesenden Zugriff, sondern auch Bearbeitungs-
rechte für ein Dokument. Dies kann auch für anonyme Anwender gelten. Über ein spezielles
Versionsmanagement können alle Veränderungen des Dokuments nachvollzogen, und ggf.
Unerwünschte rückgängig gemacht werden. Wikis eignen sich besonders für Informationen,
die eine lange Lebensdauer haben, wie etwa in Enzyklopädien. Ein populäres Beispiel für ein
Wiki ist die Online-Enzyklopädie Wikipedia74.
Ebenso wie Blogs und Wikis dient das Social Bookmarking dem Bereitstellen von anwender-
generierten Inhalten. Inhalt des Dokuments ist beim Social Bookmarking lediglich ein Lese-
zeichen sowie ergänzende Meta-Daten. Ein Beispiel für eine Social Bookmarking Plattform
ist del.icio.us75. Beim Social Bookmarking stellt jeder Anwender eine Auswahl seiner eigenen
Lesezeichen der Gemeinschaft zur Verfügung. Da Menschen sich üblicherweise nur Lese-
zeichen auf Dokumente setzen, die sie für interessant oder nutzbringend halten, stellt dies eine
qualitativ hochwertige Bewertung dar. Social Bookmarks können so für die Informations-
suche verwendet werden. Insbesondere bei Nutzung innerhalb von größeren Unternehmen
74 Vgl. http://www.wikipedia.org [07.10.2011].
75 Vgl. [Lee 2006].
39
können sie aber auch zur Identifikation von Experten dienen, die sich intensiv mit bestimmten
Themen beschäftigt haben.76
Beim Konzept des Sozialen Netzwerks (engl. Social Network) legen Anwender ein Profil mit
Informationen über sich selbst an und fügen andere Anwender zu einer Kontaktliste hinzu.
Die Applikation fördert die Vernetzung und das Kennenlernen neuer Kontakte durch die
Visualisierung von Netzwerkbeziehungen. Ein Anwender kann sehen, über welchen seiner
Kontakte er einen dritten Anwender kennt. Über Nachrichtensysteme kann man sich einander
vorstellen, oder auch alte Bekannte wieder treffen. Neben den eigenen Profilinformationen
können etwa Inhalte wie Fotos, Videos, oder Vita-Informationen den eigenen Kontakten oder
der anonymen Öffentlichkeit zur Verfügung gestellt werden. Über einen Social Activity
Stream wird der Anwender informiert, womit sich Mitglieder seines Netzwerks aktuell
beschäftigen. Die im Stream aufgeführten Nachrichten werden von den Anwendern manuell
eingegeben, oder durch von den Anwendern verwendete Applikationen automatisch
versendet.
Soziale Netzwerke haben unterschiedliche Zielgruppen. Populäre Plattformen sind Xing77 und
LinkedIn78, die sich primär als Plattformen für Geschäftskontakte positionieren sowie
Facebook79 und Google+80, bei denen private Interessen im Vordergrund stehen. Die Verbrei-
tung sozialer Netzwerke ist sehr groß. So hat beispielsweise die deutschsprachige Plattform
Xing nach eigenen Angaben ca. 10,8 Mio. registrierte Anwender.81 Deutlich größer ist
Facebook, das im Jahr 2011 weltweit mehr als 800 Millionen aktive Anwender verzeichnet.82
Auch die Entwicklung virtueller Freizeitbeschäftigungen ist ein Indikator für die Ausbildung
von Kollaborationskompetenz in Online-Umgebungen. So bewegen sich Anwender spielend
in virtuellen Welten wie SecondLife83 oder Massively Multiplayer Online Welten84, in denen
verbale und nonverbale Kommunikation zum Spielerlebnis gehören und komplexe Team-
76 Vgl. [Gilbert et al. 2009], S. 30.
77 Vgl. http://www.xing.com [07.10.2011].
78 Vgl. http://www.linkedin.com [07.10.2011].
79 Vgl. http://www.facebook.com [07.10.2011].
80 Vgl. http://plus.google.com [07.10.2011].
81 Vgl. Quartalsbericht I/2011
http://corporate.xing.com/fileadmin/image_archive/XING_AG_ergebnisse_Q1_2011.pdf [07.10.2011].
82 Vgl. http://www.facebook.com/press/info.php?statistics [07.10.2011]
83 Vgl. http://secondlife.com [07.10.2011].
84 Ein Beispiel für eine solche Klasse von Spielen sind die Massively Multiplayer Online Role-Playing Games.
Bei diesen Rollenspielen werden die Figuren einer virtuellen Welt größtenteils durch menschliche Mitspieler
repräsentiert.
40
strategien virtuell umgesetzt werden. Benford et al. schlugen folgerichtig bereits 2002 eine
neue Forschungsrichtung Computer Supported Cooperative Play als Teil der CSCW vor.85
Problematisch ist es für die Anwender von Social Software, die Vielzahl von potenziell
interessanten Webseiten aufzusuchen, um auf dem neuesten Stand der sich dynamisch ent-
wickelnden Meinungsbilder und Diskussionen zu bleiben. Insbesondere, da die Vielzahl an
Seiten stets neu aufgerufen werden müsste um zu sehen, ob sich bereits neue Beiträge auf der
Seite befinden. Diese Herausforderung wird durch Newsfeeds adressiert, die daher eine
wichtige Bedeutung bei der Akzeptanz von Social Software Anwendungen haben. Dabei wird
von einer Webseite in einem standardisierten Format eine Liste von Nachrichten publiziert.
Einträge in der Liste enthalten einen Titel, einen URI zum Dokument, und ggf. weitere
Informationen über den Eintrag, wie beispielsweise den Autor oder das Veröffentlichungs-
datum.
Anwender verwenden zur Verarbeitung von Newsfeeds einen News Reader. Diese Applika-
tion dient dazu Newsfeeds zu abonnieren. In regelmäßigen, durch den Anwender definier-
baren Abständen werden die abonnierten Newsfeeds abgerufen und der Anwender über neue
Dokumente informiert. So können auch sehr effizient Seiten beobachtet werden, auf denen
nur selten neue Dokumente publiziert werden. Ursprünglich kamen Newsfeeds zum Einsatz,
um Nachrichten von verschiedenen Informationsseiten im Internet abzurufen, was zu ihrem
Namen führte. Da sie heutzutage generisch zum Abonnieren von Inhalten eingesetzt werden,
hat sich die Kurzform Feed etabliert. Technologisch haben sich zur Umsetzung von Feeds
zwei Standards etabliert, das Atom Protokoll86 und das RSS Protokoll87.
Ein weiteres Kennzeichen von Social Software ist die Verstichwortung von Dokumenten
(engl. Tagging). Dabei werden die Stichworte stets frei vergeben, so dass anhand der
Gewichtung von Stichworten eine Taxonomie entstehen kann. Diese wird in Abgrenzung zu
üblicherweise durch Experten zentral entwickelten Taxonomien als Folksonomy bezeichnet.88
Dabei ist die Klassifizierungstiefe üblicherweise gering, häufig ist lediglich eine einfache
Klassifizierung ohne Unterklassen möglich. Die Stichworte (engl. Tags) dienen der
Navigation in thematisch verwandten Dokumentenmengen. Es handelt sich also bei den Tags
um deskriptive Meta-Daten.
85 Vgl. [Benford et al. 2002].
86 Vgl. [Nottingham/Sayre 2005].
87 Vgl. [Cadenhead et al. 2009].
88 Vgl. [Gilbert et al. 2009], S. 33.
41
Alle gängigen als Social Software positionierten Plattformen sind als Browser-basierte
Applikation ausgeführt, um die Einstiegshürde für Anwender gering zu halten und Partizipa-
tion neuer Anwender möglichst einfach zu gestalten. Für einige Dienste stehen Desktop-
Applikationen mit Spezialfunktionen wie Offline-Bearbeitung von Dokumenten oder erwei-
terte Auswertungs- und Verwaltungsfunktionen zur Verfügung. Das soziale Netzwerk Yahoo
Flickr89 bietet etwa eine Desktop-Applikation zum effizienteren Ablegen von Bildern im
Netzwerk an und del.icio.us stellt Erweiterungen für Browser zur Verfügung, mit denen dem
Dienst ein Lesezeichen und beschreibende Tags für die aktuell angezeigte Webseite hinzu-
gefügt werden können.
2.3.2.5 Workflow- und Projektmanagement
Ein Workflow ist das informationstechnische Modell eines Geschäftsprozesses. „Ein
Geschäftsprozess beinhaltet die Gesamtheit und Aufeinanderfolge von Arbeitsschritten zum
Erbringen einer Leistung für einen oder mehrere Kunden.“90 Der Begriff Kunde bezeichnet
dabei den Abnehmer der Leistung und bezieht sich sowohl auf Kunden des Unternehmens, als
auch auf interne Kunden, die eine erstellte Leistung als Produktionsfaktoren für weitere
Geschäftsprozesse nutzen. Eine konkrete Instanz des Modells wird als Vorgang bezeichnet.
Workflowmanagement umfasst Konzepte zur Planung, Modellierung und Simulation von
Workflows sowie die Steuerung und Überwachung von Vorgängen.91 Ein Workflow-
management-System (WfMS) unterstützt die genannten Tätigkeiten. Der Zweck dieser
Systeme ist die Unterstützung von arbeitsteiligen Abläufen im Unternehmen, deren Bearbei-
tung geplant und strukturiert stattfindet. Ein WfMS dient also der Koordination der Aufga-
benbearbeitung im Rahmen von Vorgängen. Im Kontext dieser Arbeit sind lediglich WfMS
relevant, die am kollaborativen Arbeitsplatz eingesetzt werden, und die der Erstellung und
Bearbeitung von Dokumenten dienen.
Workflowmanagement soll beispielsweise die Durchlaufzeiten von Vorgängen reduzieren und
somit Kosten senken oder die Kundenzufriedenheit erhöhen. Die bei Koordinationsprozessen
charakteristischen Interdependenzen zwischen arbeitsteiligen Tätigkeiten sollen minimiert
werden. Wenn dies gelingt, entstehen für die Beteiligten geringere Transaktionskosten92.
Aber auch die Produktivität der Prozessbeteiligten kann gesteigert werden. So kann
üblicherweise jederzeit der aktuelle Bearbeitungsstatus eines Dokuments festgestellt werden,
das Nachfragen bei Prozessbeteiligten entfällt. Außerdem kann der gesamte Ablauf durch das
89 Vgl. http://www.flickr.com/tools/uploadr [07.10.2011].
90 Vgl. [Nastansky et al. 2002], S. 285.
91 Vgl. [Borghoff/Schlichter 1998], S. 346.
92 Vgl. [Picot/Dietl/Franck 2005], S. 63.
42
System dokumentiert werden, so dass Entscheidungen transparenter werden und Personen
bestimmte Bearbeitungsschritte ex post zugeordnet werden können. Die verbesserte
Transparenz der arbeitsteiligen Gruppenarbeit bietet auch unter dem Gesichtspunkt der
Agenturtheorie Vorteile, denn durch die Verringerung der Informationsasymmetrie kann die
Möglichkeit zu opportunistischem Verhalten des Agenten gegenüber dem Principal reduziert
werden. Außerdem ist die im WfMS mögliche Protokollierung von Prozessschritten wichtig
für Compliance der Prozesse im Unternehmen.
Die Bearbeitung eines Arbeitsschrittes und die Weiterleitung an den nächsten Bearbeiter eines
Dokuments findet durch zugewiesene Ressourcen statt. Dabei kann es sich sowohl um Mitar-
beiter, als auch um Software-Agenten handeln, die automatisiert und regelbasiert die Bear-
beitung und Weiterleitung durchführen. Insbesondere bei der Modellierung vollständig
vordefinierter Workflows ist es notwendig, mit Organisationseinheiten zu arbeiten, statt
konkrete Individuen der Aufgabenbearbeitung als Ressourcen hinzuzufügen, da sonst im Falle
einer Änderung einer Ressource stets der Prozess geändert werden müsste. Organisations-
einheiten sind etwa Abteilung, Rolle oder Arbeitsgruppe. Zum Zeitpunkt der Weiterleitung
des Dokuments wird durch das WfMS festgestellt, welche konkreten Ressourcen Teil der
Organisationseinheit, und somit nächste Bearbeiter des Vorgangs sind. Damit die automati-
sche Zuweisung konkreter Ressourcen durch das System erfolgen kann, muss neben der
Modellierung des Workflows auch die Aufbauorganisation modelliert, und das Modell in
einem Repository hinterlegt werden.93 Dieses Repository wird als Organisationsverzeichnis
bezeichnet. Als Organisationsverzeichnis kann auch ein Directory Verwendung finden.
Eine vollständige Modellierung und Vordefinition von Workflows ist jedoch nicht immer
möglich, und auch nicht immer ökonomisch sinnvoll. Denn die präzise und vollständige
Beschreibung von schwach strukturierten Vorgängen, die Voraussetzung für eine Automati-
sierung ist, würde unter Umständen einen höheren Aufwand bedeuten, als eine manuelle
Bearbeitung der Tätigkeiten. Eine Unschärfe der Arbeitsaufträge für Wissensarbeiter bietet
stets Interpretationsspielraum, aber auch hinreichend Raum für Kreativität und das Einbringen
von eigenem Wissen. Der Wissensarbeiter hat die Fähigkeit, auf unvollständige, unpräzise
Beschreibungen von Aufträgen, aufgrund von Erfahrung und gesundem Menschenverstand
dennoch im Sinne der Intention des Auftraggebers zu handeln. Zudem kann er sich als Agent,
falls sich sein Verständnis der Auftragsbeschreibung nach Rücksprache mit dem Principal als
nicht intendiert herausstellt, flexibel auf die neu kommunizierte Interpretation einstellen. Da
Computer nicht über diese Fähigkeit verfügen, lässt sich für Tätigkeiten mit geringer Anzahl
93 Vgl. etwa [Ott 1998].
43
gleichartiger Wiederholungen durch Automatisierung keine Produktivitätsverbesserung
erzielen.
Bei der informellen Beschreibung von Tätigkeiten kann der Mensch jedoch unterstützt
werden. Fikes schlägt etwa ein Commitment-basiertes Framework für informelle kooperative
Arbeit vor, das dazu dienen kann, Menschen bei der Beschreibung und Bearbeitung von
informellen Tätigkeiten zu unterstützen.94 Huth entwirft ein Framework, das auch Ad-hoc-
Vorgänge durch ein Modellierungswerkzeug unterstützt, und eine partizipative Voraus-
planung durch die Prozessbeteiligten ermöglicht.95 So können auch im Ad-hoc-Bereich
Prozesse transparenter ausgeführt werden, mit den zuvor genannten Vorteilen. Abbildung 2-6
zeigt das beschriebene Spektrum unterschiedlicher Grade der Strukturiertheit. Der Wissens-
arbeiter ist üblicherweise mit Workflows aller Grade beschäftigt, jedoch wird der Schwer-
punkt der Tätigkeit im Bereich von eher flexiblen, einmaligen und änderbaren Workflows
liegen (Bereich 1: Ad-hoc-Workflow).
- hohe Frequenz
- vollständig
vordefiniert
- hoher Automatisie-
rungsgrad
- hohe Wiederholungsfrequenz
- vollständig vordefiniert
- einfache durchführbare Ad-hoc-Änderungen
-dringend
- kurzlebig
- außergewöhnlich
- vertraulich
z. B. Standard-
Kundenkreditanfrage
z. B. Kunden-
Kreditanfrage
mit einer
besonderen
Eigenschaft
z. B. Lösen
eines
Software-
Problems
z. B. Ko-
Autorenschaft
eines
jährlichen
Berichts
z. B.
Delegieren
einer Aufgabe
z. B. Ko-
Autoren-
schaft einer
Veröffent-
lichung
z. B. neue Arten von Anfragen,
c) Ad-hoc-
Modifikation
eines vordef.
Workflow
b) Integration
eines Sub-
Workflows in
einen vordef.
Workflow
a) Integration
von offener
Team-Arbeit
in einen
vordef. WF
d) Ad-hoc-
Workflow mit
Sub-
Workflow
c) Offene
Team-Arbeit
in Ad-hoc-
Workflow
b) Partielle
Voraus-
planung
a) Store-and-
forward,
E-Mail
3. Vollständig
vordefinierter
Workflow
2. Semi-strukturierter Workflow1. Ad-hoc-Workflow
- hohe Frequenz
- vollständig
vordefiniert
- hoher Automatisie-
rungsgrad
- hohe Wiederholungsfrequenz
- vollständig vordefiniert
- einfache durchführbare Ad-hoc-Änderungen
-dringend
- kurzlebig
- außergewöhnlich
- vertraulich
z. B. Standard-
Kundenkreditanfrage
z. B. Kunden-
Kreditanfrage
mit einer
besonderen
Eigenschaft
z. B. Lösen
eines
Software-
Problems
z. B. Ko-
Autorenschaft
eines
jährlichen
Berichts
z. B.
Delegieren
einer Aufgabe
z. B. Ko-
Autoren-
schaft einer
Veröffent-
lichung
z. B. neue Arten von Anfragen,
c) Ad-hoc-
Modifikation
eines vordef.
Workflow
b) Integration
eines Sub-
Workflows in
einen vordef.
Workflow
a) Integration
von offener
Team-Arbeit
in einen
vordef. WF
d) Ad-hoc-
Workflow mit
Sub-
Workflow
c) Offene
Team-Arbeit
in Ad-hoc-
Workflow
b) Partielle
Voraus-
planung
a) Store-and-
forward,
E-Mail
3. Vollständig
vordefinierter
Workflow
2. Semi-strukturierter Workflow1. Ad-hoc-Workflow
determiniert, hoch-strukturiert, wiederkehrend
Tendenz der zeitlichen Entwicklung von Prozessen
flexibel, änderbar, einmalig
Abbildung 2-6: GroupProcess Workflow Kontinuum96
Ähnlich wie ein Workflow findet auch ein Projekt im Kontext unternehmerischer Tätigkeit
mit dem Ziel der Erstellung einer Leistung statt. Kennzeichen eines Projekts sind, dass die
Durchführung weitgehend einmalig ist und die Strukturierung der Vorgänge eine gewisse
Komplexität aufweist. Üblicherweise finden bei Projekten zudem eine zeitliche Voraus-
94 Vgl. [Fikes 1982].
95 Vgl. [Huth 2004].
96 Vgl. [Huth 2004], S. 94. Siehe auch [Huth/Erdmann/Nastansky 2001], S. 4.
44
planung sowie die Vorausplanung eines Kosten- und Aufwandsrahmens statt.97 Aufgrund der
zeitlichen Nähe zwischen Planung und Ausführung ist es nicht üblich, die Besetzung von
Vorgängen mit Ressourcen durch Organisationseinheiten vorzunehmen, sondern durch
konkrete Personen. In Projekten mit sehr langer Laufzeit kann dies anders sein, etwa wenn die
zum Zeitpunkt der Ausführung verfügbaren Ressourcen zum Planungszeitpunkt unbekannt
sind. Dieser Sonderfall soll im Rahmen dieser Arbeit nicht berücksichtigt werden.
Projektmanagement umfasst die Tätigkeiten der Planung, Überwachung und Steuerung von
Projekten.98 Üblicherweise unterstützen Projektmanagement-Systeme (PMS) die am Projekt
beteiligten Ressourcen daher durch Planungswerkzeuge und Überwachungsfunktionalität für
relevante Kennzahlen wie Zeit, Aufwand und Kosten sowie bei der Definition von Abhän-
gigkeiten zwischen Vorgängen oder Teilprojekten. Aus diesen Abhängigkeiten und dem
definierten Start- und Endpunkt ergeben sich Termine für den Beginn- und den Endzeitpunkt
von Vorgängen. Auch bei der Berechnung dieser Termine unterstützen PMS.
Projekte weisen in der Unternehmenspraxis häufig Ähnlichkeiten zu bereits durchgeführten
Projekten auf. Daher werden auch von Projekten Vorlagen gebildet, die als Grundlage
zukünftig zu planender, ähnlicher Projekte dienen können. Eine Abstrahierung und Modellie-
rung einer Projektvorlage ist hilfreich, z. B. durch Verwendung von Organisationseinheiten
im Rahmen einer Aufbauorganisation, so dass die Abgrenzungsmöglichkeiten zu Workflows
zunehmend verschwimmen.
Abbildung 2-7: Klassifizierung von Projekt- und Workflowmanagement-Systemen99
97 Für weitere Merkmale vgl. [Ehlers 1997], S. 13 ff.
98 Für weitere Merkmale vgl. [Ehlers 1997], S. 15 f.
99 In Anlehnung an [Riempp 1998], S. 43.
45
Riempp nimmt eine solche Abgrenzung von Projekten und Workflows vor. Er klassifiziert in
Abhängigkeit von der Anzahl der Wiederholungen sowie der Möglichkeit, im Vorfeld der
Durchführung eine Strukturierung vorzunehmen (vgl. Abbildung 2-7). Dabei wird ersichtlich,
dass es eine Vielzahl überlappender Bereiche gibt in denen unklar ist, ob ein PMS oder ein
WFMS geeigneter für die Unterstützung der Bearbeitung der Vorgänge ist. Es wird deutlich,
dass auch durch Projekte die Umsetzung eines Geschäftsprozesses erfolgen kann. Auch
können innerhalb eines Projekts Workflows auftreten, etwa ein Projektantrag oder ein Antrag
auf Zuteilung einer Ressource. Um der Praxisanforderung nach einem Werkzeug für
integriertes Projekt- und Prozessmanagement näher zu kommen verfolgt etwa das InterPROM
Forschungsprojekt einen integrierten Ansatz. Das Projekt zeigt unter Anderem, dass auch der
umgekehrte Fall vorkommt, und dass in diesem Fall die Unterstützung von unstrukturierten
Teilprozessen innerhalb strukturierter Workflows besser durch PMS geleistet werden kann,
als durch WfMS.100 Mit zunehmender Bedeutung der Wissensarbeiter im Unternehmen ge-
winnt dieser integrierte Ansatz an Bedeutung.
2.3.3 Zentraler Zugriffsbereich
Wie bereits in der Einleitung ausgeführt, bevorzugen Anwender einen zentralen, personali-
sierten Zugriffsbereich101 (engl. Single Point of Access), der ihnen den Zugriff auf alle zur
Erledigung ihrer Arbeit benötigten Dokumente und Applikationen ermöglicht. Portal-
technologien und kontextuelle Kollaboration sind Ansätze, diese Herausforderung zu adres-
sieren. Sie werden in den folgenden Abschnitten vorgestellt.
2.3.3.1 Portale
Ein Portal ist eine Server-Applikation, die über eine einheitliche Oberfläche den gleich-
zeitigen Zugriff auf Funktionalitäten aus verschiedenen Applikationen ermöglicht. Die
Darstellung im Browser Client erfolgt über eine als Portlet102 bezeichnete Komponente der
Benutzeroberfläche, von denen mehrere gleichzeitig auf dem Bildschirm in Form von Recht-
ecken dargestellt werden. Ein Portal-Server bietet außerdem eine Anzahl von Diensten, die
für das effiziente Arbeiten mit den Portlets notwendig sind. So sorgt ein Dienst des Servers
dafür, dass die Zusammenstellung benötigter Applikationsfunktionen der Rolle des Anwen-
ders im Unternehmen entspricht. Ein Anwender im Vertrieb bekommt also andere Portlets
und somit andere Funktionalitäten angezeigt, als ein Anwender im Controlling. Auch kann
100 Vgl. [Huth et al. 2007], S. 7.
101 Eigene, bedeutungsgemäße Übersetzung des im Umfeld von Portal-Technologien gebräuchlichen Begriffs
Single Point of Access.
102 Vgl. [Hahnl 2004], S. 85 f.
46
der Anwender üblicherweise die ihm präsentierte Oberfläche seinen Bedürfnissen anpassen.
Diese Funktion wird als Personalisierung bezeichnet.
Zum Zugriff auf die Daten der Applikationen ist in der Regel eine Authentifizierung gegen-
über jeder einzelnen Applikation notwendig. Dies kann dazu führen, dass der Anwender beim
Aufruf einer Seite für jedes Portlet einen Benutzernamen und ein Passwort eingeben muss.
Um dies zu vermeiden, authentifiziert sich der Anwender lediglich gegenüber dem Portal-
Server. Nachdem dieser die Identität des Anwenders festgestellt hat, übernimmt er die
Authentifizierung des Anwenders gegenüber den Applikationen der anderen Portlets. Dieser
Vorgang wird als Single-Sign-On (SSO) bezeichnet. Für weitere Funktionalitäten von Portal-
Servern siehe etwa [Bullinger et al. 2002] oder [Hahnl 2004].
2.3.3.2 Kontextuelle Kollaboration
Kontextuelle Kollaboration (engl. Contextual Collaboration) bezeichnet einen Ansatz, Werk-
zeuge, die kollaborative Funktionalitäten anbieten, in den Kontext anderer Applikationen
einzubetten, so dass der Anwender sie aus dem Arbeitskontext der Applikation heraus auf-
rufen kann. Dies reduziert die Anzahl technisch verursachter, und somit nicht notwendiger
Kontextwechsel am kollaborativen Arbeitsplatz. Der Anwender muss also den Kontext der
Applikation, innerhalb derer er gerade eine Tätigkeit durchführt nicht verlassen. Bearbeitet er
etwa ein Dokument und möchte die Inhalte des Dokuments mit einem Kollegen diskutieren,
kann er direkt aus dem Editor oder der Ansicht der Applikation heraus eine E-Mail schreiben,
einen Chat starten oder eine Videokonferenz einleiten.
Zudem werden möglichst viele Informationen über den aktuellen Arbeitskontext an das
Kollaborationswerkzeug übergeben, um die Produktivität des Anwenders zu erhöhen. Beim
Starten einer Videokonferenz kann etwa das zu diskutierende Dokument automatisch in der
Konferenz angezeigt werden, oder beim Schreiben einer E-Mail wird der Autor des aktuell in
Bearbeitung befindlichen Dokuments ermittelt und dessen E-Mail-Adresse in die neu erstellte
E-Mail eingefügt. In aktuellen CIS findet diese Integration vornehmlich mit Werkzeugen zur
synchronen und asynchronen Kommunikation wie E-Mail und Chat statt. Eine sehr wichtige
Funktionalität ist die Möglichkeit, im Kontext einer Applikation zu sehen ob potenzielle
Kollaborationspartner für synchrone Kommunikation verfügbar sind, etwa am Arbeitsplatz-
rechner oder auf einem Mobiltelefon. Diese Funktion wird als Präsenzinformation (engl.
Awareness) bezeichnet.103 Ein weiteres Beispiel ist die Einbettung von Chat in einen
103 Vgl. [Hupfer et al. 2004].
47
kollaborativen Dokumenten-Editor104. In den genannten Beispielen kann als weitere Funktion
der kontextuellen Einbettung das Resultat der Chat-Kommunikation als Dokument im Kon-
text des Ursprungsdokuments referenziert oder abgelegt werden, um dem Anwender das
erneute Auffinden dieser Informationen zu erleichtern.
Aktuell haben sich noch keine Standardschnittstellen für kontextuelle Kollaboration etabliert.
Die Einbettung eines kontextuellen Werkzeugs muss also für jede einzelne Applikation erneut
durchgeführt werden. Derartige Funktionalitäten finden sich daher üblicherweise nur in
integrierten Applikationsfamilien, in denen die einzelnen Werkzeuge bereits aufeinander
abgestimmt sind. Oder es werden Werkzeuge in Form von Erweiterungen für weit verbreitete
Software angeboten, wie beispielsweise Microsoft Office.
2.4 Aktivitäten-zentrische Ansätze
Tätigkeiten, die ein Anwender am kollaborativen Arbeitsplatz ausführt, werden als Aktivitäten
bezeichnet. Aktivitäten-zentrische Ansätze zum Entwurf von Software-Werkzeugen unter-
stützen den Wissensarbeiter bei der Organisation, Strukturierung und Planung seiner Aktivi-
täten. Die Unterstützung umfasst die Verbesserung der Nutzung von Dokumenten, Werkzeu-
gen und Kollaborationsmöglichkeiten mit Teammitgliedern im Kontext seiner Aufgaben-
bearbeitung. Im Folgenden werden hierzu verwandte Konzepte aufgezeigt.
2.4.1 Kontextmanagement
Ein Teil der Dokumente am kollaborativen Arbeitsplatz enthält unstrukturierte Inhaltsdaten.
Wie in Abschnitt 2.2.2.4 ausgeführt ist es wichtig, dass ein Dokument über Summary-Daten
verfügt. Durch die hierarchische Klassifizierung von Summary-Daten wird es ermöglicht,
anhand verschiedener Kriterien mit wenigen Navigationsschritten durch eine große Menge
von Dokumenten zu navigieren. Die Verwaltung, Pflege und teilweise auch die automatisierte
Generierung von Summary-Daten wird durch WMS unterstützt. Dabei liegt der Fokus häufig
auf dem Management semantischer Gemeinsamkeiten, die Interpretationen des Inhalts von
Dokumenten und das Auffinden von Dokumenten anhand inhaltlicher Gemeinsamkeiten
unterstützen. Es handelt sich hier also um deskriptive Meta-Daten. Für das Individuum ist es
jedoch entscheidend, dass auch für die Kontext-Daten ein sinnvolles, ganzheitliches
Management Konzept existiert. Traditionell sind Applikationen auf das Management jeweils
eines Geschäftskontexts spezialisiert. Ein WFMS ist für die Prozesse zuständig, ein PMS für
Projekte, ein CRM System für den Korrespondenzkontext mit einem Kunden.
104 Vgl. [Churchill et al. 2000].
48
Da jeder Anwender bei der Durchführung von Tätigkeiten üblicherweise mit Dokumenten
arbeitet, die sich in unterschiedlichen Geschäftskontexten und Repositories befinden, benötigt
er ein Werkzeug, das ihn bei der Planung, Strukturierung und dem Zugriff auf die Dokumente
unterstützt. Ein Context Management System (CoMS) unterstützt die Organisation von
Kontextinformationen. Dabei werden für die Planung der täglichen Tätigkeiten Kontext-
informationen aus verschiedenen Repositories aggregiert. Dies können Aufgaben im PMS,
der Review eines Dokuments im Web Content Management System, oder eine automatische
Wiedervorlage eines Kunden im CRM System sein.
Der aktuelle Kontext, in dem sich ein Anwender bewegt, hat Auswirkungen auf die Relevanz
und inhaltliche Bewertung von Dokumenten.105 So ist beispielsweise ein Adressdokument
nicht relevant, wenn ein Anwender nach technischen Artikeln sucht. Technische Artikel
hingegen sind nicht relevant, wenn der Anwender gerade nach einer E-Mail-Adresse sucht.
Eine Applikation, die dem Anwender Dokumente bereitstellt und bei der Bewertung der
Relevanz eines Dokuments Kontextinformationen berücksichtigt, wird als Context-aware
Application bezeichnet.106 Dey und Abowd unterscheiden vier Klassen von Kontext-
informationen, aufgrund derer dem Anwender relevante Dokumente präsentiert werden. Dies
sind Informationen über Tätigkeit, Identität, Ort und Zeit.107 Am kollaborativen Arbeitsplatz
haben Tätigkeiten und zur Tätigkeitsbearbeitung notwendige Dokumente und Personen eine
besondere Relevanz. Die Kontextklassen Ort und Zeit werden vernachlässigt.
Um Kontextinformationen zu klassifizieren und so etwa navigierbar zu machen müssen sie
zunächst strukturiert expliziert werden. Die strukturierten Kontext-Daten aus verschiedenen
Applikationen müssen dann über Schnittstellen dem CoMS zur Verfügung gestellt werden.
Aufgrund von fehlenden Standards muss hier stets eine Transformation von bereitgestellten
Kontextinformationen in das Zielformat des CoMS erfolgen. Auch für dieses Format existiert
kein Standard.108 Böhm/Härtwig schlagen vor, die Business Process Execution Language
(BPEL)109 zu verwenden,110 die sich jedoch primär zur Darstellung von Prozess-orientierten
Kontext-Daten eignet. Andere propagieren eigene Vorschläge, z. B. Bucur/Beaune/Boissier111
oder Cappiello et al.112. Die Veröffentlichungen im Bereich von Kontextmanagement zeigen,
105 Vgl. [Schmidt/Bannon 1992], S. 33.
106 Vgl. [Dey/Abowd 1999], S. 6.
107 Vgl. [Dey/Abowd 1999], S. 9.
108 Vgl. [Cappiello et al. 2006], S. 73.
109 Vgl. BPEL Spezifikation in [Jordan/Evdemon 2007].
110 Vgl. [Böhm/Härtwig 2005].
111 Vgl. [Bucur/Beaune/Boissier 2006].
112 Vgl. [Cappiello et al. 2006].
49
dass noch viel Forschungsbedarf besteht. Außerdem bedarf es der Definition von Standards
zur Kontextexplikation.
2.4.2 Tätigkeitstheorie
Die Tätigkeitstheorie (engl. Activity Theory) geht auf den Psychologen Aleksej Nikolaevič
Leont’ev113 zurück. Im Zentrum der Theorie steht die Intention, die Natur bewusster mensch-
licher Tätigkeiten zu erklären.114 Eine Tätigkeit ist also eine bewusste, durch Motive geleitete
Handlungsabfolge. In der Tradition der kulturhistorischen Psychologie wird in der Tätig-
keitstheorie die soziale und kulturelle Umgebung des Handelnden als ein wichtiger Einfluss-
faktor auf sein Handeln betrachtet. Als Basiseinheit einer Tätigkeit wird die Interaktion
zwischen Subjekt und Objekt betrachtet. Bezogen auf den Kontext dieser Arbeit ist dies die
Interaktion eines Menschen mit IT-Artefakten, bzw. die Interaktion eines Wissensarbeiters
mit Dokumenten (vgl. Abschnitt 2.2.1). Im Folgenden werden die grundlegenden Prinzipien
der Tätigkeitstheorie erläutert.115
1 Objekt-Orientiertheit
Auslöser einer Tätigkeit ist ein bewusstes Bedürfnis eines Subjekts. Das Bedürfnis ist das
Motiv für die Durchführung der Tätigkeit. Während der Durchführung werden eines oder
mehrere Objekte durch ein Subjekt transformiert. Diese Orientierung der Tätigkeitstheorie an
Objekten und deren Transformation wird als Objekt-Orientiertheit bezeichnet. Motive für die
gleiche Tätigkeit können unterschiedlich sein. Ist beispielsweise eine Gruppe von Menschen
gemeinsam auf der Jagd nach einem Tier, so kann ein Motiv der Wunsch nach Essen sein.
Dieses Motiv ist jedoch subjektiv. Während das Motiv einer Person Hunger ist, kann das
Motiv einer andere Person aus der Gruppe etwa das Sammeln einer Trophäe sein, um das
Ansehen als Jäger innerhalb der sozialen Gemeinschaft zu steigern. Obwohl Beide unter-
schiedliche Motive haben, beteiligen sie sich kollaborativ an der Tätigkeit Jagd. Das Objekt
Tier wird dabei in Nahrung und Trophäe transformiert.
2 Hierarchische Struktur von Tätigkeiten
Bei der Analyse einer Tätigkeit können verschiedene Ebenen von Teil-Tätigkeiten untersucht
werden. So könnte die Gruppe von Personen auf der Jagd arbeitsteilig vorgehen. Ein Teil der
Gruppe schlägt mit Stöcken ins Unterholz um das Tier in Richtung der zweiten Gruppe zu
treiben, die dann das Tier erlegt. Die Handlung des Stockschlagens für sich genommen
erscheint irrational. Das Ziel der Handlung ist nicht erkennbar, ohne das Motiv der Tätigkeit
113 Leont’ev ist akademischer Schüler des Begründers der kulturhistorischen Schule Lev S. Vygotskij.
Schreibweise des Namens nach [Leont’ev 1977].
114 Vgl. [Leont’ev 1977].
115 Vgl. [Kaptelinin/Nardi 2006], S. 66 ff.
50
zu kennen. Kuutti bezeichnet daher eine Tätigkeit als den minimalen Bedeutungskontext um
individuelle Handlungen zu verstehen.116 Eine Tätigkeit kann aus einer Vielzahl von Hand-
lungen und Operationen bestehen. So kann vor der Jagd ein Speer zum Erlegen des Tiers
angefertigt worden sein, Proviant wurde verpackt und das Dorf gegen Angriffe während der
Abwesenheit der Gruppe gesichert. Die Sicherung des Dorfes setzt sich wiederum aus einer
Anzahl von Handlungen zusammen.
Abbildung 2-8: Hierarchische Ebenen einer Tätigkeit117
Findet eine Handlung unbewusst statt, wird sie als Operation bezeichnet. Aufgrund von
Übungseffekten können sich wiederholende Handlungen eines Individuums im Laufe der Zeit
zu Operationen entwickeln. In der Fahrschule muss beispielsweise das Schalten der Gänge im
Fahrzeug sowie das Lenken zunächst erlernt werden. Jede Handlung wird bewusst durchge-
führt. Mit zunehmender Übung wird aus der bewussten Handlung des Schaltens und Lenkens
jeweils eine Operation. Die Operation wird unbewusst durchgeführt, das Bewusstsein ist auf
andere Handlungen fokussiert, wie die vorausschauende Beobachtung des Verkehrsflusses.
Ob ein Mensch bewusst oder unbewusst handelt hängt von vielen Faktoren, wie der Ausbil-
dung, der Erfahrung, dem sozialen Umfeld oder persönlichen Talenten ab. Abbildung 2-8
zeigt die beschriebenen Ebenen einer Tätigkeit.
3 Internalisierung und Externalisierung
Internalisierung und Externalisierung beschreiben die Prozesse der Interaktion des mensch-
lichen Geistes mit der sozialen und kulturellen Umgebung. Die Tätigkeitstheorie unter-
scheidet zwischen internalen und externalen Tätigkeiten. Internale Tätigkeiten sind mentale
Prozesse, etwa die Planung einer Tätigkeit oder die Simulation verschiedener Handlungs-
alternativen. Externale Tätigkeiten bestehen aus dem sichtbaren Verhalten des Menschen, also
der Umsetzung von mentalen Prozessen. Als Internalisierung wird der Transformations-
prozess der externalen Tätigkeit in die internale Tätigkeit bezeichnet. Analog werden bei der
Externalisierung internale Tätigkeiten in externale Tätigkeiten transformiert. Dies ist wichtig
116 Vgl. [Kuutti 1996], S. 28.
117 In Anlehnung an [Kaptelinin/Nardi 2006], S. 64.
51
um beispielsweise internale Tätigkeiten an der Realität zu überprüfen oder eine Tätigkeit
arbeitsteilig in einer Gruppe zu koordinieren. Auch aufgrund der begrenzten kognitiven
Fähigkeiten des Menschen (vgl. Abschnitt 2.2.1) ist häufig eine Externalisierung mentaler
Prozesse durch Erstellung eines Artefakts nötig.
4 Vermittlung (Mediation)
Werkzeuge beeinflussen die Art und Weise, wie ein Mensch mit seiner Umgebung inter-
agieren kann. Des Weiteren repräsentieren Werkzeuge und andere Artefakte die Erfahrungen
und das Wissen eines Menschen, spiegeln kulturelle Errungenschaften wider und ermöglichen
die Übertragung dieses Wissens an die soziale Gemeinschaft. Artefakte wirken also als
Vermittler zwischen dem Subjekt und dem Objekt. Sie sind ein wichtiges Hilfsmittel beim
Transformationsprozess des Objekts.
Wird das Konzept der Tätigkeit auf die Gemeinschaft ausgedehnt und koordinierte Arbeits-
teilung betrachtet, so ist auch die Arbeitsteilung Mediator. Ebenso sind Regeln zu betrachten,
die als Mediator zwischen dem Subjekt und der Gemeinschaft wirken. Sie umfassen etwa
Normen, Konventionen und Gesetze der Gemeinschaft, nach denen sich das Subjekt richten
muss.
5 Entwicklung
Im Rahmen der Tätigkeitstheorie wird angenommen, dass die menschliche Interaktion mit der
Umwelt im Kontext der kulturhistorischen Entwicklung einer sozialen Gemeinschaft analy-
siert wird. Jegliche Erfahrung oder Gewohnheit bei der Durchführung einer Tätigkeit ist das
Resultat einer Entwicklung der Durchführung. Entwicklung ist ein fortwährender Prozess des
Sammelns von individuellen und kollektiven Erfahrungen. Im Zuge von Internalisierung und
Externalisierung beeinflussen sich Subjekt, Objekt und Werkzeug gegenseitig. Durch das
Ausführen, Üben und Diskutieren von Tätigkeiten in der Gemeinschaft wird die Reflexion
von Prozessen ermöglicht und es können Verbesserungen erzielt werden, z. B. durch Ver-
besserung der Fertigkeiten des Subjekts, Verbesserung von Werkzeugen oder Verwendung
anderer, besser geeigneter Objekte. Durch Übung werden außerdem Handlungen zu Operatio-
nen, und die Durchführung somit effizienter.
52
Abbildung 2-9: Struktur einer Tätigkeit118
Die genannten Prinzipien beschreiben ein komplexes System von Interdependenzen zwischen
Subjekt, Objekt und der sozialen und kulturellen Umgebung in Form der Gemeinschaft.
Abbildung 2-9 visualisiert das System der Mediation zwischen den Entitäten. Die Entitäten
Subjekt, Gemeinschaft und Objekt stehen zueinander in Beziehung. Eine gegenseitige Beein-
flussung erfolgt durch die Mediatoren Werkzeug, koordinierte Arbeitsteilung und Regeln. Das
Motiv für das Erstellen des Ergebnisses durch Transformation des Objektes ist die Ursache
für die Tätigkeit. Objekt bezeichnet dabei eines oder mehrere physische Objekte, oder auch
ein oder mehrere immaterielle Güter. Als komplexes System repräsentiert das in der Abbil-
dung dargestellte Geflecht die Struktur einer Tätigkeit.
Die Tätigkeitstheorie bietet durch den Fokus auf Mediation durch Werkzeuge Anwendungs-
möglichkeiten in Bezug auf die Interaktion zwischen Mensch und Computer (engl. Human
Computer Interaction, HCI). Durch die Berücksichtigung arbeitsteiliger Tätigkeiten und
sozialer Prozesse gilt dies insbesondere für die Analyse der Interaktion des Menschen mit CIS
und dem Entwurf von Interaktionskonzepten für CIS. Veröffentlichungen von Engeström119,
Kuutti120 und Bødker121, später von Kaptelinin122, Nardi123 und Anderen ließen der
Tätigkeitstheorie in den 1990er Jahren internationale Aufmerksamkeit im Bereich der HCI
Forschung zuteil werden. Diese Veröffentlichungen bilden die konzeptionelle Basis für die
Anwendung von Tätigkeitstheorie auf HCI und CSCW. Tabelle 2-2 zeigt Beispiele, wie die
Informationstechnologie Anwender bei der Ausführung von Tätigkeiten unterstützen kann.
118 In Anlehnung an [Kuutti 1991], S. 257.
119 Vgl. etwa [Engeström 1990] und [Engeström/Miettinen/Punamäki 1999].
120 Vgl. [Kuutti 1991].
121 Vgl. [Bødker 1991].
122 Vgl. etwa [Kaptelinin/Kuutti/Bannon 1995] und [Kaptelinin 1996].
123 Vgl. etwa [Nardi 1996] und [Nardi 1998].
53
Jeder der Ebenen einer Tätigkeit werden dabei Beispiele zugeordnet, wie eine Unterstützung
auf dieser Ebene durch IT erfolgen kann. Dabei erfolgt eine Zuordnung zu der jeweiligen
Entität der Tätigkeitsstruktur. Eine Unterstützung auf Ebene der Tätigkeit in Bezug auf das
Objekt kann etwa erfolgen, indem ein Objekt zu einem gemeinsam genutzten Objekt wird.
Angewendet auf ein konkretes Beispiel ist dies etwa die Bereitstellung eines Dokuments, das
zur Bearbeitung der Tätigkeit im Team benötigt wird. In Bezug auf die Gemeinschaft ist dies
die Gründung einer neuen Gemeinschaft, etwa durch Bereitstellung einer Online-Community,
in der Fragen zur Tätigkeit diskutiert werden können.
Unterstützung auf
Ebene der Operation Unterstützung auf Ebene
der Handlung Unterstützung auf
Ebene der Tätigkeit
Werkzeug • Abläufe
automatisieren
• Unterstützung von
transformativen oder
manipulierenden Hand-
lungen, etwa das Anzei-
gen eines Dokuments
• Die Automatisierung
eines neuen Ablaufs
ermöglichen oder
Erstellung eines neuen
Werkzeugs
Objekt • Daten über ein
Dokument zur Verfü-
gung stellen
• Ein Objekt manipulierbar
machen, etwa das
Bearbeiten eines
Dokuments
• Ein Objekt zu einem
gemeinsam genutzten
Objekt machen, etwa
gemeinsame Doku-
menten-Bearbeitung
Subjekt • Vordefinierte
Antworten auslösen
• Unterstützung der
Sinnbildung innerhalb
einer Tätigkeit, etwa
durch Kontext-
management Unter-
stützung
• Unterstützung von
Lernen und Reflexion
in Bezug auf das
gesamte Objekt und
die Tätigkeit
Regeln • Einen Satz von Regeln
einbetten oder
anwenden, etwa durch
Implementierung eines
Workflows
• Einen Satz von Regeln
wahrnehmbar und ver-
ständlich machen, etwa
durch Visualisierung eines
Workflows
• Das Aushandeln neuer
Regeln ermöglichen,
etwa partizipatives
Design eines
Workflows
Gemeinschaft • Eine implizite
Gemeinschaft ein-
richten, indem die
Arbeitsaufgaben
mehrerer Personen
verknüpft werden
• Unterstützung von
Kommunikations-
handlungen, etwa durch
E-Mail
• Das Netzwerk von
Subjekten sichtbar
machen, etwa durch
soziale Netzwerke
• Die Gründung einer
neuen Gemeinschaft
ermöglichen, etwa
durch Self-Service
Funktionen zur
Erstellung eines
Teamraums
Arbeitsteilung • Einbettung und
Ausführung von
Arbeitsteilung, etwa
durch ein WfMS
• Sichtbar und verständlich
machen von Arbeits-
organisation, etwa die
Hilfefunktion zu einem
WfMS
• Die Reorganisation
von Arbeitsteilung
ermöglichen, etwa
durch Ausnahme-
behandlung in
Workflows
Tabelle 2-2: Klassifizierung der Unterstützungsmöglichkeiten von Aktivitäten durch IT124
Aufbauend auf den genannten Veröffentlichungen begann Anfang der 2000er Jahre ein Trend,
Systeme zu konzipieren und zu implementieren, die mit Ansätzen aus der Tätigkeitstheorie
124 Beispiele auf Basis von [Kuutti 1996], S. 36.
54
korrespondieren.125 Diese Systemklasse wird mit Begriffen wie „Activity-centered
Computing“126, „Activity-centric Collaboration“127 und später als „Unified Activity
Management“128 (UAM) bezeichnet. Die beiden letztgenannten Bezeichnungen leiten sich
nicht explizit aus der Tätigkeitstheorie ab, weisen aber eine große Nähe zu den Ansätzen der
Tätigkeitstheorie auf.129 Das Ziel dieser Systeme ist die Unterstützung des Wissensarbeiters
bei der Verwaltung, Strukturierung, Priorisierung und Koordination der arbeitsteiligen
Bearbeitung von Tätigkeiten.
125 Vgl. etwa [Christensen/Bardram 2002] und [Kaptelinin 2003].
126 Vgl. [Christensen/Bardram 2002].
127 Vgl. [Geyer et al. 2003], [Muller et al. 2004] und [Millen et al. 2005].
128 Vgl. [Moran 2005], [Moran 2005] und [Moody et al. 2006]. Anmerkung: In [Moran 2003] findet das Wort
„Unified“ noch keine Verwendung.
129 Moran nimmt eine Abgrenzung vor in [Moran 2005], S. 6 ff.
55
3 Charakteristika des kollaborativen Arbeitsplatzes
In diesem dritten Kapitel wird die im Unternehmensumfeld typischerweise vorhandene
Werkzeugunterstützung von Tätigkeiten am kollaborativen Arbeitsplatz diskutiert. Die
Diskussion erfolgt empirisch-induktiv, aufbauend auf dem Ergebnis der Literaturstudie,
zahlreicher Projekterfahrungen mit kollaborativen Technologien am Groupware Competence
Center der Universität Paderborn (GCC) und der langjährigen eigenen Kenntnis des Markts
für kollaborative Technologien.
3.1 Unternehmen in der Wissensgesellschaft
3.1.1 Wissen als Produktionsfaktor
Die Ressource Wissen hat in den vergangenen Jahren zunehmend an Bedeutung für die
Wettbewerbsfähigkeit von Unternehmen gewonnen.130 Aufgrund fortgeschrittener Digitalisie-
rung des kollaborativen Arbeitsplatzes stehen in der Regel alle relevanten Informationen
weltweit und zu jeder Zeit digital zur Verfügung.131 Häufig wird von einer Informations-
überflutung des Wissensarbeiters ausgegangen, die seine Produktivität negativ beeinflussen
kann.132 Zudem hat sich die Zahl der wissensintensiven Unternehmen vergrößert, deren
primärer Produktionsfaktor das organisationale Wissen des Unternehmens ist. Dieses Wissen
kann implizit oder expliziert vorliegen.
Ein Beispiel für expliziertes Methodenwissen ist ein als Projekthandbuch bezeichnetes
Dokument, das als Leitfaden die Durchführung von Projekten im Unternehmen beschreibt.
Existiert kein Dokument dieser Art, kann implizites Methodenwissen über die Durchführung
von Projekten in Form von Mitarbeiterwissen etwa bei Projektleitern vorliegen. Das gleiche
gilt für Geschäftsprozesse im Unternehmen. Eine Beschreibung der Prozesse kann in expli-
zierter Form vorliegen oder kann implizit durch das Wissen eines oder mehrerer Mitarbeiter
repräsentiert sein. Ein einzelner Wissensträger kann beispielsweise ein Prozess-
verantwortlicher sein, der die Ausführung und Verbesserung eines bestimmten Prozesses
überwacht. Es kann aber auch sein, dass nicht eine Einzelperson eine Übersicht über den
Gesamtprozess hat, sondern das Prozesswissen in Form eines Netzwerks einzelner Personen
besteht, die jeweils nur einen Überblick über den Teilprozess haben, an dem sie selbst
beteiligt sind.
130 Vgl. [Probst/Raub/Romhardt 2006], S. 3.
131 Vgl. [Picot/Reichwald/Wigand 2003], S. 6.
132 Vgl. etwa [Simpson/Prusak 1995], [Whittaker/Sidner 1996], [Denning 2006].
56
Wenn keine Explizierung von Methoden- und Prozesswissen vorliegt besteht ein erhöhtes
Risiko für das Unternehmen, dass für die Wettbewerbsfähigkeit wichtiges Kapital, das
Wissen, durch den Ausfall oder Weggang von Wissensträgern nicht mehr als Produktions-
faktor zur Verfügung steht. Auch die Verteilung dieses Wissens wird erschwert. So bezeich-
nen in einer Studie aus dem Jahr 2008 etwa ein Drittel aller befragten Personal-
verantwortlichen die Unfähigkeit, Wissen innerhalb der Organisation zu verteilen als eine der
primären Herausforderungen ihres Unternehmens.133 Insbesondere in wissensintensiven
Branchen ist es daher eine regelmäßige Herausforderung der Unternehmen, die Mitarbeiter
dabei zu unterstützen, relevantes Wissen zu explizieren, in der großen Fülle verfügbarer
Informationen zu identifizieren, in Geschäftskontexte zu bringen und sie dann nutzbringend
einzusetzen. Wie in Abschnitt 2.3.2.3 beschrieben haben viele Unternehmen diese
Notwendigkeit erkannt, Prozesse die den Austausch von Wissen und die Konstruktion neuen
Wissens fördern, etwa durch WMS zu unterstützen.
In den letzten Jahren hat das Zusammenwirken verschiedener Faktoren zu einer grund-
legenden Änderung der Mitarbeiterstruktur in Unternehmen geführt. Zu diesen Faktoren
zählen z. B. die Realisierung von "Lean Management" oder die Senkung der Personalkosten
durch Personalabbau in den Funktionsebenen des mittleren Managements.134 Die Tätigkeiten
dieser Funktionsebenen waren häufig in Bereichen angesiedelt, in denen es um Wissens-
austausch, Vernetzung von Know-How-Trägern und die Förderung von Nachwuchs durch
beratende Mentoring-Funktionen ging. Sie waren Quelle einer Fülle des bereits diskutierten
Methoden- und Prozesswissens. Durch die Schwächung oder Eliminierung dieser Manage-
ment Stufen hat die Bedeutung von CIS für das Unternehmen zugenommen, denn Individuen
und Teams müssen in verteilten Arbeitsumgebungen selbst dafür sorgen, sich zu vernetzen,
Experten für Fachthemen zu identifizieren und notwendiges Prozesswissen aufzubauen oder
in dokumentierter Form aufzufinden. Wissensmanagement wird in Unternehmen demnach
potenziell als Substitut für Wissensträger eingesetzt.
3.1.2 Interorganisationale Kooperation
Die weltweite Verfügbarkeit von Informationen über Produkte und Dienstleistungen sowie
geringe Logistikkosten haben dazu geführt, dass Wettbewerb global stattfindet. Auch werden
mehr Nischen durch Produkte besetzt, die für lokale Märkte aufgrund zu geringer Nachfrage
nicht kostendeckend hätten produziert werden können. D’Aveni und Gunther bezeichnen
133 „Inability to collaborate/share knowledge across the organization“. Vgl. [IBM Corporation 2008], S. 56.
134 Vgl. [Nastansky/Erdmann 2006], S. 30 f.
57
diesen Trend als Hyperwettbewerb.135 Dieser Trend hat dazu geführt, dass Käufer anspruchs-
voller geworden sind. Sie sind nicht mehr bereit, lange Lieferzeiten, mangelhafte Qualität,
schlechten Service oder andere Unzulänglichkeiten zu akzeptieren. Um sich diesen erhöhten
Anforderungen anzupassen, kommt der konsequenten Kundenorientierung eine wichtige
Bedeutung zu. Es setzen sich daher zunehmend neue, modulare Organisationskonzepte durch.
Auch Geschäftsprozesse werden modularisiert. Mitglieder einzelner Module können nah am
Kunden agieren, ihre spezifischen Anforderungen selbstverantwortlich und selbst-
organisierend umsetzen und so schnell auf veränderte Rahmenbedingungen reagieren. Zudem
treten nicht nur Unternehmen verstärkt in Kooperationen ein, sondern auch die Modul-
verantwortlichen beschaffen sich Kompetenz durch interorganisationale Zusammenarbeit mit
anderen Organisationen. Sie bilden Projekt-orientiert virtuelle Organisationen, arbeiten
verteilt, flexibel und an den Schnittstellen zwischen Organisationseinheiten selbst-
organisierend.
Picot/Reichwald/Wigand führen aus, dass diese Organisationsformen unter anderem durch
Kommunikations- und Transporterleichterungen, erleichterte kommunikative Einbindung
dritter Partner, dem weltweiten Zugriff auf Wissensträger und -bestände sowie der Bünde-
lungs- und Vernetzungsmöglichkeiten von Prozessen und Personen möglich werden.136 Unter
der Annahme, dass „[…] Wissen, Fähigkeiten und Fertigkeiten global heterogen verteilt
vorliegen“137 ist die Unterstützung interorganisationaler Kooperation durch entsprechende
CIS also essenziell für flexible und virtuelle Organisationsformen. Die notwendige Flexibilität
setzt jedoch auch voraus, dass Kosten für eine gemeinsame CIS-Umgebung möglichst gering
gehalten werden, um schnell auf Veränderungen des Marktes reagieren zu können. Die
Spezifität der Kooperation muss also gering gehalten werden. Da die Zusammenarbeit
üblicherweise nicht strategischer Natur ist, sondern spontan und ad hoc entstehen kann, ist die
Möglichkeit der spontanen, selbstorganisierenden Kooperation förderlich für das beschriebene
Szenario.
Andere Kooperationsformen erscheinen deshalb ungewöhnlich, weil sie zwischen Wett-
bewerbern geschlossen werden. In Märkten, bei denen die Entwicklung neuer Technologien
sehr große Investitionen erfordert, schließen sich Konkurrenzunternehmen zusammen, um
gemeinsam etwa Basisplattformen für zukünftige Produkte zu entwickeln. Oder sie kaufen
135 Vgl. [D’Aveni/Gunther 1995].
136 Vgl. [Picot/Reichwald/Wigand 2003], S. 6.
137 Vgl. [Picot/Reichwald/Wigand 2003], S. 443.
58
gemeinsam ein, obwohl sie im Verkauf Mitbewerber sind. Diese Art der Zusammenarbeit
wird als Coopetition bezeichnet. 138
Abbildung 3-1: Kontinuum organisationaler Gestaltungsformen139
Andere Unternehmen arbeiten in Teilbereichen zusammen, während sie auf anderen Gebieten
Mitbewerber sind. Beispielsweise arbeitet die IBM Corporation mit der Microsoft
Corporation auf vielen Gebieten zusammen, weil IBM Hardware herstellt, die mit Microsoft
Betriebssystem ausgeliefert wird, und Software herstellt, die auf Microsoft Betriebssystemen
lauffähig sein muss. Auf anderen Gebieten, wie beispielsweise auf dem Gebiet der CIS, sind
beide Firmen Wettbewerber. Abbildung 3-1 zeigt die Vielzahl möglicher Kooperationsformen
in einem Kontinuum.
3.1.3 Fähigkeiten und Erwartungen von Anwendern
3.1.3.1 Funktionsvorsprung privater Kollaborationssysteme
Kollaborative Dienste stehen heute für die private Nutzung auf breiter Basis kostenlos zur
Verfügung, etwa weil sie durch Werbung finanziert werden. Dies sind beispielsweise kosten-
lose E-Mail Dienste wie Google Mail oder Microsoft Hotmail, aber auch Social Software
138 Vgl. [Nalebuff/Brandenburger 1996].
139 Vgl. [Riempp 1998], S. 94.
59
Dienste (vgl. Abschnitt 2.3.2.4). Häufig gibt es neben der kostenlosen Basisversion kosten-
pflichtige Versionen mit erweitertem Funktionsumfang. In Verbindung mit dem häufig
anzutreffenden Geschäftskonzept, Dienste lange Zeit als beta-Plattform mit eingeschränkter
Funktionalität und wenig bis keinem Support zu betreiben und in kurzen Zyklen neue
Funktionen nachzurüsten, setzen sich neue Technologien und innovative Ideen sehr schnell in
breiten Schichten privater Internetanwender durch. Durch direktes Anwenderfeedback in
frühen Phasen der Produktentwicklung können unter diesem Entwicklungsmodell die Bedürf-
nisse der Anwender nach spezifischen Funktionalitäten noch vor der Veröffentlichung des
Produkts berücksichtigt werden. Dies kann helfen, mangelnde Akzeptanz der Anwender für
ein System von vornherein zu minimieren.
Der Einsatz von IT im Unternehmensumfeld unterliegt hingegen einer Reihe von
Restriktionen die dazu führen, dass das zuvor beschriebene Entwicklungsmodell für Unter-
nehmenssoftware nicht geeignet ist. Die Gründe sind etwa hohe Anforderungen an Daten-
sicherheit, Verfügbarkeit und Prozessdokumentation aufgrund von Anforderungen an die
Compliance. Dies führt zu fundamental anderen Anforderungen an den Entwicklungs- und
Deploymentprozess als im Privatbereich. In Verbindung mit hohen Kosten für Entwicklung,
Anpassung, Installation und Wartung führt dies dazu, dass Software-Produktlebenszyklen für
CIS um ein Vielfaches länger sind, als im Bereich von Internet-basierten Diensten kollabora-
tiver Werkzeuge für den Privatgebrauch. Die Anwender von CIS in Unternehmen empfinden
daher häufig ein Fehlen innovativer Werkzeuge am kollaborativen Arbeitsplatz.
Neben dem Fehlen innovativer Werkzeuge sind zudem häufig weitere Einschränkungen am
kollaborativen Arbeitsplatz anzutreffen. So existiert etwa aus Sicherheitsgründen ein Verbot
der Verwendung externer Datenträger. Aus Kostengründen werden Beschränkungen der
Kapazitäten zur Speicherung von E-Mails (Quota) eingeführt. Diese Restriktionen können
jedoch zum Teil zu nicht erwünschten Verhaltensweisen der Anwender führen. So kommt es
vor dass Anwender vertrauliche, unternehmenskritische Informationen unverschlüsselt an ihre
privaten E-Mail-Accounts weiterleiten, bei denen häufig mehrere Gigabyte Speicher-
kapazität140 kostenlos zur Verfügung stehen. So umgehen sie die Quota Restriktion, und
können sich trotz Ermangelung externer Datenträger Arbeit mit nach Hause nehmen.
Verschlüsselte E-Mails können möglichen Schaden durch dieses Verhalten verringern.
Unternehmensextern kommt E-Mail-Verschlüsselung heute jedoch kaum zum Einsatz. Auch
sieht die Gartner Group trotz des beschriebenen Szenarios eine geringe Priorität bei der
140 Beispielsweile stellt die Firma Google Inc. über ihren Dienst Google Mail mehr als 7 Gigabyte kostenlos zur
Verfügung (Stand 09/2009).
60
Umsetzung von E-Mail-Verschlüsselung zwischen Unternehmen.141 Ebenso wird berichtet,
dass vertrauliche Daten wie Projektnamen und Einwahlinformationen für interne Besprechun-
gen verschiedener Beratungsunternehmen, die in der Regel sehr auf Vertraulichkeit bedacht
sind, über öffentliche Kalender ins Internet geraten sind142. Für die Sicherheit von Unter-
nehmensdaten ist diese Tatsache offensichtlich bedrohlich. Neben der Gefährdung der Infor-
mationssicherheit führt das Fehlen von aus dem privaten Umfeld bekannter Werkzeuge,
Konzepte und Dienste zur Frustration unter Mitarbeitern im Unternehmen.
Zudem kann wertvolles expliziertes Unternehmenswissen verloren gehen, weil es nicht in CIS
gespeichert, sondern per E-Mail versendet wird, sowie in Form unverschlüsselter E-Mails für
Wirtschaftsspionage einfach zugänglich ist. Aus den genannten Gründen ist es für Unter-
nehmen erstrebenswert, innovative, kollaborative Werkzeuge für den kollaborativen Arbeits-
platz zur Verfügung zu stellen. Beim Entwurf von CIS ist zu berücksichtigen, dass die Umge-
bung an die individuellen Bedürfnisse der Anwender in Bezug auf Werkzeugoptionen anpass-
bar ist und Restriktionen den Anwender nicht verleiten, auf unternehmensexterne Alternativen
auszuweichen.
3.1.3.2 Situationsbezogene Applikationen und partizipatives Design
Traditionelle Ansätze, mit Daten und Informationen im Unternehmen umzugehen wie struktu-
rierte Workflow-Mechanismen zur Bearbeitung von Dokumenten, oder Mechanismen wie
Enterprise Application Integration (EAI), sind für die zuvor beschriebenen Szenarien nicht
mehr hinreichend. Sie erforderten ausgebildete Spezialisten, um Geschäftsprozesse zu model-
lieren oder Datenquellen entsprechend den Anforderungen verschiedener Applikation aufzu-
bereiten. Auch sind EAI-Ansätze hauptsächlich geeignet, um strukturierte Daten auszutau-
schen. Die sich dynamisch verändernden Anforderungen im Hyperwettbewerb erfordern
jedoch neue Formen flexibler Applikationskonzepte. Zunächst kann aufgrund von verkürzten
Produktlebenszyklen nicht auf die teilweise langen Entwicklungszeiten traditioneller Appli-
kationen gewartet werden, weil sie in kurzer Zeit benötigt werden, um auf Markt-
anforderungen reagieren zu können. Zudem ist die Vielfalt verfügbarer Spezialapplikationen
sehr groß. Eine zentral gesteuerte IT kann z. B. bei den in Abschnitt 3.1.2 genannten modula-
ren Organisationsformen schwer antizipieren, welche Applikationen aus dem breiten verfüg-
baren Spektrum in interorganisationalen, selbstorganisierenden Teams benötigt werden.
141 Vgl. Hype Cycle for Collaboration and Communication, [Smith et al. 2006], S. 5.
142 Vgl. [McMillan 2007].
61
Nach Ansicht von Kaptelinin/Nardi existiert zudem grundsätzlich eine Lücke zwischen der
Intention eines Designers und der Intention eines Anwenders.143 Um diese Lücke zu
schließen, wird verstärkt nach Möglichkeiten gesucht, den Anwender in die Lage zu
versetzen, seine Business Applikationen selbst zusammenzustellen.144 Denn es kann zu
Wettbewerbsvorteilen führen, wenn die Mitarbeiter in den Fachabeilungen in die Lage
versetzt werden, auch ohne Spezialausbildung und Programmierkenntnisse Applikationen zu
erstellen, welche die individuellen Anforderungen zum aktuellen Zeitpunkt erfüllen, die
dynamisch und ad hoc am kollaborativen Arbeitsplatz entstehen. Diese Art von Applikation
wird als situationsbezogene Applikation (engl. Situational Application) bezeichnet. Eine
situationsbezogene Applikation hat typischerweise temporären Charakter. Sie ist für ein
bestimmtes Projekt oder für eine bestimmte Tätigkeit aus modularen Bausteinen zusammen-
gestellt und wird durch den Anwender für sich ändernde Anforderungen ähnlich dynamisch
weiterentwickelt, wie sich die Tätigkeit selbst ändert.
Da modulare Bausteine zu neuen Applikationen „vermischt“ oder „zusammengestellt“
werden, wird ein Teil dieser Applikationen auch als Mashup oder Composite Application
bezeichnet.145 Mashups können auch kollaborativ entwickelt werden. Dabei bringen verschie-
dene Anwender eigene Module in die Weiterentwicklung der Applikation ein. Diese Vor-
gehensweise wird als partizipatives Design von Applikationen bezeichnet. Partizipatives
Design kann auch bei der Modellierung von Geschäftsprozessen zum Einsatz kommen. So
wird der Prozess durch die Praxis weiterentwickelt und optimiert. Huth beschreibt etwa Ad-
hoc-Prozesse die nicht ex-ante vor der Ausführung vollständig modelliert werden, sondern die
jeweils lediglich einige Prozessschritte vorausmodelliert werden, jedoch üblicherweise nicht
von der ersten Aufgabe bis zum Abschluss des Prozesses.146 Jedem Bearbeiter steht es dabei
frei, die nach ihm folgenden, bereits modellierten Prozessschritte zu modifizieren, Neue
hinzuzufügen oder das Ende der Bearbeitung festzustellen.
Das Ergebnis des partizipativen Designs hilft nicht nur den Entwicklern der Applikationen
oder Prozesse, ihre Arbeit effizient durchzuführen, sondern trägt auch dazu bei, das orga-
nisationale Prozesswissen zu explizieren. Das Wissen um evolutionär entwickelte Ad-hoc-
Prozesse kann für Vorlagen genutzt werden und führt so zu einer erneuten Nutzung dieses
Wissens. Werden Muster erkannt, können die Ad-hoc-Vorlagen auch zu vordefinierten
143 Vgl. [Kaptelinin/Nardi 2006], S. 12.
144 „Enduser Programming“, vgl. etwa [Lieberman/Paternò/Wulf 2006].
145 Eine Abgrenzung dieser Begriffe ist im Kontext dieser Arbeit nicht relevant. Sie werden daher im Folgenden
Synonym verwendet. Für weitere Ausführungen siehe etwa [Thompson et al. 2009], S. 53.
146 Vgl. [Huth 2004].
62
Prozessen innerhalb eines klassischen WfMS weiterentwickelt werden147. So kann partizipa-
tives Design die Wissensmanagement Prozesse des Unternehmens unterstützen.
3.1.3.3 Partizipation durch Social Software
Der große Erfolg von Social Software (vgl. Abschnitt 2.3.2.4) hat dazu geführt, dass auch
immer mehr Unternehmen Social Software nutzen wollen um Wettbewerbsvorteile zu gene-
rieren oder ihr Informationsmanagement zu optimieren. Da es jedoch nicht im Interesse des
Unternehmens ist, das Unternehmenswissen auf im Internet frei verfügbaren Plattformen zu
verbreiten, muss die Einführung interner Plattformen für Social Software erfolgen. Bereits
2006 nimmt Gartner viele Social Software Technologien in seinen Hype Cycle für den High
Performance Workplace148 auf und prognostiziert im Jahr 2009 die weite Verbreitung etwa
von Corporate Blogging und Social Tagging im Unternehmen für das Jahr 2011.149 Dies
zeigt, dass der Anwendung von Social Software im Unternehmen signifikante
Nutzenpotenziale zugeschrieben werden. Insbesondere im Bereich der verbesserten
Auffindbarkeit von Informationen und der Informationsqualität sind bereits heute Erfolge
durch mehr Partizipation der Mitarbeiter bei der Erstellung von Dokumenten beobachtbar.
Die Art der durch Social Software generierten und gepflegten Inhalte ist kein Technik-,
sondern ein Kulturphänomen, das sich noch vor wenigen Jahren nicht abzeichnete. Die
Bereitschaft zur Deskription von Inhalten ist bemerkenswert, da gerade das wichtige Merkmal
der Beschreibung von unstrukturierten Inhalten durch Meta-Daten in WMS in Unternehmen
bisher wenig Akzeptanz bei den Anwendern fand. Auch die Bereitschaft, Wissen durch
Bereitstellung von Inhalten zu teilen und Informationen über sich selbst preiszugeben zeigen
die gesellschaftlichen Dimensionen von Social Software. Bei der Nutzung von Social Soft-
ware positioniert sich der Wissensträger bewusst oder unbewusst durch Präsenz im Diskurs,
dem individuellen Branding der eigenen Person durch Publikation der eigenen Meinung, und
der Präsentation der eigenen Kompetenz und Kreativität gegenüber einer mehr oder weniger
unbekannten Gemeinschaft als wichtig für den Erfolg des Unternehmens. In der anonymen
Masse internationaler Großunternehmen ist dies zudem eine der wenigen Möglichkeiten des
Individuums, über das eigene Team hinaus wahrgenommen zu werden und Reputation aufzu-
bauen.
Von der Nutzung von öffentlichen Social Software Diensten für Zwecke der Unternehmens-
kollaboration muss aus sicherheitsrelevanten Gründen grundsätzlich abgeraten werden. Es ist
147 Vgl. [Huth 2003], S. 86 ff.
148 Vgl. [Knox et al. 2006].
149 Vgl. [Mann et al. 2009] S. 6. Ein aktualisierter Hype Cycle liegt noch nicht vor.
63
wichtig, dass Zugriffsrechte auf die Inhalte einer solchen Plattform durch die Unternehmens-
IT festgelegt werden können. Zudem bilden die öffentlichen Dienste keine integrierte Umge-
bung mehrerer Social Software Technologien. Die Integration bietet Vorteile, etwa dass sich
Inhalte aus Blogs, Wikis, Bookmarks und anderen Systemen mit einer einheitlichen Such-
maschine durchsuchen lassen. Auch der Effekt, dass die Reputation von Experten sich durch
eigene Beiträge innerhalb mehrerer Social Software Dienste implizit herausbildet wird durch
eine integrierte Plattform verstärkt, da nicht nur ein einzelner Beitragstyp zur Reputations-
bildung beiträgt, sondern mehrere Quellen ein Gesamtbild fachlicher Beiträge einer Person
ermöglichen.
Dieses umfassende Bild von im Unternehmen verfügbaren Wissensträgern ist eine wichtige
Ressource für die Mitarbeiter, und insbesondere selbst organisierende Teams, die so auf
Personen zugreifen können, von deren Existenz oder Kompetenzportfolio sie in traditionellen
Organisationen ohne Social Software keine Kenntnis hätten. Denn dynamische Arbeits-
kontexte führen auch dazu, dass heute eine durch die Personalabteilung verwaltete Liste von
Kompetenzen ebenso wie starre Prozesse ungeeignet ist, den Anforderungen des Markts
gerecht zu werden. Auch wird die individuelle Problemlösungskompetenz unterstützt, da
Mitarbeiter umgehend Experten für eine bestimmte Themenstellung identifizieren und direkt
mit ihnen kommunizieren können. Stehen mehrere Ansprechpartner zur Verfügung kann die
Präsenzinformation integrierter Chat Systeme dazu beitragen, zeitnah eine Antwort zu
bekommen, da sofort der verfügbare Ansprechpartner ersichtlich ist, und nicht auf die
Beantwortung von E-Mails gewartet werden muss.
3.1.3.4 Ad-hoc-Aktivitäten
Globaler Wettbewerb, verkürzte Time-to-Market Phasen und die damit einhergehende Not-
wendigkeit kontinuierlicher Geschäftsprozess-Transformation erfordern eine erhöhte Flexibi-
lität von Aufbau- und Ablauforganisation der Unternehmen und verkürzen die Lebensdauer
langlebiger, vordefinierter Geschäftsprozesse. Der Anteil kollaborativer Aktivitäten zur
Produktion oder Bearbeitung von Dokumenten, die nicht im Kontext von standardisierbaren
Abläufen entstehen, oder die sich auf die Ausnahmebehandlung als Teil vordefinierter
Prozesse beziehen sowie in Bereichen, die traditionell oder aufgrund ihrer Natur informell,
ad hoc und wenig formalisiert ablaufen, nimmt zu. Diese Aktivitäten sind üblicherweise
64
ausschließlich semi-strukturiert, wenn nicht gar vollständig unstrukturiert im Sinne vor-
definierter Bearbeitungsschritte.150
Die Bearbeitung der Aktivitäten ist durch ein hohes Maß an Selbstständigkeit geprägt. Der
Wissensarbeiter muss selbst für eine adäquate Organisation und Strukturierung der Vielzahl
an Aktivitäten sorgen, um Zieltermine einzuhalten und alle Tätigkeiten mit hoher Qualität
durchzuführen. Voraussetzung für das Management und die Optimierung der Bearbeitung von
Aktivitäten ist die Explikation von Strukturinformationen der Aktivität in Form von Doku-
menten (vgl. Unterkapitel 2.2). Dies kann in Form einer einfachen Notiz bis hin zu einer
detaillierten Strukturierung durch Teilaktivitäten erfolgen.
Der optimale Grad der Explikation ist höchst individuell und hängt von der Routine bei der
Aktivitätsbearbeitung, der Ausbildung, dem sozialen Hintergrund und vielen weiteren Fakto-
ren ab (vgl. Abschnitte 2.3.2.3 und 2.4.2). Soll die Aktivitätsbearbeitung im Team erfolgen,
ist ebenso eine Explikation notwendig. Diese muss in der Regel in höherem Detailgrad als bei
individueller Bearbeitung erfolgen, da für die asynchrone Koordination von Aktivitäten
präzise beschriebene Handlungsanweisungen notwendig sind. Das liegt daran, dass Dritte
üblicherweise weniger Informationen über die Aktivität haben, als der Verfasser der expli-
zierten Information.
3.2 Kollaborative Arbeit in Teams
Bereits mehrfach wurde darauf hingewiesen, dass im Bereich von Wissensarbeit wenig
vordefinierte, strukturierte Workflows zu beobachten sind. Bea und Göbel gehen davon aus,
dass in Zukunft nahezu jede Arbeit in Projektgruppen bewältigt wird.151 Projekten wird
definitionsgemäß ein einmaliger Charakter zugeschrieben und sie werden oft nur für Sonder-
aktivitäten ins Leben gerufen. Diese Definition ist sinnvoll um Konzepte zu entwerfen die
dazu dienen, komplexe Projekte mit festgelegtem Budget und Zeitrestriktionen zu planen und
durchzuführen. In sich selbstorganisierenden Teams, die ad hoc ins Leben gerufen werden, ist
allerdings eine flexiblere Definition des Begriffs notwendig. In den folgenden Abschnitten
wird der Charakter der kollaborativen Arbeit in Teams beschrieben, die projektorientiert
arbeiten. Dabei wird nicht zwischen Projekten nach klassischer Definition und Ad-hoc-
Projekten bzw. Ad-hoc-Aktivitäten unterschieden.
Dies ist nicht notwendig, da Projektmanagement im klassischen Sinne nicht Betrachtungs-
gegenstand dieser Arbeit ist. In klassischen Projekten treten jedoch eine Fülle von individu-
150 „Much of the work performed by this group is is only semi-structured, if structured at all.“ [Ellis 1983],
S. 11 f.
151 Vgl. [Bea/Göbel 2006], S. 428-430.
65
ellen Aktivitäten auf. Ebenso gibt es Aktivitäten, die als Ad-hoc-Projekte in Teamarbeit
durchgeführt werden, Ad-hoc-Prozesse oder kleinere Teilprojekte, deren Ausführung einem
Team oder Teilprojektleiter überlassen sind, und die keine Vorgaben bzgl. Strukturierung,
Zeit- oder Budgetplanung seitens des Gesamtprojektmanagements aufweisen. Diese Aktivi-
täten sollen explizit für den Kontext dieser Arbeit eingeschlossen werden.
3.2.1 Virtualität und Verteiltheit
Durch die sich aktivitätsspezifisch ändernden Anforderungen sind zunehmend virtuelle
Teamstrukturen im Bereich der Wissensarbeit vorherrschend. Ein virtuelles Team ist nicht im
Sinne der Aufbauorganisation mit konstant bleibender Ressourcenausstattung festgeschrieben,
viele Teams werden aktivitätsspezifisch und selbstorganisierend zusammengestellt. Ein
Resultat ist, dass die Teamstruktur nur für die Dauer eines Projekts bzw. einer einzelnen
Teamaktivität Bestand hat. Auch können im Zeitverlauf Teammitglieder hinzukommen oder
das Team verlassen. Hinzu kommt, dass jedes Individuum Mitglied in einer Vielzahl von
Teams ist. Da in Unternehmen mit mehreren Standorten üblicherweise nicht alle für die
Durchführung der Aktivität benötigten Ressourcen zum Zeitpunkt der Aktivitätsbearbeitung
an einem Standort verfügbar sind, sind die Teams häufig geografisch verteilt. Eine Konse-
quenz daraus kann sein, dass sie sich in verschiedenen Zeitzonen befinden, und so auf
asynchrone Kommunikation angewiesen sind.
Auch die Arbeit am Heimarbeitsplatz oder mobil nimmt stark zu. An die Fähigkeiten und
Werkzeuge zur Koordination und Führung dieser Teams werden also neue Anforderungen
gegenüber klassischen Teamstrukturen gestellt. Hinds und McGrath zeigen, dass lose gekop-
pelte, verteilte Teams sich bereits mit heute zur Verfügung stehenden Mitteln durch Bildung
einer impliziten hierarchischen Teamstruktur effizienter koordinieren können als Teams, die
sich am gleichen Ort befinden.152 Schmidt und Bannon nennen eine Reihe von Heraus-
forderungen, die in verteilten Teams auftreten.153 So ist es für die Bewertung von
Informationen, die Grundlage für Entscheidungen im Teamarbeitsprozess sind, wichtig, den
Autor der Information zu kennen und darüber hinaus Persönlichkeit, Ansichten und fachliche
Kompetenz einschätzen zu können, denn nicht nur in interdisziplinären Teams werden Sach-
verhalte durch unterschiedliche Personen höchst unterschiedlich bewertet.
Eine weitere Herausforderung ist es, die Information und ihre Einordnung in verschiedene
Geschäftskontexte (vgl. Abschnitt 2.4.1) bewerten zu können. So haben beispielsweise
regulatorische Anforderungen unterschiedliche Auswirkungen auf die Bewertung eines
152 Vgl. [Hinds/McGrath 2006], S. 350.
153 Vgl. [Schmidt/Bannon 1992], S. 31 ff.
66
Dokuments in verschiedenen Ländern. Auch der zugehörige Geschäftsprozess, beispielsweise
für die Genehmigung eines Dokuments, kann in unterschiedlichen Lokationen eines Unter-
nehmens verschieden sein. Die Möglichkeit, Informationen über Kontextabhängigkeiten zu
erhalten ist also wichtig für verteilte Teams. Des Weiteren kann eine Information eine
politische Färbung enthalten. In Organisationen müssen bei der Bewertung von Informationen
Konflikte zwischen Organisationseinheiten und Individuen berücksichtigt werden. Ebenso
kann jede Information nicht nur unbeabsichtigt, sondern auch absichtlich fehlinterpretiert
werden, etwa wenn die Interpretation der Erreichung individueller Ziele dienlich erscheint.
Dies liegt auch daran, dass Ziele und Motive verschiedener an der Aktivität beteiligter Indivi-
duen regelmäßig inkongruenter Natur sind, etwa aufgrund von Opportunismus. Die letzte
Herausforderung nach Schmidt und Bannon ist die Beschränkung der Zugriffsrechte auf
Informationen. So kann und soll nicht jede Information für jeden Mitarbeiter sichtbar sein.
Beispiele für besonders sensible Daten sind Finanz- und Controlling-Daten oder personen-
bezogene Informationen.
3.2.2 Interorganisationalität
Wie in Abschnitt 3.1.2 ausgeführt, sind zunehmend interorganisationale Kooperationsformen
zwischen Unternehmen zu beobachten. Dies hat Auswirkungen auf die Zusammensetzung
von Teams. Stammen Teammitglieder aus unterschiedlichen Unternehmen werden sie in
Bezug auf das aktivitätsbezogene Informationsmanagement vor eine Reihe von zusätzlichen
Herausforderungen gestellt. Zunächst haben die einzelnen Teammitglieder keinen Zugriff auf
relevante Dokumente der Partnerunternehmen. Daher kommt es häufig vor, dass die aus Sicht
der Kooperationspartner notwendigen Dokumente den Teammitgliedern zunächst zur Verfü-
gung gestellt werden müssen. Werden bei einer Teamaktivität Dokumente benötigt, die
vertrauliche und schützenswerte Informationen enthalten, muss zunächst der einzelne Mit-
arbeiter entscheiden, ob die Verteilung der Informationen an die Teammitglieder von
Kooperationspartnern überhaupt zulässig ist. Eine weitere Herausforderung ist die sichere
Verteilung der Dokumente. Unverschlüsselte E-Mail ist zu diesem Zweck ungeeignet, da sie
im Internet durch Dritte mitgelesen werden kann. Verschlüsselung von E-Mail ist technisch
ausgereift und verfügbar, hat sich jedoch bisher nicht durchsetzen können.154
Abhilfe kann eine teamspezifische CIS-Infrastruktur zum Teilen von Informationen schaffen.
Die Einrichtung stellt jedoch sowohl die Anwender, als auch die Unternehmensinfrastruktur
vor weitere Herausforderungen. Wer darf und wer kann solche Bereiche erstellen, welche
154 Vgl. [Smith et al. 2006], S. 21.
67
Informationen dürfen sie enthalten, wem darf Zugriff gewährt werden, wer trägt die Kosten,
wenn mehrere Unternehmen auf das System zugreifen, wie wird Versionsmanagement mit
den Originalversionen der Dokumente betrieben und wer sorgt dafür, dass nach Abschluss der
Teamarbeit archiviert wird. Und wem „gehören“ die Dokumente nach Abschluss der Arbeit?
Es ist offensichtlich, dass die genannten Herausforderungen gerade bei ad hoc entstehenden
Aktivitäten in den meisten Fällen nicht im Vorfeld der Bearbeitung gelöst werden. Viele
dieser Dinge müssen durch organisationale Richtlinien geregelt werden und sollten außerdem
in der Vertragsbeziehung zwischen den kooperierenden Unternehmen geregelt sein. Dies
nimmt regelmäßig eine längere Vorlaufzeit in Anspruch. Heute übliche Infrastruktur-
komponenten werden in Abschnitt 3.3.4 diskutiert.
3.2.3 Heterogenität und Interdisziplinarität
Isolierte Abteilungen (engl. Organizational Silos) werden durch Personalverantwortliche in
einer Studie aus dem Jahr 2008 als die größte Barriere für die Zusammenarbeit in ihrer
Organisation bezeichnet (Vgl. Abbildung 3-2). Dies hat Auswirkungen auf die Wissensarbeit,
bei der es regelmäßig erforderlich ist, dass Teams interdisziplinär zusammengesetzt sind. Ziel
der Wissensarbeit ist Innovation durch Austausch und gegenseitige Inspiration durch das
Zusammenbringen unterschiedlicher Talente, Erfahrungen und Sichtweisen. Auch sind häufig
Teammitglieder aus verschiedenen Bereichen der Aufbauorganisation an der Bearbeitung von
Teamaktivitäten beteiligt, z. B. bei der Entwicklung eines neuen Produktes können Personen
aus den Bereichen Controlling, Marketing, Produktmanagement, Entwicklung und Produktion
nötig sein. Die unterschiedlichen Fähigkeiten der Teammitglieder sind auch ein entscheiden-
der Erfolgsfaktor für die Teamproduktion (vgl. Abschnitt 2.1.3). Sie sind aber auch Nähr-
boden für Konflikte und Missverständnisse.155
Neben der fachlichen Heterogenität sind die Teams auch häufig sozio-kulturell heterogen
zusammengesetzt. Dies ist ein Resultat der weltweiten Verteiltheit und Virtualität von Teams
(vgl. Abschnitt 3.2.1). Die Heterogenität erfordert viel Kommunikation und Abstimmung, um
mögliche Missverständnisse zu minimieren, unterschiedliche Sichtweisen zu erläutern, oder
Verständnisschwierigkeiten zu überbrücken. Dies gilt insbesondere, wenn die Teams räumlich
verteilt arbeiten, da die direkte, persönliche Kommunikation, zumindest in asynchronen
Szenarien, weitgehend entfällt.
155 Vgl. etwa [Engeström 2001]: „The multi-voicedness […] is a source of trouble and a source of innovation,
demanding actions of translation and negotiation.“ [Engeström 2001], S. 136.
68
Abbildung 3-2: Barrieren der Zusammenarbeit156
3.2.4 Individualität und Vielstimmigkeit
Die vorausgegangenen Abschnitte beschreiben die Zusammensetzung von Teams am kollabo-
rativen Arbeitsplatz. Fachliche und sozio-kulturelle Heterogenität der Mitglieder von virtu-
ellen Teams legen nahe, dass das zu transformierende Objekt einer Aktivität unterschied-
lichen, individuellen Betrachtungsweisen unterliegt. Hinzu kommt die Erfahrung, die ein
Individuum im Umgang mit dem Objekt hat. So kann von zwei Individuen, die von Außen
betrachtet das Gleiche tun, Eines eine Handlung ausführen, und Eines eine Operation (vgl.
Abschnitt 2.4.2). Beide haben also bei der Bearbeitung einer Aktivität eine unterschiedliche
mentale Belastung, aber auch im Vorfeld der Bearbeitung einen unterschiedlichen Planungs-
bedarf. Bei der Planung findet der mentale Prozess des Zerlegens der Aktivität in Handlungen
statt, es wird eine hierarchische Struktur von durchzuführenden Handlungen und ihren Inter-
dependenzen gebildet. Diese Struktur wird als Aktivitätsstruktur bezeichnet.
Zudem haben Individuen unterschiedliche Ziele und Motive innerhalb eines Teams, die mit
den Zielen und Motiven anderer Teammitglieder aus taktischen oder strategischen Gründen
divergieren können. Auch die Arbeitsteilung kann dazu beitragen, dass individuell unter-
schiedliche Ziele verfolgt werden, da jedes Individuum bestrebt ist, seine Aktivitäten mög-
lichst effizient durchzuführen, was im Konflikt zu den Bestrebungen anderer Teammitglieder
stehen kann. Fachliche und sozio-kulturelle Heterogenität, individuell unterschiedlicher
Planungsbedarf bei der Durchführung von Aktivitäten und potenziell divergierende Motive
führen dazu, dass die Struktur der Aktivität durch jedes Individuum unterschiedlich beschrie-
156 Vgl. [IBM Corporation 2008], S. 13.
69
ben wird. Dieses Merkmal wird als Individualität der Aktivitätsstruktur bezeichnet. Die
Vereinigung individueller, explizierter Aktivitätsstrukturen wird als Vielstimmigkeit („multi-
voicedness“) von Aktivitätssystemen bezeichnet.157
Wenn die Teamarbeit koordiniert werden soll, muss nun eine Explikation der Aktivitäts-
struktur und Zuweisung von Individuen zu Handlungen erfolgen. Aufgrund der Vielstimmig-
keit würde jedes Teammitglied die Explikation unterschiedlich durchführen, da es seine
Arbeit individuell organisiert, strukturiert und unterschiedliche Bedürfnisse in Bezug auf den
Detailreichtum der Explikation hat. Für die Teamarbeit muss ein intersubjektiver Konsens für
die Struktur der Aktivität gefunden werden. Dieser Prozess kann aufwändig sein und birgt
Konfliktpotenzial. Eine andere Vorgehensweise ist es, die Aktivitätsstruktur initial durch den
für die Aktivität Verantwortlichen vorzugeben, woraufhin die Struktur sich im Lebenszyklus
der Aktivität evolutionär weiterentwickeln kann. Alle Teammitglieder, die im zeitlichen
Verlauf der Aktivitätsbearbeitung hinzukommen, müssen bei der Arbeit mit der Aktivitäts-
struktur bei dieser Vorgehensweise Zugeständnisse gegenüber der ihre individuellen Bedürf-
nisse repräsentierenden Aktivitätsstruktur machen. Für die individuelle Arbeitsorganisation ist
das offensichtlich ein suboptimaler Zustand, der zu Produktivitätsverlusten führen kann.
3.2.5 Unterbrechungen und Kontextwechsel
Am kollaborativen Arbeitsplatz sind Unterbrechungen nicht die Ausnahme, sondern die
Regel. So zeigen Mark/González/Harris, dass mehr als 50% aller Aktivitäten unterbrochen
werden.158 Beispiele für Unterbrechungen sind Rückfragen durch Kollegen mithilfe von
Kommunikationswerkzeugen wie Chat, Telefon oder E-Mail, sowie durch direkte Ansprache.
Hinzu kommen Unterbrechungen von Applikationen etwa durch Popups oder
Benachrichtigungen, die beispielsweise auf neue Informationen eines Feeds oder eine neue
E-Mail hinweisen.
Unterbrechungen können positive Effekte auf die Arbeit haben. So kann die Unterbrechung
zu einer Pause oder Anregung führen, die etwa die Kreativität steigert und zu neuen Ideen
führt. Häufig wirken sich die Unterbrechungen jedoch negativ auf die Produktivität aus. Dies
ist üblicherweise dann der Fall, wenn ein Kontextwechsel zu einer anderen Aktivität die Folge
der Unterbrechung ist. Nicht alle Aktivitäten lassen sich verlustfrei unterbrechen, bzw. in
beliebig kleine Arbeitsschritte unterteilen. Ist der unterbrechungsfreie Zeitraum bei
komplexen Aktivitäten zu gering kann es sein, dass nur wenig bis gar keine Fortschritte bei
157 Vgl. [Engeström 2001], S. 136.
158 Vgl. [Mark/González/Harris 2005]. Aktivitäten werden hier als „Working Spheres“ bezeichnet.
70
der Durchführung der Aktivität erzielt werden.159 Hinzu kommt, dass die Rückkehr zu der
ursprünglichen Aktivitätsbearbeitung häufig mit einer Rüstzeit verbunden ist. Dies kann sich
sowohl auf das Auffinden benötigter Dokumente beziehen, als auch auf die Zeit, sich erneut
mental mit der aktuellen Aktivität zu befassen.
Zudem können Unterbrechungen verschachtelt auftreten, wenn z. B. die durch eine Unter-
brechung neu aufgenommene Aktivität aufgrund einer weiteren Unterbrechung nicht fort-
gesetzt werden kann. Dies kann zu Stress führen weil es schwierig ist, den Überblick über die
aktuellen Aktivitäten zu behalten. Mark/González/Harris berichten, dass es sogar vorkommt,
dass die ursprüngliche Aktivität vergessen wird. Bis dem Bearbeiter wieder einfällt, worin
diese Aktivität bestand, wird dann an der die Unterbrechung hervorrufenden Aktivität
gearbeitet.
Unterbrechungen kommen dabei nicht nur von Außen. Wissensarbeiter unterbrechen sich
ebenso selbst, z. B. wenn eine Pause bei der aktuellen Aktivitätsbearbeitung benötigt wird,
oder wenn über andere, nicht mit der aktuellen Aktivität verbundene Themen nachgedacht
wird, die den Anwender beschäftigen. Zudem ist durch die allgegenwärtigen Informationen
durch Web 2.0 und E-Mail ein Verhalten entstanden, das Stone als „Continuous Partial
Attention“ bezeichnet.160 Die Anwender, die dieses Verhalten auszeichnet, versuchen, mög-
lichst viele Informationen gleichzeitig wahrzunehmen, um ggf. reagieren zu können. Auf-
grund der Fülle von Informationen findet keine Fokussierung auf eine Aktivität statt, sondern
eine nicht priorisierte, eher periphere Wahrnehmung aller Informationen. Als Beispiel führt
Stone das Verhalten an, an Besprechungen teilzunehmen und die Zeit dann mit der Beant-
wortung von E-Mails zu verbringen, anstatt sich etwa an der Diskussion in der Besprechung
zu beteiligen.
Als Folge der Informationsüberflutung haben sich in den letzten Jahren zunehmend Strategien
entwickelt, die Continuous Partial Attention bzw. dessen Folgen entgegen wirken. So stehen
Werkzeuge zur Verfügung, die es den Anwendern ermöglichen, nicht alle Informationen zu
rezipieren, sondern nach Interessensgebieten zu filtern, und damit die Menge an Informatio-
nen zu reduzieren und auf relevante Bereiche zu beschränken. Soweit dies gelingt ist eine
stärkere Fokussierung auf die eigentlichen Aktivitäten möglich. Ein Werkzeug kann etwa ein
Feedreader sein, der nicht nur Feeds abonnieren kann, sondern diese auch thematisch filtert,
oder lediglich bestimmte Kategorien abonnieren kann.
159 Vgl. [Czerwinski/Horvitz/Wilhite 2004], S. 181 und [Mark/González/Harris 2005], S. 321.
160 Vgl. [Stone 2006].
71
3.3 IT-Infrastrukturen für Kollaborations-Informationssysteme
Die Herausforderungen, denen sich Unternehmen im Wettbewerb heute stellen müssen,
erfordern den Einsatz von Technologien, die Kollaboration effizienter gestalten. In den
folgenden Abschnitten werden typische Merkmale aktueller CIS Landschaften von Unter-
nehmen aufgezeigt.
3.3.1 Komplexität von Systemlandschaften
In vielen Unternehmen hat sich die IT-Landschaft über Dekaden hinweg evolutionär ent-
wickelt. Dies kann dazu führen, dass eine Vielzahl spezialisierter Systeme zum Einsatz
kommt, die nicht oder nur eingeschränkt über standardisierte Schnittstellen integrierbar sind.
Werden mehrere dieser isolierten Systeme von den gleichen Anwendern zur Bewältigung
ihrer Tätigkeiten im Unternehmen benötigt, wird die Infrastruktur als heterogen bezeichnet.
Eine Infrastruktur, die etwa aus vier unterschiedlichen Systemen besteht, die den Zugriff auf
Dokumente jedoch über eine Standard-basierte Schnittstelle ermöglicht, so dass die Anwender
über die gleiche Applikation auf Dokumente aus allen vier Quellen zugreifen können, ist also
nicht als heterogen zu bezeichnen.
Heterogene Systeme können einen negativen Einfluss auf die Produktivität des Wissens-
arbeiters haben. Um dies zu vermeiden, kann eine Integration der Systeme vorgenommen
werden. Wird dies als Punkt-zu-Punkt-Integration realisiert, ist die Integration kostenintensiv
und führt zu sehr komplexen Systemlandschaften. Diese lassen sich nur schwer warten, weil
sie eine Vielzahl von Abhängigkeiten aufweisen, die dazu führen, dass es bei Änderungen an
einzelnen Bausteinen, z. B. durch den Wechsel eines Software Zulieferers, zu komplexem
Änderungsbedarf an einer Vielzahl von Systemen kommen kann. So kann es sein, dass die
Einführung innovativer neuer Systeme verzögert oder aufgegeben wird, weil Kosten und
Risiko eines Migrationsprojektes zu hoch sind.
Wird hingegen auf eine Integration der Systeme verzichtet, können Geschäftsprozesse, an
denen etwa mehrere Systeme beteiligt sind, nicht adäquat unterstützt werden. Zudem ent-
stehen Medienbrüche, die von den Anwendern manuell überbrückt werden müssen. Medien-
brüche führen beispielsweise zu Mehrfacheingabe von Daten und sind inhärent fehleranfällig.
Dies liegt nicht nur an der manuellen Eingabe von Daten, sondern auch an der Problematik
von systemübergreifendem Versionsmanagement, fehlenden Statusinformationen auf
Prozessebene und mangelhafter Planbarkeit von am Prozess beteiligten Ressourcen aufgrund
fehlender Protokolldaten auf Gesamtprozessebene. Dies kann zu Wettbewerbsnachteilen bei
der Kostenstruktur, der Durchlaufzeit von Prozessen oder der Prozessqualität führen.
72
Abbildung 3-3: Beispiel für eine ECM-Architektur161
Abbildung 3-3 zeigt beispielhaft Systeme einer CIS Landschaft für das unternehmensweite
Management von Dokumenten. Ein solches Konzept wird als Enterprise Content Management
(ECM) bezeichnet. Aufgrund der Vielzahl an Systemen ist eine Punkt-zu-Punkt-Integration
nicht sinnvoll. Um diese Problematik zu adressieren haben Standardisierungsbestrebungen
dazu geführt, dass immer mehr Systeme etwa Web Services162 unterstützen. Systeme mit
diesen Schnittstellen können im Rahmen einer Service-orientierten Architektur (SOA)
Standards-basiert integriert werden.
Ein Enterprise Service Bus (ESB) übernimmt die Koordination der verschiedenen, von den
einzelnen Systemkomponenten angebotenen Dienste und vermittelt mit Systemkomponenten,
die diesen Dienst nachfragen. Eine SOA wird üblicherweise als Grundlage zur Abbildung von
systemübergreifenden Geschäftsprozessen verwendet. Ein ähnliches Konzept, das die Ent-
kopplung von Systemen noch weiter führt, das jedoch noch wenig standardisiert ist, ist die
Event-Driven Architecture (EDA). Hier hat die Quelle eines Ereignisses, z. B. ein System, das
einen Systemabsturz festgestellt hat, keine Kenntnis von verarbeitenden Systemen für das
161 Vgl. [Nastansky/Erdmann 2006], S. 28.
162 Die wichtigsten Standards, auf denen Web Services basieren sind SOAP und WSDL und REST. Vgl. etwa
[Weerawarana et al. 2006].
73
Ereignis.163 Die EDA hat ihre Stärken im Bereich der Verarbeitung von Echtzeit-Ereignissen
im Unternehmen sowie der Verarbeitung komplexer Ereignisse und deren Abhängigkeiten.
Ein komplexes Ereignis ist die Bündelung und Abstraktion mehrerer einfacher Ereignisse, die
etwa gleichzeitig oder in bestimmter zeitlicher Abfolge auftreten. Wenn beispielsweise die
Benutzung einer Kreditkarte ein einfaches Ereignis ist, dann kann die Nutzung einer Kredit-
karte im Abstand von einer Stunde in drei verschiedenen Ländern als komplexes Ereignis
definiert werden. Dieses komplexe Ereignis kann beim Kreditkartenunternehmen eine War-
nung auslösen, weil etwa der Verdacht einer missbräuchlichen Nutzung besteht. Durch die
Registrierung und Verarbeitung einer Vielzahl von Ereignissen im und außerhalb des Unter-
nehmens können Systeme intelligent und flexibel reagieren. Für weitere Ausführungen zu
SOA, ESB und EDA vgl. etwa [Dostal et al. 2005], [Manes 2006], [Weerawarana et al. 2006]
oder [Bruns/Dunkel 2010].
3.3.2 Isolierte Repositories
Für die Bearbeitung einer Aktivität ist es für den Wissensarbeiter üblicherweise notwendig
auf Dokumente zuzugreifen, die über verschiedene Repositories (vgl. Abschnitt 2.2.2.2)
verteilt abgelegt sind. Oft sind diese Repositories nicht integriert, so dass z. B. keine Suche
über alle Repositories möglich ist. Diese werden als isolierte Repositories bezeichnet. Sie
können auch durch dezentrale Systeme in Abteilungen entstehen, die nicht durch ein unter-
nehmensweites System integriert sind.164 Viele Unternehmen verfügen also nicht über ein
fertig implementiertes und genutztes ECM-Konzept, wie es beispielhaft in Abbildung 3-3
illustriert ist, sondern über eine Vielzahl isolierter Repositories.
Klassische Integrationsszenarien auf Datenebene wie z. B. dem EAI-Ansatz sind jedoch nicht
geeignet, diese Repositories zu integrieren, denn sie sind für die Integration strukturierter
Daten (vgl. Abbildung 2-2) vorgesehen, etwa um im Backend Daten auszutauschen und in
einer anderen Applikation weiter zu verarbeiten. Im Kontext von CIS, wo im Gegensatz dazu
eine Vielzahl an unstrukturierten Daten verarbeitet wird, ist eine Integration auf Datenebene
oft nicht sinnvoll, weil zur Bearbeitung des Inhalts spezialisierte CIS zum Einsatz kommen.
Ein Dokument kann also in einer anderen Applikation unter Umständen nicht einmal darge-
stellt werden.
Ähnliches gilt für die Navigationsmechanismen, die dem Auffinden von Dokumenten in CIS
dienen. Abhängig vom Geschäftskontext, in dem die Bearbeitung erfolgt, existiert eine
Vielzahl unterschiedlicher Navigations- und Suchmechanismen, die nicht durch eine zentrale
163 Vgl. [Bruns/Dunkel 2010], S. 35f.
164 Vgl. [O'Hanlon 2005].
74
Applikation einheitlich übernommen werden können (vgl. Abschnitt 2.2.2.5). Um den
Anwendern trotzdem einen zentralen Zugriffspunkt auf die von ihnen benötigten Dokumente
und Repositories und zugehörige Applikationen zu ermöglichen, können Portale (vgl. Ab-
schnitt 2.3.3.1) und Mashups genutzt werden.
3.3.3 Portale und Mashups
Portale ermöglichen eine Integration durch die Zusammenfassung des UI mehrerer Applika-
tionen (vgl. Abschnitt 2.3.3.1). Dies wird auch als "Integration on the glass"165 bezeichnet.
Neben einer Reihe von Standarddiensten, wie Abbildung 3-4 beispielhaft illustriert, können
weitere Applikationen durch die Entwicklung spezifischer Portlets integriert werden. Durch
eine Composite Application Architektur ist es auch möglich, Portlets kontextabhängig anzu-
bieten.166 Die Kombination von Portlets auf dem Bildschirm hängt dann nicht nur von der
Rolle des Anwenders ab, sondern auch vom Arbeitskontext, in dem er sich aktuell befindet.
Kontextabhängige Portlets können über eine Möglichkeit verfügen, mit anderen Portlets
strukturierte Daten auszutauschen, so dass Aktionen in einem Portlet zu Ergebnissen in
anderen Portlets führen können. Dieser Mechanismus wird als Inter-Portlet Communication
(IPC) bezeichnet.167 Ein Anwendungsbeispiel für IPC ist, dass dem Anwender, der in einem
Portlet seine E-Mails bearbeitet, entsprechend der aktuell bearbeiteten E-Mail in einem
anderen Portlet zugehörige Unternehmensinformationen des Absenders aus einem Customer
Relationship Management (CRM) System angezeigt werden. Der Austausch von Daten
zwischen Portlets wird über eine ESB ähnliche Infrastruktur realisiert, welche die Verteilung
von Daten zwischen Anbieter Portlets und konsumierenden Portlets vermittelt.
Portal-Umgebungen erlauben einen gewissen Grad an Anwender-spezifischen Anpassungen.
Üblicherweise sind die individuellen Kombinationsmöglichkeiten von Applikationen in
Portal-Umgebungen jedoch durch die Unternehmens-IT eingeschränkt. Aber auch Einschrän-
kungen technischer Art sind vorhanden. Die Entwicklung von Portlets ist aufwändig und wird
in der Regel nur für unternehmenskritische Applikationen durchgeführt.
Bei Mashup-Umgebungen handelt es sich um ein Architekturkonzept, das mit Blick auf mehr
Flexibilität und Personalisierung hin entworfen wurde. Die einzelnen UI Elemente der Appli-
kationen werden in Mashup-Umgebungen als Widget, Gadget oder Plugin bezeichnet. Diese
modularen Applikationselemente verfügen üblicherweise über ein deutlich geringeres
Funktionsspektrum als Portlets, etwa eine einzelne Funktionalität. Widgets lassen sich daher
165 Vgl. [Paulheim 2011], S. 9.
166 Vgl. etwa [Roth 2006].
167 Vgl. etwa [Roth 2006], S. 11ff.
75
üblicherweise deutlich interaktiver mit anderen Widgets kombinieren, als dies bei Portlets
üblich ist. Sie sind zudem einfacher zu entwickeln und bereitzustellen.
Abbildung 3-4: Portal Architektur168
Ziel von Mashup-Technologien ist es fortgeschrittene Anwender in die Lage zu versetzen,
ihre Applikationen selbst aus einer Vielzahl von Komponenten zusammenstellen, so dass die
resultierende Applikation hochspezifisch für ihre Anforderungen optimiert ist (vgl. Abschnitt
3.1.3). Ähnlich wie Portal-Server bieten Mashup-Server eine Reihe von Infrastruktur-
Diensten an. So stehen etwa Standard-Widgets mit der Funktionalität zur Verfügung,
automatisiert Inhalte aus einer Vielzahl von Repositories aufbereiten und darstellen zu
können. So kann der Anwender im Kontext einer Mashup-Applikation Repositories
integrieren, für die durch die IT keine spezifischen Widgets zur Verfügung gestellt werden.169
3.3.4 Interorganisationale CIS
Viele Teams setzen sich aus Mitarbeitern verschiedener Unternehmen zusammen. Wie in
Abschnitt 3.2.2 aufgezeigt ist E-Mail in vielen Fällen ungeeignet, um die benötigten Informa-
tionen zwischen Unternehmen auszutauschen. Es werden daher CIS als interorganisationale
Infrastruktur benötigt, die einen verschlüsselten Zugang zu den Dokumenten bereitstellen,
granulare Zugriffsrechte ermöglichen, und dennoch für alle Teammitglieder nutzbar sind. Der
168 Vgl. [Bullinger et al. 2002], S. 20.
169 Vgl. etwa [Simmen et al. 2008].
76
Betrieb interorganisationaler CIS stellt daher eine Reihe von Herausforderungen an alle
beteiligten Unternehmen. So sind Fragen zu klären wie etwa: Wer darf Zugriff bekommen,
wer darf Zugriffsrechte gewähren, welche Informationen dürfen zugänglich gemacht werden,
wer betreibt die Systeme, welche Lizenzen werden benötigt und wie werden die Kosten
verteilt? Die Diskussion von Antworten auf diese Fragen soll im Kontext dieser Arbeit nicht
erfolgen. Die Anforderungen dieses Szenarios müssen aber bei der Diskussion der Arbeit in
interorganisationalen Teams in der Anforderungsanalyse (Unterkapitel 4.4) berücksichtigt
werden.
Da Teams sich wie beschrieben häufig selbst organisieren haben sich für interorganisationale
CIS Selbstbedienungssysteme durchgesetzt. Bei diesen kann der Anwender bei Bedarf ohne
Zeitverzögerung einen Teamraum erstellen. Ein Teamraum ist eine Applikation, die
Kollaborationsfunktionalitäten für das Team bereitstellt. Dazu gehört auch ein für das Team
reservierter Bereich in einem Repository, um dort Dokumente abzulegen. Der Ersteller des
Teamraums kann nach der Erstellung weiteren Teammitgliedern Zugriff darauf gewähren. Für
Teammitglieder, die nicht über eine Benutzeridentität des Unternehmens, dem der Ersteller
des Teamraums angehört, verfügen, kann eine Benutzeridentität eingerichtet werden die nur
für den Teamraum Gültigkeit hat. Damit für alle Teammitglieder der Zugriff funktioniert
verfügen die Systeme üblicherweise über ein Browser UI. So ist sichergestellt, dass keine
speziellen technischen Voraussetzungen für die Teilnahme an der Zusammenarbeit erfüllt
werden müssen. Um die Teammitglieder über aktuelle Informationen im Teamraum auf dem
Laufenden zu halten verfügt das System über die Möglichkeit, entweder per E-Mail oder
Newsfeed über neue oder geänderte Dokumente zu informieren.
3.4 Werkzeugunterstützung des Wissensarbeiters
Das Konzept des Büros im Sinne eines physischen Raums ist unter dem Aspekt virtueller
Teams und mobiler Arbeitsplätze kein geeignetes Modell für die Betrachtung kollaborativen
Arbeitens (vgl. auch Abschnitt 2.3.1). Vielmehr steht der kollaborative Arbeitsplatz, mit
neuen Herausforderungen, im Vordergrund. Für einige der Herausforderungen steht keine
adäquate Unterstützung durch CIS zur Verfügung, was sich am antizipierten Verbesserungs-
potenzial der Produktivität des kollaborativen Arbeitsplatzes zeigt. So sehen 58% der
Personalverantwortlichen in einer IBM Studie als größte Herausforderung für ihr Geschäft die
Verbesserung der operativen Leistungsfähigkeit durch Ergebnisverbesserung mit gleichen
oder weniger Ressourcen (vgl. Abbildung 3-5). Diese Herausforderungen sind Gegenstand
der folgenden Betrachtung.
77
Abbildung 3-5: Größte Herausforderungen für das eigene Geschäft170
3.4.1 Werkzeugzentrierung
Aktuelle CIS sind darauf ausgerichtet, die individuelle Aufgabenbearbeitung am kollaborati-
ven Arbeitsplatz zu unterstützen, beispielsweise die Bearbeitung von E-Mail oder das Schrei-
ben von zum Ausdruck bestimmten Texten mithilfe einer Textverarbeitung. Sie sind also
nicht dafür optimiert, relevante Dokumente für den aktuellen Arbeitskontext bereitzu-
stellen.171 Die verfügbaren Werkzeuge am kollaborativen Arbeitsplatz sind nicht als ganzheit-
liche Lösung entworfen worden, sondern haben sich isoliert und evolutionär entwickelt.
Hinzu kommt die sich ebenfalls evolutionär entwickelnde IT-Infrastruktur von Unternehmen.
So entstehen Repository Landschaften mit entsprechenden Applikationen zur Bearbeitung und
Navigation, die entsprechend mit Veränderungen in der Aufbau- und Ablauforganisation
gewachsen sind. Während die PIM-Umgebung üblicherweise unternehmensweit einheitlich ist
kommt es häufig vor, dass innerhalb einer Fachabteilung eine eigene isolierte CIS-Infra-
struktur existiert.
Hinzu kommen Applikationen für Arbeitsgruppen und dynamische Teams wie Diskussions-
bereiche oder Teamräume. Diese sind Projekt-orientiert, auf die Arbeitsgruppe beschränkt
und können ad hoc erstellt werden. Darüber hinaus gibt es Applikationen, die spezialisierte
Funktionalitäten für bestimmte Rollen im Unternehmen bereitstellen. Diese Ausrichtung der
Arbeitsorganisation an Werkzeugen in Gestalt einzelner Applikationen ist auch ein Resultat
der Entwicklung der CSCW Forschung (vgl. Abschnitt 2.3.1). Zunächst wurden Grundlagen-
konzepte betrachtet. Daher wurde die Entwicklung von Software jeweils mit einem speziellen
Fokus für eine Detailthematik vorangetrieben. So erfolgte eine Trennung von Werkzeugen für
Kommunikation, Kollaboration und Koordination. Ähnliches gilt für die Zeitdimension
kollaborativen Arbeitens. So entstanden spezielle Werkzeuge für synchrone und asynchrone
170 Vgl. [IBM Corporation 2008], S. 40.
171 Vgl. [González/Mark 2004], S. 119.
78
Kollaboration. Es entstanden Werkzeuge aus Teildisziplinen wie Wissensmanagement,
Projektmanagement usw. Abbildung 3-6 zeigt beispielhaft eine solche CIS-Infrastruktur mit
nicht integrierten Applikationen.
Abbildung 3-6: Beispiel für eine CIS-Infrastruktur
Aufgrund dieser Eigenschaften wird das Paradigma der Softwareunterstützung am kollabora-
tiven Arbeitsplatz als Werkzeug-zentrische Ausrichtung bezeichnet. Die mentale Arbeits-
organisation der Anwender ist daher ebenfalls Werkzeug-zentrisch. Sie orientiert sich nicht an
den Aktivitäten, die erledigt werden müssen, sondern konzentriert sich darauf, welche Werk-
zeuge als nächstes zu nutzen sind, um eine Aufgabe zu erledigen. Portaltechnologien (vgl.
Abschnitt 2.3.3.1) und kontextuelle Kollaboration (vgl. Abschnitt 2.3.3.2) sind erste Ansätze,
die Werkzeugzentrierung am kollaborativen Arbeitsplatz zu überwinden und durch
geeignetere, ganzheitliche Konzepte zu ersetzen, die sich an der kognitiven Funktionsweise
menschlicher Aktivitäten orientieren.
3.4.2 Spektrum der E-Mail-Nutzung
E-Mail-Systeme sind sowohl im privaten Umfeld, als auch im Unternehmenskontext
essenzielle Komponenten der IT-Infrastruktur und haben das Kommunikationsverhalten der
Menschen revolutioniert. Die breite Akzeptanz und allgegenwärtige Verfügbarkeit von
E-Mail hat dazu geführt, dass Laufzeiten von Nachrichten dramatisch verkürzt worden sind.
Insbesondere die internationale Kommunikation wurde beschleunigt und hat im Vergleich zur
Papierwelt zunächst Produktivitätssteigerungen erfahren. Mitarbeiter sind durch mobile
Geräte stets in der Lage, E-Mails zu empfangen und zu senden. Dementsprechend wird
vielfach erwartet, dass eine E-Mail kurzfristig, spätestens aber noch am gleichen Tag beant-
79
wortet wird. Durch die einfache Handhabung und die stetige Präsenz beim Mitarbeiter ist
auch das Versenden von E-Mails sehr einfach und hat die Kommunikationsintensität erhöht.
Funktional sind E-Mail-Applikationen zum Zweck der asynchronen Kommunikation konzi-
piert und beinhalten nur rudimentäre Funktionalitäten zum Management der E-Mails. Eine
Fülle von Studien lässt den Schluss zu, dass die E-Mail-Umgebung auch für andere
Kollaborationsformen zum Einsatz kommt, wie die Delegation von Aktivitäten
(Koordination), Diskussionen (Kooperation) oder Dokumentenmanagement. Bereits 1996
beschrieben Whittaker und Sidner die Funktionsüberladung von E-Mail als „Email
Overload“.172 Auch zehn Jahre später hatte sich diese Situation nicht signifikant geändert.173
E-Mail-Umgebungen sind für diese Aktivitäten jedoch funktional nicht gut geeignet. Hinzu
kommt, dass ggf. unternehmensrelevante Informationen für andere Mitarbeiter nicht
zugänglich sind.
Obwohl für die genannten Zwecke in den Unternehmen in der Regel spezialisierte Systeme
zur Verfügung gestellt werden, finden diese beim Anwender auf breiter Basis keine hin-
reichende Akzeptanz. Und dies obwohl Anwender z. B. eine Umgebung, die sich nicht an
Nachrichten sondern an Personen orientiert bevorzugen, und sie anerkennen, dass eine solche
Umgebung sie effizienter in der Kommunikation macht.174 Dieses Anwenderverhalten hat
Nachteile für das Unternehmen und das Individuum gleichermaßen. So führt das Verteilen
von in Dokumenten vorhandenem aufbewahrenswerten Unternehmenswissens per E-Mail,
verglichen mit der Nutzung einer gemeinsam verwendeten Datenbank, nicht zum sozialen
Optimum in Bezug auf den Gesamtaufwand für die Verwaltung der in der E-Mail befind-
lichen Informationen, und somit für das Individuum zu zusätzlichem Aufwand. Würden statt
in der E-Mail-Umgebung alle Informationen gemäß geeigneter Informationsmanagement-
konzepte verwaltet, würde in Bezug auf den Aufwand zur Verwaltung eine Pareto-
Verbesserung eintreten. Denn jedes Dokument müsste nur einmal abgelegt werden, im
Gegensatz dazu muss jeder Empfänger die E-Mail für sich selbst organisieren. Hinzu kommen
Anforderungen aus dem Wissensmanagement, die ein strukturiertes Ablegen relevanter
Inhalte in Repositories erfordern.
3.4.3 Isolierte und dezentrale Repositories
Der große Erfolg der E-Mail spiegelt sich in seiner über die ursprüngliche konzeptionelle
Bestimmung hinausgehende Nutzung als Werkzeug wider, z. B. um koordinative und kollabo-
172 Vgl. [Whittaker/Sidner 1996].
173 Vgl. [Fisher et al. 2006].
174 Vgl. etwa [Whittaker et al. 2004] S. 461.
80
rative Prozesse abzubilden (vgl. Abschnitt 3.4.2). In Abschnitt 3.3.2 wurde außerdem
beschrieben, dass in Unternehmen häufig isolierte Repositories anzutreffen sind. Die Nutzung
von E-Mail für eine Vielzahl von Aktivitäten weist darauf hin, dass der einzelne Mitarbeiter
Eigenschaften wie den zentralen Zugriffsbereich zu allen Informationen und die an seine
individuellen Bedürfnisse bei der Aktivitätsbearbeitung angepassten Strukturierungsmerkmale
gegenüber spezialisierten aber isolierten Werkzeugen bevorzugt. Er bevorzugt also ein
Werkzeug gegenüber einer Vielzahl an Werkzeugen, auch wenn das eine Werkzeug ihn nicht
optimal bei der Aktivitätsbearbeitung unterstützt.
Ein weiterer wichtiger Grund für die anhaltend intensive E-Mail Nutzung könnte in dem
notwendigen Paradigmenwechsel bei der Umstellung von E-Mail auf andere kollaborative
Systeme liegen. Nur wenn soziale Systeme wie eine Abteilung oder das Unternehmen als
Ganzes ihre Arbeitsweise umstellen, entsteht eine Pareto-Verbesserung für alle betroffenen
Individuen. Erfolgt die Umstellung hingegen nur durch einen Teil einer Gruppe, entsteht für
Individuen, die CIS bestimmungsgemäß und zum Nutzen des Unternehmens einsetzen, ein
subjektiv erhöhter Aufwand bei der Bearbeitung von Aktivitäten, und somit eine individuell
als nachteilig empfundene Situation.
Die Tatsache, dass einzelnen Anwendern der Überblick über das Gesamtsystem der Unter-
nehmensprozesse fehlt und somit eine Reflexion der Abläufe nur schwer möglich ist,
beschränkt deren Sichtweise auf ihre jeweils individuelle Situation. Durch die Bestrebung der
individuellen Aufwandsminimierung bei der Bearbeitung von Aktivitäten, kommt es zum
beschriebenen Verhalten der Meidung aufgabenangemessener kollaborativer Systeme.
Verbesserungen komplexer Abläufe können daher nur im Zusammenspiel des gesamten
sozialen Systems vorgenommen, eingesehen und umgesetzt werden. Es handelt sich also um
eine strategische Herausforderung, bei dessen Umsetzung die Individuen unterstützt werden
müssen.
Neben der Überflutung mit E-Mail hat die allgegenwärtige Verfügbarkeit von Informationen
durch Internet und Dokumenten Repositories in den Intranets der Unternehmen zu einer
generellen Informationsüberflutung (Information Overflow) geführt, die die Strukturierung
und Identifikation von für eine gegebene Aktivität relevanten Informationsobjekten in
verteilten Informationsquellen erheblich erschwert hat. Auch CoMS haben bisher häufig
aufgrund mangelnder Akzeptanz bei der Erstellung, Ablage und Referenzierung von Doku-
menten oder nicht bestimmungsgemäßer Nutzung verfügbarer Werkzeuge nicht zu einer
signifikanten Verbesserung der Produktivität am kollaborativen Arbeitsplatz beigetragen.
81
3.4.4 Werkzeugunterstützung für Kontextmanagement
Während Ansätze zum Wissensmanagement bisher primär auf das Management von Meta-
Daten fokussieren, sind applikationsübergreifende CoMS nicht verfügbar. Wie in Abschnitt
2.4.1 ausgeführt, werden üblicherweise spezialisierte Werkzeuge für das Management jeweils
einer einzelnen Kontextdimension eingesetzt. Die folgenden Abschnitte zeigen bereits existie-
rende Werkzeugunterstützung für Kontextmanagement auf.
3.4.4.1 Management physischer Kontextdimensionen
Physische Kontextdimensionen beziehen sich auf Kontextinformationen über die Realwelt. So
wird die Kontextinformation über eine verfügbare Verbindung zum Internet als Präsenz-
information (engl. Online Awareness) bezeichnet. Neben der Information über den Online
Status wird die Statusinformation in aktuellen Systemen um weitere Informationen zum
Anwenderstatus ergänzt, wie beispielsweise „Bitte nicht stören“, oder „Online, aber vom
Gerät abwesend“. Eine Information über das aktuell vom Anwender verwendete Gerät zur
Informationsverarbeitung, wie etwa ein Laptop oder ein Smartphone wird als Device
Awareness bezeichnet. Die dritte physische Kontextdimension Place Awareness beschreibt
die geografische Position des Wissensarbeiters. Der Begriff Place Awareness kann sich neben
der geografischen Position auch auf den Arbeitskontext eines Wissensarbeiters beziehen. So
kann über die Kontextinformation festgestellt werden, an welchem Dokument der Anwender
aktuell arbeitet. Das Repository, die Applikation und ggf. ein Bereich innerhalb des
Repositories werden dabei jeweils als Place bezeichnet.
Online Awareness kann genutzt werden, um negative Unterbrechungen durch synchrone
Kommunikation zu vermeiden. So fanden Mark, González und Harris heraus, dass Kollegen,
die unmittelbar aneinander grenzende Arbeitsplätze haben, sich gegenseitig seltener unter-
brechen als Kollegen die weiter voneinander entfernt sind.175 Eine Folgerung ist, dass durch
die physische Nähe ein besserer Zeitpunkt für eine Unterbrechung gefunden werden kann, als
in entfernten Umgebungen, z. B. durch Gespräche, oder weil ohnehin gerade eine Unter-
brechung stattfindet. Ist es nicht sicher, ob der Zeitpunkt für eine Unterbrechung geeignet ist,
wurde nachgefragt. Eine vergleichbare Funktion kann in verteilten Teams die Online
Awareness leisten.
Place Awareness ermöglicht es darüber hinaus, negative Unterbrechungen in positive Unter-
brechungen zu wandeln indem synchrone Kommunikation verschoben wird, bis ein Team-
mitglied gerade im gleichen Place oder Dokument arbeitet. Auch kann festgestellt werden, ob
175 Vgl. [Mark/González/Harris 2005] S. 325.
82
ein Teammitglied gerade an der gleichen Aktivität arbeitet. So können sich Rückfragen
effizienter für den Fragenden und weniger störend für den Gefragten auswirken, weil der
Gefragte ohnehin im gleichen Thema ist und seine Aktivität so ggf. nicht wechseln muss. Im
besten Fall kann sich die Diskussion für alle Kommunikationsteilnehmer positiv auf ihre
aktuelle Tätigkeit auswirken. Die Place Awareness kann also einen Teil der positiven Effekte
des zufälligen Zusammentreffens von Arbeitskollegen, etwa in der Kantine oder der Kaffee-
küche ersetzen, bei dem es zum Austausch von Informationen kommt. Ohne Place Awareness
kommt bei verteilten Teams dieses Zusammentreffen nicht sehr häufig vor.
Awareness Informationen können zudem von Applikationen genutzt werden, um den Anwen-
der in seinem Arbeitskontext optimal zu unterstützen. So kann das Werkzeug für die Anzeige
der Online Awareness, üblicherweise heutzutage ein Instant Messaging Produkt, Kalender-
informationen nutzen, um während einer Besprechung automatisch auf „Bitte nicht stören“ zu
schalten. Eine Unified-Messaging-Umgebung kann telefonische Anrufe anhand von Online
und Device Awareness entsprechend weiterleiten. So können beispielsweise Regeln definiert
werden wie „Wenn die Online Awareness ‚abwesend’ anzeigt und der Anwender auf dem
Mobiltelefon angemeldet ist, bitte Anrufe auf den Anrufbeantworter weiterleiten, sonst ins
Sekretariat“.
Informationen zur Place Awareness können zudem verwendet werden, um den Anwender nur
aufgrund von Benachrichtigungen durch ein Popup Fenster zu unterbrechen, wenn die
Benachrichtigung für den aktuellen Arbeitskontext relevant ist (vgl. Abschnitt 3.2.5). So kann
eine Benachrichtigung über eine neue E-Mail von einem Mitglied eines Projektteams hilfreich
sein, wenn der Anwender aktuell an diesem Projekt arbeitet. Bei anderen Aktivitäten hinge-
gen würde sich eine solche Benachrichtigung ggf. als Unterbrechung negativ auf die Produk-
tivität auswirken. Place Awareness im geografischen Sinne kann genutzt werden, um dem
Anwender Umgebungsinformationen zu präsentieren, z. B. wo befindet sich auf einer Reise
der nächste Geldautomat, oder im Rahmen von Least-Cost-Routing für die Auswahl eines
Mobilfunkproviders in Abhängigkeit des Landes, in dem sich der Anwender gerade befindet.
Das Management physischer Kontextdimensionen muss üblicherweise nicht manuell durch-
geführt werden. Viele der Kontextdimensionen werden automatisch bereitgestellt. Online
Awareness durch ein Instant Messaging Produkt, Device Awareness durch das Endgerät
selbst, oder eine Applikation auf dem Endgerät, und Place Awareness durch die Applikation
oder einen GPS Empfänger im Endgerät. Es ist aber auch üblich, dass die Kontext-
informationen manuell überschrieben werden können. So kann der Anwender einstellen, ob er
83
gerade nicht gestört werden möchte oder dass Informationen zur Place Awareness nicht an
andere Applikationen übertragen werden sollen. Eine Systemumgebung, die physische
Kontextinformationen zur Verfügung stellt und nutzen kann, wird als Context Aware System,
das Konzept als Context Aware Computing bezeichnet.
3.4.4.2 Management von Geschäftsprozesskontexten
In Abschnitt 2.4.1 sind die Grundlagen zum Kontextmanagement ausgeführt worden. Ein
Dokument kann sich in verschiedenen Kontexten befinden, die unabhängig voneinander
existieren. Wenn der Anwender einer Applikation in der Liste seiner aktuellen Aufgaben ein
Dokument zur Bearbeitung vorfindet ist nur der Kontext relevant, dessen zugehörige
Kontextinformationen für die Navigation zum Dokument verwendet wurden. Außerdem
geben die Kontextinformationen weitere Informationen zur Einschätzung des Dokuments an,
wie beispielsweise Zieldatum für die Bearbeitung oder die Priorität einer Aktivität.
Ist ein Dokument zum Editieren oder Lesen geöffnet, können Informationen über alternative
Kontextdimensionen zusätzlich wertvolle Hintergrundinformationen liefern, die für die
Bearbeitung des Dokuments von Bedeutung sein können, oder das Verständnis der Inhalte des
Dokuments verbessern. Der Anwender könnte sich also sowohl für den Workflowkontext, als
auch für den Korrespondenzkontext interessieren, in dem sich das Dokument befindet. Ein
Dokument kann sich in beliebig vielen Kontexten befinden, auch in mehreren Kontexten der
gleichen Kontextdimension. So kann etwa ein Projektbericht Relevanz für mehrere Projekte
haben. Tritt einer der geschilderten Fälle ein, wirkt sich die zusätzliche Kontextinformation
positiv auf die Wissenskonstruktion des Anwenders aus.
Kontextdimensionen können in Beziehung zueinander stehen. So kann sich ein Dokument,
das einen Vorgang in einem Projekt beschreibt und somit einen Projektkontext aufweist, sich
in einem Workflow befinden, in dem die Zuweisung einer Ressource beantragt wird. Der
Workflowkontext ist projektspezifisch. Gleichzeitig kann sich das Dokument in einem
Workflow des Projektcontrollings befinden, in dem mehrere Projekte auf die Einhaltung von
Dokumentationsrichtlinien überprüft werden. Der Workflowkontext ist in diesem Fall unab-
hängig von einem Projektkontext. Der Projektkontext kann jedoch Relevanz für den
Controller haben, der das Dokument im Kontext des Projektes bewerten muss.
Die Kontextdimensionen Prozesskontext, Projektkontext und Korrespondenzkontext werden
als Geschäftsprozesskontext bezeichnet. Sie können in einer n:n Beziehung zueinander stehen,
mit n>=0. Die meisten weiteren Kontextdimensionen lassen sich auf diese Drei zurückführen.
Bei Kontextinformationen über den Wissenskontext handelt es sich etwa lediglich um eine
84
spezielle Workflowkontextdimension. Wissensmanagementprozesse sind beispielsweise die
Prozesse der Wissensidentifikation oder der Wissensnutzung.176 Weitere Summary-Daten im
Wissensmanagement beschreiben üblicherweise die Inhalte des Dokuments, es handelt sich
also nicht um Kontextinformationen, sondern um deskriptive Meta-Daten (vgl. Abschnitt
2.2.2.4).
Abbildung 3-7: Geschäftsprozesskontextdimensionen und übliche Kontextbeziehungen
Abbildung 3-7 zeigt beispielhaft die Beziehung der drei genannten, wichtigen Basiskontext-
dimensionen sowie beispielhaft weitere spezielle Kontextdimensionen. Die Entwicklung eines
umfassenden, generischen Modells für die Darstellung und Navigation von Informationen zu
unterschiedlichen Kontextdimensionen ist nur schwer möglich. Das komplexe Beziehungs-
netzwerk der hier lediglich fünf klar abgrenzbaren Kontextdimensionen zeigt dies. Die
Tatsache, dass insbesondere im Umfeld des kollaborativen Arbeitsplatzes eine Vielzahl von
Ad-hoc-Aktivitäten auftreten, die etwa als Ad-hoc-Workflows, Ad-hoc-Projekte oder Team-
kollaboration klassifiziert werden können (vgl. auch Abbildung 2-6) unterstreicht diese These.
Dies ist einer der Gründe, warum es mit existierenden Systemumgebungen aktuell nicht
möglich ist, eine sinnvolle Navigation durch alternative Kontexte eines Dokuments durch-
zuführen, da für diese Geschäftskontextdimensionen jeweils spezialisierte Klassen von
Applikationen zur Verfügung stehen. Dies sind WfMS, PMS oder CRM Systeme. Hinzu
kommt eine Fülle von Spezialapplikationen. In der Praxis verfügen diese Systeme zudem
jeweils über eigene Repositories. Dies hat zur Folge, dass ein Dokument, das sich in mehreren
Geschäftsprozesskontexten befindet, in mehreren Repositories als Kopie, ggf. in unter-
176 Für eine Übersicht von Wissensmanagement Prozessen verschiedener Autoren siehe [Smolnik 2006],
Tabelle 2.1.
85
schiedlichen Versionsständen, mit jeweils einem kontextspezifischen Satz an Kontext-
information vorhanden ist. Dies führt zu einer Fülle von Herausforderungen im Umfeld von
ECM, wie Versionsmanagement, Zugriffsmanagement, Archivierung usw. und macht zudem
eine Inter-Kontextnavigation für den Anwender unmöglich.
3.4.4.3 Individuelle Dokumentenkontexte
Da die Anforderungen an das Kontextmanagement für individuelle Bedürfnisse sowie für die
Anforderungen von Teams unterschiedlich sind, werden Geschäftskontexte und individuelle
Dokumentenkontexte unterschieden. Beispiele für individuelle Kontexte sind der Aktivitäts-
kontext und der individuelle Wissenskontext. Der Aktivitätskontext ist ein Meta-Kontext der
Geschäftskontexte. Er dient der individuellen Koordination und Strukturierung der eigenen
Aktivitäten, sowohl der individuellen, als auch der Teamaktivitäten. Aus dem Merkmal der
Individualität (vgl. Abschnitt 3.2.4) folgt, dass die Strukturierungsmerkmale von individuellen
als auch kooperativen Aktivitäten unterschiedlich sind. Um den Bedürfnissen aller Team-
mitglieder bei der Strukturierung einer Teamaktivität gerecht zu werden, müsste eine Aggre-
gation vieler individueller Aktivitätskontexte erfolgen. Da es hierbei zwangsläufig zu
Konflikten kommt, müsste im Dialog ein intersubjektiver Konsens für die Aktivitätsstruktur
erzielt werden.
In der Praxis ist der umgekehrte Weg üblich. Die Individuen erlernen die existierende
Aktivitätsstruktur und passen sich ihr an. Das individuelle Aktivitätenmanagement findet
außerhalb der Teamarbeitsumgebung statt. Es erfolgt dann eine Synchronisation von indivi-
dueller Umgebung und Teamumgebung. Kein aktuell verfügbares Werkzeug ermöglicht
individuell unterschiedliche Sichten auf eine Aktivitätsstruktur, die signifikant von der
Teamstruktur abweichen kann. Wenige verfügbare Filtermechanismen beschränken sich auf
das Ausblenden von Einträgen, z. B. aufgrund von Zugriffsrechten oder Stichwort Filter-
mechanismen. Ein Beispiel für ein verfügbares kommerzielles System ist der IBM
Connections Aktivitäten Service.177
Neben dem Management von Aktivitäten, bzw. den für Aktivitäten benötigten Dokumenten
haben Wissensarbeiter das Bedürfnis, auch außerhalb von konkreten Aktivitäten Dokumente
zu verwalten, die sie etwa für zukünftige Aktivitäten als nützlich erachten. Sie werden als
Referenzinformation zum eigenen Wissen aufbewahrt und zwecks Auffindbarkeit strukturiert.
Dieser Kontext wird als individueller Wissenskontext bezeichnet und kann auf den
177 Informationen unter http://www.ibm.com/software/lotus/products/connections/activities.html [07.10.2011].
86
Aktivitätskontext zurückgeführt werden. Es handelt sich um eine andere Kontextdimension
als der Wissenskontext, der in Abschnitt 3.4.4.2 beschrieben ist.
3.4.4.4 Klassifizierung von Dokumenten anhand von Kontextinformationen
Die Sicht eines Anwenders auf Dokumente bildet einen Querschnitt durch das Beziehungs-
geflecht der Kontexte. Für die Klassifizierung von Dokumentenkontexten gelten die gleichen
Prinzipien wie für deskriptive Meta-Daten. Sie dient der effizienten Navigation in Kontext-
informationen und dem Auffinden eines speziellen Dokuments. Bei der Klassifizierung
existiert stets ein Zielkonflikt zwischen Unübersichtlichkeit bei zu vielen Dokumenten
innerhalb einer Klasse oder Unterklasse, und zu vielen Navigationsschritten bei Vorliegen
einer zu tiefen Klassifizierungshierarchie. Um eine effektive Navigation zu gewährleisten,
muss die Klassifizierungshierarchie daher regelmäßig optimiert werden.
Für die Klassifizierung von Dokumenten existieren zwei gängige Modelle. Werden die
Klassen und Unterklassen durch das Unternehmen vorgegeben, wird dies als Taxonomie
bezeichnet. Eine Taxonomie hat den Vorteil, dass bei Kenntnis der Taxonomie Dokumente
sehr effektiv gefunden werden können. Nachteilig ist die geringe Flexibilität bei der Klassi-
fizierung. So kann nicht auf individuelle oder gruppenspezifische Bedürfnisse eingegangen
werden. Auch erfordert die Pflege der Taxonomie regelmäßig Aufwand, da immer neue
Dokumente hinzukommen und andere gelöscht oder archiviert werden, so dass manche
Klassen zu voll, und andere Klassen obsolet werden.
Gibt es hingegen in Bezug auf die Klassifizierung keinerlei Einschränkungen, und entsteht die
resultierende Taxonomie evolutionär durch die Anwender, so wird dies als Folksonomy
bezeichnet. Eine Folksonomy genießt häufig eine sehr hohe Akzeptanz bei den Anwendern,
da es sich um einen intersubjektiven Konsens handelt. Jedoch sind häufig degenerierte
Strukturen zu beobachten, da das Arbeiten in einer Folksonomy eine hohe Disziplin erfordert.
Insbesondere die Vergabe von synonymen Klassenbezeichnungen führt dazu, dass Doku-
mente, die eigentlich in den gleichen Kontext oder die gleiche Inhaltsklasse gehören, in
verschiedenen, synonymen Klassen geführt sind. Die Reparatur einer degenerierten Struktur
ist jedoch in der Folksonomy nur eingeschränkt möglich, da die Anwender dann unter Um-
ständen ihre eigenen Dokumente nicht mehr auffinden können.
Da beide Methoden Probleme aufweisen wird häufig eine Kombination aus beiden Ansätzen
verwendet. So kann z. B. eine Taxonomie zum Einsatz kommen, in der zwar auf hoher
Aggregationsebene die Klassenbezeichnungen vorgegeben sind, tiefer in der Struktur aber
eine freie Stichwortvergabe erfolgen kann. Auch kann eine orthogonale Verwendung erfol-
87
gen. Dabei wird ein Dokument sowohl in eine Taxonomie als auch zusätzlich in eine freie
Klassifikationsstruktur eingeordnet. Eine Mehrfachklassifizierung erfordert jedoch auch einen
höheren Aufwand bei der Klassifizierung.178
3.5 Forschungs- und Praxislücke
3.5.1 Fehlende Werkzeugunterstützung für Aktivitätenmanagement
In der Praxis existieren Werkzeuge zur Unterstützung des Wissensarbeiters bei der Strukturie-
rung von Aktivitäten. Entsprechend der vorherrschenden Werkzeugzentrierung (vgl.
Abschnitt 3.4.1) sind dies zunächst spezielle Werkzeuge für das individuelle Aufgaben-
management. Sie umfassen Commodity Funktionalitäten für das Aufgabenmanagement im
Rahmen der eingesetzten PIM-Umgebung oder ein erweitertes Funktionsspektrum in Form
spezialisierter Applikationen, z. B. dem Web 2.0-Dienst „Remember the milk“179. Daneben
gibt es Werkzeuge zur Team-basierten Koordination von Aufgaben und Aktivitäten180. Dies
sind sowohl klassische, an der CSCW Forschung orientierte Applikationen, als auch neuere
Entwicklungen, die speziell für die Ad-hoc-Aufgabenbearbeitung des Wissensarbeiters
konzipiert sind, wie beispielsweise der IBM Connections Aktivitäten Service181 oder Google
Wave182.
Aktuelle Werkzeuge zur Team-basierten Koordination von Aufgaben und Aktivitäten berück-
sichtigen jedoch nicht die Anforderungen, die Unternehmen etwa im Kontext einer ECM
Strategie haben, oder die Anforderungen, die aufgrund regulatorischer und gesetzlicher
Anforderungen entstehen. Sie verwalten jeweils die Inhalte gemeinsam mit den Kontext-
informationen über die Aktivitätsstruktur in einem eigenen Repository, das nicht in die
Unternehmensinfrastruktur integriert ist. Über Schnittstellen ist es zwar üblicherweise mög-
lich, die Inhalte regelbasiert in Archiv, Backup und andere Systeme zu integrieren, die Unter-
nehmensprozesse umsetzen. Jedoch besteht dann die bereits diskutierte Problematik verschie-
dener Versionsstände, aufwändiger Integrationsprojekte oder fehlender Informationen über
Alternativkontexte wie etwa bereits in den Abschnitten 3.3.1 und 3.4.4.2 ausgeführt.
Außerdem berücksichtigen sie nicht die Vielstimmigkeit von heterogenen, virtuellen und
interorganisationalen Teams. Individuelle Bedürfnisse der Anwender in Bezug auf die
Strukturierung von Aktivitäten werden in Team-orientierten Umgebungen nicht umgesetzt.
Auch der Einsatz einer Kombination aus Workflow-, Projekt- und Knowledge-Management
178 Für weitere Ausführungen zur Navigation von Klassifizierungshierarchien vgl. [Erdmann 2001], Kapitel 3.
179 Vgl. http://www.rememberthemilk.com [07.10.2011].
180 Zur Unterscheidung von Aufgaben und Aktivitäten vgl. Abschnitt 4.1.1.
181 Vgl. http://www.ibm.com/software/lotus/products/connections/activities.html [07.10.2011].
182 Vgl. http://wave.google.com [07.10.2011]. Hinweis: Das Projekt wird durch Google nicht weiter entwickelt.
88
oder Ad-hoc-Kollaborations-Applikationen berücksichtigt nicht hinreichend die Bedürfnisse
von Mitarbeitern in Bezug auf ihre individuelle Aufgabenbearbeitung im Kontext von
komplexeren Aktivitäten, sowie der Planung und Strukturierung der Aktivitäten, an denen sie
beteiligt sind.
Es fehlt eine einheitliche Werkzeugunterstützung für die Strukturierung von Aufgaben und
Aktivitäten aus allen genannten Systemklassen, ein Werkzeug zum Management von
Geschäftsprozesskontexten. Für diese strukturierende Meta-Ebene, in der Informationen über
den Aktivitätskontext verschiedener Dokumente zu einer Aktivitätsstruktur aggregiert wer-
den, gibt es aktuell kein Werkzeug, das die Anforderungen von Individuen, Teams und
Unternehmen gleichermaßen, hinreichend berücksichtigt. Es ist für den Anwender daher
aktuell nicht möglich, alle kollaborativen Interaktionen, alle Dokumente und alle zur Bear-
beitung von Dokumenten notwendigen Werkzeuge so zu organisieren, dass der Zustand eines
Arbeitskontexts über Unterbrechungen hinweg konserviert wird. Es fehlt der zentrale
Zugriffsbereich im Aktivitätenmanagement, der die Anforderungen des Unternehmens
berücksichtigt und gleichzeitig eine integrierte Sicht auf individuelle und kollaborative
Aktivitäten mit personalisierten Strukturierungsmöglichkeiten bietet.
3.5.2 Fehlende Explikation werkzeugübergreifender Geschäftsprozess-
kontexte
Bei komplexen Aktivitäten ist die Explikation aufgrund der beschränkten kognitiven Fähig-
keiten des Menschen notwendig (vgl. Abschnitt 2.2.1). Durch das fehlende Werkzeug zur
aggregierten Darstellung von Geschäftsprozesskontexten muss der Wissensarbeiter mit
anderen Werkzeugen versuchen, seine Aktivitäten zu organisieren und strukturieren. Dabei
kommt es zu Mehrfacharbeit, Medienbrüchen und Inkonsistenzen. Außerdem stehen die
explizierten Informationen zur Aktivitätsstruktur nur dem Individuum zur Verfügung und
können weder durch das Team, noch durch das Unternehmen genutzt werden. Dies führt zu
Intransparenz von Aktivitäten oder einzelnen Aufgaben auf Team- und Unternehmensebene
und erhöht die Informationsasymmetrie. Durch die Informationsasymmetrie entsteht Raum
für opportunistisches Verhalten. Außerdem können Messkosten und Mehrfacharbeit bei
weiteren Akteuren entstehen (vgl. Abschnitt 2.1.3). Dies kann zu Ineffizienzen bei der
Aktivitätsbearbeitung und somit zu höheren Kosten für das Unternehmen führen.
Auch wird der Wissensarbeiter nicht hinreichend bei der kognitiven Arbeit der Aggregation
von Dokumenten, die für die Bearbeitung einer Aktivität benötigt werden, unterstützt, da die
von ihm genutzten Werkzeuge, von E-Mail über Applikationen für das individuelle
89
Aufgabenmanagement bis hin zu Klebezetteln am Monitor, nicht für das Aktivitäten-
management optimiert sind. Hier existieren Potenziale zur Produktivitätsverbesserung.
Durch fehlende Explikation wird auch die Möglichkeit eingeschränkt, die Bearbeitung
ähnlicher Aktivitäten evolutionär weiter zu entwickeln und so im Verlauf der Zeit zu optimie-
ren, da eine strukturierte Analyse durch Unbeteiligte oder Reflexion durch das Individuum
selber nicht oder nur eingeschränkt möglich ist. Auch die organisationale Wissens-
konstruktion, z. B. durch die Entwicklung standardisierter Aktivitätsvorlagen auf Basis von
bereits durchgeführten Aktivitäten ist nicht möglich.
Zudem sind nicht nur die Werkzeuge häufig wenig integriert, auch die für eine Aktivität
benötigten Dokumente sind in der Regel über verschiedene Repositories verteilt. Zur Bear-
beitung der Aktivität müssen Mitarbeiter diese Dokumente aktiv in einem für die Bearbeitung
der Aktivität adäquaten Kontext zusammenführen. Wenn die Informationen nicht expliziert
vorliegen, müssen zunächst die relevanten Dokumente identifiziert werden. Aufgrund der
mangelnden Werkzeugunterstützung und damit fehlender Explikation in geeigneter Form im
System selbst kommt es vor, dass die Informationssuche und die kognitive Arbeit der Struk-
turierung nach jeder Unterbrechung erneut, wenn auch mit gesteigerter Effizienz durch einen
Lerneffekt, erfolgen muss. Die Suche nach Informationen verursacht Transaktionskosten. Da
Unterbrechungen am kollaborativen Arbeitsplatz häufig vorkommen (vgl. Abschnitt 3.2.5),
verringert dies die Produktivität und erhöht somit die Transaktionskosten der Bearbeitung
einer Aktivität.
Demnach sind Werkzeuge erforderlich, welche die anwender- und aktivitätsspezifische
Gruppierung von Dokumenten und zugehörigen Applikationen ermöglichen. Beim Entwurf
dieser Werkzeuge ist zu berücksichtigen, dass sowohl Dokumente, als auch Applikationen in
einer Vielzahl von Kontexten verwendet werden. Der individuelle Bearbeitungsstatus und der
Zustand der Applikation sollten über mehrere Sitzungen kontextspezifisch konserviert werden
können, um die Arbeit nach Unterbrechungen leicht wieder aufnehmen zu können.183
183 Vgl. [González/Mark 2004], S. 119f.
90
4 Entwurf eines Unified Business Activity Management
Framework
Kapitel 4 stellt das zentrale Konzeptkapitel der Arbeit dar. Nach der Diskussion von Nutzen-
dimensionen der Werkzeugunterstützung und der Herleitung von Grundannahmen für das
kollaborative Aktivitätenmanagement erfolgt eine Analyse der Anforderungen an eine UBAM
Architektur unter funktionalen und technischen Gesichtspunkten. Basierend auf den
Anforderungen erfolgen analytisch-deduktiv die Konstruktion des Modells und der Archi-
tekturentwurf für ein UBAM Framework. Die Architektur stellt das Ergebnis des
evolutionären und heuristischen Forschungsprozesses dar.
Als Abbildung der diskutierten Anforderungen stellt die Architektur im Rahmen des
Forschungsprojekts ein Maximalmodell dar. Eine vollständige Implementierung der Archi-
tektur ist nicht in allen Unternehmensszenarien technisch möglich oder ökonomisch sinnvoll.
Daher findet in Unterkapitel 4.7 eine Transformation des Maximalmodells in Szenario-
spezifische Handlungsanweisungen statt, indem eine Auswahl von Funktionen sowie deren
Priorisierung vorgenommen wird. Dies gibt für die Anwendung des Modells in der Praxis
Hilfestellung bei der Frage, welche Architekturmerkmale in Abhängigkeit von einem
konkreten Szenario bevorzugt berücksichtigt werden sollten.
4.1 Betrachtungsgegenstand des UBAM
4.1.1 Aktivitäten und Aufgaben
Das Ziel von UBAM ist die Unterstützung des einzelnen Wissensarbeiters bei der Verwal-
tung, Strukturierung, Priorisierung, zeitlichen Planung und Koordination der individuellen
sowie der arbeitsteiligen Bearbeitung sämtlicher Tätigkeiten, die ein Wissensarbeiter am
kollaborativen Arbeitsplatz durchführen muss, in einer einheitlichen Arbeitsumgebung. Dabei
sollen sowohl die Anforderungen der Unternehmung, die Anforderungen an die Koordination
von Teamarbeit, als auch die koordinativen Anforderungen des persönlichen Informations-
managements berücksichtigt werden. Aufgrund der Berücksichtigung der drei Anforderungs-
klassen Individuum, Team und Unternehmung berücksichtigt werden, wird der Ansatz als
Unified Business Activity Management bezeichnet. Es handelt sich dabei um eine andere
Bedeutung als bei Moran, der den Begriff „Unified“ verwendet, weil sich das Meta-Modell
als generischer Basisdatensatz grundsätzlich eignet, um verschiedene Formen von Tätigkeiten
zu unterstützen.184 In Ermangelung einer adäquat präzisen Übersetzung für den Begriff
184 Vgl. [Moran 2005], S. 2.
91
„Unified“ im Kontext dieser Arbeit wird die englische Bezeichnung als Projektname bei-
behalten.
Das UBAM Framework basiert auf der Tätigkeitstheorie, verwendet jedoch von dieser
abweichende Begrifflichkeiten. Da nur wenig relevante Veröffentlichungen in deutscher
Sprache erschienen sind, hat sich statt des aus der Tätigkeitstheorie stammenden Begriffs
„Tätigkeit“ auch im deutschen Sprachgebrauch die Bezeichnung „Aktivität“ durchgesetzt.
Daher wird auch in Deutschland von Aktivitätenmanagement gesprochen. Dieser Sprach-
gebrauch wird im Kontext dieser Arbeit ebenso verwendet. So bezeichnet der Begriff Tätig-
keit im Kontext dieser Arbeit jegliches zielgerichtete Handeln. Eine Tätigkeit, die ein An-
wender am kollaborativen Arbeitsplatz ausführt wird als Geschäftsaktivität (engl. Business
Activity) bezeichnet. Vereinfachend wird im Folgenden der Begriff Aktivität synonym
verwendet. Aktivitäten können aus mehreren Aktivitäten zusammengesetzt sein. Diese
werden auch als Teilaktivitäten bezeichnet.
Als Aufgabe (engl. Task) wird in diesem Zusammenhang eine als atomar empfundene Hand-
lung bezeichnet, die das Individuum an einem Dokument mithilfe eines Werkzeugs ausführt,
z. B. das Schreiben einer E-Mail mithilfe der Applikation E-Mail-Client. Das Empfinden von
Atomizität ist von vielen individuellen Einflussfaktoren abhängig. In Abhängigkeit von diesen
Faktoren kann das Schreiben einer E-Mail auch als Aktivität empfunden werden (vgl.
Abschnitt 2.4.2). Eine Aufgabe liegt also dann vor, wenn eine Aktivität oder eine Teilaktivität
durch das handelnde Individuum kognitiv nicht weiter hierarchisch unterteilt wird. Im Sinne
der Tätigkeitstheorie liegt also eine Handlung vor. Handlungen haben immer ein Ziel und sind
mit einem konkreten Transformationsprozess verbunden. Bei den zu transformierenden
Objekten handelt es sich um ein oder mehrere Dokumente. Im Gegensatz zu Handlungen
finden Operationen nicht bewusst statt. Sie sind somit auch nicht für das Management von
Aktivitäten relevant, und werden daher bei der Konstruktion des UBAM Frameworks ver-
nachlässigt. Eine Teamaufgabe ist eine Handlung, die durch ein Individuum als atomar
empfunden wird, die aber durch ein oder mehrere andere Individuen, die Bearbeiter, ausge-
führt werden soll. Es kann vorkommen, dass einer oder mehrere der zugewiesenen Bearbeiter
die Aufgabe nicht als atomar empfinden und sie entweder in mehrere Teilaktivitäten und
Aufgaben zerlegen, oder mehrere Aufgaben zusammenfassen würde.
Zusammenfassend bezeichnet eine Aktivität also eine unbestimmte Anzahl von Teilaktivitä-
ten und Aufgaben, welche von einem Individuum im Kontext eines geschäftlichen Vorgangs
als zusammengehörige Einheit wahrgenommen wird. Eine Aktivität kann n>=0 Teilaktivitä-
92
ten und m>0 Aufgaben enthalten. Im Kontext des UBAM Frameworks umfasst der Begriff
Management alle Tätigkeiten, die der Koordination der Aufgabenbearbeitung im Rahmen von
Aktivitäten dienen. Dies bezieht sich sowohl auf die Koordination individueller Aufgaben, als
auch von Teamaufgaben. Management umfasst die Verwaltung und Pflege der hierarchischen
Beziehungsstruktur von Aktivitäten, Teilaktivitäten und Aufgaben. Die Koordination umfasst
darüber hinaus unmittelbar mit der Aufgabenbearbeitung verbundene Handlungen wie die
Delegation von Teamaufgaben und Aktivitäten, Verwaltung von Prioritäten, zeitliche Planung
der Aufgabenbearbeitung und Zugriffskontrolle auf Elemente der Aktivität. Um für die
Koordination zugänglich zu sein, muss die Beziehungsstruktur der Elemente der Aktivität
zunächst expliziert werden.
Die explizierte Struktur muss darüber hinaus auch Aktivitätskontexte von Dokumenten
berücksichtigen, da Grundlage für die Aufgabenbearbeitung per Definition stets die Bearbei-
tung oder Rezeption von Dokumenten ist. Daher ist das Management des Aktivitätskontexts
von Dokumenten zentraler Bestandteil des Aktivitätenmanagements. Die Verwaltung weiterer
Kontextdimensionen soll nicht im Rahmen des Aktivitätenmanagements erfolgen, da hierfür
üblicherweise bereits spezialisierte Applikationen im Unternehmen vorhanden sind.
Primäre Elemente des UBAM Frameworks sind demnach der Wissensarbeiter, das Team und
die Unternehmung, sowie Aktivitäten, Aufgaben, Dokumente und Aktivitätsstrukturen.
Außerdem müssen Anforderungen betrieblicher CIS-Infrastrukturen berücksichtigt werden,
etwa Applikationen zur Bearbeitung von Dokumenten und Repositories zu deren Speiche-
rung. Im folgenden Abschnitt wird auf Merkmale der Aktivitätsstruktur einer Aktivität
eingegangen.
4.1.2 Abbildung einer Aktivität durch Projektion
Eine Aktivität besteht wie beschrieben aus der Menge von Aufgaben und deren durch Teil-
aktivitäten beschriebenen Beziehungen, die im Kontext der motivgerichteten Ausführung von
Tätigkeiten am kollaborativen Arbeitsplatz in einem Bedeutungszusammenhang stehen. Als
Bedeutungszusammenhang in der Vorstellung eines Individuums ist eine Aktivität also
zunächst kein Objekt der Realwelt sondern ein mentales Modell. Um die Struktur der
Aktivität extern zugänglich zu machen muss eine Darstellung für das mentale Modell der
Aktivität gewählt werden. Da die Tätigkeiten des Menschen hierarchisch repräsentiert sind,
bietet sich eine hierarchische Visualisierung an. Für die Darstellung hierarchischer
Beziehungen in grafischen Benutzungsoberflächen hat sich das Paradigma der Ordnerstruktur
bewährt. Beispiele hierfür sind grafische Dateisystem-Browser, die Ablagestruktur von
93
E-Mails in Form von Ordnern oder die Darstellung von Diskussionsthreads in Web 2.0
Applikationen.
Abbildung 4-1: Mögliches Ergebnis der Projektion einer Aktivität
Für die Abbildung des mentalen Modells wird das Prinzip der Projektion durch das handelnde
Individuum gewählt. Trotz der Wahl des Begriffs Projektion soll nicht ausgeschlossen wer-
den, dass bei der Abbildung des mentalen Modells eine weitere Reduktion, etwa der
Komplexität, erfolgt. Der Begriff wird primär gewählt, um den Prozess der Explikation von
der Modellbildung, bei der eine Reduktion von Eigenschaften der Realwelt erforderlich ist,
abzugrenzen. Abbildung 4-1 zeigt die Abbildung des mentalen Modells von Aktivität A1
durch Projektion in Form einer hierarchischen Darstellung der Beziehungen zwischen Aufga-
ben im Kontext der Aktivität durch entsprechende strukturierende Teilaktivitäten. Durch die
Projektion wird die Aktivität A1 durch ein Artefakt als Aktivität A1’ visualisierbar. Da es sich
bei der Visualisierung um die Abbildung des mentalen Modells eines Individuums handelt,
weist die Projektion individuell spezifische Merkmale auf. Dies liegt daran dass die Existenz
einer Aufgabe im mentalen Modell vom Individuum und seinen Erfahrungen und sozio-
kulturellem Hintergrund abhängt.
Was für Individuum P1 eine Aufgabe ist, kann für ein anderes Individuum P2 eine Operation
im Sinne der Tätigkeitstheorie sein. Operationen werden jedoch nicht bewusst geplant,
sondern unbewusst ausgeführt. Sie sind so auch üblicherweise in der Projektion des mentalen
Modells von P2 nicht als Aufgaben enthalten. Da Aufgaben über Atomizität definiert wurden,
kann eine Aufgabe nicht weiter unterteilt werden. Es handelt sich in der Baumdarstellung der
hierarchischen Struktur bei Aufgaben also stets um Blätter.
94
Eine Teilaktivität kann weitere Teilaktivitäten enthalten, beispielsweise T2.1 als Teilaktivität
von T2. Jede Teilaktivität muss mindestens eine Aufgabe enthalten, sonst würde es sich bei
der Teilaktivität aufgrund der Atomizität definitionsgemäß um eine Aufgabe handeln. Enthält
die Teilaktivität lediglich eine Aufgabe, wie etwa T1, kann argumentiert werden, ob T1 nicht
als atomar empfunden werden müsste, und es sich somit eher um eine Aufgabe handelt. Der
Fall einer Teilaktivität mit nur einer Aufgabe soll aber ausdrücklich berücksichtigt werden, da
im Verlauf der Diskussion weitere Elemente der Darstellung einer Aktivität hinzugefügt
werden. Im Folgenden wird als Aktivitätsstruktur die Abbildung der hierarchischen Beziehun-
gen zwischen Aufgaben einer Aktivität und ggf. vorhandenen Teilaktivitäten durch Projektion
bezeichnet.
4.1.3 Individual- und Teamaktivitäten
In Abschnitt 2.3.1 wurde auf die Unterscheidung zwischen individueller Koordination und
Koordination im Team hingewiesen. Durch ein Werkzeug für UBAM sollen beide Arten der
Koordination von Aktivitäten unterstützt werden. Da sie jeweils unterschiedliche
Charakteristika aufweisen erfolgt hier eine Unterscheidung: Eine Aktivität, an der lediglich
eine Person beteiligt ist wird als Individualaktivität bezeichnet. Eine Aktivität mit mehreren
beteiligten Individuen wird als Teamaktivität bezeichnet.
Im Hinblick auf die Explikation der Aktivität hat das Individuum üblicherweise einen gerin-
geren Explikationsbedarf als eine Gruppe, die eine Teamaktivität koordinieren muss. Denn
um die gleichen Assoziationen bei anderen Individuen zu erzeugen muss die Bedeutung
deutlich ausführlicher beschrieben, und ggf. durch erläuternde Kommunikation ergänzt
werden. Und selbst bei ausführlicher Dokumentation kann es zu Fehlinterpretationen kom-
men, da Informationen nicht verlustfrei zwischen Individuen ausgetauscht werden können
(vgl. Abschnitt 2.3.2.3).
Neben der Ausführlichkeit der Explikation kann auch die Strukturierung der Aktivität speziell
auf die individuellen Bedürfnisse des Individuums zugeschnitten sein, denn es braucht keine
Rücksicht darauf zu nehmen, ob andere Teammitglieder eine ähnliche Strukturierung für
sinnvoll erachten würden. Es besteht also keine Notwendigkeit zu intersubjektivem Konsens
bei der Strukturierung einer Aktivität. Die individuell unterschiedlichen Strategien zum
Management von Aufgaben und Informationen zeigen sich an unterschiedlichen Arbeits-
plätzen deutlich. Insbesondere, wenn die Strategien zwischen Vertretern verschiedener
Disziplinen verglichen werden. Abbildung 4-2 zeigt die unterschiedlichen Ablagestrukturen
in einem illustrierenden Vergleich zwischen strukturierter Ablage und für Außenstehende
95
eher undurchsichtig erscheinenden Ablagestrukturen. Die linke Skizze zeigt den im Rahmen
einer Studie über physische Büroorganisation erfassten Arbeitsplatz eines Einkäufers, die
rechte Skizze das kreative Chaos eines Wissenschaftlers. Auch empirisch ist die Individualität
von Aufgabenmanagement vielfach untersucht und belegt worden, etwa in [Harrison 2004].
Abbildung 4-2: Ablagestrukturen administrativer und kreativer Disziplinen185
Auch aus technischer Sicht ist eine getrennte Betrachtung notwendig, da sich etwa der Be-
reich des Rechtemanagements unterscheidet. Werden für die Bearbeitung von Aufgaben im
Kontext der Aktivität Dokumente benötigt, die sich in Repositories des persönlichen
Informationsmanagements befinden (vgl. Abschnitt 2.3.2.2), spielt das im Rahmen von
Individualaktivitäten keine Rolle. Im Kontext einer Individualaktivität kann also etwa auf
E-Mails und Notizen im persönlichen Journal zugegriffen werden. Diese Dokumente stehen
für Teamaktivitäten jedoch in der Regel nicht oder nur eingeschränkt zur Verfügung, da das
Team auf das persönliche Repository mit PIM Informationen üblicherweise nur ein-
geschränkten oder keinen Zugriff hat. Wird ein entsprechendes Dokument also innerhalb von
Teamaktivitäten benötigt, muss es zuvor in einem dem Team zugänglichen Repository
abgelegt werden.
4.1.4 Aktivitätenmanagement
Ein Individuum ist regelmäßig an mehreren Aktivitäten zur gleichen Zeit beteiligt. Die
Verwaltung dieser Aktivitäten wird als kollaboratives Aktivitätenmanagement (engl.
Collaborative Activity Management, CAM) oder verkürzt als Aktivitätenmanagement be-
zeichnet. Um die Bearbeitung der Aktivitäten zu erleichtern und effizient zu gestalten ist es
wichtig, dass das Management mehrerer Aktivitätsstrukturen durch ein Werkzeug unterstützt
185 Vgl. [Malone 1983], S. 102f.
96
wird. Ein solches Werkzeug zur Unterstützung von CAM wird als CAM System (CAMS)
bezeichnet. Aktivitätenmanagement umfasst die Gesamtheit von Methoden, Techniken und
Werkzeugen, die der Verwaltung, Koordination und Durchführung von Aktivitäten am
kollaborativen Arbeitsplatz dienen und umfasst sowohl Individual- als auch Teamaktivitäten.
Die Verwaltung umfasst die Speicherung einer Vielzahl von Aktivitäten sowie Werkzeuge zu
deren Organisation, Strukturierung, Navigation und Filterung. Die Koordination umfasst die
Planung und Strukturierung der Aufgabenbearbeitung sowie die Abstimmung der Arbeits-
teilung.
Für die Durchführung der Aufgabenbearbeitung im Kontext von Aktivitäten werden Doku-
mente und Applikationen zum Zugriff auf Dokumente und zu deren Bearbeitung benötigt. Da
am kollaborativen Arbeitsplatz sehr unterschiedliche Dokumententypen und entsprechend
korrespondierende Applikationen und Repositories zum Einsatz kommen, kann die Verwal-
tung der Dokumente selbst nicht im CAMS erfolgen. Um dennoch möglichst alle Dokumente,
die für die Bearbeitung der Aktivität nötig sind, zu erfassen und im Kontext der Aktivität zur
Verfügung zu stellen, müssen im CAMS Verknüpfungen (Links) auf die Dokumente verwal-
tet werden.
Um für Management Funktionalitäten zugänglich zu sein, ist zunächst die Explikation des
mentalen Modells einer Aktivität notwendig. Erst dann kann die Aufgabenbearbeitung durch
Werkzeugunterstützung optimiert werden. Beispiele für Planungsaufgaben sind Delegation,
Statusmanagement, Zeitplanung der Bearbeitung, Verwaltung von Zieldaten und
Priorisierung. Im PIM Umfeld erfolgt Statusmanagement in der Aufgabenverwaltung, Zeit-
management mit der Kalender-Applikation und Koordination häufig über E-Mail. Team-
aktivitäten werden durch WfMS, PMS oder andere CIS, die jeweils isoliert Aufgaben-
management Funktionen wie ein eigenes Statusmanagement bereitstellen, koordiniert. Dieses
Szenario verdeutlicht, dass eine Vielzahl unterschiedlicher Werkzeuge genutzt werden muss,
um das Management aller Aktivitäten eines Anwenders zu ermöglichen. Ein zentraler Ein-
stiegspunkt zu allen Aufgaben und Aktivitäten steht üblicherweise nicht zur Verfügung.
Dieser soll im Rahmen des UBAM Frameworks geschaffen werden.
4.1.5 Abgrenzung von etablierten CSCW Konzepten
Der Begriff Aktivität wird im allgemeinen Sprachgebrauch vielfältig verwendet, etwa um
Prozesse, Projekte und Ad-hoc-Vorgänge zu beschreiben, die sowohl unstrukturiert, als auch
strukturiert, granular oder wenig granular, langläufig und kurzläufig sein können.186 Daher ist
186 Vgl. etwa [Ellis 1983], S. 13.
97
es notwendig, im Kontext dieser Arbeit eine Abgrenzung vorzunehmen. Die Facette des
Managements von Teamaktivitäten führt dazu, dass UBAM sich zunächst in Bezug auf die
Grundkonzepte des kollaborativen Arbeitsplatzes in den Bereich Koordination im Team
einordnen lässt (vgl. Abschnitt 2.3.1). Da auch die Koordination individueller Aktivitäten
unterstützt werden soll, bewegt sich UBAM demzufolge in einer Schnittmenge der Bereiche
CSCW und Computer Supported Individual Work.
In Bezug auf PIM Applikationen erweitert UBAM insbesondere den Bereich des Aufgaben-
managements durch Teamfunktionalitäten, erweiterte Strukturierungs- und Management
Funktionalitäten, sowie die Einbindung in das ECM Konzept des Unternehmens. Dies führt
auch dazu, dass Informationsaustausch per Kommunikation, z. B. per E-Mail, in eine koordi-
nierte Form des Informationsaustauschs überführt wird. Ebenso soll der Anwender ermutigt
werden, keine privaten Repositories etwa in Form von Journalen zu unterhalten, sondern die
Informationen im ECM System oder den CIS des Unternehmens bereitzustellen.
In Bezug auf Wissensmanagement stellt UBAM ein orthogonales Konzept dar. Es ist nicht
das Ziel von UBAM, etwa Ablage- und Klassifizierungskonzepte für Dokumente in
Repositories vorzulegen, um diese zur Unterstützung von Wissensmanagement Prozessen
auffindbar und zugreifbar zu machen. Wie in Abschnitt 4.2.2 gezeigt, kann Aktivitäten-
management Wissensmanagement Prozesse unterstützen, da Aktivitätsstrukturen an sich
expliziertes organisationales Wissen repräsentieren. Auch die implizite Kontextualisierung
von Dokumenten durch Herstellen einer Beziehung zwischen den Dokumenten und der
Verwendung der Dokumente im Kontext einer Aktivität trägt dazu bei, die Bewertung und
das Verständnis des Inhalts eines Dokuments zu erleichtern.
Klassische PMS sind gestaltet, um die Vorausplanung der Durchführung eines Projektes zu
unterstützen, da in Projekten üblicherweise ein detailliertes Controlling in Form von Kosten-
und Zeitmanagement erfolgen muss. Ebenso unterstützen viele Systeme die Einsatzplanung
von Ressourcen, indem etwa versucht wird, die Auslastung von Ressourcen zu berechnen. Im
Rahmen von UBAM finden keine Kostenplanungen statt. Zwar kann im Rahmen der
Aufgabenplanung eine Zeitplanung erfolgen, diese ist jedoch üblicherweise zeitpunkts-
bezogen in Bezug auf ein Zieldatum. Eine Erfassung von Aufwänden ist nicht vorgesehen.
Der Grund ist, dass im Gegensatz zu komplexen Projekten mit hohen Budgets und einer
langen Laufzeit, eine entsprechende detaillierte Vorausplanung bei Ad-hoc-Aktivitäten am
kollaborativen Arbeitsplatz ökonomisch nicht sinnvoll ist, da der Zeitaufwand zu groß wäre.
Der Aufwand der Vorausplanung stände auch in keinem Verhältnis zu dem typischerweise
98
geringen Risiko einer zeitlichen Verzögerung. Auch findet üblicherweise keine Budget-
planung bei Ad-hoc-Aktivitäten statt. Auch die Definition von zeitlichen Abhängigkeiten
zwischen Aktivitäten oder Aufgaben ist aktuell nicht vorgesehen, um die Abgrenzung von
etablierten CSCW Konzepten für den Anwender hervorzuheben. Sie kann in bestimmten
Szenarien sinnvoll sein, UBAM kann hier leicht erweitert werden.
Die Zuordnung von Ressourcen zu Aufgaben findet anders als in PMS statt. Während
Ressourcen in Projekten üblicherweise durch einen Projektmanager zu Aufgaben zugewiesen
werden, der den Einsatz beim zuständigen disziplinarisch Vorgesetzten, oder einem
Ressourcen Koordinator angefordert hat, kann die Zuweisung von Aufgaben im Umfeld von
UBAM auch kooperativ im Team stattfinden. Die Art und Weise sich selbst organisierender
Teams wurde in Unterkapitel 3.2 diskutiert.
Anwender haben an Aktivitätenmanagement andere Anforderungen als an das Projekt-
management. Die zeitliche Abhängigkeit einzelner Aufgaben innerhalb von Aktivitäten ist
geringer, die Struktur deutlich weniger komplex und eher ad hoc geplant als vordefiniert, und
die Anzahl der Mitglieder im Team ist eher klein. Daher erfolgt die Planung von Projekt-
vorgängen üblicherweise in einer geringeren Granularität als bei der Planung von Aktivitäten.
Nur so kann der Projektmanager sicherstellen, dass Vorgänge in Teamarbeit durch Wissens-
arbeiter kreativ und effizient in Eigenverantwortung durchgeführt werden können, und keine
zu starke Bevormundung durch den Projektleiter durch zu viel Detailplanung erfolgt.
Für die Koordination der Details der Aufgabenbearbeitung kann dann ein UBAM Werkzeug
eingesetzt werden. Es kann die Abwicklung von Projekten unterstützen, indem die zuge-
wiesenen Projektressourcen auf Vorgangsebene die Strukturierung der weiteren Bearbeitung
im Rahmen einer Aktivität durchführen. Auch für den Projektmanager kann die Projekt-
planung selbst als Aktivität organisiert sein. So zeigen etwa Zhang et al. wie sich der Einsatz
von wenig komplexem Aktivitätenmanagement positiv auf die Arbeit von Projektmanagern
auswirken kann.187
Auch im Bereich des Workflowmanagements kann eine klare Abgrenzung in Bezug auf die
verschiedenen Workflowtypen vorgenommen werden (vgl. Abschnitt 2.3.2.5). So ist bei semi-
strukturierten sowie vollständig vordefinierten Workflows eine Vorausplanung der Abläufe
zumindest in Teilbereichen des Workflows kennzeichnend. Dies ist im Bereich von UBAM
nicht üblich. Vielmehr entwickelt sich die Aktivitätsstruktur dynamisch weiter. Wird eine
Vorausplanung vorgenommen, oder werden Vorlagen für Aktivitätsstrukturen verwendet,
187 Vgl. [Zhang et al. 2007].
99
findet zumindest keine Planung der zeitlichen Abfolge der Bearbeitung statt. Ein weiteres
Kriterium der genannten Workflowtypen ist die vielfache Wiederholbarkeit des Ablaufs, ohne
den eine Modellierung als vordefinierter oder semi-strukturierter Workflow ökonomisch nicht
sinnvoll ist. Die Wiederholbarkeit ist bei Aktivitäten häufig nicht gegeben. Auch beim Einsatz
von Vorlagen für Aktivitätsstrukturen ist der übliche Fall, dass diese dem effizienten Start
einer Aktivität dienen, die Struktur sich im Verlauf der Aufgabenbearbeitung jedoch dyna-
misch fortentwickelt. Für eine weitere Diskussion der Abgrenzung zu WfMS siehe
[Nastansky 2006].
Im Bereich von Ad-hoc-Workflows fällt eine Abgrenzung schwerer, da sowohl die Wieder-
holbarkeit, als auch die Vorausplanung nicht maßgeblich sind. Jedoch ist im Bereich von Ad-
hoc-Workflows dennoch eine zeitlich sequenzielle Vorausplanung kennzeichnend, auch wenn
sich die Vorausplanung nur auf wenige Schritte bezieht. In Bezug auf die Granularität der
Vorausplanung lässt sich für vollständig vordefinierte Workflows sagen, dass diese üblicher-
weise so hoch ist, dass hier keine Teamaktivitäten, sondern eher individuelle Aktivitäten
vorliegen. Ein UBAM Werkzeug kann hier das Individuum bei der Aufgabenbearbeitung
unterstützen. In allen flexiblen Teilbereichen von Workflowtypen, z. B. bei der Integration
von offener Teamarbeit in einen vordefinierten Workflow kann UBAM bei der Aufgaben-
bearbeitung unterstützen.
Abbildung 4-3: Aktivität als Meta-Ebene etablierter CSCW Konzepte188
Zusammenfassend lässt sich sagen, dass das UBAM Konzept sich klar von etablierten CSCW
Konzepten abgrenzen lässt. Es kann jedoch für jedes etablierte Konzept, und somit auch für
Systeme zur Unterstützung der jeweiligen Konzepte unterstützend eingesetzt werden. Denn
188 Vgl. [Moody et al. 2006], S. 688.
100
die etablierten Systeme hören oft dort auf, wo das Aktivitätenmanagement beginnt. In Bezug
auf die vielfältigen Unterstützungsmöglichkeiten kann ein UBAM Konzept als Meta-Ebene
zu etablierten Konzepten positioniert werden, die zur Koordination der Aktivitäten von
Individuen und Teams Workflows, Projekte, PIM, Wissensmanagement und ECM Ansätze im
Unternehmen in einem einheitlichen Modell zusammenführt. In Abbildung 4-3
veranschaulichen beispielsweise Moody et al. die Funktion von Aktivitäten als koordinative
Meta-Ebene zu etablierten CSCW Konzepten. Die Kontextdimension Aktivität ist damit als
orthogonal zu den in Abschnitt 3.4.4.2 genannten Basiskontextdimensionen zu betrachten. Es
handelt sich um eine spezielle Kontextdimension, die mit allen Basiskontextdimensionen in
Beziehung steht.
Das Konzept vereint die Wissensarbeit in dynamischen, inter-organisationalen Teams, für die
Selbstorganisation, Technologiekompetenz und Kooperation kennzeichnend ist. Die Not-
wendigkeit der Einbindung einer Vielfalt von existierenden Applikationen im Kontext einer
innovativen Technologie, die starke Aufgaben- und Dokumentenzentrierung sind typisch für
UBAM. Es liegen also Charakteristika vor, die soziale Vernetzung und kooperative Erstellung
und Verbesserung von Dokumenten erfordern (vgl. Abschnitt 2.3.2.4).
4.2 Nutzen von Unified Business Activity Management
Beim Aktivitätskontext handelt es sich um einen Individualkontext (vgl. Abschnitt 3.4.4.3)
dessen Explikation primär Vorteile für das Individuum zu bieten scheint. Dennoch hat die
Explikation des Aktivitätskontexts von Dokumenten verschiedene Nutzendimensionen, die
über den Nutzen für das Individuum hinaus gehen. So kann auch für das Team und die
Organisation Nutzen durch eine UBAM-Umgebung entstehen. Diese Nutzendimensionen
sollen in den folgenden Abschnitten diskutiert werden.
4.2.1 Produktivitätssteigerung
Die Struktur einer Aktivität, bestehend aus Kontextinformationen benötigter Dokumente und
den Beziehungen zwischen den Dokumenten im Kontext der Aktivität, kann sehr komplex
werden. Die kognitive Leistungsfähigkeit des Menschen ist jedoch begrenzt. Um diese
komplexen Strukturen begreifbar zu machen werden IT-Artefakte als Hilfsmittel zur Erweite-
rung der kognitiven Fähigkeiten benötigt, sie fungieren als externes Gedächtnis (vgl.
Abschnitt 2.2.1). Neben der Explikation der Kontextinformation als Ganzes ist auch das
Festhalten von Zwischenergebnissen wichtig. Dies ermöglicht die Überprüfbarkeit von
Ergebnissen und die Reflexion der Aktivitätsstruktur an sich, um etwa eine Bewertung des
Lösungsweges auf seine Effizienz vorzunehmen.
101
Bereits durch den Prozess der Explikation einer Aktivität durch ein Individuum findet eine
Optimierung statt. Da Explikation mit zusätzlicher Arbeit verbunden ist, bewertet das Indivi-
duum jede einzelne geplante Handlung in Bezug auf den Nutzen der Explikation. Ist eine
Zerlegung in Teilaktivitäten möglich und sollten diese wiederum weiter zerlegt werden?189 In
welcher Beziehung stehen Teilaktivitäten und Aufgaben zueinander? In welcher Aus-
führungsreihenfolge sollen Aufgaben bearbeitet werden, und wie sind sie zu priorisieren?
Zudem ermöglicht erst die Explikation eine Aufgabendelegation und ist daher Voraussetzung
für Arbeitsteilung im Team.
Des Weiteren ist die Möglichkeit der Reflexion Voraussetzung für eine Verbesserung der
Produktivität bei der Bearbeitung der Aktivität, denn nur Bereiche, die der Beobachtung
zugänglich sind, lassen sich messen. Nicht wahrnehmbare Bereiche entziehen sich einer
analytischen Betrachtung und damit gezielter Verbesserung. Für Reflexion und Verbesserung
ist zudem eine Distanz des Betrachters zum Gegenstand hilfreich, da „Betriebsblindheit“
häufig verhindert, dass Verbesserungspotenziale erkannt werden. Über diese Distanz verfügen
Individuen, die nicht an der Planung der Aktivität, bzw. der Explikation der Aktivitätsstruktur
selbst beteiligt sind. Die Möglichkeit der Diskussion und Kommunikation über eine komplexe
Aktivitätsstruktur, und damit auch den Ablauf der Bearbeitung, wird erst durch die Expli-
kation als IT-Artefakt ermöglicht. Selbst wenn Team-basierte Aufgabenbearbeitung nicht
notwendig sein sollte, ermöglicht die Team-basierte Reflexion einer Aktivität verschiedene
Perspektiven, Ansichten, Heuristiken und Problemlösungsstrategien über ein Thema in die
Problemlösung einfließen zu lassen und so die Lösung zu verbessern.190
Hinzu kommt die Reduktion von Rüstzeiten. Da der aktuelle Bearbeitungsstatus der Aktivität
durch die explizierte Struktur repräsentiert wird, entfällt die Zeit, nach einer Unterbrechung
(vgl. Abschnitt 3.2.5) wieder in das Thema einzusteigen. Das gilt auch für eine mögliche
Zusammenführung aller Bearbeitungswerkzeuge im Kontext der Aktivitätsstruktur. Der
Anwender nimmt die Werkzeuge nicht mehr als solche wahr, da sie nur im Kontext von
aktivitätsrelevanten Dokumenten zum Einsatz kommen. Es muss keine Situation hergestellt
werden, in der alle Werkzeuge zunächst in einen durch den Anwender benötigten Zustand
gebracht werden müssen.
Voraussetzung für einen Nutzen aus Explikation und Reflexion ist eine hinreichend große
Komplexität. Diese erscheint gegeben, wenn dem ausführenden Individuum eine Explikation
als hilfreich oder notwendig erscheint. Nutzen entsteht dann, wenn der kumulierte Aufwand
189 Vgl. [Moran 2005], S. 3.
190 Vgl. [Schmidt/Bannon 1992], S. 18.
102
aller Beteiligten für Explikation, Reflexion und n-fache Ausführung geringer ist, als der
Aufwand n-facher Ausführung ohne Explikation. Unabhängig von der Produktivitäts-
betrachtung ist die Explikation immer dann notwendig, wenn dem Individuum eine Durch-
führung ohne Explikation aufgrund der Komplexität nicht, oder nicht in der notwendigen
Qualität, möglich ist.
Im Kontext kooperativer Aufgabenbearbeitung ist es außerdem üblicherweise notwendig, eine
Explikation durchzuführen. Nur so kann die Team-basierte Aufgabenbearbeitung koordiniert
werden. Explikation im Teamkontext wird auch als „Articulation Work“ bezeichnet191. Die
Explikation ist außerdem Voraussetzung für die Managementunterstützung der Vielzahl von
Aktivitäten am kollaborativen Arbeitsplatz, mit denen der Wissensarbeiter stets konfrontiert
ist. Die für das Management, die Filterung und Sortierung notwendige Zuweisung von
aktivitätsspezifischen Meta-Daten wie Priorität, Zieldatum, vorgesehener Bearbeitungs-
zeitpunkt etc. muss im Kontext eines Verwaltungswerkzeugs erfolgen und setzt die vorherige
Explikation voraus.
Ebenso zur Produktivitätssteigerung kann ein verbessertes Zeitmanagement beitragen. Zeit-
management ist ein populäres Publikationsfeld in einer Arbeitsgesellschaft, in der Effizienz
und die Organisation einer Vielzahl von Aufgaben zum Alltag gehören. Vielbeachtet im
deutschsprachigen Raum sind Publikationen von Lothar Seiwert192, international sehr erfolg-
reich ist etwa David Allen193. Gemeinsam ist vielen Zeitmanagement-Konzepten die
Notwendigkeit der Explikation und Klassifizierung von Aufgaben. Durch die Unterstützung
von Zeitmanagement-Konzepten kann UBAM also ebenso zu Produktivitätssteigerungen
beitragen.
4.2.2 Unterstützung der organisationalen Wissensmanagement Prozesse
Durch die Explikation einer Aktivität als Aktivitätsstruktur entsteht ein kognitives Artefakt.
Norman verdeutlicht die Bedeutung dieses Artefakts am Beispiel einer Checkliste, die Piloten
vor Flugbeginn und während jeder kritischen Phase eines Fluges einsetzen.194 Die Checkliste
verbessert die Durchführungsqualität der Aktivität so deutlich, dass ihre Verwendung interna-
tional gesetzlich vorgeschrieben ist. Durch die Existenz dieses Artefakts entstehen zwei
unterschiedliche Sichtweisen der Aktivität, die individuelle Sicht und die Systemsicht. Als
Systemsicht wird die die Sichtweise eines Außenstehenden bezeichnet, der eine Situation
191 Vgl. [Schmidt/Bannon 1992], S. 18ff.
192 Vgl. etwa [Seiwert 2002].
193 Vgl. [Allen 2003].
194 Vgl. [Norman 1991], S. 20f.
103
beobachtet. Aus Systemsicht verbessert die Checkliste die Gedächtnisleistung des Piloten und
stellt somit eine hohe Qualität der Aufgabendurchführung sicher.
Aus der individuellen Sicht hingegen verändert die Checkliste die Aufgabe an sich. Bestand
die Aufgabe ohne die Checkliste in der Überprüfung des Flugzeugs auf Flugtauglichkeit, ist
die Aufgabe nun das Lesen und Interpretieren der Anweisungen auf der Checkliste. Planung
und Erinnerung, was zu tun ist wurden bereits vor der Verwendung der Liste durchgeführt.
Außerdem wurde die Checkliste durch eine Vielzahl von Experten in einem Jahre dauernden
Prozess verbessert. Dieser Prozess stellt im Sinne der Tätigkeitstheorie das Prinzip der
Entwicklung als permanenten Prozess des Sammelns von individuellen und kollektiven
Erfahrungen dar (vgl. Abschnitt 2.4.2 Punkt 5).
Norman bezeichnet diese Verteilung der kognitiven Leistung auf einen vorgelagerten Zeit-
raum mit ggf. mehreren Beteiligten als Vorausberechnung (engl. „Precomputation“). Voraus-
berechnung führt dazu, dass die notwendige kognitive Leistung eines Wissensträgers zur
Durchführung von wissensintensiven Tätigkeiten reduziert und gleichzeitig die Durch-
führungsqualität der Tätigkeit durch fortlaufende Optimierung unter Beteiligung von Experten
verbessert wird. Die Möglichkeit, kognitive Artefakte zu erschaffen ist eine Voraussetzung
für Vorausberechnung. Sie unterstützen als Informationsträger explizierten Wissens die
organisationalen Wissensmanagement Prozesse (vgl. Abschnitt 2.3.2.3).
Explizierte Aktivitätsstrukturen können Checklisten sein, oder diese enthalten. Sie können
Vorgehensweisen repräsentieren und als kognitives Artefakt Vorausberechnung ermöglichen.
Sie unterstützen somit die organisationalen Wissensmanagement Prozesse. Die Existenz von
Vorlagen für am jeweiligen kollaborativen Arbeitsplatz typische Aktivitätsstrukturen kann
somit die kognitive Wissensarbeit erleichtern und zu Qualitätsverbesserungen bei der Auf-
gabenbearbeitung führen.
Nutzen zur Unterstützung der organisationalen Wissensmanagement Prozesse entsteht nur,
wenn die Aktivität hinreichend komplex ist, dass sich der zusätzliche Aufwand für Voraus-
berechnung lohnt. Der Prozess der Vorausberechnung selbst erfordert üblicherweise einen
höheren Aufwand als die einmalige Durchführung einer Aktivität ohne Checkliste. Die
Erwartung der Notwendigkeit der Durchführung ähnlicher Tätigkeiten in zeitlicher Nähe ist
Voraussetzung für das Eintreten des Nutzens. Zeitliche Nähe ist daher sinnvoll, da das kogni-
tive Artefakt, damit der Anwender sich darauf verlassen kann, stets aktuell gehalten werden
muss. Am Beispiel der Pilotencheckliste wird deutlich, dass die Checkliste sowohl an techn-
ische Innovationen, wie auch an sich ändernde gesetzliche Bestimmungen angepasst werden
104
muss. Für diese Aktualisierung und Pflege entsteht Aufwand der sich nur dann auszahlt, wenn
eine hinreichend große Ausführungshäufigkeit oder Qualitätsverbesserung zu erwarten ist.
Ein weiterhin erhöhter Aufwand entsteht durch die Entwicklung einer intersubjektiv konsens-
fähigen Struktur. Wie bereits in Abschnitt 3.2.4 beschrieben können sich individuelle
Ordnungssystematiken für ähnliche Informationsräume stark voneinander unterscheiden. Soll
eine Vorlage mehrfach von unterschiedlichen Individuen verwendet werden, muss ein sinn-
voller Konsens aus einer Vielzahl möglicher Strukturierungssystematiken gefunden werden.
Außerdem ist ein präzises Beschreiben von Vorgängen notwendig, das über den Detailgrad
individueller Explikationsbedürfnisse deutlich hinausgeht.
Wurden ähnliche Aktivitäten häufiger ausgeführt, können sie zudem Gegenstand systemati-
scher Analysen sein. Durch Abstraktion von konkreten Aktivitätsstruktur-Instanzen kann eine
Vorlage generiert werden, die als Ausgangsstruktur für neue Aktivitäten dient. Dies gestaltet
die Bearbeitung ähnlicher Aktivitäten produktiver. Wird die Explikation zudem strukturiert
abgelegt, kann sie auch durch weitere Mitarbeiter genutzt werden, für die sie relevant ist.
Ähnlich wie die Checklisten zeigt die Struktur, welche Tätigkeiten und Abläufe notwendig
sein können, und welche Dokumente benötigt werden, um eine ähnliche Aktivität zu bearbei-
ten. Es ist auch möglich, dass durch eine Analyse Aktivitäten als strukturierte oder
strukturierbare Workflows erkannt werden. Diesen Ansatz des partizipativen Workflow-
designs beschreibt Huth in seiner Arbeit über Ad-hoc-Workflowmanagement.195 Ebenso
können Aktivitätsstrukturen Grundlage für die Entwicklung von Strukturierungsvorlagen für
Projekte sein, etwa um ein Projektmanagement Handbuch zu erstellen.
Wenn Vorlagen von Aktivitätsstrukturen zentral zur Verfügung gestellt werden, wird die
repetitive Aufgabe der Explikation durch Vorausberechnung auf den Zeitpunkt vor der
Aufgabenausführung verlagert. Der kognitive Aufwand zur Entwicklung der Vorgehensweise
entsteht somit nur einmal. Explizierte Aktivitätsstrukturen können also als Produktions-
faktoren betrachtet werden. So kann der Einsatz einer Vorlage durch Vorausberechnung nicht
nur die Qualität eines Produktionsprozesses erhöhen, sondern auch die Effizienz. Dies gilt
dann, wenn der Arbeitsaufwand, der für die Vorausberechnung anfällt geringer ist, als der
kumulierte Anteil der durch Vorausberechnung gesparten Zeit der Bearbeitung ähnlicher
Aktivitäten pro Wiederholung (vgl. Abschnitt 3.1.1).
195 Vgl. [Huth 2004].
105
4.2.3 Kostensenkung
Am kollaborative Arbeitsplatz findet bei jeder Teamaktivität eine Transaktion im Sinne der
Transaktionskostentheorie statt. Zudem werden mit den Aktivitäten häufig nicht originär
eigene Bedürfnisse des jeweiligen Wissensarbeiters befriedigt, sondern er bearbeitet diese
Aktivitäten um in einer Principal-Agent-Beziehung eine Vorleistung für eine andere Person
bereitzustellen. Die Gestalt der Software-Werkzeuge und der organisationalen Regeln am
kollaborativen Arbeitsplatz haben maßgeblichen Einfluss auf die Transaktionskosten.
Andersherum betrachtet kann durch eine Ausrichtung und Gestaltung der Regeln und der
Technologie am kollaborativen Arbeitsplatz eine möglichst Transaktionskosten-effiziente
Situation geschaffen werden.
Durch die Nutzung eines UBAM Werkzeugs und die damit einhergehende Explikation von
Aktivitätsstrukturen besteht so das Potenzial zur Senkung mehrerer Transaktionskostenarten
(vgl. Abschnitt 2.1.2). So wird die Senkung von Kontrollkosten durch verbesserte Trans-
parenz bei der Aktivitätsbearbeitung durch verbesserte Verfügbarkeit von Status-
informationen etwa über den Stand der Bearbeitung ermöglicht. Durch die Optimierung der
Koordination der Aufgabenbearbeitung können die Abwicklungskosten verringert werden.
Auch Suchkosten können reduziert werden, z. B. wenn die Suche nach Informationen entfällt,
etwa weil relevante Dokumente über die explizierte Aktivitätsstruktur direkt zum Zugriff
bereitstehen. Außerdem kann durch die effiziente Bereitstellung von Informationen im
Kontext der Aktivität Transaktionsunsicherheit reduziert werden.
Im Kontext von Aktivitäten ist eine Vielzahl unterschiedlicher Organisationsformen relevant,
da an der Bearbeitung von Aktivitäten sowohl mehrere Personen innerhalb eines Unter-
nehmens als auch zwischen Unternehmen beteiligt sein können (vgl. Abschnitt 3.2.2). Dies ist
z. B. der Fall, wenn häufig mit Partnern, Zulieferern oder Kunden zusammen gearbeitet wird.
Dabei wird versucht, eine verbesserte Nutzung und Vernetzung der Fülle vorhandener
Informationsressourcen, organisationalem Gedächtnis und individuellem Wissen der Mitar-
beiter herbeizuführen. Dies dient der Senkung sowohl von Messkosten bei der Bewertung von
Informationen, von Kosten für die Informationsbeschaffung als auch von Kommunikations-
kosten im Allgemeinen.
Voraussetzung für die Senkung von Transaktionskosten durch UBAM ist erneut eine hin-
reichend große Komplexität, oder eine hinreichend hohe Transaktionshäufigkeit in Bezug auf
ähnliche Transaktionen zwischen den Teammitgliedern. Für einmalige Transaktionen geringer
Komplexität zwischen Individuen werden die Kosten für die Identifikation, Implementierung
106
und Einarbeitung in eine geeignete Infrastruktur für Aktivitätenmanagement höher sein als
das Einsparpotential. Der Einsatz wäre daher ökonomisch nicht sinnvoll.
4.2.4 Linderung des Agenturproblems
In Abschnitt 2.1.3 wurde mit der Agenturtheorie ein Erklärungsansatz für Beziehungen
zwischen Auftraggeber (Principal) und Auftragnehmer (Agent) in arbeitsteiligen Aktivitäten
dargestellt. In der Principal-Agent-Beziehung ist der Principal über das Verhalten des
Agenten grundsätzlich unvollkommen informiert. Dies gilt insbesondere in räumlich verteil-
ten Teams.196 Die Informationsasymmetrie eröffnet Spielraum für opportunistisches
Verhalten des Agenten. Durch Informationstechnologie kann die Asymmetrie gelindert
werden, indem z. B. mehr Informationen über die Tätigkeiten des Agenten und den
Bearbeitungsstatus von Aufgaben zur Verfügung stehen.
Durch die Explikation von Inhalten werden, entsprechende Zugriffsmechanismen vorausge-
setzt, Aktivitäten des Auftragnehmers (Mitarbeiter) durch den Auftraggeber (Vorgesetzter)
besser beobachtbar. Somit besteht weniger Spielraum für opportunistisches Verhalten, was
sich positiv auf die Produktivität des Mitarbeiters auswirken kann und dann einen Nutzen für
das Unternehmen darstellt. Auch die Möglichkeit des verbesserten Zugriffs auf Statusinfor-
mationen von Aktivitäten und Aufgaben kann einen Nutzen darstellen, da die Auskunfts-
fähigkeit des Unternehmens verbessert wird, etwa wenn der Ansprechpartner nicht verfügbar
ist. Dies kann z. B. zur Steigerung der Kundenzufriedenheit beitragen.
Auch aus Mitarbeitersicht kann der Abbau der Informationsasymmetrie Nutzen stiften. Viele
Tätigkeiten, die Mitarbeiter erledigen, werden von Vorgesetzten nicht bewusst wahr-
genommen. Auch dies gilt insbesondere für räumlich verteilte Teams. Durch Explikation
entsteht Transparenz bei der Bearbeitung von Aufgaben und Vorgesetzte können den Arbeits-
fortschritt verfolgen. Durch die verbesserte Wahrnehmung der eigenen Tätigkeiten durch
Vorgesetzte kann der Mitarbeiter seine Reputation verbessern. Zudem kann durch Tätigkeits-
bereiche, die sich der Wahrnehmung zuvor verschlossen haben, eine bessere Profilierung
herausbilden. Der beschriebene Nutzen entsteht dabei nur, wenn der Mitarbeiter Reputation
und Profilierung als erstrebenswert ansieht. Bevorzugt er Shirking (vgl. Abschnitt 2.1.3) hat
er hingegen ein Interesse, die Informationsasymmetrie aufrecht zu erhalten.
196 Durch die „ […] räumlich de-zentralisierte Aufgabenerfüllung (Telekooperation) nehmen
Informationsasymmetrien, vor allem das Hidden-action-Problem, zwischen Principal und Agent drastisch
zu“. Vgl. [Picot/Reichwald/Wigand 2003], S. 60.
107
4.3 Explikation des Aktivitätskontextes
Die bisherigen Kapitel stellen eine Bestandsaufnahme der für den Kontext der Arbeit rele-
vanten Aspekte dar, sowie erste daraus abgeleitete Folgerungen. Dies sind zunächst die
Feststellung der Forschungs- und Praxislücke sowie eine Festelegung der Begrifflichkeiten
des Betrachtungsgegenstands von UBAM. Die darauf folgende Beschreibung möglicher
Nutzendimensionen eines UBAM Werkzeugs zeigt dass es sinnvoll ist, das Thema für den
Praxiseinsatz aufzubereiten. Aus den bereits dargelegten Abschnitten sollen nun zunächst die
wichtigsten Annahmen hergeleitet werden, welche die Grundlage für den Konzeptentwurf
bilden. Wichtigstes Ziel ist dabei eine geeignete Explikation der Aktivitätsstrukturen, die wie
bereits mehrfach festgestellt Voraussetzung für die Bereitstellung von Management Funktio-
nalitäten ist.
4.3.1 Anwendung der Tätigkeitstheorie
Nachdem der Betrachtungsgegenstand sowie der Nutzen eine UBAM Frameworks diskutiert
wurden, soll ein Überblick gegeben werden, wie die Tätigkeitstheorie in Beziehung zu den
Konzepten des Aktivitätenmanagements steht. Dazu werden in Tabelle 4-1 die grundlegenden
Prinzipien der Tätigkeitstheorie den vorgestellten UBAM Konzepten und Begrifflichkeiten
gegenüber gestellt. Die Transformation von Objekten erfolgt etwa durch die Bearbeitung,
Kontextualisierung oder Rezeption von Dokumenten durch den Wissensarbeiter mithilfe einer
Applikation. Die Bearbeitung von Aufgaben am kollaborativen Arbeitsplatz erfolgt im
Kontext von Aktivitäten. Da die Explikation von Operationen ökonomisch nicht sinnvoll ist,
weil sie unbewusst durchgeführt werden und somit für Managementfunktionalitäten keine
Relevanz haben, werden sie nicht betrachtet.
Erklärung der Prinzips Anwendung auf Kontext der Arbeit
Objekt-Orientiertheit Subjekt transformiert Objekt oder
Artefakt.
Anwender am kollaborativen Arbeits-
platz bearbeitet Dokumente.
Hierarchische Struktur
von Tätigkeiten Tätigkeit, Handlung und Operation. Aktivität, Teilaktivität und Aufgabe.
Operationen werden nicht betrachtet.
Internalisierung und
Externalisierung Permanente Wirklichkeitsprüfung
durch Transformation von internalen
Tätigkeiten zu externalen Tätigkeiten
und umgekehrt zum Zweck der
Reflexion.
Explikation der Struktur von
Aktivitäten und Internalisierung
explizierter Aktivitätsstrukturen.
Vermittlung Werkzeuge als Mediatoren zwischen
Subjekt und Objekt.
Lesen und Bearbeiten von Dokumenten
mithilfe von Applikationen.
Entwicklung Entwicklung als permanenter Prozess
des Sammelns von Erfahrungen unter
Berücksichtigung sozio-kultureller
Rahmenbedingungen.
Entwicklung durch die Möglichkeit der
Reflexion, Optimierung und Mehr-
fachnutzung von Aktivitätsstrukturen
in Form von Vorlagen.
Tabelle 4-1: Anwendung der Prinzipien der Tätigkeitstheorie auf den Kontext der Arbeit
108
Der Externalisierungsprozess wird durch ein UBAM Werkzeug unterstützt, indem der An-
wender befähigt wird, ein mentales Modell einer Aktivität zu explizieren, so dass es für
Managementfunktionalitäten und Optimierung der Bearbeitung zugänglich wird. Stehen
Vorlagen für Aktivitäten zur Verfügung, oder trifft der Anwender auf Aktivitäten, die durch
Dritte expliziert wurden, findet der Internalisierungsprozess statt. Bei der Bearbeitung von
Aufgaben stehen beide Prozesse in ständiger Wechselwirkung. Da Dokumente in Repositories
dem Anwender nur durch Applikationen zugänglich sind, ist am kollaborativen Arbeitsplatz
das Werkzeug Applikation als Mediator unumgänglich. Der Zugriff auf, und die Bearbeitung
von Dokumenten erfolgt durch Applikationen.
Der sozio-kulturelle Entwicklungsprozess schreitet voran, da UBAM die Wissenskonstruktion
unterstützt (vgl. Abschnitt 4.2.2). Durch das Ausführen, Üben, und Diskutieren von
Tätigkeiten im Team wird die Reflexion von Aktivitäten ermöglicht und es können Verbesse-
rungen erzielt werden, z. B. durch Verbesserung der Fertigkeiten des Wissensarbeiters oder
der Verbesserung von durch Aktivitätsstrukturen repräsentierten Prozessen. Durch Übung
werden außerdem Handlungen durch Transformation zu Operationen effizienter. Nach
wiederholter Ausführung ähnlicher Aktivitäten kann also z. B. der Explikationsaufwand
geringer werden, da die Granularität der Explikation nicht mehr so detailliert erfolgen muss,
wie bei der erstmaligen Ausführung.
4.3.2 Elemente einer Aktivitätsstruktur
In Abbildung 4-1 wurde beispielhaft ein mögliches Ergebnis der Projektion einer Aktivität
schematisch dargestellt. In diesem Abschnitt sollen weitere mögliche Elemente der Struktur
einer Aktivität eingeführt werden. So ist das Dokument eine essenzielle Ressource bei der
Aufgabenbearbeitung am kollaborativen Arbeitsplatz. Da die Dokumente üblicherweise in
einem oder mehreren Repositories außerhalb des UBAM Werkzeugs abgelegt sind, muss für
die benötigten Dokumente ein Aktivitätskontext (vgl. Abschnitt 3.4.4.3) expliziert werden,
um einen direkten und effizienten Zugriff zu ermöglichen. Der Aktivitätskontext eines
Dokuments beschreibt, dass ein Dokument eine Bedeutung im Kontext einer Aktivität hat,
und ggf. welche Bedeutung das Dokument für die Aktivität hat. So kann es sein dass Doku-
mente erstellt oder bearbeitet werden müssen, oder lediglich als Informationsressource
vorgesehen sind.
Die Explikation des Aktivitätskontexts eines Dokuments, im Folgenden verkürzt als Aktivi-
tätskontext bezeichnet, erfolgt über eine Dokumentenverknüpfung. Dabei kann es sich um ein
Kontext-Datum (vgl. Abschnitt 2.2.2.4) des Dokuments, um ein Kontext-Datum der
109
Aktivitätsstruktur oder um ein Kontext-Datum eines Elements der Aktivitätsstruktur handeln.
Je nach technischer Umsetzung können auch Kombinationen der Fälle eintreten. Die mehr-
fache Speicherung eines Datenfeldes wird als redundante Speicherung bezeichnet. Statt eine
oder mehrere Verknüpfungen auf konkrete Dokumente zu speichern, können auch
dynamische Verknüpfungen oder Verknüpfungslisten gespeichert werden. Hier wird der
Aktivitätskontext dynamisch durch eine Abfrage (Query) berechnet. Besteht das Ergebnis der
Abfrage aus mehr als einem Dokument, weisen alle Dokumente den gleichen Aktivitäts-
kontext auf. Beispiele für eine Abfrage sind eine Suche nach Dokumenten, der Aufruf eines
Webservice, der als Ergebnis eine Verknüpfungsmenge liefert, oder der Aufruf eines News-
feeds.
Des Weiteren kann ein regelbasierter Aktivitätskontext beschrieben werden. Ein regelbasierter
Kontext wird durch das UBAM System automatisiert erzeugt. Es stellt dabei Verknüpfungen
zu Dokumenten zur Verfügung, die eine Relevanz für die Aufgabenbearbeitung innerhalb der
Aktivität haben könnten. Die Relevanz kann z. B. durch gemeinsame Geschäftsprozess-
kontexte (vgl. Abschnitt 3.4.4.2), inhaltliche Verwandtschaft, oder die Übereinstimmung von
Meta-Daten begründet sein. Weist beispielsweise ein Diskussionsdokument einen expliziten
Aktivitätskontext auf, der sich auf Aktivität A1’ bezieht, so weisen alle Antwortdokumente
auf den Diskussionsbeitrag mit A1’ einen impliziten Aktivitätskontext auf.
Es handelt sich hier um eine inhaltliche Verwandtschaft, aufgrund der Diskussion eines
gemeinsamen Themas. Es handelt sich aber auch um eine Übereinstimmung von Meta-Daten,
da alle Dokumente das gleiche Hauptdokument aufweisen. Ein weiteres Beispiel für die
Übereinstimmung von Meta-Daten ist eine Menge von Dokumenten, die vom gleichen Autor
erstellt wurden. Ein gemeinsamer Geschäftsprozesskontext liegt vor, wenn sich beispielsweise
Dokumente im gleichen Workflow befinden, oder für das gleiche Projekt Relevanz haben.
Wichtig ist jedoch, dass die Aktivitätsstruktur nicht ausschließlich berechnete Aktivitäts-
kontexte enthält. Kaptelinin etwa merkt an, dass das manuelle Hinzufügen von Kontext-
informationen in der Regel schneller durch den Anwender durchzuführen ist als die Definition
von Selektionskriterien, welche im Ergebnis die gleiche Information liefern197. Implizite
Kontexte haben ihre Stärke also in dem Bereich, wo der Anwender sich nicht mit dem Zugriff
auf ein bestimmtes Dokument auseinandersetzt, sondern mit einer thematisch zusammen-
gehörigen Dokumentenkollektion, oder der Erschließung eines neuen, ihm noch unbekannten
Themengebiets, welche er ohnehin durch eine Suche beginnen würde.
197 Vgl. [Kaptelinin 2003], S. 354f.
110
Der Aktivitätskontext eines Dokuments kann an jeder Stelle in der Aktivitätsstruktur ange-
ordnet werden. So kann es beispielsweise sinnvoll sein, Dokumente mit Hintergrund-
informationen zur gesamten Aktivität direkt der Aktivität zuzuordnen. Dokumente mit
spezifischeren Informationen, wie Relevanz für eine Teilaktivität oder eine bestimmte Auf-
gabe, können dem entsprechenden Element in der Aktivitätsstruktur direkt zugeordnet wer-
den. Auch wenn sich jede Aufgabe definitionsgemäß auf ein Dokument bezieht ist es in
Bezug auf den Praxiseinsatz wichtig, die Dokumentenzuordnung flexibel zu halten und für
Aufgaben nicht verpflichtend zu machen. Auch können sich mehrere Aufgaben auf das
gleiche Dokument beziehen, so dass eine verpflichtende Zuordnung nicht sinnvoll ist.
Dementsprechend gilt, dass jedem Element der Aktivitätsstruktur eine Anzahl von n>=0
Aktivitätskontexte zugewiesen werden können.
Abbildung 4-4: Beispiel für eine Aktivitätsstruktur mit expliziten Aktivitätskontexten
Abbildung 4-4 zeigt beispielhaft eine Aktivitätsstruktur als Sicht auf die Aktivitätskontexte
von Dokumenten, die im Zuge der Bearbeitung der Aktivität Relevanz haben. Beispielsweise
repräsentiert Aktivitätskontext K4 den Aktivitätskontext des Dokuments D4 in Bezug auf
Aktivität A1’. Die Abbildung illustriert außerdem, dass Dokumente in verschiedenen Repo-
sitories gespeichert sein können. Auch ist es möglich, Aktivitätskontexte an beliebigen Stellen
in der Aktivitätsstruktur hinzuzufügen, auch unterhalb eines anderen Aktivitätskontexts.
Zudem besteht die Möglichkeit, dass ein Dokument mehrere Aktivitätskontexte aufweist
(D1).
111
Abbildung 4-5: Projektion zweier Aktivitäten mit gemeinsamer Teilaktivität
Kontexte können generell Beziehungen untereinander aufweisen. Diese Beziehungen können
hierarchischer Natur sein, oder auch eine Netzstruktur aufweisen. Beispiel für eine hierarchi-
sche Kontextbeziehung ist die Beziehung der Dokumenttypen Adresse, Person und Organisa-
tion in Bezug auf ihren Korrespondenzkontext. Die Adresse gehört zu einer Person, eine
Person ist Teil einer Organisation. Oder etwa ein Teilprojekt, das Teil eines übergeordneten
Projekts ist. Analog zu den genannten Beispielen bestehen auch Aktivitäten aus Teilaktivitä-
ten. Eine Teilaktivität kann auch Teil einer anderen Aktivität sein. Abbildung 4-5 zeigt die
Struktur zweier Aktivitäten A1 und A2 aus Sicht eines Anwenders P1. Teilaktivität T2 ist in
beiden Aktivitäten enthalten, der Aktivitätskontext der beteiligten Dokumente bezieht sich in
diesem Fall also auf die Zugehörigkeit zu einer Teilaktivität.
4.3.3 Individualität der Aktivitätsstruktur
Die Projektion einer Aktivität zum Zweck der Explikation erfolgt stets durch ein Individuum.
Daher ist die Aktivitätsstruktur stets durch dieses Individuum subjektiv geprägt und weicht im
Regelfall von der Wahrnehmung der gleichen Aktivität durch andere Personen ab. Zwei
Personen würde also die gleiche Aktivität in Form unterschiedlicher Aktivitätsstrukturen
projizieren. Dies liegt in der Definition von Aktivitäten begründet. Die Empfindung von
Atomizität ist individuell unterschiedlich (vgl. Abschnitt 4.1.1). Für Anwender P1 kann das
Schreiben einer E-Mail eine Aktivität oder eine Teilaktivität sein, während es für Anwender
P2 eine Aufgabe ist (vgl. Abschnitt 2.4.2).
Dies führt auch dazu, dass sich üblicherweise die Granularität der Strukturexplikationen
unterscheidet. Neben der Granularität ist auch der Grad der Vorausplanung individuell und
112
hängt von persönlichen Vorlieben und Arbeitsweisen ab. Beispielsweise wird ein Individuum,
das eine ähnliche Aktivität bereits mehrfach durchgeführt hat, eine Aktivität detailliert mit
allen Aufgaben vorausplanen, während ein Individuum, das eine ähnlichen Aktivität niemals
zuvor durchgeführt hat, noch gar nicht alle Aufgaben kennt, und daher zunächst nur eine
grobe Strukturierung durchführt und Details im Verlauf der Aktivitätsbearbeitung entwickelt.
Das Phänomen unterschiedlicher Sichtweisen wird als Vielstimmigkeit bezeichnet (vgl.
Abschnitt 3.2.4). Einflussfaktoren sind Erfahrung, sozialer, kultureller und fachlicher Hinter-
grund, Persönlichkeit und unterschiedliche Einstellungen innerhalb eines sozialen Systems.
Abbildung 4-6: Unterschiedliche Projektion einer Aktivität durch zwei Individuen
Hinzu kommt, dass im Kontext einer Teamaktivität, unterschiedliche Individuen auch unter-
schiedliche Teilaktivitäten oder Aufgaben zu bearbeiten haben. Bei der Explikation der
Aktivität werden daher häufig Bereiche nicht oder mit geringerer Granularität expliziert, die
von anderen Personen bearbeitet werden müssen. Abbildung 4-6 zeigt ein Beispiel für
verschiedene Projektionen A1’ und A1’’ durch zwei Individuen P1 und P2 der gleichen
Aktivität A1. Die Strukturen weisen unterschiedliche Teilaktivitäten auf. Außerdem wurde
Teilaktivität T1 verschieden granular expliziert. Durch Betrachtung der Explikation kann der
Grund für die unterschiedliche Explikation nicht erkannt werden. Es kann also sein, dass der
Unterschied in unterschiedlichen Aufgaben begründet ist, oder aufgrund der Individualität der
Explikation entstanden ist.
4.3.4 Unterstützung von Teamaktivitäten
Eine Person kann in einer unbekannten hierarchischen Struktur besonders effizient navigieren,
wenn sie bereits auf einer Navigationsebene nahe der Wurzel, hier also z. B. bei der Defini-
113
tion der ersten Ebene von Teilaktivitäten, erahnen kann, in welcher Teilstruktur sich die
gesuchte Information befindet. Diese Ahnung wird als Information Scent bezeichnet.198 Wie
in Abschnitt 4.3.3 beschrieben resultiert die Explikation von Aktivitäten in einer individuell
spezifischen Projektion. Auch der Grad der Vorausplanung und die Granularität der Planung
sind individuell abgestimmt. In diesem Kontext ist Information Scent nicht relevant, da der
Anwender die Struktur bereits kennt, und so jederzeit zum Ziel gelangen kann.
Die Explikation ermöglicht es, eine Aktivität im Team koordinieren zu können. Die für die
Aktivität verantwortliche Person beginnt mit der Erstellung einer Aktivitätsstruktur oder
beauftragt die Erstellung. Die Struktur der Teamaktivität entsteht also ausgehend von einer
individuellen Aktivitätsstruktur. Dabei unterscheiden sich die Strukturen von Aktivitäten, die
zunächst über einen längeren Zeitraum als individuelle Aktivitäten existiert haben, und
Aktivitäten, deren Durchführung von vornherein als Teamaktivität absehbar ist. Im ersten Fall
wird üblicherweise die zuvor beschriebene Struktur vorliegen, die auf die Arbeitsweise des
Individuums optimiert ist. Diese muss durch Detaillierung und Umstrukturierung in eine
Form gebracht werden, die für die Nutzung im Team geeignet ist. Dabei sollte Information
Scent berücksichtigt werden.
Das Individuum neigt dazu, weniger Details zu explizieren, und Aufgaben nicht so umfang-
reich zu beschreiben, wie es beispielsweise für die Delegation von Aufgaben notwendig ist.
Der Grund liegt darin, dass das Individuum für von ihm selbst explizierte Strukturelemente
genau weiß, was gemeint ist. Wenn eine weitere Person die explizierte Information wahr-
nimmt, wird sie durch Interpretation in einen vollständig neuen Bedeutungszusammenhang
gestellt. Um Missverständnissen vorzubeugen, muss hier viel detaillierter beschrieben wer-
den, was gemeint ist, als wenn sich ein Individuum eine Notiz für eine Aufgabe macht.199 Vor
der Umwandlung in eine Teamaktivität muss der Ersteller der Struktur also die Struktur für
eine Teambearbeitung vorbereiten, wenn er vermeiden will, dass es zu Missverständnissen,
Mehrarbeit oder fehlerhafter Ausführung von Aufgaben kommen kann. Ist die Aktivität von
vornherein als Teamaktivität angelegt, kann der Ersteller diese Anforderungen von Anfang an
berücksichtigen.
Um Teamarbeit zu ermöglichen ist es zweckmäßig, dass es mindestens eine Aktivitätsstruktur
gibt, die für alle Beteiligten gleich aussieht, damit an dieser Koordination, Kommunikation
198 Vgl. [Pirolli/Card/van der Wege 2000].
199 Vgl. [Schmidt/Bannon 1992], S. 27ff für Ausführungen zur Interpretation von Daten in Teams.
114
und Diskussion über einzelne Aufgaben oder Teilaktivitäten stattfinden kann.200 Die Pflege
dieser gemeinsamen Aktivitätsstruktur kann durch eine Person erfolgen. Sie kann aber auch
kollaborativ, ohne einen explizit Verantwortlichen, erfolgen. Personen, welche die Struktur
einer Aktivität modifizieren werden als Struktureditoren bezeichnet.
Damit alle Teammitglieder effizient mit der Aktivitätsstruktur arbeiten können, müssen die
Struktureditoren versuchen, einen intersubjektiven Konsens über die Struktur im Team
herzustellen oder zu antizipieren. Der Editor muss also berücksichtigen, wie individuelle
Projektionen der Aktivität aussehen könnten oder die individuellen Projektionen erfragen, und
die Vielzahl der Strukturen so zusammenführen, dass sich jedes Teammitglied in der resultie-
renden Struktur zurecht findet. Diese Aufgabe setzt Einfühlungsvermögen und eine gute
Kenntnis sowohl der Teamstruktur, als auch der Persönlichkeitsstrukturen im Team voraus.
Der Struktureditor sollte also Teil des Teams, oder eine dem Team organisational nahe Person
sein.
Aufgrund der hohen Anforderungen an das Qualifikationsprofil des Struktureditors kann es
auch sinnvoll sein, dass Personen mit diesen speziellen Fähigkeiten für häufig vorkommende
Aktivitäten Vorlagen entwickeln, und diese den Mitarbeitern des Unternehmens als Richtlinie
oder Aktivitätshandbuch zur Verfügung stellen. Von teaminternen Struktureditoren werden
diese Vorlagen dann lediglich an die Teamstruktur und die individuelle Aktivitätsinstanz
angepasst.
4.4 Funktionale Anforderungsanalyse
Im Rahmen dieses Unterkapitels wird eine Auswahl der funktionalen Anforderungen be-
trachtet, die sich nicht unmittelbar aus den Argumentationslinien der vorangegangenen
Kapitel ergeben, und die daher einer weiteren Herleitung bedürfen.
4.4.1 Effizienz
Ziel des Entwurfs eines UBAM Werkzeugs ist es, das zentrale Arbeitswerkzeug am kollabo-
rativen Arbeitsplatz zu konzipieren. Es ist daher sehr wichtig, dass der Prozess der Explika-
tion von Aktivitätsstrukturen sowie die Navigation und Handhabung von existierenden
Aktivitätsstrukturen sehr effizient möglich sind. Eine effiziente Handhabung erhöht die
Produktivität und die Anwenderakzeptanz. Eine Möglichkeit, Effizienz zu gewährleisten ist
es, die Nutzung neu entwickelter Werkzeuge nach dem Prinzip der Entwicklung in der
200 Eine Ausnahme ist, wenn Teile der Aktivitätsstruktur Zugriffsbeschränkungen unterliegen. Dann liegt
lediglich Ähnlichkeit vor, nicht jedoch Gleichheit der Sichten auf die Struktur. Dieser Fall bleibt hier
zunächst unberücksichtigt. Er stellt eine funktionale Anforderung dar und wird in Unterkapitel 4.4 diskutiert.
115
Tätigkeitstheorie möglichst eng an bereits bewährten und durch eine Vielzahl der Anwender
bereits erlernten Paradigmen zu orientieren.
Effizienz kann durch eine Vielzahl an Maßnahmen erreicht werden kann, etwa durch Opti-
mierung von Dialogen, der Einführung von Tastaturkürzeln für erfahrene Anwender, oder der
Verkürzung von Navigationspfaden. Ein Resultat aus der Effizienzforderung ist die Sekundär-
forderung nach evolutionärer Entwicklung der Werkzeuge. Die Entwicklung soll also an
heute vorherrschenden, etablierten Werkzeugen und Konzepten orientiert sein.
4.4.2 Darstellung von Aktivitäten
Da der Wissensarbeiter stets mehrere Aktivitäten parallel in Bearbeitung hat, müssen die
Strukturen mehrerer Aktivitäten ggf. gleichzeitig verwaltet werden können. Zunächst liegt
also eine Liste von Aktivitätsstrukturen vor, die zu visualisieren sind. Sowohl Teilaktivitäten,
als auch Aktivitäten können zudem untereinander in Beziehung stehen. Abbildung 4-7 zeigt
ein Beispiel. Teilaktivität T2 wird für den Wissensarbeiter P1 aus seiner Sicht zu einem Teil
der gerade bearbeiteten Aktivität A1’. Diese Aktivität A1’ wird aus Sicht von P1 als Primär-
aktivität bezeichnet. Für den Anwender ist sowohl die Art der technischen Speicherung
verknüpfter Teilaktivitäten, als auch die Teilaktivität beinhaltende Aktivität A2’ üblicher-
weise nicht unmittelbar relevant und dient lediglich als zusätzliche Kontextinformation zur
Bewertung und zum Verständnis der Teilaktivität.
Abbildung 4-7: Aktivitäten mit verknüpfter Teilaktivität
Die Beziehung von Aktivitäten und Teilaktivitäten kann jeweils durch eine Verknüpfung
abgebildet werden. In der Gesamtheit betrachtet entsteht aus den Verknüpfungen ein
Beziehungsnetzwerk. Zur Visualisierung können daher Technologien zur Visualisierung von
116
Netzwerken zum Einsatz kommen, falls geeignete Konzepte zur Verfügung stehen und auf
Anwenderakzeptanz stoßen. Zum Zeitpunkt der Veröffentlichung dieser Arbeit liegt kein
allgemein akzeptiertes Konzept oder Werkzeug für die Navigation von Netzwerken in
Informationssystemen vor, das evolutionär fortentwickelt werden könnte. Solange diese
Situation vorliegt schlagen Smolnik und Erdmann201 vor, das Netzwerk aus Sicht eines
Startknotens in eine hierarchische Darstellungsweise zu projizieren, da etwa für eine Baum-
struktur eine Vielzahl von Visualisierungskonzepten zur Verfügung steht die effizient nutzbar
sind, und auch in breiten Anwenderkreisen weitgehend akzeptiert und deren Nutzung einge-
übt ist. Ein geeigneter Startknoten ist in diesem Fall die Primäraktivität.
Abbildung 4-8: Aktivitätsnetzwerk202
Zudem ist es häufig nicht notwendig, das Beziehungsnetzwerk vollständig zu visualisieren,
weil andere Aktivitäten für die Bearbeitung der eigenen Aufgaben weniger Relevanz haben,
als Merkmale der Primäraktivität. Je weiter die Entfernung einer verknüpften Aktivität im
Navigationspfad von der Primäraktivität zu verknüpften Aktivitäten ist, je weniger Relevanz
hat die Aktivität für die Bearbeitung der Primäraktivität. Abbildung 4-8 zeigt ein einfaches
Netzwerk aus Primäraktivität A1’ und verknüpften Aktivitäten. Während Aktivität A4’ und
A5’ noch relevante Kontextinformationen für die Bearbeitung von A1’ enthalten, so ist A3’
üblicherweise bereits irrelevant für die Bearbeitung von A1’.
201 Vgl. [Smolnik/Erdmann 2003], S. 272ff.
202 Hinweis: Lediglich Aktivität A1 ist vollständig expliziert dargestellt. Alle weiteren Aktivitäten werden aus
Gründen der Übersichtlichkeit nicht im Detail dargestellt.
117
Alle mit der Primäraktivität verknüpften Aktivitäten werden als Peripheraktivitäten bezeich-
net. Es kann in diesen Fällen hinreichend sein, durch Verfolgen der Verknüpfung eine andere
Aktivität in den Visualisierungsbereich zu übernehmen. In diesem Fall kann auch ohne
Projektion eine hierarchische Darstellung gewählt werden. Da verknüpfte Aktivitäten ledig-
lich Kontextinformationen bereitstellen und anders als Teilaktivitäten per Definition nicht in
die Primäraktivität einzubetten sind, können sie in der Darstellung wie Aktivitätskontexte von
Dokumenten behandelt werden (VA4 und VA5).
Abbildung 4-9: Hierarchische Aktivitätsstrukturliste
Abbildung 4-9 zeigt ein Beispiel für eine mögliche hierarchische Darstellung einer Liste von
Aktivitäten ohne Verknüpfungen zu anderen Aktivitäten oder Teilaktivitäten. Diese Liste wird
als Aktivitätsstrukturenliste, bzw. verkürzt als Aktivitätenliste bezeichnet. Die Darstellung in
der Abbildung ist an der Definition von Aktivitäten orientiert, so dass eine Aufgabe nicht
unabhängig von einer Teilaktivität existieren kann. Das kann in der Praxis die Explikation
umständlich und damit ineffizient machen.
Enthält eine Teilaktivität wie T3 beispielsweise lediglich eine Aufgabe kann es Sinn machen,
Aufgaben und Teilaktivitäten als Einheit darzustellen, um die Handhabung effizienter zu
gestalten. Die Meta-Daten, welche die Teilaktivität bestimmen entfallen dann entweder, oder
sind implizit in der Aufgabendefinition enthalten. Abbildung 4-10 zeigt eine vereinfachte
Darstellung von Teilaktivitäten, in denen die Teilaktivität durch eine Aufgabendefinition
ersetzt wurde. Durch die Zusammenführung von Teilaktivitäten und Aufgaben können nun
auch einer Aufgabe Aktivitätskontexte wie K2.1 zugeordnet werden.
118
Abbildung 4-10: Vereinfachte Darstellung von Teilaktivitäten durch Aufgaben
4.4.3 Navigation, Orientierung und Suche
In der UBAM-Umgebung erfolgt die Navigation wie in klassischen CIS über Ansichten. Die
von Anwendern üblicherweise erwünschte Klassifizierung erfolgt über Summary-Daten der
dargestellten Dokumente.203 Die Art der Klassifizierung hängt davon ab, in welcher
Granularität die Elemente der Aktivitätsstruktur dargestellt werden sollen. So ist sowohl die
Visualisierung einer kompletten Aktivität als Dokument möglich, als auch die Visualisierung
jedes einzelnen Elements der Aktivitätsstruktur. Bei der Zusammenfassung der gesamten
Aktivität in einem Dokument bestehen eingeschränkte Möglichkeiten beim Einsatz von
Filtern. Wenn jedes Element der Aktivitätsstruktur als eigenes Dokument visualisiert wird,
kann dies unübersichtlich erscheinen. Hier muss in Abhängigkeit von Einsatzszenario
abgewogen werden. Wird die Visualisierung jedes Elements umgesetzt, so wird das Doku-
ment, welches Daten und Inhalt eines Elements der Aktivitätsstruktur speichert, als Aktivi-
tätsstruktur-Elementdokument, kurz Elementdokument bezeichnet. Wird die gesamte Aktivität
durch ein Dokument repräsentiert, wird dieses Dokument als Aktivitätsstruktur-Dokument
bezeichnet.
Unabhängig von der Granularität der Darstellung der Aktivität in einem gegebenen Szenario
ist zu berücksichtigen, dass das Element ‚Aufgabe’ ein zentrales Element am kollaborativen
Arbeitsplatz darstellt. Zunächst liegt das daran, dass der Anwender an einfaches Aufgaben-
management im Kontext von PIM Applikationen gewöhnt ist. Um hier die Einstiegshürden in
UBAM gering zu halten, sollten Elemente des Aufgabenmanagements auch im UBAM
Werkzeug wieder zu finden sein. Zudem ist die Aufgabe stets mit einer konkreten notwendi-
gen Handlung des Anwenders verbunden, während beispielsweise die Aktivität und die
Teilaktivität Kontextinformationen darstellen und als strukturierende Elemente für die
203 Vgl. etwa [Harrison 2004], S. 3.
119
Aufgabenverwaltung dienen. Neben der Navigation von Aktivitäten ist also auch ein
dediziertes Aufgabenmanagement sinnvoll.
Das Aufgabenmanagement muss aktivitätsübergreifend möglich sein, denn wenn der
Anwender beispielsweise alle Aufgaben mit hoher Priorität sucht, die heute erledigt werden
müssen, spielt die Kontextinformation ‚Zugehörigkeit zu einer Aktivität’ nur eine unter-
geordnete Rolle. Die Aktivitätszugehörigkeit kann jedoch in der Ansicht zur Klassifizierung
der Aufgaben genutzt werden. Dies muss aber nicht der Fall sein. So kann die Aktivität auch
lediglich als Kontextdimension der Aufgabendefinition dienen und nicht in der Navigation
Verwendung finden.
Ansichten und Filter dienen dazu die Menge der Elementdokumente, welche die Aktivitäts-
strukturen repräsentiert, ggf. klassifiziert zu visualisieren. Um in der Darstellung effizient die
gesuchte Information finden zu können, benötigt der Mensch markante Orientierungshilfen
(engl. Landmarks), welche die Navigation unterstützen.204 Landmarks können beispielsweise
Symbole, Farben, oder Textformatierungen wie ‚Fett’ sein, die bestimmte Summary-Daten
eines Dokuments darstellen. So kann ein Summary-Datum ‚Priorität hoch’ durch die Farbe rot
symbolisiert werden, so dass hoch priorisierte Aufgaben in einer Aktivitätenliste sofort
sichtbar sind.205 Unterschiedliche Symbole für Aktivitäten, Teilaktivitäten, Aufgaben oder
Aktivitätskontexte sind weitere Beispiele für den Einsatz von Landmarks. Ein Landmark kann
aber auch ein zeitliches Merkmal sein, etwa eine Ansicht, in der dargestellt wird, wann auf
welches Dokument zugegriffen, oder wann es zuletzt bearbeitet wurde. Eine Ansicht, die
Zugriffe etwa nach Bezeichnungen wie ‚Gestern’ oder ‚Letzte Woche’ klassifiziert, hilft,
gesuchte Informationen schnell zu finden. Eine solche Ansicht wird als Interaction History
bezeichnet.206
Während Landmarks primär in der explorierenden Navigation eine Rolle spielen, ist die
Suche ein wichtiges Mittel zu Identifikation eines spezifischen Dokuments oder einer Menge
an Dokumenten. Dies kann die Textsuche über Inhalte der dargestellten Ansicht, aber auch
die Volltextsuche innerhalb der dargestellten Dokumente sein. Dabei kann es durch den
Anwender erwünscht oder für das Auffinden der Information sogar notwendig sein, auch die
Inhalte verknüpfter Dokumente zu erfassen. Die Suche sollte also auch einen Aktivitäts-
kontext anzeigen, wenn sich das verknüpfte Dokument in einem externen Repository befindet.
Zur besseren Verständlichkeit der Abgrenzung zwischen dem Elementdokument und dem
204 Vgl. [Ark et al. 1998].
205 Vgl. [Harrison 2004], S. 4.
206 Vgl. [Kaptelinin 2003].
120
verknüpften Dokument eines Aktivitätskontexts wird das verknüpfte Dokument als Kontext-
Zieldokument, kurz Zieldokument bezeichnet.
Die Suchsyntax sollte sich dabei an die aus Web Suchen bekannte Syntax anlehnen. Die
Syntax der Google-Suche stellt hier einen Industriestandard dar. Neben der Volltextsuche, die
aufgrund der erfassten Textmenge sehr viele Ergebnisse liefern kann, ist die Attributsuche in
bestimmten Meta-Daten Feldern wichtig, da sie eine zielgenauere Lokalisierung des
gesuchten Dokuments ermöglicht. Auch hier bilden die genannten Varianten ein Spektrum
mit Vor- und Nachteilen ab. Während die Volltextsuche weniger präzise Ergebnisse liefert als
die Attributsuche, ist sie in der Handhabung effizienter und einfacher. Meta-Daten sind
demnach für die Navigation, die Orientierung und auch die Suche sehr wichtig. Das aufgrund
seiner hohen Akzeptanz und effizienten Nutzbarkeit wohl erfolgreichste Konzept der Zuwei-
sung von Meta-Daten ist aktuell das Tagging im Social Web. Daher sollte auch bei einem
UBAM Werkzeug Tagging ermöglicht werden. Dies erleichtert die Navigation, den Einsatz
von Landmarks, die Filterung, die Attributsuche und die Volltextsuche.
Für alle genannten Navigationselemente gilt, dass zumindest eine gemeinsame, gleiche Sicht
auf eine Aktivität als intersubjektiver Konsens vorhanden sein sollte (vgl. Abschnitt 4.3.4).
Daher werden Mechanismen benötigt, um eine effiziente Umstrukturierung von Aktivitäts-
strukturen für Teambedürfnisse zu ermöglichen, z. B. durch Drag-and-drop von Teilen der
Strukturhierarchie. Neben dieser Anforderung aus Teamsicht müssen die individuellen
Bedürfnisse der Anwender berücksichtigt werden. Sie sind bei der Navigation und der Filte-
rung, insbesondere aber beim Aufgabenmanagement (vgl. Abschnitt 4.1.3) wichtig.
Für das Aufgabenmanagement bedeutet dies etwa, dass eine automatisierte Aufbereitung der
Meta-Daten aus den Elementdokumenten über eine Ansicht nicht hinreichend ist. Um für die
individuellen Bedürfnisse optimiert zu sein ist es beispielsweise notwendig, die Reihenfolge
der Darstellung nicht nur in Form einer Sortierung vorzunehmen. Dies wäre eine funktionale
Einschränkung gegenüber den Möglichkeiten, die physische Arbeitsumgebungen bieten. Wie
in Umgebungen mit Papierdokumenten muss eine arbiträre Reihenfolge manuell erzeugt
werden können. In dem in Abbildung 4-2 illustrierten Beispiel ist es etwa möglich, die exakte
Bearbeitungsreihenfolge durch Stapelung festzulegen.
Auch wenn wahrscheinlich verschiedene Stapel eine Klassifizierung anhand von Meta-Daten
wie beispielsweise der Priorität darstellen, kann innerhalb der Klasse eine arbiträre Sortierung
erfolgen. Wenn Dinge besonders wichtig werden, können sie im Stapel identifiziert und nach
oben gelegt werden. Dieses Verhalten des Anwenders muss auch mit elektronischen Doku-
121
menten möglich sein. Der Anwender muss also Klassifizierung (Stapel) und manuell defi-
nierte Reihenfolge kombinieren können. Elektronische Dokumente haben gegenüber physi-
schen Papierdokumenten darüber hinaus den Vorteil, dass die Vorklassifizierung automatisch
erfolgen kann, dass sich ein Dokument gleichzeitig in mehreren Klassen befinden kann und
dass Such- und Filterfunktionen bereitstehen. Auch Landmarks können individuellen
Charakter haben. Ein physisches Äquivalent sind etwa das Post-It oder der Textmarker.
Ebenso können Anwender unterschiedliche Bedürfnisse haben, welche Meta-Daten sie zur
Navigation benötigen. So kann es etwa sinnvoll sein, die in Ansichten visualisierten Meta-
Daten konfigurierbar zu gestalten.
4.4.4 Aktivitätsvorlagen
Wie in Abschnitt 4.2.2 diskutiert kann UBAM die Wissensmanagement Prozesse im Unter-
nehmen unterstützen, indem ähnlich wie bei Checklisten, Vorlagen für Aktivitätsstrukturen
zur Verfügung gestellt werden. Vorlagen für Aktivitäten stellen organisationales Wissen dar.
Durch die Verwendung einer initialen Vorlage und der im Verlauf der Aktivitätsbearbeitung
vorgenommenen Änderungen entwickelt sich die Instanz der Vorlage weiter. Werden dabei
Verbesserungspotenziale erkannt, können diese dazu genutzt werden, die Vorlage selbst zu
verbessern und so die Entwicklung der Vorlage vorantreiben. Es ist also neben der Möglich-
keit, Aktivitätsschablonen bereitzustellen auch wichtig die Möglichkeit einzuräumen, sowohl
die Vorlage, als auch die Instanz der Vorlage zu entwickeln.
Ähnlich wie bei gesetzlich vorgeschriebenen Checklisten kann es auch im Unternehmen z. B.
aufgrund von regulatorischen Anforderungen oder organisationalen Policies notwendig sein,
dass Änderungen an Vorlagen genehmigt werden müssen. Ist dies der Fall, kann ein struktu-
rierter Änderungsprozess notwendig werden. In Abhängigkeit vom Szenario können auch
direkte Zugriffs- und Bearbeitungsrechte und eine entsprechende Protokollierung von Ände-
rungen einen vordefinierten Prozess ersetzen.
Bei der Erstellung einer Vorlage findet eine Abstraktion von der konkreten Instanz statt. Der
Abstraktionslevel einer Aktivitätsvorlage ist in der Regel recht gering. Beim Vergleich mit
anderen Arten von Vorlagen können beispielsweise Vorlagen für Projekte in PMS und
Vorlagen für Prozesse in WfMS (Workflow Modell) betrachtet werden. Ein Workflow
Modell207 weist ein hohes Abstraktionslevel auf, weil jede Instanz ohne Ausnahmen und ohne
weitere Veränderung auf dem Modell basieren muss, um eine möglichst hohe Effizienz bei
der teilautomatisierten Bearbeitung zu erreichen. Eine Projektvorlage hingegen kann und soll
207 Im Sinne von Abbildung 2-6, Bereich 3, Vollständig vordefinierter Workflow.
122
dies nicht leisten. Per Definition ist ein Projekt immer einmalig. Eine Vorlage kann daher
lediglich gewisse Rahmenbedingungen sicherstellen. Die Instanz ist nach der Erzeugung aber
hochflexibel.
Aktivitäten sind im Bereich der Flexibilität von Projekten, jedoch mit deutlich geringerer
Komplexität einzuordnen. Auch bestehen üblicherweise keine Anforderungen an Aufwands-
und Kostenmanagement oder Ressourcenplanung. Ebenso schreitet die Entwicklung der
Vorlage aufgrund der geringeren Komplexität und damit geringerer Seiteneffekte durch
Änderungen schneller fort. Daher muss auch der Aufwand, der in die Abstraktion und Bereit-
stellung von Vorlagen gesteckt wird geringer gehalten werden als bei Projekten. Auch die
Beschränkungen bei der Anpassung von Vorlagen müssen üblicherweise nicht so restriktiv
sein, wie dies bei Projekten der Fall ist.
Häufig sind Art und Struktur von Aktivitäten ohnehin nicht durch eine zentrale Instanz
vorhersehbar. Die Anzahl unterschiedlicher Aktivitäten im Unternehmen ist so vielfältig, dass
bei geringer Komplexität einer Aktivität der Aufwand für die Suche einer Vorlage größer sein
kann, als die Aktivitätsstruktur ohne Vorlage zu erzeugen. Ein Großteil der Aktivitäten wird
daher üblicherweise nicht von durch das Unternehmen bereitgestellten Vorlagen abgedeckt
werden können. Vielmehr muss das Individuum oder das Team für wiederkehrende, ähnliche
Aktivitäten eigenständig Vorlagen erstellen und zur Erzeugung von Instanzen nutzen können.
Da die Anforderungen an Abstraktionsmöglichkeiten gering sind kann es bereits hinreichend
sein, existierende Aktivitäten zu kopieren und entsprechend anzupassen, ohne den Zwischen-
schritt der Nutzung einer Vorlage. Beim Kopieren muss lediglich berücksichtigt werden, ob
lediglich reine Strukturinformationen kopiert werden sollen, oder auch die jeweiligen Inhalte
der Elementdokumente der Aktivitätsstruktur. Ist in der Vorlage beispielsweise der Aktivi-
tätskontext eines Zieldokuments gespeichert, kann es Sinn machen, die Verknüpfung zu
kopieren, wenn beispielsweise das gleiche Zieldokument in der neuen Aktivität benötigt wird.
Es kann aber auch ebenso sinnvoll sein, lediglich einen Platzhalter für die Verknüpfung
anzulegen. Der Anwender vergisst so nicht, dass an dieser Stelle üblicherweise ein Dokument
zur Aufgabenbearbeitung benötigt wird oder neu erzeugt werden muss.
4.4.5 Elemente der Aktivitätsstruktur als Dokument
In Abschnitt 4.4.3 wurde dargelegt, dass eine Aktivität sowohl als Gesamtheit in einem
Dokument beschrieben werden kann, als auch, dass die Granularität höher sein kann, also
mehrere Dokumente die Aktivität beschreiben. Die höchste Granularität wird erreicht, wenn
jedes Element der Aktivitätsstruktur durch ein eigenständiges Elementdokument repräsentiert
123
wird. Eine hohe Granularität hat Vorteile für die Organisation der Elemente, da sie beispiels-
weise durch Filterung ein spezialisiertes Aufgabenmanagement ermöglicht. Die folgenden
Abschnitte zeigen Gründe auf, warum es in den meisten Szenarien vorteilhaft ist, jedes
Element der Aktivitätsstruktur durch ein Dokument zu beschreiben.
4.4.5.1 Meta-Daten
In Abschnitt 4.1.5 wurde diskutiert, dass UBAM als organisatorische Meta-Ebene zu
etablierten CSCW Konzepten zu positionieren ist. Insbesondere für Aktivitätskontexte von
Dokumenten lässt sich diese Aussage weiter präzisieren. So lassen sich Aktivitätskontexte
innerhalb von Aktivitätsstrukturen im Kontinuum für Kontextexplikation nach Smolnik (vgl.
Abbildung 4-12) als Metakontext-Ansatz einordnen. Meta-Daten die als Kontext Deskriptoren
genutzt werden, sind bei diesem Ansatz zusätzlich zu den Zieldokument-inhärenten Meta-
Daten durch ein eigenständiges Elementdokument repräsentiert.208 Die Nutzung der Kontext-
information ‚Aktivität’ als Metakontext für eine Menge von Zieldokumenten stellt für das
organisationale Wissensmanagement eine nützliche Ressource dar. So wird über die Vergabe
von kontextspezifischen Meta-Daten (Kontext-Daten) und der Nutzung von Zieldokumenten
im Kontext einer Aktivität implizit eine Erweiterung der bereits vorhandenen Meta-Daten
vorgenommen, die für die Attributsuche, aber auch die semantische Navigation und Analyse
von verteilten Dokumentenmengen genutzt werden können. Dazu muss die Suchmaschine
Zieldokument und Elementdokument als Einheit behandeln, sie muss also ein virtuelles
Dokument als Vereinigung aller Daten beider Dokumente erzeugen (vgl. Abbildung 4-11).
208 Hinweis 1): Der Bezug zu Smolnik ist hier trotz unterschiedlicher Definition von Dokumenten relevant, da in
diesem Abschnitt lediglich die Darstellung von Dokumenten von Bedeutung ist. Smolniks
Dokumentenverständnis beinhaltet ebenfalls die Darstellung als Einheit.
Hinweis 2): Für die Gründe der Trennung von Dokument und Meta-Daten Dokument siehe [Smolnik 2006].
124
Abbildung 4-11: Zieldokumente in der Suche nach Elementen der Aktivitätsstruktur
Auch kann die Verknüpfung eines Zieldokuments in einer Aktivität ein Relevanzindikator des
Inhalts sein, denn durch die Verknüpfung findet eine implizite Bewertung des Dokuments
statt. Sie kann Aufschluss über die Aktualität des Dokuments geben, etwa anhand des Erstell-
datums eines Aktivitätskontexts. Sie kann aber auch auf die Einbettung in Aufbau- und
Ablauforganisation des Unternehmens hinweisen, etwa indem in einer Aktivitätsvorlage eine
Verknüpfung auf das Dokument vorhanden ist. Auch ist es möglich, neue semantische Bezie-
hungen z. B. über die Nutzung eines Zieldokuments in verschiedenen Aktivitäten oder die
Nutzung verschiedener Dokumente in einer Aktivität zu visualisieren und Kontexte so navi-
gierbar zu machen. Auch die von Smolnik genannten Einsatzkriterien für diesen Ansatz
passen zum vorliegenden Szenario, wie beispielsweise die Vielzahl heterogener
Informationsquellen und der starke Bezug zu Wissensarbeitern.209 Der Vorgang, Dokumenten
neue Aktivitätskontexte hinzuzufügen und somit Ihren Wert im Wissenskontext zu erhöhen
wird als Harvesting bezeichnet (dt. Ernten).
209 Vgl. [Smolnik 2006], S. 97.
125
Abbildung 4-12: Kontinuum für Kontextexplikation210
Neben der Bedeutung im Wissens- und ECM-Kontext ist aber auch die Bedeutung von Meta-
Daten für die Navigation, Orientierung, Filterung und Suche zu berücksichtigen (vgl. Ab-
schnitt 4.4.3). So tendieren selbst Anwender, die Dokumente mit extrem wenigen
Informationen erstellen dazu, durch Tagging zusätzliche Filtermöglichkeiten für sich und
Andere bereitzustellen. Beispielsweise erlaubt ein Twitter Eintrag (Tweet) lediglich 140
Zeichen für den Inhalt inkl. Meta-Daten. Als Strukturierungsmöglichkeit werden hier durch
die Anwender Hashtags (‚#’) verwendet, die als Feldmarkierung für deskriptive Meta-Daten
fungieren und so die themenorientierte Filterung von Tweets ermöglichen.211 Diese Hashtags
wurden durch die Anwender eingeführt, und waren nicht im ursprünglichen Twitter Konzept
vorgesehen. Auch wenn eine Anzahl von Tweets häufig als Aggregation dargestellt wird, so
verfügt doch jeder einzelne Tweet über einen URI und die Möglichkeit, den Tweet allein als
Dokument darzustellen. Daher handelt es sich definitionsgemäß um ein eigenständiges
Dokument.
210 Vgl. [Smolnik 2006], S. 93.
211 Vgl. [Simon/Bernhardt 2010], S. 84f.
126
4.4.5.2 Planung und Organisation der Aufgabenbearbeitung
Eine Aufgabe enthält eine Anweisung für die bewusste Durchführung einer Handlung. Die
Unterstützung der Anwender bei der Bearbeitung von Aufgaben stellt innerhalb des
Aktivitätenmanagements eine wichtige Funktionalität dar. Alle anderen Strukturelementtypen
dienen lediglich dazu, Zusammenhänge zwischen Aufgaben zu verdeutlichen oder die
Aufgabenbearbeitung effizienter zu machen. In PIM-Umgebungen gibt es eine Reihe an
typischen Meta-Daten für die Beschreibung von Aufgaben wie beispielsweise Bearbeitungs-
status, Zieldatum (engl. Due-Date) und die Priorität. Beim Zieldatum handelt es sich typi-
scherweise um eine externe Restriktion, nicht um eine selbst gewählte Frist. Für die eigene
Arbeitsorganisation bevorzugen Anwender die Planung in Form weicherer Zeiträume, wie
etwa „Dinge für nächsten Freitag“.212 Eine Abbildung dieser weichen Zeiträume könnte
beispielsweise über Tags erfolgen.
Tags dienen darüber hinaus der Klassifizierung von Aufgaben anhand von Kriterien wie
Wichtigkeit, Dringlichkeit oder Themengebiet. Dies wird auch in Zeitmanagement Publi-
kationen, etwa von Seiwert213 oder Allen214 empfohlen. Spezifischere Meta-Daten werden
benötigt, wenn eine Aufgabe einem Repository entstammt, das ein etabliertes CSCW Konzept
umsetzt. So haben beispielsweise Aufgaben aus einem PMS neben dem Zieldatum auch ein
Beginndatum, da manche Aufgaben erst begonnen werden können, wenn eine andere beendet
ist. Außerdem ist beispielsweise der Aufwand für die Bearbeitung einer Aufgabe für das
Projektcontrolling relevant, daher ist auch dies als Meta-Datum vorhanden.
Der Aufwand, bzw. die eingeplante Zeit zur Bearbeitung kann auch für das individuelle
Zeitmanagement wichtig sein. Ist der geplante Aufwand expliziert, kann dieses Datum
beispielsweise als Filter dienen. Wenn der Anwender noch 15 Minuten bis zum nächsten
Termin Zeit hat kann das System alle Aufgaben ausblenden, deren Bearbeitung voraussicht-
lich mehr Zeit erfordert. Eine zeitraumbezogene Aufgabenplanung ermöglicht es darüber
hinaus, die Aufgaben im zentralen Zeitmanagement Werkzeug des Anwenders, dem Kalen-
der, anzuzeigen. Außerdem wird die Aufwandsschätzung auch für nicht Projekt-bezogene
Aufgaben in Zeitmanagement Publikationen etwa von Seiwert215 empfohlen, da der Aufwand
bei fehlender Explikation häufig unterschätzt wird, und so leicht eine Überladung des eigenen
Aufgabenplans erfolgen kann.
212 Vgl. [Harrison 2004], S. 4.
213 Vgl. [Seiwert 2002].
214 Vgl. [Allen 2003].
215 Vgl. [Seiwert 2002], S. 36.
127
Im Teamkontext ist außerdem der Bearbeiter oder die Gruppe von Bearbeitern relevant. So
zeigen Hinds und McGrath, dass es bei verteilten Teams wichtig ist, die Struktur der Team-
aufgabe transparent zu machen.216 Sie zeigen außerdem, dass bei verteilten Teams eine
informelle Hierarchie die Koordination im Vergleich zur sonst häufig bevorzugten Modulari-
sierung von Aufgabenblöcken erleichtert.217 Es sollte also sowohl eine Unterstützung für
klare Zuständigkeiten und implizite Delegation geben, als auch die Möglichkeit zur
Modularisierung von Aufgabenblöcken.
Sind einer Aufgabe mehrere für die Bearbeitung in Frage kommende Bearbeiter zugewiesen,
von denen jedoch nur eine Person konkret an der Aufgabe arbeiten muss, ist außerdem eine
Reservierungsmöglichkeit (engl „Claim“) notwendig. Aufgaben aus WfMS haben häufig
diese Eigenschaft, da hier während der Weiterleitung eines Dokuments der im Workflowmo-
dell enthaltenen abstrakten Organisationseinheit konkrete Bearbeiter zugewiesen werden.
Erfolgt keine manuelle oder automatische Reservierung für die benötigte Anzahl an Bearbei-
tern kann es zu Mehrfachbearbeitung der Aufgabe, und somit zu Ineffizienzen kommen.
Neben Aufgaben können auch Aktivitäten und Teilaktivitäten einen Status aufweisen, und
beispielsweise erledigt, in Bearbeitung oder archiviert sein. Dieser Status kann automatisch
verwaltet sein und auf erledigt gesetzt werden, etwa wenn alle enthaltenen Aufgaben erledigt
sind. Er muss jedoch manuell verwaltet werden, wenn beispielsweise nicht jede Aufgabe auch
als Aufgabe expliziert wird. So kann beispielsweise ein Aktivitätskontext implizit eine
Aufgabe ‚lesen’ beinhalten, die dem Bearbeiter der Aufgabe implizit auch klar ist. Das
Arbeiten mit impliziten Aufgaben kommt insbesondere bei Individualaktivitäten häufig vor.
Aus diesem Grund, und aus Gründen der Effizienz bei der Explikation ist zu berücksichtigen,
dass bei der Systemgestaltung aus pragmatischen Gründen auf die Verpflichtung zur Explika-
tion von Aufgaben verzichtet werden sollte. Abbildung 4-13 zeigt die Darstellung einer
solchen Vereinfachung mit einer Teilaktivität T1.1 ohne Aufgabe. Eine weitere Verein-
fachung kann es sein, dass Elemente von Aktivitäten, die nur eine Aufgabe enthalten, nicht
expliziert werden müssen. Eine solche Aktivität hätte keine Elemente, in der Darstellung
würde die Aktivität wie eine Aufgabe visualisiert.
Abschließend soll der Bearbeitungsstatus eines Elements betrachtet werden. Neben verschie-
denen Status für die aktive Bearbeitung sind Statusinformationen wichtig, die einen inaktiven
Status kennzeichnen. Millen et al.218 zeigen etwa, dass Archivierung notwendig ist und
216 Vgl. [Hinds/McGrath 2006], S. 351.
217 Vgl. [Hinds/McGrath 2006], S. 350.
218 Vgl. [Millen et al. 2005].
128
gewünscht wird. Dabei ist ein einfaches Archiv Flag häufig nicht hinreichend. Der Anwender
muss in der Lage sein, seine archivierten/abgeschlossenen Aktivitäten möglichst effizient
wieder aufzufinden. Daher ist es nützlich, eine hierarchische Struktur im Archiv zu
unterstützen, etwa in Form von Ordnern. Eine Archivaktivität ist eine Möglichkeit der
Implementierung. Die Aktivität enthält dann alle archivierten Aktivitäten als Teilaktivität.
Abbildung 4-13: Darstellung von Teilaktivitäten ohne Aufgabe
Boardman und Sasse219 haben festgestellt dass manche Informationen gar nicht archiviert
werden. Sie schlagen vor, Inhalte nach Nutzen zu klassifizieren und nicht nach Status-
informationen wie ‚aktiv’ bzw. ‚archiviert’. Archivierte Dokumente bezeichnen sie als ruhend
(‚dormant’) um zu kennzeichnen, dass sie grundsätzlich weiterhin nützlich sein können, aber
aktuell nicht in Verwendung und nicht aktiv sind. Der Bearbeitungsstatus einer Aktivität kann
zudem für unterschiedliche Teammitglieder verschieden sein. So kann beispielsweise ein
Anwender, der alle seine Aufgaben bearbeitet hat, eine Aktivität oder Teilaktivität bereits
archivieren wollen, während ein anderes Teammitglied die Aktivität noch im Spektrum seiner
aktiven Aktivitäten benötigt. Die Individualität gilt ebenso für andere Meta-Daten wie die
Priorität, die aufgrund unterschiedlicher Arbeitsorganisation der Individuen ebenso unter-
schiedlich ausfallen kann. Individuelle Meta-Daten sind bei der UBAM Konzeption
entsprechend zu berücksichtigen.
4.4.5.3 Sicherheit
Dokumente in CIS im Unternehmen verfügen über Zugriffsbeschränkungen, um nur auto-
risierten Personen Zugriff auf die im Dokument enthaltenen Informationen zu gewähren.
Dabei wird üblicherweise das Recht ein Dokument zu lesen sowie das Recht ein Dokument zu
bearbeiten unterschieden. Des Weiteren kann der Besitzer eines Dokuments vorgesehen sein,
der das Bearbeitungsrecht für den Inhalt hat, und zusätzlich über das Recht verfügt, die
Bearbeitungsrechte zu modifizieren, und so beispielsweise einen weiteren Bearbeiter oder
219 Vgl. [Boardman/Sasse 2004].
129
Besitzer hinzuzufügen. In CIS gibt es häufig weitere Berechtigungsstufen, die für den Kontext
dieser Arbeit jedoch nicht relevant sind und daher nicht betrachtet werden.
Nicht nur die eigentlichen Inhalte eines Dokuments, sondern auch die Information, wie ein
Anwender seine Arbeit organisiert kann schutzbedürftig sein. So kann etwa ein Element-
dokument Meta-Daten enthalten, die eine Aufgabe oder den Inhalt eines Dokuments bewer-
ten, und die der Anwender nicht öffentlich zugänglich machen möchte. Es kann also auch für
Elemente von Aktivitätsstrukturen notwendig sein, Zugriffsbeschränkungen vorzunehmen.
Elemente, auf die der aktuelle Anwender nicht mindestens lesenden Zugriff hat werden in der
Ansicht der Aktivitätsstruktur nicht angezeigt. Dies ist nur dann auf Elementebene möglich,
wenn zur Implementierung der Visualisierung das Konzept der Elementdokumente gewählt
wurde (vgl. Abschnitt 4.4.3). Durch die Zugriffsbeschränkung kann die Aktivitätsstruktur für
unterschiedliche Teammitglieder unterschiedlich aussehen.
4.4.5.4 Inhaltsbeschränkung auf Kontextinformationen
Es wurde bereits mehrfach darauf hingewiesen, dass Dokumente in Unternehmensrepositories
zur gemeinsamen Nutzung vorliegen sollten. Dies ist unter anderem aus regulatorischen
Gründen, aus Gründen der ECM Strategie des Unternehmens, und aus Sicht des Wissens-
managements notwendig. Aus diesen Gründen aufbewahrungspflichtige oder
aufbewahrenswerte Dokumente werden als geschäftsrelevant bezeichnet. Da es sich bei
Aktivitäten ähnlich wie bei PIM Dokumenten um private oder teilprivate Repositories
handelt, sollte das Speichern von Inhaltsinformationen in Elementdokumenten unterbunden
werden.
Elementdokumente sollten also nur Meta-Daten enthalten, während sich der Inhalt in ent-
sprechenden geschäftsrelevanten Zieldokumenten befindet. Für die Anwender ist es jedoch
mit zusätzlichem Aufwand verbunden, bei neu anzulegenden Dokumenten zunächst ein
weiteres Repository öffnen zu müssen, das nicht zum UBAM System gehört. Dort muss dann
das Dokument angelegt, gespeichert und mit der aktuellen Aktivität verknüpft werden. Unter
dem Gesichtspunkt der Effizienz und Anwenderfreundlichkeit, die für die Akzeptanz des
Systems notwendig ist kann es also nachteilig sein, wenn an dem Grundsatz des Verbots von
Inhalten in Elementdokumenten rigide festgehalten wird. Daher kann den Anwendern etwa
erlaubt werden, so genannte aktivitätstemporäre Inhalte in Elementdokumenten zu speichern,
wenn diese nicht geschäftsrelevant sind.
Dies kann etwa auf Diskussionen über ein Zieldokument, einen aktivitätsspezifischen Chat
zwischen Teammitgliedern oder Informationen, die der Koordination der Aktivität dienen,
130
zutreffen, etwa ein Eintrag in einem Teamkalender zur Organisation einer Besprechung. Am
Beispiel des Teamkalenders wird aber auch deutlich, dass selbst aktivitätstemporär
erscheinende Informationen für andere Kontexte wichtig sein können. Denn Einträge im
Teamkalender müssen auch im persönlichen Kalender oder einem Abteilungskalender auftau-
chen können, damit für die Koordination von Besprechungen außerhalb der Aktivität voll-
ständige Informationen über die Termine jeder Person zur Verfügung stehen.
Auch die Diskussion eines Zieldokuments kann in anderen Kontexten des Dokuments rele-
vant sein. Wird beispielsweise im Rahmen der Diskussion eine fehlerhafte Information im
Zieldokument festgestellt, sollte die Diskussion auch Mitgliedern eines anderen Teams,
welches das Dokument benötigt, zur Verfügung stehen. Bei der Speicherung eines Element-
dokuments ist es für das UBAM System jedoch nicht möglich festzustellen, ob es sich um
aktivitätstemporäre Inhalte handelt, oder ob die Inhalte von Bedeutung für das organisationale
Wissen sind oder Relevanz gemäß der ECM Strategie des Unternehmens haben. Wird also die
Speicherung aktivitätstemporärer Inhalte ermöglicht, sollten Werkzeuge bereitgestellt werden,
um für den Anwender als relevant erscheinende Inhalte manuell, aber möglichst effizient
anderen Kontext Management Systemen zur Verfügung zu stellen, oder in das Repository des
Zieldokuments zu übertragen, damit sie dort direkt eingesehen werden können. Dieser Schritt
darf nur unwesentlich mehr Aufwand erfordern, als das Ablegen des Inhalts im Element-
dokument.
Abbildung 4-14 zeigt beide Szenarien in Gegenüberstellung. Im oberen Beispiel ist Dokument
D2 in der Aktivitätsstruktur gespeichert, es handelt sich also um aktivitätstemporäre Inhalte.
Im unteren Beispiel wurde das Dokument im Verlauf der Aktivitätsbearbeitung als geschäfts-
relevant betrachtet und im Unternehmensrepository R2 abgelegt. Ein Aktivitätskontext
Element wurde in der Aktivitätsstruktur angelegt. Es verweist auf das abgelegte Dokument
D2’ in Repository R2. Beim Dokument D2 handelt es sich nicht um ein neues Element der
Aktivitätsstruktur. Vielmehr kann der Inhalt in jedem beliebigen Element gespeichert sein. D2
dient lediglich der Illustration der Speicherung von Inhalten in der Struktur.
Werden beide Möglichkeiten zugelassen muss der Anwender ermuntert werden, möglichst
wenige Informationen innerhalb von Elementdokumenten abzulegen. Dies kann z. B. erreicht
werden, indem der Anwender konfigurieren kann, welche Typen von Informationen
typischerweise als Aktivitäts-temporär zu betrachten sind, etwa Chats und Diskussionen, und
welche im ECM Kontext abgelegt werden müssen, etwa Dateien oder Texte ab einer
bestimmten Länge. Bei der Ablage von Inhalten, die nicht den Vorgaben entsprechen kann
131
der Anwender dann etwa aufgefordert werden, die Information in einem CIS oder ECM
System abzulegen. Durch intelligente Vorschlagswerte kann der Aufwand der Ablage in
einem Zieldokument auf wenige Schritte reduziert werden.
Abbildung 4-14: Alternativen der Ablage von Dokumenten
Grundsätzlich besteht in diesem Szenario die Gefahr, dass nicht alle relevanten Informationen
in das entsprechend vorgesehene Repository transferiert werden, etwa weil nicht jeder UBAM
Anwender trennscharf entscheiden kann, welche Informationen geschäftsrelevant, und welche
lediglich als aktivitätstemporär zu betrachten sind. Dies ist ein weiterer Grund, die
Speicherung von Inhalten in der Aktivitätsstruktur nur in begründeten Szenarien zuzulassen.
Zumindest für den ECM und Wissenskontext lässt sich diese Problematik adressieren, indem
neben den ECM und CIS Systemen, auch die Aktivitätsstrukturen durch Suchmaschinen im
Unternehmen erfasst werden. Zusammenfassend lässt sich aber feststellen, dass Element-
dokumente nach Möglichkeit ausschließlich Kontextinformationen und keine Inhalte
enthalten sollten.
4.4.5.5 Management von Meta-Daten
Ein UBAM Framework verwaltet eine Dokumentenverknüpfung als Explikation des
Aktivitätskontexts von Zieldokumenten. Zusätzlich werden Meta-Daten der Aktivität
gespeichert (vgl. Abschnitt 4.4.5.4). Diese Kontext-Daten können eine Bedeutung für das
Repository haben, in dem das Zieldokument gespeichert ist. Dieses Repository wird als Ziel-
Repository bezeichnet. Am Beispiel einer Statusinformation wird dies deutlich. Eine Aufgabe,
die in der UBAM-Umgebung als ‚abgeschlossen’ gekennzeichnet wird kann darauf hindeuten,
dass implizit eine zugehörige Aufgabe im Ziel-Repository, z. B. einem WfMS, ebenfalls als
132
abgeschlossen markiert werden sollte. Es kann sinnvoll sein, diese Statusinformationen
zwischen UBAM und Ziel-Repository zu synchronisieren. Das Weiterschalten eines
Workflows ist aber auch ein Beispiel dafür, dass eine Synchronisation von Meta-Daten
zwischen Elementdokument und Zieldokument nicht trivial ist, denn die Status der beiden
Dokumente unterscheiden sich semantisch und technisch.
Während die Änderung des Status im UBAM etwa von ‚aktiv’ auf ‚erledigt’ aus Sicht des
Anwenders semantisch gleichbedeutend mit dem Status des Dokuments im WfMS sein kann,
so hat es hier Auswirkungen auf den Fortschritt des Geschäftsprozesses. Detailliert betrachtet
wird im UBAM der Aktivitätskontext archiviert, etwa durch Änderung eines Feldwertes. Im
WfMS hingegen wird das Dokument in der Bearbeitungsfolge an den nächsten Anwender
weitergeleitet. Dies kann die Änderung einer Vielzahl von Dokumentenfeldern beinhalten.
Die einfache Synchronisation eines Feldes ist also für das Abschließen einer Aufgabe nicht
geeignet. Ebenso gilt dies, wenn der UBAM Anwender eine Statusänderung wieder rück-
gängig macht. Während das Verschieben eines Elements der Aktivitätsstruktur aus dem
Archiv etwa durch die Änderung eines Feldwertes erfolgen kann, kann die Weiterleitung
eines Zieldokuments nicht in jedem WfMS rückgängig gemacht werden. Beide Systeme
müssen hier API Funktionen für die wichtigsten Statusänderungen bereitstellen, um eine
Synchronisation zu ermöglichen.
Neben Statusinformationen können z. B. Meta-Daten aus dem Ziel-Repository eines
Dokuments auch bei der Verwaltung der Kontextinformation nützlich sein, da sie
Informationen zum Inhalt des Zieldokuments bereitstellen. So stellt beispielsweise ein
typisches Meta-Datum das Feld ‚Thema’ (engl. Subject) dar. Es dient der Zusammenfassung
des Inhalts. In der Aktivitätsstruktur kann es der Identifikation des Zieldokuments dienen. Es
ist also sinnvoll, beim Einfügen des Aktivitätskontexts in die Aktivitätsstruktur das Thema
des Zieldokuments automatisch in das Elementdokument und somit die Aktivitätsstruktur zu
übernehmen. Ähnliches gilt für Stichworte, die der Filterung und Klassifizierung aller
Aktivitätskontexte dienen können. Wird am Elementdokument eine Änderung durchgeführt,
kann eine Synchronisation der Änderung in das Zieldokument sinnvoll sein, unter Berück-
sichtigung der Zugriffsbeschränkungen (vgl. Abschnitt 4.4.5.3). Im System müssen Regeln
hinterlegt werden können, aufgrund derer das System entscheidet, für welche Meta-Daten
eine Synchronisation erfolgen soll, für welche eine Nachfrage sinnvoll erscheint, und welche
Änderungen nicht synchronisiert werden sollen.
133
4.4.6 Zentraler Zugriffsbereich
Als Meta-Ebene zu etablierten CIS-Umgebungen (vgl. Abschnitt 4.1.5) stellt das UBAM
System einen zentralen Zugriffsbereich auf alle für die Arbeit am kollaborativen Arbeitsplatz
relevanten Personen, Dokumente, Repositories und Applikationen dar. Etablierte CIS Kon-
zepte und Applikationen werden nicht verändert, sondern evolutionär in Richtung Integration
mit einem UBAM System weiterentwickelt. Da Applikationen einzubinden sind, kann diese
Integration nicht wie etwa bei EAI oder SOA im Backend stattfinden, sondern muss im
Bereich der Benutzungsschnittstelle erfolgen. In den folgenden Abschnitten werden wichtige
Merkmale in Bezug auf den zentralen Zugriffsbereich diskutiert.
4.4.6.1 Erfassung aller Interaktionspartner
Um effizientes Aktivitätenmanagement zu ermöglichen muss sichergestellt werden, dass ein
möglichst großer Teil aller Aktivitäten im System abgebildet werden kann. Das beinhaltet
auch, dass ein möglichst großer Teil des Teams, das an der Aktivitätsbearbeitung beteiligt ist,
Zugriff auf das UBAM System hat und ohne Medienbrüche an der Bearbeitung teilnehmen
kann. Fehlt Teammitgliedern der Zugriff auf das System, müssten Anwender mit Zugriff die
benötigten Informationen über andere Wege verteilen, etwa per E-Mail. Außerdem müsste die
Koordination der Bearbeitung ebenfalls anders abgebildet werden. Die Folge ist, dass der
Anwender ohne Zugriff mit mehreren unterschiedlichen Systemen arbeiten muss, die zudem
wahrscheinlich nicht für Aktivitätenmanagement optimiert sind. Die Vermeidung der mit
diesem Szenario verbundenen Ineffizienzen und Qualitätsminderungen beim Arbeitsergebnis
ist ein Ziel von UBAM.
Insbesondere in interorganisationalen Teams ist es daher notwendig, dass die Plattform den
Zugriff über eine Technologie ermöglicht, die in allen beteiligten Organisationen verfügbar
ist. Üblicherweise ist dies ein Browser UI. Da der Zugriff auf die UBAM Infrastruktur eine
Authentifizierung und üblicherweise auch eine Autorisierung erfordert, müssen für Unter-
nehmens-externe Personen entsprechende Benutzeridentitäten verwaltet werden können. Für
enge Partner und Zulieferer kann hier eine zentrale Benutzereinrichtung hinreichend sein.
Aufgrund der Natur der Arbeit am kollaborativen Arbeitsplatz, die durch Eigenverantwortung
und dynamische Teams gekennzeichnet ist, ist die zentrale Benutzerverwaltung jedoch zu
unflexibel. So sollte berücksichtigt werden, dass der Anwender zu seinem UBAM Arbeits-
bereich Gäste einladen kann, die sich selbst registrieren können, oder deren Gastidentitäten
durch den Anwender selbst verwaltet werden können.
134
Setzt der Gast innerhalb seines Unternehmens selbst ein UBAM System ein so ist es sinnvoll,
die Systeme durch Föderierung oder Synchronisation zu verbinden, um allen Anwendern
einen zentralen Zugriffsbereich zu ermöglichen. Über eine API kann dem Gast-Anwender so
der Zugriff auf die komplette Aktivitätsstruktur ermöglicht werden, um die Übernahme der
Struktur in das eigene UBAM sicherzustellen. Eine solche API ermöglich auch die Ein-
bindung unternehmensexterner Aufgabenquellen, z. B. von Partnern und Zulieferern oder
Kunden, bis hin zu privaten Aufgaben aus öffentlich verfügbaren Diensten wie Google oder
Remember the Milk.
4.4.6.2 Erfassung aller Dokumente
Ebenso wie die Erfassung aller Interaktionspartner ist es notwendig, alle für die Aktivitäts-
bearbeitung benötigten Zieldokumente in der UBAM-Umgebung zu integrieren. Zum Lesen
und Bearbeiten von Dokumenten ist entweder eine Desktop-Applikation oder ein Browser UI
notwendig. Beide müssen im UBAM UI integrierbar sein, sonst ist das Ziel eines zentralen
Zugriffsbereichs nicht erfüllt. Abbildung 4-15 zeigt ein Beispiel für eine Implementierungs-
möglichkeit für ein UBAM UI. Der Zugriff auf Dokumente in R1 erfolgt per Browser UI, der
auf R2 per Desktop-Applikation. Das UBAM UI verwendet jeweils ein Portlet für die Dar-
stellung von Dokumenten per Browser UI und eines für eingebettete Desktop-Applikationen.
Die Liste von Aktivitätenstrukturen wird ebenfalls dargestellt. Sie setzt sich aus
Informationen zusammen, die in Elementdokumenten in UR1 gespeichert sind.
Ist das UBAM UI als Desktop-Applikation ausgeführt, muss es also Browser UIs sowie
andere Desktop-Applikationen integrieren können. Nachteilig ist hier, dass ein Zugriff durch
externe Anwender nicht ohne Weiteres möglich ist, weil die Desktop-Applikationen nicht zur
Verfügung stehen könnten. Für den externen Zugriff ist ein Browser UI notwendig. In diesem
Fall müsste aber jedes Unternehmensrepository ebenfalls über ein Browser UI verfügen.
Dieses Szenario kann durch Portaltechnologien adressiert werden. Für jedes System ohne ein
Browser UI müssen dann spezielle Portlets entwickelt werden, welche die Inhalte des Repo-
sitories im Browser darstellen und ggf. bearbeitbar machen. Trotz der immer reicheren
Interaktionsmöglichkeiten, die moderne Portalserver bieten sind Browser UIs dennoch für
Wissensarbeiter häufig nicht hinreichend, primär weil die technologischen Möglichkeiten von
Web-Applikationen noch nicht hinreichend ausgenutzt werden.
Aus diesem Grund kann es sinnvoll sein, dass das UBAM System mehrere alternative UIs zur
Verfügung stellt. So kann eine für UBAM spezialisierte Desktop-Applikation eingesetzt
werden, die Wissensarbeitern alle Dokumente und die zur Bearbeitung notwendigen Desktop-
135
Applikationen zur Verfügung stellt. Ein funktional reduziertes Browser UI, das den Zugriff
von externen Anwendern ermöglicht, kann zusätzlich zur Verfügung stehen. Für Repositories
ohne Browser UI muss für externe Anwender zusätzlich die Möglichkeit geschaffen werden,
Informationen etwa im Elementdokument abzulegen, damit keine kontextlose Verteilung per
E-Mail erfolgen muss. Dies ist durch den Transfer von D4 in E4 illustriert. Alternativ kann
eine einfache Vorschau auf Dokumente des Repositories per Browser UI implementiert
werden.
Abbildung 4-15: Beispiel für Integration externer Dokumente
In interorganisationalen Teams muss außerdem der Zugriff auf Unternehmens-externe Doku-
mente möglich sein, die nicht in internen Repositories vorliegen. Dies kann etwa durch die
Integration eines Browser UI des externen Repositories erfolgen (R3). In diesem Szenario ist
außerdem die Möglichkeit der Verwaltung externer Benutzeridentitäten zu berücksichtigen,
da die UBAM-Umgebung sonst kein Single Sign-On (SSO) durchführen kann, und der
Anwender seine Authentifizierungsinformationen, üblicherweise Benutzername und Pass-
wort, bei jedem externen Dokumentenzugriff erneut eingeben müsste. Steht kein Browser UI
zur Verfügung, muss ein Anwender der externen Organisation die Inhalte zur Verfügung
stellen, etwa über den Transfer der Inhalte in ein Elementdokument (D8 nach E8).
Im Hinblick auf die Öffnung interner Systeme ist es dabei häufig nicht erwünscht, alle Doku-
mente und Repositories für den externen Zugriff verfügbar zu machen. Insbesondere Systeme,
die unternehmenskritisch sind oder die vertrauliche Dokumente enthalten verfügen häufig
136
nicht über die Möglichkeit, von außerhalb der Organisation etwa per Browser UI auf die
Dokumente zuzugreifen. Kann also auf einige Repositories nicht über ein Browser UI zuge-
griffen werden, muss der interne Anwender diese Dokumente anders verfügbar machen, etwa
indem wie bereits zuvor beschrieben, selektiv diese Informationen in das Elementdokument
übernommen werden.
4.4.6.3 Posteingang für Aktivitäten
Die Koordination von Aktivitäten findet heute primär in etablierten CIS sowie in der E-Mail-
Umgebung statt. Eingehende E-Mails sind für Aktivitäten ein typischer Ausgangspunkt, da sie
häufig einen Auftrag zur Bearbeitung spontan auftretender, unstrukturierter Tätigkeiten
beinhaltet. Zunächst ist die E-Mail-Umgebung wie alle anderen Repositories zu betrachten.
Sie weist jedoch die spezielle Eigenschaft auf, dass üblicherweise lediglich ein Anwender
Zugriff auf die darin enthaltenen Dokumente hat. Daneben verfügt die E-Mail-Umgebung nur
über sehr rudimentäre Managementfunktionalitäten oder Mechanismen, die das Management
der in ihr enthaltenen Dokumente ermöglichen.
Dennoch stellt das Anwendungsparadigma von E-Mail-Umgebungen ein sehr erfolgreiches
Kollaborationskonzepte dar (vgl. Abschnitt 3.4.2). Ein wichtiger Grund des Erfolgs von
E-Mail ist die Einfachheit und die durch den Anwender subjektiv empfundene Effizienz der
Benutzung. Dieses Konzept durch ein radikal unterschiedliches Interaktionsparadigma zu
ersetzen beinhaltet das Risiko, dass die Anwender das neue System ablehnen. Wenn sich die
Änderungen hingegen als evolutionärer Prozess bei geringeren Produktivitätszuwächsen
gestalten, aber mit weniger großen organisatorischen Veränderungen, ist hingegen eine
höhere Akzeptanz zu erwarten. Für eine evolutionäre Entwicklung, die zu einer Abkehr von
der massiven E-Mail-Nutzung geführt hätten fehlten bisher jedoch erfolgreiche Konzepte und
Technologien. Und obwohl insbesondere in Großunternehmen die spezialisierten Alternativ-
systeme häufig bereits vorhanden sind, wird der notwendige Paradigmenwechsel organisato-
risch nicht bewältigt.
Bei der Integration von E-Mail in eine UBAM-Umgebung darf also keine radikale Änderung
bekannter Funktionalitäten erfolgen. Ebenso kann ein UBAM System davon profitieren, sich
funktional an Konzepten zu orientieren, die aus der E-Mail-Umgebung bekannt sind, etwa
dem Konzept des Posteingangs. Hier können sowohl eingehende E-Mails, als auch Hinweise
auf neue Aktivitäten, die noch nicht durch den Anwender in die persönliche Aktivitätenliste
übernommen wurden, angezeigt werden. Bei einer Integration von E-Mail in ein UBAM
System kann die existierende E-Mail-Umgebung parallel weiter genutzt werden. Anwender,
137
die sich durch die Funktionalität eines UBAM Systems zunächst überfordert fühlen, können
in der gewohnten Umgebung weiter arbeiten. Sie treten durch E-Mail-Benachrichtigungen
und darin enthaltene Links mit der UBAM-Umgebung in Interaktion. Anwender, welche die
Vorteile der UBAM-Umgebung erkennen, finden hingegen ihre E-Mails auch eingebettet in
der UBAM-Umgebung wieder.
In der gemeinsam genutzten Aktivitätenliste hingegen werden neue Aktivitäten bereits durch
die Ausgangsstruktur des Besitzers der Aktivität vorstrukturiert sein. Um in dieser Darstel-
lung neue Aktivitäten zu erkennen eignen sich Markierungen, die aus der E-Mail-Umgebung
für ungelesene Dokumente bekannt sind. Diese sollten nicht nur für Aktivitäten existieren,
sondern für alle Elemente der Aktivitätsstruktur, so dass sofort ersichtlich ist, wo in der
Aktivitätsstruktur ein neues Element erstellt oder geändert wurde. Weiterhin ist es
insbesondere im Parallelbetrieb wichtig, dass aus der gewohnten E-Mail-Umgebung heraus
Aktivitäten gestartet werden können, als auch der Aktivitätskontext von E-Mails effizient
bereits existierenden Aktivitäten zugeordnet werden kann. Etwa per Drag-and-drop-Technik,
ähnlich der Einordnung einer E-Mail in einen Ordner. Dies gilt nicht nur für die E-Mail-
Umgebung, sondern für alle in die UBAM-Umgebung zu integrierenden Systeme. Kenn-
zeichen dieser Integration werden in den nächsten Abschnitten diskutiert.
4.4.6.4 Management von Notifications
Unterbrechungen durch Applikationen treten häufig in Form von Benachrichtigungen auf. Ein
Beispiel ist die Benachrichtigung über eine neu eingetroffene E-Mail durch ein Symbol im
Benachrichtigungsfeld (engl. System-Tray) des Betriebssystems oder eine sich im Vorder-
grund öffnende Dialogbox. Ähnlich massiv ist die Unterbrechung durch Alarme des Kalen-
ders und Chat Systeme, die eine eingehende Nachricht häufig direkt in den Vordergrund des
Arbeitsplatzes bringen. Benachrichtigungen und Alarme über Ereignisse in CIS werden als
Notifications bezeichnet. Darüber hinaus kommen insbesondere im Social Web häufig
Benachrichtigungen über Tätigkeiten anderer Personen hinzu, etwa die „Live-Meldungen“ im
sozialen Netzwerk Facebook. Diese Notifications werden auch als soziale Aktivitäten (Social
Activities) bezeichnet220. Um im Kontext dieser Arbeit eine Überladung des Begriffs
Aktivität zu vermeiden, werden soziale Aktivitäten im Folgenden ebenfalls als Notifications
bezeichnet.
Um die durch Notifications hervorgerufenen negativen Unterbrechungen zu reduzieren, muss
ein zentrales Notification Management System zum Einsatz kommen, an das alle
220 Vgl. [Sala et al. 2011], Abschnitt 2.2.2.
138
Applikationen am kollaborativen Arbeitsplatz ihre Notifications melden können. Ein Regel-
system kann dann entscheiden, welche Notifications für den aktuellen Arbeitskontext relevant
sind. Diese können sich sogar positiv auf die Produktivität auswirken. Eine solche positive
Unterbrechung kann etwa die Nachricht vom Eintreffen einer E-Mail durch ein Teammitglied
der aktuell durch den Anwender in Bearbeitung befindlichen Aktivität sein, auf die der
Anwender bereits wartet. Ein Hinweis auf E-Mails von Personen, die nicht Mitglied des
Teams sind, würde hingegen nicht angezeigt. Das Regelsystem sollte durch den Anwender
auf seine spezifischen Anforderungen angepasst werden können.
Ein Notification Management System wird etwa von Mark/González/Harris221 oder Sen et
al.222 beschrieben. Neben der kontextsensitiven Filterung oder auch Gruppierung von
Notifications können Regeln auch zu bestimmten Prioritäten führen, so dass z. B. nur wich-
tige Notifications an den Anwender geleitet werden. Das Regelsystem sollte auf Kontext-
informationen (vgl. Abschnitt 3.4.4) zugreifen können, da der Arbeitskontext eine sehr hohe
Relevanz für die Identifikation positiver Unterbrechungen hat. Insbesondere explizite
Präsenzinformationen wie „Bitte nicht stören“ haben offensichtlich eine hohe Relevanz für
die Beurteilung von Notifications.
Das Anzeigen der Notifications sollte möglichst wenig störend für die Arbeit wirken. Eine
Dialogbox ist eine der am stärksten störenden Methoden. Sie kann bewusst gewählt werden,
wenn ein Anwender seine aktuelle Aktivität wirklich beenden soll, z. B. weil eine hoch
priorisierte Besprechung unmittelbar beginnt. Geeigneter für alle anderen Notifications ist
etwa ein in das UBAM System eingebettetes Portlet. Hier können die Notifications gesammelt
und aufbereitet angezeigt werden. Eine Klassifizierung etwa anhand von Priorität oder
Aktivitätskontext kann hier sinnvoll sein. Auch ein Verhandlungs-basiertes System kann
integriert sein, das beispielsweise bei Anfragen für Chats oder Telefonanrufe als Vermittler
zunächst regelbasiert entscheidet, ob der Anwender unterbrochen werden darf223. Für
Elemente der Aktivitätsstruktur sollte ebenfalls die Möglichkeit bestehen, Notifications
festzulegen, z. B. für geplante Bearbeitungszeiträume, wie es für Aufgaben in PIM-
Umgebungen üblich ist.
4.4.6.5 Vermeidung erzwungener Kontextwechsel
Wie in Abschnitt 3.2.5 beschrieben, ist der kollaborative Arbeitsplatz durch Unterbrechungen
und Kontextwechsel gekennzeichnet. Ein erzwungener Kontextwechsel liegt dann vor, wenn
221 Vgl. [Mark/González/Harris 2005].
222 Vgl. [Sen et al. 2006].
223 Vgl. [McFarlane 2002], S. 95 f.
139
der Anwender den Kontext einer Aktivität aufgrund externer Ereignisse wechselt. Eine
Ursache, die Unterbrechungen durch Notifications wurden bereits in Abschnitt 4.4.6.4 disku-
tiert. Außerdem treten Kontextwechsel durch Notwendigkeiten bei der Aktivitätsbearbeitung
auf, etwa wenn ein Dokument benötigt wird, das zunächst innerhalb der CIS-Umgebung des
Unternehmens identifiziert werden muss. Ein Kontextwechsel kann dann vermieden werden,
wenn alle Interaktionen mit Applikationen innerhalb einer Arbeitsumgebung stattfinden.
Da alle Tätigkeiten im Kontext einer Aktivität stattfinden, sollte der Aktivitätskontext stets im
kognitiven Wahrnehmungsbereich des Anwenders erhalten bleiben. Das Öffnen eines Repo-
sitories zum erstmaligen Zugriff auf ein Dokument erfolgt dann etwa im Kontext der Aktivi-
tät. Der Zugriff kann etwa aus der UBAM-Umgebung heraus über Lesezeichen möglich sein,
als auch aus der Aktivität heraus, z. B. für im Kontext der Aktivität häufig benötigte CIS. Wie
bereits in 4.3.2 beschrieben, sind als Elemente der Aktivitätsstruktur neben dem des Ziel-
dokuments bereits verschiedene Arten von Aktivitätskontexten vorgesehen, die in Form von
Verknüpfungen verwaltet werden. Über sie kann der effiziente Zugriff auf CIS umgesetzt
werden.
Ist das Dokument im Repository identifiziert, kann es der Aktivitätsstruktur etwa per Drag-
and-drop hinzugefügt werden. Wird der neue Aktivitätskontext später durch den Anwender
selektiert, kann auch das Zieldokument direkt im Kontext der Aktivität angezeigt und ggf.
bearbeitet werden, wenn der Editor in das UBAM System eingebettet ist. Die Vorteil-
haftigkeit des eingebetteten Kontextes wird auch durch Anwender bestätigt. So beschreiben
etwa González und Mark in einer Untersuchung des Managements von Aktivitäten, dass der
wichtigste Grund für die Nicht-Nutzung ihres Systems ist, dass die Aktivitätenliste nicht
permanent sichtbar ist.224
Wenn die UBAM-Umgebung nicht verlassen werden muss um mit anderen CIS zu arbeiten,
hat dies außerdem den Vorteil, dass diese CIS nicht um einen Integrationspunkt zum UBAM
System für das Harvesting erweitert werden müssen, um z. B. neue Aktivitäten anzulegen
oder dem aktuell in Bearbeitung befindlichen Zieldokument einen Aktivitätskontext hinzu-
zufügen. Denn diese Funktionalitäten können durch die permanent sichtbare UBAM-
Umgebung zur Verfügung gestellt werden. Außerdem ist es vorteilhaft, dass der Zustand der
Arbeitsumgebung so über Sitzungen hinweg konserviert werden kann. Dies verringert Rüst-
zeiten durch manuelle Wiederherstellung des Arbeitskontexts.
224 Vgl. [González/Mark 2004], S. 120.
140
4.4.6.6 Kontextuelle Kollaboration
Für die Bearbeitung von Aktivitäten im Team ist häufig viel Kommunikation und Koopera-
tion nötig. Diese Kollaborationshandlungen finden etwa durch Chat, E-Mail, CIS für asyn-
chrone Diskussionen oder Telefonate statt. Die Einbettung von Aktionen zur Durchführung
dieser Handlungen ermöglicht ein effizienteres Arbeiten im Team. So kann beispielsweise aus
dem Kontextmenü eines Elements der Aktivitätsstruktur eine E-Mail an den Besitzer oder
Editoren des Elements erstellt werden. Oder die Personen werden zu einer Application
Sharing Sitzung eingeladen. Auch das Erstellen von neuen Zieldokumenten im gleichen
Repository wie ein bereits existierendes Zieldokument, aus dem Kontextmenü eines Element-
dokuments, ist eine Möglichkeit der Effizienzsteigerung.
Ebenfalls können in die Aktivitätsstruktur eingebettete Kontextinformationen für den Anwen-
der einen positiven Effekt auf die Produktivität haben. Dies sind beispielsweise Präsenz-
informationen, der Gesprächsstatus des Telefons eines Kommunikationspartners oder Infor-
mationen darüber, welches Element einer Aktivitätsstruktur aktuell von welchem Anwender
bearbeitet wird225. Neben der reinen Initiierung von Kollaborationshandlungen sollte es
ebenfalls möglich sein, dass beim Anlegen eines neuen Zieldokuments für das Anlegen des
Aktivitätskontext eine entsprechende Verknüpfung und ggf. Meta-Daten zur Verfügung
stehen. Dies ermöglicht es dem UBAM System, den Aktivitätskontext im gleichen Arbeits-
schritt wie das Erstellen des Dokuments in der Aktivitätsstruktur anzulegen. Wenn wie in
Abschnitt 4.4.5.4 beschrieben Inhalte in der Aktivitätsstruktur gespeichert werden dürfen,
müssen diese ebenso vom CIS an das UBAM System zurückgegeben werden können, etwa
der Inhalt eines Chats, der aus der Aktivitätsstruktur heraus gestartet wurde.
4.4.7 Verfügbarkeit
4.4.7.1 Inhalte in lokalen und privaten Repositories
Für die Aktivitätsbearbeitung im Team ist es notwendig, dass jedes Teammitglied Zugriff auf
die Zieldokumente hat, auf die in der Aktivitätsstruktur verwiesen wird. Daher ist zu vermei-
den, dass Verknüpfungen zu Zieldokumenten zur Verfügung stehen, die sich in lokalen oder
privaten Repositories befinden, wie etwa die lokale Festplatte des Anwenders oder die PIM-
Umgebung. Soll ein Aktivitätskontext angelegt werden, auf den neben dem aktuellen
Anwender weitere Teammitglieder zumindest lesenden Zugriff haben, muss das UBAM
System den aktuellen Anwender darauf hinweisen, dass diese Personen keinen Zugriff auf das
Zieldokument haben.
225 Vgl. etwa [Muller et al. 2004] oder [Silva Filho et al. 2006].
141
Abbildung 4-16: Alternativen des gemeinsamen Zugriffs auf private Dokumente
Private Daten müssen im Zuge dieser Aktion dem Team zur Verfügung gestellt werden
können. Dies kann entweder geschehen, indem der Inhalt des Zieldokuments in das Element-
dokument kopiert wird, oder indem das private Zieldokument als neues Zieldokument in
einem CIS abgelegt wird, und auf dieses neue Zieldokument der Aktivitätsstruktur der
entsprechende Aktivitätskontext hinzugefügt wird. Für eine Diskussion der Alternativen siehe
Abschnitt 4.4.5.4. Hierbei sind auch Gastanwender (vgl. Abschnitt 4.4.6.1) zu
berücksichtigen. Damit die Ablage privater Zieldokumente in einem gemeinsam genutzten
CIS oder ECM System möglichst effizient möglich ist, sollte für eine Aktivität ein Standard-
Repository definiert werden können. Außerdem kann das UBAM System aufgrund von Meta-
Daten des Zieldokuments Vorschlagswerte für mögliche Ziel-Repositories anbieten. Erkennt
das System beispielsweise, dass mehrere E-Mails eines Absenders bereits im gleichen
Repository abgelegt wurden, ist die Wahrscheinlichkeit hoch, dass auch die nächste E-Mail
dort abgelegt werden soll.
4.4.7.2 Offline-Fähigkeit
Bei Wissensarbeitern muss ein UBAM System als zentrales Verwaltungswerkzeug von
Aktivitäten, ähnlich wie PIM Applikationen, über volle Offline-Fähigkeit verfügen. Die
Aktivitätsstruktur muss dabei in vollem Umfang bearbeitet werden können. Grund dafür ist,
dass der Zugriff auf einen Server auch heute noch nicht permanent gegeben ist. Insbesondere
in ländlichen Gebieten ist in Deutschland für 13,3% der Haushalte kein leistungsfähiger
Breitband Internetanschluss verfügbar226. Auch auf Zugreisen steht häufig kein Zugriff aufs
226 Definition: 1 MBit/s und mehr, vgl. [Bundesministerium für Wirtschaft und Technologie 2010], S. 6.
142
Internet zur Verfügung, auf Flugreisen sogar fast gar nicht. Diese Anforderung spricht erneut
für eine Desktop-Applikation, da Browser Applikationen üblicherweise nicht offline
verfügbar sind.
Damit der Anwender seine Aktivitäten in vollem Umfang weiter bearbeiten kann, sollten auch
Zieldokumente offline verfügbar sein. Vor dem Starten des Offline-Modus des UBAM
Systems muss daher eine Benachrichtigung aller Repositories erfolgen können, alle oder
einen Teil ihrer Dokumente offline zur Verfügung zu stellen. Dies wird üblicherweise nicht
für alle Repositories der Fall sein, insbesondere für Repositories mit Browser UI. Können
nicht die vollständigen Dokumente offline zur Verfügung gestellt werden, sollte das UBAM
System zumindest eine Vorschauansicht der Zieldokumente speichern, so dass der Anwender
den Inhalt zumindest lesen, wenn auch nicht bearbeiten kann.
4.4.7.3 Mobile Geräte
Die Popularität mobiler Geräte ist heutzutage enorm groß. Mobile Geräte werden neben der
Nutzung für PIM Funktionalitäten verstärkt auch für Applikationen verwendet, beispielsweise
für die Nutzung sozialer Netze. So gibt etwa Facebook, das größte soziale Netzwerk der Welt
an, dass mehr als 43% seiner 800 Millionen Anwender, das Netzwerk mit mobilen Geräten
nutzen.227 Hinzu kommt, dass leistungsfähige Smartphones und Tablets auch die Ausführung
komplexer Applikationen ermöglichen. Der Markt für Smartphones erfährt seit Jahren zwei-
stellige Zuwachsraten, Gartner spricht in Q2/2011 gar von einem Anstieg der Verkäufe von
74% gegenüber dem Vorjahresquartal, so dass Smartphones nun einen Marktanteil von 25%
erreichten.228 Bei Tablets stellt IDC im gleichen Quartal gar eine Zuwachsrate von über 300%
gegenüber dem Vorjahr fest.229
Aufgrund der hohen Verfügbarkeit und Popularität sollte es möglich sein, dass das UBAM
System auf mobilen Endgeräten zur Verfügung steht, etwa weil Aktivitäten für das Zeit-
management relevante Informationen wie Zieldaten enthalten, die nicht verpasst werden
dürfen. Bereits 2004 berichtet etwa Harrison, dass Anwender verschiedene Strategien ver-
folgen, um Erinnerungen in möglichst vielen Umgebungen redundant zur Verfügung zu
haben, unter anderem aufgrund der Angst vor Vergessen und damit einhergehender möglicher
sozialer Konsequenzen wie öffentlicher Bloßstellung.230 Die Möglichkeit, die Aktivitäts-
struktur in vollem Umfang bearbeiten zu können ist wünschenswert.
227 350 Mio. mobile Anwender, vgl. http://www.facebook.com/press/info.php?statistics [07.10.2011].
228 Vgl. http://www.gartner.com/it/page.jsp?id=1764714 [07.10.2011].
229 Vgl. http://www.idc.com/getdoc.jsp?containerId=prUS23034011 [07.10.2011].
230 Vgl. [Harrison 2004], S. 2.
143
Die zusätzliche Funktionalität, auch für Zieldokumente eine Offline-Verfügbarkeit anzubieten
wird üblicherweise in Unternehmen aufgrund der Vielzahl unterschiedlicher Systeme und der
eingeschränkten Möglichkeiten von Mobilgeräten nicht möglich sein. Durch die exzellenten
Browser aktueller Smartphones kann eine Alternative sein, ein Browser UI als Alternative zur
Desktop-Applikation bereitzustellen. Auch eine Synchronisation der Aufgaben aus der
Aktivitätsstruktur in die native PIM-Umgebung des Gerätes sollte berücksichtigt werden.
4.5 Technische Anforderungsanalyse
Aus den Charakteristika des kollaborativen Arbeitsplatzes sowie den funktionalen
Anforderungen ergeben sich Empfehlungen für technische Anforderungen. Von diesen
Empfehlungen kann in Abhängigkeit der Unternehmensszenarien abgewichen werden, deren
Diskussion in Abschnitt 4.7.2 erfolgt.
4.5.1 Speicherung von Aktivitätsstrukturen
Aktivitätsstrukturen können entweder explizit in einem Repository gespeichert werden, oder
durch das UBAM System zum Zeitpunkt des Zugriffs aus den für einen Anwender konfigu-
rierten Repositories generiert werden. Dabei kommt es zur Anwendung individuell konfigu-
rierter Regeln etwa für die Sortierung von Elementen der Aktivitätsstruktur. Ein Vorteil der
automatisierten Generierung liegt darin, dass mit sehr geringem Aufwand für den Anwender
die Aktivitätsstruktur generiert wird, da dieser sie nicht erstmalig manuell zusammenstellen
muss. Wenn beispielsweise in einem WfMS ein neues Dokument zur Bearbeitung vorgelegt
wird, erscheint die Aufgabe automatisch in der Aktivitätsstruktur des Anwenders.
Voraussetzung der dynamisch generierten Struktur ist jedoch die Bereitstellung von Informa-
tionen durch jedes benötigte Repository, die speziell für die Verwendung in einem UBAM
System aufbereitet sind. Da es keinen Standard für die Bereitstellung derartiger Informationen
gibt, müsste jedes Repository angepasst werden, um Informationen bereitzustellen. Alternativ
müsste das UBAM System speziell für den Zugriff auf jedes der Repositories befähigt wer-
den, etwa durch Programmierung einer Schnittstelle auf Basis einer API, die das Repository
bereitstellt. Beides würde einen hohen Aufwand für die Implementierung bedeuten. Hinzu
kommt, dass aufgrund der hohen Dynamik des kollaborativen Arbeitsplatzes häufig nicht
antizipiert werden kann, welche Repositories von welchen Anwendern benötigt werden.
Eine weitere Herausforderung der Implementierung ist es, dass eine Reihe von Meta-Daten
der Aktivitätsstruktur gespeichert werden müssen, wie beispielsweise die Reihenfolge der
Elemente der Aktivitätsstruktur, die Verstichwortung, die Teammitglieder mit Zugriff auf die
Aktivität und viele mehr. Zur Speicherung würde jeder Anwender Editorenrechte für jedes
144
durch ihn genutzte Ziel-Repository benötigen. Eine Offline-Fähigkeit wäre zudem nur dann
möglich, wenn alle Repositories offline verfügbar sind, denn sonst besteht kein Zugriff auf die
Aktivitätsstruktur, die ja nicht lokal, sondern verteilt über die Ziel-Repositories gespeichert
ist.
Ein weiteres Argument gegen die dynamische Generierung ist die Performance. Für jede
einzelne Aktion des UBAM Systems müssten Abfragen gegen eine Vielzahl an Repositories
durchgeführt werden, was die Repositories stark belasten würde. Bei expliziter Speicherung
hingegen müssen für Basisfunktionalitäten die Ziel-Repositories weder angepasst werden,
noch müssen zu UBAM Nutzung Abfragen erfolgen (vgl. Abschnitt 4.3.2). Zusammenfassend
ist zu empfehlen, die Aktivitätsstruktur explizit in einem Repository zu speichern und nicht
dynamisch zu generieren.
4.5.2 Modularisierung und Portalkonzept
Wissensarbeiter sind am kollaborativen Arbeitsplatz mit einer Vielzahl an Informations-
quellen innerhalb und außerhalb des Unternehmens konfrontiert. Zur Standardisierung in
Bezug auf die Benutzung unterschiedlicher Systemlandschaften haben in der vergangenen
Dekade Portaltechnologien beigetragen. Portale stellen den Anwendern basierend auf deren
Rollen im Unternehmen unterschiedliche Applikationen und Repositories zur Verfügung und
verfolgen wie in Abschnitt 4.4.6 gefordert den Ansatz eines zentralen Zugriffsbereichs auf
alle benötigten Informationen.
Der zentrale Zugriffspunkt konnte jedoch bis heute auch durch Portale nicht hergestellt
werden. Zunächst kann die IT des Unternehmens nicht alle Anforderungen an den kollabora-
tiven Arbeitsplatz des individuellen Wissensarbeiters antizipieren. Dies soll dadurch
adressiert werden, dass fortgeschrittenen Anwendern die Möglichkeit eingeräumt werden
kann, selbst Applikationen der Arbeitsoberfläche hinzuzufügen. Es können jedoch nur Appli-
kationen hinzugefügt werden, deren UI als Portlet zur Verfügung steht. Alle anderen
Repositories, insbesondere die, für deren Zugriff eine Desktop-Applikationen benötigt wird,
können nicht integriert werden. Außerdem zeigte sich, dass Anwender im Laufe der Zeit
mehrere Portalserver benötigten, um ihre Arbeit zu erledigen. Dies wird als Portal
Proliferation231 bezeichnet.
Trotz neuer Entwicklungen wie AJAX, Flash oder HTML5 sind Browser-basierte Applikatio-
nen zudem klassischen Desktop-Applikationen funktional unterlegen und wie bereits mehr-
fach diskutiert noch nicht für den Wissensarbeiter optimiert. Zwar werden klassische Desk-
231 Vgl. [Hahnl 2004].
145
top-Applikationen zunehmend durch Cloud-basierte Applikationen ergänzt. Diese sind aus
Anwendersicht von der Desktop-Applikation jedoch kaum zu unterscheiden. Der Unterschied
liegt lediglich im Deployment-Modell und der Softwarepflege. Sie werden daher im Folgen-
den nicht gesondert betrachtet.
Das erfolgreiche Portalkonzept muss aufgrund der bestehenden Nachteile also erweitert
werden. Für das UBAM UI wird die Form der Desktop-Applikation gewählt, welche hin-
reichend modular aufgebaut ist, um ein Portalkonzept umzusetzen, und gleichzeitig Desktop-
Applikationen und Webapplikationen zu integrieren, die nicht über ein Portlet UI verfügen.
Die Technologie steht heute in modernen Betriebssystemen, Web Applikationen und auch in
Plattformen zur Entwicklung von Desktop-Applikationen zur Verfügung. In Microsoft
Windows ist dies etwa das COM sowie das ActiveX Konzept. In Web Applikationen sind dies
etwa Portlets oder Widgets, und bei Desktop-Applikationen sind dies Plugin Konzepte, wie
etwa das Konzept der Open Source Rich Client Plattform Eclipse232. Für die Eclipse Plattform
stehen generische Container zur Verfügung, um auch Desktop-Applikationen einzubetten
etwa von der Firma OpenSpan233.
Zur Integration von Applikationen, die bereits für Portalserver zur Verfügung stehen, sollte
die Plattform Portlets des WSRP Standards unterstützen. Außerdem sollte die Umgebung über
einen eingebetteten Browser verfügen, so dass Web Applikationen unmodifiziert integriert
werden können. Mit einer solchen Technologie kann ebenfalls das Konzept des zentralen
Zugriffbereichs (vgl. Abschnitt 4.4.6) und insbesondere das Konzept der ständig im Arbeits-
kontext sichtbaren Aktivitätenliste (vgl. Abschnitt 4.4.6.5) umgesetzt werden. Damit das
UBAM Werkzeug mit den eingebetteten Komponenten kommunizieren kann, etwa um Meta-
Daten auszutauschen (vgl. etwa Abschnitt 4.4.5.5), sollte es eine Kommunikationsschnittstelle
zwischen den Komponenten geben. Für eine solche Kommunikation ist bei den meisten
Portal-Servern ein proprietärer Mechanismus vorhanden. Auch die Kommunikationsstandards
WSRP 2.0234 und Portlet Specification 2.0235 ermöglichen diese Kommunikation, deren
Unterstützung in vielen Portal-Servern bereits vorhanden ist.
In Umgebungen, die über eine solche Schnittstelle verfügen wird das Kombinieren von
Applikationen oder Applikationskomponenten zu einer flexiblen, Anwender-spezifischen
Arbeitsumgebung als Integration on the Glass bezeichnet. Diese Bezeichnung dient der
Abgrenzung zu Backend Integrationsmethoden wie SOA oder EAI. Die resultierende Appli-
232 Vgl. http://www.eclipse.org [07.10.2011].
233 Vgl. http://www.openspan.com [07.10.2011].
234 Vgl. [Thompson 2008].
235 Vgl. [Hepper 2008].
146
kation wird als Composite Application oder Mashup bezeichnet. Auch wenn Infrastrukturen
dieser Art noch nicht sehr verbreitet sind, erwartet etwa Gartner in einer Analyse aus dem
Jahr 2009 für die Etablierung im Massenmarkt einen Zeitraum von 2-5 Jahren.236
4.5.3 Schnittstellen und API
Die Nutzung von Standards führt zur Senkung der Spezifität von Transaktionen und einer
Reduktion der Komplexität zwischen Systemen, die Gesamtkosten für die Integration können
sinken. Dies ist eine wichtige Voraussetzung, wenn wie gefordert alle benötigten Systeme
sowohl zwischen Unternehmen, als auch innerhalb eines Unternehmens integriert werden
sollen. Die wichtigsten Schnittstellen im Kontext dieser Arbeit ergeben sich aus der
funktionalen Anforderungsanalyse. So ist die Voraussetzung für die Föderation mehrerer
UBAM Systeme eine Schnittstelle für den Zugriff auf die Aktivitätsstruktur. Da in jedem der
Systeme Aktivitäten modifiziert werden können, muss die Schnittstelle alle möglichen
Operationen sowohl lesend als auch schreibend ermöglichen. Schreibende Operationen sind
etwa das Erstellen und Löschen von Aktivitäten oder die Bearbeitung von Elementen der
Aktivitätsstruktur.
Zur Integration von Systemen sowohl auf Backend Ebene, als auch für Dienste im Internet
haben sich in Unternehmen Web Services und serviceorientierte Architekturen (SOA)
etabliert (vgl. Abschnitt 3.3.1). Neben den Web Services Protokollen hat zur Integration von
Web-basierten Applikationen das REST Protokoll237 eine große Bedeutung, da dessen Hand-
habung einfacher ist als die native Verwendung von Web Services Protokollen wie SOAP und
WSDL. Um auf Inhalte zuzugreifen ist das RSS Protokoll sehr verbreitet. Gartner erwartet in
einer Analyse aus dem Jahr 2009, dass innerhalb von 2-5 Jahren die meisten Produkte der
Bereiche Content Management, Enterprise Portals und Collaboration Suites RSS Funktionen
beinhalten werden.238 RSS ermöglicht jedoch lediglich lesenden Zugriff auf Daten. Daneben
bietet das Atom Protokoll ähnliche Möglichkeiten (vgl. Abschnitt 2.3.2.4), unterstützt neben
dem Abonnieren von Inhalten als Atom Publishing Protocol (AtomPub)239 auch deren
Publikation. Atom ist daher gut als Bi-direktionales Integrationsprotokoll geeignet. Zum rein
lesenden Zugriff hat sich durch die zunehmende Verbreitung von AJAX in Web Applikatio-
nen auch das XML-basierte Datenformat JSON240 als sehr erfolgreich erwiesen. Die Verfüg-
barkeit einer JSON Schnittstelle sollte daher ebenfalls geprüft werden. Je nach Integrations-
236 Vgl. Enterprise Mashups in [Gilbert et al. 2009], S. 15 und [Thompson et al. 2009], S. 53.
237 Vgl. [Fielding 2000].
238 Vgl. [Gilbert et al. 2009], S. 36.
239 Vgl. [Gregorio/de hÓra 2007].
240 Vgl. [Crockford 2006].
147
szenario sollten daher als Schnittstellen Web Services, REST und Atom bereitstehen, um auf
das UBAM System programmatisch zuzugreifen.
Um eine Integration im Bereich des UI zu implementieren ist außerdem das OpenSocial
Protokoll241 wichtig. Neben dem Informationsaustausch ist dabei die Integration von Gadgets
möglich. Darüber kann eine Web Applikation eine einfache Version des eigenen UIs bereit-
stellen, so dass wichtige Funktionen im Kontext einer anderen Applikation ausgeführt wer-
den.242 Ein solches Gadget kann über den Web Application Service der UBAM-Umgebung
als alternatives UI zum kompletten Browser UI bereitgestellt werden.
Wenn das UBAM System die Speicherung von Inhalten zulässt kann es notwendig werden,
dass die Inhalte unternehmensintern in die ECM Infrastruktur eingebunden werden müssen.
Hier ist es zu empfehlen, den Zugriff auf das UBAM Repository als Java Content Repository
(JCR)243 zu ermöglichen, das von allen wichtigen ECM System Herstellern unterstützt wird
oder eine Unterstützung geplant ist. Gleiches gilt für den Standard CMIS244. Auch die
Integration von PIM Systemen muss berücksichtigt werden. Die Möglichkeit der Erzeugung
einer E-Mail aus dem UBAM System heraus ist für vielfältige Zwecke notwendig,
beispielsweise um Notifications über Ereignisse zu versenden, periodische
Zusammenfassungen zu verteilen oder Inhalte weiter zu leiten. Daneben werden in der
Aktivität Aufgaben generiert. Diese müssen ggf. in PIM Systeme verteilt werden können.
Aktivitätsspezifische Termine und Teamkalender müssen im persönlichen Kalender
angezeigt, und ggf. auch auf Mobilgeräte synchronisiert werden. Für Termine, Aufgaben und
Einträge im persönlichen Journal steht das iCalendar245 Format zur Verfügung. Zum
Austausch von Adressbuch Informationen ist das vCard246 Format üblich.
Um den Zugriff auf Aktivitäten zu beschränken und die Anforderungen aus Abschnitt 4.4.5.3
umzusetzen, sollte zudem das LDAP247 Protokoll unterstützt werden. Es hat sich als Standard
für den Zugriff auf Directory Dienste etabliert und ermöglicht so die Authentifizierung und
Authentisierung von Anwendern. Dies ist eine Voraussetzung, um die Autorisierung eines
Anwenders zu prüfen und den Zugriff auf Elemente der Aktivitätsstruktur zu steuern. Wenn
das Einsatzszenario eine Authentifizierung mit einer großen Anzahl an Systemen erfordert,
241 Vgl. [OpenSocial Foundation 2010].
242 Vgl. [Sala et al. 2011], Abschnitt 2.2.1.
243 Formell „Content Repository for Java Technology API“, vgl. [Nuescheler 2002].
244 Vgl. [Brown et al. 2010].
245 Vgl. [Desruisseaux 2009].
246 Vgl. [Dawson/Howes 1998].
247 Vgl. [Sermersheim 2006].
148
sollte außerdem die Unterstützung von OpenID248 in Betracht gezogen werden. Es handelt
sich dabei um ein breit akzeptiertes, dezentrales System für Web-basierte Authentifizierung.
Für die Anbindung etablierter Kollaborationssysteme sollten außerdem Spezialprotokolle
berücksichtigt werden, etwa SIP/SIMPLE249 für Instant Messaging und Unified
Communications. Für weitere etablierte CSCW Konzepte existieren weitere Standards, die an
dieser Stelle jedoch nicht weiter berücksichtigt werden sollen.
4.6 Architekturentwurf
Im Schwerpunkt des Architekturentwurfs steht die Entwicklung eines Modells für ein UBAM
System, welches das komplexe Zusammenspiel potenziell vorhandener Systeme am kollabo-
rativen Arbeitsplatz vereinfacht darstellt. Das Modell soll außerdem das verdeutlichen,
welche Dienste ein UBAM System aufweisen sollte um in der Lage zu sein, die zuvor
beschriebenen Anforderungen umzusetzen. Für eine Vorschau auf die hergeleitete Architektur
vgl. Abbildung 4-24.
4.6.1 Grundlegende Architekturmerkmale
4.6.1.1 Trennung von Aktivitäten- und Ziel-Repository
Wie in Abschnitt 4.4.5.4 diskutiert wird als grundlegendes Architekturparadigma eine
logische Trennung zwischen Ziel-Repositories mit Inhaltsdokumenten, und dem Repository
des UBAM Systems angenommen, das die Elementdokumente oder die Aktivitätsstruktur-
Dokumente enthält. Nur so kann sichergestellt werden, dass das Konzept ein Szenario um-
setzt, bei dem jedes Dokument, das geschäftsrelevante Informationen enthält, durch die ECM
Infrastruktur des Unternehmens verwaltet wird. Eine Erweiterung der Architektur um die
Speicherung von Aktivitäts-temporären Inhalten, oder die Möglichkeit, neben der Verwaltung
von Verknüpfungen in Ausnahmefällen auch Inhalte im Elementdokument zu verwalten, ist
trivial und bleibt daher hier unberücksichtigt.
Durch die logische Trennung werden im UBAM Repository lediglich Verknüpfungen zu
Zieldokumenten und Meta-Daten der Aktivitätsstrukturen verwaltet. Eine Verknüpfung
erfolgt in Form eines URIs (vgl. Abschnitt 2.2.2.3). In aktuellen Betriebssystemumgebungen
enthält der URI kodifiziert den zugehörigen Editor, der für die Anzeige und Bearbeitung des
Zieldokuments benötigt wird. Dieser wird als Zieldokument-Editor bezeichnet. Die
Zuordnung kann beispielsweise über eine Dateiendung oder eine Protokollbezeichnung wie
“http://” erfolgen, zu der im Betriebssystem der entsprechende Zieldokument-Editor
248 Vgl. [Fitzpatrick et al. 2007].
249 Vgl. [Campbell et al. 2002].
149
registriert ist. Wird auf einen URI zugegriffen, lokalisiert das Betriebssystem den Editor und
lädt automatisch das in der URI bezeichnete Zieldokument aus dem ebenfalls im URI kodifi-
zierten Ziel-Repository.
Über Anker (engl. Anchor) kann ein Dokument-URI eine weitere Kontextinformation ent-
halten um zu kennzeichnen, dass der Zieldokument-Editor eine bestimmte Stelle im Ziel-
dokument anzeigen soll. Über einen URI können neben Dokumenten auch Ansichten geöffnet
werden. Enthält ein Ansichts-URI eine Ankerinformation, kann aus der Liste dargestellter
Dokumente eine bestimmte Position angesprungen werden. Diese Kontextinformation er-
möglicht es beispielsweise bei klassifizierter Darstellung der Dokumente, eine Verknüpfung
auf mehrere semantisch zusammengehörige Zieldokumente zu verwalten.
Abbildung 4-17: Einbettung von Dokumenten in den UBAM Client
Abbildung 4-17 zeigt eine Übersicht der Architektur eines UBAM Clients. Das UBAM
Backend verwaltet, neben weiteren Elementen der Aktivitätsstruktur und der Beziehung der
Elemente untereinander, die Aktivitätskontexte relevanter Zieldokumente in Form von Ver-
knüpfungen. Das UBAM Repository ist Teil des Backends und wird hier nicht explizit
dargestellt. Die Aktivitätskontexte werden zur Generierung der Aktivitätsstrukturen, und
resultierend der gesamten Aktivitätenliste, die in der Aktivitätenansicht dargestellt ist, ein-
gesetzt. Wenn ein Aktivitätskontext in der Aktivitätenansicht durch den Anwender selektiert
wird, wird das zugehörige Zieldokument über die Verknüpfung in das UBAM UI geladen.
Dazu wird der Zieldokument-Editor gestartet und eingebettet im Editor Bereich des UBAM
150
UI angezeigt. Durch die Einbettung der Ziel-Applikation kann die Aktivitätenansicht an-
gezeigt werden, während gleichzeitig ein Dokument am Bildschirm dargestellt wird. Dies
verringert die Anzahl notwendiger Kontextwechsel (vgl. Abschnitt 4.4.6.5). Der Editor
Bereich kann außerdem verwendet werden, um ein erweitertes UBAM UI mit zusätzlichen
Funktionen anzuzeigen die etwa für umfangreiche Arbeiten mit Aktivitätsstrukturen benötigt
werden, die aber selten zum Einsatz kommen, und deshalb nicht in der Aktivitätenansicht
vorhanden sind.
4.6.1.2 Verwaltung des Client Status
Um die Offline-Arbeit zu unterstützen muss das UBAM System die Aktivitätsstrukturdaten in
einem lokalen Repository speichern können. Damit bei Verfügbarkeit einer Verbindung zum
Server die lokalen Änderungen nicht verloren gehen ist es notwendig, dass das lokale
Repository bidirektional mit der Server Version des UBAM Repositories synchronisieren
kann. Beim Arbeiten ohne Netzverbindung benötigt der Anwender zudem Zugriff auf ver-
knüpfte Zieldokumente. Aufgrund der Vielzahl verfügbarer Repositories und Applikationen
kann nicht das UBAM System dafür sorgen, dass Zieldokumente offline zur Verfügung
stehen. Jedes Ziel-Repository muss selbst dafür sorgen, dass der Offline-Status festgestellt
wird, und dass in diesem Fall der Zieldokument-Editor auf ein lokales Repository zugreifen
muss. Bei offline vorgenommenen Änderungen muss außerdem eine Synchronisation durch-
geführt werden, wenn wieder eine Verbindung möglich ist (vgl. Abbildung 4-18).
Abbildung 4-18: Offline-Architektur
Zunehmend lassen sich auch Browser-basierte Applikationen offline betreiben, indem die
Arbeitsumgebung es ermöglicht, auf dem Client den dafür notwendigen Web- oder Portlet-
151
Container zu betreiben sowie ein lokales Repository anzusprechen. Der Offline-Modus des
Clients ist nur ein Sonderfall der Möglichkeit, verschiedene Ziel-Repositories für das gleiche
Zieldokument anzusprechen. So kann beispielsweise beim Ausfall eines Servers ein
alternativer Server zur Verfügung stehen. Oder durch Einwahl in das Virtual Private Network
des eigenen Unternehmens steht der Zugriff auf öffentliche Server nicht mehr zur Verfügung.
Es gibt also eine Vielzahl an Situationen, die dazu führen können, dass einzelne Repositories
nicht angesprochen werden können. Beim Aufrufen eines URIs wird daher grundsätzlich ein
URI Proxy angesprochen.
Dieses Modul ist dafür zuständig in Abhängigkeit vom Status des Clients den aufgerufenen
URI ggf. zu modifizieren. Das Modul kann für jede Kombination aus Applikation und Ziel-
Repository eine Regel speichern, aufgrund der notwendige Modifikationen in Abhängigkeit
vom Client Status vorgenommen werden können. Alternativ kann ein zusätzlich zur Standard
Verknüpfung gespeicherter URI für einen speziellen Client Modus wie den Offline-Modus
gespeichert werden. Der URI muss nicht für jedes System konfiguriert werden. Einige Ziel-
dokument Editoren verfügen über die Funktionalität, einen URI selbstständig zu modifizieren.
Versucht der Editor auf ein Repository zuzugreifen, das nicht verfügbar ist, sucht er automa-
tisch nach einem alternativen Repository, welches das zu ladende Dokument enthält. Dies
kann auch ein Offline-Repository sein.
Wenn ein Repository und dessen Zieldokument-Editor keinen Offline-Modus unterstützen,
kann der UBAM Client eine Vorschau auf das Zieldokument im Elementdokument speichern
(vgl. Abschnitt 4.4.7.2). So kann der Anwender zumindest lesend auf einen Teil der Inhalte
zugreifen. Dies ist jedoch problematisch für den Fall, dass Zugriffsrechte im Ziel-Repository
den lesenden Zugriff nicht für alle Mitglieder der Aktivität zulassen. So haben evtl. nicht
autorisierte Personen Zugriff auf den Inhalt eines Zieldokuments. Hier muss in der UBAM
Umgebung entweder sichergestellt sein, dass eine Synchronisation der Zugriffsinformationen
mit der UBAM Umgebung erfolgen kann (4.4.5.5), oder dass die Vorschau Information nicht
gespeichert wird, wenn dieser Fall vorliegt.
4.6.1.3 Ansichten von Aktivitäten
Die Anforderungen an das individuelle Aktivitätenmanagement machen es notwendig,
unterschiedliche Ansichten auf die Struktur einer Aktivität zu ermöglichen. Die Struktur einer
Aktivität ist maßgeblich durch semantische Zusammenhänge bestimmt. So werden komplexe
Aktivitäten in kleinere, einfacher beherrschbare Teilaktivitäten mit Aufgaben zerlegt. Es
handelt sich bei der Sicht auf die Elemente einer Aktivitätsstruktur also nicht um eine auto-
152
matisch erzeugte Sortierung, sondern eine durch Anwender arbiträr festgelegte Reihenfolge.
Auch die hierarchische Beziehung zwischen Elementen ist arbiträr. Im Folgenden wird die
Reihenfolge sowie die hierarchische Beziehung von Elementen als Hierarchie bezeichnet.
Die Reihenfolge der Aktivitäten in der Aktivitätenansicht hingegen kann, aber muss nicht
arbiträr sein. Hier kann es auch sinnvoll sein, nach bestimmten Kriterien automatisiert
sortieren zu lassen, etwa nach Zieldatum, Priorität oder klassifiziert nach gemeinsamen Meta-
Daten. Dennoch kann auch hier der Wunsch des Individuums nach arbiträrer Reihenfolgen
vorhanden sein, so dass diese Möglichkeit berücksichtigt werden sollte. Auf die Hierarchie
der Aktivitätenansicht wird hier nicht weiter eingegangen, da sich die Diskussion nicht von
der einer einzelnen Aktivitätsstruktur unterscheidet.
Während der Explikation einer Aktivität sind üblicherweise lediglich eine oder wenige
Personen an der Bearbeitung der Aktivitätsstruktur beteiligt. Es gibt daher zunächst auch nur
eine individuell definierte Hierarchie der Aktivität. Diese wird als Standard-Hierarchie (engl.
Default Hierarchy) bezeichnet. Für den Umgang mit Modifikationen der Hierarchie gibt es
verschiedene Möglichkeiten. Bearbeitet ein Anwender mit Bearbeitungsrechten für die
gesamte Aktivität die dargestellte Hierarchie im UBAM Client, kann etwa eine Modifikation
der Standard-Hierarchie erfolgen. Das bedeutet, dass auch alle anderen Teammitglieder die
Modifikation der Hierarchie angezeigt bekommen. Alternativ kann eine Kopie der Struktur
angefertigt werden. Der Anwender arbeitet dann mit seiner privaten Kopie der Hierarchie.
Diese wird als Privat-Hierarchie bezeichnet. Zusätzlich kann er bei Bedarf in eine Ansicht
wechseln, welche die Standard-Hierarchie darstellt. Weitere Mitglieder des Teams arbeiten
entweder mit der Standard-Hierarchie, oder ebenfalls mit jeweils einer Privat-Hierarchie.
Der Anwender muss also lediglich dann eine Entscheidung treffen, ob er eine private Kopie
der Standard-Hierarchie anlegen möchte, wenn er die Standard-Hierarchie modifizieren
möchte, noch nicht über eine Privat-Hierarchie für die aktuelle Aktivität sowie über
Bearbeitungsrechte der Aktivität verfügt. Über entsprechende persönliche Voreinstellungen
kann diese Entscheidung auch gespeichert oder über eine administrative Richtlinie (engl.
Policy) vorkonfiguriert werden. Alle diskutierten Möglichkeiten zu filtern oder zu sortieren
(vgl. Abschnitt 4.4.3) sind sowohl in der Privat-, als auch in der Standard-Hierarchie sinnvoll.
Der Anwender kann also beispielsweise seine Privat-Hierarchie so filtern, dass nur hoch
priorisierte Aufgaben mit Zieldatum ‚heute’ angezeigt werden.
153
Abbildung 4-19: Beispiel für Standard- und Privat-Hierarchie sowie Aufgabenliste
Findet eine Modifikation der Hierarchie statt, wenn der Anwender in der Darstellung der
Privat-Hierarchie arbeitet, erfolgt diese nur an der Privat-Hierarchie. Die Standard-Hierarchie
bleibt unverändert. Arbeitet er im aktuellen Arbeitskontext hingegen in der Darstellung der
Standard-Hierarchie, so werden durchgeführte Änderungen in die Standard-Hierarchie
übernommen, vorausgesetzt der Anwender verfügt über die entsprechenden Rechte. Ist dies
nicht der Fall, wird eine Modifikation der Hierarchie unterbunden.
Standard- und Privat-Hierarchie können also verschieden aussehen. Auch das Entfernen
kompletter Teilaktivitäten, die beispielsweise für den Anwender nicht relevant erscheinen ist
möglich, ohne diese Elemente der Teilaktivitätsstruktur aus der Standard-Hierarchie zu
entfernen. Abbildung 4-19 zeigt dies beispielhaft. So wurden etwa T1.2.1 und T1.3 entfernt
und die Aufgaben in T1.2 umsortiert. Es ist jedoch nicht möglich, dass die Privat-Hierarchie
Elemente enthält, die nicht in der Standard-Hierarchie enthalten sind. Ansonsten wäre etwa
der Zugriff auf Elemente durch einen Administrator nicht möglich. Wenn der Anwender ein
neues Element in der Privat-Hierarchie anlegt, wird dieses unter dem gleichen Eltern-Element
auch in der Standard-Hierarchie hinzugefügt. Dient das Element lediglich seiner individuellen
Arbeitsorganisation und soll es für andere Anwender nicht sichtbar werden, so muss er den
Zugriff auf das Element beschränken. Dann ist es zwar in der Standard-Hierarchie enthalten,
wird aber anderen Anwendern nicht angezeigt.
Zu berücksichtigen ist außerdem, dass Änderungen an Elementen der Aktivitätsstruktur zwar
keine Auswirkungen auf die Hierarchie haben, denn die Hierarchie legt lediglich die
Beziehung und die Reihenfolge von Elementen der Aktivitätsstruktur fest. Aber Änderungen
wirken sich auf alle Darstellungen der Elemente in allen Hierarchien aus. Wird beispielsweise
154
die Bezeichnung der Aufgabe A1.2.2 modifiziert, wirkt sich diese Änderung in allen
Ansichten und in allen Hierarchien der Aktivitätsstruktur aus, also sowohl in S1, als auch in
P1.1 sowie allen anderen Privat-Hierarchien. Denn die Modifikation bewirkt eine Änderung
von Daten des Elementdokuments, aus denen die Darstellung der Aktivitätsstruktur generiert
wird.
Wie bereits diskutiert ist insbesondere die Aufgabenbearbeitung von herausragender Bedeu-
tung. Wenn die Aufgaben z. B. durch Filterung ohne den Kontext der Aktivitätshierarchie
angezeigt werden, muss auch hier eine arbiträre Reihenfolge durch den Anwender festlegbar
sein, da er sonst nicht dediziert planen kann, in welcher Reihenfolge er die Aufgaben aus-
führen möchte. Denn die Ausführungsreihenfolge von Aufgaben hängt nicht notwendiger-
weise von der Position der Aufgaben in der Hierarchie der entsprechenden Aktivitäten ab.
Beispielsweise können Faktoren wie die aktuell verfügbare Zeit des Anwenders bestimmen,
dass eine Aufgabe jetzt bearbeitet werden kann, weil für eine andere Aufgabe mehr Zeit
benötigt wird. Zusätzlich zu den Hierarchien ist also üblicherweise eine arbiträre, private
Aufgabenliste zu verwalten. Diese enthält Aufgaben aus allen Aktivitäten des Anwenders, hier
etwa auch Aufgabe A3.2.
4.6.2 Datenmodell
Um eine Implementierung der Basisfunktionalitäten der bisher beschriebenen Anforderungen
umzusetzen sollen die notwendigen Elemente des Datenmodells beschrieben werden.
Abbildung 4-20 zeigt ein Entity-Relationship-Modell (ERM) der wichtigsten Entitäten. Die
zentrale Entität ist das ActivityStructureElement. Es repräsentiert jeweils ein Element der
Aktivitätsstruktur. Mögliche Instanzen sind eine Aktivität (Activity), eine Aufgabe (Task)
oder ein Aktivitätskontext (ActivityContext). Die Attribute des ActivityStructureElement sind
grundlegende administrative Meta-Daten zur Verwaltung des Elements. Die ElementID ist
eine eindeutige ID des Elements. Bei Verwendung eines Elementdokuments kann dies die
Dokument-ID des Elementdokuments sein. Da jedes Element einer Aktivitätsstruktur Teil
einer Aktivität ist, speichert die ActivityID diese Zugehörigkeit.
Das ModificationDate wird von anderen Entitäten benötigt, etwa für die Verwaltung von
Markierungen, ob ein Element gelesen oder ungelesen ist. So kann festgestellt werden, ob an
einem Element eine Änderung durchgeführt wurde, seit der Anwender das letzte darauf
zugegriffen hat. Ist dies der Fall, kann das Element als ungelesen gekennzeichnet werden. Der
ElementTitle ist ein Bezeichner für das Element, der durch den Anwender vergeben wird, um
das Element zu identifizieren. Es wird benötigt, da der Anwender aufgrund seiner kognitiven
155
Fähigkeiten üblicherweise nicht mit der ElementID arbeiten kann. Dieses Attribut ist kein
administratives Meta-Datum, sondern stellt strukturierte Inhaltsdaten des Elementdokuments
dar. Zur Kennzeichnung von Inhaltsdaten wird das Attribut im ERM nicht ausgefüllt darge-
stellt.
Abbildung 4-20: ERM Modell eines UBAM System mit den wichtigsten Attributen
Die Aktivität kann eine beliebige Anzahl an Aktivitätskontexten und Aufgaben enthalten.
Jedem Aktivitätskontext und jeder Aufgabe ist aber eine Aktivität zugeordnet. Die in
Abbildung 4-8 beschriebene Verknüpfung von Aktivitäten kann durch Aktivitätskontexte der
Dokumente umgesetzt werden, welche die Aktivität beschreiben, also etwa das Element-
dokument der Aktivitätswurzel. Eine Aktivität kann außerdem weitere Aktivitäten beinhalten.
Diese stellen Teilaktivitäten dar. Sind ElementID und ActivityID gleich handelt es sich um
die Wurzel der Aktivitätsstruktur, unterscheiden sie sich, handelt es sich um eine Teilaktivität.
Neben Aktivitäten können auch Aufgaben Aktivitätskontext-Elemente enthalten. Dies ist das
Resultat der vereinfachten Darstellung von Teilaktivitäten, wie sie in Abbildung 4-10
beschrieben ist.
Die Reihenfolge der Elemente sowie die Ebene in der Hierarchie werden durch die Entität
ElementHierachy abgebildet. Das Attribut IsDefault legt dabei fest, ob es sich um eine
Standard-Hierarchie oder eine private Hierarchie handelt. Das Attribut Collation beschreibt
die Sortierreihenfolge der ActivityStructureElemente. Die ElementHierarchy kann wiederum
beliebig viele ElementHierarchy Entitäten enthalten. Durch diese Beziehung wird die Liste
156
mehrerer Aktivitätsstrukturen abgebildet, wie sie beispielsweise als Grundlage einer Ansicht
benötigt wird.
Die Festlegung von Rechten für den Zugriff auf die Elemente und auf Hierarchien wird durch
die Member Entitäten beschrieben. Die Entität HierarchyMember enthält UserCredentials die
vergeben werden, wenn der Anwender authentifiziert ist. Das AccessLevel Attribut regelt, ob
der Anwender Leser- oder Editorenrechte besitzt, oder der Besitzer des Elements bzw. der
Hierarchie ist. Der Besitzer hat Editorenrechte sowie zusätzlich das Recht, die Liste der
Teammitglieder zu bearbeiten sowie das Element zu löschen. Neben dem Besitzer der
Aktivität als Verantwortlichem für die Bearbeitung, können weitere Personen über die
gleichen Rechte wie der Besitzer verfügen, etwa der Vorgesetzte des Besitzers. Private
Hierarchien enthalten lediglich ein Mitglied, Standard-Hierarchien können mehrere Mit-
glieder enthalten.
Für die Verwaltung des Zugriffs auf Elemente der Aktivitätsstruktur wird eine weitere Entität
ElementMember eingeführt, da hier weitere Attribute notwendig sind. Das Attribut Unread-
Mark zeigt dem Anwender, ob das Element der Aktivitätsstruktur, zu dem die Entität in
Beziehung steht, neu ist oder seit dem letzten Zugriff geändert wurde. Das Attribut Status
beschreibt den Bearbeitungsstatus des Elements aus Sicht des Individuums. Es wird verwen-
det, wenn eine Funktionalität implementiert ist, die den individuellen Status zusätzlich zu
möglicherweise vorhandenen globalen Statusfeldern des Elements verwalten soll (vgl. Ab-
schnitt 4.4.5.2).
Bei der Bearbeitung von Aufgaben im Team kommen üblicherweise mehrere Personen in
Frage, eine Aufgabe zu bearbeiten. Um Doppelarbeit zu verhindern wird die Möglichkeit
benötigt, ein Element für die Bearbeitung zu reservieren und so anzuzeigen, dass ein Anwen-
der die Verantwortung für die Bearbeitung übernimmt. Das Attribut ClaimedBy wird auf
Ebene des ActivityStructureElement definiert, weil es sich auf alle abhängigen Entitäten wie
Aktivität und Aufgabe beziehen kann. Auch für einen Aktivitätskontext kann eine Reservie-
rung Sinn machen und beispielsweise anzeigen, dass eine Tätigkeit an dem entsprechenden
Dokument aktuell exklusiv erfolgen soll. Inwieweit der UBAM Client den Reservierungs-
status eines Elements in unterschiedliche Berechtigungen umsetzt wird an dieser Stelle der
grundlegenden Architekturbeschreibung bewusst offen gelassen. Umsetzungsempfehlungen
folgen im Abschnitt zur Client Architektur (vgl. Abschnitt 4.6.6).
Auf eine Spezifizierung der Datentypen von Attributen wird verzichtet. Sie ergibt sich aus
konkreten Anforderungen des jeweils vorliegenden Anwendungsszenarios. Auch eine weiter-
157
gehende Modellierung ist nicht notwendig, da etwa optionale Attribute für den Architektur-
entwurf nicht relevant sind. Sie ergeben sich aus den Beschreibungen der funktionalen
Anforderungsdefinition. Weitere Attribute sind etwa für erweiterte Architekturmerkmale wie
Offline-Fähigkeit, Kalender Integration, Notification Management oder Tagging nötig.
4.6.3 Vorlagen und Schablonen für Aktivitätsstrukturen
Eine bereits mehrfach diskutierte Anforderung ist die Nutzung von Vorlagen zur Erstellung
einer Aktivitätsstruktur (vgl. etwa Abschnitte 4.2.2 und 4.4.4). Grundlage zur Erstellung einer
Aktivitätsstruktur kann etwa die Struktur von bereits fertig bearbeiteten Aktivitäten sein, oder
eine Vorlage die im Unternehmenskontext als eine Art Richtlinie über einen Vorlagenkatalog
zentral zur Verfügung gestellt wird. Für den Entwurf eines UBAM Frameworks sind zwei
Fälle von Vorlagen zu unterscheiden. Wird die Struktur einer bestehenden Aktivität kopiert,
enthält die resultierende Aktivitätsstruktur alle Inhaltsdaten der Vorlagenstruktur. So verwei-
sen etwa Aktivitätskontexte auf das gleiche Zieldokument, Aufgaben behalten ihren Status
und die Reservierung eines Elements bleibt bestehen. Lediglich die administrativen Meta-
Daten werden durch das System neu generiert.
Dieses Verhalten kann erwünscht sein. Verweist z. B. der Aktivitätskontext auf ein Ziel-
dokument, das jeweils die aktuellste Version einer Unternehmensrichtlinie enthält, die in jeder
Instanz der Vorlage gleich ist, soll sich der Verweis nicht ändern. Wenn hingegen der
Aktivitätskontext als Platzhalter zur Erstellung einer vorgeschriebenen Dokumentation dient,
muss nach dem Kopieren ein neues Zieldokument angelegt, und im Elementdokument die
Verknüpfung auf das neue Dokument eingetragen werden. Damit dem Anwender dieser
Aufwand erspart bleibt sollte in Aktivitätsvorlagen dem ActivityStructureElement ein Attribut
AbstractInTemplate hinzugefügt werden, das eine Verfahrensinstruktion bei der Nutzung der
Vorlage spezifiziert. Enthält es keine Informationen wird das Element kopiert. Enthält es
einen Wert wird bei der Nutzung der Vorlage eine Abstraktion des Elements durchgeführt,
dem Vorgabewert der Instanz kann der Wert des Attributs zugewiesen werden. Enthält eine
Vorlage Elemente die zu abstrahieren sind, wird die Vorlage als Schablone bezeichnet.
Abbildung 4-21 veranschaulicht die Unterscheidung zwischen Vorlage und Schablone. Der
Aktivitätskontext K1.1.1 wird im Fall der Vorlage kopiert. Der resultierende Kontext in
Aktivität A2 enthält die gleichen Inhaltsdaten wie in A1. Im Fall der Schablone werden die
Inhaltsdaten abstrahiert und es entsteht ein Kontext K2.1.1 in A2. Dieser kann zunächst leer
sein und durch den Anwender neu befüllt werden. Er kann aber auch Vorgabewerte enthalten.
158
Abbildung 4-21: Aktivitätsvorlagen: Beispiel für Abstraktion und Kopie
Neben der Abstraktion von Elementen der Aktivitätsstruktur können auch Abstraktionen der
Member Entitäten von konkreten Personen erforderlich sein. Beim Entwurf von Schablonen
ist der Regelfall, dass die konkrete Person, die für die Bearbeitung zuständig ist, noch nicht
festgelegt werden kann. Die Identifikation einer zuständigen Organisationseinheit ist jedoch
in der Regel möglich. So kann eine Gruppe, beispielsweise „Sekretariat“ für die Bearbeitung
einer Aufgabe vorgesehen werden. Wird aus der Schablone eine Aktivitätsinstanz erzeugt,
wird anhand eines Organisationsverzeichnisses eine Zuordnung konkreter Personen zur
Organisationseinheit vorgenommen. Die Abstraktion ist auch deshalb notwendig, weil sonst
bei wechselnden Zuständigkeiten stets die Schablone aktualisiert werden müsste. Für Grund-
lagen und weiterführende Informationen zur Organisationsmodellierung siehe [Ott 1998]. Für
weiterführende Diskussionen zur Abstraktion von organisationalen Entitäten zum Entwurf
von Schablonen siehe [Huth 2004]250.
4.6.4 Architektur im Kontext von ECM
Ein wichtiger Aspekt des UBAM Konzepts ist die Einbettung in die existierende Unter-
nehmensinfrastruktur. Am kollaborativen Arbeitsplatz nimmt die ECM Architektur des
Unternehmens aufgrund der Bedeutung von Dokumenten eine zentrale Stellung ein.
Aufbauend auf die im Kontext der Einbettung kollaborativer Systeme in ECM konzipierte
Abbildung 3-3 zeigt Abbildung 4-22 beispielhaft eine mögliche Einbettung von Aktivitäten in
die ECM Infrastruktur eines Unternehmens. Konzeptionell stellt die Aktivität eine Meta-
Ebene zu etablierten CSCW Bausteinen dar. Als Anwendung am kollaborativen Arbeitsplatz
kommt sie parallel zu diesen Systemen zum Einsatz. Da die Bearbeitung von Aktivitäten
250 Vgl. [Huth 2004], S. 181 ff.
159
sowohl im Bereich PIM, als auch im Bereich der Geschäftskontexte stattfindet, wenn die
Aktivität im Team bearbeitet wird, erscheint die Aktivität in der Abbildung in beiden
Bereichen.
Abbildung 4-22: Beispiel für die Integration von UBAM in eine ECM Architektur
Die Aktivität wird durch Elementdokumente repräsentiert, die wie alle anderen Dokumente
im Unternehmen behandelt werden. Sie werden mit einem Lebenszyklus versehen und
entsprechend in Bezug auf Compliance und Archivierung behandelt. Ebenso werden sie in
Bezug auf ihre Bedeutung für das organisationale Wissensmanagement betrachtet. Sie müssen
wie alle anderen Dokumente im Backup gesichert werden und in die Sicherheitsinfrastruktur
des Unternehmens eingebunden sein. Dennoch wird durch die Trennung von Dokumenten die
Kontextinformationen speichern und Zieldokumenten deutlich, dass sie als Dokumentenklasse
anders behandelt werden als Zieldokumente. Da Zieldokumente implizit oder explizit
referenziert werden ist es wichtig, dass insbesondere die langfristige Referenzierbarkeit von
Zieldokumenten sichergestellt werden kann.
Im Internet stellte sich eine ähnliche Anforderung bei der elektronischen Publikationen von
Dokumenten, da sich der URI eines Dokuments im World Wide Web häufig ändert, etwa
aufgrund des Redesigns der Website, zu der das Dokument gehört. Daher wurde zur
Identifikation von Dokumenten das System der Digital Object Identifier (DOI) eingeführt.
Ein Dienstleister kann dann dafür sorgen, dass beim Aufruf eines DOIs die Zuordnung zu
einem URI erfolgen kann und Verknüpfungen so unabhängig vom URI verwaltet werden
können. So funktioniert eine Verknüpfung weiterhin, auch wenn sich der URI geändert hat.
Voraussetzung ist, dass der Verwalter über die Änderung des URIs informiert wurde. Aus
diesem Grund wird auch in der ECM Architektur nicht direkt auf Zieldokumente zugegriffen,
sondern stets über einen dem DOI-System ähnlichen Dienst. Ein alternatives Konzept ist es,
bei der Änderung eines URIs programmatisch nach Verknüpfungen auf das Zieldokument in
160
allen in Frage kommenden Systemen durchzuführen, und diese Verknüpfungen zu
aktualisieren. Die Vor- und Nachteile beider Vorgehensweisen sollen nicht weiter diskutiert
werden, da sie das Kernthema Aktivitätenmanagement nicht direkt berühren.
Abbildung 4-23: Lebenszyklus einer Aktivität251
Die Frage, was mit einer Aktivität im ECM Kontext passieren soll hängt von der Implemen-
tierung des UBAM Systems ab. Enthält das UBAM System keine Inhalte, so muss am Ende
des Aktivitätslebenszyklus lediglich entschieden werden, was mit der Aktivitätsstruktur
geschieht, etwa Archivierung zu Referenzzwecken, Überführung in eine Vorlage oder
Schablone, oder Löschung. Sind Inhalte gespeichert, muss mit diesem Inhalt gemäß den
Richtlinien des Unternehmens verfahren werden. Er wird etwa archiviert, in einem in einem
Repository versehen mit einem Geschäftskontext abgelegt oder in einem strukturierten
Prozess weiter bearbeitet. Im Vorschlag für eine zeitliches Rahmenwerk für eine Aktivität
nach Harrison (vgl. Abbildung 4-23) fallen diese Arbeitsschritte in den Bereich Bericht.
4.6.5 Erweiterbarkeit des Framework
Neben der Umsetzung von grundlegenden UBAM Funktionen im Rahmen der in 4.6.1
beschriebenen Architekturmerkmale wurden eine Reihe von Funktionen beschrieben, die
zusätzlichen Nutzen des UBAM Systems für die Unternehmung stiften können. In den
folgenden Abschnitten werden die wichtigsten Erweiterungsmöglichkeiten beschrieben. Ein
Datenmodell dazu wird nicht entwickelt, da die Implementierung stark vom jeweiligen
Szenario im Unternehmen sowie von der Funktionalität des Erweiterungsmoduls abhängt.
Abbildung 4-24 zeigt eine Übersicht der Architektur. Dabei sind Module dargestellt, welche
die Kernkomponenten UBAM UI und UBAM Backend erweitern. Das Activity API Modul
greift auf Module, die unterhalb der API dargestellt sind zu. Diese Module implementieren
also Funktionen der API. Module innerhalb des Backends, die oberhalb der API dargestellt
sind hingegen greifen ihrerseits auf Funktionen der API zu.
251 Übersetzung und Modifikation von [Harrison 2004], S. 3.
161
Abbildung 4-24: Erweiterte UBAM Architektur
Außerhalb dieser Komponenten sind die eigenständigen Dienste dargestellt, die Schnittstellen
zu externen Infrastrukturen wie ECM oder dem World Wide Web darstellen. Diese sind durch
eine Wolke symbolisiert. Außerdem sind einzelne externe Diensten wie die Online Awareness
enthalten. Bereits in Abbildung 4-17 und Abbildung 4-18 wurde eine Trennung von UI und
Backend vorgenommen, ohne weiter auf die Gründe einzugehen. Für Softwaresysteme ist
eine Trennung der Module Datenhaltung (Model), Darstellung (View) und Geschäftslogik
(Controller) in eigenständige Einheiten üblich. Dieses Konzept wird als Model View
Controller252 bezeichnet. Es ermöglicht eine flexible Anpassung des Systems an
Erfordernisse des Unternehmens. So kann beispielsweise eine neue Datenbank eingeführt
werden, ohne die Geschäftslogik einer Applikation ändern zu müssen. Ebenso können
mehrere Darstellungsebenen, z. B. für eine Desktop-Applikation, als auch für ein Browser UI
entwickelt werden, ohne Geschäftslogik oder Datenhaltung zu modifizieren.
In den hier dargestellten Architekturentwürfen wird das Modul für die Datenhaltung nicht
eigenständig betrachtet. Das UBAM Backend umfasst also sowohl das Modul Datenhaltung
als auch die Geschäftslogik. Der Zugriff auf das UBAM Repository wird durch das Reposi-
tory Modul dargestellt. Das UBAM UI bezeichnet die Desktop-Applikation mit dem maxi-
malen Funktionsspektrum der zur Verfügung stehenden Benutzungsschnittstellen. Es ist das
252 Vgl. [Cavaness 2004], S. 8.
162
primäre Aktivitätenmanagement Werkzeug des Wissensarbeiters. Alternative Benutzungs-
schnittstellen wie ein Browser UI oder eine mobile Applikation sind wichtig, weisen
üblicherweise aber einen reduzierten Funktionsumfang auf. Weitere Details zu den
Erweiterungsmodulen und -diensten werden in den folgenden Abschnitten erläutert.
4.6.5.1 API und Event Manager
Die Activity API ist ein Modul des UBAM Backends. Jegliche Interaktion mit der Aktivitäts-
struktur erfolgt ausschließlich durch die API. Sie stellt Funktionen wie das Anlegen einer
Aktivitätsstruktur oder eines Elements einer Aktivitätsstruktur bereit, sowie die Möglichkeit,
existierende Entitäten zu bearbeiten. Sie ermöglicht außerdem den Zugriff auf Daten der
Aktivitätsstruktur in den Formaten, die von anderen Diensten benötigt werden, etwa über
REST Services oder einen Feed (vgl. Abschnitt 4.5.3). Durch die Nutzung der API brauchen
die Entwickler aufrufender Applikationen wie des UI Moduls keine Kenntnis über die
internen Strukturen der Geschäftslogik oder die Art der Speicherung der Daten des UBAM
Backends zu haben.
Zu den API Funktionen gehört auch die Suche. Soll etwa ein Text in der Aktivitätsstruktur
gefunden werden, so ruft beispielsweise das UI eine Suchfunktion der API auf. Diese leitet
den Aufruf an das Suchmodul weiter, das wiederum die Suche im UBAM Repository durch-
führt. Das Ergebnis z. B. in Form einer Liste von Elementen einer Aktivitätsstruktur wird über
die API an das UI zurück geliefert. Das UI übernimmt für diese Liste die Darstellung und ggf.
eine weitere Filterung.
Der Event Manager kann ein Teil der API sein. Er kann aber auch als externer Dienst ausge-
führt sein, etwa weil seine die Funktionen durch eine Standard Software wie einen ESB
übernommen werden, oder im Rahmen einer EDA realisiert sind. Abbildung 4-24 zeigt für
den Event Manager Dienst lediglich die Beziehungen zwischen UBAM UI, Backend, Notifi-
cation Manager und Sharing Manager, um die Darstellbarkeit der Grafik nicht negativ zu
beeinflussen. Wenn das Modul im Rahmen einer EDA beispielsweise durch eine Standard
Software realisiert wird, bestehen üblicherweise weitere Beziehungen zu anderen Systemen
etwa zum ECM, PIM Systemen und etablierten CSCW Systemen. Innerhalb des UBAM UI
ist der Event Manager an den UI Service Bus angeschlossen, der das Management von
Ereignissen innerhalb des UI übernimmt. Es existiert ein eigener Service Bus für das UI, da
Ereignisse im UI an Erweiterungskomponenten verteilt werden müssen. Details dazu folgen
in Abschnitt 4.6.6.2.
163
Die Aufgabe des Event Managers ist, angeschlossene Module und Dienste über Ereignisse zu
informieren, die in der Activity API, dem Desktop des Anwenders oder anderen Teilen der
Infrastruktur auftreten. Das kann das Eintreffen einer neuen Aufgabe im WfMS sein, oder das
Öffnen eines Dokuments in einem Repository durch den Anwender. Kaptelinins UMEA
Prototyp etwa versucht den Aufwand für das Pflegen der Aktivitätsstruktur zu minimieren. Er
nutzt dazu den Event Manager Dienst von Microsoft Office, um beim Öffnen eines Doku-
ments automatisch einen Aktivitätskontext in der Aktivitätsstruktur anzulegen.253
Tritt im UBAM Backend ein Ereignis auf, ist die API in diesem Kontext ein Sender
(Publisher), die angeschlossenen Module und Dienste sind die Empfänger (Subscriber oder
Listener). Im Beispiel des UMEA Prototypen ist Microsoft Office der Publisher und der UI
Service Bus des UBAM UI ist Empfänger dieses Events, da er nach dem Öffnen eines Doku-
ments automatisch einen Aktivitätskontext anlegen muss. Die Activity API wäre kein
geeigneter Subscriber des Events, da das Backend keine Kontextinformation hat, in welcher
Aktivität der Anwender aktuell aktiv ist. Das UI fügt dem Ereignis also eine Kontext-
information hinzu und initiiert das Anlegen des Aktivitätskontexts durch einen API Aufruf im
Backend. Im Rahmen einer EDA wird der Publisher als Ereignisquelle, der Subscriber als
Ereignissenke bezeichnet.254
Die Information über das Auftreten eines Ereignisses wird vom Publisher an den Event
Manager gesendet. Dieser informiert die Subscriber über das Auftreten des Ereignisses. Wenn
der Publisher eine Nachricht über das Auftreten eines Ereignisses sendet, wird dies als On
Operation Event bezeichnet. Er kann aber auch eine Nachricht senden, unmittelbar bevor oder
nachdem eine Ereignis stattgefunden hat. So können die Subscriber etwa selbst Code aus-
führen der beendet sein muss, bevor das eigentliche Ereignis auftritt. Der Publisher wartet
dann mit der Ausführung von Operationen, bis der Subscriber mit seiner Operation fertig ist.
Diese Ereignisse werden als Query Operation Events und Post Operation Events bezeichnet.
On Operation Events ermöglichen eine sehr lose Kopplung von Diensten, da der Event
Manager die Information über Ereignisse lediglich verteilt und keine Kenntnis über die
Subscriber benötigt. Das Modul, in dem das Ereignis aufgetreten ist wartet mit der weiteren
Ausführung nicht auf eine Rückmeldung der angeschlossenen Module. In einer EDA oder
SOA etwa sind nur On Operation Events zulässig. Query und Post Operation Events werden
im Rahmen einer engeren Kopplung von Applikationen verwendet. Dies wird als Request-
253 Vgl. [Kaptelinin 2003], S. 356. Als Weiterentwicklung, siehe auch [Dragunov et al. 2005].
254 Vgl. [Bruns/Dunkel 2010], S. 31.
164
Reply-Modell bezeichnet. Ein Anwendungsfall dieser engeren Kopplung ist der Sharing
Manager, der im folgenden Abschnitt erläutert wird.
4.6.5.2 Gemeinsame Nutzung von Inhalten
In Abschnitt 4.4.5.4 wurde ausgeführt, dass nach Möglichkeit keine Inhalte in der Aktivitäts-
struktur selbst gespeichert werden sollten, damit sie z. B. auch im ECM Kontext zur Verfü-
gung stehen. Daher muss dem Anwender im Kontext einer Aktivitätsstruktur ermöglicht
werden, Inhalte zur gemeinsamen Nutzung in einem dafür geeigneten Repository abzulegen.
Um diese Funktion effizient und mit hoher Anwenderakzeptanz zur Verfügung zu stellen,
muss der Sharing Manager sehr komfortabel sein, in geeigneten Situationen automatisiert
starten, mit möglichst wenigen Schritten abgeschlossen sein, und daher möglichst viele
Parameter antizipieren oder konfigurierbar machen.
Aus seinen Erfahrungen mit modernen Betriebssystemen und Desktop-Applikationen erwartet
ein Anwender heute beispielsweise, dass eine Datei aus dem Dateisystem per Drag-and-drop
in den Inhaltsbereich von Datenfeldern gezogen werden kann. Es wird entweder erwartet,
dass die Datei dort als Anhang abgelegt, oder eine Verknüpfung auf die Datei angelegt wird.
Da zwei Optionen möglich sind rechnet der Anwender evtl. auch mit einem Dialog, um sich
zwischen den Optionen zu entscheiden.
Die Ablage als Anhang im Inhaltsbereich eines Elements der Aktivitätsstruktur ist jedoch
keine erwünschte Aktion im UBAM Kontext. Statt der Ablage muss eine alternative Option
zur Verfügung stehen. Der Anwender kann sich etwa stattdessen entscheiden, in welchem
gemeinsam genutzten Repository die Datei abgelegt werden soll. Repositories, die häufig vom
Anwender als Ziel verwendet werden, sollten ohne weiteren Dialog direkt zur Auswahl
angeboten werden. Nach der Auswahl des Repositories muss ein Dokumententyp sowie die
für diesen Dokumententyp notwendigen und optionalen Meta-Daten eingegeben werden.
Auch die Zuweisung dieser Daten kann durch den Sharing Manager aufgrund vorherigen
Anwenderverhaltens oder einer personalisierten Konfiguration antizipiert werden.
Ist das Dokument erfolgreich im Ziel-Repository angelegt, muss der aktuellen Aktivitäts-
struktur ohne weitere Anwenderinteraktion der Aktivitätskontext dieses neuen Zieldokuments
als neues Element hinzugefügt werden. Denn das ist das erwartete Verhalten der meisten
Anwender gemäß bekannter UI Paradigmen. Wenn eine Software die Erwartung des
Anwenders in Bezug auf die Ergebnisse einer Aktion erfüllt wird dies als Erwartungs-
konformität bezeichnet.
165
Auch das Elementdokument, das den Aktivitätskontext repräsentiert verfügt über Meta-Daten,
die durch den Sharing Manager sinnvoll mit Vorgabewerten befüllt werden können. Dies ist
etwa der ElementTitle des Aktivitätskontexts. Denn üblicherweise wird ein Bezeichner-Feld
in dem neu angelegten Zieldokument ein Pflichtfeld sein. Abbildung 4-25 zeigt ein Beispiel,
wie die Kommunikation zwischen den beteiligten Entitäten der Architektur für das geschil-
derte Szenario aussehen kann. Für das UI meldet der UI Service Bus das Auftreten des Drag-
and-drop Ereignisses an den EventManager. Dieser stellt fest, dass für den Empfang dieses
Ereignisses der SharingManager mit dem Aufruf shareObject registriert ist. Der Aufruf erfolgt
asynchron, da der EventManager weiterhin in der Lage sein muss, andere Ereignisse zu
empfangen.
Abbildung 4-25: Sequenzdiagramm Ablage eines Dokuments mit dem Sharing Manager
Der SharingManager stellt fest, dass das Zieldokument in einem TargetRepository erzeugt
werden muss und führt entsprechende Operationen aus. Nachdem das Dokument abgelegt
wurde, muss über die ActivityAPI ein Aktivitätskontext für das neue Dokument erzeugt
werden. Sind diese Aktionen beendet informiert der SharingManager den EventManager über
die Erstellung eines neuen Elements in der Aktivitätsstruktur. Das UI wird dann darüber
informiert, damit ein Neuaufbau der Darstellung erfolgen kann. Abschließend informiert das
166
UI den EventManager durch den postDragDrop Event, dass ein Drag-and-drop Ereignis
erfolgreich abgeschlossen wurde.
Der Sharing Manager kommt auch dann zum Einsatz, wenn ein Aktivitätskontext auf ein
Dokument in einem privaten Repository verweist, der Anwender aber weiteren Team-
mitgliedern den Zugriff auf das Element ermöglicht. In diesem Moment muss ein Hinweis
erfolgen, dass die neuen Anwender des Dokuments keinen Zugriff darauf haben. Erneut sollte
im gleichen Schritt vorgeschlagen werden, welches ein geeignetes Repository zur Ablage
wäre. Im Anschluss an das Ablegen wird dann die ursprüngliche Verknüpfung, die auf das
Dokument im privaten Repository verwies, durch eine Verknüpfung im gemeinsam genutzten
Repository ersetzt.
4.6.5.3 Statusmanagement und Synchronisation von Meta-Daten
Das Elementdokument das Informationen über einen Aktivitätskontext speichert verfügt
ebenso über Meta-Daten wie ein Zieldokument, dessen Aktivitätskontext es repräsentiert.
Üblicherweise gibt es zwischen beiden Mengen eine Schnittmenge, insbesondere im Bereich
der deskriptiven Meta-Daten, da ja in beiden Fällen der Inhalt des Dokuments beschrieben
wird, wenn auch im Fall des Elementdokuments für den Inhalt im speziellen Kontext der
Aktivität. Um zu verhindern, dass Meta-Daten doppelt gepflegt werden müssen, kann eine
Synchronisation der Meta-Daten von Elementdokument und Zieldokument sinnvoll sein. Für
die Synchronisation ist der Dienst Meta-Daten Sync zuständig. Der Dienst wird so konfigu-
riert, dass er in der Lage ist, Meta-Daten aus dem Elementdokument, als auch aus dem
Zieldokument zu lesen und zu schreiben.
Dafür muss insbesondere konfiguriert werden, wie der Dienst anhand des Repositories und
des Dokumententyps die Meta-Daten des Zieldokuments lesen und schreiben kann. Es muss
also eine Zuweisung von Meta-Daten Feldern im Zieldokument zu Meta-Daten Feldern im
Elementdokument erfolgen. Optional kann der Meta-Daten Sync anstatt direkt auf die API
zuzugreifen über den Event Manager angebunden sein. Die Änderung eines Meta-Datums löst
dann ein Ereignis aus. Ist ein Empfänger für die Änderung von Meta-Daten registriert, nimmt
dieser die Änderung entgegen.
Üblicherweise ist trotz des Nutzens für die eigene Arbeitsorganisation die Motivation von
Anwendern zur Zuweisung von Meta-Daten gering, insbesondere bei einem Element-
dokument, das lediglich temporären Charakter hat. Beim Erstellen sollten daher die für das
Elementdokument relevanten Meta-Daten aus dem Zieldokument automatisch übernommen
werden. Der Anwender kann sie bei Bedarf jederzeit ändern. Wenn der Anwender Meta-
167
Daten ändert, die sich in beiden Systemen befinden, oder neue Daten hinzufügt kann ihm
angeboten werden, die neuen oder geänderten Meta-Daten in das Zieldokument zu überneh-
men, unter der Voraussetzung, dass der Anwender über Bearbeitungsrechte auf dem Ziel-
dokument verfügt. Stellt der Dienst fest, dass im Zieldokument Meta-Daten geändert wurden,
kann der Anwender ebenfalls nach der gewünschten Aktion gefragt werden. Die Nachfrage
darf dabei nicht zu einer Unterbrechung der eigentlichen Aktivität führen. Es darf also bei-
spielsweise keine Dialogbox verwendet werden. Eine Meldung des Änderungsereignisses an
den Notification Manager mit einer entsprechenden Aktion kann die Störung des Anwenders
minimieren.
Im Fall von administrativen Meta-Daten, die etwa den Zugriff auf die Dokumente regeln, ist
eine Synchronisation üblicherweise nicht erwünscht, da sich die Anwendergruppen in unter-
schiedlichen Kontexten oft unterscheiden. Ein Sonderfall ist, wenn dem Elementdokument ein
Anwender hinzugefügt wurde, der keinen Zugriff auf das Zieldokument hat. Hier kann es
sinnvoll sein den aktuellen Anwender davon in Kenntnis zu setzen und ihm, wenn er über die
entsprechenden Rechte verfügt, anzubieten, dem neuen Anwender auch Berechtigungen auf
dem Zieldokument zu erteilen.
Ein weiterer Fall, in dem die Synchronisation von Meta-Daten sinnvoll sein kann ist die
Synchronisation von Statusinformationen. Dieser Vorgang kann jedoch sehr komplex sein,
weil die Semantik von Statusfeldern von der Geschäftslogik des jeweiligen Anwendungs-
systems abhängig ist. Dies sei am Beispiel des Zusammenspiels von UBAM und einem
WfMS illustriert. Ein Anwender bekommt im WfMS die Aufgabe zugewiesen, ein Dokument
zu redigieren. Um dem Anwender einen zentralen Zugriffspunkt auf seine Aktivitäten zu
ermöglichen wird durch das WfMS automatisch eine Aktivität im UBAM System angelegt.
Die Aktivität enthält eine Aufgabe, die der Aufgabe aus dem WfMS entspricht. Außerdem
enthält sie einen Aktivitätskontext des zu redigierenden Zieldokuments.
Das Statusmanagement des Elementdokuments kann durch ein einfaches Feld erfolgen, in
dem etwa der Text „erledigt“ oder „offen“ steht. Wenn die Aufgabe, oder die übergeordnete
Aktivität als erledigt gekennzeichnet wird, ändert sich dieser Text. Eine einfache Synchroni-
sation des Feldinhalts in das WfMS ist jedoch nicht möglich. Würde der Anwender im
Zieldokument eine Aktion ‚Erledigt’ durchführen, werden üblicherweise eine Reihe
komplexer Aktionen ausgelöst. Es wird etwa ein Protokoll geschrieben und festgestellt, wer
der nächste Bearbeiter des Workflows ist, und das Dokument entsprechend weiter geleitet.
168
Eine Lösung kann es sein, das Statusmanagement von Aufgaben ausschließlich im Zielsystem
durchzuführen. Möchte der Anwender eine Aufgabe im UBAM abschließen wird automatisch
das Zieldokument geöffnet und es erfolgt ein Hinweis, dass die Aufgabe nur im Zielsystem
abgeschlossen werden kann. Es kann dann eine Meldung an den Event Manager oder ein
direkter Aufruf von API Funktionen erfolgen, dass die Aufgabe als abgeschlossen zu
markieren ist. Das funktioniert auch dann, wenn das Abschließen der Aufgabe nicht aus dem
UBAM UI heraus initiiert wurde, sondern aus dem Ziel-Repository erfolgt ist.
Gesondert betrachtet werden muss außerdem der Umgang mit Statusinformationen bei
Teamaufgaben. Im genannten Beispiel kann es sein, dass der Anwender das Redigieren
gemeinsam mit einem weiteren Teammitglied durchführt. Der Kollege, der später
hinzukommt, legt sich eine eigene Aufgabe an. Erst wenn beide Aufgaben erledigt sind kann
der Workflow im Zieldokument weiter geleitet werden. Für die Synchronisation von Status-
informationen muss es also möglich sein, ein komplexes Regelwerk zu konfigurieren, um
sinnvolle semantische Zusammenhänge umzusetzen. Außerdem muss eine Möglichkeit
existieren, wie die Markierung der Zugehörigkeit einer Aufgabe im UBAM System zu einer
Aufgabe in einem Ziel-Repository erfolgen kann. Befindet sich der Aktivitätskontext in der
Aktivitätsstruktur etwa direkt unter einer Aufgabe, kann eine Zuordnung implizit
vorgenommen werden. Kommt eine weitere Aufgabe hinzu, wird es schwierig, eine implizite
Zugehörigkeit über die Position in der Aktivitätsstruktur zu erkennen. In der Praxis hat es sich
daher bewährt, die Zuordnung explizit vorzunehmen, sie also etwa in einem Feld zu
speichern. Eine weitere Möglichkeit der Implementierung wäre es, Aktivitätskontext und
Aufgaben in einem Element der Aktivitätsstruktur zusammenzufassen.
Das geschilderte Beispiel, dass ein WfMS System Funktionen der UBAM API aufruft wird
als Push-Modell bezeichnet. Nicht immer ist es möglich, dass das externe System beim
Auftreten von Aufgaben eine Aktivität über die UBAM API anlegt. Auch ist es häufig
effizienter und besser wartbar, nicht in jedem System, das Aufgaben generiert, eine
Anbindung an das UBAM System zu implementieren. Vielmehr kann es ein Modul im
UBAM Backend geben das so konfiguriert ist, dass es eine Anzahl von Zielsystemen
periodisch nach neuen Aufgaben durchsucht. Wird eine Aufgabe gefunden, übernimmt das
Modul die zuvor geschilderten Schritte wie das Anlegen einer neuen Aktivität. Dieser Dienst
wird als Auto Harvester bezeichnet, das Vorgehensmodell wird als Pull-System bezeichnet.
Der Nachteil des Pull-Systems ist, dass die Aufgaben nicht unmittelbar, sondern erst nach
Ablauf der Periode im UBAM System erscheinen. In Produktivumgebungen wird daher
169
häufig eine Kombination von Push- und Pull-Modell zum Einsatz kommen, wobei nur für
besonders zeitkritische Aufgaben das Push-Modell verwendet wird.
4.6.5.4 Notifications
Der Notification Manager ist ein Dienst, der den Anwender über bestimmte Ereignisse in
seiner Arbeitsumgebung informiert, z. B. wenn ein neues Element einer Aktivität hinzugefügt
wurde, an der er beteiligt ist. Die Information über das Auftreten von Ereignissen erhält der
Notification Manager durch den Event Manager. In einer einfachen Implementierungsvariante
informiert der Notification Manager über alle Ereignisse in der Arbeitsumgebung des An-
wenders etwa durch eine E-Mail, einen Signalton oder ein eingeblendetes Dialogfenster. Es
ist jedoch wichtig, dass durch Notifications möglichst wenig negative Unterbrechungen der
Arbeit am kollaborativen Arbeitsplatz auftreten (vgl. Abschnitt 4.4.6.4). Während es die
Aufgabe des Event Managers ist, Informationen zu möglichst vielen Ereignissen sammeln
und bei Bedarf zu verteilen, ist es die Aufgabe des Notification Managers, möglichst nur für
den aktuellen Arbeitskontext relevante Ereignisse an den Anwender zu melden, und dies in
einer Form zu tun, die dem Ereignis in Bezug auf seine Wichtigkeit angemessen ist. Dies
dient der Vermeidung unnötiger Unterbrechungen.
Um möglichst effizientes Arbeiten zu ermöglichen ist es für die Implementierung des
Notification Managers außerdem wichtig, dass neben der Information auch eine mögliche
Aktion angezeigt wird, wie der Anwender auf die Notification reagieren möchte. Die Aktion
kann etwa über eine Verknüpfung direkt aus der Nachricht heraus ausgeführt werden, damit
der Anwender nicht zunächst die Applikation öffnen muss, in der das Ereignis aufgetreten ist.
Trifft beispielsweise eine neue E-Mail ein, könnte eine mögliche Aktion das Öffnen der
E-Mail sein. Auch mehrere unterschiedliche Aktionen sind möglich. So kann etwa der
Anwender auch direkt aus der Notification heraus entscheiden, dass die E-Mail gelöscht, oder
einer Aktivität hinzugefügt werden soll. Ohne in die E-Mail-Umgebung zu wechseln hat der
Anwender also den Eingang der E-Mail direkt behandelt. Eine Nachricht besteht somit aus
einem Text und einer Anzahl möglicher Aktionen, die im aktuellen Arbeitskontext sinnvoll
sind.
Eine Beispielimplementierung einer Kombination aus Event Manager und Notification
Manager sind die Statusmeldungen der Plattform Facebook255. Hier werden in einem Social
Activity Stream sowohl Meldungen von Anwendern, als auch von Applikationen, zu einer
Liste aggregiert. Das Ziel ist es, alle relevanten Meldungen an einem Ort im Zugriff zu haben.
255 Vgl. http://www.facebook.com [07.10.2011].
170
Facebook übernimmt dabei die Funktion des Event Managers und des Notification Managers.
Alle Nachrichten werden als Liste im Profil des Anwenders dargestellt. Der Anwender kann
über Filtermechanismen bestimmte Nachrichten ausblenden, etwa Nachrichten einer
bestimmten Applikation oder Person. Eine Implementierung eines Notification Managers mit
Listendarstellung als zentrales Element eines Betriebssystems plant etwa die Firma Apple für
iOS 5. Aus jeder Applikation heraus besteht direkter Zugriff auf den Notification Center
genannten Dienst. Neue Notifications werden lediglich kurz eingeblendet, ohne die
Benutzung der aktuellen Applikation zu unterbrechen.256
Als Standard zur Implementierung vergleichbarer Funktionen steht die OpenSocial API257 zur
Verfügung. Sie bietet sowohl Schnittstellendefinitionen für Ereignisse, als auch eine Spezifi-
kation für Gadgets.258 OpenSocial Gadgets stellen ein funktional reduziertes Browser UI für
Applikationen bereit. Eine Beispielimplementierung im Bereich von Anwendungssoftware für
Unternehmen stellt die Firma IBM mit der Social Business Toolkit API zur Verfügung. Die
API des Event Managers basiert hier auf dem ActivityStreams Format.259 Aktionen werden
über OpenSocial Gadgets implementiert. Der Notification Manager, insbesondere die
Filterung von Ereignissen, wird durch den Subscriber von Ereignissen implementiert.
Abbildung 4-26 zeigt den Fluss der Information vom Publisher (Application Service) über
den Event Manager (Aggregation Service) hin zum Subscriber (IBM oder Third-Party Client).
Abbildung 4-26: Beispielimplementierung Notification und Event Manager260
256 Vgl. http://www.apple.com/ios/ios5/features.html#notification [13.06.2011].
257 Vgl. [OpenSocial Foundation 2010].
258 Vgl. [Sala et al. 2011], Abschnitt 2.2.1.
259 Vgl. [Atkins et al. 2011].
260 Vgl. [Gary/Hill/Prager 2011], S. 29.
171
Der Notification Manager in Abbildung 4-24 zeigt lediglich die Beziehungen zwischen
UBAM UI und Backend, um die Darstellbarkeit der Grafik nicht negativ zu beeinflussen. Ist
er als allgemeiner Enterprise Notification Service implementiert, steht er auch mit anderen
Systemen in Verbindung, unter anderem mit ECM Systemen, PIM Systemen und etablierten
CSCW Systemen. Auch manuelle Entscheidungen über Meta-Daten Synchronisation ent-
sprechend Abschnitt 4.6.5.3 können auf diese Art getroffen werden. Notification Management
ist ein komplexes Thema und kann im Rahmen dieser Arbeit nicht umfassend diskutiert
werden. Es müssen aber Schnittstellen vorhanden sein, um ein Notification Management
System anzubinden. Dafür muss das UBAM System relevante Daten liefern können. Weiter-
führende Diskussionen im Umfeld von Notification Management sind etwa bei [Carroll et al.
2003], [Sen et al. 2006] oder [Iqbal/Horvitz 2010] zu finden.
4.6.5.5 Integration interorganisationaler Aktivitäten
Der Fall, dass Mitglieder außerhalb des eigenen Unternehmens an Aktivitäten mitarbeiten
kommt am kollaborativen Arbeitsplatz häufig vor (vgl. Abschnitte 3.2.2 und 4.4.6.1). Um
auch in dieser Situation effiziente Teamarbeit zu unterstützen, können entweder externe
UBAM-Umgebungen angebunden werden, oder die externen Teammitglieder greifen über ein
Browser UI auf die Aktivitätsstruktur zu. Das Browser UI wird durch den Web Application
Service bereitgestellt und kann auch von Anwendern verwendet werden, die über keine eigene
UBAM-Umgebung verfügen. Voraussetzung dafür ist die Möglichkeit, dem externen Anwen-
der Zugriffsrechte auf die Umgebung zu gewähren. Dafür muss der externe Anwender über
Authentifizierungsdaten wie Anwendername und Passwort oder ein digitales Zertifikat verfü-
gen. Diese Daten werden als User Credentials bezeichnet.
Die komfortablere Situation für den Anwender ist die Anbindung einer externen UBAM
Architektur. Sie wird in Abbildung 4-24 durch den Remote Activity Service symbolisiert.
Wenn mit dem externen System eine Vertrauensstellung besteht, kann das Backend direkt auf
die externen Aktivitäten zugreifen. Der Auto Harvester Dienst übernimmt dann auch hier das
Einsammeln der Aktivitäten aus dem externen System. Sehr effizient wirkt sich aus, dass bei
dieser Implementierung alle Komfortmerkmale des eigenen Systems wie Offline-Verfüg-
barkeit und Filter zur Verfügung stehen. Unter Umständen merkt der Anwender nicht einmal,
dass eine Aktivität von einem anderen System stammt. In diesem Szenario kann in der Regel
auch ein Meta-Daten Sync durchgeführt werden. Der Aufbau einer solchen Anbindung ist
jedoch aufwändig, da weder etablierte Standards zur Kopplung, noch Standardsoftware für
UBAM-Umgebungen zur Verfügung stehen. Die Spezifität einer solchen Infrastruktur ist also
172
hoch und nur dann wirtschaftlich sinnvoll, wenn zwischen den Unternehmen regelmäßig
interorganisationale Teams zusammenarbeiten.
Ist die Kopplung des Backends technisch oder organisatorisch nicht möglich, und steht bei
dem externen UBAM System kein Browser UI zur Verfügung, kann das UBAM UI auch
direkt auf den externen Dienst zugreifen. Damit der Anwender nicht bei jeder Aktualisierung
seine Benutzerdaten neu eingeben muss kann ein Credential Store implementiert werden, der
die User Credentials verschlüsselt speichert und bei Bedarf automatisch eine
Authentifizierung vornimmt. Auch in diesem Szenario führt das Fehlen etablierter Standards
für die Kopplung von UBAM-Umgebungen allerdings zu hohem Aufwand und kommt daher
aktuell nur theoretisch infrage.
Sowohl die Backend Kopplung als auch der Zugriff durch das UI wird dadurch vereinfacht,
dass das externe System eine Standards-basierte API, etwa auf Basis des ATOM-Protokolls,
bereitstellt. Wenn der Partner also das gleiche System einsetzt, sinkt die Spezifität der Kopp-
lung und ebenso die Kosten auf beiden Seiten. Greift ein externer Aktivitätsservice auf die
interne Umgebung zu, so kann dies durch direkten Zugriff auf die UBAM API erfolgen. So
kann etwa über einen Feed die Aktivitätsstruktur ausgelesen werden, und über die API
können auch Änderungen an den internen Elementen der Struktur durchgeführt werden.
Neben dem Zugriff auf die Aktivitätsstrukturdaten ist der Zugriff auf Dokumente wichtig,
deren Aktivitätskontext in der Struktur enthalten ist. Üblicherweise haben externe Anwender
jedoch nur auf wenige interne CIS Zugriff und können so auf die meisten Zieldokumente
nicht direkt zugreifen, denn die Freigabe des Dokuments im Unternehmensrepository für
Externe Anwender ist in der Regel nicht möglich (vgl. Abschnitt 4.4.6.2). Für diesen Fall
kann eine Kopie des Dokuments bis zum Abschluss der Aktivität redundant zum Ziel-
dokument im Unternehmensrepository in einem temporären Dokument abgelegt werden, dass
im Repository des UBAM Systems gespeichert wird. Das temporäre Dokument ersetzt dann
in der Ansicht für den externen Anwender den Aktivitätskontext in der Aktivitätsstruktur. Um
das Dokument im Unternehmensrepository und im temporären Repository auf dem gleichen
Stand zu halten muss eine Synchronisation des Inhalts erfolgen. Das temporäre Dokument
wird als Schattendokument bezeichnet.
Wie in Abbildung 4-27 verdeutlicht stellt das Schattendokument üblicherweise nur einen
Ausschnitt des Zieldokuments dar. Meta-Daten werden nicht synchronisiert, und auch der
Funktionsbereich des Dokuments, in dem beispielsweise eine Aufgabe abgeschlossen, oder
ein Workflow weiter geleitet wird, kann fehlen. Deshalb wird dieses Konzept nicht bei den
173
internen Anwendern angewendet. Um die volle Funktionalität des Zieldokuments bereit-
zustellen, muss dieses im Original geöffnet werden. Das Schattendokument hat in diesem
Szenario die Funktion, eine Vorschau auf das Zieldokument bereitzustellen. Das Schatten-
dokument wird zum Zeitpunkt der Freigabe des Zieldokuments automatisch erstellt. Wird die
Aktivität oder Teilaktivität, die den Aktivitätskontext beinhaltet, als erledigt gekennzeichnet,
wird das Schattendokument ebenso automatisch wieder gelöscht.
Abbildung 4-27: Schattendokument für externe Zugriffe auf Dokumenteninhalte
Die Freigabe des Dokuments für den externen Anwender P1 muss durch Unternehmens-
richtlinien geregelt werden. Der Antrag und die Freigabe eines Dokuments können etwa durch
einen vordefinierten Workflow geregelt sein. Dies sollte jedoch auf wenige Fälle beschränkt
werden. Aufgrund der Natur der Wissensarbeit schränkt ein Workflow die Flexibilität und
Reaktionsgeschwindigkeit des Teams zu sehr ein. Es muss auf Freigaben gewartet werden,
und es entsteht durch den Freigabeprozess zusätzlicher Aufwand. Im Sinne einer eigen-
verantwortlichen Arbeitsweise, wie sie etwa in Unterkapitel 3.2 und Abschnitt 4.1.5
beschrieben ist, hat sich die Vorgehensweise bewährt, dass der Anwender, der die Freigabe
eines Dokuments für einen externen Anwender (P2) durchführt, die Verantwortung für diesen
Vorgang trägt. Es wird demnach protokolliert, wer die Freigabe erteilt hat. Die Synchronisa-
tion der Inhalte zwischen UBAM System und dem Unternehmensrepository erfolgt dann stets
mit den Zugriffsrechten von P2. Wenn gewünscht können die Besitzer des Zieldokuments
über die Freigabe für einen externen Anwender informiert werden, etwa per E-Mail oder per
Notification.
174
Das Konzept des Schattendokuments ermöglicht es grundsätzlich auch, dass das Dokument
durch den externen Anwender bearbeitet wird. Der Inhalt kann dann etwa mit den Rechten
des Anwenders, der die Freigabe erteilt hat, in das Zielsystem zurück gespeichert werden.
Voraussetzung hierfür ist es, dass P2 selbst über Bearbeitungsrechte am Zieldokument ver-
fügt. Ob dieses Szenario erwünscht ist muss in jeder Organisation diskutiert werden. Hier
müssen ggf. mögliche unterschiedliche Freigabestufen implementiert werden. Nur bestimmte
Anwender, die etwa eine Schulung für den Umgang mit Dokumenten im Unternehmen
besucht haben erhalten die Berechtigung, Freigaben an Externe zu erteilen, welche eine
Editiermöglichkeit des Dokumenteninhalts einschließen. Neben externen Anwendern kann
das Konzept auch für interne Anwender ohne Zugriff auf das entsprechende Repository
verwendet werden.
In der Implementierung kann die redundante Speicherung und Synchronisation vermieden
werden, indem der Dokumenteninhalt zum Zeitpunkt des externen Zugriffs mit den Rechten
des Anwenders, der die externe Freigabe erteilt hat, aus dem internen Repository geladen
wird. Der Inhalt wird in ein temporäres Dokument übertragen das nicht gespeichert wird, und
dann dem Anwender angezeigt. Diese Art der Implementierung wird als temporäres
Schattendokument bezeichnet.
Wenn der externe Anwender noch nicht bekannt ist, muss zusätzlich ein Benutzerkonto
eingerichtet werden. Je nach Szenario kann hier automatisch ein Workflow gestartet werden,
oder der Anwender, der die Freigabe erteilt, trägt wiederum selbst die Verantwortung für die
Erstellung des Benutzerkontos. Das Konto wird dann im Self-Service unmittelbar erzeugt,
und ggf. erhält der Administrator der UBAM-Umgebung eine Benachrichtigung.
4.6.5.6 Mobile Verfügbarkeit
Die mobile Verfügbarkeit von PIM Informationen ist im Zeitalter verbreiteter Smartphone
Plattformen wie Blackberry, iOS, Android oder Windows Phone eine Anforderung, die für
Anwender selbstverständlich ist. Aufgaben, die im Kontext von Aktivitäten entstehen müssen
in dieser mobilen PIM Infrastruktur des Anwenders zur Verfügung stehen. Auch einige
Informationen über Elemente der Aktivitätsstruktur können mit der PIM-Umgebung des
Anwenders synchronisiert werden, z. B. Zieldaten von Aktivitäten oder Aufgaben mit dem
Kalender. Diese Synchronisation erfolgt primär zu dem Zweck, dass der Anwender diese
wichtigen Informationen in seiner primären PIM-Umgebung zur Verfügung hat. Ist diese
Umgebung auch an ein Mobilgerät angebunden, existieren auf dem Mobilgerät bereits native
Applikationen, und die Synchronisation von Aktivitätsdaten kann über den Standard
175
Synchronisationsmechanismus der PIM-Umgebung erfolgen. Der Dienst PIM Sync des
UBAM Systems muss also lediglich für eine Synchronisation mit der PIM-Umgebung sorgen,
nicht für eine allgemeine Synchronisation aller UBAM Daten mit Mobilgeräten.
Um neben PIM Informationen vollständige Aktivitäten und deren Strukturelemente auf
mobilen Endgeräten verfügbar zu machen, kann im Fall von Smartphones oder Tablets der
Zugriff mit einem Browser auf das Standard Browser UI des UBAM Frameworks, oder auf
eine ggf. vorhandene spezielle Version der Browserapplikation für Mobilgeräte zugegriffen
werden. Hier kann auch eine Variante als OpenSocial Gadget (vgl. Abschnitt 4.5.3) zum
Einsatz kommen, wenn dies von einer Applikation auf dem Mobilgerät unterstützt wird.
Hierfür kommt das Modul Web Application Service zum Einsatz, das auch für den normalen
Web Zugriff etwa aus einem Internet Kiosk heraus verwendet wird. Für den Zugriff auf die
UBAM-Umgebung mit einem Browser müssen temporäre Schattendokumente erzeugt wer-
den, da üblicherweise nicht alle Ziel-Repositories über ein Browser UI verfügen. Außerdem
sind sie aus Sicherheitsgründen in der Regel nicht vom Internet aus erreichbar.
Daneben kann auch eine native Smartphone Applikation als mobiler Rich Client zum Einsatz
kommen, der über einen Synchronisationsdienst die notwendigen Daten der Aktivitätsstruktur
auf das Mobilgerät synchronisiert. Dies geschieht durch den Dienst Mobile Sync. Der mobile
Client nimmt dann die Funktion des UBAM UI im Sinne von Abbildung 4-24 ein. In diesem
Szenario müssen für Aktivitätskontexte entweder temporäre Schattendokumente erzeugt
werden, oder die mobile Applikation muss über ein lokales UBAM Offline-Repository (vgl.
Abbildung 4-18) verfügen.
4.6.6 Architekturmerkmale des UI
Die folgenden Abschnitte beschreiben die Architektur des UBAM UI Moduls in der Aus-
führung als Desktop-Applikation. Es ist als Superset aller Funktionalitäten konzipiert. Je nach
Verfügbarkeit anderer Technologieoptionen können weitere UI Varianten wie ein Browser UI
abgeleitet werden.
4.6.6.1 Layout des UI
Das UI besteht zunächst aus der Visualisierung der Liste von Aktivitätenstrukturen, die sich
an der Darstellung in Abbildung 4-13 orientieren kann. Dieser Bereich wird als Aktivitäten-
ansicht (vgl. Abbildung 4-17) bezeichnet. Dabei kann eine beliebige Anzahl an Meta-Daten,
bis hin zu Inhaltsdaten in der Ansicht angezeigt werden. Da Kontextwechsel Unterbrechungen
bedeuten (vgl. Abschnitt 4.4.6.5) und nach Möglichkeit vermieden werden sollen, ist die
Aktivitätenansicht in der Voreinstellung stets sichtbar. Ein Bereich der Ansicht kann außer-
176
dem dazu dienen, durch den Anwender zu initiierende Aktionen anzubieten, etwa eine Suche
innerhalb der Aktivitätsstrukturen, oder das Umschalten zwischen Privat-Hierarchie und
Standard-Hierarchie (vgl. Abschnitt 4.6.1.3). Dabei werden im Modus Standard-Hierarchie
alle Aktivitäten in der Standard-Hierarchie dargestellt. Im Modus Privat-Hierarchie werden
alle Aktivitäten in der Privat-Hierarchie dargestellt, für die eine Privat-Hierarchie existiert.
Alle Weiteren werden in der Standard-Hierarchie angezeigt. In diesem Modus wird als
Voreinstellung bei einer Modifikation der Aktivitätsstruktur stets eine Privat-Hierarchie
angelegt, auch wenn der Anwender das Recht hat, die Standard-Hierarchie zu modifizieren.
Eine Alternative Implementierung ist die Möglichkeit, ohne einen globalen Hierarchie Modus
zu arbeiten und jeweils einzelne Aktivitäten von Standard auf Privat umzuschalten.
Bei der Interaktion mit Dokumenten in der Ansicht wird die Primäraktion und die Sekundär-
aktion unterschieden. Als Primäraktion wird die Selektion eines Elements der Aktivitäts-
struktur festgelegt. Dies geschieht etwa durch Navigation mit der Tastatur zum
entsprechenden Dokument, oder durch einen Einfachklick auf ein Dokument mit der Maus.
Die Sekundäraktion wird üblicherweise entweder durch die Enter-Taste oder einen
Doppelklick auf das Element ausgeführt. Wird die Primäraktion durch den Anwender
ausgeführt, wird die Primärfunktion aufgerufen. Entsprechendes gilt für die Sekundäraktion.
Die durch die Aktion ausgelöste Funktion wird mithilfe des selektierten Elements im Editor
Bereich (vgl. Abbildung 4-17) durchgeführt. Dies ist der Bereich, in dem etwa die
Bearbeitung von Dokumenten stattfindet.
Dies können etwa Dokumente sein, die in Form eines Aktivitätskontexts in der Aktivitäts-
struktur enthalten sind. Sie werden aus dem Unternehmensrepository mit dem dazugehörigen
Editor in den Editorbereich geladen, wenn der Anwender die Primäraktion auf dem Aktivi-
tätskontext durchführt. Durch die Sekundäraktion kann anstatt des Zieldokuments im Unter-
nehmensrepository, das Elementdokument geladen werden. So können die entsprechenden
Meta-Daten editiert werden. Für andere Elemente der Aktivitätsstruktur, wie Aufgaben oder
Teilaktivitäten gibt es kein verknüpftes Zieldokument, das geladen werden kann. Daher wird
in der Voreinstellung sowohl bei der Primär-, als auch bei Sekundäraktion das Elementdoku-
ment geladen. Alternativ kann der Anwender konfigurieren, ob bei der Primäraktion das
zuletzt geöffnete Dokument im Editor erhalten bleiben soll. So kann etwa eine Aufgabe in der
Aktivitätenansicht abgeschlossen werden, ohne dass das Elementdokument geladen wird.
Auch andere wichtige Meta-Daten der Elementdokumente sollten direkt in der Ansicht
bearbeitet werden können. Dies ist deutlich effizienter, als zunächst ein Dokument zu öffnen,
177
es in den Bearbeiten-Modus zu versetzen, ein Feld zu ändern und dann das Dokument zu
speichern und zu schließen. So sollten Aufgaben entsprechend visualisiert sein, dass etwa eine
Bearbeitung des Status effizient erledigt werden kann, etwa indem für die Änderung von
„Offen“ auf „Erledigt“ eine Checkbox abgehakt werden kann. Der ElementTitle kann durch
eine Anwenderaktion an der Stelle in den Modus Bearbeitung versetzt werden, an der er in
der Ansicht dargestellt wird. Dies kann etwa durch die Taste „F2“ geschehen, die in Microsoft
Windows Umgebungen als Standard üblich ist, um Objektnamen zu editieren.
Der Editorbereich sollte über die Möglichkeit verfügen, mehrere Fenster in geöffnetem
Zustand zu verwalten, etwa über die Visualisierung geöffneter Fenster durch Registerkarten.
So kann vermieden werden, dass beim notwendigen Wechsel zwischen mehreren
Dokumenten, die einzelnen Dokumente stets neu aus dem Ziel-Repository geladen werden
müssen. Dies wirkt sich sowohl auf die Performance der Systeme, als auch auf die
Produktivität des Anwenders negativ aus. Auch beim Durchführen einer Suche nach Doku-
menten kann das Suchergebnis aktiv bleiben, während ein Dokument bearbeitet wird.
4.6.6.2 Plugins
Viele in der Architektur (vgl. Abbildung 4-24) beschriebenen Dienste können durch Standard-
software abgedeckt werden, etwa Enterprise Search und Online Awareness. Damit dies
möglich ist, muss das UBAM UI an verschiedenen Stellen die Möglichkeit zur Erweiterung
der eigenen Funktionalitäten durch externe Module anbieten. Während das Backend die
Erweiterbarkeit über eine API ermöglicht, müssen in der Benutzungsschnittstelle
Erweiterungspunkte vorgesehen werden, in die sich zusätzliche visuelle Applikations-
komponenten einklinken können. Diese Komponenten werden als Plugins bezeichnet. Die
Erweiterungspunkte werden durch das Modul Plugin API bereitgestellt. Die Kommunikation
zwischen den Plugins und dem UBAM API sowie ggf. auch zwischen mehreren Plugins
erfolgt über den UI Service Bus.
Ein Erweiterungspunkt ist etwa die Suche. Während das Standard Suchfeld lediglich eine
Eingabe an die UBAM API ermöglicht, die wiederum die Suche innerhalb der Aktivitäts-
struktur und somit der Elementdokumente durchführt, ist es wünschenswert, die Such-
ergebnisse etwa auch auf die Inhalte von Zieldokumenten auszudehnen. Da es sich bei den
Ziel-Repositories um eine Vielzahl heterogener Systeme handeln kann, muss hier in der Regel
ein Aufruf des Enterprise Search Dienstes zusätzlich zur Aktivitätssuche erfolgen. Dieser
kann über den Erweiterungspunkt eingebunden werden. Neben der Suche in Zieldokumenten
wird so auch die Suche in der kompletten CIS-Infrastruktur des Unternehmens ermöglicht. So
178
können auch Dokumente identifiziert werden, die zur Bearbeitung einer Aktivität nötig sind,
zu denen jedoch noch kein Aktivitätskontext in der aktuellen Aktivität existiert.
Bei der Implementierung ist darauf zu achten, dass je nach durchgeführter Suche die visuelle
Darstellung des Suchergebnisses für den Anwender unterschiedlich ist. Erfolgt die Suche
innerhalb der Aktivitätsstruktur und innerhalb der Zieldokumente, ist das Ergebnis der Suche
eine gefilterte Aktivitätenansicht, da sich alle Ergebnisse in Aktivitätsstrukturen befinden, und
so auch im Kontext der Aktivitäten angezeigt werden können. Bei der Suche über die gesamte
CIS-Infrastruktur werden vornehmlich Dokumente gefunden, die sich nicht in der Aktivitäts-
struktur befinden. Die unterschiedlichen Typen von Suchergebnissen müssen für den Anwen-
der in geeigneter Weise visualisiert werden.
Auch alle Felder, die Namen von Anwendern des Systems anzeigen, sollten einen
Erweiterungspunkt aufweisen. Dies sind z. B. die Namen der Mitglieder, die direkt oder
indirekt an der Bearbeitung der Aktivität beteiligt sind. An dieser Stelle sind Erweiterungen
sinnvoll, die kontextuelle Kollaboration ermöglichen (vgl. Abschnitt 2.3.3.2), etwa einen Chat
mit der Person zu initiieren, dessen Name angezeigt wird. In diesem Kontext ist auch die
Anzeige des Online Status der Person sinnvoll, denn diese Information wird benötigt um zu
entscheiden, ob die Person überhaupt für synchrone Kommunikation zur Verfügung steht. Zu
diesem Zweck wird der Dienst Online Awareness eingebettet. Über das Kontextmenü des
Plugins kann dann direkt die Kommunikation initiiert werden, z. B. indem ein Chat gestartet
wird.
Auch der Editor Bereich kann über sinnvolle Erweiterungspunkte verfügen. Zunächst sollte
der Editor zur Bearbeitung von Elementdokumenten ebenfalls als Plugin implementiert
werden, da es dann einfacher ist, den kompletten Editor durch andere Komponenten zu
ersetzen. Dies ist kein Sonderfall sondern eher die Regel, da für die Bearbeitung und Anzeige
von Zieldokumenten häufig eine Desktop-Applikation benötigt wird. Dazu wird ein
generisches Plugin benötigt, das für die Einbettung von Desktop-Applikationen in den UBAM
Client zuständig ist. Um eine Interaktion zwischen UBAM-Umgebung und eingebetteter
Applikation zu ermöglichen muss ein Kommunikationskanal zwischen UBAM UI und der
generischen Komponente bestehen, der es ermöglicht, Eingaben aus der UBAM-Umgebung
an die eingebettete Applikation weiterzureichen. Diese Kommunikation erfolgt über das
Modul UI Service Bus.
Ein weiteres Plugin wird benötigt, um Browser Applikationen, Portlets, Widgets und Gadgets
zu integrieren. Dieses Plugin wird als Managed Browser bezeichnet, weil ein Browser im
179
Kontext des UBAM UI eingebettet wird, der unter der Kontrolle des UBAM Systems steht
und eine Kommunikation mit der Web Applikation erlaubt. Dies ist deshalb nötig, damit z. B.
eine URL aufgerufen, oder ein Feld in einem Formular mit sinnvollen Werten aus der
Aktivität gefüllt werden kann.
Eine populäre Beispielumgebung für eine umfassende Plugin-Architektur bietet das Open
Source Framework Eclipse. Die Eclipse Rich Client Platform (RCP)261 besteht lediglich aus
einem Ausführungskern und einer Plugin Architektur. Alle UI Komponenten bestehen aus
Plugins. Die Plugins können ihrerseits Erweiterungspunkte für Plugins bereitstellen.
4.6.6.3 Posteingang für Aktivitäten
In Abschnitt 4.4.6.3 wurde beschrieben, dass eine Integration von E-Mails in die UBAM-
Umgebung sowie ein Posteingang für Aktivitäten benötigt werden. Die Integration von
E-Mails, und PIM Dokumenten im Allgemeinen hängt davon ab, welche programmatischen
Zugriffsmöglichkeiten die E-Mail und die PIM-Umgebung auf ihre Dokumente ermöglichen.
Auch hier ist bei der Wahl der Integrationsmöglichkeit der Grundsatz geboten, Inhalte nur
einmal zu speichern und zum Zugriff lediglich Verknüpfungen zu verwenden. Würde eine
Kopie etwa von E-Mails in die UBAM-Umgebung erfolgen, würde die Bearbeitung von
E-Mails entweder zu unterschiedlichen Versionen in der PIM-Umgebung und im UBAM
System führen, oder es müsste anschließend eine Synchronisation der Daten erfolgen. Eine
geeignete Möglichkeit ist die Integration durch einen Feed. So könnten etwa neue E-Mails in
einer sortierten Liste mit neuen Aktivitäten erscheinen. Die E-Mail verbleibt aber im E-Mail-
Repository. Ein weiterer Vorteil ist, dass mehr als eine E-Mail-Umgebung integriert werden
kann, etwa die persönliche und eine Team-E-Mail-Umgebung.
Steht für den Zugriff auf E-Mails kein Feed zur Verfügung, kann über einen Erweiterungs-
punkt für ein Plugin die Integration der E-Mail-Umgebung erfolgen. Wird die Integration
durch ein Plugin realisiert sind sowohl die Einbettung im Rahmen des Editors, als auch im
Rahmen der Aktivitätenansicht sinnvoll. Dabei hängt es primär davon ab, wie viel Platz der
Anwender für die Verwendung der E-Mail zur Verfügung haben möchte, und ob die E-Mail-
Umgebung stets im Kontext aller Tätigkeiten erhalten bleiben soll. Erfolgt die Einbettung im
Editor Bereich, so wird die E-Mail-Umgebung durch Aktionen des Anwenders, wie das
Selektieren von Elementen der Aktivitätsstruktur, durch ein Dokument ersetzt. Es ist also eine
zusätzliche Anwenderinteraktion nötig, um die Umgebung wieder in den sichtbaren Bereich
des Editors zu bringen. Erfolgt die Einbettung in die Aktivitätenansicht, steht hingegen
261 Vgl. http://wiki.eclipse.org/index.php/Rich_Client_Platform [07.10.2011].
180
lediglich ein kleiner Bereich zur Verfügung, der die Nutzung unübersichtlich werden lassen
kann.
Wichtig ist es, dass die Einbettung so erfolgt, dass zumindest die Aktivitätenansicht stets im
Kontext der E-Mail-Bearbeitung sichtbar bleibt. Denn es ist eine Vielzahl an Interaktion
zwischen Aktivitätselementen und E-Mails zu erwarten. So wird etwa per Drag-and-drop eine
Zuordnung von E-Mails zu Aktivitäten erfolgen. Auch kann es sinnvoll sein, das Versenden
von E-Mails direkt in die UBAM-Umgebung zu ermöglichen. Eine Aktivität müsste dafür
eine eigene E-Mail Adresse erhalten. Ist der UBAM Server etwa als SMPT Server konfigu-
riert, so könnten die Besitzer der Aktivität beim Erstellen selbst eine E-Mail-Adresse für die
Aktivität vergeben. Diese Vorgehensweise könnte eine Fülle von E-Mails an mehrere Team-
mitglieder vermeiden, wenn für den Kontext der E-Mail bereits eine Aktivität erstellt wurde.
4.6.6.4 Place Awareness
Neben der Online Awareness ermöglicht die Place Awareness es, Unterbrechungen zu ver-
meiden oder positiv zu nutzen (vgl. Abschnitt 3.4.4.1). Die Place Awareness in Abbildung
4-24 ist als Modul des UBAM UI ausgeführt. Für die Ansiedlung einer Place Awareness
Komponente bietet sich die UBAM-Umgebung an, weil diese am idealtypischen
kollaborativen Arbeitsplatz den zentralen Einstiegpunkt zu allen Tätigkeiten in allen CIS des
Unternehmens darstellt. Das UI Modul kommuniziert mit dem Event Manager, um die
Informationen über den Wechsel des Arbeitskontexts des Anwenders an andere Team-
mitglieder zu verteilen. So kann die „Anwesenheit“ bestimmter Personen in der aktuellen
Aktivität für alle Anwender angezeigt werden. Über den Notification Manager können
Anwender außerdem aktiv über Kontextwechsel wichtiger Teammitglieder informiert werden.
Die Darstellung dieser Information kann ähnlich der Darstellung der Online Awareness durch
ein dem Namen räumlich zugeordnetes Symbol erfolgen. Werden etwa in der Aktivitäts-
strukturliste keine Namensinformationen angezeigt, kann das Symbol auch einem Element der
Aktivitätsstruktur zugeordnet sein. Die Einbettung des Symbols kann in beiden Fällen durch
ein Plugin erfolgen.
Die Granularität der Place Information kann unterschiedlich gewählt werden. Sie kann z. B.
auf Ebene jedes einzelnen Elements der Aktivitätsstruktur implementiert sein. Dies ermög-
licht die Feststellung ob ein Teammitglied gerade an einem bestimmten Dokument arbeitet.
Häufig ist eine so hohe Granularität jedoch nicht notwendig, um die positiven Effekte der
Place Awareness für die Unterbrechungsvermeidung zu nutzen. So kann die Information, dass
ein Teammitglied gerade in einer bestimmten Aktivität oder Teilaktivität arbeitet hinreichend
181
sein. Je höher die Granularität, desto häufiger finden auch Wechsel des Places statt, und desto
höher ist die Beeinflussung der Performance des Place Awareness oder Notification
Management Dienstes. Da die Place Awareness Information mit möglichst geringer Verzöge-
rung erfolgen muss ist Performance hier ein wichtiger Faktor. Für einen umfassenden, generi-
schen Ansatz zu Place Awareness vgl. Ploch 2009.262
4.6.6.5 Alternative Geschäftsprozesskontexte
Der Dienst Kontext Manager ist dafür zuständig, dem Anwender zu seinem aktuellen Arbeits-
kontext alternative Kontextinformationen anzubieten die ihm helfen können, seine Aufgaben
effizienter zu erledigen. So kann ein Kontext Manager etwa anhand von deskriptiven Meta-
Daten Dokumente finden, die Informationen zum gleichen Thema beinhalten, oder zu einer E-
Mail anzeigen, welche weiteren Dokumente des Absenders der E-Mail existieren. Dies
können etwa andere E-Mails des Absenders sein, Chats, die mit diesem Anwender durch-
geführt, oder Aktivitäten, die mit diesem Anwender gemeinsam bearbeitet wurden. Die Liste
dieser Dokumente wird als Kollaborationshistorie mit diesem Anwender bezeichnet.
Die Funktionsweise des Kontext Managers kann ähnlich der Enterprise Search implementiert
werden, die erforderlichen Parameter für die Suche werden dabei jedoch aus dem aktuellen
Arbeitskontext heraus automatisch bestimmt. Dieser Ansatz wird als implizite Abfrage
(Implicit Query) bezeichnet. So muss der Anwender sich keine Gedanken dazu machen, wie
die Alternativkontexte zu generieren sind. Im Beispiel der E-Mail erkennt der Kontext
Manager, dass der Absender ein relevanter Suchbegriff ist. Er erkennt aufgrund seiner
Konfiguration außerdem, in welchen Repositories zu suchen ist, wenn der Anwender die
Kollaborationshistorie aufruft. Im Beispiel sind dies die Repositories des UBAM Systems, der
E-Mail-Umgebung und des Chat Systems.
Neben der Enterprise Search, bestehend etwa aus Attributsuche oder der Volltextsuche, dient
der Kontext Manager aber auch zur Anzeige vorhandener Geschäftsprozesskontexte von
Dokumenten (vgl. Abschnitt 2.4.1). So stellt der Kontext Manager eine API bereit, über die
sich CIS wie PMS oder WfMS registrieren können, die für das Management einzelner
Geschäftsprozesskontexte eingesetzt werden. Bei der Registrierung wird jeweils durch das
System mitgeteilt, wie der Kontext Manager Informationen über Geschäftsprozesskontexte zu
einem Dokument abrufen kann. Möchte der Anwender etwa die Geschäftsprozesskontexte
sehen, die zu einem Dokument existieren das sich in der Aktivitätsstruktur befindet, kann das
UBAM System zunächst diese Information nicht bereitstellen, da lediglich der Aktivitäts-
262 Vgl. [Ploch 2009], hier insbesondere Abschnitt 4.3.5.8.
182
kontext bekannt ist. Will der Anwender weitere Kontexte anzeigen, kann das UBAM System
jedoch eine Anfrage an den Kontext Manager stellen. Als Parameter wird das Zieldokument
übergeben. Ist das Repository des Zieldokuments im Kontextmanager registriert, stellt der
Kontextmanager eine Anfrage und erhält als Rückgabewert ein Suchergebnis. Das Ergebnis
kann etwa eine Liste von Dokumenten sein, die im gleichen Prozess oder im gleichen Projekt
verwendet werden. Das Ergebnis kann aber auch eine Information über den Kontext selbst
sein, etwa eine Projekt ID oder der Name des Prozesses.
Ein weiterer relevanter Kontext ist der Wissenskontext. So kann das Dokument durch
Einbettung Teil eines Verbunddokuments sein und so modular in mehreren Wissenskontexten
verwendet werden. Das WMS kann über diese Kontexte Auskunft geben und so etwa die
Liste von Dokumenten liefern, die im gleichen Verbunddokument eingebettet sind, eine Liste
von allen Verbunddokumenten, in denen das Dokument eingebettet ist, oder eine Liste von
Dokumenten, die den gleichen Kontext wie eines oder mehrere Verbunddokumente
aufweisen. Für detaillierte Ausführungen zum Thema Kontextualisierung von Dokumenten in
WMS siehe Wang-Nastansky 2007.263
Da für die Kontextsuche keine Eingaben des Anwenders erforderlich sind, kann sie stets dem
aktuellen Arbeitskontext angepasst werden. Sie sollte ebenso wie die Aktivitätenansicht
permanent sichtbar sein, denn nur so nimmt der Anwender die Hintergrundinformationen war,
von denen er nicht einmal wusste, dass es sie gibt. Da aber anders als bei einer Enterprise
Search der Anwender auch sucht, wenn er eigentlich gerade keine Suche durchführen will,
kann das Suchergebnis nicht den gesamten Editor Bereich einnehmen. Es würde so seine
Arbeit am aktuellen Dokument unterbrechen. Es ist daher zweckmäßig, den Editorbereich
(vgl. Abbildung 4-17) zu unterteilen, und einen Teil für die Darstellung des Dokuments, und
einen Teil für die Kontextsuche zu verwenden.
Außerdem besteht die Möglichkeit, die Kontextsuche zur Generierung regelbasierter
Aktivitätskontexte einzusetzen (vgl. Abschnitt 4.3.2). Zu jedem Dokument im Suchergebnis
wird dann unmittelbar ein temporärer Aktivitätskontext erzeugt, und als eigenes Element der
Aktivitätsstruktur dargestellt. Regelbasierte Aktivitätskontexte können etwa in der Aktivitäts-
struktur hierarchisch unterhalb des Aktivitätskontexts angezeigt werden. Dabei muss sicher-
gestellt sein, dass die Ergebnismenge nicht zu groß ist, da die Aktivitätsstruktur sonst sehr
unübersichtlich wird.
263 Vgl. [Wang-Nastansky 2007].
183
4.7 Bewertung von Merkmalen der erweiterten Architektur
In der Praxis ist es aus technischen, organisatorischen und wirtschaftlichen Gründen häufig
nicht sinnvoll, alle beschriebenen Dienste und Module der erweiterten UBAM Architektur
umzusetzen. Der folgende Abschnitt dient dazu, Hinweise für den Praxiseinsatz der Archi-
tektur zu geben. Es findet durch Handlungsanweisungen eine Transformation des Maximal-
modells in Szenario-spezifische Architekturen statt. Hierzu wird eine Auswahl und eine
Priorisierung von Funktionen durchgeführt, um Anleitung zu geben, welchen Architektur-
merkmalen in Abhängigkeit von einem konkreten Szenario Priorität eingeräumt werden sollte.
Die Bewertung erfolgt anhand des Nutzens für die Anwender und das Unternehmen sowie des
Implementierungsaufwands für das Modul oder den Dienst. Dabei steht die Anwender-
akzeptanz des UBAM Systems im Vordergrund. Für die Akzeptanz des Systems wirkt es sich
negativ aus, wenn der Anwender Doppel- und Mehrfacharbeit leisten muss. Ein Beispiel ist
etwa die Notwendigkeit, Statusinformationen im UBAM System und im WfMS doppelt zu
pflegen. Solche Situationen sind nach Möglichkeit zu vermeiden, wenn dies wirtschaftlich
möglich ist.
Die Anzahl der beschriebenen Szenarien ist nicht vollständig und dient lediglich der
Illustration, wie das UBAM Konzept Anwendung finden kann. Sie sind außerdem bewusst
abstrakt gehalten. Ziel ist es, dass das Konzept in möglichst vielen Szenarien angewendet
werden kann, daher wird auf die Beschreibung sehr spezifischer Merkmale verzichtet. Auch
hat eine sehr spezifische Beschreibung keine Vorteile gegenüber einer abstrakten Beschrei-
bung, da bei der Implementierung einer UBAM Architektur ohnehin eine Re-Evaluierung
aller Komponenten am Realwelt-Szenario durchgeführt werden muss. Dies beinhaltet insbe-
sondere eine Prüfung der ökonomischen Vorteilhaftigkeit der Implementierung einzelner
Module. Hier müssen Kosten und Nutzen, etwa in Form erwarteter Produktivitäts-
verbesserungen, abgewogen werden.
Die exemplarisch ausgewählten Szenarien orientieren sich an den wichtigsten Merkmalen der
Charakteristika des kollaborativen Arbeitsplatzes (vgl. Kapitel 3) sowie den wichtigsten
betriebswirtschaftlichen Aspekten einer UBAM Implementierung. Bei der Beschreibung der
Module und Dienste wird davon ausgegangen, dass eine Funktion nicht nur durch die API
bereitgestellt, sondern auch durch das UI dem Anwender angeboten wird.
4.7.1 Szenario-unspezifisch zu bewertende Module und Dienste
Aus der Menge der beschriebenen Module und Dienste können einige Szenario unabhängig
bewertet und priorisiert werden, während andere je nach Szenario zu bewerten sind. Hier
184
sollen zunächst Module und Dienste diskutiert werden, welche Szenario-unspezifisch priori-
sierbar sind. Dienste, die für eine sinnvolle Nutzung der UBAM-Umgebung unverzichtbar,
oder essenziell für eine hohe Anwenderakzeptanz des Systems sind, sollten bereits zum
Projektstart der Einführung eines UBAM Systems zur Verfügung stehen (Abschnitt 4.7.1.1).
Module und Dienste, die nicht unmittelbar zum Projektstart zur Verfügung stehen müssen,
aber dennoch hohe Produktivitätsvorteile erwarten lassen, werden ebenfalls hoch priorisiert
und in Abschnitt 4.7.1.2 diskutiert, gefolgt von den niedrig priorisierten in Abschnitt 4.7.1.3.
Nutzen Primärer
Nutznießer Vermeidet
Doppelarbeit? Standard
Software? Aufwand Imple-
mentierung
Activity Search Hoch Anwender Nein Ja Gering
Enterprise Search Hoch Anwender Nein Ja Mittel
Event Manager Hoch Unternehmen Nein Ja Hoch
Meta-Daten Sync
(einfach) Gering Anwender Nein Ja Gering
Notification Manager
(einfach) Hoch Anwender Nein Ja Gering
Notification Manager
(generisch) Hoch Anwender Nein Nein Hoch
Online Awareness Mittel Anwender Nein Ja Gering
Place Awareness Mittel Anwender Nein Nein Hoch
Plugin API Mittel Unternehmen Nein Ja Gering
Sharing Manager Hoch Unternehmen Nein Ja Mittel
Single Sign-On Hoch Anwender Ja Ja Gering
UI Service Bus Gering Anwender Nein Ja Mittel
Tabelle 4-2: Übersicht Szenario-unspezifischer Module und Dienste
Tabelle 4-2 zeigt eine Übersicht der Module und Dienste und stellt eine Zusammenfassung
der Diskussion in den folgenden Abschnitten dar. Die Tabelle stellt die Höhe des erwarteten
Nutzens sowie den primären Nutznießer der Funktion dar. Ist der Anwender primärer Nutz-
nießer, hat das Modul direkten Einfluss auf die Produktivität und die Zufriedenheit der
Anwender. Ist primärer Nutznießer das Unternehmen, so hat der Dienst nur einen geringen
Einfluss auf die Akzeptanz des Systems beim Anwender. Vielmehr liegt der Nutzen etwa bei
Kostenvorteilen des Unternehmens, etwa durch geringere Wartungskosten bei System-
anpassungen durch eine Plugin API. Außerdem wird aufgezeigt, für welche Funktionalität
Standardsoftware zur Verfügung steht. In diesem Fall ist der Aufwand der Implementierung
üblicherweise geringer, als wenn das entsprechende Modul neu entwickelt werden muss. Die
Einschätzungen in der Tabelle stellen Durchschnittswerte zum Zeitpunkt der Veröffentlichung
dieser Arbeit dar und müssen für konkrete Einführungsprojekte daher vor der Priorisierung
überprüft werden.
185
4.7.1.1 Module und Dienste mit hoher Priorität zum Projektstart
Unverzichtbar, und somit den Anwendern bereits zum Projektstart einer UBAM Einführung
bereitzustellen, ist das Modul Activity Search. Ohne eine Suchfunktionalität in den
komplexen Strukturen von Aktivitäten kann der Anwender am kollaborativen Arbeitsplatz
nicht effektiv mit der UBAM-Umgebung arbeiten. Außerdem ist ein einfacher Notification
Manager bereits von Beginn an nötig, um den Anwender über den Ablauf von Zieldaten zu
informieren, oder Statusinformation in das primäre Kommunikationswerkzeug des
Anwenders, üblicherweise die E-Mail-Umgebung, zu liefern. Durch einen Dienst mit
erweiterter Funktionalität wie in Abschnitt 4.6.5.4 beschrieben kann er zu einem späteren
Zeitpunkt ersetzt werden. Neben dem hohen Nutzen können beide Funktionen durch
Standardsoftware abgedeckt werden und lassen einen geringen Implementierungsaufwand
erwarten.
4.7.1.2 Module und Dienste mit hoher Priorität optional zum Projektstart
Der Anwender am kollaborativen Arbeitsplatz muss mit Dokumenten aus einer Vielzahl
unterschiedlicher Repositories interagieren. Es bedeutet eine störende Unterbrechung der
Arbeit, wenn häufig Benutzername und Passwort eingegeben werden müssen, insbesondere
wenn es sich dabei um eine Vielzahl unterschiedlicher Passwörter handelt. Die mehrfache
Authentifizierung bedeutet für den Anwender Mehrfacharbeit. Single Sign-On (SSO) ist daher
eine mit hoher Priorität zu betrachtende Funktionalität. Da SSO auch einen positiven Einfluss
auf die Akzeptanz von Systemen hat, sollte die Implementierung so früh wie möglich erfol-
gen, wenn sie technisch umsetzbar ist. Ist SSO technisch nicht umsetzbar, kann alternativ ein
Credential Store implementiert und auch für den Zugriff auf interne Systeme verwendet
werden.
Einen hohen Nutzen für den Anwender haben Enterprise Search und Notification Manager.
Enterprise Search ermöglicht eine Volltextsuche in allen Repositories des Unternehmens mit
nur einer Abfrage. Ohne Enterprise Search muss der Anwender jedes Repository manuell
öffnen und die Suchfunktionen der jeweiligen Applikation nutzen, die den Zugriff auf das
Repository ermöglicht. Hinzu kommt, dass der Anwender ohne Enterprise Search das
Repository bereits kennen muss, um ein Dokument zu finden. Mit Enterprise Search ist das
nicht der Fall. Sowohl für Enterprise Search, als auch für SSO stehen Standards und
Standardsoftware zur Verfügung. Der Implementierungsaufwand von SSO ist als gering
einzustufen, da viele Repositories einen etablierten Standard für SSO unterstützen. Der
Aufwand für die Implementierung von Enterprise Search ist höher, da die Durchführung der
Suche in heterogenen Repositories, die Aggregation der Ergebnisse und die Berücksichtigung
186
von Zugriffsrechten in der Ergebnisliste eine komplexe Konfiguration des Suchdienstes
erfordert.
Der erweiterte Notification Manager kann einen Teil der negativen Unterbrechungen am
Arbeitsplatz verhindern. Er trägt somit dazu bei, die Produktivität und Zufriedenheit des
Anwenders zu erhöhen, und die Qualität zu verbessern. Voraussetzung für die Nutzung des
erweiterten Notification Managers ist der Event Manager, denn nur bei Verfügbarkeit von
Ereignissen können diese auch bewertet und gefiltert verteilt werden. Eine Implementierung
als getrennte Module muss aber nicht erfolgen. Sammeln und Filtern kann auch innerhalb
eines Dienstes implementiert werden.
Zudem soll verhindert werden, dass unternehmensrelevante Informationen in teilprivaten
Repositories wie dem UBAM System verschwinden und somit für Systeme der ECM
Infrastruktur des Unternehmens sowie für Systeme welche die Compliance der
Unternehmensprozesse sicherstellen sollen, nicht zugänglich sind. Daher sollte das Speichern
von Inhalten in der Aktivität unterbunden werden. In einem solchen Szenario ist der Sharing
Manager wichtig, da die Ablage von Inhalten sonst mit zusätzlichem Aufwand verbunden ist,
und damit die Akzeptanz des UBAM Systems leidet. Da dies für das Unternehmen strategisch
wichtig ist, besitzt die Implementierung des Sharing Manager eine hohe Priorität.
Die Plugin API ist wichtig, um das UBAM UI durch kontextuelle Funktionalitäten zu
erweitern. Zwar können alle potenziellen Anwender der API auch manuell direkt in die
Applikation programmiert werden, der Aufwand für die Integration wäre jedoch deutlich
höher. Nutzen durch die Implementierung hat also nicht primär der Anwender, sondern das
Unternehmen. Dienste, welche durch Nutzung der API eingebettet werden können sind etwa
Online Awareness und Enterprise Search.
4.7.1.3 Module und Dienste mit geringer Priorität in allen Szenarien
Die folgenden Module und Dienste können ebenfalls Szenario-unabhängig bewertet werden.
Der Nutzen für Anwender und Unternehmen ist jedoch geringer einzuschätzen als bei den
zuvor Diskutierten. Es wurden Module und Dienste mit geringer Priorität klassifiziert, die
entweder einen geringen Nutzen, oder einen mittleren Nutzen verbunden mit hohem
Implementierungsaufwand, aufweisen. Dies gilt etwa für den UI Service Bus. Er ermöglicht
die Kommunikation zwischen Plugins des UBAM UIs. Zwar verspricht diese Kommunikation
eine komfortablere Nutzung der Umgebung, das Erreichen messbarer Produktivitätsgewinne
allein durch diesen Dienst erscheint aber fraglich. Zudem sind ist durch das Modul der größte
Nutzen zu erwarten, wenn der Anwender flexibel die Kommunikation zwischen Komponen-
187
ten seiner Arbeitumgebung konfigurieren kann. Erste Ansätze, etwa im Composite
Application Modell der Firma IBM264 oder den Kommunikationsschnittstellen der Enterprise
Mashup Produkte verschiedener Hersteller265 haben sich jedoch als für Anwender schwer
handhabbar erwiesen.
Im Fall der Place Awareness ist grundsätzlich ein klarer Nutzen zur Reduktion von Unter-
brechungen oder gar zur Generierung positiver Unterbrechungen erkennbar. Auch wenn es
klare Hinweise gibt, dass Unterbrechungen sich negativ auf die Produktivität von Wissens-
arbeitern auswirken, ist der positive Effekt von vermiedenen Unterbrechungen im Kontext
kollaborativer Applikationen nicht hinreichend erforscht. Da im Vergleich dazu eine große
Zahl an Arbeiten vorliegt, die klare negative Effekte von Unterstützungsfunktionen im
Umfeld von Dokumentenmanagement aufzeigen, wird der Nutzen der Place-based Awareness
im Vergleich zu Modulen und Diensten, welche die Arbeit mit Dokumenten produktiver
gestalten, lediglich als mittel eingestuft. Aufgrund fehlender Standards ist hier der Implemen-
tierungsaufwand zudem als hoch einzuschätzen.
Die Synchronisation von Meta-Daten erleichtert das Anlegen und das Management von
Aktivitäten für den Anwender. In Bezug auf den Gesamtaufwand beim Verwalten von, und
Arbeiten mit Aktivitäten ist der Nutzen durch Produktivitätsgewinne jedoch als gering einzu-
schätzen. Für eine einfache Feldsynchronisation ist jedoch auch nur ein geringer Aufwand
nötig, da leicht zu konfigurierende Standardsoftware eingesetzt werden kann. Daher kann der
Meta-Daten Sync als Komfortmerkmal zur Steigerung der Akzeptanz eines UBAM Systems
dennoch sinnvoll sein, auch wenn die Implementierung nicht mit hoher Priorität erfolgt. Die
erweiterte Synchronisation, etwa von Statusinformationen wird in Abschnitt 4.7.2 betrachtet.
4.7.2 Szenario-spezifisch zu bewertende Module und Dienste
Aus der Menge der beschriebenen Module und Dienste müssen Einige in Bezug auf eine
Bewertung der Relation von Nutzen zu Kosten in unterschiedlichen Szenarien auch unter-
schiedlich priorisiert werden. Tabelle 4-3 zeigt eine Übersicht der Module und Dienste und
stellt eine Vorschau auf die Diskussion in den folgenden Abschnitten dar. In der Tabelle wird
innerhalb eines Szenarios jeweils der Fall angegeben, in dem der höchste Nutzen durch eine
Implementierung zu erwarten ist. Spielt der Dienst oder das Modul in mehreren Szenarien
eine Rolle, wird die Bewertung für jedes Szenario vorgenommen.
264 Das Composte Application Modell wird von den Produkten IBM Websphere Portal, IBM Lotus Expeditor
und IBM Lotus Notes unterstützt.
265 Für Beispiele von Herstellern von Enterprise Mashup Produkten siehe [Gilbert et al. 2009], S. 17.
188
Szenario Nutzen Aufwand Vermeidet
Doppelarbeit? Priorität /
Projektstart
Auto Harvester Hohe Heterogenität Hoch Hoch Ja Hoch / Start
Credential Store Hohe inter-
organisationale
Transaktions-
häufigkeit
Mittel Mittel Ja Hoch / Start
Kontext Manager Hohe Heterogenität Hoch Hoch Nein Hoch / Optional
Kontext Manager Hoher Anteil an
Wissensarbeit
Hoch Hoch Nein Hoch / Optional
Meta-Daten Sync
(erweitert) Hohe Heterogenität Mittel Mittel Ja Hoch / Start
Mobile Sync Einsatz mobiler
Endgeräte
Hoch Hoch Nein Hoch / Optional
Offline-Architektur Mobiler Arbeitsplatz Hoch Hoch Nein Hoch / Optional
PIM Sync Einsatz mobiler
Endgeräte
Mittel Gering Nein Hoch / Optional
Template Directory Hoher Anteil an
Wissensarbeit
Mittel Mittel Ja Hoch / Optional
Template Directory Hohe
Transaktionshäufig-
keit gleicher oder
ähnlicher Aktivitäten
Mittel Mittel Ja Hoch / Optional
Web Application
Service Hohe inter-
organisationale
Transaktions-
häufigkeit
Hoch Hoch Ja Hoch / Start
Tabelle 4-3: Übersicht des Nutzens von Modulen in speziellen Szenarien
4.7.2.1 Anteil der Wissensarbeit am Produktionsprozess
Je höher der Anteil der Wissensarbeit am Produktionsprozess ist, umso wichtiger ist die
Unterstützung der Wissensarbeiter durch ein UBAM System, da im Umfeld der Wissensarbeit
mehr Ad-hoc-Aktivitäten auftreten, als in Szenarien mit geringen Wissensanteilen. Hinzu
kommt, dass diese Aktivitäten für den gesamten Wertschöpfungsprozess eine höhere Bedeu-
tung haben als in Unternehmen mit geringerem Wissensanteil. In diesem Szenario kommt der
effizienten Organisation und Bearbeitung von Dokumenten eine besonders hohe Bedeutung
zu. Aufgrund der Intensität der Arbeit mit Dokumenten ist es in diesem Szenario zudem sehr
wichtig, dass das UBAM UI als Desktop-Applikation ausgeführt ist.
Da in diesem Szenario das Arbeiten mit Aktivitätenstrukturen einen großen Anteil der
Arbeitszeit des Wissensarbeiters einnimmt, muss die Arbeit sowohl mit Aktivitätsstrukturen,
als auch mit Dokumenten im Allgemeinen, besonders effizient sein. Hier ist z. B. der Einsatz
eines Template Directories sinnvoll, das Vorlagen und Schablonen häufig benötigter
Aktivitätsstrukturen zur Verfügung stellt und auch Konzepte berücksichtigt, die es
ermöglichen, aus bereits erledigten Aktivitäten Vorlagen und Schablonen zu erstellen und mit
Kollegen zu teilen. Das Template Directory stellt außerdem ein Repository mit Prozesswissen
189
dar und hilft, durch Checklistenfunktionalität eine hohe Qualität bei der Aufgabenbearbeitung
sicherzustellen.
In diesem Szenario kann außerdem die Implementierung des besonders innovativen, aber
auch aufwändig zu implementierenden Kontext Managers erfolgen. Der Kontext Manager hat
in diesem Szenario das höchste Nutzenpotenzial.
4.7.2.2 Einfluss interorganisationaler Kooperation
Aufgrund der Zunahme interorganisationaler Kooperation (vgl. Abschnitt 3.1.2) ist eine
Unterstützung dieser Art der Zusammenarbeit auch im Kontext von UBAM wichtig und hat
Auswirkungen auf die Bewertung von Modulen und Diensten der UBAM-Umgebung. Die
Kooperation in diesem Umfeld erfolgt über die Anbindung eines externen UBAM Systems
(vgl. Remote Activity Service in Abbildung 4-24) oder die Zusammenarbeit über das Browser
UI des UBAM Systems. Die Entscheidung, ob die Zusammenarbeit zwischen zwei Organisa-
tionen auf Basis eines UBAM Systems ökonomisch sinnvoll ist hängt maßgeblich von der
Transaktionshäufigkeit ab. Findet der Austausch von Informationen zur Aktivitätsbearbeitung
nur selten statt, ist dies als Grund für die Implementierung eines Web Application Dienstes
oder die Anbindung eines externen Aktivitätenmanagement Systems nicht hinreichend. Bei
geringer Transaktionshäufigkeit kann die Kooperation etwa per E-Mail, Chat und Telefon
erfolgen. Da die Doppelarbeit nur selten erfolgt ist es ein Szenario, das die Akzeptanz des
UBAM Systems nur gering beeinflusst.
Auch wenn ohnehin ein Browser UI zur Verfügung steht, etwa weil auf die Implementierung
einer Desktop-Applikation verzichtet wurde, entsteht dennoch ein zusätzlicher Aufwand z. B.
für die Implementierung von Prozessen zur Zulassung externer Anwender für das UBAM
System. Ein Browser UI ist im Umfeld interorganisationaler Kooperation zudem ein Kom-
promiss und keine optimale Lösung, denn für den Kooperationspartner des Partner-
unternehmens stellt das UBAM System mit hoher Wahrscheinlichkeit ein externes, nicht
integriertes System dar. Die bessere Lösung ist die direkte Kopplung der UBAM Systeme
durch den Remote Activity Service, die aufgrund fehlender Standards jedoch eine Investition
mit hoher Spezifität darstellt, die nur bei großer Transaktionshäufigkeit sinnvoll ist.
Ähnlich wie bei SSO innerhalb der eigenen Organisation ist die Authentifizierung ein Vor-
gang, der häufig vorkommt und der für den Anwender Mehrfacharbeit bedeutet, die
verhindert werden sollte. Daher ist die Implementierung eines Credential Store zum Zugriff
auf den Remote Activity Service wichtig, wenn keine alternativen Mechanismen für die
Authentifizierung zur Verfügung stehen. Bei hoher Transaktionshäufigkeit kann die Alter-
190
native der Implementierung einer Vertrauensstellung zwischen den Servern der
Organisationen sinnvoll sein.
Für die Anbindung des Remote Activity Service können auch Meta-Daten Sync und der Auto
Harvester bzw. dazu verfügbare Alternativen berücksichtigt werden. Aus Sicht einer Kosten-
Nutzen Bewertung sollte der zusätzliche Aufwand durch die Anbindung des externen Systems
in die in Abschnitt 4.7.1 beschriebene Analyse integriert werden.
4.7.2.3 Organisatorische Rahmenbedingungen
Die Transaktionshäufigkeit hat nicht nur einen Einfluss auf die Bewertung interorganisatio-
naler Kooperation, sondern auch auf die Bewertung von Modulen und Diensten die lediglich
intern genutzt werden. Dabei spielt sie insbesondere dann eine Rolle, wenn durch das UBAM
System automatisch oder halbautomatisch Aktivitäten identifiziert werden können, deren
Aktivitätsstruktur gleich oder ähnlich ist. Auch wenn die Mehrzahl der durchgeführten
Aktivitäten im Unternehmen von der Aktivitätsstruktur her unterschiedlich ist, gibt es den-
noch Typen von Aktivitäten, deren Bereitstellung als Vorlage sich unabhängig von Qualitäts-
oder Wissensaspekten lohnt, etwa eine Standard Vorlage für die Organisation und Protokol-
lierung von Besprechungen.
Die Organisation von Besprechungen tritt derart häufig in ähnlicher Form auf, dass es effi-
zient ist, wenn die einzelnen Aufgaben und etwa notwendige Formulare zur Beantragung von
Konferenzgetränken oder Raumreservierung effizient bereitgestellt werden, und die
Aktivitätsstruktur nicht von jedem Anwender erneut erdacht werden muss. Hier ist die
Implementierung eines Template Directories lohnenswert. In diesem Szenario kann auch der
Mehraufwand zur Modellierung von abstrakten Member Entitäten in Schablonen ökonomisch
sinnvoll sein (vgl. Abschnitt 4.6.3).
Ein weiterer Aspekt ist die Mobilität von Teammitgliedern. Ist es in einer Organisation häufig
anzutreffen, dass Mitarbeiter Mobilgeräte oder mobile Arbeitsplätze nutzen, sind einige
Zusatzdienste für diese Umgebung sinnvoll. Wird ein vollwertiger mobiler Arbeitsplatz
benutzt, etwa ein Laptop, hat die Implementierung einer Offline-Funktionalität Nutzen-
potenzial. Kommen Smartphones oder Tablets zum Einsatz, ist die Verfügbarkeit des Mobile
Sync Dienstes in Kombination mit einer nativen Applikation auf dem Mobilgerät sinnvoll. Ist
der Aufwand für die Implementierung zu hoch kann evaluiert werden, ob auch ein PIM Sync
hinreichend ist.
Abschließend lässt sich sagen, dass auch die Art des UBAM Deployments einen Einfluss auf
die Wirkung der Infrastruktur auf die Bewertung von Nutzen und Kosten in Bezug auf
191
Heterogenität hat. Wenn etwa das Deployment der UBAM-Umgebung lediglich auf
Abteilungsebene, oder auf Ebene einzelner Unternehmensteile erfolgt, sinkt üblicherweise die
Heterogenität der Systeme, allein aufgrund der reduzierten Anzahl im Einsatz befindlicher
Systeme. Sollte dieser Sonderfall vorliegen, ist das entsprechend bei der Bewertung zu
berücksichtigen. Gleiches gilt, wenn es sich bei der Organisation um ein kleines oder mittel-
ständisches Unternehmen handelt, und dort aufgrund der Natur der Organisation weniger
Systeme vorhanden sind, als etwa in Konzernen.
Diese Art der Umsetzung in kleinen organisationalen Strukturen beeinflusst auch zuvor
diskutierte Bereiche, etwa den Nutzen von Diensten im Umfeld wissensintensiver
Produktionsprozesse. So ist das Nutzenpotenzial von Template Directory und Kontext Mana-
ger in kleinen UBAM-Umgebungen geringer als in großen. Zunächst ist üblicherweise die
Heterogenität der Systeme gering, und daraus resultierend ist die Anzahl unterschiedlicher
Geschäftsprozesskontexte gering.
4.7.2.4 Vorhandene Infrastruktur
In Abschnitt 3.3.1 wurde beschrieben, dass durch die evolutionäre Entwicklung von Software
Klassen in Unternehmen häufig heterogene CIS-Infrastrukturen anzutreffen sind. Je größer
die Heterogenität der Unternehmensinfrastruktur, umso wichtiger ist eine automatisierte
Unterstützung des Anwenders im Umgang mit Dokumenten und Aufgaben. Muss der
Wissensarbeiter mit sehr vielen CIS arbeiten, ist etwa der Nutzen eines Kontext Management
Dienstes besonders hoch. Eine hohe Heterogenität der gesamten Infrastruktur geht häufig mit
einer großen Anzahl an Systemen einher, die Quelle von Aufgaben oder Aktivitäten sind.
Diese Systeme werden als Aktivitätenquelle (engl. Activity Source) bezeichnet, etwa WfMS
oder PMS. Von diesen Merkmalen der Infrastruktur maßgeblich betroffen ist die Bewertung
von Kosten und Nutzen des Kontext Managers, des Auto Harvesters sowie alternativer
Implementierungen, etwa eine direkte programmatische Anbindung der Systeme an das
UBAM System.
Der Begriff Heterogenität wird im Folgenden sowohl für die Anzahl heterogener CIS, als
auch für die Anzahl heterogener Aktivitätenquellen verwendet. Die Anzahl heterogener
Aktivitätenquellen hat maßgeblichen Einfluss auf die Kosten Nutzen Bewertung des Auto
Harvesters, die Gesamtzahl heterogener CIS hingegen hat Einfluss auf die Bewertung des
Kontext Managers. Außerdem sind Alternativen zur Implementierung der Module und
Dienste zu berücksichtigen, etwa der individuelle programmatische Integrationsaufwand für
diese Systeme in die UBAM-Umgebung. Abbildung 4-28 zeigt ein Beispiel für eine solche
192
Analyse. Der grüne Graph zeigt den Aufwand für die Implementierung des Auto Harvesters
und in diesem Beispiel vom Aufwand vergleichbarer Alternativen, etwa der Implementierung
eines ESB oder Event Managers. Der rote Graph zeigt eine weitere Alternative, die einen
anderen Verlauf des Aufwands in Abhängigkeit von der Heterogenität zeigt, nämlich die
direkte programmatische Punkt zu Punkt Integration. Je höher das Heterogenitätslevel der
eigenen Umgebung ist, je größer ist der Nutzen aus dem Modul oder Dienst für den
Anwender, denn der Anwender müsste ohne die Integration von Aktivitäten jeweils in
mehrere unterschiedliche CIS navigieren, um seine Aktivitäten oder entsprechende
Dokumente zu finden. Je höher die Heterogenität, umso größer ist jedoch auch der Aufwand
für die Implementierung des Dienstes oder Moduls.
In dem Beispiel fällt für die Implementierung des Auto Harvesters ein Basisaufwand (B) an,
um den Harvester zu entwickeln oder bereitzustellen. Eine ähnliche Aufwandsentwicklung
würde hier die Implementierung einer direkten Integration aufweisen, die mithilfe eines ESB
oder Event Managers implementiert wird. In einem Realwelt Szenario ist üblicherweise für
diese Alternativen ebenfalls jeweils ein Graph zu entwickeln. Nach der Bereitstellung des
Moduls entsteht durch die Konfiguration eines zusätzlichen Systems ein weiterer Aufwand,
der Verlauf des Graphs ist jedoch flach.
Abbildung 4-28: Beispiel für eine Kosten-Nutzen Analyse
alternativer Implementierungen
Für eine direkte Punkt zu Punkt Integration hingegen fällt kein Basisaufwand an. Da jedoch
die Anbindung jedes zusätzlichen Systems an das UBAM System, etwa unter Verwendung
der Activity API, einen im Vergleich zum Auto Harvester höheren Aufwand pro System
bedeutet, gibt es ein Heterogenitätslevel (A), ab dem der Aufwand höher ist als bei
193
Implementierung des Auto Harvesters. Liegt also das eigene Heterogenitätslevel unterhalb
von A würde eine Entscheidung zugunsten der Punkt zu Punkt Integration fallen, liegt es
oberhalb von (A) würde eine Entscheidung zugunsten des Auto Harvesters fallen. Analog ist
für eine Analyse des Kontext Managers zu verfahren. Wird eine Entscheidung für die
Implementierung des Auto Harvesters getroffen, sollte die Implementierung möglichst früh
im Projektverlauf erfolgen. Zwar können Pilotanwender zu Beginn manuell heterogene
Repositories öffnen, beim Deployment im gesamten Unternehmen sollte jedoch von Anfang
an diese für die Anwenderakzeptanz wichtige Funktion zur Verfügung stehen. Auch wenn der
Nutzen des Kontext Managers in diesem Szenario auch als hoch einzustufen ist, kann eine
Implementierung später erfolgen.
Der Auto Harvester hat hier eine höhere Priorität, da er den Anwendern Doppelarbeit erspart.
Hinzu kommt, dass ein Meta-Daten Sync mit Abgleich von Statusinformationen in diesem
Szenario wichtig sein kann. Auch wenn hier der Implementierungsaufwand im Vergleich zur
einfachen Feldsynchronisation deutlich steigt, ist die Synchronisation von
Statusinformationen in heterogenen Umgebungen wichtig. Denn der Anwender kann auf
deskriptive Meta-Daten im UBAM System üblicherweise komplett verzichten.
Statusmanagement ist jedoch unbedingt notwendig. Erfolgt keine Synchronisation, muss das
Statusmanagement manuell in zwei Systemen erfolgen, es ist also Doppelarbeit notwendig,
was zu geringerer Akzeptanz für das System führen kann.
Durch unterschiedliche Strategien kann eine Senkung der Heterogenität einer Infrastruktur
erfolgen. So kann die konsequente Bereitstellung von Informationen durch Standards-basierte
Schnittstellen wie etwa Feeds oder JCR-kompatible Repositories die Heterogenität senken.
Durch den Einsatz von Portaltechnologien werden Legacy-Systeme in eine einheitliche
Oberfläche integrierbar. Durch ESB kann eine standardisierte Form der Backend Integration
umgesetzt werden. Durch strategische Ausrichtung auf einen oder wenige Software Anbieter
(engl. One-Vendor-Strategie, Few-Vendor-Strategie), der ein möglichst breites Portfolio an
benötigten Lösungen anbietet, wird die Notwendigkeit manueller Integration minimiert, da
sich Produkte des gleichen Herstellers üblicherweise mit geringem Aufwand integrieren
lassen.
Bei der Modellentwicklung ist daher zu berücksichtigen, dass das Heterogenitätslevel in einer
Organisation nicht stabil sein muss, vielmehr kann es sinken oder steigen. Daher ist auch die
Entwicklung des Heterogenitätslevels der Infrastruktur des Unternehmens zu berücksichtigen.
Ist durch Konsolidierungsbestrebungen oder durch Umsetzung einer One-Vendor-Strategie
194
die Heterogenität der eigenen Infrastruktur tendenziell in den letzten Jahren gesunken, muss
dies bei der Entscheidung für eine Alternative berücksichtigt werden. Ist umgekehrt eine
Steigerung der Heterogenität zu erkennen, und sind kurzfristig keine Konsolidierungs-
bestrebungen zu erwarten, beeinflusst auch dies die Entscheidung für eine der Alternativen.
195
5 GCC-AM: Umsetzung der Architektur für ein
Beispielszenario
5.1 Einführung
5.1.1 Szenario und Anforderungen
In Unterkapitel 4.7 wurde anhand von Beispielszenarien die Anwendung des UBAM Konzep-
tes in der Praxis gezeigt. Ein weiteres Beispiel für die Anwendung des Konzeptes ist die
prototypische Implementierung eines UBAM Systems am Groupware Competence Center der
Universität Paderborn (GCC) mit der Bezeichnung GCC Activity Manager (GCC-AM). Am
GCC wurde seit der Gründung im Jahr 1989 eine Fülle von Forschungsarbeiten, Prototypen
und daraus resultierender Standard Software Produkte im Umfeld etablierter CSCW Konzepte
entwickelt, etwa im Bereich von Office Management, Workflowmanagement, Knowledge
Management, Projektmanagement und Portaltechnologien. Das Ziel des GCC-AM sollte es
sein, die Vielzahl entstehender Aufgaben aus diesen unterschiedlichen Systemen, sowie das
Management individueller Aufgaben zusammenzuführen und durch ein Werkzeug abzu-
bilden. Gleichzeitig sollte durch die Erfahrungen bei der Implementierung eine Verfeinerung
des UBAM Architekturentwurfs erfolgen. Bei der Implementierung lag ein Fokus auf dem
UBAM UI. Des Weiteren sollte bei der Implementierung der Komponenten nach Möglichkeit
Standard Software zum Einsatz kommen.
Aktivitäten entstehen in der wissensintensiven Arbeit am GCC im Rahmen von Technologie-
transfer- und Praxisprojekten, interdisziplinären und interorganisationalen Forschungs-
projekten, strukturierten Workflows, etwa im Umfeld des Lehr- und Lernbetriebs und des
allgemeinen Wissensmanagements im Forschungsbetrieb. Insbesondere in Forschungs-
projekten ist die tägliche Arbeit durch flexible und sich selbstständig organisierende Arbeits-
gruppen gekennzeichnet. Der Arbeitsplatz ist vollständig mobil, auch am Büroarbeitsplatz
kommen ausschließlich Laptops zum Einsatz, so dass der Anwender immer seine komplette
Arbeitsumgebung bei sich führt. In dieser Umgebung ist die Offline-Fähigkeit aller Applika-
tionen, insbesondere des GCC-AM eine wichtige Anforderung.
Die CIS-Infrastruktur des GCC ist durch eine durchgängige Verwendung von auf IBM Lotus
Notes basierenden Lösungen gekennzeichnet. Es kommt also eine Desktop-Applikation als
kollaboratives UI aller Business Applikationen zum Einsatz. Alle Repositories sind IBM
Lotus Domino basiert, so dass dies gleichzeitig die ECM Infrastruktur des GCC darstellt.
Auch das Intranet ist Lotus Notes und Domino basiert, so dass dieser Bereich des
Architekturentwurfs nicht gesondert betrachtet werden muss, und etwa SSO nicht implemen-
196
tiert werden muss. Das gleiche gilt für die nächst höhere organisationale Ebene, der Fakultät
für Wirtschaftswissenschaften der Universität Paderborn.
Es handelt sich also um eine homogene CIS-Infrastruktur. Daher ist die Implementierung von
erweitertem Meta-Daten Sync nicht hoch priorisiert. Auch der Kontext Manager ist nicht
notwendig, da die Arbeit zwar wissensintensiv ist, aber in einer überschaubaren, homogenen
Umgebung mit wenigen Repositories stattfindet (vgl. Abschnitt 4.7.2.3). Die Implementie-
rung eines Template Directories ist ebenfalls nicht notwendig, da es sich um ein recht kleines
Deployment eines UBAM Systems handelt, und gleichzeitig eine geringe Transaktions-
häufigkeit unterschiedlicher Ad-hoc-Aktivitäten vorliegt. Das Kopieren existierender
Aktivitäten ist daher hinreichend. Alle Aktivitäten mit hoher Transaktionshäufigkeit werden
am GCC über strukturierte oder ad hoc geplante Workflows im Rahmen eines WfMS
abgebildet.
Da interorganisationale Kooperation häufig vorkommt, ist ein Web Application Service
wichtig, um externen Organisationen Zugriff auf Aktivitätsstrukturen zu ermöglichen. Auf die
Implementierung des Auto Harvesters wird im Rahmen des GCC-AM Prototypen verzichtet.
Im Laufe des UBAM Projektes wurden einige Ansätze zum Auto Harvester evaluiert und aus
technologischen Gründen verworfen (vgl. Abschnitt 5.1.2). Heute wäre eine Implementierung
aufgrund allgegenwärtiger Standards für Harvesting wie etwa RSS mit geringerem Aufwand
möglich. Im Rahmen der Prototyp Entwicklung wurde auf eine Neuimplementierung aus
Kapazitätsgründen verzichtet. Alle Aktivitäten werden demnach in der aktuellen Version
manuell angelegt. Aufgrund der Homogenität der Infrastruktur kann diese Funktionalität
später entwickelt und nachgerüstet werden. Außerdem wurde im Rahmen der Prototyp-
entwicklung auf PIM Sync und mobile Sync verzichtet. Als Alternative zum Mobile Sync
steht das Web Interface über den Web Application Service auch auf mobilen Geräten zur
Verfügung.
Außerdem wurde auf die Implementierung eines generischen Notification Managers ver-
zichtet, da dies einen eigenen Forschungsbereich darstellt und über den Rahmen der
vorliegenden Arbeit hinausgeht. Es wurde auch auf Funktionalitäten verzichtet, die in Ab-
schnitt 4.7.1.3 als Funktionen mit geringer Priorität klassifiziert wurden, etwa die Place
Awareness. Dennoch stehen einige Funktionen niedriger Priorität zur Verfügung, weil sie als
Standardfunktion bereits in der ausgewählten Plattform vorhanden sind, etwa der UI Service
Bus und die Plugin API des UBAM UIs. Die beschrieben Design Entscheidungen führen zur
197
in Abbildung 5-1 dargestellten Architektur des GCC-AM, die gegenüber der generischen
UBAM Architektur verändert wurde.
Abbildung 5-1: GCC-AM Architektur Überblick
Im aktuellen Status der Prototyp Entwicklung ist die Activity API nicht implementiert wor-
den. Für zukünftige Erweiterungen durch neue Module und Dienste ist dies ein erster sinn-
voller Schritt. Im Rahmen des Forschungsprojektes wurde aus zwei Gründen darauf ver-
zichtet. Zunächst lag der Fokus der Implementierung auf dem UBAM UI. Außerdem war ein
Ziel der Implementierung, die Umsetzung des UBAM Konzepts mit möglichst hohen
Anteilen an Standard Software umzusetzen. Daher wurden alle erweiterten Module und
Dienste außer dem Meta-Daten Sync durch Standard Software abgebildet. In Ermangelung
eines Standards für den Zugriff auf Aktivitäten hätten diese Standard Software Komponenten
an die API Aufrufe angepasst werden müssen. Dies wäre möglich aber sehr aufwändig
gewesen. Der Zugriff der Komponenten erfolgt im Rahmen der Plattform API direkt auf
Datenfelder der Elementdokumente.
5.1.2 Projekthistorie und angrenzende Projekte
Dieser Abschnitt gibt einen Überblick über wichtige Meilensteine der Entwicklung des GCC-
AM. Die Forschungsprojekte am Groupware Competence Center der Universität Paderborn
waren stets von dem Ziel getrieben, die Produktivität des Wissensarbeiters am kollaborativen
Arbeitplatz zu verbessern und seine Arbeit angenehmer zu gestalten. Die Zusammenführung
198
der Aufgaben aus klassischen CSCW Systemen war daher ein notwendiger evolutorischer
Schritt. Erste Versuche resultierten in Portal-ähnlichen Ansätzen, die durch die Einbettung
mehrerer Aufgabenlisten aus unterschiedlichen Repositories in den Arbeitskontext des
Anwenders erfolgten. Dieses Konzept war jedoch auf wenige Szenarien mit homogener
Systemumgebung mit wenigen CIS, ähnlich dem des GCC beschränkt.
Ein weiterer Ansatz entstand durch den Bedarf, in wissensintensiven Umgebungen jedes
Dokument im Kontext seines CIS diskutieren zu können. Dies führte zur Entwicklung eines
Diskussionsmoduls für CIS in der Umgebung des GCC, das generisch in jedes Repository
eingebettet werden konnte. Durch dieses Modul entstand eine Vielzahl von isolierten
Diskussionssträngen und der Anwender musste eine Vielzahl an Systemen nutzen, um den
verteilten Diskussionen zu folgen. Auf Basis einer hybriden Datenbanktechnologie wurde ein
Prototyp entworfen, der die in mehreren Repositories verteilten Diskussionen dynamisch zu
einer einheitlichen Diskussionsumgebung aggregiert.266 Es handelte sich dabei um eine erste
Umsetzung eines Auto Harvester Konzeptes. Der Anwender selbst konfigurierte die Ziel
Repositories und definierte Filter, um die eingehenden Diskussionen aufzubereiten.
Mithilfe dieser Technologie wurde anschließend eine erste Version des GCC-AM entwickelt,
die ausschließlich auf Auto Harvesting beruhte. Diese Entwicklung wurde jedoch verworfen.
Die Implementierung sah keine persistente Speicherung der Aktivitätsstruktur vor. Für eine
detaillierte Diskussion der Auswirkungen dieser Vorgehensweise siehe Abschnitt 4.5.1. Die
Verfolgung dieses Ansatzes wurde außerdem verworfen, da sowohl die Performance der
dynamisch generierten Aktivitätsstrukturen nicht zufrieden stellend war, als auch aufgrund
der Tatsache, dass die Technologie der hybriden Datenbanken267 nicht im Offline-Modus zur
Verfügung stand. Des Weiteren musste die umfangreiche Konfiguration der Umgebung durch
den Anwender erfolgen, da nur dieser die Quellen seiner Aufgaben kennt. In Kombination mit
der eingeschränkten manuellen Manipulierbarkeit automatisch gesammelter Aktivitäten
erschien dieser Ansatz nur für eine kleine Zahl von fortgeschrittenen Anwendern als praxis-
tauglich. Der Ansatz ist im UBAM Konzept durch den Bezug zu impliziten und expliziten,
sowie abfragebasierten expliziten Dokumentenverknüpfungen erhalten geblieben (vgl.
Abschnitt 4.3.2).
Im gleichen Zeitraum wie die ersten Entwicklungen des GCC-AM wurde der IBM Workplace
Managed Client (WMC) veröffentlicht. IBM ist langjähriger Technologiepartner des GCC.
Daher wurde diese Java-basierte Technologie als mögliche Plattform für den GCC-AM
266 Vgl. [Yanik 2005].
267 Zum Einsatz kamen die Produkte IBM Lotus Domino mit NSFDB2 Technologie sowie IBM DB2 UDB.
199
evaluiert und erste Prototypen entwickelt (siehe Abbildung 5-2). Der WMC basierte zwar auf
Java, aber es gab dennoch Ansätze, Desktop-Applikationen einzubinden, die nicht auf Java
basierten. Dies wurde etwa mit dem IBM Lotus Notes Plugin implementiert, das es ermög-
lichte, klassische IBM Lotus Notes Applikationen im WMC anzuzeigen und auszuführen.
Ebenso war es möglich, eine Kombination aus Lotus Notes und WMC/Java basierten Kom-
ponenten zu entwickeln. Diese Technologie erschien besonders interessant, weil die Ein-
bettung beliebiger Desktop-Applikationen im Kontext von UBAM eine Technologieoption
mit Nutzenpotenzial darstellte. Daher wurde zunächst die Entscheidung getroffen, den GCC-
AM auf Basis des WMC umzusetzen, unter Einbettung von Funktionalitäten aus Lotus Notes.
Der WMC enthielt selbst ein Werkzeug zum Aktivitätenmanagement, den IBM Activity
Explorer. Dieser basierte maßgeblich auf Arbeiten von IBM Research, die etwa durch Geyer
et al.268 und Muller et al.269 beschrieben wurden. Ähnliche Entwicklungen wurden parallel
durch Moran, ebenfalls IBM, vorgestellt.270 Morans Arbeiten basierten unter anderem auf der
Tätigkeitstheorie, die ab diesem Zeitpunkt auch als theoretische Grundlage der Entwicklungen
am GCC verwendet wurde. Das Konzept des Activity Explorer, wie das aller Nachfolge-
produkte, ermutigte die Anwender jedoch zum Speichern von Inhalten in der Aktivitäten-
struktur. Dies hatte Potenzial, die Teamarbeit effizienter zu gestalten und war ein erster
Schritt in Richtung Aktivitätenmanagement. Aus Sicht des Wissensmanagements im Unter-
nehmen war dies jedoch kein signifikanter Fortschritt zur E-Mail-Nutzung, da die Dokumente
weiterhin in quasi Anwender-privaten Repositories gehalten wurden.
Im Bereich der Implementierung von Forschungsprototypen für das persönliche
Informationsmanagement stellte Kaptelinin einen Prototyp mit der Bezeichnung User-
Monitoring Environment for Activities (UMEA) vor271. UMEA führt die Prototypen zuvor
vorgestellter Forschungsprojekte anderer Autoren zusammen, indem geschickt deren Vorteile
kombiniert werden, etwa die Verwendung einer Interaction History und die Pflege
aktivitätsspezifischer Strukturen272. Durch die Kombination mit der automatisierten Pflege
der Aktivitätenstruktur gleicht er die Nachteile der Ursprungskonzepte aus. Der UMEA
Prototyp erfordert zunächst die manuelle Definition einer Aktivität. Anschließend
protokolliert er alle Interaktionen des Anwenders mit Dokumenten und fügt verwendete
Dokumente einer Interaktionshistorie hinzu.
268 Vgl. [Geyer et al. 2003].
269 Vgl. [Muller et al. 2004].
270 Vgl. [Moran 2003].
271 Vgl. [Kaptelinin 2003].
272 Kaptelinin bezeichnet Aktivitätsstrukturen als Project Contexts.
200
Abbildung 5-2: Screenshot des GCC Activity Manager auf Basis des WMC273
UMEA führte sehr gute Ideen für das individuelle Aktivitätenmanagement ein, etwa die
Nutzung eines Event Managers zur automatisierten Anlage von Aktivitätskontexten. Das
Grundparadigma der Aufzeichnung aller Anwenderinteraktionen, bis hin zum Drucken eines
Dokuments führt jedoch bereits bei der Vorstellung des Projekts zu Hinweisen, dass der
Aufwand für die Pflege fälschlicherweise hinzugefügter Aktivitätskontexte zu hoch ist.274
Diese Schilderung bestätigte die Entscheidung, als Grundparadigma des UBAM Konzepts
eine vollständig manuelle Pflege der Aktivitätsstruktur zu wählen. Die Idee, den Anwender
durch Automatismen zu unterstützen wurde im Architekturentwurf zum Event Manager und
zum Auto Harvester berücksichtigt.
Der WMC-basierte Prototyp des GCC-AM verfügte über viele wichtige Funktionalitäten zur
Abdeckung der Anforderungen am GCC, etwa Offline-Fähigkeit, Filter Funktionen und
insbesondere die manuelle Umorganisation der Aktivitäten. Die Umsetzung der Möglichkeit
umzusortieren erfolgte per Drag-and-drop. Diese Möglichkeiten entstanden durch die
Nutzung der Möglichkeiten der Java Umgebung, bei einer Implementierung in Lotus Notes
wäre dies nicht möglich gewesen.
273 Vgl. [Rasche 2006], S. 79.
274 Vgl. [Kaptelinin 2003], S. 358.
201
Im Jahr 2005 begann auch die Planung der neuen Version 8 von Lotus Notes. Das GCC war
IBM Lotus Design Partner während der Entwicklungsphase bis zum Release im September
2007, und so an technologischen, funktionalen und konzeptionellen Diskussionen während
der Entwicklung beteiligt. Dabei wurde auch die Weiterentwicklung des Activity Explorer
diskutiert. Die Place Awareness Komponente des Activity Explorer hatte maßgeblichen
Einfluss auf die Performance sowie die Skalierbarkeit des Systems. Da IBM das System
innerhalb der eigenen Organisation zum Management kollaborativer Aktivitäten einsetzen
wollte, hätte die Forderung nach der Erfassung aller Interaktionspartner (vgl. Abschnitt
4.4.6.1) nicht erfüllt werden können. Daher wurde der Activity Explorer in der Rich Client
Architektur nicht weiter entwickelt. Eine neue Applikation mit einem Browser UI auf Basis
von Web 2.0 Technologien wurde entwickelt und floss in das Release eines neuen Produkts
namens IBM Connections ein.
Abbildung 5-3: Screenshot GCC-AM auf Basis von Notes 8.5 mit Eclipse Portlet275
Neben der Neuentwicklung des Activity Explorer wurde die Entwicklung des WMC ein-
gestellt, und mit der Version 8 wurde Lotus Notes auf ein Java-basiertes Framework um-
gestellt, so dass die umfassenden technischen Möglichkeiten des WMC auch in Lotus Notes
zur Verfügung standen. Die Entwicklung des GCC-AM wurde daher erneut auf Lotus Notes
275 Vgl. [Wiele 2007], S. 79.
202
umgestellt. Lotus Notes enthielt ab Version 8 ebenfalls eine Plugin-API276 sowie einen UI
Service Bus. Das UI Service Bus Konzept von Notes 8 wird als Composite Application (CA)
Modell bezeichnet. Es kommt auch in anderen Produkten zum Einsatz, etwa in IBM
WebSphere Portal. Seit dieser Version ist der GCC-AM auf IBM Lotus Notes und Domino
basiert. Für eine Einordnung des GCC-AM in die Bandbreite verfügbarer CSCW Werkzeuge
siehe [Nastansky 2006]. Für eine funktionale Beschreibung siehe [Wiele 2007], [Rasche
2006] oder die Anwenderdokumentation des GCC Activity Manager. Eine Auswahl wichtiger
Funktionalitäten wird im nächsten Abschnitt beschrieben.
5.2 Basisarchitektur des GCC-AM
5.2.1 Aktivitätenmanagement mit dem UBAM UI
Der GCC-AM wurde so konzipiert, dass keine Inhaltsdaten in Elementdokumenten ge-
speichert werden. Als Elemente der Aktivitätsstruktur stehen Aktivitäten, Teilaktivitäten und
Aktivitätskontexte von Dokumenten zur Verfügung. Auf ein Element vom Typ Aufgabe
wurde verzichtet. Dies ist eine Besonderheit der Implementierung. Der Verzicht ist dadurch
begründet, dass alle CIS am GCC über die Möglichkeit verfügen, Aufgaben oder Workflows
zu jedem Dokument zu verwalten. Das Statusmanagement findet also stets im Zieldokument
statt. Für persönliche Aufgaben und Aufgaben ohne Aktivitätskontext kann auf die Aufgaben
Funktion der PIM-Umgebung zurückgegriffen werden. Da die PIM-Umgebung ein
Repository ist, können die Aufgaben als Zieldokumente verwendet werden. Für eine mögliche
zukünftige Erweiterung der Implementierung könnte der Status redundant in den Aktivitäts-
kontexten gepflegt werden, um so eine Statusanzeige in der Aktivitätenliste zu ermöglichen.
Durch einen erweiterten Meta-Daten Sync würde kein Zusatzaufwand für die Pflege von
Aufgaben entstehen.
Aktivitäten und Teilaktivitäten können deskriptive Meta-Daten enthalten. Es ist ein generi-
sches Konzept implementiert, das eine beliebige Anzahl deskriptiver Meta-Daten vorsieht. Es
wird dazu jeweils eine Kategorie angelegt, mit einer zugehörigen Auswahlliste in Frage
kommender Werte. Über diesen Mechanismus können etwa Prioritäten, ein Archiv Flag zum
Statusmanagement oder Stichwortklassen implementiert werden. Außerdem werden
administrative Meta-Daten verwaltet, etwa die Zugriffsrechte auf die Aktivität. Bei den
Elementdokumenten der Aktivitätskontexte sind Stichwortklassen entsprechend der GCC
Taxonomie fest definiert, etwa People, Places, Organizations und Label277.
276 Die Plugin API basiert auf der Eclipse RCP (Rich Client Platform), vgl. http://www.eclipse.org [07.10.2011].
277 Vgl. „K-pool Multidimensional Taxonomy“, [Nastansky 2005], S. 4f.
203
Es ist eine beliebig tiefe Hierarchie von Aktivitäten und Teilaktivitäten möglich. Aktivitäts-
kontexte können sowohl Aktivitäten, als auch Teilaktivitäten zugeordnet werden. Eine
arbiträre Umordnung ist per Drag-and-drop möglich. Die Elementdokumente der Aktivitäts-
kontexte können verwendet werden, um jeweils Verknüpfungen auf Dokumente im Dateisys-
tem des Betriebssystems, im Browser oder in einem CIS des GCC zu verwalten. Außerdem
können über View-Links, View-Anchor-Links und Datenbank-Links auch Verknüpfungen auf
dynamische Dokumentenkollektionen verwaltet werden. Jede Aktivitätsstruktur kann als
Vorlage für eine neue Aktivität verwendet werden. Im Kontextmenü der Aktivität steht eine
Funktion zum Kopieren (engl. Copy) zur Verfügung. Die Aktivitätsstruktur ist im Team,
abgesehen von Unterschieden aufgrund von Zugriffsrechten, immer gleich. Individuelle
Sichten wurden zum Zeitpunkt der WMC Implementierung entwickelt278 und für die Lotus
Notes Version nicht re-implementiert.
Für das Aktivitätenmanagement stehen zwei Varianten des GCC-AM zur Verfügung. Die
kompakte Variante steht in der Seitenleiste des Lotus Notes Client stets im Kontext aller
Dokumente zur Verfügung. Sie stellt die gesamte Liste an Aktivitätsstrukturen in Form einer
Aktivitätenansicht dar. Der Editor Bereich in dieser Variante besteht aus dem verbleibenden
UI des Notes Clients. Dokumente werden direkt aus dem Aktivitätskontext Element heraus
geöffnet. Die Aktivitätenansicht steht darüber hinaus auch in einer Variante zur Verfügung,
die den gesamten Bildschirm nutzt, um mit Aktivitäten zu arbeiten. Abbildung 5-3 zeigt diese
Variante des UBAM UI. Das UI ähnelt der Darstellung von Applikationen in Portal-
umgebungen in Form von Portlets. Die Aktivitätenliste ist eines dieser Portlets. Oberhalb der
Aktivitätenliste befindet sich das Portlet mit Filtermöglichkeiten. Hier können die Aktivitäten
basierend auf Kategorien, Priorität oder Zugriffsrechten gefiltert werden.
Ganz rechts befinden sich vier Portlets, welche aggregiert alle Meta-Daten aus Element-
dokumenten der Aktivitätskontexte anzeigen. Durch Selektion und Verknüpfung der
Selektionen durch logische Operatoren „AND“ und „OR“ kann hier ein Filter gesetzt werden,
so dass nur noch Aktivitätskontexte angezeigt werden, die entsprechende Meta-Daten auf-
weisen. Zwischen den bisher beschriebenen Bereichen befinden sich in der oberen Hälfte
Portlets für Aktivitätskontexte von PIM-Dokumenten, etwa E-Mails und Kalender Einträge.
In der unteren Hälfte sind drei durch den Anwender konfigurierbare Portlets verfügbar. Sie
werden als Business-Portlets bezeichnet, weil sie die Aktivitätskontexte der wichtigsten
Business-Applikationen des Anwenders anzeigen. Ein weiteres Portlet zeigt alle weiteren
Aktivitätskontexte an, die weder durch ein Business-Portlet, noch durch die PIM-Portlets
278 Vgl. [Dehring 2006].
204
erfasst werden. Dieses flexible Interface ermöglicht ein effizientes Arbeiten mit Dokumenten
aus verschiedenen Quellen im Kontext einer oder mehrerer Aktivitäten.
5.2.2 Harvesting
Der Harvesting Dialog zum Hinzufügen von Aktivitätskontexten zur Aktivitätsstruktur wird
innerhalb von Lotus Notes durch einen Toolbar Eintrag umgesetzt. Für Web-Dokumente steht
ein Plugin für Mozilla Firefox zur Verfügung, um effizient URLs von Webseiten als
Aktivitätskontext hinzuzufügen. Des Weiteren kann ein Aktivitätskontext aus dem Kontext-
menü des Microsoft Windows Explorer abgelegt werden. Diese Mechanismen wurden
exemplarisch implementiert. Für andere Betriebssysteme und Browser kann analog verfahren
werden. Abbildung 5-4 zeigt den Harvesting Dialog. Auf der linken Seite wird der voll-
ständige Dialog gezeigt. Auf der rechten Seite wird der Teil angezeigt, in dem Meta-Daten
dem Elementdokument zugewiesen werden. Alle Felder sind bereits mit Standardwerten
vorbelegt.
Abbildung 5-4: Harvesting Dialog279
In der Vorbelegung wird eine Verknüpfung auf das aktuell selektierte Zieldokument erstellt.
Der Anwender erhält außerdem die Kontextinformation, in welchen Aktivitäten sich bereits
ein Aktivitätskontext des aktuellen Dokuments befindet. Der ElementTitle sowie alle weiteren
Meta-Daten werden bereits mit entsprechenden Meta-Daten des Zieldokuments vorbelegt.
Der Aktivitätsfilter zur leichteren Identifikation spezifisch gesuchter Aktivitäten bleibt aus der
letzten Verwendung des Harvesting Dialogs erhalten. Außerdem ist die Teilaktivität
selektiert, der bei der letzten Verwendung ein Aktivitätskontext hinzugefügt wurde. Dies ist
279 Modifiziert aus [Wiele 2007].
205
hilfreich, da der Anwender bei der Erstellung der Aktivitätsstruktur zunächst alle Dokumente
einsammelt, die er im Kontext der Aktivität benötigt. Der Dialog wird also mehrfach
hintereinander geöffnet, um auf die gleiche Teilaktivität zuzugreifen.
Ist keine Änderung an den vorbelegten Werten erforderlich, kann der Anwender ohne weitere
Interaktion über die Schaltfläche „Add to Activity“ den Aktivitätskontext erzeugen. Das
Erstellen eines Aktivitätskontexts erfordert im Idealfall also lediglich zwei Mausklicks. Es ist
auch möglich, mehrere Aktivitätskontexte des Dokuments ohne Schließen des Dialogs in
mehreren Aktivitätsstrukturen anzulegen.
5.2.3 Repository und Offline-Fähigkeit
Die Aktivitätsstruktur wird in einem separaten Repository gespeichert, das ausschließlich
Dokumente des UBAM Systems enthält. Für jedes Element der Aktivitätsstruktur wird ein
Elementdokument gespeichert. Da sowohl das UBAM System, als auch die ECM
Infrastruktur am GCC auf Basis von IBM Lotus Notes implementiert ist, kann auf die Ver-
wendung eines dedizierten URI Proxies verzichtet werden. Wenn ein Repository nicht ver-
fügbar ist, übernimmt der Lotus Notes Client die Funktion des Proxies, um auf eine redundant
gespeicherte Version des gleichen Dokuments in einem anderen Repository zuzugreifen. Es
werden auch die Offline-Fähigkeiten der Basisplattform genutzt. Das UBAM System geht
dabei davon aus, dass die Ziel-Repositories offline zur Verfügung stehen. Ist dies nicht der
Fall, stehen ggf. die entsprechenden Dokumente nicht zur Verfügung.
Abbildung 5-5: Offline-Architektur GCC-AM
Abbildung 5-5 zeigt die modifizierte Architekturgrafik aus Abbildung 4-18 um die Funktions-
weise der Offline-Architektur des GCC-AM zu illustrieren. Wird in der Aktivitätenansicht
206
durch die Durchführung der Sekundäraktion ein Dokument geöffnet, wird dieses automatisch
aus dem als Offline-Repository bezeichneten Ziel-Repository in den Editor Bereich geladen.
5.2.4 Konfiguration und Sicherheit
Für die Entwicklung des GCC-AM wurde von der PAVONE AG in Paderborn ein Ent-
wicklungs-Framework für die Lotus-Notes-Umgebung zur Verfügung gestellt, das auch in
den Produkten der PAVONE AG zum Einsatz kommt. Es stellt Hilfsfunktionen für die
Programmierung bereit. Dazu gehört ein Konfigurationsmodul. In den persönlichen Einstel-
lungen kann jeder Anwender für sich die Business Portlets konfigurieren, denn nur der
Anwender weiß, welches die für ihn und seine Arbeit wichtigsten Applikationen und Reposi-
tories darstellen.
In der allgemeinen Konfiguration werden das Verzeichnis (Domino Directory) sowie das
PAVONE Organisationsverzeichnis hinterlegt. So ist es möglich, für die Zugriffssteuerung
auf Elemente von Aktivitäten die Aufbauorganisation zu verwenden. So kann etwa neben dem
Namen eines Anwenders auch eine Arbeitsgruppe ausgewählt werden. Für die Zugriffs-
steuerung wird ebenfalls ein Standard Modul des PAVONE Frameworks verwendet.
Die wissenschaftlichen Grundlagen des PAVONE Organisationsverzeichnis sind im Rahmen
des GroupOrga Projekts beschrieben.280 Durch die Verwendung des Verzeichnisses wird es
für zukünftige Erweiterungen des GCC-AM möglich, die Zuweisung von Personen zu
Aktivitäten durch abstrakte Organisationseinheiten zu modellieren und so ein Schablonen-
konzept für Aktivitäten zu implementieren.
Die Festlegung des Zugriffs wurde auf Aktivitätsebene implementiert. Die Zugriffsrechte für
das Elementdokument der Aktivität werden in die Aktivitätskontexte und Teilaktivitäten
übernommen. Ein Konzept, das feinere Granularitäten auf Ebene jedes Elementdokuments
ermöglicht wurde nicht implementiert, da dies im GCC Szenario nicht notwendig war. Der
Anwender sollte nur überlegen müssen, wer an der Aktivität mitarbeitet und danach mit
Sicherheitseinstellungen nicht mehr konfrontiert werden. In einer zukünftigen Version, die
auch für andere Szenarien konzipiert ist, sollte dies in den persönlichen Einstellungen konfi-
gurierbar sein, so dass der Anwender entscheiden kann, welche Granularität er bevorzugt.
5.3 Erweiterte Module und Dienste des GCC-AM
Neben dem beschriebenen PAVONE Framework wurden weitere Standardprodukte der
PAVONE AG eingesetzt, um einzelne Module und Dienste des GCC-AM zu implementieren.
280 Vgl. [Ott 1998].
207
Als Notification Manager wurde PAVONE nsfWatch verwendet. Das Produkt beobachtet
Ereignisse in Lotus Notes Datenbanken wie etwa die Änderung eines Feldes oder das Erstel-
len neuer Dokumente. Es fungiert also zugleich als eine Art Event Manager. Tritt ein Ereignis
auf, wird eine definierte Aktion ausgelöst, wie etwa das Versenden einer E-Mail. Sobald ein
neues Elementdokument erzeugt wird, können so die an der Aktivität beteiligten Team-
mitglieder per E-Mail informiert werden. Es handelt sich bei nsfWatch um einen asynchronen
Prozess, das heißt die Notification wird nicht unmittelbar versendet, wenn ein Ereignis auf-
tritt. Vielmehr wird periodisch in einem zuvor definierten Intervall auf neue Ereignisse
geprüft. Der Vorteil gegenüber der synchronen Implementierung ist die Möglichkeit, den
Anwender nicht mit E-Mails zu überfluten, denn mehrere Ereignisse werden zu einer News-
letter E-Mail mit mehreren Notifications zusammengefasst. Der Nachteil ist, dass die Team-
mitglieder erst mit einer zeitlichen Verzögerung über das Ereignis informiert werden. Auf-
grund von Restriktionen der Basisplattform liegt das kleinste einstellbare Intervall bei 5
Minuten.
Für die Meta-Daten Synchronisation wird das Produkt PAVONE nsfSync eingesetzt. Der
Anwender konfiguriert dazu für jedes Ziel-Repository die Meta-Daten Felder, die mit ent-
sprechenden Feldern der Elementdokumente von Aktivitätskontexten synchronisiert werden
sollen. Diese Konfiguration wird als Field-Mapping bezeichnet. Ein Feld des Element-
dokuments wird dabei als PrimaryKey definiert. Dieser dient zur Identifikation des Ziel-
dokuments bei der Synchronisation. Abbildung 5-6 zeigt einige Beispiele unterschiedlicher
Möglichkeiten von Field-Mappings. In dem Beispiel werden die Inhalte der Felder authors
und readers des Ziel-Dokuments vereinigt und in das Feld mainPeople des Elementdokuments
übertragen. Das Feld orgStructure wird durch eine programmatische Formel transformiert, so
dass beispielsweise aus der Organisationsstruktur der Name der Organisation extrahiert wird.
Dieser Name wird wiederum in das Feld organizations übertragen.
Der Inhalt des Feldes category wird dem Inhalt des Feldes keywords hinzugefügt. Das
bedeutet also, dass im Elementdokument zusätzlich zu den Meta-Daten des Zieldokuments
weitere Elementdokument-spezifische Meta-Daten eingetragen sind. Treten Änderungen an
den Meta-Daten des Zieldokuments auf, werden diese in das Elementdokument übernommen.
Die Felder title und subject werden synchronisiert. Treten also an einem der Dokumente
Änderungen auf, werden diese jeweils in das andere Dokument übertragen.
208
Abbildung 5-6: Beispiel für Meta-Daten Synchronisation
Für die Sharing Manager Implementierung wurde PAVONE KnowledgeGateway® ver-
wendet. Das Produkt dient dem Transfer von E-Mail-Dokumenten in Ziel-Repositories. Im
Kontext des UBAM Projekts wurde es aber als generisches Transfer-Werkzeug eingesetzt.
Stellt der Harvesting Mechanismus fest, dass es sich beim Anlegen eines Aktivitätskontexts
beim Ziel-Repository um ein privates Repository handelt, wird er auf diese Tatsache per
Dialog hingewiesen. Er kann dann entscheiden, ob er das Dokument vor der Zuweisung zu
einer Aktivität in ein gemeinsam genutztes Ziel-Repository transferieren möchte. In diesem
Fall wird vor dem Aufruf des Harvesting Dialogs der Transfer Dialog von PAVONE
KnowledgeGateway® aufgerufen. Ist das Dokument im Ziel-Repository angelegt, wird der
Harvesting Dialog im Kontext des neu angelegten Dokuments erneut aufgerufen, so dass der
Anwender nun den entsprechenden Aktivitätskontext in der Aktivitätsstruktur anlegen kann.
209
6 Schlussbetrachtungen und Ausblick
6.1 Zusammenfassung und kritische Würdigung
Seit Mitte der 1990er Jahre wird in der Forschung die Anwendung der Tätigkeitstheorie auf
den Entwurf von Interaktionsparadigmen für Computersysteme diskutiert und erforscht. Der
Fokus dieser Projekte lag stets im Bereich des Interaktionsdesigns von Systemen. Die Aus-
wirkungen dieser wichtigen Forschungen auf die innovative Gestaltung von Standardsoftware
im Bereich CIS zum Management der Aktivitäten selbst waren jedoch bis heute gering. So
kann die Erfüllung der in dieser Arbeit abgeleiteten Anforderungen in der Praxis heute nur
mit großen Anstrengungen erreicht werden. Selbst die Forderung nach einem zentralen
Zugriffsbereich für alle Aktivitäten ist in der Praxis üblicherweise nicht erfüllt. In diesem
Bereich besteht großes Potenzial, die Produktivität des Wissensarbeiters am kollaborativen
Arbeitsplatz zu verbessern.
Die vorliegende Arbeit stellt eine umfassende Auseinandersetzung mit Unified Business
Activity Management (UBAM) dar, der konzeptionell integrierten Betrachtung individuellen
und kollaborativen Aktivitätenmanagements. Dazu wurden zunächst die Grundlagen aus den
relevanten Bereichen der Wirtschaftswissenschaften, der Wirtschaftsinformatik und der
Tätigkeitstheorie aufbereitet und ein neuer konzeptioneller Rahmen für ein umfassendes
Aktivitätenmanagement Konzept im Kontext von Geschäftsprozessen geschaffen. In diesem
Rahmen wurden die aktuellen Entwicklungen im Unternehmensumfeld diskutiert sowie die
vorherrschenden Strukturen der Wissensarbeit am kollaborativen Arbeitsplatz berücksichtigt.
Insbesondere diese ökonomischen und infrastrukturellen Einflussfaktoren sind bei der
Konzeption der wenigen existierenden Forschungsarbeiten mit Implementierungsanteilen zu
diesem Thema in Bezug auf die Anforderungen von Unternehmen in einer globalisierten
Wissensgesellschaft nicht oder nur unzureichend berücksichtigt. In keinem dem Autor
bekannten Forschungsprojekt wurden Aspekte wie die notwendige Integration in die
bestehende IT-Infrastruktur von Unternehmen berücksichtigt. Auch explizite betriebs-
wirtschaftliche Bezüge sind bisher weitgehend nicht hergestellt worden. Dies stellt einen
wichtigen Kern des Erkenntnisfortschritts dieser Arbeit dar.
Die auf die Diskussion folgende Anforderungsanalyse bildet die Basis für einen ideal-
typischen Architekturentwurf für UBAM im Unternehmen. Dabei wurden die kognitiven
Fähigkeiten der Anwender sowie die sich durch arbeitsteilige Geschäftsprozesse ergebenden
Anforderungen berücksichtigt. Die Anwendung dieses Entwurfs in praxisrelevanten Szenarien
210
sowie die Beschreibung der prototypischen Implementierung für das Beispielszenario GCC
schließen die Arbeit ab.
Neben den theoretischen Erkenntnisgewinnen hat die Arbeit gezeigt, dass mit aktuell verfüg-
baren Technologien eine Implementierung eines UBAM Werkzeugs möglich ist, das sowohl
die Anforderungen von Unternehmen, als auch die der Anwender am kollaborativen Arbeits-
platz erfüllen kann. Auch können bei der Implementierung des Konzepts alle relevanten
Nutzendimensionen realisiert werden, etwa die Linderung des Agenturproblems, die Unter-
stützung des organisationalen Wissensmanagements und vor allem die Steigerung der
Produktivität am kollaborativen Arbeitsplatz.
Erste Erfahrungen aus dem Praxiseinsatz am GCC sind vielversprechend. Die Nutzung des
GCC-AM Prototypen ist aufgrund der definierten Anforderungen jedoch stark auf Umge-
bungen eingeschränkt, in denen IBM Lotus Notes einen Schwerpunkt der CIS-Infrastruktur
darstellt. Auch das Harvesting ist für eine homogene Umgebung optimiert und in heterogenen
Umgebungen nicht effizient einsetzbar. Außerdem führt der gewählte Fokus auf betriebs-
wirtschaftliche Anforderungen dazu, dass Anforderungen aus dem Forschungsbereich
Mensch-Maschine-Interaktion, Benutzungsfreundlichkeit und Software Ergonomie nur in
geringem Maße berücksichtigt werden konnten.
Das generelle Feedback von Praxispartnern des GCC auf das Forschungsprojekt sowie die
Erfahrungen aus der Berufspraxis des Autors in Bezug auf Anforderungen von Unternehmen
zeigen, dass der Bedarf für ein integriertes Aktivitätenmanagement in den Unternehmen
vorhanden ist. Die umfassenden Anforderungen, die sich aus der Analyse ergeben machen
jedoch auch deutlich, dass zum jetzigen Zeitpunkt eine vollständige operative Implementie-
rung der Anforderungen aus technischer und organisatorischer Sicht unter der Berück-
sichtigung ökonomischer Restriktionen für Unternehmen nur selten durchgeführt werden
wird. Es ist also eine Priorisierung und Funktionsauswahl vorzunehmen. Ein Grund liegt in
der noch fehlenden industrieweiten Etablierung und Akzeptanz der verfügbaren, noch jungen
Standards.
Neben der Existenz von Standards ist es als Voraussetzung für einen integrierten, Aktivitäten-
zentrischen Teamarbeitsplatz, der alle notwendigen Werkzeuge generisch unterstützt notwen-
dig, dass sich modularisierte kollaborative Komponenten auf breiter Front in Unternehmen
durchgesetzt haben. Hier sieht Gartner im Jahr 2009 zwei bis fünf Jahre bis zum Massen-
markt281. Trifft diese Prognose zu, ist ein Durchbruch in naher Zukunft zu erwarten. Dennoch
281 Vgl. [Thompson et al. 2009], S. 53.
211
ist für Funktionen wie der Nutzung von UBAM im Kontext flexibler Mashups oder
Composite Applications nur ein kleiner Teil von Power Usern unter den Wissensarbeitern
geeignet. Für viele andere Anwendergruppen muss neben der Effizienz die Einfachheit der
Bedienbarkeit und der Erlernbarkeit im Vordergrund stehen. Dies ist gerade auch ein wich-
tiger Erfolgsfaktor der sich immer stärker durchsetzenden Social Software Dienste.
Auch wenn die vollständige Umsetzung aktuell nicht angestrebt werden muss, zeigen die
Erfahrungen mit dem GCC Activity Manager dennoch, dass auch heute bereits ohne großen
technischen Aufwand mit Aktivitätenmanagement begonnen werden kann, um kurzfristig
Nutzen für das Unternehmen und den Wissensarbeiter durch Steigerung der Produktivität zu
generieren. Auch ist es zu empfehlen, frühzeitig zu beginnen, die Rahmenbedingungen für die
Implementierung von Aktivitätenmanagement zu schaffen, denn das Konzept hat großes
Potenzial, zu Produktivitätssteigerungen am kollaborativen Arbeitsplatz zu führen.
Die genannten Ergebnisse unterliegen, wie alle Konzepte in der Wirtschaftsinformatik, dem
dynamischen Wandel von Unternehmensstrukturen sowie der rasanten technologischen
Entwicklung. Das Konzept wurde über den Zeitraum einer Dekade evolutionär entwickelt und
optimiert. Diese Entwicklung ist mit der vorliegenden Arbeit nicht beendet. Zukünftige
Forschungsprojekte sollten etwa im Bereich der Verfeinerung des Konzepts im Rahmen von
Fallstudien angesiedelt sein.
Abschließend bleibt anzumerken, dass aufgrund der Natur der Tätigkeitstheorie auch das
Aktivitätenmanagement grundsätzlich kulturhistorisch geprägt ist. Das vorliegende Konzept
hat daher für Kulturkreise, dessen Organisation der Arbeitswelt signifikante Unterschiede zu
der in Deutschland und anderen westlichen Ländern aufweist, lediglich eine begrenzte
Aussagekraft. Auch hier besteht weiterer Forschungsbedarf um die Übertragbarkeit auf andere
Kulturkreise zu prüfen und bei Abweichungen der Anwendbarkeit ein neues Modell, oder
eine Generalisierung des vorliegenden Modells vorzunehmen.
6.2 Ausblick
Für an das UBAM Projekt anschließende Forschungsvorhaben ergibt sich im Bereich der
Kontextnavigation ein interessantes Betätigungsfeld, das in dieser Arbeit nur rudimentär
diskutiert werden konnte. Auch hier fehlen Standards, wie Kontextinformationen zu beschrei-
ben oder strukturieren sind, sowie entsprechende standardisierte Schnittstellen, um auf diese
Informationen in Repositories zuzugreifen. Dieses Feld hat insbesondere im Bereich der
Wissensmanagement Forschung Relevanz, um die Ressource Dokument noch produktiver
einzusetzen. Ebenfalls im Bereich Wissensmanagement anzusiedeln ist die weitere
212
Erforschung automatischer Methoden zur Analyse von Aktivitätsstrukturen. Dies dient dazu,
geeignete Kandidaten für Vorlagen und Schablonen für Aktivitätsstrukturen zu identifizieren
und im Unternehmen über ein Template Directory bereitzustellen. Sich wiederholende Muster
können aber auch ein Indiz dafür sein, dass hier ein Prozess vorliegt, der durch andere CSCW
Konzepte abgebildet werden sollte. Durch eine solche Erkenntnis kann evtl. ein besser
geeignetes Werkzeug für die Bearbeitung dieser Art von Aktivitäten identifiziert werden. Dies
kann ebenfalls zu Produktivitätsverbesserungen führen.
Für eine Weiterentwicklung des Prototypen mit dem Ziel ein UBAM Werkzeug für IBM-
Lotus-Notes-zentrische Unternehmensinfrastrukturen zu schaffen, sollten mit Fokus auf den
Anwender zwei Aspekte im Vordergrund stehen. Die Implementierung der individuellen
Sichten, die auf Basis des WMC Prototypen bereits existierte, muss mit dem neuen Proto-
typen erneut erfolgen. Eine weitere wichtige Entwicklung ist die generische Einbettung von
Desktop-Applikationen im Editor Bereich des GCC-AM. Mit Blick auf die Applikations-
architektur ist ein wichtiger Baustein die Implementierung einer Activity API und eine
konsequente Neuausrichtung der Implementierung an der API.
Die Herausforderungen für eine vollständige Implementierung der vorgeschlagenen UBAM
Architektur sind nicht technologischer Art. Vielmehr fehlten in diesem Bereich Standards mit
breiter Akzeptanz bei Industrie und namhaften Herstellern von Standardsoftware. Jedoch
selbst im Bereich geschlossener Infrastrukturen, etwa innerhalb derer eines einzelnen Soft-
wareherstellers, wurde ein portfolioweites, produktübergreifendes Aktivitätenmanagement
Konzept bisher nicht implementiert, obwohl seit mehr als fünf Jahren kommerzielle Produkte
verfügbar sind, die als eigenständiges Werkzeug zum kollaborativen Aktivitätenmanagement
konzipiert wurden.
Im Bereich der Einbettung von Applikationen im Umfeld von Desktop-Applikationen
existieren etablierte Technologien wie die Eclipse RCP oder das Windows COM Modell, es
fehlt jedoch an Standards, die herstellerübergreifend echte Composite Applications ermög-
lichen. Im Bereich der Web Technologien haben sich Portlets und iWidgets durchgesetzt.
Eine auf Standards basierende, durch den Anwender definierte Interaktion zwischen
Applikationskomponenten existiert jedoch nicht. Es sind ausschließlich proprietäre Lösungen
verfügbar. Eine Standardsoftware, die signifikante Teile des UBAM Konzepts umsetzt ist aus
den genannten Gründen daher aktuell nicht verfügbar. Im Bereich der geschlossenen Infra-
strukturen scheint sich jedoch ein vielversprechendes, auf Standards basierendes Konzept in
der Kombination aus ActivityStreams und OpenSocial Gadgets abzuzeichnen.
213
So hat etwa die Firma IBM im Januar 2011 unter der Bezeichnung IBM Social Business
Toolkit API282 eine produktübergreifende API vorgestellt, die Grundlage eines generischen
Notification Managers für alle Produkte aus dem Hause IBM sein soll, die am kollaborativen
Arbeitsplatz eingesetzt werden. Die vorgesehene Architektur ermöglicht sowohl die Anbin-
dung jeglicher Applikation auf Daten-Ebene, als auch auf UI-Ebene. Dabei wird zu einer
Notification durch ein OpenSocial Gadget mitgeliefert, das im Notification verarbeitenden
Client zur direkten Interaktion mit dem Ziel-Repository verwendet werden kann. Es kann
damit ein Posteingang für Aktivitätsstrukturelemente realisiert werden. Auf dieser Basis wird
die Entwicklung eines auf Standards basierenden UBAM Werkzeugs möglich sein, das
weitgehende Teile des UBAM Konzepts umsetzen können wird.
Auch diese Entwicklung wird in naher Zukunft wohl nicht dazu führen, dass sich ein umfas-
sendes UBAM Werkzeug realisieren lässt, weil nicht für jede Business Applikation ein
OpenSocial Gadget entwickelt werden wird. Aber das Toolkit ist ein erster wichtiger Schritt
hin zu einem zentralen Einstiegspunkt für alle individuellen und kollaborativen Aktivitäten im
Unternehmen.
282 Vgl. http://www.ibm.com/developerworks/lotus/ibmsocialbusinesstoolkit/ [03.04.2011].
214
7 Literaturverzeichnis
A
[Alchian/Demsetz 1972]
Alchian, Armen A.; Demsetz, Harold: Production, Information Costs, and Economic
Organization, in: American Economic Review, Volume 62, Issue 5, American Economic
Association, Nashville 1972, S. 777-795.
[Allen 2003]
Allen, David: Getting things done: the art of stress-free productivity, Penguin Books, London
2003.
[Ark et al. 1998]
Ark, Wendy; Dryer, D. Christopher; Selker, Ted; Zhai, Shumin: Landmarks to Aid
Navigation In a Graphical User Interface, in: Proceedings of Workshop on Personalized and
Social Navigation in Information Space, Swedish Institute of Computer Science, Kista 1998,
S. 102-108.
[Atkins et al. 2011]
Atkins, Martin; Norris, Will; Messina, Chris; Wilkinson, Monica; Dolin, Rob: Atom Activity
Streams 1.0, in: http://activitystrea.ms/specs/atom/1.0/ [07.10.2011], Activity Streams
Working Group, San Francisco 2011.
B
[Bannon/Bødker 1991]
Bannon, Liam; Bødker, Susanne: Beyond the interface: encountering artifacts in use, in:
Carroll, John M. (Hrsg.): Designing interaction: psychology at the human computer interface,
Cambridge University Press, Cambridge 1991, S. 227-253.
[Benford et al. 2002]
Benford, Steve; Reynard, Gail; Koleva, Boriana; Greenhalgh, Chris; Fraser, Mike: Computer
Supported Cooprative Play, in: Herczeg, Michael (Hrsg.): Mensch & Computer 2002,
Teubner, Stuttgart 2002, S. 21-29.
[Berman et al. 2010]
Berman, Saul; Korsten, Peter; Chopard, Grace; Jørgensen, Hans-Henrik; Kanemaki, Ryuichi;
Longworth, Sara; Lubowe, Dave; Riddleberger, Eric; Scheffler, Roland; Vlasselaer, Michel;
Bell, Ragna; Arnette, Denise; Ballou, Steve; Jain, Rajeev; Kasdan, Deborah; Kinser,
Christine; Landis, Keith; Martin, Kathleen; McDonald, Joni; Ranft, Susan; Slike, Christian;
Sudhakar, Raghuram; Talwar, Gaurav; van de Vliet, Vanessa: Unternehmensführung in einer
komplexen Welt – Global CEO Study, IBM Deutschland GmbH, Ehningen 2010.
[Berners-Lee/Fielding/Masinter 2005]
Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry: RFC 3986: Uniform Resource Identifier
(URI): Generic Syntax, in: http://tools.ietf.org/html/rfc3986 [07.10.2011], The Internet
Society, Reston 2005.
215
[Bertelsen/Korpela/Mursu 2004]
Bertelsen, Olav W.; Korpela, Mikko; Mursu, Anja: Proceedings of the first international
workshop on Activity Theory based practical mehtods for IT-design, Computer Science
Department, University of Aarhus, Aarhus 2004.
[Bloech 2004]
Bloech, Jürgen: Einführung in die Produktion, 5. Auflage, Springer, Berlin, Heidelberg 2004.
[Boardman/Sasse 2004]
Boardman, Richard; Sasse, M. Angela: „Stuff goes into the computer and doesn't come
out“: a cross-tool study of personal information management, in: Proceedings of the SIGCHI
conference on Human factors in computing systems, ACM Press, New York 2004, S. 583-
590.
[Böhm/Härtwig 2005]
Böhm, Karsten; Härtwig, Jörg: Prozessorientiertes Wissensmanagement durch
kontextualisierte Informationsversorgung aus Geschäftsprozessen, in: Ferstl, Otto; Sinz,
Elmar; Eckert, Sven; Isselhorst, Tilman (Hrsg.): Wirtschaftsinformatik 2005, Physica-Verlag,
Heidelberg, New York 2005, S. 943-962.
[Borghoff/Schlichter 1998]
Borghoff, Uwe M.; Schlichter, Johann H.: Rechnergestützte Gruppenarbeit, 2. Auflage,
Springer, Berlin 1998.
[Bødker 1991]
Bødker, Susanne: Through the interface, Erlbaum, Hillsdale 1991.
[Brown et al. 2010]
Brown, Al; Choy, David; Davis, Cornelia; Gur-Esh, Ethan: Content Management
Interoperability Services (CMIS) Version 1.0, in: http://docs.oasis-
open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html [07.10.2011], OASIS, Burlington 2010.
[Bruns/Dunkel 2010]
Bruns, Ralf; Dunkel, Jürgen: Event-Driven Architecture – Softwarearchitektur für
ereignisgesteuerte Geschäftsprozesse, Springer, Berlin, Heidelberg 2010.
[Bucur/Beaune/Boissier 2006]
Bucur, Oana; Beaune, Philippe; Boissier, Olivier: Steps Towards Making Contextualized
Decisions: How to Do What You Can, with What You Have, Where You, in: Roth-Berghofer,
Thomas R.; Schulz, Stefan; Leake, David B. (Hrsg.): Modeling and Retrieval of Context,
Springer, Berlin, Heidelberg 2006, S. 62-85.
[Bullinger et al. 2002]
Bullinger, Hans-Jörg (Hrsg.); Eberhardt, Claus-T.; Gurzki, Thorsten; Hinderer, Henning:
Marktübersicht Portal Software für Business-, Enterprise-Portale und E-Collaboration,
Fraunhofer IRB Verlag, Stuttgart 2002.
216
[Bundesministerium für Wirtschaft und Technologie 2010]
TÜV Rheinland: Breitbandatlas 2010 – Teil 1: Ergebnisse, Bundesministerium für Wirtschaft
und Technologie, Berlin 2010.
C
[Cadenhead et al. 2009]
Cadenhead, Rogers; Camden, Sterling; Carletti, Simone; Holderness, James; Levine, Jenny;
Lunt, Eric; Morin, Randy Charles; Parman, Ryan; Savin, Jake; Shellen, Jason; Querna, Paul:
RSS 2.0 Specification, in: http://www.rssboard.org/rss-2-0-11 [07.10.2011], RSS Advisory
Board 2009.
[Campbell et al. 2002]
Campbell, Ben; Rosenberg, Jonathan; Schulzrinne, Henning; Huitema, Christian; Gurle,
David: RFC 3428: Session Initiation Protocol (SIP) Extension for Instant Messaging, in:
http://tools.ietf.org/html/rfc3428 [07.10.2011], The Internet Society, Reston 2002.
[Cappiello et al. 2006]
Cappiello, Cinzia; Comuzzi, Marco; Mussi, Enrico; Pernici, Barbara: Context Management
for Adaptive Information Systems, in: Electronic Notes in Theoretical Computer Science,
Volume 146, Issue 1, Elsevier 2006, S. 69-84.
[Card/Mackinlay/Shneiderman 1999]
Card, Stuart K.; Mackinlay, Jock D.; Shneiderman, Ben (Hrsg.): Readings in information
visualization, Morgan Kaufmann Publishers, San Francisco 1999.
[Carroll et al. 2003]
Carroll, John M.; Neale, Dennis C.; Isenhour, Philip L.; Rosson, Mary Beth; McCrickard, D.
Scott: Notification and awareness: synchronizing task-oriented collaborative activity, in:
International Journal of Human-Computer Studies, Volume 58, Issue 5, Elsevier, Amsterdam
2003, S. 605-632.
[Cavaness 2004]
Cavaness, Chuck: Programming Jakarta Struts, 2. Auflage, O’Reilly Media, Sebastopol 2004.
[Christensen/Bardram 2002]
Christensen, Henrik Bærbak; Bardram, Jakob E.: Supporting Human Activities -- Exploring
Activity-Centered Computing, in: Borriello, Gaetano; Holmquist, Lars Erik (Hrsg.): UbiComp
2002: Ubiquitous Computing, Springer, Berlin, Heidelberg 2002, S. 37-62.
[Churchill et al. 2000]
Churchill, Elizabeth F.; Trevor, Jonathan; Bly, Sara; Nelson, Les; Cubranic, Davor: Anchored
conversations: chatting in the context of a document, in: Proceedings of the SIGCHI
conference on Human factors in computing systems 2000, ACM Press, New York 2000,
S. 454-461.
217
[Coase 1937]
Coase, Ronald H.: The Nature of the Firm, in: Economica, Volume 4, Issue 16, Blackwell
Publishing, Oxford 1937, S. 386-405.
[Crockford 2006]
Crockford, Douglas: RFC 4627: The application/json Media Type for JavaScript Object
Notation (JSON), in: http://tools.ietf.org/html/rfc4627 [07.10.2011], The Internet Society,
Reston 2006.
[Czerwinski/Horvitz/Wilhite 2004]
Czerwinski, Mary; Horvitz, Eric; Wilhite, Susan: A diary study of task switching and
interruptions, in: Proceedings of the SIGCHI conference on Human factors in computing
systems, ACM Press, New York 2004, S. 175-182.
D
[D’Aveni/Gunther 1995]
D’Aveni, Richard A.; Gunther, Robert E.: Hyperwettbewerb, Campus, Frankfurt 1995.
[Davenport/Prusak 1998]
Davenport, Thomas H.; Prusak, Laurence: Working Knowledge, Harvard Business School
Press, Boston 1998.
[Dawson/Howes 1998]
Dawson, Frank; Howes, Tim: RFC 2426: vCard MIME Directory Profile, in:
http://tools.ietf.org/html/rfc2426 [07.10.2011], The Internet Society, Reston 1998.
[Dehring 2006]
Dehring, Karim: Konzeption und prototypische Implementierung einer Architektur für
individualisierte Sichten auf Teamaktivitäten, Diplomarbeit, Universität Paderborn, Paderborn
2006.
[Denning 2006]
Denning, Peter J.: Infoglut, in: Communications of the ACM, Volume 49, Issue 7, ACM
Press, New York 2006, S. 15-19.
[Desruisseaux 2009]
Desruisseaux, Bernard: RFC 5545: Internet Calendaring and Scheduling Core Object
Specification (iCalendar), in: http://tools.ietf.org/html/rfc5545 [07.10.2011], The Internet
Society, Reston 2009.
[Dey/Abowd 1999]
Dey, Anind K.; Abowd, Gregory D.: Towards a Better Understanding of Context and
Context-Awareness, GVU Technical Report GIT-GVU-99-22, in:
ftp://ftp.cc.gatech.edu/pub/gvu/tr/1999/99-22.pdf [30.10.2007], Georgia Institute of
Technology, Atlanta 1999.
218
[Dostal et al. 2005]
Dostal, Wolfgang; Jeckle, Mario; Melzer, Ingo; Zengler, Barbara: Service-orientierte
Architekturen mit Web Services, Spektrum Akademischer Verlag, München 2005.
[Dragunov et al. 2005]
Dragunov, Anton N.; Dietterich, Thomas G.; Johnsrude, Kevin; McLaughlin, Matthew; Li,
Lida; Herlocker, Jonathan L.: TaskTracer: a desktop environment to support multi-tasking
knowledge workers, in: Proceedings of the 10th international conference on Intelligent user
interfaces, ACM Press, New York 2005, S. 75-82.
[Ducheneaut/Bellotti 2001]
Ducheneaut, Nicolas; Bellotti, Victoria: Email as habitat: An exploration of embedded
personal information management, in: ACM Interactions, Volume 8, Issue 5, ACM Press,
New York 2001, S. 30-38.
E
[Ehlers 1997]
Ehlers, Peter: Integriertes Projekt- und Prozeßmanagement auf Basis innovativer
Informations- und Kommunikationstechnologien: Das GroupProject-System, Shaker Verlag,
Aachen 1997.
[Ellis 1983]
Ellis, Clarence A.: Formal and informal models of office activity, in: Mason, Richard E. A.
(Hrsg.): Proceedings of the IFIP 9th World Computer Congress, North-Holland, Amsterdam,
New York, Oxford 1983, S. 11-22.
[Engeström 1990]
Engeström, Yrjö: Learning, Working, and Imagining: Twelve Studies in Activity Theory,
Orienta-Konsultit Oy, Helsinki 1990.
[Engeström 2001]
Engeström, Yrjö: Expansive Learning at Work: toward an activity theoretical
reconceptualization, in: Journal of Education and Work, Volume 14, No. 1, Carfax
Publishing, London 2001, S. 133-156.
[Engeström/Miettinen/Punamäki 1999]
Engeström, Yrjö; Miettinen, Reijo; Punamäki, Raija-Leena: Perspectives on Activity Theory
(Reprint), Cambridge University Press, New York 2003, Erstveröffentlichung 1999.
[Erdmann 2001]
Erdmann, Ingo: Direkt manipulatives graphisches Dokumentenmanagement in Groupware-
Datenbanken, Diplomarbeit, Universität Paderborn, Paderborn 2001.
[Erlei/Leschke/Sauerland 1999]
Erlei, Mathias; Leschke, Martin; Sauerland, Dirk: Neue Institutionen Ökonomik, Schäffer-
Poeschl, Stuttgart 1999.
219
F
[Fielding 2000]
Fielding, Roy T.: Architectural Styles and the Design of Network-based Software
Architectures, Dissertation, University of California, Irvine 2000.
[Fikes 1982]
Fikes, Richard E.: A Commitment-Based Framework for Describing Informal Cooperative
Work, in: Cognitive Science, Volume 6, Issue 4, Ablex Publishing, Norwood 1982,
S. 331-347.
[Fischer et al. 2002]
Fischer, Joachim; Herold, Werner; Dangelmaier, Wilhelm; Nastansky, Ludwig; Suhl, Leena:
Bausteine der Wirtschaftsinformatik, 3. Auflage, Erich Schmidt Verlag, Berlin, Bielefeld,
München 2002.
[Fisher et al. 2006]
Fisher, Danyel; Brush, A. J.; Gleave, Eric; Smith Marc A.: Revisiting Whittaker & Sidner's
"email overload" ten years later, in: Proceedings of the 20th anniversary conference on
Computer supported cooperative work, ACM Press, New York 2006, S. 309-312.
[Fitzpatrick et al. 2007]
Fitzpatrick, Brad; Recordon, David; Hardt, Dick; Hoyt, Josh: OpenID Authentication 2.0, in:
http://openid.net/specs/openid-authentication-2_0.html [07.10.2011], OpenID Foundation,
San Ramon 2007.
[Furnas 1999]
Furnas, George W.: Effective View Navigation, in: Card, Stuart K.; Mackinlay, Jock D.;
Shneiderman, Ben (Hrsg.): Readings in information visualization, Morgan Kaufmann
Publishers, San Francisco 1999, S. 589-596.
G
[Garrett 2005]
Garrett, Jesse James: Ajax: A New Approach to Web Applications, in:
http://www.adaptivepath.com/ideas/essays/archives/000385.php [07.10.2011], Adaptive Path,
San Francisco 2005.
[Gary/Hill/Prager 2011]
Gary, Jason Roy; Hill, Charlie; Prager, Scott: INV104 – IBM Project Vulcan: Blueprint to
integrate the collaboration portfolio – and beyond, in: Presentations at Lotusphere 2011, IBM
Corporation, Armonk 2011.
[Geyer et al. 2003]
Geyer, Werner; Vogel, Jürgen; Cheng, Li-Te; Muller, Michael J.: Supporting Activity-centric
Collaboration Through Peer-to-Peer Shared Objects, in: Proceedings of the 2003 international
ACM SIGGROUP conference on Supporting group work, ACM Press, New York 2003,
S. 115-124.
220
[Geyer et al. 2006]
Geyer, Werner; Muller, Michael J.; Moore, Martin Thomas; Wilcox, Eric; Cheng, Li-Te;
Brownholtz, Beth; Hill, Charles M.; Millen, David R.: Activity Explorer: Activity-centric
collaboration from research to product, in: IBM Systems Journal, Volume 45, Issue 4, IBM
Corporation, Armonk 2006, S. 713-738.
[Gilbert et al. 2009]
Gilbert, Mark R.; Knox, Rita E.; Austin, Tom; Drakos, Nikos; Maoz, Michael; Harris, Kathy;
Valdes, Ray; Phifer, Gene; Bell, Toby; Mann, Jeffrey; Andrews, Whit; Silver, Michael A.;
Rozwell, Carol; Gootzit, David; Harris, Marti; Newman, David; Shegda, Karen M.; Cain,
Matthew W.; Bradley, Anthony; Knipp, Eric: Hype Cycle for High-Performance Workplace,
Gartner, Stamford 2009.
[González/Mark 2004]
González, Victor M.; Mark, Gloria: Constant, constant, multi-tasking craziness: managing
multiple working spheres, in: Proceedings of the SIGCHI conference on Human factors in
computing systems, ACM Press, New York 2004, S. 113-120.
[Gora/Scheid 2001]
Gora, Walter; Scheid, Eva Maria: Organisation auf dem Weg zur Virtualität, in: Gora, Walter
(Hrsg.): Virtuelle Organisationen im Zeitalter von E-Business und E-Government, Springer,
Berlin 2001, S. 9-24.
[Gregorio/de hÓra 2007]
Gregorio, Joe; de hÓra, Bill (Hrsg.): RFC 5023: The Atom Publishing Protocol, in:
http://www.ietf.org/rfc/rfc5023.txt [07.10.2011], The Internet Society, Reston 2007.
[Gutenberg 1983]
Gutenberg, Erich: Die Produktion, 24. Auflage, Springer, Berlin, Heidelberg, New York
1983.
H
[Hahnl 2004]
Hahnl, Olaf: Föderierte Portale zur Überwindung inner- und zwischenbetrieblicher
Portalproliferation, Dissertation, Universität Paderborn, Paderborn 2004.
[Harrison 2004]
Harrison, Beverly L.: An activity-centric approach to context-sensitive time management, in:
CHI 2004, Workshop on Temporal Aspects of Work,
http://www.cs.bath.ac.uk/~hci/TICKS/chi-2004-workshop/acceptedpapers.html [01.11.2007],
University of Bath, Bath 2004.
[Heinrich 2001]
Heinrich, Lutz Jürgen: Wirtschaftsinformatik, 2. Auflage, Oldenbourg, München 2001.
221
[Hepper 2008]
Hepper, Stefan: JSR 286: Portlet Specification 2.0, in: http://jcp.org/en/jsr/detail?id=286
[07.10.2011], IBM Corporation, Armonk 2008.
[Hilpert 1992]
Hilpert, Wolfgang: Workflow Management im Office-Bereich mit verteilten
Dokumentendatenbanken, in: Nastansky, Ludwig (Hrsg.): Workgroup Computing, S+W
Steuer und Wirtschaftsverlag, Hamburg 1992, S. 127-140.
[Hinds/McGrath 2006]
Hinds, Pamela; McGrath, Cathleen: Structures that work: social structure, work structure and
coordination ease in geographically distributed teams, in: Proceedings of the 2006 20th
anniversary conference on Computer supported cooperative work, ACM Press, New York
2006, S. 343-352.
[Horvitz/Apacible 2003]
Horvitz, Eric; Apacible, Johnson: Learning and reasoning about interruption, in: Proceedings
of the 5th international conference on Multimodal interfaces, ACM Press, New York 2003,
S. 20-27.
[Hupfer et al. 2004]
Hupfer, Susanne; Cheng, Li-Te; Ross, Steven; Patterson, John: Introducing Collaboration into
an Application Development Environment, in: Proceedings of the 2004 ACM conference on
Computer supported cooperative work, ACM Press, New York 2004, S. 21-24.
[Huth/Erdmann/Nastansky 2001]
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, Ralph H. (Hrsg.): Proceedings of the 34th Hawaii International
Conference on System Sciences, IEEE Computer Society Press, Los Alamitos 2001.
[Huth 2004]
Huth, Carsten: Groupware-basiertes Ad-hoc-Workflow-Management: Das GroupProcess-
System, Dissertation, Universität Paderborn, Paderborn 2004.
[Huth et al. 2007]
Huth, Carsten; Völker, Norbert; Hahnl, Olaf; Reinhold, Björn: InterPROM – A Collaborative
Framework driven by Business Needs, in: International Conference on e-Business, INSTICC,
Barcelona 2007.
I, J
[IBM Corporation 2008]
IBM: The Global Human Capital Study 2008, IBM Corporation, Armonk 2008.
222
[Iqbal/Horvitz 2010]
Iqbal, Shamsi T.; Horvitz, Eric: Notifications and awareness: a field study of alert usage and
preferences, in: Proceedings of the 2010 ACM conference on Computer supported
cooperative work, ACM Press, New York 2010, S. 27-30.
[Jeng/Chang/Chung 2004]
Jeng, Jun-Jang; Chang, Henry; Chung, Jen-Yao: A policy framework for Web-Service based
Business Activity Management (BAM), in: Information Systems and E-Business
Management, Volume 2, Number 1, Springer, Berlin, Heidelberg 2004, S. 59-87.
[Jordan/Evdemon 2007]
Jordan, Diane; Evdemon, John: Web Services Business Process Execution Language Version
2.0, in: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html [07.10.2011], OASIS,
Burlington 2007.
K
[Kaptelinin/Kuutti/Bannon 1995]
Kaptelinin, Victor; Kuutti, Kari; Bannon, Liam: Activity Theory: Basic Concepts and
Applications, in: Blumenthal, Brad; Gornostaev, Juri; Unger, Claus (Hrsg.): Human-
Computer Interaction, Springer, Berlin, Heidelberg, New York 1995, S. 189-201.
[Kaptelinin 1996]
Kaptelinin, Victor: Computer-Mediated Activity: Functional Organs in Social and
Developmental Contexts, in: Nardi, Bonnie A. (Hrsg.): Context and Consciousness, MIT
Press, Cambridge 1996, S. 45-68.
[Kaptelinin 2003]
Kaptelinin, Victor: UMEA: translating interaction histories into project contexts, in:
Proceedings of the SIGCHI conference on Human factors in computing systems, ACM Press,
New York 2003, S. 353-360.
[Kaptelinin/Nardi 2006]
Kaptelinin, Victor; Nardi, Bonnie A.: Acting with technology – Activity Theory and
Interaction Design, MIT Press, Cambridge 2006.
[Karnani 2001]
Karnani, Fritjof: Virtuelle Wertschöpfungskette – mit revolutionären Strategiekonzepten die
Märkte erobern, in: Gora, Walter; Bauer, Harald (Hrsg.): Virtuelle Organisationen im
Zeitalter von E-Business und E-Government, Springer, Berlin 2001, S. 95-104.
[Kawell et al. 1988]
Kawell, Leonard; Beckhardt, Steven; Halvorsen, Timothy; Ozzie, Raymond; Greif, Irene:
Replicated document management in a group communication system, in: Proceedings of the
1988 ACM conference on Computer-supported cooperative work, ACM Press, New York
1988, S. 395-404.
223
[Keil-Slawik 1992]
Keil-Slawik, Reinhard: Artifacts in software design, in: Floyd, Christiane (Hrsg.): Software
development and reality construction, Springer, Berlin, New York 1992, S. 168-188.
[Knox et al. 2006]
Knox, Rita E.; Logan, Debra; Austin, Tom; Andrews, Whit; Lundy, James; Shegda, Karen
M.; Bell, Toby; Chin, Kenneth; Phifer, Gene; Drakos, Nikos; Cain, Matthew W.; Latham,
Lou; Valdes, Ray; Fenn, Jackie; Harris, Kathy; Silver, Michael A.; Elliot, Bern; De Azevedo
Filho, Waldir Arevolo; Pittet, Stephanie; Eid, Tom; Weiner, Allen; McGuire, Mike; Baker,
Van L.; Cearley, David W.; Gootzit, David; Smith, David Mario; Gilbert, Mark R.; Mann,
Jeffrey; Jump, Annette; Harris, Richard G.; Weiss, George J.: Hype Cycle for High-
Performance Workplace, Gartner, Stamford 2006.
[Kock 2007]
Kock, Ned (Hrsg.): Information Systems Action Research, Springer, New York 2007.
[Krcmar 2005]
Krcmar, Helmut: Informationsmanagement, 4. Auflage, Springer, Berlin, Heidelberg 2005.
[Kuutti 1991]
Kuutti, Kari: The concept of activity as a basic unit of analysis for CSCW research, in:
Bannon, Liam; Robinson, Mike; Schmidt, Kjeld (Hrsg.): Proceedings of the 1991 Second
European Conference on Computer Supported Cooperative Work, Kluwer Academic
Publishers, Dordrecht 1991, S. 249-264.
[Kuutti 1996]
Kuutti, Kari: Activity Theory as a potential framework for human-computer interaction
research, in: Nardi, Bonnie A. (Hrsg.): Context and Consciousness, MIT Press, Cambridge
1996, S. 17-44.
L
[Lakatos 1982]
Lakatos, Imre: Die Methodologie der wissenschaftlichen Forschungsprogramme, Vieweg,
Braunschweig 1982.
[Lee 2006]
Lee, Kathy J.: What goes around comes around: an analysis of del.icio.us as social space, in:
Proceedings of the 2006 20th anniversary conference on Computer supported cooperative
work, ACM Press, New York 2006, S. 191-194.
[Leont’ev 1977]
Leont’ev, Aleksej N.: Tätigkeit, Bewusstsein, Persönlichkeit, Klett, Stuttgart 1977.
[Lieberman/Paternò/Wulf 2006]
Lieberman, Henry; Paternò, Fabio; Wulf, Volker (Hrsg.): End user development, Springer,
Dordrecht 2006.
224
M
[Malone 1983]
Malone, Thomas W.: How do people organise their desks? Implications for the design of
office information systems, in: ACM Transactions on Office Information Systems, Volume 1,
Issue 1, ACM Press, New York 1983, S. 99-112.
[Malone/Crowston 1990]
Malone, Thomas W.; Crowston, Kevin: What is coordination theory and how can it help
design cooperative systems?, in: Proceedings of the 1990 ACM conference on Computer-
supported cooperative work, ACM Press, New York 1990, S. 357-370.
[Manes 2006]
Manes, Anne Thomas: Service-Oriented Architecture: Developing the Enterprise Roadmap,
Burton Group, Midvale 2006.
[Mann et al. 2009]
Mann, Jeffrey; Drakos, Nikos; Frank, Andrew; Rozwell, Carol; Harris, Kathy; Valdes, Ray;
Prentice, Stephen; Bell, Toby; McGuire, Mike; Baker, Van L.; LeHong, Hung; Otter,
Thomas; Andrews, Whit; Cain, Matthew W.; Basso, Monica; Goldman, Matthew; Bradley,
Anthony; Maoz, Michael; Dunne, Michael; Weiner, Allen; Harris, Marti; Sarner, Adam;
Prentice, Brian; Fenn, Jackie; Smith, David Mario; Knipp, Eric: Hype Cycle for Social
Software, Gartner, Stamford 2009.
[Mark/Gonzalez/Harris 2005]
Mark, Gloria; Gonzalez, Victor M.; Harris, Justin: No task left behind? Examining the nature
of fragmented work, in: Proceedings of the SIGCHI conference on Human factors in
computing systems, ACM Press, New York 2005, S. 321-330.
[McFarlane 2002]
McFarlane, Daniel C.: Comparison of Four Primary Methods for Coordinating the
Interruption of People in Human–Computer Interaction, in: Human-Computer Interaction,
Volume 17, Issue 1, Lawrence Erlbaum Associates, Mahwah 2002, S. 63-139.
[McFarlane/Latorella 2002]
McFarlane, Daniel C.; Latorella, Kara A.: The Scope and Importance of Human Interruption
in Human-Computer Interaction Design, in: Human-Computer Interaction, Volume 17, Issue
1, Lawrence Erlbaum Associates, Mahwah 2002, S. 1-61.
[McMillan 2007]
McMillan, Robert: Corporate data slips out via Google Calendar, in:
http://www.computerworld.com/s/article/9016920/Corporate_data_slips_out_via_Google_Cal
endar [07.10.2011], Computerworld, Framingham 2007.
[McNiff/Whitehead 2005]
McNiff, Jean; Whitehead, Jack: Action research, 2. Auflage, Reprint, Routledge Falmer,
London, New York 2005.
225
[Mertens et al. 2005]
Mertens, Peter; Bodendorf, Freimut; König, Wolfgang; Picot, Arnold; Schumann, Matthias;
Hess, Thomas: Grundzüge der Wirtschaftsinformatik, 9. Auflage, Springer, Berlin,
Heidelberg 2005.
[Millen et al. 2005]
Millen, David R.; Muller, Michael J.; Geyer, Werner; Wilcox, Eric; Brownholtz, Beth:
Patterns of media use in an activity-centric collaborative environment, in: Proceedings of the
SIGCHI conference on Human factors in computing systems, ACM Press, New York 2005,
S. 879-888.
[Monson et al. 2006]
Monson, Philip; Chase, Lisa; Larsson, Dick; Santana, Manny; Grapengiesser, Frank: IBM
Lotus Domino 7 Application Development, in:
http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/redp4102.html [07.10.2011],
IBM Corporation, Armonk 2006.
[Moody et al. 2006]
Moody, Paul; Gruen, Daniel; Muller, Michael J.; Tang, John; Moran, Thomas P.: Business
activity patterns: A new model for collaborative business applications, in: IBM Systems
Journal, Volume 45, Issue 4, IBM Corporation, Armonk 2006, S. 683-694.
[Moore 1995]
Moore, Kenneth: The Lotus notes storage system, in: Proceedings of the 1995 ACM
SIGMOD international conference on Management of data, ACM Press, New York 1995,
S. 427-428.
[Moran 2003]
Moran, Thomas P.: Activity: Analysis, Design, and Management, in: Proceedings of the
Symposium on the Foundations of Interaction Design 2003, Interaction Design Institute Ivrea,
Mailand 2003.
[Moran 2005]
Moran, Thomas P.: Unified Activity Management: Explicitly Representing Activity in Work-
Support Systems, in: European Conference on Computer Supported Cooperative Work:
Workshop on Activity, http://www.daimi.au.dk/~bardram/ecscw2005/papers/moran.pdf
[07.10.2011], IBM Corporation 2005.
[Muller et al. 2004]
Muller, Michael J.; Geyer, Werner; Brownholtz, Beth; Wilcox, Eric; Millen, David R.: One-
Hundred Days in an Activity-Centric Collaboration Environment based on Shared Objects, in:
Proceedings of the SIGCHI conference on Human factors in computing systems, ACM Press,
New York 2004, S. 375-382.
[Musser/O’Reilly 2006]
Musser, John; O’Reilly, Tim: Web 2.0 Principles and Best Practices, O’Reilly Media,
Sebastopol 2006.
226
N
[Nalebuff/Brandenburger 1996]
Nalebuff, Barry J.; Brandenburger, Adam M.: Coopetition – kooperativ konkurrieren,
Campus, Frankfurt 1996.
[Nardi 1996]
Nardi, Bonnie A. (Hrsg.): Context and Consciousness, MIT Press, Cambrigde 1996.
[Nardi 1998]
Nardi, Bonnie A.: Concepts of Cognition and Consciousness: Four Voices, in: Journal of
Computer Documentation, Volume 22, Issue 1, ACM Press, New York 1998, S. 31-48.
[Nastansky et al. 2002]
Nastansky, Ludwig; Bruse, Thomas; Haberstock, Philipp; Huth, Carsten; Smolnik, Stefan:
Büroinformations- und Kommunikationssysteme: Groupware, Workflow Management,
Organisationsmodellierung und Messaging-Systeme, in: Fischer, Joachim; Herold, Werner;
Dangelmaier, Wilhelm; Nastansky, Ludwig; Suhl, Leena: Bausteine der
Wirtschaftsinformatik, 3. Auflage, Erich Schmidt Verlag, Berlin, Bielefeld, München 2002,
S. 235-327.
[Nastansky 2005]
Nastansky, Ludwig: K-Pool: A Process-driven Knowledge Management System for
Contextual Collaboration in Virtual Communities, in: Kommers, Piet; Isaias, Pedro:
Proceedings of the 2005 IADIS International Conference: Web Based Communities, IADIS
Press, Lissabon 2005, S. 134-141.
[Nastansky 2006]
Nastansky, Ludwig: Geschäftsprozesse aus Sicht des einzelnen Mitarbeiters –
Aktivitätsmanagement als komplementäre Struktursicht auf Workflows, in: Loos, Peter;
Krcmar, Helmut (Hrsg.): Architekturen und Prozesse, Springer, Berlin, Heidelberg, New
York 2006, S. 99-116.
[Nastansky/Erdmann 2005]
Nastansky, Ludwig; Erdmann, Ingo: BP126 – Domino 7 and DB2: Effective Use of Access
and Query Views, in: Presentations at Lotusphere 2005, IBM Coporation, Armonk 2005.
[Nastansky/Erdmann 2006]
Nastansky, Ludwig; Erdmann, Ingo: Office-Exzellenz im Unternehmen – strategische
Positionierung kollaborativer IT-Trends, Universität Paderborn, Paderborn 2006.
[Norman 1991]
Norman, Donald A.: Cognitive artifacts, in: Carroll, John M. (Hrsg.): Designing interaction:
psychology at the human computer interface, Cambridge University Press, Cambridge 1991,
S. 17-38.
227
[Nottingham/Sayre 2005]
Nottingham, Mark; Sayre, Robert (Hrsg.): RFC 4287: The Atom Syndication Format, in:
http://tools.ietf.org/html/rfc4287 [07.10.2011], The Internet Society, Reston 2005.
[Nuescheler 2009]
Nuescheler, David: JSR 283: Content Repository for Java Technology API Version 2.0, in:
http://jcp.org/en/jsr/detail?id=283 [07.10.2011], Sun Microsystems, Santa Clara 2009.
O
[O'Hanlon 2005]
O'Hanlon, Charlene: A conversation with Ray Ozzie, in: Social computing, Volume 3,
Issue 9, ACM Press, New York 2005, S. 18-26.
[Österle 2007]
Österle, Hubert: Business Engineering – Geschäftsmodelle transformieren, in: Loos, Peter;
Krcmar, Helmut (eds.): Architekturen und Prozesse, Springer, Berlin, Heidelberg 2007,
S. 71-84.
[OpenSocial Foundation 2010]
OpenSocial and Gadgets Specification Group: OpenSocial Specification 1.1, in:
http://opensocial-resources.googlecode.com/svn/spec/1.1/OpenSocial-Specification.xml
[07.10.2011], OpenSocial Foundation, San Francisco 2010.
[Orlikowski/Lacono 2001]
Orlikowski, Wanda J.; Lacono, C. Suzanne: Desperately Seeking the ’IT’ in IT Research – A
Call to Theorizing the IT Artifact, in: Information Systems Research, Volume 12, Issue 2,
Informs, Hanover 2001, S. 121-134.
[Ott 1998]
Ott, Marcus: Organization Design as a Groupware-supported Team Process, Dissertation,
Universität Paderborn, Paderborn 1998.
[Owen 2001]
Owen, Harrison: Open space technology, Klett-Cotta, Stuttgart 2001.
P
[Paulheim 2011]
Paulheim, Heiko: Ontology-based Application Integration, Springer, New York 2011.
[Picot/Dietl/Franck 2005]
Picot, Arnold; Dietl, Helmut; Franck, Egon: Organisation, 4. Auflage, Schäffer-Poeschel,
Stuttgart 2005.
[Picot/Reichwald/Wigand 2003]
Picot, Arnold; Reichwald, Ralf; Wigand, Rolf T.: Die grenzenlose Unternehmung, 5. Auflage,
Gabler, Wiebaden 2003.
228
[Pirolli/Card/van der Wege 2000]
Pirolli, Peter; Card, Stuart K.; van der Wege, Mija M.: The Effect of Information Scent on
Searching Information Visualizations of Large Tree Structures, in: Proceedings of the
working conference on Advanced visual interfaces, ACM Press, New York 2000, S. 161-172.
[Plattner 2007]
Plattner, Hasso: The World Is Not Plug and Play: Why Design Will Be a Critical Competency
for Enterprise Software Providers, Partners, and Customers, in: Loos, Peter; Krcmar, Helmut
(Hrsg.): Architekturen und Prozesse, Springer, Berlin, Heidelberg 2007, S. 3-9.
[Ploch 2009]
Ploch, Holger: Explikation und Wahrnehmung kollaborativer Arbeitskontexte mittels
Workspace Awareness am Beispiel von Prozessunterstützungssystemen – Konzepte,
Rahmenmodell und Realisierung, Dissertation, Universität Paderborn, Paderborn 2009.
[Polanyi 1985]
Polanyi, Michael: Implizites Wissen, Suhrkamp, Frankfurt am Main 1985.
[Probst/Raub 1995]
Probst, Gilbert; Raub, Steffen: Action Research: Ein Konzept angewandter
Managementforschung, in: Die Unternehmung, Volume 49, Issue 1, Versus, Zürich 1995,
S. 3-19.
[Probst/Raub/Romhardt 2006]
Probst, Gilbert; Raub, Stefan; Romhardt, Kai: Wissen managen – Wie Unternehmen ihre
wertvollste Ressource optimal nutzen, 5. Auflage, Gabler, Wiesbaden 2006.
Q, R
[Rasche 2006]
Rasche, Torben: Konzeption und prototypische Implementierung einer Architektur für
kollaboratives Aktivitätenmanagement, Diplomarbeit, Universität Paderborn, Paderborn 2006.
[Riempp 1998]
Riempp, Gerold: Wide Area Workflow Management: Creating Partnerships for the 21st
Century, Springer, Berlin, London 1998.
[Rosenberg 2005]
Rosenberg, Martin: Vom Mailing zum Mailmanagement, Diplomarbeit, Universität
Paderborn, Paderborn 2005.
[Roth 2006]
Roth, Craig: Communication and Collaboration in Portals: Half the Battle, Burton Group,
Midvale 2006.
229
S
[Sala et al. 2011]
Sala, Luis; Halvorson, Mike; Simons, Jay; Arumugam, Thangam; Budhiraja, Navin; Schalk,
Chris; Grandison, Tyrone; Hutcheson, Tracy; Johnson, David; Maximilien, Michael; Weitzel,
Mark; Bride, Laurent; Horne, Robert; Mayerhofer, John; Meyer, David; Wachob, Gabriel:
Enterprise OpenSocial Whitepaper, in: http://www.opensocial.org/page/enterprise-opensocial
[03.04.2011], OpenSocial Foundation, San Francisco 2011.
[Schmidt/Bannon 1992]
Schmidt, Kjeld; Bannon, Liam: Taking CSCW seriously – Supporting articulation work, in:
Computer Supported Cooperative Work, Volume 1, Issue 1-2, Kluwer Academic Publishers,
Dordrecht 1992, S. 7-40.
[Seiwert 2002]
Seiwert, Lothar J.: Das neue 1 x 1 des Zeitmanagement, 24. Auflage, Gräfe und Unzer,
München 2002.
[Sen et al. 2006]
Sen, Shilad; Geyer, Werner; Muller, Michael J.; Moore, Marty; Brownholtz, Beth; Wilcox,
Eric; Millen, David R.: FeedMe: a collaborative alert filtering system, in: Proceedings of the
20th anniversary conference on Computer supported cooperative work, ACM Press, New
York 2006, S. 89-98.
[Sermersheim 2006]
Sermersheim, Jim: RFC 4511: Lightweight Directory Access Protocol (LDAP): The Protocol,
in: http://tools.ietf.org/html/rfc4511 [07.10.2011], The Internet Society, Reston 2006.
[Silva Filho et al. 2006]
Silva Filho, Roberto S.; Geyer, Werner; Brownholtz, Beth; Redmiles, David F.:
Understanding the Trade-Offs of Blending Collaboration Services in Support of Contextual
Collaboration, in: Dimitriadis, Yannis A.; Zigurs, Ilze; Gómez-Sánchez, Eduardo:
Groupware: Design, Implementation, and Use, Springer, Berlin, Heidelberg 2006, S. 270-285.
[Silver 2006]
Silver, Mark S.: Browser-based applications: popular but flawed?, in: Information Systems
and E-Business Management,Volume 4, Number 4, Springer, Berlin, Heidelberg 2006, S.
361-393.
[Simmen et al. 2008]
Simmen, David E.; Altinel, Mehmet; Markl, Volker; Padmanabhan, Sriram; Singh, Ashutosh:
Damia: Data Mashups for Intranet Applications, in: Proceedings of the 2008 ACM SIGMOD
international conference on management of data, ACM Press, New York 2008, S. 1171-1182.
[Simon/Bernhardt 2010]
Simon, Nicole; Bernhardt, Nikolaus: Twitter – mit 140 Zeichen zum Web 2.0, 2. Auflage,
Open Source Press, München 2010.
230
[Simpson/Prusak 1995]
Simpson, Chester W.; Prusak, Laurence: Troubles with information overload – Moving from
quantity to quality in information provision, in: International Journal of Information
Management, Volume 15, Issue 6, Elsevier, Kidlington 1995, S. 413-425.
[Smith et al. 2006]
Smith, David Mario; Drakos, Nikos; White, Andrew; Elliot, Bern; Phifer, Gene; Lundy,
James; Mann, Jeffrey; Orans, Lawrence; Latham, Lou; Cain, Matthew W.; Valdes, Ray; Eid,
Tom; De Azevedo Filho, Waldir Arevolo; Fenn, Jackie; Logan, Debra; Basso, Monica; Knox,
Rita E.; Chamberlin, Ted; Hallawell, Arabella; Firstbrook, Peter; Wheatman, Vic; Ouellet,
Eric; Gootzit, David; Andrews, Whit; Skorupa, Joe; Harris, Kathy; Costello, Rich; Stuart,
Donald A.; Gilbert, Mark R.; Austin, Tom: Hype Cycle for Collaboration and
Communication, Gartner, Stamford 2006.
[Smith/Zdonik 1987]
Smith, Karen E.; Zdonik, Stanley B.: Intermedia: A Case Study of the Differences Between
Relational and Object-Oriented Database Systems, in: Conference proceedings on Object-
oriented programming systems, languages and applications, ACM Press, New York 1987, S.
452-465.
[Smolnik 2006]
Smolnik, Stefan: Wissensmanagement mit Topic Maps in kollaborativen Umgebungen,
Shaker Verlag, Aachen 2006.
[Smolnik/Erdmann 2003]
Smolnik, Stefan; Erdmann, Ingo: Visual navigation of distributed knowledge structures in
groupware-based organizational memories, in: Business Process Management Journal,
Volume 9, Issue 3, Emerald, Bradford 2003, S. 261-280.
[Staud 2005]
Staud, Josef: Datenmodellierung und Datenbankentwurf, Springer, Berlin, Heidelberg 2005.
[Stone 2006]
Stone, Linda: Attention – The Real Aphrodisia, in: O'Reilly Radar,
http://radar.oreilly.com/archives/2006/03/etech_linda_stone_1.html [07.10.2011], O’Reilly
Media, Sebastopol 2006.
T, U
[Thompson et al. 2009]
Thompson, Jess; Pezzini, Massimo; Natis, Yefim V.; Sholler, Daniel; Lheureux, Benoit J.;
Kenney, L. Frank; Plummer, Daryl C.; Malinverno, Paolo; Beyer, Mark A.; Knipp, Eric;
McClure, David; Blechar, Mike; Driver, Mark; Schulte, W; Clark, William; King, Michael J.;
Gassman, Bill: Hype Cycle for Application Infrastructure, Gartner, Stamford 2009.
[Thompson 2008]
Thompson, Rich: Web Services for Remote Portlets Specification v2.0, in: http://docs.oasis-
open.org/wsrp/v2/wsrp-2.0-spec.html [07.10.2011], OASIS, Burlington 2008.
231
[Ulrich/Hill 1979]
Ulrich, Peter; Hill, Wilhelm: Wissenschaftstheoretische Grundlagen der
Betriebswirtschaftlehre, in: Raffée, Hans; Abel, Bodo (Hrsg.): Wissenschaftstheoretische
Grundfragen der Wirtschaftswissenschaften, Verlag Franz Vahlen, München 1979,
S. 161-190.
V, W
[Wallis/North 1986]
Wallis, John Joseph; North, Douglass C.: Measuring the Transaction Sector in the American
Economy, 1870-1970, in: Engerman, Stanley L.; Gallman, Robert E. (Hrsg.): Long-term
Factors in American Economic Growth, University of Chicago Press, Chicago 1986, S. 95-
161.
[Wang-Nastansky 2007]
Wang-Nastansky, Pei: From Learning Objects to Knowledge Nuggets – Contextual Model for
Workplace Learning On-demand in Practice (CM-WLOD), Dissertation, Universität
Paderborn, Paderborn 2007.
[Weerawarana et al. 2006]
Weerawarana, Sanjiva; Curbera, Francisco; Leymann, Frank; Storey, Tony; Ferguson, Donald
F.: Web services platform architecture, Prentice Hall, Upper Saddle River 2006.
[Whittaker et al. 1997]
Whittaker, Steve; Swanson, Jerry; Kucan, Jakov; Sidner, Candy: TeleNotes: managing
lightweight interactions in the desktop, in: ACM Transactions on Computer-Human
Interaction (TOCHI) Volume 4, Issue 2, ACM Press, New York 1997, S. 137-168.
[Whittaker et al. 2004]
Whittaker, Steve; Jones, Quentin; Nardi, Bonnie A.; Creech, Mike; Terveen, Loren; Isaacs,
Ellen; Hainsworth, John: ContactMap: Organizing communication in a social desktop, in:
ACM Transactions on Computer-Human Interaction (TOCHI), Volume 11, Issue 4, ACM
Press, New York 2004, S. 445-471.
[Whittaker/Sidner 1996]
Whittaker, Steve; Sidner, Candace: Email overload: exploring personal information
management of email, in: Proceedings of the SIGCHI conference on Human factors in
computing systems: common ground, ACM Press, New York 1996, S. 276-283.
[Wiele 2007]
Wiele, Frank: GCC Activity Manager: Konzeption und prototypische Implementierung einer
Umgebung zum kollaborativen Management von Aktivitäten – Realisierung auf Basis eines
Rich Client Composite Application Frameworks, Diplomarbeit, Universität Paderborn,
Paderborn 2008.
[Williamson 1975]
Williamson, Oliver E.: Markets and Hierarchies, Free Press, New York 1975.
232
X, Y
[Yanik 2005]
Yanik, Murat: Navigationsmethodik für hierarchisch strukturierte Beziehungen elektronischer
Dokumente in Knowledge Management Umgebungen – Konzeption und prototypische
Realisierung eines Komponenten-basierten Ansatzes, Diplomarbeit, Universität Paderborn,
Paderborn 2005.
Z
[Zahn/Schmid 1996]
Zahn, Erich; Schmid, Uwe: Produktionswirtschaft, Lucius und Lucius, Stuttgart 1996.
[Zhang et al. 2007]
Zhang, Shaoke; Zhao, Chen; Moody, Paul; Liao, Qinying; Zhang, Qiang: Lightweight
Collaborative Activity Patterns in Project Management, in: Harris, Don (Hrsg.): Engineering
Psychology and Cognitive Ergonomics, Springer, Berlin, Heidelberg 2007, S. 465-473.
233
Ehrenwörtliche Erklärung
Hiermit erkläre ich, dass ich die vorliegende Dissertation selbständig verfasst und nur die
angegebenen Quellen und Hilfsmittel benutzt habe. Wörtlich oder inhaltlich übernommene
Stellen sind als solche gekennzeichnet.
Die Dissertation ist keine Gemeinschaftsleistung.
Hiermit erkläre ich, dass ich noch an keiner deutschen oder ausländischen Hochschule den
Antrag auf ein Promotionsverfahren gestellt habe.
Paderborn, im Oktober 2011
Ingo Erdmann
234
