Steuerungsinstrumente und Maßnahmen für Wissensrisiken

Steuerungsinstrumente und
Maßnahmen für Wissensrisiken
Theoretische Untersuchung, Entwurf eines Modells und
Entwicklung eines Prototyps
Thomas Moser

Response Planning for knowledge risks
A theoretical study, development of a model and implementation of a prototype
Master’s Thesis
at
Graz University of Technology
submitted by
Thomas Moser
Institut für Wissensmanagement und Wissensvisualisierung (IWW),
Technische Universität Graz
A-8010 Graz
20th October 2005
c○ Copyright 2005 by Thomas Moser
Advisor: Univ.-Prof. Dr. Klaus Tochtermann
Supervisor: Dr. Stefanie Lindstaedt

Steuerungsinstrumente und Maßnahmen für Wissensrisiken
Theoretische Untersuchung, Entwurf eines Modells und Implementierung eines Prototyps
Magisterarbeit
an der
Technischen Universität Graz
vorgelegt von
Thomas Moser
Institut für Wissensmanagement und Wissensvisualisierung (IWW),
Technische Universität Graz
A-8010 Graz
20. Oktober 2005
c○ Copyright 2005, Thomas Moser
Begutachter: Univ.-Prof. Dr. Klaus Tochtermann
Betreuer: Dr. Stefanie Lindstaedt

Abstract
As a result of rising competition in most branches, new laws and regulations the need
for effective risk management increases. Effective risk management requires critical risks
identification and treatment. In this paper the author wants to determine how far the
task of risk response planning can be supported.
For this purpose, the author combines the key risks for companies with knowledge inten-
sive processes and business operations to a new definition. The definition distinguishes
between risks based on knowledge gaps and risks which endanger the resource knowl-
edge. Based on this definition for the term knowledge risk, the author formulates the
Risk Response Planning Model and implements it in a software prototype for an easier
application.
Essential parts of the model are a catalog on generic risks and a catalog on adequate risk
responses. These two catalogs are linked together with a logic, which is developed by the
author. If a user instances a new specific risk from a generic one, the model will propose
adequate generic risk responses. Thus the model and the prototype support the user by
the planning of adequate risk responses for knowledge risks.

Kurzfassung
Aufgrund steigenden Wettbewerbs, neuen Gesetzen und Vorschriften gewinnt der Um-
gang mit Risiken immer mehr an Bedeutung. Ein effizientes Risikomanagement erfordert
die Betrachtung von erfolgskritischen Risiken. In wie fern sich die Entwicklung von geeig-
neten Steuerungsmaßnahmen für diese Risiken unterstützen lässt, untersucht der Autor
in dieser Arbeit.
Dazu fasst er die für ein Unternehmen mit wissensintensiven Geschäftsprozessen und
Tätigkeiten kritischen Risiken in einer neuen, weiter reichenden Definition zusammen.
Darin wird zwischen wissensbasierten und wissensgefährdenden Risiken unterschieden.
Aufbauend auf dieser Definition für den Begriff Wissenrisiken entwirft der Autor das
Risk Response Planning Modell und implementiert einen Prototyp zur vereinfachten An-
wendung.
Wesentliche Stützpunkte des Modells sind ein Katalog an abstrahierten, generellen Wis-
sensrisiken und ein Katalog an geeigneten Steuerungsmaßnahmen. Diese Kataloge werden
durch eine vom Autor entwickelte Logik miteinander verbunden. Instanziiert ein Benut-
zer ein neues fallspezifisches Risiko von einem aus dem generischen Wissensrisikokatalog,
kann das Modell anhand der logischen Verbindung zwischen den beiden Katalogen dem
Benutzer geeignete generische Steuerungsmaßnahmen vorschlagen. Auf diese Weise un-
terstützt das Modell den Benutzer bei der Entwicklung von passenden Steuerungsmaß-
nahmen für Wissensrisiken.

I hereby certify that the work presented in this thesis is my own and that work performed
by others is appropriately cited.
Ich versichere hiermit, diese Arbeit selbständig verfasst, andere als die angegebenen Quel-
len und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfsmittel be-
dient zu haben.

Danksagung
Diese Arbeit hätte ohne die Unterstützung und den Einfluss der folgenden Personen nicht
ihre heutige Form gefunden. Jedem möchte ich an dieser Stelle einzeln meinen besonde-
ren Dank aussprechen und ihre hinterlassenen Spuren in der Arbeit kurz nachzeichnen:
Univ.-Prof. Klaus Tochtermann für die Betonung des technischen Aspekts der Arbeit und
für eine sehr hilfreiche Anleitung für die Einleitung und Schlussbemerkung; Dr. Stefanie
Lindstaedt für den roten Faden durch die Arbeit und das gerechtfertigte Hinterfragen
mancher von mir verwendeter Begriffe und Formulierungen; Mag. Stefan Koller für die
Idee dieser Arbeit und seine Vorschläge bei der Entwicklung des RRP Modells mit allen
seinen Komponenten; Dipl.-Ing. Peter Scheir und Jordi Valles für die offenen Ohren und
Hilfestellungen bei der Konzeption und Implementierung des Prototyps; Barbara Knall-
nig, Christina Kaufmann, Josef Prainsack und Jean-Francois Dufour für das professionelle
Korrektur lesen;
i

Inhaltsverzeichnis
1. Einleitung 1
1.1. Relevanz des Themas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Umfeld der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Forschungsfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Risikomanagement 4
2.1. Begriffserklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Historische Betrachtung . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Was ist Risiko? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Unternehmensweites Risikomanagement . . . . . . . . . . . . . . . 8
2.2.3. Projektrisikomanagement . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Risikomanagementprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Planungsphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. Risikoidentifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3. Risikobewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.4. Maßnahmenplanung . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Risikokategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1. Unternehmensweite Kategorien . . . . . . . . . . . . . . . . . . . . 18
2.4.2. Projektbezogene Kategorien . . . . . . . . . . . . . . . . . . . . . . 20
2.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3. Wissen und Risiko 23
3.1. Begriff Wissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ii

3.2. Allgemeiner Zusammenhang . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Einleitung Wissensrisiken . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4. Wissensgefährdende Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.1. Personelle Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2. Know-how-Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.3. Definition Wissensrisiken nach Meyer und Zbinden . . . . . . . . . 34
3.5. Wissensbasierte Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6. Definition Wissensrisiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7. Eigenständige Kategorie Wissensrisiken . . . . . . . . . . . . . . . . . . . 36
3.8. Generischer Wissensrisikokatalog . . . . . . . . . . . . . . . . . . . . . . . 37
3.9. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4. Steuerungsstrategien und Maßnahmen 41
4.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2. Strategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1. Vermeidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2. Umverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.3. Minderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.4. Akzeptanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3. Steuerungsmaßnahmen für wissensgefährdende Risiken . . . . . . . . . . . 46
4.3.1. Personelle Wissensrisiken . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.2. Sachlich-Technische Wissensrisiken . . . . . . . . . . . . . . . . . . 48
4.3.3. Organisatorische Wissensrisiken . . . . . . . . . . . . . . . . . . . . 49
4.3.4. Marktbezogene Wissensrisiken . . . . . . . . . . . . . . . . . . . . . 51
4.4. Steuerungsmaßnahmen für wissensbasierte Risiken . . . . . . . . . . . . . 52
4.4.1. Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.2. Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.3. Erstellen von Inhalten . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.4. Content Management . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.5. Adaptierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.6. E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.7. Persönliche Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.8. Künstliche Intelligenz . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.9. Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5. Auszug aus dem Katalog an generischen Maßnahmen für Wissensrisiken . 55
4.6. Auswählen der geeignetsten Maßnahme . . . . . . . . . . . . . . . . . . . . 58
iii

4.6.1. Reihung der Risikoszenarien . . . . . . . . . . . . . . . . . . . . . . 58
4.6.2. Effizienz der Steuerungsmaßnahmen . . . . . . . . . . . . . . . . . 59
4.6.3. Verfügbarkeit von benötigten Ressourcen . . . . . . . . . . . . . . . 59
4.6.4. Wichtigkeit für die Stakeholder . . . . . . . . . . . . . . . . . . . . 59
4.6.5. Dringlichkeit der Maßnahme . . . . . . . . . . . . . . . . . . . . . . 60
4.7. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5. RRP Modell 61
5.1. Modell als Teil des Knowledge@Risk Framework . . . . . . . . . . . . . . . 62
5.1.1. Konzeptive Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.2. Anwendungsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.3. Software Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2. Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.1. Generische Wissensrisiken und Maßnahmen . . . . . . . . . . . . . 64
5.2.2. Instanziieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.3. Logische Verknüpfung . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3. Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.1. Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4. Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.1. Risikoidentifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.2. Vorschlag an geeigneten Steuerungsmaßnahmen . . . . . . . . . . . 70
5.4.3. Beschreiben der fallspezifschen Maßnahme . . . . . . . . . . . . . . 71
5.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6. Knowledge@Risk Prototyp 74
6.1. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2. Technische Entscheidungen . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.1. Webapplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.2. ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.3. Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.4. Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3. Goal Oriented Interaction Design . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.1. Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.3.3. Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4. Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
iv

6.4.1. Projektleiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.2. Arbeitspaketleiter . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.4.3. Risk Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.5. Funktionsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.5.1. Projekteigenschaften erfassen . . . . . . . . . . . . . . . . . . . . . 91
6.5.2. Arbeitspakete beschreiben und Arbeitspaketleiter festlegen . . . . . 91
6.5.3. Risiken identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.5.4. Risiken bewerten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.5.5. Maßnahmen treffen . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.5.6. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.6. Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.6.1. Hauptnavigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.6.2. Sitemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.6.3. Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.7. Klassendesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.7.1. Benutzerklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.7.2. Beschreibungsklassen . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.7.3. Generische Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.7.4. Maßnahmenklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.7.5. Risikoklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.7.6. Projektklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.7.7. Managerklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.8. Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.8.1. Datenbank Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.8.2. Tabelle Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.9. TreeView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.9.1. Unterstützung bei der Identifikation . . . . . . . . . . . . . . . . . 106
6.9.2. Unterstützung bei der Steuerung . . . . . . . . . . . . . . . . . . . 107
6.10. DataGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.10.1. Anzeigen der persönlichen Risiken . . . . . . . . . . . . . . . . . . 109
6.10.2. Anzeigen der persönlichen Aufgaben . . . . . . . . . . . . . . . . . 110
6.11. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7. Schlussbetrachtung 112
7.1. Definition Wissensrisiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.2. Generische Kataloge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
v

7.3. RRP Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.4. Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A. Generischer Wissensrisiko Katalog 116
B. Generischer Maßnahmen Katalog für Wissensrisiken 119
C. Logik 125
D. Personas 126
D.1. Heiner Rumpler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
D.2. Friedrich Kracher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
E. Use Cases 130
F. Vollständiges Klassendiagramm 137
Literaturverzeichnis 142
vi

Abbildungsverzeichnis
1.1. Gegenüberstellung Themenbereiche - Kapitel der Arbeit . . . . . . . . . . 3
2.1. Begriff Risiko nach [Kon01], Seite 5 . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Geographische Verteilung der Standards und Richtlinien . . . . . . . . . . 11
2.3. Überblick Risikomanagementprozesse . . . . . . . . . . . . . . . . . . . . . 13
2.4. AS/NZS 4360:1999 [Bro99] Risikomatrix . . . . . . . . . . . . . . . . . . . 16
2.5. Beispiele für Treiber von Schlüsselrisiken nach [IRM02] . . . . . . . . . . . 19
2.6. Universal Risk Areas nach [HH02] . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Hierarchisches Konzept für Wissen nach [DP98] . . . . . . . . . . . . . . . 24
3.2. Wissensgefährdende Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3. Wissensbasierte Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4. Know-how-Risikokategorien im Überblick nach [PK98] . . . . . . . . . . . 30
3.5. Eigenständige Betrachtung von Wissensrisiken . . . . . . . . . . . . . . . . 37
5.1. Knowledge@Risk Framework (Quelle: [Kol05]) . . . . . . . . . . . . . . . . 63
5.2. Risk Response Planning Modell . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3. Ausschnitt aus der Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1. Dynamische Generierung von Webinhalten mittels Embedded Code . . . . 77
6.2. Primäre Persona: Heiner Rumpler . . . . . . . . . . . . . . . . . . . . . . . 80
6.3. Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4. Uses Cases - Projektleiter und Arbeitspaketleiter . . . . . . . . . . . . . . 87
6.5. Use Cases - Risk Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6. Screenshot - Zugriffsrechte Risk Owner . . . . . . . . . . . . . . . . . . . . 89
6.7. Aktivitätsdiagramm mit Rollen . . . . . . . . . . . . . . . . . . . . . . . . 90
6.8. Riskmap nach [HRD99] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.9. Mockup - Knowledge@Risk Prototyp . . . . . . . . . . . . . . . . . . . . . 95
vii

6.10. Sitemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.11. Benutzerklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.12. Beschreibungsklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.13. Generische Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.14. Maßnahmenklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.15. Risikoklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.16. Projektklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.17. Managerklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.18. Datenbankdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.19. Auschnitt aus der Tabelle Logic . . . . . . . . . . . . . . . . . . . . . . . . 105
6.20. Screenshot - Neues Risiko erfassen . . . . . . . . . . . . . . . . . . . . . . 107
6.21. Screenshot - Neue Maßnahme erfassen . . . . . . . . . . . . . . . . . . . . 108
6.22. Screenshot - My Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.23. Screenshot - My Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.1. Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
D.1. Primäre Persona: Heiner Rumpler . . . . . . . . . . . . . . . . . . . . . . . 126
D.2. Sekundäre Persona: Friedrich Kracher . . . . . . . . . . . . . . . . . . . . 128
F.1. Vollständiges Klassendiagramm Knowledge@Risk Prototyp . . . . . . . . . 137
viii

Tabellenverzeichnis
3.1. Wissensbasierte Klassifikation von unternehmensweiten Risiken nach [CC04] 27
3.2. Sachlich-Technisches Wissensrisiko: Wissenstransfer an die Konkurrenz . . 32
5.1. Generisches Wissensrisiko: Unfreiwillige Wissensdiffusion . . . . . . . . . . 69
5.2. Instanziiertes Wissensrisiko: Ungewollter Wissensabfluss . . . . . . . . . . 70
5.3. Generische Maßnahme: Verschlüsselungstechniken . . . . . . . . . . . . . . 71
5.4. Instanziierte Maßnahme: PGP im Projekt verwenden . . . . . . . . . . . . 72
6.1. Use Case 4: Erfassen einer Maßnahme für ein Wissensrisiko . . . . . . . . 85
E.1. Use Case 1 - Eröffnen eines neuen Projektes . . . . . . . . . . . . . . . . . 130
E.2. Use Case 2 - Eingabe von neuen Wissensrisiken . . . . . . . . . . . . . . . 131
E.3. Use Case 3 - Bewerten eines Wissensrisikos . . . . . . . . . . . . . . . . . 132
E.4. Use Case 4 - Erfassen einer Maßnahme für ein Wissensrisiko . . . . . . . . 133
E.5. Use Case 5 - Ansicht der persönlichen Wissensrisiken . . . . . . . . . . . . 134
E.6. Use Case 6 - Über die Veränderung eines Wissensrisikos berichten . . . . . 134
E.7. Use Case 7 - Ansicht aller Wissensrisiken . . . . . . . . . . . . . . . . . . . 135
E.8. Use Case 8 - Ansicht der TOP 10 Wissensrisiken . . . . . . . . . . . . . . 135
E.9. Use Case 9 - Suchen von Wissensrisiken . . . . . . . . . . . . . . . . . . . 136
E.10.Use Case 10 - Ansicht der persönlichen Aufgaben . . . . . . . . . . . . . . 136
ix

1. Einleitung
1.1. Relevanz des Themas
Aufgrund steigenden Wettbewerbs, neuen Gesetzen und Vorschriften, wie dem Sarbanes-
Oxley Act in den USA, Basel II in Europa oder dem Gesetz zur Kontrolle und Trans-
parenz im Unternehmensbereich (KonTraG) in Deutschland, gewinnt der Umgang mit
Risiken, die den Erfolg einer Geschäftstätigkeit bedrohen, immer mehr an Bedeutung.
Zusätzlich erfordern Faktoren, wie die Wachstumsbestrebungen der Unternehmen und
eine zunehmende Komplexität unternehmerischen Handels, eine Etablierung eines effizi-
enten Risikomanagements im Unternehmen.
Mit dem steigendem Interesse an einem effizienten unternehmensweiten Risikomanage-
ments wächst auch das Interesse an einem erfolgreichen Risikomanagement in Projekten.
Projektrisikomanagement ist Teil der operativen Ebene des unternehmensweiten Risi-
komanagements. Alle strukturierten Methoden des Projektmanagements beinhalten er-
folgreiches Risikomanagement als eine der Kernaufgaben. So widmet beispielsweise der
weltgrößte Projektmanagementverband, das Project Management Institute, im Project
Management Body of Knowledge [PMI04], dem Standardwerk für Projektmanagement,
ein ganzes Kapitel dem Thema Risikomanagement.
In Theorie und Praxis wird die Forderung, den Betrachtungsraum vom klassischen Risi-
komanagement auf andere, weiter reichende Risiken auszuweiten, immer stärker. Durch
die Ausweitung des Betrachtungsraumes wird eine qualitative Verbesserung des Risiko-
managements erreicht. Denn das Risikomanagement kann nur dann effizient wirken, wenn
die für ein Unternehmen tatsächlich erfolgskritischen Risiken betrachtet werden. In fast
allen Branchen ist die Wissensintensität von Geschäftstätigkeiten und -prozessen enorm
gestiegen und das Wissen der Mitarbeiter und generell das Wissen im Unternehmen
wurde zu einem der kritischen Erfolgsfaktoren.
1

1.2. Umfeld der Arbeit
Um den kritischen Erfolgsfaktor Wissen den notwendigen Stellenwert im Risikomana-
gement einzuräumen, forscht das Grazer Know-Center 1 , Österreichs Kompetenzzentrum
für Wissensmanagement, an einem Framework zur Integration von Wissensrisiken in be-
stehende Risikomanagementmodelle und -systeme. Im Rahmen des Projekts entsteht eine
Dissertation [Kol05] mit dem Ziel erfolgskritische Wissensrisiken im Unternehmen zu un-
tersuchen. Im Dissertationsvorhben soll eine Methode entwickelt und geprüft werden,
welche Wissensrisiken durch ein systematisches Vorgehen identifiziert, sie bewertet und
geeignete Steuerungsinstrumente auswählt. Die Methode wird von Koller mit Knowled-
ge@Risk Framework bezeichnet und soll insbesonders Unternehmen mit wissensintensiven
Geschäftsprozessen und -tätigkeiten bei einem erfolgreichen Risikomanagement unter den
heutigen wirtschaftlichen Rahmenbedingungen bestmöglich unterstützen.
1.3. Forschungsfrage
Der letzte Schritt des Frameworks, die Auswahl von geeigneten Steuerungsinstrumenten,
ist für ein effizientes Risikomanagement äußerst wichtig [Hil99] und zugleich das Thema
dieser Arbeit. Die Arbeit möchte Steuerungsinstrumente und -methoden für Wissensrisi-
ken sowohl aus dem Bereich des Risiko- als auch aus dem Wissensmanagements untersu-
chen und die Forschungsfrage Wie können Benutzer bei der Entwicklung von Steuerungs-
maßnahmen für Wissensrisiken unterstützt werden? beantworten.
1.4. Aufbau der Arbeit
Um diese Forschungsfrage im Laufe der Arbeit zu beantworten, wird zunächst eine theo-
retische Grundlage geschaffen. Kapitel 2 führt dazu in das klassische Risikomanagement
ein und schenkt dabei den unterschiedlichen Prozessen und Kategorien des Risikoma-
nagements besondere Beachtung. Anschließend beschäftigt sich Kapitel 3 mit der eigen-
ständigen Kategorie der Wissensrisiken. In diesem Kapitel wird eine neue, weiter rei-
chende Definition für den Begriff Wissensrisiko getroffen und zwischen wissensbasierten
und wissensgefährdenden Risiken unterschieden. Aufbauend auf dieser Definition wird
1 http://www.know-center.at/
2

ein Katalog an abstrahierten, generellen Wissensrisiken erarbeitet. Die Entwicklung von
passenden Steuerungsmaßnahmen ist Teil des Risikomanagementsprozesses und wird in
Kapitel 4 ausführlich beschrieben. Hierfür werden unterschiedliche Strategien und Steue-
rungsinstrumente bzw. -methoden untersucht und schließlich ein Katalog an abstrahier-
ten, generellen Steuerungsmaßnahmen dem Katalog an Wissensrisiken gegenübergestellt.
Basierend auf den theoretischen Ausführungen und den in den in den Kapiteln 3 und 4
entwickelten Katalogen an generischen Wissensrisiken und Steuerungsmaßnahmen wird
in Kapitel 5 das Risk Response Modell entwickelt. Das Modell verbindet die beiden
Kataloge mittels einer Logik und ermöglicht das Instanziieren spezifischer Risiken und
Maßnahmen. Das Instanziieren schafft eine Verbindung zwischen einem spezifischen und
einem dazu passenden generischen Risiko. Durch damit mögliche Vorschläge von geeig-
neten Maßnahmen zur Steuerung von spezifischen Wissensrisiken möchte das Modell den
Benutzer bei der Entwicklung von geeigneten Steuerungsmaßnahmen unterstützen und
somit eine Antwort auf die Forschungsfrage geben. Um das Risk Response Modell besser
anwenden zu können, wird in Kapitel 6 ein Software Prototyp anhand des Goal Oriented
Interaction Designs entworfen und die für die Implementierung notwendigen technischen
Entscheidungen und die Ergebnisse der Implementierung ausführlich beschrieben.
Abschließend werden die Ergebnisse der Arbeit in Kapitel 7 zusammengefasst und unter
dem Gesichtspunkt der Qualität der Antwort auf die Forschungsfrage bewertet.
In Abbildung 1.1 sehen sie eine Gegenüberstellung der einzelnen Kapitel zu den in die-
ser Arbeit behandelten Themenbereiche. Diese Grafik wird am Beginn jedes Kapitels
verwendet und erleichtert dem Leser die Orientierung beim Studium der Arbeit.
Abbildung 1.1.: Gegenüberstellung Themenbereiche - Kapitel der Arbeit
3

2. Risikomanagement
Dieses Kapitel behandelt das klassische Risiko-
management. Der Begriff des Risikos wird definiert
und sowohl unternehmensweites als auch projekt-
spezifisches Risikomanagement näher erläutert. Im
Speziellen wird hierbei auf die verwendeten Risiko-
managementprozesse und Risikokategorien geach-
tet. Außerdem wird der Zusammenhang zwischen
dem Risikomanagement im Unternehmen und im
Projekt hergestellt. Auf diesen Ausführungen bau-
en die weiteren Kapitel über Wissensrisiken und
deren Steuerungsmöglichkeiten auf. Diese Kapi-
tel werden hauptsächlich unter dem Aspekt des
Projektrisikomanagements betrachtet, da das in der Arbeit entwickelte Modell und der
Prototyp speziell auf Projekte zugeschnitten ist.
2.1. Begriffserklärung
2.1.1. Historische Betrachtung
Historisch betrachtet stammt der Begriff Risiko vom lateinischen Wort resceare ab. Das
Wort kann mit abtrennen ins Deutsche übersetzt werden. Das Webster Dictionary [o.V13]
vertritt die Meinung, dass das Wort Risiko ursprünglich von Seeleuten zur Beschreibung
einer Gefahr verwendet wurde. Erst im 17ten Jahrhundert wurden die fundamentalen
Konzepte des Risikos schrittweise entdeckt und die Begriffe Risiko und Wahrscheinlich-
keit gebräuchlich. Bernstein [Ber02] erklärt die späte Einführung der Begriffe in den
alltäglichen Sprachgebrauch damit, dass im Alten Griechenland als auch in den früheren
westlichen Kulturen Ereignisse als Naturereignisse, die mit keiner Unsicherheit behaftet
4

und von den Göttern vorbestimmt sind, betrachtet wurden. Dass diese Ereignisse mit ei-
nem gewissen Risiko behaftet und so einer gewissen Wahrscheinlichkeit eintreten wurde
erst später erkannt, und floss dann in den alltäglichen Sprachgebrauch ein.
2.1.2. Was ist Risiko?
Wie Hillson [Hil02c] in What is risk? Towards a common definiton feststellt, existieren
im Fachgebiet des Risikomanagements zwei konträre Definitionen von Risiko. Einerseits
sehen Fachleute in Risiken den mit Unsicherheit behafteten Eintritt eines negativen Ereig-
nisses und andererseits den Überbegriff für mögliche positive als auch negative Ereignisse.
Hillson schlägt folgende zwei Möglichkeiten der Begriffsdefinition vor und merkt an, dass
sich die Risikomanagementgemeinde in die Richtung der zweiten Definition bewegt.
1. Unsicherheit ist ein Überbegriff für
• Risiko - Eine Unsicherheit mit negativen Auswirkungen
• Chance - Eine Unsicherheit mit positiven Auswirkungen
2. Risiko ist Überbegriff für
• Chance - Ein Risiko mit positiven Auswirkungen
• Gefährdung - Ein Risiko mit negativen Auswirkungen
Erste Sichtweise
Im Alltag wird ein Risiko vor allem als Gefahr gesehen. Eine Straßenbefragung zum
Begriff Risiko würde diese Meinung bestätigen (vgl. [Hil02c]) und auch das Merriam-
Webster Dictionary [o.V96] schließt sich dieser Sichtweise mit der Erläuterung des Begriffs
Risiko als possibility of loss or injury an.
Für einige nationale Standards im Risikomanagement ist der Ausdruck Risiko zur Gänze
negativ. Beispiele dafür sind der Norwegische Standard NS5814:1981, der Britische BS
8444-3:1996 und der Kanadische CAN/CSA-Q850-97:1997.
Wie man in Abbildung 2.1 erkennen kann, schließt sich Kontio [Kon01] in seiner Defini-
tion von Risiko ebenfalls diesen Standards an.
5

Offene Sichtweise
Abbildung 2.1.: Begriff Risiko nach [Kon01], Seite 5
Die UK Association for Project Management (APM) [APM97] definiert Risiko mit an
uncertain event or set of circumstances which, should it occur, will have an effect on
achievement of objectives und lässt offen, ob die Auswirkungen positiv oder negativ
sind. Der britische Standard BS6079-3:2000 und der australische AS/NZS 4360:1999
beinhalten ebenfalls eine offene Definition des Begriffs Risiko.
Zweite Sichtweise
Andere Richtlinien gehen sogar noch einen Schritt weiter und führen explizit an, dass sich
ein Risiko auch in einer positiven Art und Weise realisieren kann. Beispielsweise definiert
das Institute of Risk Management (IRM) gemeinsam mit der Association of Insurance
und Risk Managers (AIRMIC) und dem National Forum for Risk Management in the
Public Sector (ALARM) Risiko folgendermaßen:
Risk can be defined as the combination of the probability of an event and
its consequences [...] In all types of undertaking, there is the potential for
events and consequences that constitute opportunities for benefit (upside) or
threats to success (downside) [IRM02]
Diese Definition wird ebenfalls von der Federation of European Risk Management As-
sociation (FERMA) in ihrem Risikomanagement Standard [FER02] übernommen. Das
6

Project Management Institute (PMI) [PMI04] schließt sich mit der Definition an uncer-
tain event or condition that, if it occurs, has a positive or negative effect on a project
objective den anderen Institutionen an.
Die Risikomanagementprozesse für die beiden Sichtweisen sind sehr ähnlich. Möchte ein
Unternehmen nun ein Risikomanagement nach der zweiten Sichtweise einführen, so ge-
nügt es, den bereits bestehenden und für Gefährdungen entwickelten Risikomanagement-
prozess für Risiken mit positiven Auswirkungen (vgl. [Hil02c]) zu erweitern. Es ist nicht
notwendig, einen neuen Risikomanagementprozess ins Unternehmen einzuführen.
2.2. Risikomanagement
2.2.1. Definition
Risikomanagement ist eine sehr breite Disziplin und unterschiedlichste Gebiete und Men-
schen verschiedenster Professionen beschäftigen sich damit. Wie sehr sich die Sichtweisen
auf den Begriff Risikomanagement unterscheiden, verdeutlicht das Zitat von Kloman.
What is risk management? To many social analysts, politicians and acade-
mics it is the management of environmental and nuclear risks, those technology-
generated macro-risks that appear to threaten our existence. To bankers and
financial officers it is the sophisticated use of such techniques as currency
hedging and interest rate swaps. To insurance buyers and sellers it is coor-
dination of insurable risks and the reduction of insurance costs. To hospital
administrators it may mean ’quality assurance.’ To safety professionals it is
reducing accidents and injuries. [Klo90]
Diese Arbeit basiert auf zwei Bereichen des Risikomanagements, namentlich dem un-
ternehmensweiten Risikomanagement und dem diesen unterzuordnenden Projektrisiko-
management. Das unternehmensweite Risikomanagement ist für die vorliegende Arbeit
deswegen entscheidend, weil die Literatur über Wissensrisiken (siehe Kapitel 3) diese
aus einer unternehmensweiten Perspektive betrachtet. Das Projektrisikomanagement, ei-
ne Teildisziplin des unternehmensweiten Risikomanagements, ist von Bedeutung, da in
diesem Gebiet schon viele Werkzeuge und Verfahren zum Umgang mit Risiken entwickelt
wurden.
7

In dieser Arbeit werden ein Modell sowie ein Pro-
totyp entwickelt, welche speziell auf das Projek-
trisikomanagement zugeschnitten sind. Trotzdem
wird in den theoretischen Ausführungen auf Pro-
zesse, Werkzeuge und Erkenntnisse des unterneh-
mensweiten Risikomanagements näher einzugehen
sein, da sie ebenfalls im Projektrisikomanagement
angewendet werden können.
Im Rahmen des Risikomanagements für Unterneh-
men und Projekte existieren anerkannte Standards
und Richtlinien. Da die weiteren Ausführungen auf
diese Dokumente zurückgreifen, werden sie im Anschluss vorgestellt.
2.2.2. Unternehmensweites Risikomanagement
Durch den ständig steigenden Wettbewerbsdruck sowie neue Gesetze und Vorschriften,
wie dem Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) in
Deutschland oder dem Sarbanes-Oxley Act in den USA, gewinnt der Umgang mit Ri-
siken, die den Erfolg ihrer Geschäftstätigkeit bedrohen können, für Unternehmen an
Bedeutung. Das Committee of Sponsoring Organizations of the Treadway Commission
(COSO) definiert unternehmensweites Risikomanagement wie folgt:
Enterprise risk management is a process, effected by an entity’s board of
directors, management and other personnel, applied in strategy setting and
across the enterprise, designed to identify potential events that may affect the
entity, and manage risk to be within its risk appetite, to provide reasonable
assurance regarding the achievement of entity objectives. [COS04]
A Risk Management Standard
Das Institute of Risk Management (IRM) wurde 1986 aufgrund der wachsenden Nach-
frage nach Kursen über Risikomanagement gegründet. Während der bisherigen 19 Jahre
gelang es dem IRM eine treibende Kraft der Risikomanagementausbildung mit ungefähr
8

2000 Mitgliedern in 50 Ländern zu werden. 1
Wie schon in unter 2.1.2 angeführt publiziert das Institue of Risk Management gemein-
sam mit den beiden anderen großen Risikomanagement Organisationen Großbritanniens,
der Association of Insurance und Risk Managers (AIRMIC) und dem National Forum
for Risk Management in the Public Sector (ALARM), einen Risikomanagementstandard
[IRM02].
COSO Enterprise Risk Management
Das Committee of Sponsoring Organizations of the Treadway Commission (COSO) wur-
de 1985 gegründet um die National Commission on Fraudulent Financial Reporting, eine
unabhängige private Initiative, welche die Ursachen für betrügerische Finanzberichter-
stattung untersucht und Vorschläge für Aktiengesellschaften und deren unabhängige Bi-
lanzprüfer entwickelt, zu unterstützen. Die Organisation wird von den fünf führenden Bi-
lanzbuchhaltergesellschaften, wie unter anderem der American Accounting Association,
gefördert und besteht aus Vertretern der Privatwirtschaft, des öffentlichen Berichtswe-
sens, der Investmentgesellschaften und der New York Stock Exchange 2 .
Die von COSO publizierte Richtlinie Enterprise Risk Management - Integrated Frame-
work [COS04] diskutiert die Schlüsselprinzipien und Konzepte des unternehmensweiten
Risikomanagements und bietet klare Empfehlungen und Beratung. Das Dokument wur-
de von PricewaterhouseCoopers unter Anleitung eines Komitees, zusammengesetzt aus
Vertretern der fünf unterstützenden Organisationen verfasst.
2.2.3. Projektrisikomanagement
Das Projektrisikomanagement ist Teil der operativen Ebene des unternehmensweiten Ri-
sikomanagements. Aufgrund der speziellen Charakteristika von Softwareprojekten, wie
etwa der großen Unsicherheit, mit der ihr Ausgang behaftet ist, wurde Projektrisiko-
management zunächst hauptsächlich in diesen Projekten verwendet. Dabei wurden viele
Verfahren und Werkzeuge, wie die Risk Taxonomy des Software Engineering Institu-
tes [CKM + 93], entwickelt, die nun auch in anderen Disziplinen des Risikomanagements
Verwendung finden. Isoliert vom restlichen Unternehmen betrachtet, führt Projektrisiko-
1 http://www.theirm.org/aboutheirm/ABhistory.htm [14.04.2005]
2 http://www.coso.org/ [14.04.2005]
9

management selten zum Erfolg. Das Unternehmen muss eine unterstützende Umgebung
für das Projektrisikomanagement bieten (vgl. [Lor02]) und Risiken auch über der Pro-
jektebene verwalten und steuern. Risiken beschreiben die Randbedingungen, in denen
ein Unternehmen handelt. Deswegen ist es ebenfalls ein Bestandteil der Unternehmens-
strategie. Die RISK Special Interest Group des Project Management Institutes definiert
Projektrisikomanagement so:
The process associated with identifying, analyzing, planning, tracking and
controlling project risks; The life cycle process which includes identification,
assessment and analysis, but adds the identification and implementation of
proactive actions which are intended to mitigate risks and enhance oppor-
tunities. The management process also includes monitoring the efficacy of
planned actions and the continuous update of all assessments as they change
due to the implementation of actions and/or changes in the project environ-
ment with the passage of time. [RISK Special Interest Group] 3
Risikomanagement spielt eine kritische Rolle im erfolgreichen Projektmanagement und
das Interesse an einer erfolgreichen Umsetzung in der Praxis wächst. Alle strukturierten
Methoden des Projektmanagements beinhalten Risikomanagement als eine ihrer Kern-
disziplinen, und viele von ihnen bieten Richtlinien mit einem best practice Prozess (vgl.
[Hil02b]) an.
Die im Risikomanagement verwendeten Standards und Richtlinien umfassen internatio-
nale sowie nationale Standards und Richtlinien von professionellen Institutionen. Zu den
internationalen Standards zählen ISO 10006:1997, IEC 62198:2001 sowie ISO DGuide
73:2001. Standards auf nationaler Ebene sind der englische BS 8444-3:1996, der kanadi-
sche CAN/CSA-Q850-97:1997 und der australische AS/NZS 4360:1999. Zu den Institu-
tionen, welche sich mit dem Projektmanagement auseinander setzen, zählen das Project
Management Institute (PMI) und die UK Association for Project Management (APM).
Im Folgenden werden drei Richtlinien genauer beschrieben sowie Gemeinsamkeiten und
Unterschiede aufgezeigt. Diese Dokumente wurden in Hinblick auf ihre geographische
Herkunft und ihre Bedeutung ausgewählt (siehe Abbildung 2.2).
3 http://www.risksig.com/resource/lexicon.htm#R [14.04.2005]
10

Abbildung 2.2.: Geographische Verteilung der Standards und Richtlinien
1. Richtlinie: Project Management Body of Knowledge (PMBoK)
Das Project Management Institute ist mit seinen über 150.000 Mitgliedern in über 150
Ländern 4 die führende Institution im Projektmanagement. Sie beheimatet 33 Specific
Interest Groups (SIG) unter denen sich auch die SIG Risk Management befindet.
Im Project Management Body of Knowledge [PMI04], welcher im Jahr 2002 zum dritten
Mal publiziert wurde, ist das Kapitel 11 dem Thema Risikomanagement gewidmet. Dar-
in werden Prozesse und Methoden des Risikomanagements und die hierfür notwendigen
Managementstrukturen beschrieben. Dieser Leitfaden umfasst sowohl die Charakterisie-
rung eines Risikos als individuelle Aufgabe als auch als Aufgabe ganzer Projektteams und
verweist unter anderem auf Entscheidungsbäume, Flussdiagramme und Monte-Carlo Si-
mulation als Werkzeuge für erfolgreiches Risikomanagement.
2. Richtlinie: Project Risk Analysis and Management (PRAM) Guide
Die Association for Project Management ist die größte unabhängige Organisation im
Bereich des Projektmanagements in Europa. Sie führt über 13.500 Personen und 240
Gesellschaften als Mitglieder 5 . Ihre Ziele sind die Entwicklung und Verbreitung von Pro-
4 http://www.pmi.org/info/default.asp [07.04.2005]
5 http://www.apm.org.uk/apm/Default.htm [07.04.2005]
11

jektmanagement in allen Sektoren der Industrie und darüber hinaus. Der von ihr in der
zweiten Ausgabe publizierte Project Risk Analysis and Management Guide beschreibt
einen eigenständigen Projektrisikoprozess mit den dafür notwendigen Schritten und Me-
thoden.
Das Konzept entspricht dem des PMBoK, allerdings werden die Managementstrukturen
formaler behandelt.
3. Richtlinie: AS/NZS 4360:1999
Im Gegensatz zu den beiden oben beschriebenen und von professionellen Institutionen
publizierten Standards ist der AS/NZS 4360:1999 ein nationaler Standard, der von ei-
ner staatlichen Institution verfasst wurde. Er beinhaltet einen generischen Ansatz zum
Risikomanagement und schlägt geeignete Prozesse, aber keine Methoden zur Umsetzung
vor.
Dieser Standard wird hauptsächlich zur qualitativen Bewertung angewendet, aber zu-
sätzlich kann auch eine quantitative Bewertung mittels Eintrittswahrscheinlichkeit und
Auswirkung durchgeführt werden. Der Prozess des Risikomanagements baut auf einem
Risikoregister 6 auf und lässt sich leicht der Größe des Projektes anpassen.
2.3. Risikomanagementprozesse
Im vorigen Abschnitt 2.2 wurden Standards und Richtlinien aus dem unternehmensweiten
und aus dem Projektrisikomanagement vorgestellt. In diesem Kapitel werden nun die
einzelnen Risikomanagement Prozesse dieser Dokumente präsentiert und in allgemeine
Teilprozesse zusammengefasst, welche im Anschluss genauer beschrieben werden.
Wie man in Abbildung 2.3 erkennen kann, ähneln sich die Prozesse des unternehmens-
weiten sowie des Projektrisikomanagement [BDR01]. Man kann sie in folgende fünf all-
gemeine Prozessschritte unterteilen:
6 A log of risks of all kinds that threaten an organisation’s success in achieving its declared
aims and objectives, Risk Register Working Group (RRWG), Juli 2002 [18.04.2005]:
http://www.dhsspsni.gov.uk/hss/governance/documents/guide_populate_riskregister.pdf
12

1. Planungsphase
2. Risikoidentifikation
3. Risikobewertung
4. Maßnahmenplanung
5. Monitoring
Abbildung 2.3.: Überblick Risikomanagementprozesse
Bei der nun folgenden detaillierten Beschreibung der einzelnen Prozessschritte werden
diese zuerst aus einer unternehmensweiten Perspektive und anschließend aus einer pro-
jektspezifischen Sichtweise betrachtet.
2.3.1. Planungsphase
Die Identifikation von Risiken wird oft als Kernstück von Risikomanagement gesehen.
Abbildung 2.3 zeigt allerdings, dass alle untersuchten Risikomanagementstandards und
13

Richtlinien nicht mit diesem Arbeitsschritt beginnen. Um ein Risiko identifizieren zu
können, muss man zunächst den Kontext für das Risikomanagement festlegen.
Der australische Standard AS/NZS 4360:1999 [Bro99] teilt diesen Schritt in zwei Teile,
den beschreibenden und kreativen Teil, auf. Der beschreibende Teil umfasst die Definition
der Unternehmensziele und der kreative Teil beschreibt die Zerlegung des Unternehmens
in Schlüsselelemente, die bei der Risikoidentifizierung gezielt betrachtet werden.
COSO [COS04] betitelt diesen Arbeitsschritt mit Objective Settings und fügt bei, dass die
entwickelten Ziele zum Unternehmen passen und dem gewählten Risikoprofil entsprechen
sollen.
Im Projektrisikomanagement wird in dieser Phase nicht das Unternehmen, sondern das
Projekt durchleuchtet. So merkt Chapman [Cha97] an, dass in diesem Arbeitsschritt
unter anderem die Projektziele, der Umfang des Projektes und die Strategie klar und
eindeutig formuliert werden müssen.
2.3.2. Risikoidentifikation
Der COSO Standard [COS04] unterscheidet zwischen Risiken und Chancen und fasst
beide unter dem Begriff Ereignis zusammen. Solche internen bzw. externen Ereignisse,
welche das Erreichen von Unternehmenszielen beeinflussen, müssen in diesem Prozess-
schritt identifiziert werden.
Die Identifikation von Risiken eines Unternehmens benötigt ein umfangreiches Wissen
über die Organisation. Laut dem Risk Management Standard [IRM02] soll die Identifi-
kation von Risiken methodisch abgearbeitet werden, um sicherzustellen, dass alle Akti-
vitäten eines Unternehmens betrachtet und die darin enthaltenen Risiken dokumentiert
wurden. Die Aktivitäten lassen sich in die folgenden Bereiche aufteilen:
• Strategie
• Operativ
• Finanz
• Wissensmanagement
• Sicherheit
14

Auch im Projektrisikomanagement wird zwischen internen und externen Risiken unter-
schieden. Der Project Management Body of Knowledge [PMI04] definiert interne Risiken
als jene, die vom Projektteam kontrolliert bzw. beeinflusst werden können, wie die Auf-
gabenverteilung oder Kostenschätzungen. Externe Risiken sind nicht vom Projektteam
beeinflussbar, zu ihnen zählen Marktbewegungen und Regierungsentscheidungen.
Chapman [Cha97] führt die Identifikation von Risiken in zwei Schritten durch. Zunächst
werden Risiken mithilfe von Werkzeugen, wie Brainstorming oder Interviews, gesucht.
Und im zweiten Schritt werden die gefundenen Risiken klassifiziert, um eine passende
Basis zur Entwicklung von Maßnahmen zu schaffen.
Der australische Standard AS/NZS 4360:1999 [Bro99] beschreibt die Werkzeuge zur
Identifikation von Risiken genauer. Die beschreibende Methode greift auf Checklisten
zurück, welche sich einfach verwenden lassen und schnell ein Ergebnis liefern; aber es
lassen sich damit nur Standardrisiken identifizieren. Um Risiken zu identifizieren, welche
noch nicht in einer von Experten erstellten Liste dokumentiert sind, muss ein kreativer
Prozess durchgeführt werden. Hierzu kann ein Brainstorming in einem Gruppenseminar
oder ein strukturierter Workshop, welcher aus Interviews, Fragebögen und schriftlichen
Umfragen besteht, angewandt werden.
2.3.3. Risikobewertung
Der nächste Schritt im Risikomanagementprozess ist die Bewertung der identifizierten
Risiken. COSO [COS04] sieht darin die Analyse der Risiken bezüglich deren Eintritts-
wahrscheinlichkeit und Auswirkungen. Diese Analyse dient als Basis für die Entwicklung
von Maßnahmen.
Das Institute of Riskmanagement [IRM02] fügt an, dass mit dieser Bewertung die ge-
sammelten Risiken gereiht werden und dadurch die Schlüsselrisiken einer genaueren Un-
tersuchung unterzogen werden können. Nach dieser detaillierteren Untersuchung sollen
die analysierten Risiken den Unternehmenskriterien, wie zugehörigen Kosten und Nut-
zen, gesetzlichen Bestimmungen oder den Ansprüchen der Stakeholder gegenübergestellt
werden.
Chapman [Cha97] begründet die Wichtigkeit der Reihung von Risiken damit, dass hiermit
nicht zu viel Zeit in die Analyse und Behandlung von geringfügigen Risiken investiert
wird. Die so gewonnene Zeit kann für die großen Risiken, welche eine komplexe Maß-
15

nahmenplanung erfordern, aufgewendet werden. Im Gegenzug zum unternehmensweiten
Management müssen die Eintrittswahrscheinlichkeit und die Auswirkungen im Projekt-
management in Hinblick auf Projektziele, wie Projektkosten und Zeitplan, geschätzt wer-
den.
Abbildung 2.4.: AS/NZS 4360:1999 [Bro99] Risikomatrix
Der australische Standard AS/NZS 4360:1999 [Bro99] schlägt vor, dass bei einfachen
Risiken, welche durch die Unsicherheit eines Ereignisses ausgedrückt werden können,
eine qualitative Bewertung von Eintrittswahrscheinlichkeit und Auswirkung sinnvoll ist.
Diese Bewertung soll mit einer Matrix (siehe Abbildung 2.4), welche allen möglichen
Kombination dieser Bewertungen eine Bedeutung zuweist, gekoppelt werden.
Für komplexere Risiken, welche beispielsweise mehrere Ereignisse und Einflüsse bein-
haltet, müssen umfangreichere Verfahren angewandt werden. Hierfür schlägt das Project
Management Institue [PMI04] unter anderem Simulation, Entscheidungsbäume und Ex-
pertenwissen vor. Die bekannteste Simulation ist die von Projektzeitplänen. Sie baut auf
dem Projektplan auf und wird meistens mit einer Monte Carlo 7 Simulation durchgeführt.
Ein Entscheidungsbaum beschreibt die Schlüsselbeziehungen zwischen Entscheidungen
und den damit verbundenen Wahrscheinlichkeit.
7 Verfahren der stochastischen Simulation zur näherungsweisen Bestimmung von mathematischen Größen,
die abhängig vom Zufall sind. Die Monte Carlo Methode basiert im Vergleich zur historischen
Simulation nicht auf Vergangenheitswerten, sondern auf einer Simulation der Risikoparameter.
[19.04.2005] http://risknet.risktech.de/Glossar.62.0.html?&tx_simpleglossar_pi1[headerList]
16

2.3.4. Maßnahmenplanung
Dieser Schritt im Risikomanagementprozess beinhaltet die Entwicklung von Maßnah-
men, welche zur Risikotoleranz des Unternehmens passen. Hierfür stehen die Strategien
(vgl. [COS04]) Vermeidung, Verminderung, Transfer und die Übernahme von Risiken zur
Verfügung.
Nachdem eine Maßnahme entwickelt wurde, sieht das Institute of Risk Management
[IRM02] vor, dass der mögliche wirtschaftliche Effekt dieser Maßnahme und die Kos-
ten ihrer Installation und Durchführung quantifiziert werden. Anhand dieser beiden Er-
gebnisse lässt sich feststellen, ob die Umsetzung einer Maßnahme wirtschaftlich sinnvoll
ist.
Chapman [Cha97] unterscheidet zwischen proaktiven und reaktiven Maßnahmen. Proak-
tive Maßnahmen werden vor dem Eintritt eines Risikos angewandt, reaktive hingegen
erst, wenn sich ein Risiko zu einem Problem realisiert. Die Beschreibung von Maßnahmen
soll Elemente wie Priorität, verantwortliche Person bzw. Abteilung, benötigte Ressourcen
oder Meilensteine beinhalten.
Das Ergebnis dieses Arbeitsschrittes (vgl. [PMI04]) sollen ein Risikomanagementplan,
Informationen für andere Prozesse, Notfallpläne, die Bildung von Rücklagen und ver-
tragliche Vereinbarungen sein. Der Risikomanagementplan soll Vorgänge für die Hand-
habung aller Risiken beschreiben und die Verantwortung dafür bestimmten Personen
bzw. Abteilungen zuweisen.
2.3.5. Monitoring
Effektives Risikomanagement benötigt ein Berichtswesen und eine Überprüfungsstruktur
(vgl. [IRM02]) um sicherzustellen, dass Risiken effizient identifiziert und bewertet wer-
den. Außerdem sorgt dies für die Entwicklung von präsenten Maßnahmen, die immer
zur Steuerung der Aktivitäten bereit stehen. Änderungen im Unternehmen und dessen
Umfeld müssen identifiziert und das Risikomanagementsystem entsprechend angepasst
werden.
Chapman [Cha97] bezeichnet diesen Prozess als Manage Phase und für ihn beginnt sie,
sobald ein Projekt ausgeführt wird. Es müssen der aktuelle Fortschritt und die entwi-
ckelten Risikomanagementpläne auf Änderungen überwacht und detailliertere Pläne für
17

die unmittelbare Zukunft entworfen werden.
2.4. Risikokategorien
Risikokategorien dienen in erster Linie zur Unterstützung bei der Identifikation von Ri-
siken (vgl. [Hil02a]). Sie helfen dem Verantwortlichen für das Risikomanagement einen
Überblick über das Unternehmen bzw. Projekt zu bekommen und die Bereiche, in denen
Risiken auftreten können, klar vor Augen zu haben. Anschließend wird auf die Risiko-
kategorien eingegangen, um einen Überblick über die verschiedensten Risiken, die im
Projekt bzw. Unternehmen auftreten können, zu bekommen, um später in Kapitel 3
Wissensrisiken diesen Kategorien zuzuordnen.
2.4.1. Unternehmensweite Kategorien
COSO Enterprise Risk Management
Nach COSO [COS04] soll ein Unternehmen im Kontext seiner Unternehmensvision stra-
tegische Ziele und eine Unternehmensstrategie entwickeln. Hierzu werden die Ziele und
die damit verbundenen Risiken in vier Bereiche kategorisiert.
• Strategic - mit der Unternehmensvision verbundene Ziele
• Operations - effektiver und effizienter Einsatz von Unternehmensressourcen
• Reporting - Zuverlässigkeit des Berichtswesens
• Compliance - Einhalten von Gesetzen und Vorschriften
Die Kategorisierung ermöglicht einen gezielten Fokus auf diese vier unterschiedlichen
Aspekte des unternehmensweiten Risikomanagements und ermöglicht es, eine Differen-
zierung zwischen den Erwartungen der einzelnen Kategorien zu treffen. Da sich diese
Kategorien überschneiden, kann ein spezifisches Ziel mehr als einer Kategorie zugeordnet
werden.
18

A Risk Management Standard
Der Risikomanagementstandard des Institute of Risk Management [IRM02] unterschei-
det zwischen internen und externen, auf ein Unternehmen einwirkende, Faktoren. Die
Abbildung2.5 zeigt, dass Risiken sowohl externe als auch interne Treiber besitzen und
somit beiden Bereichen angehören können. Sie lassen sich aber weiter in Kategorien wie
strategische, finanzielle, operationale oder zufällige Risiken zusammenfassen.
Abbildung 2.5.: Beispiele für Treiber von Schlüsselrisiken nach [IRM02]
19

2.4.2. Projektbezogene Kategorien
Das Projektrisikomanagement ist eine Teildisziplin des unternehmensweiten Risikomana-
gements (vgl. Kapitel 2.2) und so sind auch die Kategorien des Projektrisikomanagements
Teile des unternehmensweiten. Sie lassen sich unter die Kategorie der operativen Risiken
eingliedern.
Universal Risk Areas
Die Risk Special Interest Group (SIG) des Project Management Institutes entwickelte
gemeinsam mit der Risk Management Working Group (RMWG) des International Coun-
cil on Systems Engineering (INCOSE) eine Liste und Definitionen von Universal Risk
Areas [HH02]. Diese allgemeinen Risikobereiche sollen auf jedes Projekt, sei es aus dem
industriellen, staatlichen oder wirtschaftlichen Bereich, anwendbar sein. Die Liste dieser
Risiken ist illustrativ und dient als Grundlage und Hilfe für den Risikoidentifikations-
prozess. Es ist keine verpflichtende und allumfassende Liste, die jedes Projekt zur Gänze
abdeckt.
Abbildung 2.6 zeigt die von der Risk SIG definierten Risikobereiche. Im Folgenden wird
die erste Ebene dieser Bereiche kurz erläutert:
1. Management Risk Area - Die Risiken aus diesem Bereich beschreiben die Organisa-
tion, in der das Projekt durchgeführt wird, unter dem Aspekt von Projektmanagement,
Systemmanagement und Organisationsmanagement. Die Teilbereiche beinhalten unter
anderem die finanzielle Lage des Unternehmens, die Art des Managements und der Kom-
munikation sowie die Unternehmenskultur.
2. External Risk Area - Dieser Risikobereich liegt außerhalb der Kontrollmöglichkeit
des Unternehmens. Er besteht aus den Teilbereichen Verhalten von Außenstehenden (wie
Kunden, anderen Stakeholdern, Lieferanten usw.), klimatische oder demografische Ver-
änderungen und wirtschaftliches Wachstum.
3. Technology Risk Area - Die Risiken aus diesem Bereich beruhen auf den im Projekt,
Produkt, System oder in der Analyse verwendeten Technologie oder Prozessen. Techno-
20

Abbildung 2.6.: Universal Risk Areas nach [HH02]
logische Risiken enthalten die Ressourcen und die unterstützenden Technologien und
Prozesse der Entwicklungs- und betrieblichen Umgebung.
RAMP
Der von dem Departement of Commerce des Bundesstaates North Carolina US entwi-
ckelte Risk Assessment and Management Process (RAMP) [SNC98] ist eine Risikoma-
nagementmethode zur Unterstützung von Softwareentwicklung. Das Handelsministerium
schlägt folgende Risikokategorien als allgemeine potentielle Risikobereiche vor:
• Financial
• Resource
• Schedule
• Technical
21

• Management
• Communication
• Operational
• Political
• Organizational
2.5. Zusammenfassung
Es existieren mehrere Sichtweisen zur Definition des Begriffs Risiko und Risiko als Über-
begriff für Chance - Risiko mit positiven Auswirkungen, und Gefährdung - Risiko mit
negativen Auswirkungen, wird von der Fachwelt immer mehr und mehr anerkannt und
in Standards und Richtlinien zum Risikomanagement eingeführt.
Das Projektrisikomanagement ist eine Teildisziplin des unternehmensweiten Risikoma-
nagements und muss immer in einen unternehmensweiten Kontext gestellt werden, um
sinnvoll zu sein. Die Prozesse der beiden Disziplinen sind sich sehr ähnlich und lassen sich
in die allgemeinen Prozessschritte Planungsphase, Risikoidentifikation, Risikobewertung,
Maßnahmenplanung und Monitoring unterteilen. Der Maßnahmenplanung fällt in jedem
Standard oder jeder Richtlinie ein eigener Arbeitsschritt zu.
Die Kategorien des unternehmensweiten und des Projektrisikomanagements schaffen
einen guten Überblick über die Bereiche im Unternehmen bzw. Projekt, in denen Risiken
auftreten können. Wissensrisiken werden in keinem Standard und in keiner Richtlinie als
eigene Risikokategorie angeführt. Es ist dennoch wichtig die einzelnen Kategorien hier
aufzulisten, um in Kapitel 3 zu sehen, wie Wissensrisiken ins Projekt und Unternehmen
passen.
22

3. Wissen und Risiko
Im Jahr 2004 führten Casselman und Coleman
[CC04] eine Stichwortsuche in den Titeln und
Kurzfassungen von wissenschaftlichen Veröffentli-
chungen in den fünf bedeutendsten Management
Journals (nach dem ISI Journal Citations Index
Ranking) durch. Für den Zeitraum ab 1995 fanden
sie 208 Artikel, welche den Begriff Risiko und 234
welche den Begriff Wissen enthielten. Beide Be-
griffe gemeinsam wurden allerdings nur in fünf Ar-
tikeln verwendet, wobei keiner dieser Artikel eine
aussagekräftige Erklärung über die Verknüpfung
der Konzepte von Risiko und Wissen bietet.
Ausgehend vom, im vorigen Kapitel ausführlich beschriebenen, traditionellen Risikoma-
nagement beginnt dieses Kapitel mit der Herstellung eines Zusammenhanges zwischen
den Konzepten von Risiko und Wissen. Hierfür muss zunächst der Begriff Wissen erklärt
werden. Nach einer Herstellung eines allgemeinen Zusammenhangs zwischen den beiden
Konzepten wird im Speziellen auf wissensgefährdende und wissensbasierte Risiken ein-
gegangen. Diese sind die Grundlage für den Wissensrisikobegriff dieser Arbeit. Darauf
aufbauend wird erklärt, dass sich Wissensrisiken nicht in bestehende Risikokategorien
(vgl. Kapitel 2.4) einordnen lassen sondern einer expliziten Betrachtung bedürfen. Ab-
schließend wird ein generischer Katalog an Wissensrisiken entworfen, welcher gemeinsam
mit einem generischen Katalog an passenden Steuerungsmaßnahmen (vgl. Kapitel 4.5)
die Grundlage für das im Rahmen dieser Arbeit entwickelte Modell zur Unterstützung
der Entwicklung von passenden Steuerungsmaßnahmen für Wissensrisiken ist.
23

3.1. Begriff Wissen
In Kapitel 2.1.2 wurde bereits der Begriff Risiko genauer betrachtet und für diese Arbeit
definiert. Um nun eine Verknüpfung zwischen den beiden Konzepten Risiko und Wissen
herstellen zu können, ist zunächst eine Einführung in den Begriff Wissen notwendig.
Wissen wird in den unterschiedlichsten, wissenschaftlichen Disziplinen anders betrachtet.
So zahlreich diese Betrachtungen sind, so sind es auch die Definitionen für den Begriff
Wissen. In dieser Arbeit ist es vor allem wichtig, eine breit akzeptierte Definition zu
finden und sie dieser Arbeit zu Grunde zu legen.
In der Literatur findet sich sehr oft ein hierarchisches Konzept der Begriffe Daten, Infor-
mation und Wissen. Diese Hierarchie besteht einerseits im zeitlichen Sinn (Information
entsteht aus Daten, Wissen entsteht aus Information) und anderseits impliziert es auch
eine Wertehierarchie (Wissen ist höherwertig als Information, Information ist höherwer-
tig als Daten). Beispielsweise verwenden Davenport und Prusak in ihrem Standardwerk
Working Knowledge dieses hierarchische Konzept (siehe Abbildung 3.1).
Abbildung 3.1.: Hierarchisches Konzept für Wissen nach [DP98]
Die unterste Ebene stellen Daten, welche eine Ansammlung von diskreten, objektiven
Fakten über Ereignisse sind, dar. Im Kontext von Projekten werden Daten am sinnvolls-
ten als strukturierte Aufzeichnungen von Tätigkeiten bezeichnet.
Verschiedenste Prozesse werden unterschieden, durch die man Daten in Informationen
umwandelt:
• Kontextualisierung
• Kategorisierung
24

• Berechnung
• Korrektur
• Komprimierung
Information lässt sich als Nachricht, meistens in Form eines Dokumentes oder einer hör-
baren oder sichtbaren Kommunikation, beschreiben. Wie jede Nachricht verfügt auch
diese über einen Sender und einen Empfänger. Information bedeutet eine Veränderung
in der Sichtweise des Empfängers. Sie hat Einfluss auf dessen Bewertung und Verhalten.
Bei der Generierung von Wissen aus Information steht der Mensch im Mittelpunkt und
es werden folgende Prozesse identifiziert:
• Vergleich der Information in verschiedenen Situationen
• Abschätzung der Konsequenzen der Information auf Entscheidungen und Handlun-
gen
• Identifizierung von Beziehungen zwischen verschiedenen Informationen
• Konversation, Einholen von anderen Meinungen über eine gegebene Information
Aus diesem hierarchischen Konzept für Daten, Information und Wissen folgt folgende
Definition für den Begriff Wissen von Davenport und Prusak:
Knowledge is a fluid mix of framed experience, values, contextual information,
and expert insight that provide a framework for evaluating and incorporating
new experiences and information. It originates and is applied in the minds of
knowers. In organizations, it often becomes embeded not only in documents
or repositories but also in organizational routines, processes, practices, and
norms. [DP98]
Im deutschsprachigen Standardwerk Wissen managen von Gilbert Probst, Steffen Raub
und Kai Romhardt wird der Begriff Wissen noch stärker im Kontext von Personen so
definiert:
25

Wissen bezeichnet die Gesamtheit der Kenntnisse und Fähigkeiten, die In-
dividuen zur Lösung von Problemen einsetzen. Dies umfasst sowohl theo-
retische Erkenntnisse als auch praktische Alltagsregeln und Handlungsan-
weisungen. Wissen stützt sich auf Daten und Informationen, ist im Gegen-
satz zu diesen jedoch immer an Personen gebunden. Es wird von Individu-
en konstruiert und repräsentiert deren Erwartungen über Ursache-Wirkung-
Zusammenhänge. [PRR03]
Auf dieser im deutschsprachigen Raum anerkannten Definition baut die weitere Arbeit
auf.
Die Unterscheidung zwischen explizitem und implizitem Wissen ist in der Wissensmana-
gementliteratur weit verbreitet und gründet auf der Arbeit von Michael Polanyi [Pol66]
aus dem Jahr 1966. Nonaka und Takeuchi [NT95] greifen diesen Ansatz auf und entwerfen
ein Modell, bei dem Wissen in einer kontinuierlichen Transformation zwischen implizi-
tem und explizitem Wissen erzeugt wird. Explizites Wissen existiert in der Gestalt von
Büchern und Dokumenten, Gesetzen, Datenbanken und Handbüchern [OCJG98], impli-
zites Wissen wiederum kann in den Köpfen der Angestellten als Kundenerfahrungen oder
Erinnerungen festgestellt werden und ist sehr schwer kategorisierbar und dokumentierbar.
3.2. Allgemeiner Zusammenhang
Nach Casselman und Coleman [CC04] sind die Konzepte Risiko und Wissen eng mitein-
ander verknüpft. Entscheidungsträger werden beispielsweise nur aufgrund von fehlendem
Wissen über das Wesen und die Folgen der unterschiedlichen Möglichkeiten im Entschei-
dungsprozess mit Risiko konfrontiert. Würden sie vollständiges Wissen über die Möglich-
keiten und deren zukünftige Entwicklung besitzen, wäre ihre Entscheidung mit keinem
Risiko behaftet. Aber dieses vollständige Wissen ist in der Realität nicht vorhanden, Wis-
sen ist somit kumulativ und nur durch Zeit bzw. Leistung erwerbbar. So gründet jedes
Risiko auf einer Wissenslücke und ist indirekt proportional zum vorhandenen, relevanten
Wissen.
Risiken entstehen durch Ungültigkeit von Wissen oder mangelndem Wissenszugang für
den Entscheidungsträger. Nach Casselman und Coleman lassen sie sich auf sieben unter-
schiedliche Quellen von Wissenslücken innerhalb einer Organisation zurückführen. Diese
26

Quellen werden in Tabelle 3.1 aufgelistet und ihnen Beispiele von organisatorischen Ri-
siken gegenübergestellt.
Knowledge Gap Corporate Risk
Incorrect Knowledge - Customer demand
- Product quality
- Performance
Process Uncertainty - Political or regulatory
- Economy
- Markets
- Environmental, health and safety
Knowledge Uncertainty - Credit
- Product costs
Hidden Knowledge - Development of rival products and technologies
- Operational failure
- Organisational failure (fraud, mismanagement)
Cognitive Bounds - Industry and market evolution
- Infrastructure failure
Knowledge Transfer - Supplier performance
- Supply chain efficiency
- Ordering
- Information overload
Application - Inadequate governance
- Poor strategy
- Competitiveness
- Performance
Tabelle 3.1.: Wissensbasierte Klassifikation von unternehmensweiten Risiken nach
[CC04]
Die naheliegendste Wissenslücke, falsche Daten, verdeutlicht den Zusammenhang zwi-
schen Wissen und Risiko. Zusätzliches Wissen kann Risiko vermindern, falsches Wissen
und Ignoranz können es erhöhen. Wenn einem Ereignis zugrundeliegende Prozesse nicht
verstanden werden, entsteht eine Wissenslücke. Dies trifft üblicherweise auf die Vorhersa-
ge von Naturereignissen, wie Wetter- und Erdbebenvorhersagen, zu. Die Unzuverlässig-
keit dieser Vorhersagen beruht auf dem Fehlen von Fachwissen und nicht auf dem Fehlen
von Daten oder deren Unrichtigkeit. Wird Wissen vorenthalten oder ist es nicht zugäng-
lich, entsteht ebenfalls eine Wissenslücke. So ist Wissen für neue Produkte und Prozesse
oft unzugänglich und nur für ein paar eingeweihte Experten erreichbar. Es enthält sich
einem breiten Kreis von Interessierten vor.
27

3.3. Einleitung Wissensrisiken
Die Untersuchungen von Lindstaedt, Koller und Krämer [LKK04] haben gezeigt, dass ein
neuer Typ von Risiken vorliegt, welcher bisher selten systematisch berücksichtigt wurde.
Dieser Typ stellt eine große Bedrohung, speziell von technischen Projekten dar und wird
mit Wissensrisiko betitelt.
In diesem Kapitel wird zunächst veranschaulicht, wie der Begriff Wissen innerhalb eines
Risikos gesehen werden kann. Dies ist auf zwei Arten möglich, den wissensbasierten und
den wissensgefährdenden Risiken. Im Detail wird auf diese beide Arten im nächsten
Kapitel eingegangen.
Das Software Engineering Institute an der Carnegie Mellon University [DWA + 96] sieht
folgende zwei Punkte als entscheidend für eine klare Risikobeschreibung an:
• Eine Beschreibung der derzeitigen Bedingungen, welche möglicherweise zu einem
Verlust führen.
• Eine Beschreibung des Verlustes.
Basierend auf diesen beiden Punkten lassen sich Wissensrisiken in zwei Arten unterteilen.
Erstens Risiken, deren Inhalt Wissen ist (vgl. Abbildung 3.2), d.h. die Ressource Wissen
geht möglicherweise verloren und ist so Teil der Beschreibung des Verlustes (Punkt 2).
Diese Risiken werden im Weiteren wissensgefährdende Risiken genannt.
Abbildung 3.2.: Wissensgefährdende Risiken
Zweitens existieren Risiken, deren Eintreten sich auf fehlendes Wissen gründet (vgl. Ab-
bildung 3.3). Hier ist Wissen nicht der Inhalt des Risikos, sondern mangelndes Wissen
führt zu einem möglichen Risiko (Punkt 1), welches beispielsweise einen zeitlichen, finan-
ziellen oder qualitativen Verlust in sich birgt.
28

Abbildung 3.3.: Wissensbasierte Risiken
3.4. Wissensgefährdende Risiken
Wie schon im vorigen Abschnitt angesprochen, beschreiben wissensgefährdende Risiken
jene Risiken, welche die Ressource Wissen einem bestimmten Risiko aussetzen. Diese
wissensgefährdende Sichtweise entstand aus dem klassischen Risikomanagement in einem
der ersten Beiträge von Kobi [Kob99]. In seiner Arbeit führt Kobi Personalrisiken als eine
eigene Kategorie von Risiken ein. Diese Personalrisiken wurden durch Probst und Knaese
[PK98] um sachlich-technische, organisatorische sowie marktbezogene Know-how-Risiken
zur Gesamtheit der Know-how-Risiken erweitert. Meyer und Zbinden [ZM01] fassen diese
beiden Arbeiten zusammen und führen den Begriff von Wissensrisiken ein.
3.4.1. Personelle Risiken
Nach Kobi [Kob99] lassen sich fast alle Risiken auf den Personalbereich zurückführen, da
Schäden meistens durch menschliches Versagen entstehen. Eine umfassende Betrachtung
der Personalrisiken führt zu vier Hauptrisikogruppen:
• fehlende Leistungsträger (Engpassrisiko)
• gefährdete Leistungsträger (Austrittsrisiko)
• falsch qualifizierte Mitarbeiter (Anpassungsrisiko)
• zurückgehaltene Leistung von Mitarbeitern (Motivationsrisiko)
Unter dem Punkt fehlende Leistungsträger merkt Kobi an, dass qualifizierte Mitarbeiter
in Zukunft in allen Bereichen fehlen werden. Dies hat zur Folge, dass bestimmte Projekte
und Entwicklungen nicht umgesetzt werden können, weil das notwendige Wissen nicht
vorhanden ist. Seit August 2000 gibt es beispielsweise eine Green Card für ausländische
29

Software-Ingenieure in Deutschland, um die Lücke fehlender Fachleute im IT-Bereich zu
schließen 1 .
3.4.2. Know-how-Risiken
Probst und Knaese [PK98] sehen die Personalrisiken als Teil der von ihnen gebilde-
ten Know-how-Risiken und bezeichnen sie mit Personelle Know-how-Risiken. Personelle
Know-how-Risiken bedrohen das Humankapital, an Personen gebundenes Wissen eines
Unternehmens. Wie man in Abbildung 3.4 erkennen kann, gefährden sachlich-technische,
organisatorische und marktbezogene Know-how-Risiken im Unterschied zu den personel-
len Know-how-Risiken das strukturelle Kapital, organisatorisch verankertes Wissen eines
Unternehmens.
Abbildung 3.4.: Know-how-Risikokategorien im Überblick nach [PK98]
Als Basis für ihre Definition von Know-how-Risiken verwenden Probst und Knaese [PK98]
1 http://www.bva.bund.de/aufgaben/auslandsschulwesen/faq/unterseite6/
30

eine verlustbezogene Risikodefinition (siehe Kapitel 2.1.2) und definieren Know-how-
Risiken als die Gefahr für das Unternehmen, einen Verlust an ’Know-how-Kapital’ zu
erleiden.
Nach Probst und Knaese kann ein Know-how-Kapitalverlust 2 durch
• ungewünschten oder unfreiwilligen Abfluss,
• Vernichtung,
• Substitution,
• Fehlallokation oder
• Nichtnutzung
von kritischem Wissen entstehen.
Probst und Knaese unterteilen die Know-how-Risiken in vier Bereiche, die im folgenden
näher erläutert werden. Besonders ausführlich wird auf die sachlich-technischen Know-
how-Risiken eingegangen, um ein diffizileres Verständnis der Know-how-Risiken zu för-
dern.
Personelle Know-how-Risiken
Unter personellen Know-how-Risiken fallen alle Risiken, die aus der Neueinstellung, dem
Einsatz, der Ausbildung oder dem Weggang von Mitarbeitern entstehen. Diese Risiken
realisieren sich durch einen Know-how-Kapitalverlust.
Ein auf High-Tech-Unternehmen spezialisiertes Team von 100 Investmentbankern der
Deutschen Bank in Amerika wechselte mit seinem Leiter Frank Quattrone zum Konkur-
renten Credit Suisse First Boston (CFSB) 3 . Durch diesen Mitarbeiterabgang verliert die
Deutsche Bank das an diese Mitarbeiter gebundene Know-How-Kapital in Form eines
einzigartigen Kontaktnetzes in der High-Tech-Branche.
2 Know-how-Kapital = Humankapital + strukturelles Kapital
3 Vgl. Frankfurter Allgemeine Zeitung (16.Juli 1998 S.13).
31

Sachlich-technische Know-how-Risiken
Sachlich-technische Wissensrisiken entstehen durch die Beschaffung und den Einsatz von
IT-Systemen oder herkömmlichen Medien zur Speicherung kodifizierten Wissens. Reali-
sieren sich diese Risiken, führen sie zu einem Verlust von Know-how-Kapital.
Einige der markantesten Beispiele für sachlich-technische Know-how-Risiken werden an
dieser Stelle aufgezählt:
• Unabsichtlicher Wissenstransfer an die Konkurrenz
• Überschaubarkeitsverlust durch Information Overload
• Verlust von kodifiziertem Wissen durch Inkompatibilitäten mit bestehender tech-
nischer Infrastruktur
• Verlust von kodifiziertem Wissen durch die Verletzlichkeit der IT-Systeme (z.B.
Viren)
• Keine zeitgerechte Aktualisierung von Expertensystemen und Daten
• Mehraufwand durch technische Infrastruktur
• Technikbarrieren der Mitarbeiter
• Entstehung von elektronischen Informations- und Datenfriedhöfen
In Tabelle 3.2 wird das Know-how-Risiko Unabsichtlicher Wissenstransfer an die Kon-
kurrenz mit einigen Eigenschaften, wie etwa Indikator oder potentiellen Auswirkungen,
beschrieben.
Name Unabsichtlicher Wissenstransfer an die
Konkurrenz
Alternativer Name Unfreiwillige Wissens-Diffusion
Indikator Kodifizierungsgrad
Meßtechnik Ermittlung des Kodifizierungsgrades
Praxis-Beispiel Ungewollter Wissensabfluss durch Kooperation
an Konkurrenz
Potentielle Auswirkungen bspw. Verlust von Wettbewerbsvorteilen
Tabelle 3.2.: Sachlich-Technisches Wissensrisiko: Wissenstransfer an die Konkurrenz
32

Als Indikator für dieses Know-how-Risiko dient der Kodifizierungsgrad. Durch Kodifizie-
rung wird implizites Wissen in explizites (zur Unterscheidung von implizitem und expli-
zitem Wissen siehe Ende Kapitel 3.1) übergeleitet und kann somit zwischen einzelnen
Personen leichter kommuniziert bzw. ausgetauscht werden. Kodifizierung vermindert auf
der einen Seite die Auswirkungen von personellen Know-how-Risiken. Auf der anderen
Seite entstehen die sachlich-technischen Know-how-Risiken erst durch die Kodifizierung
und den damit verbunden möglichen Verlust der kodifizierten Informationen.
Eine potentielle Auswirkung des unabsichtlichen Wissenstransfers an die Konkurrenz ist
der Verlust von Wettbewerbsvorteilen. Passende Maßnahmen führen von Risikovermei-
dung, wie Unterlassung der Kodifizierung von in Prozessabläufen verankertem Wissen,
Risikoreduzierung, wie Sicherheitsmaßnahmen im IT-Bereich, Kontrollen bis hin zu Ri-
sikoumverteilung durch entsprechende Versicherungen.
Organisatorische Know-how-Risiken
Organisatorische Know-how-Risiken sind die dritte von Probst und Knaese definierte
Kategorie. Sie bezeichnen die Gefahr, dass die organisatorischen Prozesse oder Strukturen
zu einem Verlust an Know-how-Kapital führen.
Börsenbewegungen im Bereich des Investment-Banking müssen schnell erkannt und ge-
deutet werden, um im Anschluss schnell Entscheidungen treffen zu können. Die Interpe-
denzen der geographisch entfernten Finanzmärkte bewirken, dass auf einzelne Teilmärkte,
Produkte oder Währungen spezialisierte Händler ihr Wissen untereinander austauschen
müssen, um erfolgreich zu sein. Dabei ist Zeit ein sehr kritischer Faktor.
Marktbezogene Know-how-Risiken
Die letzte Kategorie sind die marktbezogenen Know-how-Risiken. Sie betreffen das Wett-
bewerbsumfeld und die Ursachen für ihre Entstehung sind unter anderem die dort wirken-
den Wettbewerbskräfte (vgl. [Por99]), wie Nachfrager, Zulieferer, aktuelle und potentielle
Konkurrenten oder die Bedrohung durch Substitute.
33

3.4.3. Definition Wissensrisiken nach Meyer und Zbinden
Meyer und Zbinden [ZM01] fassen die Arbeit von Probst und Knaese sowie Kobi zusam-
men. Sie verwenden auch erstmals den Begriff Wissensrisiken und unterscheiden zwischen
personellen und organisatorischen Wissensrisiken.
Personelle Wissensrisiken definieren sie als all jene Risiken [...], die aus der Neuein-
stellung, dem Einsatz, der Ausbildung oder dem Weggang von Mitarbeitern resultieren
und zu einem Wissensverlust der Unternehmung führen, dagegen organisatorische Wis-
sensrisiken als die Gefahr, dass die organisatorischen Prozesse oder Strukturen zu einem
Verlust an Wissen führen. Die kann sich auf die individuelle Gruppen-, Unternehmens-
und interorganisationale Ebene beziehen. [ZM01]
Für die vorliegende Arbeit ist diese Definition von Wissensrisiken zu sehr auf den Ver-
lust von Wissen fixiert. Deswegen wird der Begriff Wissensrisiko im nächsten Kapitel
um die auf einer Wissenslücke basierenden Risiken, die so genannten wissensbasierten
Risiken, erweitert, um in weiterer Folge eine breitere und umfassendere Definition von
Wissensrisiken für diese Arbeit zu treffen.
3.5. Wissensbasierte Risiken
Einen erster Ansatz, Wissensrisiken über wissensgefährdende Risiken hinaus zu betrach-
ten stellt die Arbeit von Lindstaedt, Koller und Krämer dar. Sie definieren Wissensrisiken
folgend:
Wissensrisiken sind Risiken, die sich auf einen Mangel von Wissen und Fer-
tigkeiten, welche für die Durchführung einer geschäftsrelevanten Aktion not-
wendig sind, zurückführen lassen. [LKK04]
Lindstaedt, Koller und Krämer führen einige Beispiele an. Darunter beschreiben sie das
Risiko, welches zu Beginn eines Projektes existiert. Inwieweit gelingt es dem Projektteam,
die Kundenanforderungen richtig zu identifizieren und die richtigen Projekt-Stakeholder
einzubinden. Eindeutig ist vorhandenes Wissen hier Grundlage für das Risiko. Riskiert
wird die erfolgreiche Abwicklung des Projektes. Dieses Risiko kann also den wissensba-
sierten Risiken zugeordnet werden.
34

Wissensgefährdende Risiken treten auch aufgrund fehlender Transparenz zu Tage. Ty-
pischerweise lässt sich dies zwischen verschiedenen Abteilungen und Geschäftsbereichen
identifizieren. Ist beispielsweise die Rechtsabteilung nicht über die Existenz eines beson-
ders riskanten Projekttypen informiert, können diese Risiken nicht mit Hilfe von Ver-
tragsgestaltungen oder dem Abschluss von Versicherungen eingedämmt werden.
Wie bereits in Kapitel 3.2 angemerkt, identifizieren Casselman und Coleman [CC04]
sieben Auslöser für Wissenslücken. Diese werden hier nochmals aufgezählt:
• Incorrect Knowledge
• Process Uncertainty
• Knowledge Uncertainty
• Hidden Knowledge
• Cognitive Bounds
• Knowledge Transfer
• Application
Die Arbeit von Casselman und Coleman stammt aus der Theorie der Entscheidungsfin-
dung. So können diese Auslöser nicht direkt für die wissensbasierten Risiken übernommen
werden. Manche von ihnen basieren nicht auf Wissen und lassen sich somit auch nicht mit
Werkzeugen des Wissensmanagements steuern. Offensichtlich sind dies die beiden Punk-
te Process und Knowlegde Uncertainty, weil sie im Kern unveränderbare Unsicherheiten,
wie Naturereignisse, steigende Rohstoffpreise, etc. beinhalten. Auch die Punkte Cogniti-
ve Bounds und Application sind keine Auslöser für wissensbasierte Risiken. Es bleiben
folgende Punkte, welche zugleich Unterkategorien für wissensbasierte Risiken darstellen,
bestehen; die Liste wird zudem um die Punkte Unzureichendes Wissen, welches sich klar
von versteckten Wissen abgrenzt, und inadäquate Nutzung erweitert, um vollständiger
zu sein.
• fehlerhaftes Wissen
• verstecktes Wissen
• unzureichendes Wissen
35

• Mangel im Wissenstransfer
• inadäquate Nutzung
3.6. Definition Wissensrisiken
Aufbauend auf der Unterscheidung zwischen wissensbasierten und wissensgefährdenden
Risiken wird in diesem Kapitel eine eigenständige Definition für den Begriff Wissensrisi-
ken getroffen. Sie zieht einerseits in Betracht, dass die Ressource Wissen einem gewissen
Risiko ausgesetzt ist und andererseits, dass ein Risiko aufgrund eines Mangels an Wissen
entstehen kann.
Wissensrisiken sind Risiken, die sich auf einen Mangel von Wissen und Fer-
tigkeiten, welche für die Durchführung einer geschäftsrelevanten Aktion not-
wendig sind, zurückführen lassen und Risiken, die das Wissenskapital einer
nach wirtschaftlichen Zielsetzungen handelnden Organisation bedrohen.
Die obige Definition bezieht sich auf Organisationen oder Teile dieser Organisationen,
und hat damit eine allgemeine Gültigkeit. Wie schon in den vorigen Kapiteln erläutert
spezialisiert sich diese Arbeit auf Wissensrisiken in Projekten; die Definition der Wis-
sensrisiken wird im Weiteren unter einem projektspezifischen Gesichtspunkt betrachtet,
wobei dieser nicht stark von einem organisationsspezifischen abweicht.
3.7. Eigenständige Kategorie Wissensrisiken
In Kapitel 2.4 wurden Beispiele für die Unterteilung der traditionellen Risiken in Kate-
gorien angegeben. Im Projektrisikomanagement sind dies beispielsweise die Unterteilung
in finanzielle, technische, organisatorische Risiken, usw. (vgl. RAMP, Kapitel 2.4.2)
Nun könnte man diese klassischen Kategorien um eine zusätzliche für Wissensrisiken
erweitern, und sie so dem klassischen Risikomanagement anfügen. Damit würden die
Wissensrisiken mitsamt den traditionellen Risiken gehandhabt.
Koller [Kol05] sieht allerdings in der gezielten Identifikation von Wissensrisiken die Mög-
lichkeit für technische und innovative Unternehmen, die für sie zentrale Ressource Wissen
36

Abbildung 3.5.: Eigenständige Betrachtung von Wissensrisiken
zu verwalten. Wissensrisiken finden sich hier zum Großteil bereits in den Kategorien des
traditionellen Risikomanagements (siehe Abbildung 3.5) wieder, werden aus ihnen her-
aus gelöst und zusammen mit neu identifizierten Wissensrisiken zu einer eigenständigen
Kategorie vereinigt.
Diese eigenständige, vom klassischen Risikomanagement losgelöste Betrachtung besitzt
den großen Vorteil, dass man sofort die zentralen Risiken identifiziert, und auch ähnliche
Werkzeuge aus dem Bereich des Wissensmanagements zur Verfügung stehen, um diese
gezielt zu steuern.
3.8. Generischer Wissensrisikokatalog
Auf der Grundlage der Definition von Wissensrisiken und den Ausführungen über wis-
sensbasierte und wissensgefährdende Risiken wird in diesem Abschnitt ein generischer
Katalog für Wissensrisiken entwickelt. Dieser Katalog stellt keinen Anspruch auf Voll-
ständigkeit, da dies den Rahmen der Arbeit übersteigen würde, sondern dient dazu, einen
Überblick über verschiedenste Kategorien zu geben und vor allem das Modell, und damit
auch den entwickelten Prototyp, mit sinnvollen Daten zu füllen um die Funktionsweise
von beiden prüfen zu können.
Die Hauptkategorie wissensgefährdende Risiken basiert auf der Arbeit von Probst und
Knaese [PK98]. So lehnen sich die Unterkategorien, wie personelle oder sachlich-technische
37

Wissensrisiken, sehr stark an ihre Arbeit an. Auch die einzelnen Beispiele für generische
Wissensrisiken, wie kriminelle Delikte oder Demotivation der Mitarbeiter, stammen groß-
teils von den genannten Autoren.
Die zweite Hauptkategorie wissensbasierte Risiken baut auf der Arbeit von Casselman
und Coleman [CC04] auf, welche aber für die Verwendung auf Wissensrisiken adaptiert
wurde (vgl. Kapitel 3.5). Die generischen Risiken wurden vom Autor selbst geschaffen.
Im Modell und im Prototyp unterstützt dieser Katalog den Anwender bei der Identifi-
kation von Wissensrisiken, indem ermöglicht wird, reale Risiken von diesen generischen
Risiken abzuleiten. In Kombination mit einem Katalog von Steuerungsmaßnahmen und
einer logischen Verknüpfung mit diesen, unterstützt der Katalog von generischen Wis-
sensrisiken auch die Entwicklung von passenden Steuerungsmaßnahmen. Diese Aspekte
sind Teil Steuerung von Wissensrisiken aus Kapitel 4 und dem Modell aus Kapitel 5.
Auszug aus dem generischen Wissensrisiko-Katalog (der vollständiger Katalog befindet
sich in Anhang A):
• wissensgefährdende Risiken
– Personelle
∗ Schlüsselpersonen verlassen das Unternehmen
∗ Demotivation der Mitarbeiter
∗ ...
– Sachlich-technische
∗ unfreiwillige Know-how-Diffusion
∗ Verlust an Überschaubarkeit
∗ ...
– Organisatorische
∗ kulturelle Unterschiede
∗ unkontrollierte Wissenszu- und Abflüsse
∗ ...
– Marktbezogene
∗ Abwanderung wichtiger Kunden
∗ Ineffizienzen im Umgang mit wissensbasiertem Kunden-Kapital
38

∗ ...
• wissensbasierte Risiken
– falsches Wissen
∗ falsche Informationen bzw. Daten
∗ falsche Interpretation
∗ ...
– verstecktes Wissen
∗ fehlende Überschaubarkeit
∗ Nichtnutzung (= nicht zureichende Aktivierung)
∗ ...
– unzureichendes Wissen
∗ unzureichende Bildung
∗ unzureichende Vorbereitung
∗ ...
– Wissenstransfer
∗ mangelhafte Infrastruktur
∗ Organisationsmangel (Prozess, Handlung)
∗ ...
– falsche Nutzung
∗ Zielkonflikte: Menschen und Unternehmen
∗ unzureichende Internalisierung
∗ ...
3.9. Zusammenfassung
Wissen und Risiko sind zwei Konzepte, welche eng miteinander verknüpft sind. Zusätzlich
erworbenes Wissen kann Risiko minimieren, falsches Wissen hingegen kann es erhöhen.
Wissensrisiken lassen sich einerseits in wissensgefährdende Risiken, die das Wissenskapi-
tal gefährden, und andererseits in wissensbasierte Risiken, die aufgrund einer Wissens-
lücke entstehen, unterteilen. Eine eigenständige Betrachtung dieser Risiken ist besonders
39

für High-Tech-Unternehmen, aufgrund der innerbetrieblich zentralen Rolle der Ressource
Wissen, sinnvoll.
Die Identifikation von Wissensrisiken kann durch die Verwendung eines Katalogs von
generischen Risiken unterstützt werden, und gemeinsam mit einen Katalog an generischen
Steuerungsmaßnahmen zusätzlich die Entwicklung von passenden Steuerungsmaßnahmen
fördern.
40

4. Steuerungsstrategien und Maßnahmen
Dieses Kapitel baut auf dem klassischen Risiko-
management (vgl. Kapitel 2) sowie der Definiti-
on des Begriffs Wissensrisiken für diese Arbeit
(vgl. Kapitel 3.1) auf, und beschäftigt sich weiters
mit der Entwicklung von passenden Steuerungs-
maßnahmen für Wissensrisiken und der Auswahl
der geeignetsten für ein spezifisches Risiko. Die-
se beiden Schritte sind für eine gute Steuerung
von Risiken entscheidend (vgl. [Kon01]) und wer-
den hier ausführlich beschrieben. Eine besondere
Bedeutung fällt in diesem Kapitel außerdem dem
darin entwickelten Katalog an generischen Steue-
rungsmaßnahmen zu, welcher gemeinsam mit dem in Kapitel 3 entwickelten Katalog an
generischen Wissensrisiken die Basis für das im nächsten Kapitel beschriebene Modell
darstellt.
Der Stellenwert der Identifikation und Entwicklung von passenden Steuerungsmaßnah-
men für ein erfolgreiches Risikomanagement und die Eigenschaften einer guten Maßnah-
me werden in der Einleitung erklärt. Daraufhin werden in diesem Kapitel verschiedene
Strategien für den Umgang mit Wissensrisiken aufgezählt und näher erläutert. Steue-
rungsmaßnahmen für wissensgefährdende und wissensbasierte Risiken geben dann erst-
mals einen Einblick in konkrete Maßnahmen und deren Kategorien. Sie sind die Grund-
lage für den entwickelten Katalog an generischen Maßnahmen. Am Ende des Kapitels
wird noch erklärt, nach welchen Kriterien man aus mehreren Maßnahmen die geeignetste
auswählen kann.
In dieses Kapitel fließt sowohl Literatur aus dem klassischen Risikomanagement, wie
bei den unterschiedlichen Steuerungsstrategien oder dem Auswählen der geeignetsten
Maßnahme, und andererseits Literatur aus dem Gebiet der Wissensrisiken und des Wis-
41

sensmanagements, etwa im Rahmen der Steuerungsmaßnahmen für wissensgefährdende
und wissensbasierte Risiken, ein.
4.1. Einleitung
Kapitel 2.3.4 setzte sich schon mit der Maßnahmenplanung als Teil des Risikomanage-
mentprozesses auseinander. So wurden in Abbildung 2.3 Prozesse aus unterschiedlichen
Standards und Richtlinien aufgezeigt und festgestellt, dass der Maßnahmenplanung bzw.
-durchführung ein eigener Prozessschritt zufällt. Dies unterstreicht die Wichtigkeit dieses
Teilprozesses für den gesamten Risikomanagementprozess.
Die Prozessschritte Risikoidentifikation und Bewertung gewinnen durch die Planung und
Umsetzung von Maßnahmen an großem Wert (vgl. [Hil99]), trotzdem ist die Maßnahmen-
planung meistens der schwächste Teil des Risikomanagementprozesses und viele Organisa-
tionen verabsäumen es dadurch, die vollen Möglichkeiten des Projektrisikomanagements
auszunützen.
Hillson [Hil99] beschreibt in seiner Arbeit folgende Kriterien für eine effektive Steue-
rungsmaßnahme:
• Appropriate - die Größe der Maßnahme muss zu der des Risikos passen
• Affordable - eine Kosten/Nutzen Analyse muss für die Maßnahme durchgeführt
werden
• Actionable - ein Zeitfenster für den möglichen Start der Maßnahme muss festgelegt
werden
• Achievable - eine Maßnahme muss technisch und mit den vorhandenen Ressourcen
umsetzbar sein
• Assessed - nach der Durchführung einer Maßnahme muss eine erneute Bewertung
der Wirkung der Maßnahme für zukünftige Anwendungen erfolgen
• Agreed - alle Stakeholder im Projekt sollen mit der Maßnahme einverstanden sein
und sie unterstützten
• Allocated & Accepted - die Verantwortung für eine Maßnahme soll einer Person
zugewiesen werden
42

Diese Kriterien beschreiben eine ideale Maßnahme. Eine reale Maßnahme kann nicht
allen Kriterien zur Gänze entsprechen, deswegen ist es notwendig, die für die Maßnahme
entscheidenden Kriterien auszuwählen und sie anhand dieser zu entwickeln.
Die Umsetzung der entworfenen Steuerungsmaßnahmen ist üblicherweise mit Kosten, wie
einer zeitlichen Verzögerung, dem Bedarf von zusätzlichen Ressourcen oder finanziellen
Aufwendungen, verbunden (vgl. [Hil99]). Ein wichtiger Punkt für eine effektive Umset-
zung einer Maßnahme ist die Akzeptanz in einem Projekt. Das frühzeitige Übernehmen
von fixen Kosten, um sich vor dem möglichen Eintritt von variablen Kosten in der Zu-
kunft zu schützen, muss für alle Projektbeteiligten verständlich sein. Dieser Vorgang
macht natürlich nur dann Sinn, wenn die Ausgaben für eine Maßnahme der Größe des
Risikos angepasst sind (siehe Effizienz einer Steuerungsmaßnahme, Kapitel 4.6.2).
4.2. Strategien
Mit den unterschiedlichen Strategien zum Umgang mit Risiken verhält es sich ähnlich
wie mit den Schritten in den verschiedenen Risikomanagementprozessen (vgl. Kapitel
2.3). Die einzelnen Standards verwenden ähnliche Strategien, betiteln diese allerdings
manchmal anders oder verwenden eine feinstufigere Unterteilung. Der PMBoK [PMI04],
ein amerikanischer Standard aus dem klassischen Risikomanagement, unterscheidet zwi-
schen Vermeidung, Minderung und Akzeptanz. Die RAMP [SNC98] Richtlinie schlägt zu-
sätzlich eine Risikoumverteilungsstrategie vor und unterscheidet zwischen Maßnahmen,
welche die Eintrittswahrscheinlichkeit des Risikos und solche welche die Auswirkungen
vermindern.
Die Literatur aus dem Bereich der Wissensrisiken lehnt sich sehr stark an das klassische
Risikomanagement an. So differenziert Probst [PK98] beispielsweise zwischen Risikover-
meidung und -reduzierung. Zbinden und Meyer [ZM01] erweitern dies um die Strategie
der Risikodiversifikation.
Am ausführlichsten beschäftigt sich Hillson [Hil99] mit den Steuerungsstrategien, deshalb
ist seine Arbeit die Grundlage für die folgenden Ausführungen zu diesem Thema. Hillson
unterscheidet zwischen den vier Strategien: Vermeidung, Umverteilung, Minderung und
Akzeptanz. An dieser Stelle werden diese Strategien detaillierter erläutert.
43

4.2.1. Vermeidung
Die Risikovermeidungsstrategie versucht Unsicherheiten vollständig zu beseitigen. Zwei
unterschiedliche Arten von Maßnahmen, direkte und indirekte, können zur Erreichung
dieses Ziels angewendet werden. Direkte Maßnahmen finden Verwendung, wenn ein Ri-
siko in Wissenslücken begründet ist (vgl. wissensbasierte Risiken, Kapitel 3.5). Folgende
Maßnahmen greifen diese Unsicherheiten direkt an.
• Anforderungen abklären
• Ziele definieren
• Informationen sammeln
• Kommunikation verbessern
• Forschung betreiben (Bau eines Prototyps, Entwicklung)
• Expertenwissen aneignen (mittels Schulungen oder der Anstellung von neuen Mit-
arbeitern)
Alternativ zu diesen Maßnahmen kann man auch die Quelle des Risikos adressieren.
Eine Vermeidungsmaßnahme entfernt entweder die Quelle des Risikos oder unterbricht
die kausale Kette und verhindert damit das Eintreten des Risikos.
Indirekte Maßnahmen führen zu einer Durchführung des Projektes auf eine andere Weise.
Dies kann die Unsicherheiten dadurch eliminieren, dass die Auswirkungen eines Risikos
für das Projekt bedeutungslos werden. Dies kann unter anderem durch folgende Hand-
lungen erreicht werden:
• den Umfang des Projektes verändern um riskante Elemente auszuschließen
• einen vertrauten Ansatz anstatt eines innovativen zu verwenden
• auf bewährte Technologie oder Verfahren zurückgreifen
• Redundanz in das Projektdesign einbauen
44

4.2.2. Umverteilung
Mittels der Risikoumverteilungsstrategie wird die Verantwortung für ein spezielles Risiko
an einen Dritten weitergereicht. Durch die Anwendung dieser Strategie können haupt-
sächlich finanzielle Auswirkungen abgefedert werden, wo im Falle des Risikoeintritts Drit-
te den finanziellen Schaden ausgleichen. Üblicherweise ist zuvor eine Zahlung einer Risi-
koprämie an diesen Dritten notwendig. Die Kosten dafür sollten immer mit den Nutzen
der Risikoumverteilung verglichen werden.
Eine Risikoumverteilung lässt sich beispielsweise durch den Abschluss einer Versicherung
durchführen. Andere finanzielle Instrumente erstrecken sich von Erfüllungsgarantien über
Gewährleistungen bis hin zu Bürgschaften. Andere Werkzeuge der Risikoumverteilung
bauen auf dem Weiterreichen der Verantwortung auf der Basis von Verträgen auf. Unter
anderem gehört die Verwendung eines Festpreis-Vertrages, welches das finanzielle Risiko
auf den Auftragnehmer abwälzt, zu diesen Instrumenten.
Mit Verträgen lassen sich auch spezifische Risiken explizit aus einem Projekt ausschließen
und können auf den Kunden oder den Auftraggeber umverteilt werden. Auf mehrere
Parteien lassen sich Risiken durch Joint Ventures oder Partnerschaften aufteilen.
Unabhängig von der Art der Risikoumverteilung ist es von besonderer Bedeutung, mit
dem Risiko auch die Verantwortung für das Risiko als Teil der Vereinbarung an den
Dritten weiterzugeben. So beinhaltet eine Umverteilung des Risikos unbedingt auch den
Wechsel der für das Risiko verantwortlichen Person bzw. Organisationseinheit. Zu beach-
ten ist, dass die Weitergabe eines Risikos an einen Dritten das Risiko nicht vollständig
beseitigt. Deswegen ist es von großer Wichtigkeit, dass der Dritte auch in der Lage ist,
das Risiko zu steuern. Ist dies nicht der Fall, ist das Projekt einem unkontrollierten Risiko
ausgesetzt.
4.2.3. Minderung
Die Zahl der Risiken, welche durch Vermeidung oder Transfer gesteuert werden können,
ist gewöhnlich limitiert. Das führt dazu, dass Minderung und Akzeptanz die gebräuch-
lichsten Strategien für den Umgang mit Risiken sind. Das Ziel der Risikominderung ist
die Reduktion der Risikoauswirkungen unter den für das Projekt festgesetzten Schwel-
lenwert des akzeptierten Risikos. Damit man ein Risiko unter einen Schwellenwert senken
kann, muss dieser natürlich für das Projekt zunächst festgelegt werden.
45

Die Minderung der Auswirkungen eines Risikos können mit Maßnahmen reduziert werden
die entweder die Eintrittswahrscheinlichkeit oder den möglichen Schaden eines Risikos
mindern. Manchmal ist es auch möglich beide gleichzeitig zu minimieren. Zusätzlich
wird noch zwischen vorbeugenden und heilenden Maßnahmen unterschieden, wobei eine
klare Präferenz zu den vorbeugenden besteht, da diese proaktiver sind und erfolgreich
umgesetzt sogar zu einer Vermeidung des Risikos führen können.
Diese vorbeugenden Maßnahmen greifen an der Quelle des Risikos an und versuchen die
Eintrittswahrscheinlichkeit des Risikos zu reduzieren. Wo eine Reduktion dieser Wahr-
scheinlichkeit nicht möglich ist, versucht man die Auswirkungen beim Eintritt zu ver-
mindern. Ein frühes Ergreifen von Maßnahmen schützt oft vor den schlimmsten Auswir-
kungen eines Risikos und macht das Risiko für das Projekt akzeptabel.
4.2.4. Akzeptanz
Nach der Vermeidung, dem Transfer und der Minderung von Risiken bleibt dennoch ein
gewisses Restrisiko bestehen. Dieses Restrisiko beinhaltet all die kleinen Risiken, deren
Steuerung mehr Kosten verursachen würde, als der mögliche Schaden des Risikos wäre.
Auch bei diesen Risiken ist ein proaktiver Umgang von Bedeutung.
Die gebräuchlichste Maßnahme ist ein Notfallplan, welcher die benötigten Ressourcen in
Form von Kosten und Zeit beschreibt. Dies ist sowohl für bereits identifizierte als auch
für unbekannte Risiken von Bedeutung.
4.3. Steuerungsmaßnahmen für wissensgefährdende Risiken
Die Ausführungen über Steuerungsmaßnahmen für wissensgefährdende Risiken basieren
großteils auf der Arbeit von Probst und Knaese und werden in dieselben Kategorien wie
die wissensgefährdenden Risiken an sich (vgl. Kapitel 3.4) unterteilt.
4.3.1. Personelle Wissensrisiken
Wie in Kapitel 3.4.1 bereits erwähnt, bedrohen personelle Wissensrisiken das Humanka-
pital (an Personen gebundenes Wissen) eines Unternehmens. Dementsprechend schützen
46

die Steuerungsmaßnahmen aus diesem Bereich das Humankapital. Im Folgenden werden
sie anhand der Bereiche Risikovermeidung, -minderung und -umverteilung näher erklärt.
Risikovermeidung
Im Bereich der personellen Wissensrisiken ist eine vollständige Risikovermeidung nur
schwer möglich. Denn die Einstellung von Mitarbeitern führt automatisch zur Entste-
hung von personellen Wissensrisiken [PK98]. Vollständig können diese Risiken also nicht
vermieden werden. Aber in Einzelfällen ist dies durchaus möglich, beispielsweise durch
die Entlassung oder Nichteinstellung risikobehafteter Mitarbeiter.
Risikoreduzierung
Dagegen existiert eine umfangreichere Sammlung an Maßnahmen zur Reduzierung von
personellen Wissensrisiken. Ein erster Ansatzpunkt ist die Quantität des Personals. Wis-
sensrisiken, welche auf einer arbeitsmäßigen Überlastung der Mitarbeiter beruhen, lassen
sich beispielsweise durch eine adäquate Steuerung der Quantität des Personals reduzie-
ren. Weitere Maßnahmen in Zusammenhang mit der Quantität der Mitarbeiter reichen
von der Mitarbeitervertragsgestaltung, über Sonderleistungen und Ausbildung bis hin zu
Auffanggesellschaften zur vorübergehenden Weiterbeschäftigung [PK98].
Ein zweiter Ansatzpunkt ist die Qualität des Personals. Die zwei entscheidendsten Quali-
tätskriterien sind die Zuverlässigkeit und die Qualifikation der Mitarbeiter. Maßnahmen,
wie innovative Formen der Aus- und Weiterbildung, risikobewußte Personalauswahl oder
die Schaffung eines lern- und innovationsfreudigen Unternehmensklimas sichern die Qua-
lität des Personals.
Die beiden obigen Ansatzpunkte greifen an der Eintrittswahrscheinlichkeit der personel-
len Wissensrisiken an. Ein dritter Ansatzpunkt hingegen vermindert den Schaden, den
potentiellen Wissenskapitalsverlust, beim Eintritt eines Risikos. Mittels Maßnahmen,
welche zu einer vorzeitigen Teilung von Wissen mit anderen Organisationsmitgliedern
führen, können personelle Wissensrisiken gesteuert werden. So geht durch den Weggang
eines Mitarbeiters nicht das ganze an ihn gebundene Wissen verloren, wenn es zuvor mit
anderen Mitarbeitern geteilt wurde. Maßnahmen aus diesem Bereich sind unter anderem
der Aufbau von Expertenverzeichnissen oder die Verbesserung des Wissenszugriffs durch
Anreiz-Beitragssysteme.
47

Risikoumverteilung
Personelle Wissensrisiken lassen sich durch Umverteilungsmaßnahmen, wie den Abschluss
einer Personalgarantieversicherung, steuern. Sie kommt für Schäden aus Delikten auf, die
von Mitarbeitern begangen wurden.
4.3.2. Sachlich-Technische Wissensrisiken
Wie schon in Kapitel 3.4.2 näher erläutert, entstehen sachlich-technische Wissensrisiken
durch die Beschaffung und den Einsatz von IT-Systemen oder herkömmlichen Medien zur
Speicherung kodifizierten Wissens. Realisieren sie sich, führen sie zu einem Verlust an
Wissenskapital. Vor diesem Verlust schützen Maßnahmen aus dem sachlich-technischen
Bereich, die nun anhand der Bereiche Risikovermeidung, -minderung und -umverteilung
näher erklärt werden.
Risikovermeidung
Die sachlich-technischen Risiken gründen auf der Kodifizierung von Wissen. Sie ließen
sich einfach anhand eines Verzichtes auf Kodifizierung von Wissen vermeiden. Eine solche
vollkommene Verzichtsstrategie scheint allerdings wenig sinnvoll, da infolgedessen auch
die mit der Kodifizierung einhergehenden Vorteile, wie die Erleichterung des Wissen-
stransfers und die Reduktion von personellen Wissensrisiken, verloren gehen.
In Kapitel 3.4.2 wurde das Beispiel des Unabsichtlichen Wissenstransfers an die Kon-
kurrenz ausführlich beschrieben. Eine Vermeidung der Kodifizierung von Wissen würde
dieses Risiko wahrscheinlich nicht vollkommen ausschließen, aber ein Transfer von Wissen
bzw. Informationen an die Konkurrenz würde deutlich erschwert werden.
Risikoreduzierung
Die Maßnahme Schutz vor gewöhnlicher Einbruchs- und Diebstahlskriminalität stammt
aus dem nicht-technischen Betriebsbereich. Allerdings lassen sich mit ihr ebenfalls Risi-
ken, wie der physische Diebstahl von Wissens-Speichermedien, steuern. Um diesen phy-
sischen Diebstahl zu verhindern, ist hauptsächlich ein guter Zugangs- und Zugriffsschutz
für Computersysteme und Datenträger von Bedeutung.
48

Die aus dem IT-Bereich stammenden Maßnahmen konzentrieren sich auf Zugangs- und
Zugriffssicherheit, Übertragungssicherheit und Schutzmaßnahmen gegen Softwaremani-
pulationen und solchen in Verbindung mit digitalen Kommunikationsanlagen [PK98].
Das Risiko Unabsichtlicher Wissenstransfer an die Konkurrenz könnte beispielsweise mit
einer Maßnahme aus dem Bereich Übertragungssicherheit reduziert werden. Würden alle
ausgehenden Nachrichten eines Unternehmens nur verschlüsselt gesendet werden, könnten
sie zwar von der Konkurrenz empfangen, aber nicht entschlüsselt und somit auch nicht
verwertet werden.
Sachlich-technische Risiken lassen sich auch mithilfe von Anwenderschulungen reduzie-
ren. Schulungen über den Umgang mit IT-Systemen können unzureichenden Mitarbei-
terkenntnissen und den damit verbundenen Wissensrisiken entgegenwirken.
Risikoumverteilung
Die durch höhere Gewalt ausgelösten Wissensrisiken, wie Feuer oder Diebstahl, können
durch die Auslagerung der IT in ein Rechenzentrum eines fremden Unternehmens, welches
verschiedene Datenzentren mit redundanten Beständen hält, auf einen Dritten umverteilt
werden.
4.3.3. Organisatorische Wissensrisiken
Wie bereits in Kapitel 3.4.2 beschrieben sind organisatorische Wissensrisiken solche, die
zu einer Gefährdung von organisatorischen Prozessen oder Strukturen, und so zu ei-
nem Wissenskapitalverlust führen. Steuerungsmaßnahmen aus dieser Kategorie versu-
chen dem Wissenskapitalverlust entgegenzuwirken. Genauso wie die organisatorischen
Risiken verschiedene Ebenen der Organisation durchziehen, entsprechen die dafür vorge-
sehenen Maßnahmen diesen Ebenen. Deswegen werden im Folgenden die Maßnahmen zu
Gruppen auf die Kategorien Individuelle Ebene, Gruppenebene, Gesamtebene und Inter-
organisatorische Ebene aufgeteilt.
49

Individuelle Ebene
Durch Bereichsegoismus entsteht oft ein Festhalten an Mitarbeitern, dass dem „Einsper-
ren“ von Kompetenzen gleichkommt. Diesem Risiko kann durch die Einführung einer
systematischen Job-Rotation entgegengewirkt werden. Außerdem verhindern starre und
veraltete Beförderungsregeln ebenfalls die Nutzung von vorhandenen Wissen und Kom-
petenzen. Sie lassen sich mittels Flexibilisierung und Entbürokratisierung der Unterneh-
mensstrukturen abschwächen.
Gruppenebene
Auf Gruppenebene können unter anderem Telearbeitsplätze, die ausschließlich am PC
zuhause eingerichtet sind, Wissenskapital gefährden. Der Grund hierfür liegt in der Ein-
schränkung von persönlicher Kommunikation, dem wichtigsten Medium zur Wissenstei-
lung. So können informelle Netzwerkbeziehungen und darin verankertes Wissen zerstört
werden, wenn einer der Mitarbeiter auf Telearbeit umsteigt. Eine alternierende Telear-
beit, bei der Tätigkeiten abwechselnd zuhause und im Büro durchgeführt werden, würde
dieses Wissensrisiko reduzieren.
Gesamtebene
Dieser Kategorie gehören unter anderem Risiken, die durch Outsourcing von Entschei-
dungen entstehen, an. Um diese Risiken zu minimieren ist individuell zu prüfen, ob durch
die Fremdvergabe gleichzeitig unternehmensspezifisches Wissen verloren geht oder Kom-
petenzen durch Nichtnutzung vernichtet werden.
Interorganisationale Ebene
Bei einer Zustimmung zu einer unternehmensübergreifenden Kooperation steht sehr viel
Wissen auf dem Spiel. Einer Kooperation sollte aus dem wissensorientierten Blickwinkel
nur dann zugestimmmt werden, wenn sich ein eigenständiger Wissensaufbau aus finanzi-
ellen, zeitlichen oder aus Gründen einer mangelhaften Wissensbasis verbietet. Bei einer
Kooperation kann man sich durch Vereinbarungen, über spezielle Tabubereiche, wie wett-
bewerbskritisches Wissen, vor einem Wissenstransfer in fremde Unternehmen schützen.
50

4.3.4. Marktbezogene Wissensrisiken
Wie in Kapitel 3.4.2 bereits erläutert, betreffen marktbezogene Wissensrisiken das Wett-
bewerbsumfeld und die Ursachen für ihre Entstehung sind unter anderem die dort wir-
kenden Wettbewerbskräfte. Die marktbezogenen Wissensrisiken lassen sich nach Porter
[Por99] in die folgenden vier Bereiche unterteilen:
• Kunden
• Zulieferer
• Konkurrenz
• Bedrohung durch Substitute
Da die Maßnahmen für die einzelnen Kategorien sehr unterschiedlich sind, werden sie im
Weiteren einzeln diesen Kategorien entsprechend erklärt.
Kunden
Ein sehr beliebtes Werkzeug zur Verhütung von Wissensverlusten durch Kundenabwan-
derungen ist die Verbesserung des Kundenverhältnisses. Dies kann beispielsweise durch
Servicegarantien oder ein Versprechen gegenüber den Kunden, bei Abweichungen von
einem bestimmten Serviceniveau eine Entschädigung zu zahlen, erfolgen. Eine andere
bewährte Maßnahme ist die Vergabe von Treuepunkten oder Database-Marketing.
Zulieferer
Unternehmensberater und Lieferanten von Hard- und Software sind Zulieferer, die Wis-
senskapital gefährden können. Ein vollständiger Verzicht von Wissensimport durch Unter-
nehmensberater ist meistens nicht zielführend. Im Zuge des Beratungsgespräches sollte
ein klar umrissenes Wissensziel, welches Expertenwissen während der Beratung ange-
eignet werden soll, definiert werden. Entscheidend ist zusätzlich die unternehmensweite
Verbreitung dieses Wissens. Diese Verbreitung kann mittels Lessons-Learned-Seminaren
oder der Migration von Mitarbeitern in den Beratungsprozess erreicht werden.
51

Konkurrenz
Wissensabflüsse an die Konkurrenz entstehen oft durch Unternehmensberater oder in
Zusammenhang mit Competitive-Intelligence-Aktivitäten. Auf den Bereich Unterneh-
mensberater wurde im vorigen Abschnitt bereits eingegangen, deswegen konzentrieren
wir uns hier auf Competitive-Intelligence-Aktivitäten. Einerseits müssen sich Unterneh-
men vor Competitive-Intelligence-Aktivitäten ihrer Mitbewerber in Acht nehmen und
anderseits selbst dieses Instrument verwenden, um einen Wettbewerbsvorteil gegenüber
der Konkurrenz zu erreichen.
Bedrohung durch Substitute
Der Gefahr, dass neue Kompetenzen entstehen, welche die derzeitigen Kernkompeten-
zen eines Unternehmens ersetzen oder obsolet werden lassen, kann durch die Antizipie-
rung möglicher Kompetenzsprünge begegnet werden. So muss ein Unternehmen ständig
überlegen und antizipieren, welche neuen Kompetenzen aufgebaut werden sollen um die
derzeitige Position zu festigen bzw. auszubauen.
4.4. Steuerungsmaßnahmen für wissensbasierte Risiken
Die Ausführungen über Steuerungsmaßnahmen für wissensbasierte Risiken basieren haupt-
sächlich auf der Arbeit von Rollett [Rol03], da diese Arbeit eine ausführliche Beschreibung
der Werkzeuge und Techniken des Wissensmanagements beinhaltet. Mittels dieser Werk-
zeuge und Techniken lassen sich wissensbasierte Risiken steuern und sie werden an dieser
Stelle, in den Kategorien von Rollett unterteilt, allgemein und anhand von Beispielen
erklärt.
4.4.1. Kommunikation
Kommunikation ist sehr wichtig für ein gutes Wissensmanagement. Besonders bei der Er-
zeugung von Wissen und dem Transfer von Wissen ist die Kommunikation ein zentraler
Bestandteil (vgl. [Rol03]). Die Kommunikationstechnologie unterstützt einen Wissensaus-
tausch im Projekt indem sie die Kommunikation der Mitarbeiter untereinander fördert.
52

Beispielsweise ermöglichen virtuelle Plattformen, wie Diskussionsgruppen oder eine Mai-
lingliste, die Kommunikation zwischen Menschen, wenn keine persönliche Sitzung möglich
ist.
4.4.2. Zusammenarbeit
Die Zusammenarbeit zwischen Mitarbeitern im Projekt wird typischerweise durch Grup-
penprogramme unterstützt. Sie fördern die Wissensteilung und die Kommunikation zwi-
schen den Gruppenmitgliedern. Beispielsweise ermöglichen Shared Spaces nicht nur Be-
sprechungen von örtlich getrennten Personen, sondern schaffen auch eine zusätzliche Qua-
lität der Kommunikation durch die Integration von virtuellen White Boards und Shared
Browsing in Videokonferenzen. Zudem schaffen Gruppenprogramme eine Kultur des Wis-
sensteilens im Projekt und wirken so einer fehlenden Bereitschaft zur Teilung von Wissen.
4.4.3. Erstellen von Inhalten
Das Erstellen von Inhalten technologisch zu unterstützen ist offensichtlich für das Wis-
sensmanagement bedeutend, da es Mitarbeitern eine effiziente Erklärung und Dokumen-
tierung ihres Wissens ermöglicht. Das Erstellen von Inhalten wird durch das Wissensma-
nagement nicht nur unterstützt, sondern oft sogar dadurch erst eingeleitet. Durch eine
automatische Erzeugung von Expertenprofilen in einem Arbeitsschritt kann beispiels-
weise verstecktes Wissen ans Tageslicht gefördert werden. Erkennt das System, dass ein
Mitarbeiter mehrfach zu einem bestimmten Thema in E-Mails befragt wird, kann das
System trotz der Tatsache, dass er nie zu diesem Thema publiziert hat, darauf schließen,
dass der jeweilige Mitarbeiter ein Experte auf diesem Gebiet ist.
4.4.4. Content Management
Explizites Wissen ist zum Großteil in Dokumenten gespeichert. Jede Technologie, die da-
bei hilft, diese Dokumente zu verwalten, unterstützt im weitesten Sinn das Wissensma-
nagement im Projekt. Viele Content Management Systeme unterstützen unter anderem
ein Zusammenfassen von Dokumenten zu Sammlungen anhand eines Klassifizierungs-
schemas. Diese Klassifizierung ermöglicht ein einfaches Auffinden der Dokumente und sie
wirkt den in fehlender Überschaubarkeit begründeten wissensbasierten Risiken entgegen.
53

Auf falschen Daten bzw. Informationen basierte Risiken können entstehen, wenn veral-
tete Dokumente wiederverwendet werden. Hier scheint die Technologie des Versionings,
wobei unterschiedliche Versionen eines Dokuments automatisch mitverfolgt werden, ein
passendes Instrument zu sein.
4.4.5. Adaptierung
Durch Adaptierung muss sich der Benutzer nicht länger der Technologie anpassen, sie
kann sich stattdessen auf jeden Benutzer individuell einstellen. So wird der Inhalt und
die Darstellung auf jeden Benutzer abgestimmt. Stimmt man beispielsweise die Visuali-
sierung von Wissenslandkarten auf den Benutzer und die Situation, in der sie aufgerufen
werden, ab, wird die Karte für den Benutzer übersichtlicher, Wissen lässt sich leichter
identifizieren und in Bezug stellen. Eine besser auf den Benutzer abgestimmte Darstellung
kann zudem eine falsche Interpretation durch den Benutzer verhindern.
4.4.6. E-Learning
E-Learning ist eine kostensparende Möglichkeit, Wissen zu transferieren. Einerseits sind
die Entwicklungskosten für einzelne Kurse relativ hoch, andererseits sind die Durchfüh-
rungskosten jedoch sehr gering. Wissen lässt sich mittels E-Learning schneller und an
eine größere Anzahl von Mitarbeitern verbreiten, als mit herkömmlichen, von Ausbildern
geführten Seminaren. So können beispielsweise tausende Angestellte an einem Tag über
neue Produkte informiert und über ihre Funktionen ausgebildet werden. Auf diese Art
und Weise ermöglicht E-Learning sogar das Lernen in Situationen, in denen es sonst nicht
möglich wäre. Es lässt sich erfolgreich gegen auf unzureichender Ausbildung beruhenden
Risiken anwenden.
4.4.7. Persönliche Werkzeuge
Persönliche Wissensmanagement-Werkzeuge sprechen sowohl die Motivation der Mitar-
beiter als auch die generelle Akzeptanz von Wissensmanagementprojekten an. Die Fragen
nach dem persönlichen Nutzen von diesen Projekten lässt sich für den einzelnen Angestell-
ten viel leichter beantworten, wenn über Werkzeuge für seine persönlichen Bedürfnisse
gesprochen wird. Mittels integrierter Werkzeuge kann beispielsweise einer fehlenden Be-
54

eitschaft zur Wissensteilung entgegengewirkt werden. Persönliche Datenbanken erlauben
wiederum die Führung eines Bücherverzeichnisses, welches bei Bedarf leicht an Kollegen
weitergegeben werden kann.
4.4.8. Künstliche Intelligenz
Es existieren viele Gebiete im Wissensmanagement, wo auf künstlicher Intelligenz be-
ruhende Technologien einen Beitrag leisten. So kann das mittels künstlicher Intelligenz
automatische Zusammenfassen von Dokumenten die Überschaubarkeit verbessern. Zu-
sätzlich können Intelligent Agents mit Analysemethoden für Dokumente Verbindungen
zwischen diesen und Personen herstellen, und somit dem Risiko von verstecktem Wissen
entgegenwirken.
4.4.9. Netzwerke
Die Aufgabe von Netzwerktechnologien im Wissensmanagement ist hauptsächlich die
Errichtung von passender Infrastruktur für Anwendungen. Eine sichere und stabile Netz-
werkverbindung ermöglicht einen geregelten Wissensfluss, Investitionen in die Netzwerk-
technologie wirken somit mangelnder Infrastruktur und den damit verbundenen einge-
schränkten Wissenstransfers entgegen.
4.5. Auszug aus dem Katalog an generischen Maßnahmen
für Wissensrisiken
Auf der Grundlage der beiden obigen Ausführungen zu Steuerungsmaßnahmen für wis-
sensbasierte und wissensgefährdende Risiken wird in diesem Abschnitt ein generischer
Katalog an Maßnahmen für Wissensrisiken entwickelt. Dieser Katalog stellt nicht den
Anspruch vollständig zu sein, da dies den Rahmen der Arbeit übersteigen würde. Er
dient vielmehr dazu, einen Überblick über die verschiedensten Kategorien und Techno-
logien zu bieten.
Die Hauptkategorie der Maßnahmen für wissensgefährdende Risiken basiert auf der Ar-
beit von Probst und Knaese [PK98], so lehnen sich die Unterkategorien, wie personelle
55

oder sachlich-technische Maßnahmen sehr stark an ihrer Arbeit an. Dasselbe gilt für die
einzelnen Werkzeuge wie leistungsabhängige Entlohnung oder Servicegarantien.
Die zweite Hauptkategorie der Maßnahmen für die wissensbasierten Risiken bauen auf
der Arbeit von Rollett [Rol03] auf. Die Kategorien entsprechen seiner Unterteilung der
Werkzeuge des Wissensmanagements und auch die Auflistung der Werkzeuge zur Steue-
rung lehnt sich stark an seine Forschung an.
Der Katalog zeigt, dass sich wissensgefährdende Risiken sowohl mit Maßnahmen aus dem
herkömmlichen Risikomanagement als auch aus dem Wissensmanagement steuern lassen.
Die Maßnahmen aus dem herkömmlichen Risikomanagement schützen vor allem vor dem
Eintritt des Risikos, senken also die Eintrittswahrscheinlichkeit. Die Maßnahmen aus
dem Wissensmanagement schützen das Wissen und reduzieren die möglichen Schäden
des Risikos.
Die Maßnahmen für die wissensbasierten Risiken stammen zur Gänze aus dem Wis-
sensmanagement und setzen sowohl an der Eintrittswahrscheinlichkeit als auch auf den
Auswirkungen an.
Sowohl im Modell als auch im Prototyp unterstützt dieser Katalog den Anwender bei
der Entwicklung von passenden Steuerungsmaßnahmen, indem er anhand einer logischen
Verknüpfung, welche im nächsten Kapitel entsteht, passende generische Maßnahmen für
ein von einem generischen Risiko abgeleitetes spezifisches Risiko vorschlägt.
Auszug aus dem generischer Maßnahmenkatalog für Wissensrisiken (vollständiger Kata-
log in Anhang B)
• für wissensgefährdende Risiken
– Personelle
∗ Gründung einer Auffanggesellschaft
∗ Risikobewusste Personalauswahl
∗ Personalgarantieversicherung
– Sachlich-technische
∗ Verzicht auf Kodifizierung von Wissen
∗ Objekt-, Gebäude-, Raumsicherung
∗ Verschlüsselungstechniken
56

– Organisatorische
∗ Systematische Job-Rotation
∗ Alternierende Telearbeit
∗ Verankerung kritischen Wissens
– Marktbezogene
∗ Database-Marketing
∗ Lessons-Learned-Seminare
∗ Servicegarantien
• für wissensbasierte Risiken
– Kommunikation
∗ IP-Telephonie
∗ Diskussionsforen
∗ Unified messaging
– Zusammenarbeit
∗ Shared Spaces
∗ Gruppenunterstützende Systeme
∗ Wiki Webs
– Erstellen von Inhalten
∗ Autorensysteme
∗ Anreicherung von Dokumenten
∗ Expertise Profiling
– Content Management
∗ Versioning
∗ Klassifikation
∗ Retrieval
– Adaptierung
∗ Personalisierung
∗ Visualisierung
∗ Wissenslandkarten
– E-Learning
57

∗ Computerbasiertes Lernen
∗ Webbasiertes Lernen
∗ E-Learning
– Personelle Werkzeuge
∗ Organisation und Notizenführung
∗ Persönliche Datenbanken
∗ Integrierte Werkzeuge
– Künstliche Intelligenz
∗ Wissenspräsentation
∗ Expertensysteme und Fuzzy-Logic
∗ Automatisches Zusammenfassen
– Netzwerke
∗ Intranetze und Extranetze
∗ Verzeichnisservices
∗ E-Mail
4.6. Auswählen der geeignetsten Maßnahme
Nach der Entwicklung von passenden Steuerungsmaßnahmen ist die Auswahl der geeig-
netsten aus dieser Sammlung von Maßnahmen der nächste Schritt im Risikomanagement-
prozess. Kontio [Kon01] schlägt die fünf Kriterien Reihung der Risikoszenarien, Effizienz
der Steuerungsmaßnahmen, Verfügbarkeit von benötigten Ressourcen, Wichtigkeit für die
Stakeholder und Dringlichkeit der Umsetzung für die Auswahl der geeignetsten Maßnah-
me vor. Diese Kriterien werden nun im Weiteren genauer erklärt.
4.6.1. Reihung der Risikoszenarien
Ein entscheidender Punkt im Risikomanagement ist eine Bewertung der Risiken (vgl.
Kapitel 2.3.3). Im weiteren Durchlauf des Risikomanagementprozesses sollen die höher
bewerteten und somit gefährlicheren Risiken priorisiert werden. Übertragen auf die Maß-
nahmenplanung bedeutet dies, dass zuerst Maßnahmen für die höher bewerteten Risiken
entwickelt und angewendet werden sollen, die vorhandenen Ressourcen werden zunächst
für die Entschärfung genannter Risiken eingesetzt.
58

4.6.2. Effizienz der Steuerungsmaßnahmen
Der Fokusierung auf die großen Risiken ist ein sehr einfaches, und dennoch wirkungs-
volles Auswahlkriterium. Leider lässt es einige wichtige Punkte, wie die Effizienz der
Maßnahme oder eine mögliche Ressourcenbeschränkung unberücksichtigt. Mithilfe des
Risk-Reduction-Leverage Factors, erstmals von Boehm [Boe89] vorgeschlagen, lässt sich
die Effizienz einer Steuerungsmaßnahme messen.
RRL = Auswirkungen vor der Maßnahme − Auswirkungen nach der Maßnahme
Kosten für die Maßnahme
Der Risk-Reduction-Levarage Factor beschreibt die Verminderung der Risikoauswirkun-
gen im Vergleich zu den dafür benötigten Kosten. Je größer der RRL, desto kosteneffizi-
enter ist die Maßnahme. Werte unter 1 kosten somit mehr, als sie an Schaden in Zukunft
verhindern. Hillson [Hil99] schlägt als Daumenregel vor, dass Maßnahmen mit einen RRL
über 20 kosteneffiziente Maßnahmen sind. Mittels des RRL können auch unterschiedliche
Maßnahmen für ein Risiko unter dem Aspekt der Kosteneffizienz verglichen werden.
De Klerk [Kle01] erweitert den Risk-Reduction-Leverage Faktor unter Anwendung der
Utility Theory und schließt sich mit dieser Sichtweise des Nutzens Kontio [Kon01] an.
Eine ausführlichere Erklärung dieses Ansatzes würde leider den Rahmen dieser Arbeit
übersteigen.
4.6.3. Verfügbarkeit von benötigten Ressourcen
Das dritte von Kontio [Kon01] vorgeschlagene Kriterium sind Ressourcenbeschränkun-
gen. Diese Beschränkungen lassen sich beispielsweise auf ein festgesetztes Budget für das
Risikomanagement oder die Verfügbarkeit von Ressourcen und Fähigkeiten zurückführen.
Solche Beschränkungen können die Umsetzung einer guten Maßnahme leicht unmöglich
machen, und müssen deswegen bei der Auswahl der Maßnahme berücksichtigt werden.
4.6.4. Wichtigkeit für die Stakeholder
Die Wichtigkeit der einzelnen Stakeholder im Projekt und deren Ansichten beeinflussen
die Auswahl der adäquaten Maßnahme. Wenn die Stakeholder die Größe von Risiken
anders bewerten, haben sie wahrscheinlich auch unterschiedliche Vorlieben für die Um-
59

setzung von Steuerungsmaßnahmen. Die Stakeholder müssen nun feststellen, wo sie un-
terschiedliche Interessen besitzen und entweder verhandeln oder die Verantwortung bzw.
Kosten für die für sie wichtigen Maßnahmen übernehmen.
4.6.5. Dringlichkeit der Maßnahme
Die Dringlichkeit der Maßnahme ist das fünfte Kriterium von Kontio [Kon01]. Dieses
Kriterium kann die Auswahl der Steuerungsmaßnahme stark beeinflussen. Die Dringlich-
keit hängt einerseits vom Eintrittszeitpunkt des Risikos und andererseits vom zeitlichen
Aufwand der Umsetzung der Maßnahme ab.
4.7. Zusammenfassung
Der Prozess der Maßnahmenplanung kann in zwei Schritte unterteilt werden, erstens
die Entwicklung von passenden Maßnahmen für ein konkretes Risiko und zweitens die
Auswahl der für die aktuelle Situation geeignetsten aus dieser Sammlung.
Wissensgefährdende Risiken lassen sich sowohl mit Werkzeugen und Techniken aus dem
klassischen Risikomanagement als auch aus dem Wissensmanagement steuern. Die An-
sätze des klassischen Risikomanagements versuchen vermehrt die Eintrittswahrscheinlich-
keit, die aus dem Wissensmanagement die Auswirkungen zu vermindern. Die Maßnahmen
für die wissensbasierten Risiken stammen für beide Ansätze aus dem Wissensmanage-
ment.
Die Entwicklung von passenden Steuerungsmaßnahmen lässt sich mithilfe einer logischen
Verknüpfung beider Kataloge, jenem der generischen Wissensrisiken und dem der gene-
rischen Maßnahmen für diese Risiken unterstützen. Mit der Entwicklung des Katalogs
der generischen Maßnahmen in diesem Kapitel wurde eine Basis für die angesprochene
logische Verknüpfung geschaffen.
Die unterschiedlichen Maßnahmen lassen sich zunächst einfach aufgrund ihrer Strategie,
Vermeidung, Umverteilung, Minderung oder Akzeptanz von einander unterscheiden. Die
geeignetste Maßnahme lässt sich zusätzlich anhand der fünf Kriterien Reihung der Risiko-
szenarien, Effizienz der Steuerungsmaßnahmen, Verfügbarkeit von benötigten Ressourcen,
Wichtigkeit für die Stakeholder und Dringlichkeit der Umsetzung ermitteln.
60

5. RRP Modell
Mit diesem Kapitel beginnt der praktische Teil der
Arbeit. Der praktische Teil basiert auf den theore-
tischen Ausführungen der vorigen Kapitel. Haupt-
sächlich greift er auf die in Kapitel 3.8 und 4.5
entwickelten Kataloge an generischen Wissensrisi-
ken und generischen Maßnahmen für diese Wis-
sensrisiken zurück. Diese zwei Kataloge schaffen ei-
ne theoretische Grundlage für das in diesem Kapi-
tel entworfene Risk Response Planning Modell und
werden durch eine ebenfalls in diesem Kapitel ent-
wickelte Logik miteinander verbunden. Das ferti-
ge RRP Modell ist die Basis für den in Kapitel 6
konzeptierten und implementierten Prototyp. Dieser Prototyp soll die Erkenntnisse des
Modells in einer Software abbilden und den Projektmitarbeiter bei der Entwicklung von
passenden Steuerungsmaßnahmen für Wissensrisiken unterstützen.
Am Beginn dieses Kapitels wird der Zusammenhang zwischen dem Modell und dem
Knowledge@Risk Framework (vgl. Kapitel 1.2) dargestellt. Anschließend wird das Mo-
dell anhand einer Beschreibung der Funktion der generischen Risiken und Maßnahmen,
des Instanziierens und der Logik genauer erklärt und den zuvor bestimmten Anforde-
rungen gegenüber gestellt. Die Entwicklung der Logik, der Kern dieses Kapitels und des
Modells, wird anschließend beschrieben und ihre Anwendung durch ein Beispiel anschau-
lich erklärt.
61

5.1. Modell als Teil des Knowledge@Risk Framework
Um ein Verständnis der Rahmenbedingungen und der Anforderungen an das Modell
zu fördern, wird das Knowledge@Risk Framework an dieser Stelle kurz vorgestellt. Das
Knowledge@Risk Framework (siehe Abbildung 5.1) [Kol05] besteht aus einer konzeptiven,
Anwendungs- und Software Ebene. Im Anschluss werden diese drei Ebenen kurz erklärt
und besonders die Position des RRP Modells in ihnen dargestellt und von der restlichen
Framework abgegrenzt.
5.1.1. Konzeptive Ebene
Die konzeptive Ebene des Knowledge@Risk Frameworks dient als Basis für die ande-
ren zwei Ebenen. Sie beinhaltet detaillierte Definitionen von Begrifflichkeiten, eine Be-
schreibung der Eingliederung des Framework in bestehende Ansätze und ein Kategorisie-
rungsschema für Wissensrisiken. Die zentralen Elemente dieser Ebene sind einerseits eine
möglichst große Sammlung an abstrahierten, generischen Wissensrisiken und andererseits
eine Sammlung an möglichen Instrumenten und Maßnahmen zur Steuerung dieser Risi-
ken. Diesen Elementen entsprechen die in den Kapiteln 3.8 und 4.5 entwickelten Kataloge
an generischen Risiken und generischen Maßnahmen. Ein weiteres Element dieser Ebe-
ne ist die logische Verknüpfung (siehe Abbildung 5.1, [1]), die ebenfalls in dieser Arbeit
entwickelt und in Kapitel 5.3 im Detail beschrieben wird.
5.1.2. Anwendungsebene
Die Anwendungsebene beschreibt den Risikomanagementprozess des Knowledge@Risk
Frameworks. Zunächst wird eine Umfeldanalyse (siehe Abbildung 5.1, [2]) durchgeführt
um die kritischen Risikobereiche eines Projektes zu identifizieren. Anhand einer Detail-
analyse [3] werden fallspezifische von den generischen Wissensrisiken instanziiert und
im Detail beschrieben. Im nächsten Schritt werden diese identifizieren, spezifischen Risi-
ken bewertet [4]. Abschließend sollen geeignete Steuerungsmaßnahmen und -instrumente
für Wissensrisiken ausgewählt bzw. entwickelt werden [5]. Genau dieser Schritt der An-
wendungsebene wird im RRP Modell abgebildet. Hierfür wird die Funktionsweise des
Instanziierens der Framework in das Modell übernommen und in Abschnitt 5.2 näher
erläutert.
62

Abbildung 5.1.: Knowledge@Risk Framework (Quelle: [Kol05])
5.1.3. Software Ebene
Die dritte Ebene des Knowledge@Risk Frameworks soll die Anwendungsebene auf ein
Software-Tool abbilden und so ein geeignetes Werkzeug zum Verwalten und Steuern von
Wissensrisiken bieten. In Rahmen dieser Arbeit wurde ein Knowledge@Risk Prototyp
entwickelt, welcher speziell den Schritt zur Entwicklung von passenden Maßnahmen von
der Anwendungsebene auf die Software Ebene abbildet. Andere Teile der Framework,
wie die Risikoidentifikation und Bewertung, werden zunächst nur in einer Grundfunk-
tionalität im Prototyp umgesetzt und bedürfen weiteren theoretischen Untersuchungen
und Ausbaustufen. Die Konzeption und Implementierung des Prototyps wird in Kapitel
6 beschrieben.
5.2. Funktionsweise
Wie bereits in Kapitel 4 im Detail ausgeführt, besteht die erfolgreiche Steuerung von
Risiken aus zwei Schritten. Der erste Schritt ist die Planung von passenden Steuerungs-
maßnahmen. Aus dieser Sammlung von passenden Maßnahmen muss im zweiten Schritt,
die für das spezifische Risiko geeignetste Maßnahme ausgewählt werden. Das in diesem
Kapitel entwickelte Modell konzentriert sich auf den ersten Schritt und unterstützt den
63

Anwender bei der Entwicklung von passenden Steuerungsmaßnahmen.
Das RRP Modell (siehe Abbildung 5.2) besteht aus den Katalogen an generischen Risiken
und Maßnahmen, einer logischen Verknüpfung dieser zwei Kataloge [2] und der Möglich-
keit spezifische Risiken [1] und Maßnahmen [3] von den Katalogen zu instanziieren. Im
Folgendem werden diese Bestandteile des Modells detailliert beschrieben.
Abbildung 5.2.: Risk Response Planning Modell
5.2.1. Generische Wissensrisiken und Maßnahmen
Der Begriff generisch stammt aus dem Lateinischen und bedeutet das Geschlecht oder
die Gattung betreffend 1 . Er beschreibt den Grad der Allgemeingültigkeit einer Lösung
oder eines Ansatzes. Je generischer, desto vielfältiger ist die Lösung wiederverwendbar.
So sind generische Wissensrisiken abstrahierte, generelle Risiken die sich auf einen Man-
gel von Wissen und Fertigkeiten, welche für die Durchführung einer geschäftsrelevanten
Aktion notwendig sind, zurückführen lassen und abstrahierte, generelle Risiken, die das
Wissenskapital eines Projektes bedrohen (vgl. Definition Wissensrisiken, Kapitel 3.6).
Dementsprechend sind generische Maßnahmen, jene allgemeinen und abstrakten Instru-
1 Quelle: http://de.wikipedia.org/wiki/Generisch [abgerufen 12.09.2005]
64

mente und Techniken, welche sich auf die generischen Risiken anwenden lassen um diese
zu vermeiden, vermindern, umzuverteilen oder zu akzeptieren. Die generischen Wissensri-
siken wurden in Kapitel 3.8 und die Maßnahmen in Kapitel 4.5 jeweils zu einem Katalog
zusammengefasst. Ein Risikokatalog unterstützt die Identifikation von Risiken [HH02]
und durch eine Kategorisierung, dem Gruppieren von ähnlichen Risiken und Maßnah-
men, entstehen zusätzlich neue Erkenntnisse [FGRD02].
Die beiden Kataloge geben zunächst einen Überblick über mögliche Wissensrisiken, denen
ein Projekt ausgesetzt sein kann, und Maßnahmen mit denen diese Risiken gesteuert
werden könnten. Ihr Nutzen wird durch die logische Verknüpfung der beiden Kataloge
erweitert.
5.2.2. Instanziieren
Eine Instanz beschreibt in der Philosophie einen Einzelfall oder ein konkretes Beispiel für
eine abstrakte Idee, ein Prinzip oder einen Begriff und in der objektorientierten Program-
mierung eine Ausprägung eines Objektes 2 . Der Vorgang des Instanziierens (Abbildung
5.2, [1] und [3]), auch Ableiten genannt, ist für Risiken und Maßnahmen identisch, wird
aber im Folgendem für Risiken erklärt. In Zusammenhang mit dem Modell beschreibt der
Vorgang des Instanziierens die Entwicklung eines fallspezifischen Risikos auf Basis eines
generischen. Diese beim Instanziieren entstehende Verbindung zwischen generischen und
instanziierten Risiko bleibt über die weiteren Schritte des Risikomanagementprozesses
bestehen.
Das instanziierte, fallspezifische Risiko wird durch die von Moser [Mos04] entwickelten
Beschreibungselemente für Wissensrisiken charakterisiert. Unter ihnen befinden sich Ele-
mente wie Titel, Beschreibung, Risiko-Verantwortlicher oder die vom Risiko betroffenen
Arbeitspakete. Ein instanziiertes Risiko ist immer genau mit einem generischen Risiko
verbunden. Aber von einem generischen Risiko lassen sich mehrere unterschiedliche, fall-
spezifische Risiken ableiten.
Fallspezifische Risiken sind Risiken, die durch eine spezielle Schadensanfälligkeit eines
Projektes entstehen [LFTR03]. So sind die abgeleiteten Wissensrisiken nicht länger all-
gemein und abstrakt, wie die generischen, sondern konkret und durch ein bestimmtes
Projekt und dessen Umfeld bestimmt.
2 Quelle: http://de.wikipedia.org/wiki/Instanz [abgerufen 12.09.2005]
65

5.2.3. Logische Verknüpfung
Die zwei generischen Kataloge werden durch eine Logik (Abbildung 5.2, [2]) verbunden,
welche im folgenden Abschnitt 5.3 entworfen und im Detail erklärt werden. An dieser
Stelle wird vor allem die Bedeutung der Logik für das RRP Modell geschildert.
Durch die logische Verknüpfung der beiden generischen Kataloge wird die Entwicklung
von passenden Steuerungsmaßnahmen unterstützt, da mit ihr von fallspezifischen, instan-
ziierten Risiken auf passende generische Steuerungsmaßnahmen geschlossen werden kann.
Diese geeigneten generischen Maßnahmen werden dem Anwender zur Steuerung des Risi-
kos vorgeschlagen. Wählt der Anwender eine generische Maßnahme aus und instanziiert
eine fallspezifische davon, ist diese fest mit dem fallspezifischen Risiko, für welches die
Maßnahme entwickelt wurde, verbunden.
5.3. Logik
Das Ziel des Modells ist eine dem Anwender unterstützende Entwicklung von geeigne-
ten Steuerungsmaßnahmen. Hierzu würde das Modell im idealen Fall dem Benutzer die
geeignetste Steuerungsmaßnahme für das von ihm erfasste Wissensrisiko vorschlagen.
Aufgrund der bis dato geringen Anzahl an wissenschaftlichen Arbeiten aus dem Bereich
Wissensrisikomanagement (vgl. Kapitel 3) und Untersuchungen über Wissensrisiken und
der Wirksamkeit und Eignung von Steuerungsmaßnahmen, ist der Vorschlag einer idea-
len Maßnahme nicht möglich. Stattdessen möchte das RRP Modell dem Benutzer eine
Auswahl an geeigneten und empfohlenen Maßnahmen zur Steuerung eines fallspezifischen
Wissensrisikos unterbreiten.
Hierzu wird vom Autor eine die beiden generischen Kataloge (vgl. Kapitel 3.8 und 4.5)
verbindende Logik entwickelt. Ihre Aufgabe besteht darin, die generischen Wissensrisiken
mit geeigneten Steuerungsmaßnahmen zu verbinden. Um diese logische Verbindung zu
entwickeln stellt der Autor den Katalog an generischen Risiken jenen generischen Maß-
nahmen aus dem Katalog in einer Matrix gegenüber. Anschließend wird die Eignung
der jeweiligen Maßnahme für ein spezifisches Risiko vom Autor bewertet und somit die
Verbindung zwischen generischen Risiken und geeigneten Maßnahmen hergestellt. Ab-
bildung 5.3 zeigt einen Ausschnitt aus der Matrix und eine vollständige Darstellung der
Matrix mitsamt Bewertungen befindet sich in Anhang C.
66

Abbildung 5.3.: Ausschnitt aus der Logik
Die Logik und das darin verwendete Bewertungsschema stellt den Kern des Modells
dar. Die Vorgangsweise bei der Bewertung wird anschließend genauer erklärt. Dafür wird
das Beispiel des sachlich-technischen Wissensrisikos Unfreiwillige Wissensdiffusion (siehe
Tabelle 5.1) aus Kapitel 4.3.2 wieder aufgegriffen und an dieser Stellung zur Erklärung
der Bewertung verwendet.
5.3.1. Bewertung
Die Bewertung der Eignung der einzelnen generischen Maßnahmen für spezielle generische
Risiken wurde vom Autor anhand einer dreistufigen Skala durchgeführt. Die Skala besteht
aus den drei Stufen:
• nicht geeignet
• geeignet
• sehr geeignet
67

Nicht geeignet
Generische Maßnahmen, deren Anwendung zur Steuerung von einem bestimmten generi-
schen Risiko nicht sinnvoll sind, werden vom Autor für dieses generische Risiko mit dem
Attribut nicht geeignet versehen. Beispielsweise lässt sich das generische Risiko Wis-
sensdiffusion nicht mit der generischen Maßnahme offene Gebäudearrangements weder
vermeiden, vermindern noch auf einen Dritten umverteilen. Darum wird sie vom Autor
in diesem Fall mit dem Attribut nicht geeignet bewertet.
Geeignet
Der Autor weist generischen Maßnahmen, deren Anwendung zur Steuerung eines be-
stimmten generischen Risikos unter Umständen sinnvoll ist, das Attribut geeignet zu.
Das bereits oben erwähnte Beispiel der Wissensdiffusion kann möglicherweise mit der
generischen Maßnahme der Identifikationstoken vermindert werden.
Identifikationstoken ermöglichen eine Bestimmung all jener Personen, die zu gewissen
Räumen bzw. Informationen und Daten Zugangs- bzw. Zugriffsrechte besitzen. Dadurch
kann die Anzahl der Personen mit Zugang zu bestimmten Wissen eingeschränkt und
somit auch die Eintrittswahrscheinlichkeit von unfreiwilliger Wissensdiffusion gesenkt
werden.
Sehr geeignet
Generische Maßnahmen, welche der Autor als besonders geeignet zum Steuern von spe-
ziellen generischen Wissensrisiken einstuft, werden für dieses generische Risiko mit dem
Attribut sehr geeignet versehen. Maßnahmen mit dieser Bewertung werden vom Autor
zur Steuerung des jeweiligen Risiko empfohlen. So kann die Eintrittswahrscheinlichkeit
des generischen Wissensrisikos der Wissensdiffusion mit der generischen Steuerungsmaß-
nahme Verschlüsselungstechniken erfolgreich vermindert werden.
Eine Anwendung der Maßnahme Verschlüsselungstechniken würde, wie in Kapitel 4.3.2
bereits erwähnt, die unabsichtliche Weitergabe von Wissen durch E-Mails vermindern.
Verschlüsseln alle Projektmitarbeiter ihre elektronischen Nachrichten, können diese zwar
von der Konkurrenz empfangen werden, aber das in ihnen kodifizierte Wissen bleibt durch
die Verschlüsselung vor unbefugten Zugriff geschützt.
68

5.4. Beispiel
Bereits in Abschnitt 5.3 dieses Kapitels wurde das Beispiel des sachlich technischen Wis-
sensrisikos Unfreiwillige Wissensdiffusion (siehe Tabelle 5.1) verwendet. An dieser Stel-
le wird dieses Beispiel wieder aufgegriffen und die einzelnen Schritte des Modells, von
der Identifikation eines fallspezifischen Risikos bis hin zur Beschreibung einer geeigneten
Maßnahme für dieses Risiko, anschaulich erklärt.
Titel Unfreiwillige Wissensdiffusion
Kategorie Sachlich-Technisch
Beschreibung Ein Projekt profitiert einerseits von den technischen
Möglichkeiten eines projektweiten Wissenstransfers
andererseits ist es einem erhöhten technischen
Wissensrisiko ausgesetzt. Internet, Shared Databases,
Expertensysteme und andere Technologien erlauben
einen schnelleren und zuverlässigeren Zugriff auf
Wissen. Dadurch wird allerdings die Möglichkeit der
unfreiwilligen Wissensdiffusion vergrößert. Diffundiert
strategisches Wissen unfreiwillig kann dadurch das
ganze Projekt gefährdet sein.
Tabelle 5.1.: Generisches Wissensrisiko: Unfreiwillige Wissensdiffusion
5.4.1. Risikoidentifikation
Der erste Schritt im Modell ist die Identifikation eines neuen Risikos. Wird ein neues
Risiko identifiziert, muss es von einem generischen Risiko abgeleitet werden. Der Katalog
an generischen Wissensrisiken unterstützt einerseits den Anwender bei der Identifikation
eines neuen Risikos indem er allgemeine Beispiele von Risiken, welche das Projekt ge-
fährden könnten, auflistet. Andererseits ist er die Grundlage für das Instanziieren von
Risiken. Wird beispielsweise erkannt, dass das Projekt vom Risiko des Ungewollten Wis-
sensabflusses durch Kooperation an die Konkurrenz (siehe Tabelle 5.2) betroffen ist, wird
der Katalog nach einem passenden generischen Risiko durchsucht. Ist das passende ge-
nerische Risiko gefunden, wird das fallspezifische von ihm abgeleitet.
69

Generisches Risiko Unfreiwillige Wissensdiffusion
Titel Ungewollter Wissensabfluss durch Kooperation an die
Konkurrenz
Verantwortlicher Heiner Rumpler
Beeinflusste Arbeitspa- Produktentwicklung, Planung der Verkaufsstrategie
kete
Beschreibung Durch die Kooperation mit der Firma Unternehmens
Consulting kann es möglicherweise zu einem ungewollten
Wissensabfluss an die Konkurrenz kommen, da diese
Firma auch mit dem größten Konkurrenten eine Geschäftsbeziehung
pflegt. So können beispielsweise E-
Mails, die an uns gesendet werden, unabsichtlich an
diese Firmen fließen.
Tabelle 5.2.: Instanziiertes Wissensrisiko: Ungewollter Wissensabfluss
5.4.2. Vorschlag an geeigneten Steuerungsmaßnahmen
Wurde ein fallspezifisches Risiko von einem generischen instanziiert, lassen sich im zwei-
ten Schritt Rückschlüsse auf geeignete Maßnahmen zur Steuerung dieses Risikos ziehen.
Der Rückschluss basiert auf der in Kapitel 5.3 entwickelten Logik, welche die beiden
generischen Kataloge miteinander verbindet. Durch die Anwendung der Logik in diesem
Beispiel, werden dem Benutzer folgende generische Maßnahmen zur Steuerung des Risi-
kos vorgeschlagen. Vom Autor empfohlene und mit sehr geeignet bewertete Maßnahmen
werden mit (!) hervorgehoben:
• Verzicht auf Kodifizierung von Wissen (!)
• Objekt-, Gebäude-, Raumsicherung (!)
• elektronisch gesicherte Schränke (!)
• Schlösser (!)
• Tastatur- und Festplattenverriegelungen (!)
• Gehäuseverplombungen (!)
• Internet-Firewalls (!)
• Verschlüsselungstechniken (!)
70

• digitale Unterschriften (!)
• Schutzmaßnahmen für digitale Kommunikationsanlagen (!)
• Anwenderschulungen (!)
• IT-Sicherheitsverantwortlicher (!)
• Diebstahl-, Feuer u.ä. Versicherungen (!)
• Passwörter (!)
• Zweischlüsselverfahren
• Kartenlesesysteme
• Identifikationstoken
Nach Durchsicht der vorgeschlagenen generischen Maßnahmen, entscheidet sich der An-
wender für die Steuerung durch Verschlüsselungstechniken (siehe Tabelle 5.3). Diese Maß-
nahme entspricht dem Umfang und mit der Strategie Vermeidung seinen Vorstellungen
der Steuerung für das Wissensrisiko Ungewollten Wissensabflusses durch Kooperation an
die Konkurrenz. Andere Kriterien für die Auswahl der geeignetsten Maßnahme wären ei-
ne Reihung der Risikoszenarien, Effizienz der Steuerungsmaßnahmen, Verfügbarkeit von
benötigten Ressourcen, Wichtigkeit für die Stakeholder und Dringlichkeit der Umsetzung
(siehe Kapitel 4.6).
Generisches Risiko Unabsichtlicher Wissenstransfer an die Konkurrenz
Titel Verschlüsselungstechniken
Kategorie Sachlich-Technisch
Strategie Vermeidung
Beschreibung Mit modernen Verschlüsselungstechniken (Kryptologie)
kann sichergestellt werden, dass eine Nachricht
lediglich vom gewünschten Adressaten gelesen werden
kann. Digitale Unterschriften dienen außerdem als
elektronisches Äquivalent zur manuellen Unterschrift.
Tabelle 5.3.: Generische Maßnahme: Verschlüsselungstechniken
5.4.3. Beschreiben der fallspezifschen Maßnahme
Entscheidet sich der Anwender für die Verwendung der generischen Maßnahme Verschlüs-
selungstechniken, leitet er eine fallspezifische Maßnahme von dieser generischen ab. Das
71

Ableiten geschieht, wie in Abschnitt 5.2.2 erklärt, durch eine ausführliche Beschreibung
der Maßnahme. Typische Beschreibungselemente (siehe Tabelle 5.4) sind Titel, verant-
wortliche Person und eine schriftliche Beschreibung der Maßnahme. In diesem Fall leitet
der Anwender die fallspezifische Maßnahme Verschlüsselungssoftware PGP im Projekt
verwenden (siehe Tabelle 5.4) ab.
Generische Maßnahme Verschlüsselungstechniken
Titel Verschlüsselungssoftware PGP im Projekt verwenden
Verantwortlicher Heiner Rumpler
Beschreibung PGP (Pretty Good Privacy) ist ein Programm zur Verschlüsselung
von Daten. Es benutzt das sogenannte
Public Key-Verfahren, d.h. es gibt ein eindeutig zugeordnetes
Schlüsselpaar: Nachrichten an einen Empfänger
werden mit seinem öffentlichen Schlüssel codiert
und können dann nur durch den privaten Schlüssel des
Empfängers geöffnet werden. In die Mailprogramme
aller Projektmitarbeiter soll ein PGP Plug-In installiert
und die Mitarbeiter im Umgang mit dem Programm
geschult werden. Ab dem Arbeitspaket 3 sollen
dann alle Mitarbeiter nur mehr verschlüsselt miteinander
kommunizieren.
Tabelle 5.4.: Instanziierte Maßnahme: PGP im Projekt verwenden
5.5. Zusammenfassung
In diesem Kapitel wurde zunächst das Modell in das Knowledge@Risk Framework ein-
gebettet. Die beiden Kataloge an generischen Wissensrisiken und Maßnahmen und die
Logik entsprechen der konzeptiven Ebene und die Funktion des Instanziierens und da-
durch geschaffene fallspezifische, abgeleitete Risiken und Maßnahmen sind Teil der An-
wendungsebene des Framework.
Anschließend wurden der Aufbau des Modells mit einer Beschreibung der Aufgaben der
generischen Risiken und Maßnahmen und die Funktionsweise mit einer Beschreibung
des Instanziierens und der Logik näher erläutert. Die Entwicklung der Logik durch den
Autor und das ihr zugrunde liegende Bewertungsschema bildete den nächsten Abschnitt
des Kapitels.
72

Abschließend wurde das Modell anhand einer beispielhaften Entwicklung einer geeigneten
Steuerungsmaßnahme für das spezifische Wissensrisiko Ungewollter Wissensabfluss durch
Kooperation an die Konkurrenz anschaulich beschrieben.
73

6. Knowledge@Risk Prototyp
Aufbauend auf den theoretischen Ausführungen
über das klassische Risikomanagement, Wissens-
risiken, Steuerungsmaßnahmen und dem Entwurf
des Risk Response Planning Modells zur Entwick-
lung von passenden Maßnahmen wurde ein Soft-
wareprototyp entworfen und implementiert. Die-
ser im Weiteren mit Knowledge@Risk Prototyp be-
zeichnete Prototyp bildet in erster Linie die Ideen
und Konzepte des Risk Response Planning Modells
(vgl. Kapitel 5) in einer Softwareanwendung ab
und schafft zusätzlich ein Grundgerüst für die Im-
plementierung des gesamten Knowlegde@Risk Fra-
meworks (vgl. Kapitel 5.1). Insbesondere unterstützt der Prototyp die Entwicklung von
passenden Steuerungsmaßnahmen.
In diesem Kapitel werden zunächst die Zielsetzungen für den Prototyp erklärt und die für
das Konzept und die Implementierung notwendigen technischen Entscheidungen getrof-
fen und begründet. Mittels dem Goal Oriented Interaction Design werden anschließend
die Anforderungen der Benutzer an den Prototyp untersucht und anhand der Ergebnisse
unterschiedliche Rollen, ein Funktionsablauf, ein Navigationskonzept, ein Klassendesign
und eine Datenbankstruktur entwickelt und realisiert. Abschließend werden die zentra-
len technischen Komponenten der Anwendung, TreeView und DataGrid, mithilfe von
Anwendungsfällen erklärt.
74

6.1. Zielsetzung
Das Ziel des praktischen Teils dieser Arbeit war die auf dem in Kapitel 5 entworfe-
nen RRP Modell aufbauende Entwicklung eines Softwareprototyps zur Handhabung und
Steuerung von Wissensrisiken. Die Applikation sollte hierbei folgende Hauptfunktionen
in ihrer ersten Entwicklungsphase ermöglichen:
• Authentifikation der Benutzer
• Erfassen von neuen Risiken
• Bewertung von Risiken
• Entwicklung von passenden Maßnahmen
• Suche nach Risiken
• Betrachtung von Risiko- und Maßnahmenkatalog
Die Applikation bildet kein am Markt befindliches herkömmliches Risikomanagement-
Tool, wie das MIS Risk Management des deutschen Unternehmens MIS AG 1 , Welcom
Risk der amerikanischen Firma Welcom 2 oder RiskTrak von Risk Services & Technology 3 ,
nach. Vielmehr besitzt der Prototyp durch die Unterstützung bei der Entwicklung der
Maßnahme einen speziellen Nutzen für den Anwender.
Von so genannten wissenschaftlichen Prototypen, wie dem Riskplan Tool [LFTR03], dem
von der NASA entwickelten SIRTF Tool [FGRD02] oder dem RiskCheck! [GPW97],
welche unter anderem versuchen, den Benutzer bei der Identifikation zu unterstützen,
grenzt sich der Knowledge@Risk Prototyp insbesondere durch seine spezielle Ausrichtung
auf Wissensrisiken ab.
1 http://www.misag.com/ca/kl/zom/ [abgerufen 16.09.2005]
2 http://www.welcom.com/ [abgerufen 16.09.2005]
3 http://www.risktrak.com/ [abgerufen 16.09.2005]
75

6.2. Technische Entscheidungen
Im Vorfeld und während der Konzeption des Prototyps wurden einige technische Ent-
scheidungen getroffen. In diesem Abschnitt werden die verschiedenen Möglichkeiten der
Implementierung aufgezählt und die Wahl der technischen Umsetzung kurz begründet.
6.2.1. Webapplikation
Grundsätzlich standen die beiden Möglichkeiten der Implementierung einer klassischen
Computeranwendung und einer Webapplikation zur Wahl. Schmiderer zählt in seiner
Arbeit [Sch03] folgende acht Vorteile einer Webapplikation gegenüber einer klassischen
Computeranwendung auf:
• Universelle Verfügbarkeit
• Plattformunabhängigkeit
• Geringe Anforderungen an den Client
• Geringer Installations- und Wartungsaufwand beim Client
• Skalierbarkeit
• Einheitliche Standards
• Einfache Entwicklung
• Kosten
Die von Schmiderer [Sch03] ebenfalls genannten Nachteile, wie eine eingeschränkte Be-
nutzerschnittstelle und die geringe Geschwindigkeit, werden durch die oben aufgezählten
Vorteile aus der Sicht der Anforderungen des Knowledge@Risk Prototyps mehr als auf-
gewogen. Vor allem die Eigenschaften der universellen Verfügbarkeit und des geringen
Installations- und Wartungsaufwandes beim Client sind von großer Bedeutung und er-
möglichen eine einfache und schnelle Erfassung und Verwaltung von Wissensrisiken.
76

6.2.2. ASP.NET
Für die Entwicklung einer Webapplikation existieren verschiedenste Werkzeuge. Scheir
schafft in seiner Arbeit [Sch02] einen umfassenden Überblick über diese Werkzeuge und
zählt zusätzlich Vor- und Nachteile auf. Für die Implementierung des Knowledge@Risk
Prototyps fiel die Wahl auf ASP.NET. Diese serverseitige Technologie zum Aufbau von
Webapplikationen basiert auf der Embedded Code Methode (siehe Abbildung 6.1) und
verfügt über eine zu anderen Technologien verbesserte Handhabbarkeit, weil es durch
das Code-Behind-Model zu keiner Vermischung von Layout und Code kommt.
Abbildung 6.1.: Dynamische Generierung von Webinhalten mittels Embedded Code
Auch wegen der von ASP.NET zur Verfügung gestellten Werkzeuge, wie DataGrid (vgl.
Kapitel 6.10), TreeView (vgl. Kapitel 6.9) und anderen Webcontrols und der guten Per-
formance bei Webapplikationen in der Größenordnung des Knowledge@Risk Prototyps
wurde die Webapplikation mit ASP.NET entwickelt. Als Programmiersprache, wurde die
eigens für ASP.NET von Microsoft entwickelte Sprache C#, eine Erweiterung von Java,
verwendet.
6.2.3. Datenbank
Für die Realisierung der Datenbank fiel die Entscheidung auf eine Microsoft Access Da-
tenbank, worauf über eine Open DataBase Connection (ODBC) mittels Standard Query
Language (SQL) Abfragen zugegriffen wird. Die Verwendung von Microsoft Access ist in
der benutzerfreundlichen Entwicklung von Datenbanken begründet und der Einsatz der
ODBC-Schnittstelle kombiniert mit der Abfragesprache SQL ermöglicht eine unkompli-
zierte, nachträgliche Änderung des Datenbanksystems.
77

6.2.4. Layout
Um das Veröffentlichen und Betreuen der HTML Seiten des Prototyps [Nie00] einfach
zu gestalten wurden Formatierungen, wie Schriften, Abstände, Rahmen, Hintergrundfar-
ben und Positionierungen anhand der deklarativen Stylesheet-Sprache Cascading Style
Sheets (CSS) in einem Dokument für die komplette Webapplikation definiert. Soll nun
die Farbe aller Seitenüberschriften geändert werden, reicht die Änderung eines Eintrages
in der Stylesheet-Datei aus, um diese dann für alle Seiten der Applikation automatisch
zu übernehmen.
6.3. Goal Oriented Interaction Design
Goal Oriented Interaction Design ist eine auf den Zielen der Benutzer aufbauende Software-
Designmethodik. Im Gegensatz zum traditionellen Interface-Design, welches eine Schnitt-
stelle zwischen dem Code auf der einen Seite und dem Benutzer auf der anderen Seite,
sowie dem Übermitteln von Nachrichten zwischen ihnen vorschlägt, steht beim Interacti-
on Design eine auf den Benutzer abgestimmte Entwicklung von Software oder Produkten
im Vordergrund [Kei05]. Dadurch wird verhindert, dass Programmierer beim Schreiben
des Codes den Benutzer und dessen Ziele aus den Augen verlieren.
Der Interaction Design Prozess setzt sich aus folgenden Schritten zusammen:
• Interview mit Benutzern
• Gestalten von Personas
• Definieren ihrer Goals
• Schaffen von konkreten Szenarien
• Entwerfen einer Designlösung
Bei der Entwicklung des Knowledge@Risk Prototyps wurde auf Benutzerinterviews ver-
zichtet, da die Thematik der Wissensrisiken in Unternehmen noch kaum verbreitet ist,
und somit die Interviews nicht zu neuen Erkenntnissen geführt hätten. Aus diesem Grund
wurde mit der Definition von Personas begonnen.
78

6.3.1. Personas
Einer der ersten Schritte im Interaction Design Prozess ist das Erstellen von Personas.
Personas sind keine echten Menschen, aber sie repräsentieren diese während des gesamten
Design-Prozesses [Coo99]. Obwohl Personas frei erfunden sind, werden sie sehr detailliert
beschrieben und wie ein Rollenspielcharakter beim Designprozess eingesetzt. Dadurch
können die Bedürfnisse der zukünftigen Benutzer besser erkannt werden.
Eine gut definierte Persona ist nicht durchschnittlich, sondern typisch und glaubwürdig.
Ihre Beschreibung beinhaltet einen Namen, ein Bild und persönliche Eigenschaften. Mit
deren Hilfe können die Designer die Bedürfnisse der Personas besser erkennen und unter
anderem auch leichter argumentieren, ob eine Persona gewisse Funktionen und Optionen
der Anwendung benötigt oder nicht.
Es gilt also den typischsten Anwender für den Prototyp zu finden. Dafür werden zu-
nächst für die praktische Anwendung des Prototyps typische Benutzer gesammelt. Für
den Knowledge@Risk Prototyp wurden in diesem Schritt folgende Personas identifiziert:
• Erfahrener Projektmanager mit geringen Kenntnissen über Wissensrisiken
• Unerfahrener Projektmanager mit geringen Kenntnissen über Wissensrisiken
• Erfahrener Wissensmanager mit wenig Erfahrung im Risikomanagement
• Risikomanager
• Vorstandsmitglied
• Projektmitarbeiter
• Systemadministrator
Nach der Identifikation von Personas, werden ähnliche Personas kombiniert und redun-
dante verworfen. Im Speziellen werden primäre und sekundäre Personas gesucht. Wo-
bei eine primäre Persona der typischste Anwender für den Prototyp ist und sich nicht
mit dem Design für eine andere Persona zufrieden stellen lässt [Kei05]. Im Fall des
Knowledge@Risk Prototyps waren dies eindeutig der erfahrene Projektmanager und der
Systemadministrator. Weil ihre Bedürfnisse sehr unterschiedlich sind, musste der Design-
Prozess für diese Personas einzeln durchgeführt werden.
79

Im ersten Schritt wurde dies für den erfahrenen Projektmanager realisiert, dessen Persona
an dieser Stelle detaillierter beschrieben wird. Zu dieser primären passt die sekundäre
Persona des unerfahrenen Projektmanagers, dessen Charakter ebenfalls Einflüsse auf den
Design-Prozess hatte. Eine genaue Beschreibung dieser Persona befindet sich in Anhang
D.2.
Primäre Persona: Heiner Rumpler
Abbildung 6.2.: Primäre Persona: Heiner Rumpler
Erfahrener Projektmanager mit geringen Kenntnissen über Wissensrisiken
Heiner Rumpler ist 50 Jahre alt, verheiratet und hat eine Tochter. Er schloss das Studi-
um der Informatik erfolgreich ab und ist nun seit 15 Jahren in der IT-Firma Metapicture
beschäftigt. Vor rund 10 Jahren wurde er zum Projektmanager befördert und übt diese
Funktion seit damals ununterbrochen aus. Er verwendet den Computer täglich, haupt-
sächlich die Microsoft Office Produkte.
In den 10 Jahren als Projektmanager konnte er schon einige Erfahrung auf dem Gebiet
des Risikomanagements sammeln. Bei Metapicture gehört Risikomanagement seit eini-
ger Zeit zum erfolgreichen Projektmanagement und so besuchte Heiner Rumpler unter
anderem auch einige Seminare zu diesem Thema. Er verfügt somit über theoretische
Kenntnisse über das Risikomanagement. Allerdings baut er das Risikomanagement im
Projektalltag mehr auf seinen bisherigen Erfahrungen und Erkenntnissen im Umgang mit
Risiken als auf der Theorie auf. Beginnt er ein neues Projekt, weiß er ungefähr welche Ri-
siken im Projekt entstehen könnten und wie er mit ihnen umgeht. Beispielsweise musste
er schon oft Notfallpläne entwickeln und durchführen, wenn sich ein Risiko zum Problem
materialisierte. Wissen dieser Art hilft ihm im alltäglichen Risikomanagement weiter. Er
80

fühlt sich sicher und verzichtet darauf, Risiken zu dokumentieren oder vorausschauend
Maßnahmen für ihr mögliches Eintreten zu planen.
Mit Wissensmanagement hatte Heiner Rumpler bisher noch wenig Kontakt. Seine Vorge-
setzten entdeckten, dass sie als IT-Unternehmen durch Wissensrisiken besonders betrof-
fen sind, und gerne eine Softwareanwendung zum Verwalten und Steuern dieser Risiken
einsetzen würden. Deswegen hat Heiner Rumpler ein Seminar zum Thema Wissenska-
pital und dessen möglichen Verlust besucht. Seitdem sieht er das Thema als bedeutend
an, besonders weil er dadurch erkannte, wie oft ihm bereits Wissenskapital durch den
Abgang eines Mitarbeiters verloren ging und sich Projekte dadurch zeitlich verzögerten.
Dennoch möchte er nicht zuviel Zeit mit der Erfassung und Handhabung der Risiken
verbringen. Er möchte nicht gezwungen sein, sich durch viele Fenster zu klicken, wenn
er genau weiß, wie das Risiko aussieht und wie er es behandeln möchte. Er möchte sich
nicht lange mit Risiken beschäftigen, die kaum gefährdend auf das Projekt wirken. Das
Bewertungsschema und der Risikomanagementprozess sollten dem des ursprünglichen Ri-
sikomanagements ähnlich sein. Allerdings braucht er Unterstützung bei der Identifikation,
der Bewertung von Risiken und der Entwicklung von passenden Steuerungsmaßnahmen.
Die Behandlung der Wissensrisiken soll im selben Softwaresystem erfolgen, wie die der
klassischen Risiken.
6.3.2. Goals
Personas sind durch ihre Goals - Ziele - bestimmt [Coo99]. Diese Ziele unterscheiden
sich eindeutig von Tasks - Tätigkeiten. Ein Ziel ist eine Endbedingung, während eine Tä-
tigkeit ein dazwischenliegender Vorgang zur Erreichung dieser Endbedingung ist. Recht
einfach lassen sich die beiden Begriffe dadurch unterscheiden, dass Tätigkeiten sich mit
der verwendeten Technologie ändern und Ziele nicht. Ist das Ziel von Wien nach Paris
zu reisen, kann dies mit der Tätigkeit Autofahren oder Fliegen erreicht werden.
Das zentrale Ziel von Heiner Rumpler ist die effiziente und erfolgreiche Handhabung von
Wissensrisiken. Dazu ist es notwendig, dass er schnell einen Überblick über die wich-
tigsten Risiken im Projekt bekommt. Außerdem ist es für ihn wichtig, dass er über die
Risiken, für die er verantwortlich ist (siehe Abschnitt 6.4.3), bestens informiert ist. Eine
Aufstellung über die noch durchzuführenden Tätigkeiten zur Erreichung des Ziels einer
effizienten und erfolgreichen Handhabung von Wissensrisiken und eine Unterstützung bei
der Entwicklung von passenden Steuerungsmaßnahmen sind ihm zusätzlich hilfreich.
81

6.3.3. Szenarien
In einem Szenario wird eine menschliche Tätigkeit durch eine Geschichte beschrieben.
Diese Beschreibung erlaubt die Untersuchung und die Diskussion über Zusammenhänge,
Bedürfnisse und Anforderungen einer Softwareanwendung [PRS02]. Der Umgang mit die-
ser Software, oder benötigte technische Unterstützung, welche zur Durchführung dieser
Tätigkeiten notwendig sind, werden in einer Szenariobeschreibung nicht explizit ange-
führt. Die Beschreibung eines Szenarios erfolgt in ganzen Sätzen und mit dem Vokabular
des Anwenders. Solche Szenarien ermöglichen die Kommunikation zwischen dem Design-
Team und den Stakeholdern und dadurch lassen sich erste Anforderungen an die An-
wendung festlegen. Eine Entwicklung von Szenarien verhilft somit zu einer vollständigen
Integration der Stakeholder in den Entwicklungsprozess der Anwendung.
Cooper [Coo99] unterscheidet zwischen daily use, necessary use und edge case scenarios.
Bei der Entwicklung eines Prototyps sollen hierbei die daily use scenarios priorisiert
werden. Ein Beispiel eines solchen daily use scenarios, welches für die Konzeption des
Prototyps verwendet wurde, wird an dieser Stelle angeführt.
Daily Use Scenario: Entwickeln einer Steuerungsmaßnahme
Ein Projektmanager betrachtet seine noch offenen Tätigkeiten. Tätigkeiten die er durch-
führen sollte, um seine Wissensrisiken erfolgreich zu steuern. Er erkennt, dass das Risiko
des Ungewollten Wissensabflusses durch Kooperation an die Konkurrenz zwar bereits
identifiziert und für das Projekt bewertet, aber noch keine Maßnahme zur Steuerung
dieses Risikos entwickelt wurde.
Da dies eines der zentralsten Risiken im Projekt, und er dafür verantwortlich ist, möch-
te Heiner Rumpler nun eine passende Steuerungsmaßnahme entwickeln. Die Anwendung
zeigt ihm allgemeine, abstrahierte Maßnahmen passend zu diesem Wissensrisiko an. Nach
einer Betrachtung dieser möglichen Maßnahmen, und der bereits in der Vergangenheit
von ihnen abgeleiteten spezifischen Maßnahmen, entscheidet er sich für die Verminde-
rungsmaßnahme Verschlüsselungstechniken. In weiterer Folge leitet er die spezifische
Maßnahme Verschlüsselungssoftware PGP im Projekt verwenden von der allgemeinen
ab und beschreibt diese im Detail.
82

6.3.4. Use Cases
Ein Use Case ist eine Sammlung an möglichen Abläufen von Interaktionen zwischen dem
jeweiligen System und ihren externen Benutzern. Die Abläufe werden hierbei speziell
unter dem Aspekt der Ziele der Benutzer betrachtet [Coc95].
Ausgehend von den vorherigen Ausführungen wurden zehn Use Cases definiert. Diese
zehn Use Cases decken einerseits die Anforderungen (siehe Kapitel 6.1) an den Prototyp
und die dafür notwendige Funktionalität vollständig ab. Andererseits beschreiben sie alle
durch die Goals (siehe Kapitel 6.3.2) der Personas auftretenden Anwendungsfälle. So
führt das Ziel der primären Persona schnell einen Überblick über die wichtigsten Risiken
zu bekommen zum Use Case „Ansicht der TOP 10 Wissensrisiken“ (siehe Tabelle E.9).
Folgende zehn Use Cases wurden identifiziert:
1. Create new project - Eröffnen eines neuen Projektes
2. Create new risk - Eingabe eines neuen Wissensrisikos
3. Analyse risk - Bewerten eines Wissensrisikos
4. Create new action - Erfassen einer neuen Maßnahme für ein Wissensrisiko
5. Show my risks - Ansicht der persönlichen Wissensrisiken
6. Risk reporting - Über die Veränderung eines Risikos berichten
7. Show all risks - Ansicht aller Risiken
8. Show top 10 risks - Ansicht der TOP 10 Wissensrisiken
9. Search for risks - Suche nach Wissensrisiken
10. Show my tasks - Ansicht der persönlichen Aufgaben
Exemplarisch wird der Use Case Erfassen einer Maßnahme für ein Wissensrisiko in
Tabelle 6.1 im Detail beschrieben. Eine detaillierte Beschreibung der restlichen Use Cases
befindet sich in Anhang E.
Der Aufbau der Tabelle lehnt sich an die Vorlage von Cockburn [Coc01] an. Wobei der
Use Case in der Tabelle durch unterschiedliche Felder beschrieben wird. Das Feld Pre-
condition bezeichnet die erforderlichen Vorbedingungen für den Use Case. Der Zustand
83

der Anwendung nach der Durchführung des jeweiligen Use Cases wird im Feld Post-
condition bestimmt. Die Angabe der beiden Bedingungen fördert das Verständnis der
Zusammenhänge zwischen den einzelnen Use Cases.
Im Feld Rolle wird zwischen den unterschiedlichen Rollen der Anwender des Prototyps
(vgl. Kapitel 6.4) unterschieden. Diese Rollen werden in Abbildung 6.4 und 6.5 in Ab-
schnitt 6.4 den auf sie zugeschnittenen Use Cases in einem Unified Modeling Language
(UML) Anwendungsfalldiagramm gegenübergestellt [FS00].
84

Name Erfassen einer Maßnahme für ein Wissensrisiko
ID 4
Ziel Entwickeln einer passenden Maßnahme für ein identifiziertes,
bewertetes Wissensrisiko
Häufigkeit Unregelmäßig
Rolle Risk Owner
Precondition Risk Owner am K@R Tool angemeldet; Wissensrisiko
identifiziert und dem Risk Owner zugewiesen; Wissensrisiko
bereits vom Risk Owner bewertet;
Postcondition Weiterer Umgang mit dem Wissensrisiko geplant und dokumentiert
Standardablauf 1. Der Risk Owner wählt die Option Maßnahme erfassen
aus.
2. Der Risk Owner erfasst nun die Maßnahme in der erscheinenden
Eingabemaske Alternative 1, Alternative
2
3. Er speichert das Risiko, dabei verknüpft das System
das Risiko mit der eingegebenen Maßnahme Alternativen
Alternative 1 Erfassen einer Maßnahme anhand des generischen
Maßnahmenkataloges
A1.1. Das System schlägt aufgrund des generischen Risikos,
von dem das Wissensrisiko abgeleitet wurde, mehrere
Maßnahmen zum Umgang mit dem Risiko vor.
A1.2. Der Risk Owner wählt ein Risiko aus der Liste aus.
A1.3. Das System übernimmt die Daten der generischen
Maßnahme in die Eingabemaske und der Risk Owner füllt
die restlichen Elemente der Maske aus bzw. ändert bestehende
Einträge.
Alternative 2 Erfassen einer Maßnahme mit der Unterstützung
durch auf ähnliche Risiken bereits angewendete
Maßnahmen
A2.1. Das System schlägt aufgrund einer Ähnlichkeitssuche
über die Risiken bereits in anderen Projekten erfasste
Maßnahmen vor.
A2.2. Der Risk Owner wählt ein Risiko aus der Liste aus.
A2.3. Das System übernimmt die Daten der ausgewählten
Maßnahme in die Eingabemaske und der Risk Owner
passt die Einträge an.
Prototyp Im ersten Schritt der Prototypentwicklung sollte der
Standardablauf als auch die Alternative 1 umgesetzt werden.
Alternative 2 ist im ersten Schritt aufgrund der fehlenden
historischen Daten schwer umsetzbar.
Tabelle 6.1.: Use Case 4: Erfassen einer Maßnahme für ein Wissensrisiko
85

6.4. Rollen
Die drei Rollen des Projektleiters, des Arbeitspaketleiters und des Risk Owners wurden
ausgehend von den in Abschnitt 6.3.1 festgelegten Personas entwickelt. Abbildung 6.3
zeigt die Zusammenhänge zwischen den drei Rollen. Es wird klar dargestellt, dass die
Rolle des Risk Owners jene des Projektleiters und Arbeitspaketleiters erweitert (vgl.
Kapitel 6.4.3).
Abbildung 6.3.: Rollen
Im Weiteren werden die einzelnen Rollen jeweils kurz beschrieben sowie ihre unterschied-
lichen Ziele und somit auch divergierenden Anforderungen und Bedürfnisse gegenüber
dem Knowledge@Risk Prototyp untersucht.
6.4.1. Projektleiter
Das zentrale Ziel eines Projektleiters ist die erfolgreiche Durchführung des Projektes.
Der Erfolg eines Projektes wird hauptsächlich anhand der drei Parameter Zeit, Kosten
und Qualität gemessen. Um den Erfolg eines Projektes zu gewährleisten ist ein aktiver
Umgang mit Wissensrisiken notwendig. Ziele für den Umgang mit Wissensrisiken müssen
festgelegt und durch Identifikation, Bewertung, Entwicklung einer Strategie bzw. Maß-
nahme und Berichterstattung realisiert werden.
Aus diesem Ziel und den damit verbundenen Rahmenbedingungen lassen sich einige
Anforderungen und Bedürfnisse des Projektleiters an den Prototyp ableiten. Für den
Projektleiter ist es entscheidend, einen schnellen Überblick über die wichtigsten Wis-
sensrisiken eines Projektes zu besitzen. Zusätzlich sollen für ihn alle anderen Risiken
zugänglich und beobachtbar sein. Arbeitspakete, welche durch Risiken sehr stark gefähr-
86

det werden und Risikoverantwortliche, die sich nicht um ihre Risiken kümmern, sollen
zudem einfach identifizierbar sein.
In Abbildung 6.4 werden die Rollen des Projektleiter und Arbeitspaketleiter den für sie
bestimmten Use Cases (siehe Kapitel 6.3.4) gegenübergestellt.
Abbildung 6.4.: Uses Cases - Projektleiter und Arbeitspaketleiter
6.4.2. Arbeitspaketleiter
Die Ziele eines Arbeitspaketleiters sind natürlich denjenigen eines Projektleiters sehr
ähnlich. Der Unterschied liegt darin, dass für ihn der Erfolg des Arbeitspakets und nicht
der Erfolg des Projekts im Vordergrund steht. Auch sein Erfolg wird unter den drei
Aspekten Kosten, Qualität und Zeit gemessen.
So ist ein Arbeitspaketleiter hauptsächlich an den Risiken in seinem Arbeitspaket in-
teressiert und möchte diese in einer arbeitspaketspezifischen Ansicht betrachten können.
Allerdings möchte er zusätzlich die Möglichkeit besitzen, beim Erfassen von neuen Risi-
ken und beim Entwickeln von Steuerungsmaßnahmen die von anderen Arbeitspaketleitern
identifizierten Risiken oder entwickelten Maßnahmen zu betrachten. Dadurch kann der
87

Arbeitspaketleiter erkennen, ob ein Kollege oder ein Projektleiter bereits ein ähnliches
bzw. sogar dasselbe Risiko erfasst hat und welche Maßnahmen dafür getroffen wurden.
Der Prototyp unterstützt ein gruppenbasiertes Zugangskonzept. Dafür werden die Daten
der einzelnen Benutzer wie Vor-, Nach-, Benutzername und Kennwort in einer eigenen
Tabelle in der Datenbank gespeichert. Meldet sich ein Benutzer für ein Projekt am System
an, wird durch eine Datenbankabfrage festgestellt, ob er ein Projektleiter (siehe Kapitel
6.4.1) oder ob er ein Arbeitspaketleiter ist. Mit der Unterscheidung zwischen diesen
beiden Rollen werden auch die Zugriffsrechte gesteuert. Auf diese Weise bleibt einem
Arbeitspaketleiter die Ansicht auf Risiken aus Arbeitspaketen, für die er nicht zuständig
ist, verwehrt.
6.4.3. Risk Owner
Sowohl der Projekt- als auch der Arbeitspaketleiter können zusätzlich zu der bestehenden
Rolle die eines Risk Owners zugewiesen bekommen. Wird ein neues Risiko identifiziert
und von einem generischen Risiko instanziiert (vgl. Kapitel 5.2.2), wird es einer dafür in
Zukunft verantwortlichen Person, einem so genannten Risk Owner, zugewiesen.
Abbildung 6.5.: Use Cases - Risk Owner
88

Diese Person erkennt bei der nächsten Anmeldung an das System, dass ihr ein neues
Risiko zugewiesen wurde, und erklärt sich mit einer Bestätigung der Zuweisung mit der
weiteren Verantwortung über das Risiko einverstanden. Ab diesem Zeitpunkt ist sie für
die Bewertung des Risikos, das Erstellen von passenden Steuerungsmaßnahmen und das
Reporting verantwortlich.
Das Ziel eines Risk Owners ist die erfolgreiche Handhabung und Steuerung aller Risiken,
für die er verantwortlich ist. Hierzu ist die Möglichkeit einer schnellen Ansicht seiner
Risiken und der mit dem Risiko verknüpften Tätigkeiten, wie es zu akzeptieren, es zu
bewerten oder eine Steuerungsmaßnahme zu planen, von großer Bedeutung. Abbildung
6.5 stellt die Rolle des Risk Owners den für ihn bestimmten Use Cases (siehe Kapitel
6.3.4) gegenüber.
Abbildung 6.6.: Screenshot - Zugriffsrechte Risk Owner
Wie bereits in Kapitel 6.4.2 beschrieben basiert die Unterscheidung zwischen dem Projekt-
und Arbeitspaketleitern mit den mit ihnen verbundenen Zugriffsrechten auf einem grup-
penbasierten Zugangskonzept. Die Abgrenzung zur dritten Rolle, dem Risk Owner, erfolgt
in der Navigation. So ist die linke Navigationsleiste für die beiden Rollen Projekt- und
Arbeitspaketleiter vorgesehen. Der Risk Owner navigiert mittels der oberen Navigations-
leiste. Öffnet er den Bereich My Risks (siehe Abbildung 6.22 in Abschnitt 6.10) oder My
Tasks (siehe Abbildung 6.23) werden nur die Risiken angezeigt, für die er verantwortlich
ist. Denn nur er besitzt die Rechte diese zu bewerten oder eine Steuerungsmaßnahme für
sie zu entwickeln.
Die Zugriffsrechte des Risk Owners werden auch bei der Ansicht aller Risiken, der TOP-
10 Risiken und der Suchergebnisse berücksichtigt. Ist der an das System angemeldete
Benutzer der Risk Owner eines noch nicht bewerteten Risikos wird ihm in den Risiko-
89

tabellen für dieses Risiko die Möglichkeit einer Bewertung angeboten (siehe Abbildung
6.6). Für den Fall, dass er nicht der Verantwortliche für dieses Risiko ist, wird ihm das
Recht für die Bewertung verweigert.
6.5. Funktionsablauf
In Kapitel 2.3 wurden die Prozesse des klassischen Risikomanagements ausführlich er-
klärt. Ausgehend von diesen Prozessen wurde ein Funktionsablauf für den Knowled-
ge@Risk Prototyp unter Berücksichtigung der Rollen (siehe Kapitel 6.4) entwickelt. Der
Funktionsablauf beginnt mit der Erfassung der Projekteigenschaften und der Festlegung
der Arbeitspakete mit dazugehörigem Arbeitspaketleiter (vgl. Abbildung 6.7). Diese zwei
Aktivitäten legen die Rahmenbedingungen für das Wissensrisikomanagement im Projekt
fest und werden nur einmal am Beginn des Projektes durchgeführt. Sind die Rahmen-
bedingungen erfolgreich erfasst, kann mit dem eigentlichen Risikomanagement begonnen
werden. Es setzt sich aus den Aktivitäten Risiken identifizieren, Risiken bewerten, Maß-
nahmen treffen und Reporting zusammen, welche schrittweise für jedes Risiko abgearbei-
tet werden.
Abbildung 6.7.: Aktivitätsdiagramm mit Rollen
90

In der ersten Ausbaustufe des Prototyps wurde auf eine Implementierung der Aktivitäten
Neues Projekt anlegen, Arbeitspakete festlegen und Reporting zugunsten einer Konzentra-
tion auf die Unterstützung bei der Entwicklung von geeigneten Steuerungsmaßnahmen,
wie es der Forschungsfrage (siehe Abschnitt 1.3) entspricht, verzichtet. Im Folgenden
werden die einzelnen Aktivitäten des Funktionsablaufs im Detail beschrieben.
6.5.1. Projekteigenschaften erfassen
In der ersten Aktivität werden die Projekteigenschaften vom Projektleiter festgelegt.
Das Erfassen der Projekteigenschaften ist vor allem für eine Ausbaustufe des Prototyps
in Richtung einer projektübergreifenden Ähnlichkeitssuche interessant (siehe Kapitel 7).
In diesem Fall können anhand der Projekteigenschaften ähnliche Projekte identifiziert
und deren Risiken angezeigt werden. In der aktuellen Ausbaustufe dient die Erfassung
dieser Eigenschaften in erster Linie dazu, Informationen über das Projekt an die Benutzer
weiterzugeben.
6.5.2. Arbeitspakete beschreiben und Arbeitspaketleiter festlegen
In der nächsten Aktivität erfasst der Projektleiter die einzelnen Arbeitspakete des Pro-
jektes, beschreibt sie und bestimmt den jeweiligen Arbeitspaketleiter. Somit lassen sich
die Risiken den passenden Arbeitspaketen zuordnen, die passenden Rollen den einzelnen
Benutzern zuweisen und die Informationen über die einzelnen Arbeitspakete des Projek-
tes für die Anwender anzeigen.
Das Erfassen der Projekteigenschaften (voriger Schritt) und die Beschreibung der Ar-
beitspakete mitsamt der Festlegung der Arbeitspaketleiter müssen nur am Beginn eines
Projektes einmalig durchgeführt werden. Alle weiteren Aktivitäten werden nacheinander
einzeln für jedes Risiko durchgearbeitet.
6.5.3. Risiken identifizieren
Ein neues Risiko kann entweder von einem Projekt- oder Arbeitspaketleiter identifiziert
werden. Im ersten Schritt muss hierzu ein generisches Wissensrisiko (vgl. Kapitel 5.2.1)
ausgewählt werden. Um den Benutzer bei der richtigen Auswahl zu unterstützen, werden
alle generischen Wissensrisiken in ihren Kategorien geordnet in einer TreeView Baum-
91

struktur (vgl. Kapitel 6.9) mit den bereits von ihnen abgeleiteten Risiken angezeigt.
Durch Selektion des generischen Risikos bzw. des bereits abgeleiteten Risikos lässt sich
das generische bzw. abgeleitete Risiko im Detail betrachten.
Die Anzeige der bereits abgeleiteten Risiken erfüllt zweierlei Funktion. Einerseits wird
hiermit einer doppelten Erfassung eines Risikos vorgebeugt und andererseits kann der
Benutzer durch das Betrachten dieser Risiken besser beurteilen, ob das neue Risiko zu
diesem generischen Risiko passt. Hat der Benutzer das passende generische Risiko aus-
gewählt leitet er das neue Risiko von ihm ab (vgl. Kapitel 5.2.2).
Beim Instanziieren des Risiko werden in einem Risikoformular Felder wie Risikotitel, Ri-
sikobeschreibung oder die betroffenen Arbeitspakete ausgefüllt. Ein wichtiger Punkt ist
auch die Zuweisung des Risikos an einen Risk Owner (siehe Abschnitt 6.4.3). Dadurch
wechselt die Verantwortung für das neue Risiko an diese Person, und sie hat die Auf-
gabe, die folgenden Schritte des Bewertens, der Entwicklung von Maßnahmen und des
Reporting für dieses instanziierte Risiko durchzuführen.
6.5.4. Risiken bewerten
Hat ein Risk Owner ein ihm neu zugewiesenes Risiko akzeptiert, so ist seine nächste Auf-
gabe die Bewertung dieses Risikos. Die verwendete Bewertungsmethode basiert auf einer
Untersuchung verschiedenster Methoden zur Bewertung für Wissensrisiken von Turek
[Tur05].
Abbildung 6.8.: Riskmap nach [HRD99]
92

In ihrer Arbeit schlägt Turek die Verwendung einer Bewertung mittels einer Riskmap vor.
Eine Riskmap ist eine Portfoliodarstellung bzw. eine Matrix, in welcher die Parameter
Eintrittswahrscheinlichkeit und Schadensausmaß sowohl qualitativ als auch quantitativ
dargestellt werden können. Dies erfolgt anhand einer Einteilung in unterschiedliche Ri-
sikoklassen. Zudem wird eine vom Projektleiter individuell für das Projekt festgelegte
Risikoschwelle in das Diagramm eingezeichnet (siehe Abbildung 6.8).
6.5.5. Maßnahmen treffen
Die nächste Aktivität im Funktionsablauf ist die Entwicklung von passenden Steuerungs-
maßnahmen für die zuvor identifizierten und bewerteten Risiken. Nur die für das jeweilige
Risiko verantwortliche Person hat die notwendigen Rechte um eine Maßnahme für dieses
Risiko zu erfassen.
Wählt der Risk Owner das Risiko aus, für welches er eine Maßnahme entwickeln möchte,
werden ihm alle passenden generischen Maßnahmen angezeigt. Die Verknüpfung zwischen
dem instanziierten Risiko und den generischen Maßnahmen funktioniert über die gene-
rischen Risiken und deren logischer Verbindung mit den generischen Maßnahmen (vgl.
Kapitel 5.2.3 und Abbildung 5.2). Die generischen Maßnahmen werden anhand ihrer Ka-
tegorie geordnet mit bereits von ihnen abgeleiteten Maßnahmen in einer Baumstruktur
(siehe Abschnitt 6.9) angezeigt. Durch eine Selektion der Maßnahmen in der Baumstruk-
tur lässt sich die generische bzw. die instanziierte Maßnahme im Detail betrachten.
Wie bei der Baumstruktur für die Identifikation von Risiken (siehe Abschnitt 6.5.3) soll
die Ansicht der bereits instanziierten Maßnahmen den Benutzer dabei unterstützen, die
richtige generische Maßnahme zu finden. Außerdem können die Informationen über die
instanziierten Maßnahmen bei der Beschreibung und Entwicklung der neuen Maßnahme
hilfreich sein. Hat der Benutzer die passende generische Maßnahme ausgewählt, leitet er
die neue Maßnahme von ihr ab (vgl. Kapitel 5.2.2).
Beim Ableiten der Maßnahme werden in einem Maßnahmenformular Felder wie Maßnah-
mentitel, -beschreibung, Status und Kosten spezifiziert.
93

6.5.6. Reporting
Die letzte Aktivität im Funktionsablauf ist das kontinuierliche Berichten über die Verän-
derungen des Risikos oder das Wirken der Maßnahmen, auch Reporting genannt. So ist
die Gefährdung, die durch ein Risiko entsteht, über die Zeit nicht konstant [Mel98]. Das
personelle Wissensrisiko der Demotivation der Mitarbeiter steigt beispielsweise typisch
mit dem Fortgang des Projektes an.
Das Reporting soll vom Risk Owner sowohl bei Veränderungen als auch in einem regel-
mäßigen Abstand durchgeführt werden. Die Ergebnisse dieses Schrittes ermöglichen ein
Anwachsen des Wissens über Risiken und Maßnahmen. Bei zukünftigen Entwicklungen
von Maßnahmen können bereits verwendete Maßnahmen und deren Erfolg betrachtet
werden. Dies lässt Rückschlüsse auf einen möglichen Erfolg der neuen Maßnahme zu.
So ist das Lernen aus der Vergangenheit für Fisher [FGRD02] ein zentraler Aspekt des
Risikomanagements.
6.6. Navigation
Ausgehend von den Erkenntnissen des Goal Oriented Interaction Designs (vgl. Kapitel
6.3) und dem Funktionsablauf (vgl. Kapitel 6.5) wurde ein Navigationskonzept für den
Prototyp entworfen. Das Konzept besteht aus einer Hauptnavigation, einer Sitemap und
dem Datenaustausch zwischen den einzelnen Seiten.
6.6.1. Hauptnavigation
Die Überlegungen über die Navigation innerhalb des Prototyps wird mithilfe der Ausfüh-
rungen über die unterschiedlichen Rollen, deren Ziele und dem Funktionsablauf getroffen.
Abbildung 6.9 zeigt einen für die Konzeption des Prototyps verwendeten Mockup 4 . In der
Abbildung ist die Trennung der Rollen Risk Owner und Projekt- bzw. Arbeitspaketleiter
in den Navigationsleisten des Knowledge@Risk Prototyps klar ersichtlich.
4 Ein Mockup in der Softwareentwicklung bezeichnet einen rudimentären Wegwerfprototyp der Benutzeroberfläche
einer zu erstellenden Software. Mockups werden insbesondere in frühen Entwicklungsphasen
eingesetzt, um Anforderungen an die Benutzeroberfläche in Zusammenarbeit mit Auftraggeber
und Anwendern besser ermitteln zu können. Es handelt sich meist um ein reines Grundgerüst der Bedienelemente
ohne weitere Funktionalität, Quelle: http://de.wikipedia.org/wiki/Mock-up [abgerufen
20.09.2005]
94

Abbildung 6.9.: Mockup - Knowledge@Risk Prototyp
In der oberen Navigationsleiste findet ein Risk Owner alle für ihn notwendigen Funktio-
nen, wie die Ansicht der ihm zugewiesenen Risiken und die Tätigkeiten, die für einen
erfolgreichen Umgang mit diesen Risiken notwendig sind.
Die linke Navigationsleiste beinhaltet wiederum die Funktionen für den Projekt- bzw.
Arbeitspaketleiter. Ausgehend von dieser Navigationsleiste lässt sich unter anderem ein
neues Risiko erfassen, alle Risiken im Projekt bzw. in den Arbeitspaketen anzeigen oder
nach Risiken suchen. Die Ziele der Projekt- und Arbeitspaketleiter (siehe Abschnitt 6.4)
werden speziell durch die schnelle Übersicht der zehn wichtigsten Risiken im Projekt oder
Arbeitspaket unterstützt.
6.6.2. Sitemap
Anhand der Use Cases und dem Funktionsablauf mitsamt den Rollen und deren Zielen
wurde eine Sitemap entwickelt, welche alle für die Webapplikation notwendigen Seiten
mit den Verbindungen zwischen ihnen in einem Diagramm darstellt. Als Darstellungsform
wurde die von Conallen [Con99] vorgeschlagene UML Modellierung für Sitemaps gewählt.
Die Komponenten stellen die Seiten der Webapplikation und die Pfeile Links zwischen
ihnen dar.
95

Abbildung 6.10.: Sitemap
96

6.6.3. Datenaustausch
Für die Weitergabe von Daten zwischen den in der Sitemap (siehe Abbildung 6.10) dar-
gestellten Seiten des Knowledge@Risk Prototyps werden zwei unterschiedliche Methoden
verwendet.
Session State
Nach dem sich ein Benutzer erfolgreich am Knowledge@Risk Prototyp angemeldet hat,
lädt die Anwendung Daten, wie seinen Namen oder Identifikationsnummer, aus der Da-
tenbank in den Session State. Auf die nun im Session State gespeicherte Information
kann jede Seite zugreifen und somit erkennen, welcher Benutzer die Seite aufruft. Dies
ist beispielsweise in der Seite My Risks, wo der Benutzer eine Darstellung aller Risiken
für die er verantwortlich ist erhält, von großer Bedeutung.
URL Parameter
Eine weitere Möglichkeit Informationen von einer Seite der Anwendung auf die nächs-
te zu übertragen, stellen URL Parameter dar. Hierbei werden Parameter, beispielsweise
eine Risiko-Identifikationsnummer, in der URL übergeben. Diese Art der Informations-
übermittlung wird im Prototyp bei den Detailansichten verwendet. So öffnet die URL
http://riskdetail.aspx?ID=1 die Detailansicht des Risikos mit der Identifikationsnum-
mer 1.
6.7. Klassendesign
Aufbauend auf den Ausführungen über das RRP Modell (vgl. Kapitel 5), dem Goal Ori-
ented Interaction Design (vgl. Kapitel 6.3) und dem Funktionsablauf (vgl. Kapitel 6.5)
wurde ein Klassendesign für den Prototyp entworfen. Es besteht erstens aus den durch
Assoziationen verbundenen Benutzerklassen, Beschreibungsklassen, Generische Klassen,
Maßnahmenklassen, Risikoklassen und Projektklassen (Vollständiges Diagramm siehe
Anhang F). Zweitens beinhaltet es auch die von diesen Klassen losgelösten Manager-
klassen.
97

6.7.1. Benutzerklassen
Die beiden Klassen Riskidentifier und Owner werden von der Basisklasse User, welche
alle wichtigen Informationen über den Benutzer als Attribute beinhaltet, abgeleitet (siehe
Abbildung 6.11).
6.7.2. Beschreibungsklassen
Abbildung 6.11.: Benutzerklassen
Da viele Beschreibungsklassen, wie Impact, Strategy oder Status, jeweils aus den Attri-
buten Id und Name bestehen wurden sie von einer gemeinsamen Basisklasse Description
abgeleitet (siehe Abbildung 6.12).
Abbildung 6.12.: Beschreibungsklassen
98

6.7.3. Generische Klassen
In Kapitel 5.2.1 wurde die Funktion des generischen Risiko- und Maßnahmenkataloges
innerhalb des Risk Response Planning Modells bereits sehr ausführlich beschrieben. Diese
Kataloge finden sich auch im Klassendesign wieder. Die Klasse G_Action ist eine von der
Klasse G_Risk aggregierte Klasse (siehe Abbildung 6.13).
6.7.4. Maßnahmenklasse
Abbildung 6.13.: Generische Klassen
Die Klasse Action leitet sich von der Basisklasse G_Action ab und aggregiert ihrerseits
die beiden Klassen Status und Owner (siehe Abbildung 6.14).
Abbildung 6.14.: Maßnahmenklasse
99

6.7.5. Risikoklasse
Die Klasse Risk verfügt über die meisten Assoziationen mit anderen Klassen. Sie wird
von der Basisklasse G_Risk abgeleitet und verfügt über Aggregationsbeziehungen mit
den Klassen Action, Probability, Impact, Level, Owner und Riskidentifier (siehe
Abbildung 6.15).
Abbildung 6.15.: Risikoklasse
100

6.7.6. Projektklasse
Die Klasse Project verfügt über eine Komposition mit der Klasse Workpackage und einer
Aggregation mit der Klasse Owner. Die Klasse Workpackage hat ebenfalls einen Owner
und zusätzlich eine Aggregationsbeziehung mit der Klasse Risk (siehe Abbildung 6.16).
Abbildung 6.16.: Projektklasse
101

6.7.7. Managerklasse
Die Klasse Manager enthält alle Operationen der Business Logic und eine Aggregati-
onsbeziehung mit der Klasse DatabaseManager, welche alle Datenbankoperationen bein-
haltet (siehe Abbildung 6.17). Mittels der Enumeration DatabaseCommands kann der
DatabaseManager die gewünschten Objekte bei den Operationen Get() bzw. Set() aus
der Datenbank auslesen bzw. abspeichern. Die Klassen wurden so entworfen, damit sie
dem objektorientierten Konzept der Kapselung entsprechen und ein unkontrollierter Zu-
griff auf Objekte verhindert wird.
Abbildung 6.17.: Managerklasse
102

6.8. Datenbank
Die Datenbank spielt in Webapplikationen laut Schmiderer [Sch03] üblicherweise eine
zentrale Rolle. So übernimmt sie auch im Knowledge@Risk Prototyp eine tragende Auf-
gabe. Dabei wurde vor allem auf Wartbarkeit der Datenbank und deren Konsistenz ge-
achtet.
6.8.1. Datenbank Design
Bei der Implementierung wurde auf das Speichern von aller Daten in der Datenbank
Wert gelegt, um mögliche Änderungen in der Datenbank und nicht im ASP.NET Code
durchführen zu können. So wurden beispielsweise die Daten für die Bewertung der Ein-
trittswahrscheinlichkeit und der Auswirkungen jeweils in einer eigenen Tabelle gespei-
chert. Entscheidet sich der Projektleiter für eine detailliertere Skalierung der Bewertung,
kann er dies einfach in der Datenbank ändern (siehe Tabelle Level in Abbildung 6.18).
Abbildung 6.18 zeigt ein vollständiges Datenbankdiagramm. Das Kürzel PK steht für
Primary Key und beschreibt einen Wert, welcher zur eindeutigen Identifikation einer spe-
zifischen Zeile verwendet wird 5 . Fremdschlüssel - Foreign Keys - werden im Datenbank-
diagramm mit dem Kürzel FK gekennzeichnet. Sie verweisen jeweils auf ein Datenfeld
mit einem Primary Key in einer anderen Tabelle 6 . Auf diese Weise können Datenfelder
und die in ihnen gespeicherte Informationen aus unterschiedlichen Tabellen miteinander
verbunden werden, was einen wichtigen Bestandteil der Normalisierung einer Datenbank
darstellt. Durch die Normalisierung der Datenbank werden Redundanzen, mehrfach vor-
handene Einträge oder Felder, und die damit verbundene Gefahr von Anomalien, einan-
der widersprechende Dateninhalte, vermieden. Somit wird die Wartung der Datenbank
vereinfacht und deren Konsistenz gewährleistet.
5 http://en.wikipedia.org/wiki/Primary_key [abgerufen am 27.10.2005]
6 http://en.wikipedia.org/wiki/Foreign_key [abgerufen am 27.10.2005]
103

Abbildung 6.18.: Datenbankdiagramm
104

6.8.2. Tabelle Logik
Die Tabelle Logic hat besondere Bedeutung für die Webapplikation, da sie die in Kapi-
tel 5.3 entwickelte Logik im Prototyp abbildet. In ihr wird der Katalog an generischen
Wissensrisiken mit jenen an generischen Steuerungsmaßnahmen, welche in den Tabellen
Generic Risks und Generic Actions abgespeichert sind, verbunden. Die Matrixform der
Logik (siehe Abbildung C.1) wurde in die Tabelle Logic übertragen indem die Identifika-
tionsnummer aller für ein spezifisches generisches Wissensrisiko geeigneten generischen
Steuerungsmaßnahmen aufgenommen wurden (siehe Abbildung 6.19). Generische Maß-
nahmen die in der Logik mit nicht geeignet (vgl. Kapitel 5.3.1) bewertet sind wurden
nicht in die Tabelle aufgenommen. Maßnahmen mit der Bewertung geeignet wurden mit
dem Score 1 und sehr geeignete Maßnahmen mit 2 gekennzeichnet.
In der momentanen Ausbaustufe des Prototyps werden dem Benutzer alle für die Steue-
rung sehr geeigneten generischen Maßnahmen für ein fallspezifisches Risiko vorgeschlagen
(vgl. Kapitel 6.9.2). Die mit geeignet bewerteten Maßnahmen sollen in einer Ausbaustufe
auf Wunsch des Benutzers zusätzlich angezeigt werden, wenn er unter den sehr geeigneten
keine für ihn passende Maßnahme finden kann. Dadurch wird die Unschärfe, die durch
die subjektive Entwicklung der Logik entstand, noch weiter entschärft.
6.9. TreeView
Abbildung 6.19.: Auschnitt aus der Tabelle Logic
Eine traditionelle Repräsentation von Baumstrukturen ist eine Form der Visualisierung,
die zahlreich eingesetzt wird. Ihre Anwendung im Windows Explorer machte eine große
105

Anzahl von Computernutzern mit dieser Art der Visualisierung vertraut. Eine TreeView
Darstellung ist eng mit dieser traditionellen Darstellungsform verbunden und aus diesem
Grund ist ihre Visualisierung für den Benutzer intuitiv gut verständlich.
Jede TreeView Komponente hat die Fähigkeit Teilbäume ein- und auszublenden um die
Übersichtlichkeit zu steigern. Zudem verbrauchen sie in horizontaler Richtung relativ we-
nig Platz und eignen sich dadurch zur Visualisierung von Anwendungen in denen neben
der Darstellung einer Hierarchie selbst, noch andere Informationen angezeigt werden müs-
sen [Sch02]. Ein Nachteil dieser Form der Darstellung ist, dass sie bei großen Hierarchien
schnell unübersichtlich wird und eine schlechte Platzausnutzung den Nutzer dazu zwingt,
den Baum scrollen zu müssen, oder Informationen bleiben in ausgeblendeten Teilbäumen
verborgen.
Die TreeView Komponente findet im Prototyp in den beiden Schritten der Risikoidentifi-
kation und der Entwicklung von Steuerungsmaßnahmen Verwendung. Beide Fälle werden
im Folgenden beschrieben und die Vorteile der Verwendung der TreeView Darstellung
aufgezeigt.
6.9.1. Unterstützung bei der Identifikation
Bei der Erfassung eines neuen Risikos werden dem Projekt- bzw. Arbeitspaketleiter die
generischen Risiken aus dem in Kapitel 3.8 entwickelten Katalog in einer TreeView Dar-
stellung in Kategorien geordnet angezeigt (siehe Abbildung 6.20). Zusätzlich werden die
von diesen generischen Risiken im Projekt schon instanziierten Risiken ebenfalls darge-
stellt.
Die Darstellung des Kataloges an generischen Risiken ermöglicht dem Benutzer einen
Einblick in die Kategorien und Wissensrisiken, von denen das Projekt betroffen sein
könnte. Wenn er möchte, kann er Risiko für Risiko durchgehen und entscheiden, ob das
jeweilige Risiko in seinem Projekt bzw. Arbeitspaket auftreten kann. Dies wird vor al-
lem bei der Neueinführung von Wissensrisikomanagement im Unternehmen eine übliche
Herangehensweise darstellen. Ist das Management von Wissensrisiken im Projekt schon
etablierter, werden die Risiken durch die Projekt- bzw. Arbeitspaketleiter selbstständig
identifiziert. Bei der passenden Zuweisung der identifizierten Risiken zu den generischen
Risiken ist dann die Ansicht der von den generischen bereits instanziierten Risiken hilf-
reich.
106

Abbildung 6.20.: Screenshot - Neues Risiko erfassen
6.9.2. Unterstützung bei der Steuerung
Bei der Entwicklung der passenden Steuerungsmaßnahmen für bereits identifizierte und
bewertete Wissensrisiken wird der Benutzer durch das in Kapitel 5 entworfene Modell
und dessen Umsetzung im Knowledge@Risk Prototyp unterstützt.
Wählt ein Benutzer die Funktion der Erfassung einer neuen Maßnahme aus, werden ihm
alle zum Risiko passenden generischen Maßnahmen aus dem Katalog 4.5 in ihren Ka-
tegorien geordnet angezeigt (siehe Abbildung 6.21). Welche generischen Maßnahmen zu
welchen generischen Risiken passen, entscheidet die im RRP Modell entwickelte Logik
(vgl. Kapitel 5.3). In der aktuellen Ausbaustufe werden dem Benutzer alle für das je-
weilige generische Risiko mit sehr geeignet (siehe Kapitel 5.3.1) bewerteten generische
Steuerungsmaßnahmen angezeigt. Die angezeigten generischen Maßnahmen beschreiben
Techniken und Werkzeuge, welche eingesetzt werden können, um das identifizierte Risi-
ko zu steuern. Nach einer Durchsicht der generischen Maßnahmen und denen von ihnen
bereits abgeleiteten Maßnahmen kann der Benutzer aufgrund der in der TreeView Dar-
107

stellungen vorhandenen Information eine passende Steuerungsmaßnahme entwickeln. Für
den Fall, dass der Benutzer selbständig eine Maßnahme entwickelt, helfen ihm die bereits
abgeleiteten Maßnahmen dabei die richtige Zuordnung zu einer generischen Maßnahme
zu finden.
6.10. DataGrid
Abbildung 6.21.: Screenshot - Neue Maßnahme erfassen
Das DataGrid Webcontrol bietet die Möglichkeit Daten tabellarisch zu visualisieren und
eignet sich im Falle des Knowledge@Risk Prototyps einerseits ausgezeichnet zur Darstel-
lung von vielen Risiken in einer Tabelle, wie es beispielsweise auf den Seiten My Risks, All
Risks oder Top 10 Risks der Fall ist. Andererseits eignet es sich zur Aufzählung von Lis-
ten unbestimmter Länge, wie bei der Aufzählung der Workpackages auf der Projektseite
108

oder bei der Aufzählung der Tätigkeiten auf der My Tasks Seite.
An dieser Stelle wird die Verwendung des DataGrids auf den Seiten My Risks und My
Task im Detail beschrieben.
6.10.1. Anzeigen der persönlichen Risiken
Auf der Seite My Risks werden dem Benutzer alle ihm zugewiesenen Risiken in einer
Tabelle angezeigt. Die Tabelle enthält die Felder Titel, Category, Workpackages, Level
und Action (siehe Abbildung 6.22).
Abbildung 6.22.: Screenshot - My Risks
Das Feld Titel beinhaltet einen Hyperlink mit den Titel des Risiko, welcher zu einer
Detailansicht des Risikos führt. Den Titel der Kategorie des jeweiligen Risikos enthält
das Feld Category. Das Feld Workpackages enthält eine zweite Tabelle, in der alle vom
109

Risiko betroffenen Arbeitspakete aufgezählt werden. Die beiden Felder Level und Acti-
on ermöglichen die Bewertung eines Risikos bzw. das Erfassen einer Maßnahme, wenn
diese Aktivität für das betreffende Risiko noch nicht durchgeführt wurde. Ansonsten
beinhalteten sie eine Beschreibung des Levels bzw. den Titel der Maßnahme.
6.10.2. Anzeigen der persönlichen Aufgaben
Die Seite My Tasks (siehe Abbildung 6.23) zeigt dem Benutzer alle noch notwendigen
Tätigkeiten für ein erfolgreiches Wissensrisikomanagement an. Diese Tätigkeiten bein-
halten das Akzeptieren der Verantwortung über ein Risiko, das Bewerten eines Risikos
und das Entwickeln von geeigneten Maßnahmen zur Steuerung von Risiken.
Abbildung 6.23.: Screenshot - My Tasks
110

Jede Tätigkeit besteht aus einer eigenen Tabelle - DataGrid - mit dem Titel des Risiko,
dem Identifikationsdatum und einer Schaltfläche, welche zur Durchführung der jeweiligen
Tätigkeit führt.
6.11. Zusammenfassung
Zu Beginn des Kapitels wurde in der Zielsetzung eine klare Abgrenzung der Funktio-
nalität des Prototyps getroffen und entschieden, den Prototyp in einer Webapplikation
mittels ASP.NET und der Programmiersprache C# zu realisieren. Für die Implementie-
rung der Datenbank wurde Microsoft Access in Verbindung mit einer ODBC Schnittstelle
und der Abfrage SQL verwendet. Das Layout der Applikation wird zentral für alle Seiten
in einer Stylesheet Datei gespeichert.
Im Rahmen des Goal Oriented Interaction Designs wurden anschließend Personas und
Goals definiert, welche in einem Szenario und zehn Use Cases detailliert beschrieben wur-
den. Ausgehend von den Erkenntnissen des Design-Prozesses wurden die drei Rollen des
Projekt-, Arbeitspaketleiters und Risk Owners bestimmt. Weiters wurde ein Funktions-
ablauf des Prototyps mit den Aktivitäten Projekteigenschaften beschreiben, Arbeitspakete
festlegen, Risiken identifizieren, Risiken bewerten, Maßnahmen treffen und Reporting ent-
worfen.
Ausgehend von diesen konzeptionellen Überlegungen wurde ein Navigationskonzept, be-
stehend aus einer Hauptnavigation, einer Sitemap und einer Beschreibung des Datenaus-
tausches für die Implementierung festgelegt. Weiters wurde ein Klassendesign und eine
Datenbankstruktur entwickelt und implementiert. Am Ende des Kapitels wurden noch
die beiden für die Implementierung zentralen Webcontrols TreeView und DataGrid und
ihre Anwendung im Prototyp beschrieben.
111

7. Schlussbetrachtung
In diesem letzten Kapitel der Arbeit werden die bisherigen Erkenntnisse zusammengefasst
und insbesondere die selbständigen Entwicklungen der Arbeit, wie die Kataloge an ge-
nerischen Risiken und geeigneten Steuerungsmaßnahmen oder das RRP Modell, kritisch
betrachtet und in Hinblick auf die Beantwortung der Forschungsfrage bewertet. Zudem
sollen mögliche zukünftige Entwicklungen und Verbesserungen aufgezeigt werden.
In Kapitel 2 wurde in das klassische Risikomanagement eingeführt und anhand einer
Untersuchung aus Standards und Richtlinien aus dem projekt- und unternehmenswei-
ten Risikomanagement erkannt, dass der Maßnahmenplanung eine besondere Rolle im
Risikomanagementprozess zufällt und Wissensrisiken in keinem dieser Standards und
Richtlinien eine eigene Kategorie zufällt.
Mit einer eigenständigen Kategorie von Wissensrisiken beschäftigt sich Kapitel 3 und
trifft nach einer ausführlichen Betrachtung der bisherigen Forschungslage zum Thema
Wissensrisiken eine neue Definition für diesen Begriff.
7.1. Definition Wissensrisiken
Die in der Arbeit verwendete Definition ist weiter reichend als die bisher für diesen Begriff
getroffenen Definitionen. Die bisher getroffenen Definitionen konzentrieren sich auf einen
möglichen Verlust an Wissenskapital. Solche so genannten wissensgefährdenden Risiken
werden um Risiken, die durch einen Mangel an Wissen und Fertigkeiten, welche für die
Durchführung einer geschäftsrelevanten Aktion notwendig sind, erweitert.
Die Erweiterung des Wissensrisikobegriffs um diese vom Autor mit wissensbasiert be-
zeichneten Risiken ist vor allem in der Eignung von Werkzeugen und Methoden des Wis-
sensmanagements zur erfolgreichen Steuerung dieser Risiken begründet. Die Gesamtheit
der wissensbasierten und wissensgefährdenden Risiken fasst alle für ein wissensintensives
112

Unternehmen entscheidenden Risiken zusammen und ermöglicht diesem Unternehmen
eine gleichzeitige Betrachtung aller für das Erreichen ihrer Unternehmensziele kritischen
Risiken und damit ein effizientes Risikomanagement.
7.2. Generische Kataloge
Um ein besseres Verständnis der neuen Definition von Wissensrisiken zu fördern wurde
in Kapitel 3.8 darauf aufbauend ein Katalog an abstrahierten, generellen Wissensrisiken
erarbeitet. Anschließend wurden unterschiedliche Strategien, mögliche Steuerungsinstru-
mente und -methoden für Wissensrisiken untersucht und dem Katalog an generischen
Wissensrisiken in Kapitel 4.5 ein Katalog an geeigneten abstrahierten, generellen Maß-
nahmen gegenüber gestellt.
Offensichtlich unterscheiden sich die in unterschiedlichen Projekte und Unternehmen auf-
tretende Wissensrisiken voneinander. Aber auf Grundlage der generischen Kataloge kön-
nen projekt- bzw. unternehmensspezifische Wissensrisiken identifiziert und spezifische
Maßnahmen zur Steuerung dieser Risiken entwickelt werden. Hierfür ist natürlich eine
gewisse Allgemeingültigkeit der Risiken und Maßnahmen aus den Katalogen von Bedeu-
tung.
Der Autor erachtet die bestehenden Kataloge als umfassend und zutreffend genug für
einen Praxiseinsatz. Dennoch wurden bei der Entwicklung der logischen Verknüpfung der
beiden Kataloge (siehe Kapitel 5.3) zwei mögliche Verbesserungen identifiziert. Aufgrund
von ähnlichen Mustern in der die Logik abbildenden Matrix (siehe Anhang C) wurden ein
paar redundante Risiken und Maßnahmen entdeckt, die um eine bessere Eindeutigkeit zu
erreichen aus den Katalogen entfernt werden sollten. Außerdem machte sich eine leich-
te Schieflage zwischen der Abstraktionsebene der Maßnahmen für wissensbasierte und
jener für wissensgefährdende Risiken bemerkbar, indem die Maßnahmen für wissensba-
sierte Risiken aus derselben Kategorie meist eine ähnliche Risikozuordnung aufwiesen.
Maßnahmen aus der Kategorie Kommunikation lassen sich so alle gemeinsam oder keine
auf ein generisches Wissensrisiko anwenden. Da die Treffsicherheit der Maßnahmen für
wissensgefährdende Risiken besser (weniger Bewertungen mit dem Attribut geeignet) ist,
wäre eine Anpassung der Abstraktionsebene der Maßnahmen für wissensbasierte Risiken
an jene der Maßnahmen für wissensgefährdende Risiken sinnvoll.
113

Nach Meinung des Autors sollten die bestehenden Kataloge in einem realen Projekt
angewandt und danach evaluiert werden. Die daraus resultierenden Ergebnisse sollten
dann gemeinsam mit den beiden oben vorgeschlagenen Verbesserungen in die Kataloge
eingearbeitet werden und somit deren Qualität verbessern.
7.3. RRP Modell
Das in Kapitel 5 entworfene Risk Response Planning Modell möchte die in der Einleitung
gestellte Forschungsfrage Wie können Benutzer bei der Entwicklung von Steuerungsmaß-
nahmen für Wissensrisiken unterstützt werden? beantworten. Dazu greift das Modell
auf die zwei generischen Kataloge zurück und verbindet sie mit einer Logik. Zusätzlich
erlaubt das Modell ein Instanzieren von fallspezifischen Risiken und Maßnahmen von
den generischen Wissensrisiken und Maßnahmen. In Abschnitt 5.4 wurde die Entwick-
lung einer geeigneten Steuerungsmaßnahme anhand des RRP Modells in einem Beispiel
erklärt.
Durch dieses Beispiel und des durch das Modells dem Anwender zur Verfügung gestellte
Wissen über generische Wissensrisiken und geeignete Steuerungsmaßnahmen sieht sich
der Autor in der Beantwortung der Forschungsfrage mit dem Modell bestätigt. Das Mo-
dell unterstützt den Benutzer Wissensrisiken zu identifizieren und geeignete Steuerungs-
maßnahmen zu entwickeln. Wobei die Unterstützung bei der Identifikation eine Nebenent-
wicklung der Arbeit darstellt, aber die Unterstützung bei der Entwicklung von passenden
Maßnahmen der eigentliche Nutzen des Modells ist.
Die Qualität der Unterstützung des Anwenders hängt zum Großteil von der Qualität der
logischen Verknüpfung zwischen den beiden Katalogen ab. Der Autor sieht den Grad
der Qualität der bestehenden Logik als hoch genug an, um das Modell in der Praxis
erfolgreich einzusetzen. Trotzdem soll die Qualität der Logik nach der Meinung des Au-
tors durch Rückmeldungen, die im Praxiseinsatz des Modells entstehen, stetig verbessert
werden. Dazu kann sich der Autor eine Erweiterung des Modells um eine automatische
Feinjustierung der Logik durch neu generiertes Wissen vorstellen.
114

7.4. Prototyp
In Kapitel 6 wurde die Konzeption und die Implementierung eines Prototyps beschrie-
ben, welcher das RRP Modell in einer Software abbildet und damit die Anwendung des
Modells erheblich erleichtert. Durch die Umsetzung des Prototyps sieht sich der Au-
tor zusätzlich in der Unterstützung des Anwenders bei der Entwicklung von geeigneten
Wissensrisiken bestätigt. Der Prototyp bietet sogar eine über das Modell hinausgehende
Unterstützung des Anwenders durch die in der TreeView (vgl. Kapitel 6.9) dargestellten
bereits instanzierten Risiken bzw. Maßnahmen an.
Solches bei der kontinuierlichen Verwendung des Prototyps im Projekt generierte zusätz-
liche Wissen über Risiken (Eintrittswahrscheinlichkeit und Auswirkungen) und Maßnah-
men (Effektivität) kann in weiteren Ausbaustufen noch effektiver genutzt werden. Eine
Ausbaustufe wäre die, bereits für das Modell geschilderte, automatische Feinjustierung
der Logik. Führte beispielsweise die Anwendung einer bestimmten generischen Maßnah-
me zur Steuerung eines Risikos des Öfteren nicht zum gewünschten Erfolg, könnte die
logische Verknüpfung zwischen dem generischen Risiko und der Maßnahme gelöst werden.
Oder eine nicht durch die Logik vorgeschlagene Maßnahme wird öfters zur Steuerung be-
stimmter von einem generischen Risiko abgeleiteter Risiken erfolgreich verwendet. Dann
könnte das System automatisch diese generische Maßnahme mit dem generischen Risiko
verbinden und hiermit bei zukünftigen Anwendungen diese Maßnahme dem Benutzer
zusätzlich vorschlagen.
Sind nach einem längeren Einsatz der Applikation im Projektmanagement eines Unter-
nehmens genügend instanziierte Risiken und Maßnahmen in der Datenbank vorhanden,
bringt ein Einsatz von Ähnlichkeitssuchen zusätzlichen Nutzen. Diese Ähnlichkeitssuche
könnte einerseits über ein Projekt hinweg funktionieren. Bei der Erfassung eines neuen
Projektes wird dies vom Projektleiter durch Eigenschaften beschrieben. Anhand dieser
Eigenschaften lassen sich ähnliche Projekte identifizieren und dem Projektleiter können
Risiken angezeigt werden, die in ähnlichen Projekten schon aufgetreten sind und wel-
che Maßnahmen für sie entwickelt wurden. Andererseits kann die Ähnlichkeitssuche bei
der Erfassung eines neuen Risikos Verwendung finden. Hier wird die Ähnlichkeit zwi-
schen dem neuen Risiko mit bereits erfassten Risiken ermittelt. Ähnliche Risiken können
angezeigt werden, und die in ihnen gespeicherte Informationen, wie Eintrittswahrschein-
lichkeit, Auswirkungen oder auf sie angewendete Maßnahmen, können dem Benutzer bei
der Identifikation und Steuerung des neuen Risikos unterstützen.
115

A. Generischer Wissensrisiko Katalog
• wissensgefährdende Risiken
– Personelle
∗ Schlüsselpersonen verlassen das Unternehmen
∗ Demotivation der Mitarbeiter
∗ Kriminelle Delikte
∗ Mitarbeiterleistung lässt nach
∗ Qualifikationsdefizite und Wissenslücken
∗ Blindes Vertrauen in Expertenfähigkeit
∗ Über- und Unterinvestitionen in Ausbildung
∗ Unbefriedigende Nachfolgeregelung
– Sachlich-technische
∗ Unfreiwillige Wissensdiffusion
∗ Verlust an Überschaubarkeit
∗ Entstehung von elektronischen Informations- und Datenfriedhöfen
∗ Fehlinvestitionen in technische Ausstattung
∗ Verletzlichkeit der Systeme
∗ Fehlende Aktualisierung von Expertensystemen
∗ Wissensmissbrauch durch Computerhacker oder Mitarbeiter
– Organisatorische
∗ Kulturelle Unterschiede
∗ Unkontrollierte Wissenszu- und Wissensabflüsse
∗ Unsicherheit bzgl. Wert und Erhalt des erworbenen Wissens
∗ Kein gezielter Erwerb benötigter Fähigkeiten
∗ Abgrenzungskonflikte bei Stellenbegrenzung
∗ Integration heterogener Aktiva
116

∗ Zusammenprall unterschiedlicher Betriebssysteme
∗ Zusammentreffen unterschiedlicher Unternehmenskulturen
– Marktbezogene
∗ Abwanderung wichtiger Kunden
∗ Ineffizienzen im Umgang mit wissensbasiertem Kunden-Kapital
∗ Hard- und Softwarelieferanten
∗ Einsatz von Unternehmensberatern
∗ Konkurrenz
∗ Bedrohung durch Substitute
• wissensbasierte Risiken
– falsches Wissen
∗ Falsche Informationen / Daten
∗ Falsche Interpretation
∗ Fehlerhaftes Berechnungsmaterial
∗ Fehlerhafte Schätzung
∗ Manipulation
– verstecktes Wissen
∗ Fehlende Überschaubarkeit
∗ Nichtnutzung (=nicht zureichende Aktivierung)
∗ Fehlende Bereitschaft zur Wissensteilung
∗ Fehlende Bereitschaft Wissen anzuwenden / einzusetzen
∗ Datenfriedhof
∗ Translation / Kodifizierung
– unzureichendes Wissen
∗ Unzureichende Bildung
∗ Unzureichende Vorbereitung
∗ Zu wenig Ressourcen / Quellen / Daten (-material)
∗ Unzureichende Kenntnis der Ziele und Rahmenbedingungen
∗ Fehlende Qualifikation für die Rolle
∗ Fehlendes Bewusstsein für notwendige Fachkräfte
– Wissenstransfer
117

∗ Mangelhafte Infrastruktur
∗ Organisationsmangel (Prozess, Handlung)
∗ Kulturunterschiede
∗ Menschliche Barrieren
∗ Fehlender Anwendungskontext
– falsche Nutzung
∗ Zielkonflikte - Menschen und Unternehmen
∗ Unzureichende Internalisierung
∗ Irrationale Entscheidungen
∗ Manipulation (von außen)
∗ Unzureichendes Wissen über Auswirkungen
118

B. Generischer Maßnahmen Katalog für
Wissensrisiken
• wissensgefährdende Risiken
– Personelle
∗ Beteiligung am Unternehmenserfolg
∗ Leistungsabhängige Entlohnung
∗ Mindestbeschäftigungsdauer
∗ Flexible Arbeitszeitgestaltung
∗ Eigenverantwortliches Handeln fördern
∗ Sonderleistungen
∗ Ausbildung über den eigentlichen Bedarf
∗ Einsatz von Springergruppen
∗ Gründung von Beratungs-Spin-Offs
∗ Gründung einer Auffanggesellschaft
∗ Innovative Formen der Aus- und Weiterbildung
∗ Risikobewusste Personalauswahl
∗ Sensibilisierungsprogramme
∗ Ethiktraining
∗ Lern- und innovationsfreudiges Unternehmensklima
∗ Expertenverzeichnisse
∗ Wissenskarten
∗ Interner Transparenzschaffer
∗ Bauliche Veränderungen
∗ Anreiz-Beitrag Systeme
∗ Einsatz von Management-Informationssystemen
119

∗ Fokussierte Schulungsmaßnahmen
∗ Einrichtung einer Corporate University
∗ Mentorkonzept
∗ Expertensysteme
∗ Personalgarantieversicherung
– Sachlich-technische
∗ Verzicht auf Kodifizierung von Wissen
∗ Objekt-, Gebäude-, Raumsicherung
∗ Elektronisch gesicherte Stahlschränke
∗ Schlösser
∗ Tastatur- und Festplattenverriegelungen
∗ Identifikationskarten
∗ Gehäuseverplombungen
∗ Passwörter
∗ Zweischlüsselverfahren
∗ Kartenlesesysteme
∗ Identifikationstoken
∗ Internet-Firewalls
∗ Verschlüsselungstechniken
∗ Digitale Unterschriften
∗ Zertifizierte Software
∗ Keine Verwendung fremder Software
∗ Virensuchprogramme
∗ Schutzmaßnahmen für digitale Kommunikationsanlagen
∗ Anwenderschulungen
∗ IT-Sicherheitsverantwortlicher
∗ Diebstahl-, Feuer- u.ä. Versicherungen
– Organisatorische
∗ Systematische Job-Rotation
∗ Teambasierte Honorierung von Wissensaustausch
∗ Flexibilisierung und Entbürokratisierung unzeitgemäßer Regelungen
∗ Strategy-based-lending
120

∗ Netgraphing-Methode
∗ Alternierende Telearbeit
∗ Telearbeitszentren
∗ Funktionsweise der Dorfgemeinschaft
∗ Offene Gebäudearrangements
∗ Verglaste Räume
∗ Vermeidung von Wissensinseln
∗ Wissensorientierte Reengineering Lösung
∗ Puffer für Lern- und Kommunikationsmöglichkeiten
∗ Bildung heterogen zusammengesetzer Teams
∗ Matrix der Normwissensstrategien
∗ Übernahme ganzer Arbeitsschritte en bloc
∗ Frühzeitige Einbeziehung der Mitarbeiter
∗ Schnelle, klare Personalentscheidungen
∗ Abbau der Abwehrhaltung von Mitarbeitern
∗ Offene und umfassende Kommunikation
∗ Bewusstmachung von Unterschieden
∗ Kulturmanagement
∗ Kulturverantwortlicher
∗ Abbau von Wissensbarrieren
∗ Ausschluss von Tabubereichen beim Transfer
∗ Ausbau der Lernkapazität
∗ Verankerung kritischen Wissens
∗ Aufbau wechselseitiger Abhängigkeiten
∗ Berücksichtigung individueller historischer Entwicklung
∗ Checkliste
– Marktbezogene
∗ Relationship
∗ Servicegarantien
∗ Treuepunkte
∗ Database-Marketing
∗ Aufbau von Kompetenzen
121

∗ Befriedigung von Kundenwünschen
∗ Festlegung von Wissenszielen
∗ Lessons-learned Seminare
∗ Bemessung von Honorare am Beratungserfolg
∗ Kritische Selektion der Unternehmensberater
∗ Vereinbarung Konkurrenzverbots
∗ Prüfung Notwendigkeit des Beratereinsatzes
∗ Kompetenzen Audit
• wissensbasierte Risiken
– Kommunikation
∗ IP-Telephonie
∗ Videokonferenzen
∗ Chaträume
∗ Instant Messaging
∗ SMS
∗ E-Mail
∗ Diskussionsforen
∗ Audio- und Videonachrichten
∗ Unified Messaging
– Zusammenarbeit
∗ Shared Spaces
∗ Echtzeit Zusammenarbeit
∗ Ideensammlung
∗ Collaborative Writing
∗ Asynchrone Zusammenarbeit
∗ File Sharing
∗ Wählmechanismen
∗ Collaborative organizing
∗ Wiki webs
∗ Gruppenunterstützende Systeme
∗ Workflow Management
122

– Erstellen von Inhalten
∗ Autorensysteme
∗ Erläuterungen
∗ Stimulieren der Kreativität
∗ Handlungsstrukturen
∗ Anreicherung von Dokumenten
∗ Expertise Profiling
∗ Data mining
– Inhalt Management
∗ Verbinden von Inhalten
∗ Metadaten
∗ Speicherung
∗ Versioning
∗ Klassifikation
∗ Link Management
∗ Retrieval
∗ Ausgabe
∗ Workflow
∗ Sicherheit
– Adaptierung
∗ Customization
∗ Personalisierung
∗ Recommender Systems
∗ Dokument Adaptierung
∗ Data warehousing
∗ Portale
∗ Visualisierung
∗ Wissenslandkarten
– E-Learning
∗ Computerbasiertes Lernen
∗ Webbasiertes Lernen
∗ E-Learning
123

∗ Autorensysteme
∗ Administration
∗ Zuführung
∗ Kommunikation
∗ Testen
∗ Feedback
– Personelle Werkzeuge
∗ Organisation und Notizenführung
∗ Capturing
∗ Retrieving
∗ Tagebücher
∗ Bookmark Management
∗ Persönliche Datenbanken
∗ Integrierte Werkzeuge
– Künstliche Intelligenz
∗ Wissenspräsentation
∗ Expertensysteme und Fuzzy Logik
∗ Natural language processing
∗ Analyse von Dokumenten
∗ Automatisches Zusammenfassen
∗ Maschinelles Lernen
∗ Segmentation und Klassifikation
∗ Intelligent agents
– Netzwerke
∗ Intranetze und Extranetze
∗ Verzeichnisservices
∗ E-Mail
∗ Web Server
∗ Web Browser
124

C. Logik
Abbildung C.1.: Logik
125

D. Personas
D.1. Heiner Rumpler
Abbildung D.1.: Primäre Persona: Heiner Rumpler
Erfahrener Projektmanager mit geringen Kenntnissen über Wissensrisiken
Heiner Rumpler ist 50 Jahre alt, verheiratet und hat ein Kind. Er ist schon seit 15 Jahren
in der IT-Firma Metapicture beschäftigt. Vor 10 Jahren wurde er zum Projektmanager
befördert und übt diese Funktion seit damals ununterbrochen aus. Er verwendet den
Computer täglich, hauptsächlich Microsoft Word, Excel und Outlook.
Wie man aus der kurzen Beschreibung erkennen kann hat er bereits viel Erfahrung auf
dem Gebiet Risikomanagement. Beginnt er ein neues Projekt, weiß er ungefähr welche
Risiken durch das Projekt entstehen und wie er sie handhabt. Beispielsweise musste er
schon oft Notfallspläne entwickeln oder ergreifen, wenn sich ein Risiko in ein Problem
materialisierte. Solches Wissen hilft ihm im alltäglichen Risikomanagement weiter. Er
fühlt sich sicher und verzichtet darauf Risiken zu dokumentieren oder bereits Maßnahmen
für ihr mögliches Eintreten zu planen.
Mit Wissensmanagement hatte er bis jetzt wenig Kontakt, aber da seine Vorgesetzten
126

entdeckten, dass sie als IT-Unternehmen besonders durch Wissensrisiken betroffen sind,
und nun dieses Softwaresystem einsetzen wollen, hat er sich ein wenig mit dem Thema
Wissenskapital und deren möglicher Verlust auseinandergesetzt. Er sieht das Thema als
wichtig an, da er schon oft genug miterlebte, wie die Kündigung eines Mitarbeiters Lücken
hinterließ und sich Projekte zeitlich verzögerten.
Dennoch möchte er nicht zuviel Zeit mit der Erfassung und Handhabung der Risiken
verbringen. Er möchte nicht gezwungen sein, sich durch viele Fenster zu klicken, wenn er
genau weiß, wie das Risiko aussieht und wie er es behandeln möchte. Er möchte sich nicht
lange mit Risiken beschäftigen, die kaum gefährdend auf das Unternehmen wirken. Das
Bewertungsschema und der Risikomanagementprozess sollten dem des ursprünglichen
RM ähnlich sein. Allerdings braucht er Unterstützung bei der Identifikation, Bewertung
von Risiken und der Entwicklung von passenden Steuerungsmaßnahmen. Die Behandlung
der Wissensrisiken soll im selben Softwaresystem erfolgen, wie die der "normalen"Risiken.
127

D.2. Friedrich Kracher
Abbildung D.2.: Sekundäre Persona: Friedrich Kracher
Unerfahrener Projektmanager mit geringen Kenntnissen über Wissensrisiken
Friedrich Kracher ist 30 Jahre alt, verlobt und hat keine Kinder. Seine Computerkennt-
nisse sind sehr gut.
Er ist seit 5 Jahren bei der IT Firma Metapicture beschäftigt. Er arbeitete als Software-
entwickler für 5 Jahre in dieser Firma und ist vor kurzem zum Projektmanager in diesem
Bereich aufgestiegen. Für ihn sind die meisten Arbeitschritte neu und es ist sehr schwierig
für ihn sich einzuarbeiten. Er hat zwar einige Kurse über Projektmanagement besucht,
aber Theorie und Praxis sind sehr unterschiedlich. Oft fragt er andere Projektmanager
um Rat, aber er möchte ihnen nicht lästig sein und so macht er manchmal Fehler im
Projektmanagement. Der Grund liegt hauptsächlich in seiner Unerfahrenheit.
Das Risikomanagement für ein Projekt wichtig ist, wurde ihn in den Kursen gelernt
und er versucht, dass dort erlangte Wissen umzusetzen. Notiert sich die wichtigsten
Risiken in Formularen (die im Kurs ausgeteilt wurden) und folgt den dort vorgeschlagenen
Schritten: Risikobeschreibung, Bewertung, Entwicklung von Steuerungsmaßnahmen und
Überwachung. All diese Informationen trägt er sorgfältig in die Formulare ein, ist sich
aber oft nicht sicher, ob seine Bewertung richtig ist oder ob er alle entscheidenden Risiken
identifizieren konnte.
Über Wissensmanagement hat er ebenfalls einen Kurs besucht, aber kaum praktische
Erfahrung. Momentan hätte er gerne eine zentrale Wissensdatenbank, wo er auf das
128

Wissen anderer Projektmanager zugreifen kann, ohne sie ständig, fragen zu müssen.
Friedrich Kracher möchte eine Software, die ihm beim Risikomanagement sehr unter-
stützt. Die ihm vor allem auf das Wissen anderer Projektmanager zugreifen lässt. Er
möchte durch sie, und nicht durch eigene Fehler, lernen. Er braucht Unterstützung im her-
kömmlichen Risikomanagement als auch im Management von Wissensrisiken. Es macht
ihm nichts aus, sich durch mehrere Fenster zu klicken um zu seinem Ziel zu gelangen.
129

E. Use Cases
Name Eröffnen eines neuen Projektes
ID 1
Ziel Eröffnen eines neuen Projektes im K@R Tool durch die
Eingabe der Projekt-Metadaten, Arbeitspakete und zugehörige
Arbeitspaketleiter.
Häufigkeit Unregelmäßig, jeweils am Beginn eines neuen Projektes
Rolle Projektleiter
Precondition Projektleiter am K@R Tool angemeldet
Postcondition Neues Projekt im K@R Tool beschrieben; Metadaten erfasst;
Arbeitspakete mit zugehörigen Leiter erfasst
Standardablauf 1. Der Projektleiter wählt die Option Neues Projekt anlegen.
2. Es öffnet sich eine Eingabemaske in der der Projektleiter
die Metadaten des Projekts erfassen kann.
3. Der Projektleiter speichert die Metadaten und erhält
eine Maske zur Erfassung der Arbeitspakete
4. Hier erfasst er jeweils ein neues Arbeitspaket und definiert
in welchen Zusammenhang es zu den anderen steht.
Außerdem weißt er jedem Paket eine Person als Arbeitspaketleiter
aus der Personendatenbank zu.
5. Abschließend speichert der Projektleiter seine Eingaben
Prototyp Diese Eingaben könnten beim Prototyp direkt in der Datenbank
und ohne Maske erfolgen, da der Prototyp auf
ein Projekt spezifiziert ist..
Tabelle E.1.: Use Case 1 - Eröffnen eines neuen Projektes
130

Name Eingabe von neuen Wissensrisiken
ID 2
Ziel Neue Risiken in das K@R Tool einpflegen
Häufigkeit Unregelmäßig
Rolle Projektleiter, Arbeitspaketleiter
Precondition Projektleiter / Arbeitspaketleiter am K@R Tool angemeldet;
Projekteigenschaften im System erfasst;
Postcondition Neues Risiko in der Datenbank erfasst
Standardablauf 1. Der Projektleiter / Arbeitspaketleiter wählt die Option
neues Risiko erfassen aus.
Der Projektleiter erfasst nun das Wissensrisiko in der erscheinenden
Eingabemaske Alternative 1, Alternative
2
3. Teil der Erfassung eines Risikos ist die Zuordnung eines
Risk Owners (aus der Personendatenbank) zum jeweiligen
Risiko. Für die weitere Verwaltung des Risikos ist dieser
verantwortlich.
4. Er speichert das Risiko, dabei fügt das System Informationen,
wie Risiko Identifikationsnummer, Identifikationsdatum
etc. automatisch dem Datenbankeintrag bei.
Alternative 1 Erfassung eines Wissensrisikos anhand der Projekteigenschaften
A1.1. Das System schlägt aufgrund der eingegebenen Projekteigenschaften
dem Benutzer verschiedene generische
Wissensrisiken vor.
A1.2. Der Projektleiter / Arbeitspaketleiter wählt ein Risiko
aus der Liste aus.
A1.3. Das System übernimmt die Daten des generischen
Wissensrisikos in die Eingabemaske und der Projektleiter
/ Arbeitspaketleiter füllt die restlichen Elemente der
Maske aus bzw. ändert bestehende Einträge.
Alternative 2 Unterstützung der Erfassung eines Wissensrisikos
anhand von ähnlichen (historischen) Risiken
A2.1. Das System schlägt aufgrund von speziellen Suchwörtern
bereits in anderen Projekten erfasste Wissensrisiken
vor.
A2.2. Der Projektleiter / Arbeitspaketleiter wählt ein Risiko
aus der Liste aus.
A2.3. Das System übernimmt die Daten dieses Wissensrisikos
in die Eingabemaske und der Projektleiter / Arbeitspaketleiter
passt die Einträge seinem Projekt an.
Prototyp Im ersten Schritt der Prototypentwicklung sollte der
Standardablauf als auch die Alternative 1 umgesetzt werden.
Alternative 2 ist im ersten Schritt aufgrund der fehlenden
historischen Daten schwer umsetzbar.
Tabelle E.2.: Use Case 2 - Eingabe von neuen Wissensrisiken
131

Name Bewerten eines Wissensrisikos
ID 3
Ziel Qualitative und Quantitative Bewertung eines Risikos
Häufigkeit Regelmäßig / Unregelmäßig
Rolle Risk Owner
Precondition Risk Owner am K@R Tool angemeldet; Wissensrisiken
identifiziert und dem Risk Owner zugeordnet;
Postcondition Bewertung des Risikos hinsichtlich dessen Auswirkung
und Eintrittswahrscheinlichkeit
Standardablauf 1. Der Projektleiter / Arbeitspaketleiter wählt die Option
Risiko bewerten aus.
2. Er bewertet das Risiko nach der von Turek vorgeschlagenen
Methodik zur Bewertung von Wissensrisiken.
3. Er speichert die Bewertung des Risikos ab.
Prototyp JA
Tabelle E.3.: Use Case 3 - Bewerten eines Wissensrisikos
132

Name Erfassen einer Maßnahme für ein Wissensrisiko
ID 4
Ziel Entwickeln einer passenden Maßnahme für ein identifiziertes,
bewertetes Wissensrisiko
Häufigkeit Unregelmäßig
Rolle Risk Owner
Precondition Risk Owner am K@R Tool angemeldet; Wissensrisiko
identifiziert und dem Risk Owner zugewiesen; Wissensrisiko
bereits vom Risk Owner bewertet;
Postcondition Weiterer Umgang mit dem Wissensrisiko geplant und dokumentiert
Standardablauf 1. Der Risk Owner wählt die Option Maßnahme erfassen
aus.
2. Der Risk Owner erfasst nun die Maßnahme in der erscheinenden
Eingabemaske Alternative 1, Alternative
2
3. Er speichert das Risiko, dabei verknüpft das System
das Risiko mit der eingegebenen Maßnahme Alternativen
Alternative 1 Erfassung einer Maßnahme anhand des generischen
Maßnahmenkataloges
A1.1. Das System schlägt aufgrund des generischen Risikos,
von dem das Wissensrisiko abgeleitet wurde, mehrere
Maßnahmen zum Umgang mit dem Risiko vor.
A1.2. Der Risk Owner wählt ein Risiko aus der Liste aus.
A1.3. Das System übernimmt die Daten der generischen
Maßnahme in die Eingabemaske und der Risk Owner füllt
die restlichen Elemente der Maske aus bzw. ändert bestehende
Einträge.
Alternative 2 Erfassung einer Maßnahme mit der Unterstützung
durch auf ähnliche Risiken bereits angewendete
Maßnahmen
A2.1. Das System schlägt aufgrund einer Ähnlichkeitssuche
über die Risiken bereits in anderen Projekten erfasste
Maßnahmen vor.
A2.2. Der Risk Owner wählt ein Risiko aus der Liste aus.
A2.3. Das System übernimmt die Daten der ausgewählten
Maßnahme in die Eingabemaske und der Risk Owner
passt die Einträge an.
Prototyp Im ersten Schritt der Prototypentwicklung sollte der
Standardablauf als auch die Alternative 1 umgesetzt werden.
Alternative 2 ist im ersten Schritt aufgrund der fehlenden
historischen Daten schwer umsetzbar.
Tabelle E.4.: Use Case 4 - Erfassen einer Maßnahme für ein Wissensrisiko
133

Name Ansicht der persönlichen Wissensrisiken
ID 5
Ziel Dem Risk Owner einen schnellen Überblick über die Risiken,
für die er verantwortlich ist, zu bieten.
Häufigkeit Regelmäßig
Rolle Risk Owner
Precondition Risk Owner am K@R Tool angemeldet; Wissensrisiko
identifiziert und dem Risk Owner zugewiesen;
Postcondition Risk Owner besitzt aktuelle Informationen über ßeine"Wissensrisiken.
Standardablauf 1. Der Risk Owner wählt die Option My Risks aus.
2. Es erscheint eine Ansicht mit allen Risiken für die der
Risiko Owner verantwortlich ist.
Prototyp JA
Tabelle E.5.: Use Case 5 - Ansicht der persönlichen Wissensrisiken
Name Über die Veränderung eines Wissensrisikos berichten
ID 6
Ziel Aktuelle Bewertungsdaten für Risiken und die Möglichkeit
deren historischen Verlauf darzustellen.
Häufigkeit Unregelmäßig
Rolle Risk Owner
Precondition Risk Owner am K@R Tool angemeldet; Wissensrisiko
identifiziert und dem Risk Owner zugewiesen; Wissensrisiko
bereits vom Risk Owner bewertet;
Postcondition Neue Bewertung eines Wissensrisikos
Standardablauf 1. Der Risk Owner wählt die Option Reporting aus.
2. Es erscheint die Detailansicht des Risikos
3. Dort kann der Risk Owner, die Bewertung des Risikos
ändern, Anmerkungen zum Risiko machen, die Maßnahmen
eines Risikos verwalten.
4. Er speichert seine Eingaben.
Prototyp JA
Tabelle E.6.: Use Case 6 - Über die Veränderung eines Wissensrisikos berichten
134

Name Ansicht aller Wissensrisiken
ID 7
Ziel Alle Risiken im Projekt / Arbeitspaket anzeigen, damit
der Projektleiter / Arbeitspaketleiter einen Überblick
über alle Risiken in seinem Bereich bekommt.
Häufigkeit Regelmäßig
Rolle Projektleiter / Arbeitspaketleiter
Precondition Projektleiter / Arbeitspaketleiter am K@R Tool angemeldet;
Projekteigenschaften am System erfasst; Risiken
identifiziert;
Postcondition Darstellung aller Risiken
Standardablauf 1. Der Projektleiter / Arbeitspaketleiter wählt die Option
All Risks aus.
2. Es erscheinen alle Wissensrisiken im Projekt bzw. Arbeitspaket
Prototyp JA.
Tabelle E.7.: Use Case 7 - Ansicht aller Wissensrisiken
Name Ansicht der TOP 10 Wissensrisiken
ID 8
Ziel Die Top 10 Risiken im Projekt / Arbeitspaket anzeigen,
damit der Projektleiter / Arbeitspaketleiter einen Überblick
über die wichtigsten Risiken in seinem Bereich bekommt.
Häufigkeit Regelmäßig
Rolle Projektleiter / Arbeitspaketleiter
Precondition Projektleiter / Arbeitspaketleiter am K@R Tool angemeldet;
Projekteigenschaften am System erfasst; Risiken
identifiziert und bewertet;
Postcondition Darstellung der Top 10 Risiken
Standardablauf 1. Der Projektleiter / Arbeitspaketleiter wählt die Option
Top 10 Risks aus.
2. Es erscheinen die Top 10 Wissensrisiken im Projekt
bzw. Arbeitspaket
Prototyp JA.
Tabelle E.8.: Use Case 8 - Ansicht der TOP 10 Wissensrisiken
135

Name Suchen von Wissensrisiken
ID 9
Ziel Risiken im aktuellen Projekt / Arbeitspaket leicht zu finden.
Häufigkeit Unregelmäßig
Rolle Projektleiter / Arbeitspaketleiter
Precondition Projektleiter / Arbeitspaketleiter am K@R Tool angemeldet;
Projekteigenschaften am System erfasst; Risiken
identifiziert;
Postcondition Erfolgreiche Suche eines Wissensrisikos
Standardablauf 1. Der Projektleiter / Arbeitspaketleiter wählt die Option
Risk Search aus.
2. Er gibt seine Suchparameter ein und bestätigt sie
3. Jetzt erhält er eine Liste mit allen Risiken die diesen
Suchparametern entsprechen Alternativen
Prototyp JA.
Tabelle E.9.: Use Case 9 - Suchen von Wissensrisiken
Name Ansicht der persönlichen Aufgaben
ID 10
Ziel Überblick über Tätigkeiten
Häufigkeit Regelmäßig
Rolle Risk Owner
Precondition Projektleiter / Arbeitspaketleiter am K@R Tool angemeldet;
Projekteigenschaften am System erfasst; Risiken
identifiziert;
Postcondition Risk Owner besitzt aktuelle Informationen über ßeine"Tätigkeiten.
Standardablauf 1. Der Risk Owner wählt die Option My Tasks aus.
2. Es erscheint eine Ansicht mit allen Tätigkeiten, die der
Risk Owner noch durchführen sollte.
Prototyp JA.
Tabelle E.10.: Use Case 10 - Ansicht der persönlichen Aufgaben
136

F. Vollständiges Klassendiagramm
Abbildung F.1.: Vollständiges Klassendiagramm Knowledge@Risk Prototyp
137

Literaturverzeichnis
[APM97] APM. The Association for Project Management: Project risk analysis and
management. 1997
[BDR01] Ben-David, I ; Raz, T: An integrated approach for risk response develop-
ment in project planning. In: Journal of the Operational Research Society 52
(2001), S. 14–25
[Ber02] Bernstein, Peter L.: Wider die Götter. Deutscher Taschenbuch Verlag,
2002. – ISBN: 3423308354
[Boe89] Boehm, Barry W.: Tutorial: Software risk management. IEEE Computer
Society Press, 1989
[Bro99] Broadleaf. Tutorial notes: The Australian and New Zealand standard on
risk management, AS/NZS 4360:1999. 1999
[CC04] Coleman, Les ; Casselman, R. M. What you don’t know can hurt you:
Towards an integrated theory of knowledge and corporate risk. Working Paper
Series, Departement of Management, University of Melbourne. 2004
[Cha97] Chapman, Chris: Project risk analysis and management - PRAM the generic
process. In: International Journal of Project Management 15 (1997)
[CKM + 93] Carr, Marvin J. ; Konda, Suresh L. ; Monarch, Ira ; Ulrich, F. C. ;
Walker, Clay F. Taxonomy-based risk identification. Technical Report,
Software Engineering Institute CMU. June 1993
[Coc95] Cockburn, Alistair. Structuring use cases with goals. 1995
[Coc01] Cockburn, Alistair: Writing effective use cases. Addison-Wesley, 2001. –
ISBN: 0201702258
138

[Con99] Conallen, Jim: Modeling web application architectures with UML. In:
Communications of the ACM (1999)
[Coo99] Cooper, Alan: The inmates are running the asylum. SAMS, 1999. – ISBN:
0672316498
[COS04] COSO. Enterprise risk management - Integrated framework. 2004
[DP98] Davenport, Thomas H. ; Prusak, Laurence: Working knowledge. How
organizations manage what they know. Harvard Business School Press, 1998.
– ISBN: 00875846556
[DWA + 96] Dorofee, Audrey J. ; Walker, Julie A. ; Alberts, Christopher J. ; Higue-
ra, Ronald P. ; Williams, Ray C.: Continuous risk management guidebook.
Carnegie Mellon Software Engineering Institute, 1996
[FER02] FERMA. Federation of European Risk Management Association: A risk ma-
nagement standard. 2002
[FGRD02] Fisher, Keevin ; Greanias, George ; Rose, Jim ; Dumas, Robin: Risk ma-
nagement tools for complex project organizations. In: Aerospace Conference
Proceedings, IEEE, 2002, S. 721–727
[FS00] Fowler, Martin ; Scott, Kendall: UML konzentriert. Eine strukturier-
te Einführung in die Standard-Objektmodellierungssprache. Addison-Wesley,
2000. – ISBN: 3827316170
[GPW97] Garvey, Paul R. ; Phair, Douglas J. ; Wilson, John A.: An information
architecture for risk assessment and management. In: IEEE Software 14
(1997), May, Nr. 3, S. 25–34
[HH02] Hall, Dave ; Hulett, David. Universal risk project, final report. Risk
Special Interest Group, PMI. 2002
[Hil99] Hillson, David: Developing effective risk responses. In: Proceedings of the
30th Annual Project Management Institute, 1999
[Hil02a] Hillson, David: The risk breakdown structure (RBS) as aid to effective
risk management. In: Fifth European Project Management Conference PMI
Europe, 2002

[Hil02b] Hillson, David: Success in risk management. In: Project Management Re-
view (2002)
[Hil02c] Hillson, David: What is risk?/Towards a common definition. In: InfoRM
Magazine (2002), April
[HRD99] Hornung, K. ; Reichmann, T. ; Diederichs, M.: Risikomanagement,
Teil 1: Konzeptionelle Ansätze zur pragmatischen Realisierung gesetzlicher
Anforderungen. 11 (1999), S. 317–325
[IRM02] IRM. Institute of Riskmanagement: A risk management standard. 2002
[Kei05] Keith, Andrews. Human computer interaction. IICM, Technical University
Graz. 2005
[Kle01] de Klerk, Antonie M.: The value of project risk management. In: Mana-
gement of Engineering and Technology (2001)
[Klo90] Kloman, H. F.: Risk management agonists. In: Risk Analysis 10 (1990)
[Kob99] Kobi, Jean-Marcel: Personalrisikomanagement / Eine neue Dimension im
Human Resources Management: Strategien zur Steigerung des People Value.
Gabler Verlag, 1999. – ISBN: 3409114688
[Kol05] Koller, Stefan. Knowledge@Risk, Framework zur Identifikation und
Handhabung von Wissensrisiken / Exposé eines Dissertationsvorhabens an
der Sozial- und Wirtschaftswissenschaftlichen Fakultät. Karl-Franzens-
Universität Graz. Jänner 2005
[Kon01] Kontio, Jyrki: Software engineering risk management / A method, improve-
ment framework, and empirical evaluation, Helsinki University of Technology,
Diss., September 2001
[LFTR03] de Landa Farias, Luciana ; Travassos, Guilherme H. ; Rocha, Ana R.:
Managing organizational risk knowledge. In: Journal of Universal Computer
Science 9 (2003)
[LKK04] Lindstaedt, Stefanie N. ; Koller, Stefan ; Krämer, Thomas: Eine Wis-
sensinfrastruktur für Projektrisikomanagement - Identifikation und Manage-
ment von Wissensrisiken. In: Tagungsband zur KnowTech, 2004, S. 367–375

[Lor02] Lord, Chris: Software project risk management: Why is it hard and what
can be done. In: Risk Analysis 10 (2002)
[Mel98] Meli, Roberto: SAFE: A method to understand, reduce, and accept project
risk. In: ESCOM-ENCRESS 98, Project Control for 2000 and Beyond, 1998,
S. 18
[Mos04] Moser, Thomas. Beschreibungselemente für Wissensrisiken. Seminararbeit
am IICM, Technische Universität Graz. 2004
[Nie00] Nielsen, Jakob: Designing web usability. New Riders Publishing, 2000. –
ISBN: 156205810X
[NT95] Nonaka, Ikujiro ; Takeuchi, Hirotaka: The knowledge-creating company.
How japanese companies create the dynamics of innovation. Oxford Univ.
Press, 1995. – ISBN: 0195092694
[OCJG98] O’Dell, Carla ; C. Jackson Grayson, JR.: If only we knew what we know.
the transfer of internal knowledge and best practice. The Free Press, 1998. –
ISBN: 0684844745
[o.V13] o.V.: Webster’s Revised Unabridged Dictionary. 1913. – zit. nach [Kon01]
[o.V96] o.V.: Merriam-Webster’s Dictionary of Law. Merriam-Webster Inc., 1996
[PK98] Probst, Gilbert J. ; Knaese, Birgit: Risikofaktor Wissen / Wie Banken
sich vor Wissensverlusten schützen. Gabler Verlag, 1998. – ISBN: 3409189807
[PMI04] PMI: Project Management Institute: A guide to the project management
body of knowlegde (PMBok Guide). 3. Project Management Institue, 2004. –
ISBN: 193069945X
[Pol66] Polanyi, Míchael: The Tacit Dimension. Doubleday, 1966
[Por99] Porter, Michael E.: Wettbewerbsstrategie. Campus Fachbuch, 1999. – ISBN:
3593361779
[PRR03] Probst, Gilbert ; Raub, Steffen ; Romhardt, Kai: Wissen managen.
Gabler, 2003. – ISBN: 3409493174
[PRS02] Preece, Jennifer ; Rogers, Yvonne ; Sharp, Helen: Interaction design:
Beyond human-computer interaction. John Wiley & Sons, 2002. – ISBN:
0471492787

[Rol03] Rollett, Herwig: Knowledge management. Processes and technologies. Klu-
wer Academic Publishers, 2003. – ISBN: 1402071698
[Sch02] Scheir, Peter: Wissensmanagement zur Unterstützung von Kundenbezie-
hungsmanagement, Technische Universität Graz, Diplomarbeit, 2002
[Sch03] Schmiderer, Johannes: Webapplikationen mit Unterstützung von XML, Uni-
versität Salzburg, Diplomarbeit, April 2003
[SNC98] SNC. State of North Carolina: Risk assessment and management process
(RAMP). 1998
[Tur05] Turek, Maria: Bewertung von Wissensrisiken. Vergleich von Modellen des
Risikomanagements zur Bewertung von Wissensrisiken, Fachhochschule Ei-
senstadt, Diplomarbeit, 2005
[ZM01] Zbinden, Daniela ; Meyer, Peter. Wissensrisiko-Management / Ein Vor-
gehen zur Identifizierung und Bewertung von Wissensrisiken als Problemlö-
sungsinstrument. Reihe A: Discussion Papers der Fachhochschule Solothurn.
2001