Implementierung
eines wissensbasierten Informationssystems
in die industrielle Prozessumgebung
zur Erlangung des akademischen Grades eines
DOKTORS DER INGENIEURWISSENSCHAFTEN (Dr.-Ing.)
der Fakultät für Maschinenbau
der Universität Paderborn
genehmigte
DISSERTATION
von
Dipl.-Wirt.-Ing. Volker Huneke
aus Minden
Tag des Kolloquiums: 07. Januar 2008
Referent: Prof. Dr.-Ing. Rainer Koch
Korreferent: Prof. Dr. rer. nat. Reinhard Keil
Vorwort
Die vorliegende Arbeit entstand während meiner Tätigkeit bei der Hella Leuchten-Systeme
GmbH. Das Projekt zur Implementierung eines wissensbasierten Informationssystems
wurde in einer Kooperation mit dem Lehrstuhl für Computeranwendung und Integration in
Konstruktion und Planung (C.I.K.) der Universität Paderborn durchgeführt.
Dem Leiter des Lehrstuhls, Herrn Prof. Dr.-Ing. Rainer Koch, danke ich für die Förderung
und Unterstützung dieser Arbeit. Ihm danke ich ebenso für die kritische Auseinanderset-
zung mit dem wissenschaftlichen Inhalt und seine vielen Hinweise, die zu dieser Arbeit
beigetragen haben.
Herrn Prof. Dr. rer. nat. Reinhard Keil danke ich für die Übernahme des Korreferats.
Ebenso danke ich Herrn Dr.-Ing. Bruno Hüsgen, Leiter des Bereichs Technik bei der Hella
Leuchten-Systeme GmbH, für die gute Zusammenarbeit und die Möglichkeit, das Konzept
in der Praxis umzusetzen. Herrn Markus Westermilies, Leiter HLS-TP, danke ich für die
persönliche Unterstützung und den Freiraum zur Erstellung dieser Arbeit. Allen Kollegen
aus den Abteilungen HLS-TP und HLS-TG danke ich für die angenehme Atmosphäre im
gemeinsamen Büro.
Ein ganz herzlicher Dank gebührt meiner lieben Freundin Evelyn für ihre Geduld und das
Verständnis für die Entbehrungen bei der Erstellung der Arbeit.
Abschließend gilt ein liebevoller Dank meinen Eltern Gerd und Brigitte Huneke für die
jahrelange Unterstützung, ohne die mein Studium nicht möglich gewesen und diese Arbeit
niemals entstanden wäre. Ihr Anteil ist nicht in Worte zu fassen.
München, im Januar 2008 Volker Huneke
INHALTSVERZEICHNIS SEITE I
Inhaltsverzeichnis
Inhaltsverzeichnis I
Übersicht über verwendete Abkürzungen V
1 Einleitung 1
1.1 Problemstellung und Handlungsbedarf 1
1.2 Zielsetzung der Arbeit 2
1.2.1 Theoretischer Hintergrund 2
1.2.2 Anwendungsbereich des Pilotsystems 3
1.3 Aufbau und Vorgehensweise 3
2 Die Begriffe Implementierung und wissensbasiertes Informationssystem –
eine Einführung in den Untersuchungsgegenstand 7
2.1 Verständnis des Begriffs „Implementierung“ 7
2.2 Inhaltliche Eingrenzung eines „wissensbasierten Informationssystems“ 9
3 Analyserahmen der Wissensmanagementforschung als Voraussetzung für
den Umgang mit Wissen 13
3.1 Forschungsstand im „Wissensmanagement“ 13
3.1.1 Eingrenzung des umfassenden Begriffs „Wissen“ 14
3.1.2 Das Management des Wissens 17
3.1.3 Grundlegende Wissensmanagement-Strategien 18
3.1.4 Eingesetzte Werkzeuge zur Realisierung eines Wissensmanagements 25
3.2 Die Lernende Organisation 27
3.2.1 Das organisationale Lernen 28
3.2.2 Lernfördernde und lernhemmende Mechanismen in lernenden Organisationen 31
3.2.3 Defizite im Umgang mit Wissen 33
3.3 Anforderungen an die Unternehmenskultur 34
3.3.1 Die Bedeutung der Unternehmenskultur 34
3.3.2 Charakterisierung einer wissensorientierten Unternehmenskultur 36
3.3.3 Verknüpfung mit den Unternehmenszielen 37
3.3.4 Möglichkeiten eines Kulturwandels 38
3.4 Messung und Bewertung von Wissen 40
3.4.1 Problemfeld Messung und Bewertung von Wissen 41
3.4.2 Die Balanced Scorecard – Das Grundmodell von KAPLAN/NORTON 42
3.4.3 Die Balanced Scorecard – Anwendung im Wissensmanagement 43
SEITE II INHALTSVERZEICHNIS
4 Erkenntnisse aus den Verfahren zur Implementierung von
Standardsoftware-Systemen 47
4.1 Standardsoftware vs. wissensbasiertes Informationssystem 47
4.2 Implementierung von Standardsoftware mit Hilfe eines Projekts 49
4.2.1 Grundlagen einer Projektorganisation im Implementierungskontext 49
4.2.2 Projektplanung und -vorbereitung 52
4.2.3 Durchführung des Projekts 55
4.3 Vorgehensweisen zur Implementierung von Standardsoftware 56
4.3.1 Grundlegende Einführungsstrategien 56
4.3.2 Phasenkonzepte zur Systemeinführung 57
4.4 Customizing und Business Process Reengineering 61
4.4.1 Customizing einer Standardsoftware 61
4.4.2 Business Process Reengineering – Eine Voraussetzung? 62
4.4.3 Anwendung des Customizing und Business Process Reengineering 63
4.5 Change Management in Standardsoftwareprojekten 64
4.5.1 Phasenmodell der Veränderung und seine Akteurs- und Handlungsebenen 65
4.5.2 Unterstützung von Erfolgsfaktoren bei ERP-Projekten durch Change Management 68
4.5.3 Gestaltung und Akzeptanz eines Veränderungsprojektes 70
4.6 Kernpunkte erfolgreicher Standardsoftware-Implementierungen und
Adaptionsmöglichkeiten für wissensbasierte Informationssysteme 72
5 Implementierungsmodell für wissensbasierte Informationssysteme in die
industrielle Prozessumgebung 75
5.1 Das Wissensmanagement als Grundlage 76
5.1.1 Anwendung eines integrationsorientierten TOM-Modells 77
5.1.2 Umsetzung einer prozessorientierten Einführungsstrategie 78
5.1.3 Einbettung in das Konzept der Lernenden Organisation 81
5.1.4 Motivation der Systemnutzer 82
5.1.5 Der wissensorientierte Implementierungsprozess 84
5.2 Projektaufbau und Start des Implementierungsvorhabens 85
5.2.1 Definition von Zielen 86
5.2.2 Aufgaben des Projektmanagements 89
5.2.3 Durchführung einer Kick-off Veranstaltung 91
5.3 Das Implementierungsprojekt als Phasenkonzept 93
5.3.1 Anwendung einer Domino-Strategie 95
5.3.2 Vorbereitungsphase 96
5.3.3 Pilotphase 98
5.3.4 Ausbauphase 101
5.3.5 Vollbetriebsphase 103
5.3.6 Vergleich mit Verfahren für Standardsoftware 105
INHALTSVERZEICHNIS SEITE III
5.4 Mitarbeiterorientiertes Change Management 106
5.4.1 Notwendigkeit einer Mitarbeiterorientierung 107
5.4.2 Ableitung des Veränderungsbedarfs aus den Unternehmens- und Projektzielen 109
5.4.3 Förderung des Veränderungsprozesses in den Phasen der Implementierung 109
5.4.4 Kultivierung der Veränderungen 112
5.5 Anpassung des Softwaresystems 113
5.5.1 Notwendigkeit einer anpassbaren Software 113
5.5.2 Einbindung der Software in die Prozesse 114
5.5.3 Einbindung des Softwareherstellers im Gesamtprojekt 115
5.6 Sicherstellung des langfristigen Erfolgs 117
5.6.1 Einrichtung eines Vorschlagswesens für die Systemnutzer 118
5.6.2 Durchführung von Review-Gesprächen 118
5.6.3 Rückkopplung zur Systementwicklung 119
5.6.4 Erfolgsorientiertes Projektmarketing 119
5.7 Goldene Regeln für die Implementierung eines wissensbasierten
Informationssystems 120
6 Instrumentarium zur Messung des Implementierungserfolgs 123
6.1 Kennzahlen für die Implementierung wissensbasierter Informationssysteme124
6.1.1 Anforderungen und Ableitung einer Kennzahl 124
6.1.2 Dimensionen für Kennzahlen 125
6.2 Nutzenmessung durch direkte Kennzahlen des wissensbasierten
Informationssystems 126
6.2.1 Messung der Nutzung des Systems 126
6.2.2 Befragung der Systemnutzer 127
6.3 Beobachtung indirekt beeinflusster Kenngrößen 128
6.3.1 Einflüsse der Implementierung auf die Mitarbeiter und die Unternehmenskultur 128
6.3.2 Verbesserung von Kennzahlen der Organisationseinheiten und Benchmarking 129
6.4 Entwurf einer Implementierungs-Scorecard 130
6.4.1 Aufbau der Implementierungs-Scorecard 130
6.4.2 Vier Perspektiven der Implementierungs-Scorecard 131
6.4.3 Verfolgung der Kennzahlen 133
6.4.4 Zusammenhänge der Perspektiven 136
7 Prototypische Anwendung des Implementierungsmodells in der
Automobilindustrie 137
7.1 Rahmenbedingungen für die Durchführung des Implementierungsprojekts 137
7.1.1 Ausgangssituation im Unternehmen 137
7.1.2 Zielsetzungen des Projekts 138
SEITE IV INHALTSVERZEICHNIS
7.2 Anwendung des Implementierungsmodells 138
7.2.1 Rolle des Projektmanagements und Phasenkonzepts 139
7.2.2 Das Change Management 141
7.2.3 Die Zusammenarbeit mit dem Softwarehersteller 141
7.2.4 Die Messung des Systemnutzens 142
7.3 Zusammenfassende Betrachtung der industriellen Praxis 142
8 Zusammenfassung und Ausblick 145
8.1 Ausgangspunkt der Arbeit 145
8.2 Methodisch konzeptionelle Vorgehensweise 145
8.3 Inhaltliche Ergebnisse 146
8.4 Weiterer Forschungsbedarf 148
Literaturverzeichnis 149
Abbildungsverzeichnis 161
ÜBERSICHT ÜBER VERWENDETE ABKÜRZUNGEN SEITE V
Übersicht über verwendete Abkürzungen
EDV Elektronische Datenverarbeitung
ERP Enterprise Resource Planning
IT Informationstechnologie
IuK Informations- und Kommunikationstechnologie
Kick-off Offizielle Startveranstaltung eines Projektes
KMU Kleine und mittlere Unternehmen
TOM Technik – Organisation - Mensch
SEITE VI
EINLEITUNG SEITE 1
1 Einleitung
„If I give you a dollar and you give me a dollar, then we have one dollar each.
But if I give you an idea and you give me an idea, we have two ideas each.
That’s the growth of intellectual capital.”
(Heinrich von Pierer)
Wissen und intellektuelles Kapital sind heute grundlegende Werte von Unternehmen und
werden in der Literatur schon als der „vierte Produktionsfaktor“ [Stew98, S. 1] bezeichnet.
Sie gelten im gleichen Zusammenhang als die „thermonuklearen Verteidigungs- und An-
griffswaffen unserer Zeit“ [Stew98, S. 7]. Ressourcen sind wertvoll und ohne ein aktives
Management ist der effiziente Umgang mit der Ressource Wissen in Unternehmen undenkbar
[Hoff05, S. 26]. Zur Unterstützung dieses Managements von Wissen werden häufig soft-
waretechnische Systeme eingesetzt. Mittlerweile steht jedoch fest, dass es „mit einem ausge-
fuchsten IT-Tool alleine nicht getan ist“ [Berg05, S. 20]. Um zu einem positiven Kosten-
Nutzen-Verhältnis von Wissensmanagement bzw. dem wissensunterstützenden System zu
gelangen, ist es wichtig, den Implementierungsprozess detailliert zu planen und alle Beteilig-
ten frühzeitig und ausführlich zu informieren [MeZi05, S. 48].
1.1 Problemstellung und Handlungsbedarf
Bekannt ist, dass die Möglichkeiten der modernen Informationstechnik es erlauben, die inner-
und zwischenbetrieblichen Prozesse zu optimieren und völlig neue Wege in der Aufgabener-
füllung zu realisieren [Öste99, S. 12]. Einerseits führen neue (Software-) Technologien zu
immer schnelleren und stärkeren Veränderungen [ScRe99, S. 56], andererseits wird weiterhin
die Frage diskutiert, wie innovative Technologien zur Unterstützung des Umgangs mit Wis-
sen eingesetzt werden können [Lehn01, S. 227]. Generell lässt sich ein Defizit an organisatio-
nalen Strukturen und Prozessen zur Wissensverbreitung und gemeinsamen Wissensverarbei-
tung identifizieren [GöSc04, S. 220].
Es existieren vielfältige und gut beschriebene Konzepte zur Auswahl, Einführung und Imple-
mentierung von betrieblichen Standardinformationssystemen in die Prozessabläufe eines
Unternehmens wie beispielsweise von BARBITSCH [Barb96], GRONAU [Gron01], KIRCHMER
[Kirc96] oder SHIELDS [Shie02]. Diese Vorgehensweisen können jedoch nicht ohne weiteres
auf die Einführung von wissensbasierten Systemen übertragen werden, da die Implementie-
rung einer Standardsoftware durch den Einsatz von Reengineering-Methoden regelmäßig den
Charakter einer Revolution annimmt [Wahl02, S. 75]. Das Arbeiten mit Wissensressourcen
dagegen ist gleichbedeutend mit einem feinfühligen Umgang mit Menschen. Die Mitarbeiter
eines Unternehmens sind die entscheidende Ressource, da sie die Träger des Wissens sind
und mit diesem „Schatz in den Köpfen“ [Pala97, S. 112] agieren.
Neben den Konzepten für die Einführung von Standardsoftware existiert eine Vielzahl von
Veröffentlichungen aus der Forschung zu dem Gebiet des Wissensmanagements. Die Unter-
SEITE 2 EINLEITUNG
suchungsansätze sind in unterschiedliche Strömungen geteilt und umfassen ein Spektrum von
globalen Wissensmanagementprozessen wie etwa nach dem Genfer Modell von PROBST /
RAUB / ROMHARDT [PrRR03] bis hin zu Unterstützungsmöglichkeiten im Wissensprozess
durch kleine oder große Softwaresysteme. Als ein erfolgskritischer Bestandteil stellt sich in
der Praxis jedoch immer wieder die Integration in die reale Unternehmensumgebung heraus.
Beispielsweise FELBERT [Felb98] stellt fest, dass Vorschläge zum Wissensmanagement oft
entweder auf einer instrumentell-technischen oder aber auf einer unternehmenskulturellen
Sichtweise beruhen. Beide Ansätze erscheinen auf dem ersten Blick wenig kompatibel
[Felb98, S. 121].
Die technischen Systeme dürfen jedoch keinesfalls losgelöst betrachtet werden, da viel wich-
tiger als das System selbst die Steuerungsprozesse dahinter sind [Schü05, S.18]. Schließlich
handelt es sich dabei nicht um starre Objekte, sondern um hochdynamische Systeme mit
Menschen als Akteuren, die in jedem Wandlungsprozess eingegliedert werden müssen.
KOEDER / ROHLEDER [KoRo04, S. 10] stellen fest, dass die Implementierung von Wissensma-
nagement an fehlenden Strategien und bereichsübergreifenden Konzeptionen sowie an einer
mangelnden Integration der Mitarbeiter krankt. Sie fordern auch, dass es das Ziel sein muss,
ganzheitliche Konzepte zu entwickeln, die durch moderne Technologien unterstützt werden.
Der Umgang mit Wissen wird nur in wenigen Veröffentlichungen mit nachfrageorientierten
Gestaltungsansätzen, Vorgehensmodellen und Modellierungsmethoden behandelt [GrMü05,
S. 50]. Daher sind Modelle notwendig, wie wissensorientierte Informationssysteme unter
Beachtung der Nachfrager in Organisationen implementiert werden können.
1.2 Zielsetzung der Arbeit
1.2.1 Theoretischer Hintergrund
Die bisherigen Arbeiten fokussieren regelmäßig stark auf einen der Bereiche Informations-
technologie, Organisation, Mitarbeiter oder grundlegende Wissensmanagementprozesse. Es
ist eine Integration aller Komponenten notwendig, um nachhaltige Erfolge zu erzielen. An
diesem Punkt setzt die vorliegende Arbeit an, indem eine strukturierte Vorgehensweise zur
Implementierung eines wissensbasierten Informationssystems untersucht wird.
Die Ausgangspunkte sind zum einen in den aktuellen Grundlagen der Wissensmanagement-
forschung und zum anderen in dem Stand der Technik der Implementierung von Standard-
softwaresystemen gegeben. Die bekannten Ansätze sollen analysiert und die grundlegenden
Aspekte aufgegriffen werden. Das Ziel liegt in der Weiterentwicklung zu einer Gesamt-
methodik in Form eines durchgängigen Implementierungsmodells für wissensbasierte Sys-
teme.
Das primäre Augenmerk des zu entwickelnden Implementierungsmodells liegt in der abge-
stimmten Eingliederung eines wissensbasierten Systems in die industrielle Prozessumgebung.
Dazu wird eine praktische Vorgehensweise erarbeitet, nach der eine Einführung eines wis-
sensbasierten Systems unter Beteiligung der Mitarbeiter durchgeführt werden kann. Dies führt
auf den Ansatz eines mitarbeiterorientierten Change Managements, das bewährte Elemente
aus der Implementierung von Standardsoftware aufnehmen und mit den Gedanken des Wis-
EINLEITUNG SEITE 3
sensmanagements weiter entwickelt werden soll. Dabei werden auch die notwendigen Vor-
aussetzungen und begleitende Maßnahmen zur Unterstützung des Einführungsprozesses
betrachtet. Ein wesentlicher Aspekt ist die Prämisse, dass die Vorgehensweise – soweit mög-
lich – die Mitarbeiter integrieren soll, die sich nicht als „Leidtragende“, sondern als „Nutznie-
ßer“ des wissensbasierten Systems fühlen sollen. Mit dem Ziel, die Betroffenen zu Beteiligten
zu machen, wird die Forderung nach der Erreichung einer möglichst hohen und vor allem
schnellen Akzeptanz des Softwaresystems und der begleitenden Prozesse verbunden.
Ein weiteres wesentliches Ziel ist die Erarbeitung eines Instrumentariums zur implementie-
rungsbegleitenden Erfolgsmessung. Eine frühzeitige Ermittlung und Beobachtung von Kenn-
größen verspricht eine rechtzeitige Vermeidung von Fehlentwicklungen und ein Gegensteuern
noch während der Implementierung. Das Ziel ist eine nachhaltige Erhöhung der Erfolgsquote
angegangener Implementierungsvorhaben nach dem hier zu entwickelnden Modell. Zusätzlich
soll durch die stetige Steuerung eine möglichst schnelle und breite Akzeptanz der Maßnah-
men erreicht werden.
1.2.2 Anwendungsbereich des Pilotsystems
Die Arbeit ist im Rahmen einer Implementierung eines wissensbasierten Informationssystems
im Unternehmen entstanden. Die Zielsetzung bestand darin, eine Möglichkeit zu finden, den
Wissensprozess im Bereich der Fertigung zu unterstützen. Die dortigen Mitarbeiter sind alle
versierte Experten in ihrem jeweiligen Fachgebiet. Da das Unternehmen jedoch mehrere
Fertigungslinien betreibt, haben diese Experten untereinander nur wenig Kontakt.
Die Aufgabe bestand darin, ein wissensbasiertes Informationssystem so zu entwickeln und zu
implementieren, dass das Wissen der Experten für alle verfügbar wird und dabei hilft, sowohl
die Prozesse als auch die Fehlerqouten zu optimieren. Die Arbeit hat daher nicht nur das Ziel,
die Softwareentwicklung und Softwareimplementierung im Unternehmen zu beschreiben,
sondern zeigt zusätzlich auf, wie die Mitarbeiter zu der Teilung ihres Wissens motiviert
werden können. Die im Folgenden dargestellten Vorgehensweisen beinhalten verschiedene
Erfahrungen aus dem praktischen Einsatz des Implementierungsmodells und sind dabei
soweit abstrahiert und teilweise ergänzt, dass sie sich für den Einsatz in verschiedenen
anderen Unternehmen eignen.
1.3 Aufbau und Vorgehensweise
Die Abbildung 1 zeigt den Aufbau und die verwendete Vorgehensweise dieser Arbeit in einer
Übersicht.
Zunächst wird in Kapitel 2 das grundlegende Verständnis für den Untersuchungsgegenstand
gelegt. Dazu werden die beiden Begriffe „wissensbasiertes Informationssystem“ und „Imple-
mentierung“ mit ihren Definitionen und dem Verständnis aus aktuellen Veröffentlichungen
betrachtet. Da die wissensbasierten Informationssysteme momentan eine große Vielzahl an
Ausprägungen zeigen, soll ein kurzer Überblick über Inhalte und Funktionsweisen das Unter-
suchungsobjekt näher bestimmen. Genauso wird für den Begriff der Implementierung ein
einheitliches Verständnis für diese Arbeit gelegt.
SEITE 4 EINLEITUNG
Das Kapitel 3 stellt den Analyserahmen der aktuellen Wissensmanagementforschung dar. Erst
durch das Verständnis für die besondere Ressource Wissen kann eine sinnvolle Herange-
hensweise an den Umgang mit Wissen aufgezeigt werden. Ziel dieses Kapitels ist es, das
zugrunde gelegte Verständnis des Wissensbegriffes theoretisch zu fundieren und Gestaltungs-
ansätze aus dem Wissensmanagement für die folgende Implementierung von wissensbasierten
Informationssystemen abzuleiten. Die Wissensmanagement-Literatur bietet verschiedene
Entwürfe, wie lernende Organisationen mit Wissen umgehen und welche Unternehmens- und
Wissenskulturen besonders förderlich sind. Diese werden ebenso herausgearbeitet wie eine
Auswahl von bereits beschriebenen Instrumenten zur Messung und Bewertung von Wissen.
EinführungKapitel 1
Kapitel 3
Implementierung Wissensmanagement
Analyserahmen der
Wissensmanagement-
forschung
Implementierungs-
verfahren für
Standardsoftware
Kapitel 4
Kapitel 5 Entwicklung eines Implementierungsmodells für
wissensbasierte Informationssysteme
UntersuchungsgegenstandKapitel 2
Kapitel 6 Instrumentarium zur Messung des
Implementierungserfolgs
Prototypische Anwendung des
Implementierungsmodells
Kapitel 7
Zusammenfassung und AusblickKapitel 8
Quelle: Verfasser
Abbildung 1: Aufbau der Arbeit
Im Zentrum von Kapitel 4 steht die Aufarbeitung von Erkenntnissen aus den Verfahren zur
Implementierung von Standardsoftware-Systemen. Da diese bereits seit vielen Jahren in
EINLEITUNG SEITE 5
unterschiedlichen Formen auf dem Markt sind, haben bereits etliche Autoren Vorgehensmo-
delle zu deren Implementierung entwickelt. Diese Vorgehensweisen sollen als Basis für die
Weiterentwicklung zu dem Implementierungsmodell für wissensbasierte Informationssysteme
dienen. Der Begriff der Standardsoftware als solcher wird zur Erreichung eines einheitlichen
Verständnisses zu Beginn in einer knappen Abhandlung erläutert. Im Fokus stehen die Aus-
sagen zur betrieblichen Integration und zur Systematik der Einführung, insbesondere mit
Hilfe von Projektorganisationen.
In Kapitel 5 werden die Ergebnisse aus den beiden vorangegangenen Kapiteln als Grundlage
für die Erarbeitung eines Implementierungsmodells für wissensbasierte Systeme verwendet.
Das Ziel des Implementierungsmodells ist es, eine Handlungsanleitung für die nachhaltige
Systemeinführung in die industriellen Prozesse zu geben. Zunächst wird ein Projektaufbau für
die Einführung und Anpassung eines wissensbasierten Informationssystems vorgestellt, der in
einem mehrstufigen Phasenkonzept umgesetzt wird. Im Anschluss werden die Bezüge zu den
Konzepten des Wissensmanagements hergestellt und zur intensiven Einbeziehung der Mitar-
beiter ein Change Management ausgearbeitet. Zur Sicherung des langfristigen Projekterfolgs
werden begleitende Maßnahmen und eine Zusammenfassung in Form von „Goldenen Regeln“
für die Implementierung entworfen.
Das Kapitel 6 entwickelt ein Instrumentarium zur Messung des Systemnutzens. Mit diesem
Instrumentarium können während und nach der Implementierung die wichtigsten Eckdaten
für einen nachhaltigen Erfolg konsequent verfolgt werden. Verwendet werden direkte Kenn-
zahlen, die aus dem Softwaresystem abgeleitet werden und indirekte Kennzahlen, die primär
die Mitarbeitersicht betreffen. Die Nutzenbewertung erfolgt durch die Anwendung einer
eigens entworfenen Implementierungs-Scorecard, die aus einer Balanced Scorecard abgeleitet
ist. Als Bewertungsdimensionen verwendet die Implementierungs-Scorecard eine Mitarbei-
terperspektive, Informationssystemperspektive, Prozessperspektive und Unternehmenskultur-
perspektive.
Im Kapitel 7 werden die Erfahrungen einer prototypischen Anwendung des Implementie-
rungsmodells in einem Unternehmen der Automobilzulieferindustrie gezeigt. Die Ergebnisse
geben Anregungen für weitere Implementierungsprojekte und dienen als Überprüfung der
zuvor aufgezeigten Implementierungssystematik. In diesem Rahmen werden sie auch einer
kritischen Beschreibung unterzogen.
Das abschließende Kapitel 8 fasst die wesentlichen Ergebnisse der Arbeit zusammen. Den
Abschluss bilden Hinweise und Anregungen für weitere Forschungsaktivitäten, die sich aus
der Arbeit mit dem Themenbereich der Implementierung von wissensbasierten Informations-
systemen heraus ergeben haben.
SEITE 6 EINLEITUNG
DIE BEGRIFFE IMPLEMENTIERUNG UND WISSENSBASIERTES INFORMATIONSSYSTEM SEITE 7
2 Die Begriffe Implementierung und wissensbasiertes Informations-
system – eine Einführung in den Untersuchungsgegenstand
Der Beginn der Weisheit ist die Definition der Begriffe.
(Sokrates)
In diesem Kapitel wird das inhaltliche Begriffsverständnis durch die Erläuterung der beiden
Kernbegriffe „Implementierung“ und „wissensbasiertes Informationssystem“ gelegt. Dazu wer-
den die vorhandenen Grundlagen aus der Literatur herangezogen und zu einer für diese Arbeit
tragfähigen Definition weiter entwickelt.
2.1 Verständnis des Begriffs „Implementierung“
Der Begriff der „Implementierung“ wird in den Disziplinen der Informatik und Ingenieurwissen-
schaft uneinheitlich verwendet. Als Herangehensweise an die Erarbeitung der Bedeutung wird
zunächst die Wortherkunft und das Verständnis in einer Enzyklopädie betrachtet, um anschlie-
ßend die Verwendung im Sprachgebrauch von aktuellen Veröffentlichungen zu untersuchen.
Der Wortstamm leitet sich aus dem lateinischen Wort „implere“ ab, das mit „anfüllen“ oder
„erfüllen“ übersetzt werden kann [N.N.97, S. 437]. Im Allgemeinen wird unter einer Implemen-
tierung laut der BROCKHAUS-ENZYKLOPÄDIE [N.N.97, S. 437] die Umsetzung oder Durchsetzung
eines Konzepts verstanden.
Für den Bereich der Informatik versteht die BROCKHAUS-ENZYKLOPÄDIE unter der Implementie-
rung die Realisierung eines Entwurfs oder Konzepts durch ein lauffähiges Programm, wozu auch
die Wahl einer geeigneten Programmiersprache gehört [N.N.97, S. 437]. In einer aktuellen Spe-
zialausgabe des BROCKHAUS FÜR COMPUTERTECHNOLOGIE [N.N.03, S.447] wird zusätzlich in
Software und Hardware unterschieden. Die Implementierung einer Software bedeutet dabei die
Installation eines Programms und dessen Anpassung an ein Rechnersystem. Der Aussagegehalt
der Implementierung einer Hardware bezieht sich auf die Verwirklichung eines noch nicht ge-
nutzten technischen Konzepts einschließlich Erprobungen und Anpassungen. Bei der Implemen-
tierung eines neuen Computersystems wird regelmäßig ein bisheriges System abgelöst. Es kann
sich dabei auch um die Einführung eines Teilsystems handeln [N.N.03, S. 447].
Der Ursprung des Terminus „Implementierung“ ist in den ingenieurwissenschaftlichen Diszipli-
nen zu finden und wird dort häufig im Zusammenhang mit der Entwicklung von Informations-
systemen verwendet [Seib80, S. 853f.]. Eine eher betriebswirtschaftliche Sichtweise auf die
Implementierung ergibt keine konsistente Beschreibung des Begriffs. Bereits NOBLE [Nobl99]
konstatierte, dass die betriebswirtschaftliche Implementierungsforschung vergleichsweise frag-
mentiert ist und signifikante Lücken aufweist:
„To date, implementation research has been fairly fragmented due to the lack of
clear models on which to build. If the area is to advance, more conceptual efforts
must be made to enable.”[Nobl99, S. 132]
SEITE 8 DIE BEGRIFFE IMPLEMENTIERUNG UND WISSENSBASIERTES INFORMATIONSSYSTEM
Diese Situation hat sich auch mit den neueren Veröffentlichungen wie etwa von TROJAN
[Troj05] oder KARNER [Karn05] nicht grundlegend verändert. Eine konsistente Vorgehensweise
für die Einführung von wissensbasierten Informationssystemen in eine Organisation ist noch
nicht beschrieben worden. Den kleinsten Nenner bildet die Erkenntnis, dass sich die Implemen-
tierung einerseits auf die Änderung von Verhalten und Einstellungen einer Vielzahl von Perso-
nen bezieht und andererseits von einer Sequenz verbundener Ereignisse und Handlungen kon-
stituiert wird. Nach SHIELDS [Shie02, S. 26] sind für eine Implementierung Veränderungen in
drei Bereichen erforderlich: Mitarbeiter, Technologie und Prozesse. Eine ausschließliche Instal-
lation eines Softwaresystems spricht dagegen nur den Teilbereich der Technologie an.
Eine Implementierung im weiteren Sinn umfasst laut GREWE einen Veränderungsprozess insge-
samt, der bereits mit der Formulierung eines Projektauftrags beginnt [Grew00, S. 32]. In der
Wirtschaftsinformatik wird unter der Implementierung ein umfassender Gestaltungsansatz ver-
standen, der als Prozess der zielgerichteten Abstimmung zwischen den Komponenten Informati-
onstechnik, Aufgabe/Funktion, Personen und Organisation definiert werden kann [Müld01, S.
231].
Die Betrachtung aktueller Veröffentlichungen, die sich mit wissensorientierten Thematiken und
Implementierungsaufgaben auseinander setzen, ergibt ebenfalls ein unspezifisches Bild der
Verwendung des Begriffs Implementierung. KARNER [Karn05] versteht darunter die Installation
und kundenspezifische Anpassung eines IT-Tools mit anschließender Information der Mitarbei-
ter. Weiterhin in diesen Prozess eingeschlossen ist für ihn die Phase des Anlernens der Mitar-
beiter sowie das Einpflegen der Inhalte in das IT-System. Als Voraussetzung für die Implemen-
tierung verlangt er die Erstellung eines Anforderungsprofils, nach dem die Erfordernisse für das
Software-Tool festgelegt werden.
ROHLEDER [Rohl05] beschreibt mit der Implementierung ebenfalls schwerpunktmäßig die Ein-
führung von Systemen. Er fokussiert das Thema insbesondere auf die kleinen und mittleren
Unternehmen (KMU) und folgert, dass bei ihnen Systeme erforderlich sind, die mehr den Aus-
tausch zwischen den Personen in den Vordergrund stellen als die technologiegestützte Doku-
mentation. Daher müssen die in der Implementierung angesprochenen Werkzeuge und Methoden
den kurzen, informellen Kommunikationswegen Rechnung tragen.
Als drittes Beispiel kommt die Veröffentlichung von TROJAN [Troj05] in Betracht. Der Autor
beschreibt mit dem Begriff der Implementierung die Einführung eines neuen technischen Sys-
tems. Allerdings legt er in diesem Rahmen sehr großen Wert darauf, eine hohe Mitarbeitermoti-
vation zu erzielen und parallel dazu die Gestaltung der Prozesse und Systeme zu betrachten.
Diese Auswahl zeigt, dass mit dem Begriff Implementierung die Einführung von IT-Systemen
und weitere Begleitprozesse wie Kommunikationsförderung, Motivation und Organisationsges-
taltung verbunden werden. Der Fokus wird in der Praxis oft nur auf die Einführung des techni-
schen Systems selbst gelegt. Eine solche Betrachtungsweise ist für diese Arbeit nicht ausrei-
chend, da sie insbesondere die von der Fachliteratur geforderte Idee einer bereichsübergreifen-
den Wissensmanagementkonzeption konterkariert. Folgendes Verständnis des Begriffs der Imp-
lementierung wird hier zugrunde gelegt:
„Eine Implementierung ist die Einführung eines IT-Systems auf Basis seiner speziel-
len Eigenschaften in ein Unternehmen mit Hilfe einer Projektorganisation. Dabei
werden zum einen Rahmenbedingungen, Regeln, Zielvorgaben und Bedürfnisse der
DIE BEGRIFFE IMPLEMENTIERUNG UND WISSENSBASIERTES INFORMATIONSSYSTEM SEITE 9
Mitarbeiter, zum anderen auch die Unternehmenskultur und die unternehmensinter-
nen Prozesse berücksichtigt.“
Diese Auffassung impliziert, dass, wie in der Zielformulierung dieser Arbeit gefordert, ein Imp-
lementierungsmodell einen Leitfaden bilden kann, mit dem die Umsetzung der Integration eines
wissensbasierten Informationssystems in einer Unternehmensorganisation mit vorgeprägter
Unternehmenskultur und vorhandenen Prozessabläufen vorgenommen werden kann. Dabei ist
eine einseitige Fokussierung auf IT-Tools ohne die ausdrücklich geforderte Berücksichtigung der
organisatorischen Umgebungsbedingungen sowie der Mitarbeiterbeteiligung ausgeschlossen.
Vielmehr beinhaltet diese Auffassung von einer Implementierung vielfältige Rahmenbedingun-
gen, die die Abbildung 2 zusammenfassend darstellt. Diese Annahmen bilden die Basis für die
Erarbeitung des Vorgehens im Implementierungsmodell.
Prozessorganisation
Unternehmenskultur
Projektorganisation
Mitarbeiter-
orientierung
wissensbasiertes
Informationssystem
Implementierung
Wissensmanagement
Quelle: Verfasser
Abbildung 2: Auswahl der durch die Implementierung berücksichtigten Rahmenbedingungen
2.2 Inhaltliche Eingrenzung eines „wissensbasierten Informationssystems“
Der Begriff des wissensbasierten Informationssystems ist in der derzeitigen Diskussion unscharf
gefasst und eine einheitliche Definition als solche nicht erkennbar. Da das zu entwickelnde
Implementierungsmodell eine möglichst große Anwendungsbreite erhalten soll, wird die ge-
samte Gruppe der wissensverarbeitenden Informationssysteme betrachtet. Diese Art von Syste-
men ist in sehr vielen Ausprägungen auf dem Markt zu finden und wird für verschiedene Funk-
tionen im unternehmerischen Prozessablauf eingesetzt. Um einen Zugang zu dem Begriffsinhalt
zu erlangen, wird zunächst das computerunterstützte Informationssystem kurz erläutert.
Gemäß KRCMAR [Krcm03, S. 25] ist ein computergestütztes Informationssystem ein soziotech-
nisches System, das aus Teilsystemen für die optimale Bereitstellung von Information und (tech-
SEITE 10 DIE BEGRIFFE IMPLEMENTIERUNG UND WISSENSBASIERTES INFORMATIONSSYSTEM
nischer) Kommunikation besteht. MERTENS [Mert05, S. 1] formuliert eine allgemeinere Defini-
tion und beschreibt die computergestützte Informationsverarbeitung als ein Gesamtsystem, das
aus mehreren Anwendungen besteht. Als Teilaufgaben im Umgang mit Informationen kommen
in Industriebetrieben verschiedene Bereiche, wie etwa Produktion, Beschaffung, Personal, Fi-
nanzen oder Kundendienst in Betracht [Mert05, S.83ff.]. Diese einfache Beschreibung lässt viel
Spielraum für Interpretationen und muss weiter auf wissensbasierte Informationssysteme spezifi-
ziert werden.
Im Falle dieser wissensbasierten Systeme gilt es als wichtigster Aspekt, dass eine Trennung
zwischen der Darstellung des Wissens über den betreffenden Problembereich (Wissensbasis) und
der Verarbeitung dieses Wissens (Wissensverarbeitung) herrschen muss [BeKe00, S. 10]. Nach
diesem Ansatz werden damit zwei Gesichtspunkte realisiert. Zum einen gibt es eine klare Tren-
nung zwischen Problembeschreibung und Problemlösung, zum anderen kann das Wissen über
den Anwendungsbereich direkt ausgedrückt werden.
Die wissensbasierten Systeme gehen gegenüber reinen Informationssystemen einen Schritt wei-
ter. Sie beinhalten nicht nur den Informationsgehalt als solchen, sondern unterstützen den Nutzer
bei konkreten Problemstellungen. Sie sind in der Lage, durch spezielle Mechanismen genau das
Wissen zu liefern, das der Nutzer an einer bestimmten Stelle seiner Arbeit benötigt. Eine Defini-
tion von BORGELT / TIMM / KRUSE [BOTK03] für ein wissensbasiertes System lautet:
„Wissensbasierte Systeme sind Programme, die auf der Grundlage von Wissen über
einen bestimmten Anwendungsbereich Schlussfolgerungen ziehen können und so dem
Benutzer helfen, ein Problem zu lösen oder eine Entscheidung zu treffen.“ [BoTK03,
S. 291]
Als primären Anwendungszweck werden von BODENDORF [Bode03, S. 129] pragmatische
Problemstellungen priorisiert, die wegen hoher Komplexität, Unsicherheit oder nur teilweise
vorhandener Information mit herkömmlichen algorithmischen und kombinatorischen Methoden
nicht oder nur begrenzt gelöst werden können. Die wissensbasierten Systeme werden daher für
die Bearbeitung von Aufgaben verwendet, zu denen der Mensch üblicherweise seine Intelligenz
einsetzt. Die hohe Komplexität zeigt sich etwa in der Betrachtung von Systemen, die mensch-
liche Experten bei ihrer Arbeit unterstützen. Zur Veranschaulichung werden diese Experten-
systeme genauer beschrieben, um zu zeigen, dass die sorgfältige Implementierung eines solchen
oder eines artverwandten Systems große Potenziale birgt.
Die Expertensysteme zeichnen sich im Gegensatz zu dem allgemeinen wissensbasierten System
dadurch aus, dass das in ihnen vorhandene spezielle Wissen von Experten generiert wird
[Pupp91, S. 2]. Nach diesem Kriterium sind die meisten der derzeit existierenden wissensbasier-
ten Systeme Expertensysteme [BeKe00, S. 10] und es können nach BODENDORF [Bode03, S.
134] folgende Komponenten unterschieden werden: Wissenserwerbskomponente, Problem-
lösungskomponente, Dialogkomponente, Erklärungskomponente und ein Benutzermodell. Jeder
dieser Bausteine ist individuell anzupassen und birgt aus diesem Grund Schnittstellen zu dem
hier zu entwickelnden Implementierungsmodell. BEIERLE / KERN-ISBERNER [BeKe00] haben
einen schematischen Aufbau eines Expertensystems gemäß Abbildung 3 entwickelt, woraus die
Anknüpfungspunkte zu dem Vorgehen bei einer Implementierung abgeleitet werden können.
Dazu kommen etwa die Gestaltung des Wissenserwerbs oder der Systemschnittstellen in Be-
tracht. Ein ähnliches Systemschema wird auch von BODENDORF [Bode03, S. 135] vertreten.
DIE BEGRIFFE IMPLEMENTIERUNG UND WISSENSBASIERTES INFORMATIONSSYSTEM SEITE 11
Dialog-
komponente
Erklärungs-
komponente
Regelhaftes Wissen
(Wissensbasis)
Fallspe-
zifisches
Wissen
Wissenserwerbs-
komponente Wissensverarbeitung
Benutzungsschnittstelle
Schnittstelle für Experten
Quelle: nach [BeKe00, S. 15]
Abbildung 3: Schematischer Aufbau eines Expertensystems
Wissensbasierte Systeme und insbesondere Expertensysteme müssen auf die besonderen Eigen-
schaften von menschlichen Experten mit ihren Stärken und Schwächen eingehen. Die folgende
Auflistung gibt einen kurzen Überblick von Stärken und Schwächen menschlicher Experten, die
Beachtung finden müssen: [N.N.90, S. 14]
• Experten besitzen überdurchschnittliche Fähigkeiten, Probleme in einem speziellen Gebiet
zufriedenstellend zu lösen, selbst wenn diese Probleme keine eindeutigen Lösungen besit-
zen oder neu auftreten.
• Sie verwenden heuristisches Wissen, um spezielle Probleme zu lösen und verwerten dabei
ihre Erfahrungen.
• Sie haben zusätzlich Allgemeinwissen.
• Experten handeln oft intuitiv richtig, können dann aber ihre Entscheidungen nicht begrün-
den.
• Experten können Probleme unter Verwendung unvollständigen oder unsicheren Wissens
lösen.
• Sie sind selten und teuer.
• Ihre Leistungsfähigkeit schwankt je nach Tagesverfassung.
• Ein Experte allein ist oft nicht ausreichend.
• Das Wissen der Experten kann verloren gehen.
SEITE 12 DIE BEGRIFFE IMPLEMENTIERUNG UND WISSENSBASIERTES INFORMATIONSSYSTEM
Zusammenfassend schreibt GRUBER [Grub94], dass ein Experte eine Person ist, die auf einem
Gebiet dauerhaft (also nicht zufällig oder singulär) herausragende Leistungen erbringt. Aus
diesen speziellen Eigenschaften von menschlichen Experten resultieren vielfältige Anforderun-
gen sowohl an die Softwaresysteme, die ihnen bei der wissensorientierten Arbeit helfen, als auch
an die Implementierung dieser Systeme innerhalb von Organisationen, die eine erfolgreiche
Arbeit mit dem wissensbasierten System erst ermöglicht. Die Unterstützungsleistung der Soft-
waresysteme kann sich auch nur dann entfalten, wenn eine Einbettung in die Prozesse gegeben
ist.
Bei der Entwicklung eines Implementierungsmodells für wissensbasierte Informationssysteme
werden in dieser Arbeit Systeme verstanden, die der folgenden arbeitsspezifischen Definition
entsprechen:
„Wissensbasierte Informationssysteme sind Systeme, die Benutzern über Schnittstel-
len die Möglichkeit bieten, bereits vorhandenes Wissen für ihre aktuelle Fragestel-
lung gezielt einzusetzen. Dabei ist es Aufgabe des wissensbasierten Informations-
systems, die von den Benutzern eingegebenen Wissensressourcen in geeigneter Form
aufzubereiten und lösungsorientiert im unternehmensspezifischen Prozesskontext zur
Verfügung zu stellen.“
Das Ziel besteht darin, die von einer solchen Software bereit gestellten Ressourcen durch den
Verankerungsprozess in der Organisation umfassend nutzbar zu machen. Das Implemen-
tierungsmodell stellt hierzu die notwendige Vorgehensweise bereit.
Die wissensbasierten Informationssysteme lassen sich zu folgenden Softwaregruppen abgrenzen,
die nicht Inhalt der Definition sind:
• Die Abgrenzung zur Standardsoftware wird im späteren Verlauf der Arbeit in Kapitel
4.1 behandelt.
• Eine weitere Abgrenzung der wissensbasierten Informationssysteme ist dahingehend
gegeben, dass Individualentwicklungen für bestimmte nicht wissensorientierte Zwecke
nicht unter diesen Begriff fallen. Beispielsweise sind hierunter Anwendungen für
mathematische Operationen oder Bildverarbeitungssoftware zu verstehen.
• Die Systeme müssen in der Lage sein, Wissensressourcen zu speichern und können
prozessual in die Unternehmensumgebung integriert werden.
• Die hier betrachteten Systeme sind im gesamten Unternehmen nutzbar und beschrän-
ken sich nicht auf einzelne Mitarbeiter oder Arbeitsstationen.
• Die Anzahl der Nutzer ist prinzipiell beliebig, d.h. es handelt sich nicht um eine spe-
zielle Entwicklung für einen einzelnen Anwender.
Diese Arbeitsfassung wird im weiteren Verlauf der Arbeit verwendet, um ein Implementierungs-
verfahren für den abgegrenzten Bereich der wissensbasierten Informationssysteme zu ent-
wickeln.
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 13
3 Analyserahmen der Wissensmanagementforschung als Voraus-
setzung für den Umgang mit Wissen
Wissen ist wissen, Nichtwissen ist nicht wissen.
Das ist Wissen.
(Konfuzius)
In diesem Kapitel wird der Stand der Wissensmanagementforschung diskutiert, dessen Ergeb-
nisse eine große Bedeutung für die Implementierung und die Nutzung von wissensbasierten
Informationssystemen hat. Wie bereits in Kapitel 2 dargestellt, besteht bei wissensbasierten
Informationssystemen die Notwendigkeit, sich mit dem Wissen als solchem und den Menschen
als Wissensträgern intensiv zu befassen. Nach der Extraktion wichtiger Konzepte aus dem Wis-
sensmanagement, der Lernenden Organisation und der Unternehmens- und Wissenskulturen für
die Entwicklung eines Implementierungsmodells werden im Anschluss Instrumente für die
Realisierung eines Wissensmanagements vorgestellt. Dieses Kapitel schließt mit der Betrachtung
des Stands der Technik der Messung und Bewertung von Wissen, um eine stetige Überwachung
und Steuerung des Erfolgs einer Implementierung zu gewährleisten.
3.1 Forschungsstand im „Wissensmanagement“
Das „Wissensmanagement“ gilt als eine noch junge Forschungsdisziplin [Souk01, S. 90]. Derzeit
werden in verschiedenen Fachrichtungen unter ihren jeweiligen spezifischen Perspektiven Ideen
unter dem Dach des Begriffs Wissensmanagement entwickelt. Es ist daher keine gemeinsame
Problemsicht erkennbar [Souk01, S. 87].
Schon früh hat SVEIBY [Svei94] postuliert, dass Wissen als die „vierte Produktionskraft“ anzuse-
hen sei, und NONAKA/TAKEUCHI [NoTa97] bezeichnen das Wissen als die „kreative Ressource“.
Nach DRUCKER [Druc93, S. 8] wird derzeit ein Wandel hin zur Wissensgesellschaft vollzogen,
der dazu führt, dass die Bedeutung der klassischen ökonomischen Ressourcen Arbeit, Boden und
Kapitel in ihrem Stellenwert von der Ressource Wissen überflügelt werden. Die Notwendigkeit
eines Managements des Wissens ergibt sich daraus, dass in rein quantitativer Betrachtung die
Entwicklung menschlichen Wissens eindeutig exponentielle Tendenzen hat. SCHÜPPEL [Schü97]
zeigt den Umfang der Wissensentwicklung anhand einer „Halbwertszeit des Wissens“, die 1997
bei etwa fünf Jahren lag. Während vor einigen Jahrhunderten ein Universalgelehrter noch einen
Gesamtüberblick über den Stand nahezu aller wissenschaftlichen Forschungsgebiete gewinnen
konnte, treten heute bereits innerhalb eines Faches erhebliche Verständigungsschwierigkeiten
zwischen Mitgliedern verschiedener Spezialdisziplinen auf [PRRo03, S. 6].
Die besondere Relevanz des Wissensmanagements für diese Arbeit liegt darin, dass durch diese
Konzepte die Voraussetzungen für eine erfolgreiche Implementierung eines wissensbasierten
Informationssystems gelegt werden. Daher wird im Folgenden sowohl das Wissen als solches
SEITE 14 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
näher betrachtet als auch das Management dieses Wissens unter dem Aspekt der Implementie-
rung.
3.1.1 Eingrenzung des umfassenden Begriffs „Wissen“
Die Frage nach dem Begriff „Wissen“ wird in verschiedenen Forschungsrichtungen bearbeitet.
Je nach Wissenschaftsdisziplin - beispielsweise Wirtschaftsinformatik, Organisationsforschung,
Philosophie, Psychologie, Pädagogik oder Soziologie - gibt es sehr differenzierte Betrachtungs-
weisen [EKPW99, S. 78] [FrSc01, S. 165] [Amel02, S. 40] [Tupp03, S. 11].
Einen ersten zusammenfassenden Überblick über die Begriffe, die Sichtweisen und die Be-
schreibungen der Ressource Wissen der einzelnen Wissenschaftsdisziplinen geben beispiels-
weise ROMHARDT [Romh98, S. 27ff.] und AMELINGMEYER [Amel02, S. 40ff.] in ihren Arbeiten.
AMELINGMEYER [Amel02, S. 40f.] führt verschiedene Autoren mit ihren jeweiligen Definitionen
tabellarisch auf und stellt fest, dass die jeweiligen Definitionen sehr stark von der konkreten
Fragestellung der Autoren sowie von ihrem wissenschaftlichen Umfeld geprägt sind. Zusätzlich
sei zu beobachten, dass sich die Autoren in ihren weiteren Ausführungen oftmals nicht an die
zuvor gegebene Definition halten. Daher entsteht ein unscharfes Bild des Wissensbegriffs, das in
den folgenden Ausführungen fokussiert wird.
Für diese Arbeit wird zunächst ein Grundverständnis durch die inhaltliche und hierarchische
Unterscheidung der Begriffe „Daten“, „Information“ und „Wissen“ gegeben. Diese Abgrenzung
nehmen bereits CLEVELAND [Clev89] und DAVIS/BOTKIN [DaBo94] vor. CLEVELAND [Clev89,
S. 22] beschreibt Daten als eine untergeordnete Beobachtung oder Menge von Fakten. Informa-
tionen dagegen sind Daten, die von Dritten organisiert wurden, wie etwa ein Buch. Wissen ist
erst dann gegeben, wenn Informationen von einem Individuum selbst organisiert und internali-
siert sind. DAVIS/BOTKIN [DaBo94, S. 166] bezeichnen Daten als „unstrukturierten, unorgani-
sierten Schlamm des Informationszeitalters“. Erst wenn Daten in sinnvollen Mustern geordnet
werden, sind sie als Information nutzbar. Diese wiederum wird zu Wissen, wenn eine Person
durch sie etwas lernen kann. Damit lässt sich auch eine Abhängigkeit zu einem bestimmten
menschlichen Wissensträger ableiten. REHÄUSER/KRCMAR [ReKr96, S. 3 ff.] betrachten die
Begriffe „Daten“, „Information“ und „Wissen“ in einer Begriffshierarchie, die sich wie in
Abbildung 4 darstellen lässt. Diese Ansicht wird auch von DAVENPORT/PRUSAK [DaPr98, S.
26ff.], SANDEN [Sand01, S. 73] oder TUPPINGER [Tupp03, S. 14] aufgegriffen und im Rahmen
ihrer Wissensmanagementforschungen geteilt.
Nach Meinung von PROBST/RAUB/ROMHARDT [PRRo03, S.17f.] ist statt einer strengen Trennung
von Daten, Informationen und Wissen die Vorstellung eines Kontinuums zwischen den Polen
Daten und Wissen tragfähiger. Schließlich ist eine Problemsituation selten in einzelnen und klar
abgrenzbaren Schritten zu bewältigen. Eine Annäherung an die Lösung in vielen kleinen Schrit-
ten trifft die Realität wesentlich besser. Wie auch Fähigkeiten in einem kontinuierlichen Prozess
erlernt werden, zeigt das Kontinuum von Daten über Informationen zu Wissen einen Entwick-
lungsprozess.
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 15
Informationen
Daten
Wissen
Rohmaterial
Informationen
mit Wert
Strukturierte
Daten
Interpretation/Bewertung
Code/Regeln
Quelle: Verfasser nach [GeSt98]
Abbildung 4: Hierarchie von Daten über Informationen zu Wissen
Auf dieser Basis muss die Frage beantwortet werden, wie der Begriff Wissen für diese Arbeit
definiert werden kann. Die Definitionen einiger Autoren geben hierzu gemäß Abbildung 5 einen
Rahmen. Die Definition von DAVENPORT/PRUSAK [DaPr98] fasst den Begriff des Wissens sehr
weit, hebt dafür aber die Einbettung des Wissens in die Organisation hervor. Neben dieser An-
sicht ist auch der Aspekt von BULLINGER/SCHÄFER [BuSc97] in dieser Arbeit zu berücksichti-
gen, die insbesondere dem Gedanken der integrativen Vernetzung Rechnung tragen und die
Handlungs- bzw. Prozessorientierung verdeutlichen.
„Wissen ist die Vernetzung von Informationen, welche es dem Träger
ermöglicht, Handlungsvermögen aufzubauen und Aktionen in Gang zu setzen.“
Bullinger/Schäfer
[BuSc97, S. 97]
„Wissen ist eine fließende Mischung aus strukturierten Erfahrungen,
Wertvorstellungen, Kontextinformationen und Fachkenntnissen, die in ihrer
Gesamtheit einen Strukturrahmen zur Beurteilung und Eingliederung neuer
Erfahrungen und Informationen bietet. Entstehung und Anwendung von Wissen
vollziehen sich in den Köpfen der Wissensträger. In Organisationen ist Wissen
häufig nicht nur in Dokumenten oder Speichern enthalten, sondern erfährt auch
eine allmähliche Einbettung in organisatorische Routinen, Prozesse, Praktiken
und Normen.“
Davenport/Prusak
[DaPr98, S. 32]
„Wissen bezeichnet die Gesamtheit der Kenntnisse und Fähigkeiten, die
Individuen zur Lösung von Problemen einsetzen. Dies umfasst sowohl
theoretische Erkenntnisse als auch praktische Alltagsregeln und
Handlungsanweisungen. Wissen stützt sich auf Daten und Informationen, ist im
Gegensatz zu diesen jedoch immer an Personen gebunden. Es wird von
Individuen konstruiert und repräsentiert deren Erwartungen über Ursache-
Wirkungs-Zusammenhänge.“
Probst/Raub/Romhardt
[PRRo03, S. 22]
„As an economy, we are on the cusp of the transition form information to
knowledge, with knowledge meaning the application and productive use of
information.“
Davis/Botkin
[DaBo94, S. 167]
DefinitionAutoren
Quelle: Verfasser
Abbildung 5: Auswahl von Definitionen des Begriffs Wissen
SEITE 16 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
Weiterhin ist es für diese Arbeit wichtig, im Rahmen der Implementierung und des Umgangs mit
wissensbasierten Informationssystemen die Kontextgebundenheit des Wissens hervorzuheben.
Diese impliziert, dass das informationstechnische System keinesfalls alleinstehend gesehen
werden darf, sondern es in jedem Fall begleitender Prozesse und Maßnahmen bedarf, die dem
Nutzer den entsprechenden Zusammenhang aufzeigen und den Kontakt zu weiteren Wissensträ-
gern oder Wissensressourcen bieten.
Soziale Komponente des Wissens
Neben den sachlichen und praxisorientierten Definitionen laut Abbildung 5 beschreiben mehrere
Autoren eine große Bedeutung der sozialen Komponente des Wissens. HOWALDT/KLATT/KOPP
[HoKK04, S. 13ff.] halten die Herangehensweise der Wissenssoziologie für viel versprechend,
da sie sich von ontologischen Definitionsversuchen fern hält und empirisch zu ergründen ver-
sucht, was unabhängig von einem Unternehmen in einer konkreten Gesellschaft als Wissen gilt.
Auf einer allgemeinen Ebene lässt sich Wissen als „Fähigkeit zum sozialen Handeln“ [Steh01, S.
62] definieren. HOWALDT/KLATT/KOPP [HoKK04, S. 13 ff.] stellen fest, dass diese Definition
den Zusammenhang zwischen Wissen und Handeln betont und Wissen noch kein Handeln ist,
sondern lediglich das Handlungsvermögen darstellt, welches in Aktion gebracht werden muss,
um sich zu beweisen und Wirkung zu entfalten. Damit sei auch eine Kontextabhängigkeit allen
Wissens verbunden. Jenseits dieses Kontextes ließe sich keine sinnvolle Aussage über den Wert
bzw. den Wahrheitsgehalt von Wissen machen. Diese Feststellung muss bei der Implementie-
rung Beachtung finden, da sich wissensbasierte Informationssysteme in einem sozialen Umfeld
bewegen und diesem angepasst werden müssen. Das weist auch darauf hin, dass wissensbasierte
Informationssysteme mit einer universellen Softwareanwendung nicht machbar sind, sondern
immer spezifischer Anpassungen auf die Organisation bedürfen.
Implizites und explizites Wissen
Eine weitere wichtige Unterscheidung für das Verständnis der Implementierung wissensbasierter
Informationssysteme ist die Trennung der beiden Wissensarten „implizites Wissen“ und „expli-
zites Wissen“. Beide Formen des Wissens spielen bei der Lösung von Aufgaben in vielfältiger
Form zusammen, werden aber im Detail unterschiedlich abgegrenzt [Amel02, S. 47].
SCHÜPPEL [Schü97] beschreibt das explizite Wissen in der Form, dass es unabhängig von einem
personifizierten Wissensträger in beliebigen Medien gespeichert werden kann. AMELINGMEYER
[Amel02, S. 47] merkt an, dass es vor allem wichtig ist, dass das Wissen artikulierbar ist, also
auch sprachlich umsetzbar ist bzw. unmittelbar sprachlich umgesetzt werden kann. Dieser
Blickwinkel ist gerade vor dem Hintergrund der Weitergabe von Erfahrungswissen wichtig, da
persönliche Einstellungen oder intuitive Gedanken auf Basis des individuellen Erfahrungsschat-
zes oft nur schwer oder gar nicht explizierbar sind. Zu dem expliziten Wissen werden subjektive
Einsichten und die Intuition hinzugerechnet, die tief in den Erfahrungen und Handlungen von
Personen verwurzelt sind.
Für die Entwicklung einer Lösung in einer Problemsituation spielen beide Wissensarten in viel-
fältiger Form ineinander. Es kann zwar nur das Wissen, welches ein Individuum bewusst expli-
zieren kann, über ein wissensbasiertes Informationssystem direkt übertragen werden, aber genau
dieser Anteil kann den entscheidenden Impuls für eine schnelle Lösung geben. Es gilt, die Ent-
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 17
stehung solcher Lösungen zu fördern, die nur durch den zusätzlichen Input expliziten Wissens
entstehen.
3.1.2 Das Management des Wissens
Der Begriff „Management“ kommt aus der Betriebswirtschaftslehre und kann gemäß
STEINMANN/SCHREYÖGG [StSc05, S. 6] unter zwei Aspekten betrachtet werden. Zum einen ist
ein „institutioneller Ansatz“ zu nennen, der die Gruppe von Personen beschreibt, die in einer
Organisation mit Anweisungsbefugnis betraut ist. Für das Wissensmanagement ist allerdings der
„funktionale Ansatz“ von wesentlicher Bedeutung, der unabhängig von einer Fixierung auf
Personen an diejenigen Handlungen anknüpft, die zur Steuerung des Leistungsprozesses dienen.
Dort setzt das Wissensmanagement an, indem es das Wissen als Ressource begreift und einen
bewussten Umgang mit diesem Potenzialfaktor in Organisationen fordert. BLEICHER [Blei99, S.
54] unterscheidet in seinem Konzept eines integrierten Managements die drei Funktionen
Gestaltung, Lenkung und Entwicklung, die das Wissensmanagement integrativ abdecken muss.
Als eigenständiger Managementansatz enthält das Wissensmanagement jedoch eine große be-
griffliche Unschärfe [Kate03, S.16]. In der Praxis ist derzeit eine unüberschaubare Vielfalt von
Zielen, Gegenständen, Konzepten, Methoden im Hinblick auf die Wissensmanagementpraxis
auszumachen [HoKK04, S. 15]. Verschiedene Autoren haben sich mit dem Begriff auseinander
gesetzt und eine Definition aus ihrer jeweiligen Sichtweise erarbeitet.
„Wissensmanagement ist die Summe „aller möglichen human- und
technikorientierten Interventionen und Maßnahmen, die dazu geeignet sind, die
Wissensproduktion, -reproduktion, -distribution, -verwertung und –logistik in einer
Organisation zu optimieren“.
Schüppel
[Schü96, S. 191]
„Wissensmanagement ist ein integriertes Interventionskonzept, das sich mit den
Möglichkeiten zur Gestaltung, Lenkung und Entwicklung der organisatorischen
Wissensbasis befasst.“
Romhardt
[Romh98, S. 45]
„Wissensmanagement ist die Gesamtheit aller Planungen und Maßnahmen, mit Hilfe
derer das Wissen und die Erfahrung einzelner Beschäftigter gesammelt, miteinander
verbunden und fortentwickelt werden können.“
Herrmann et al.
[Herr01, S. 15]
„Wissensmanagement kann als Gestaltung und Abstimmung von Lernprozessen
(Wissenstransformation) in und von Organisationen verstanden werden. […] [Ebenso]
umfasst ein ganzheitliches Wissensmanagement [...] die Gestaltung von strukturellen
Rahmenbedingungen, die Lernprozesse in Organisationen fördern.“
Pawlowsky
[Pawl94, S. 158]
„Wissensmanagement meint die Gesamtheit organisationaler Strategien zur
Schaffung einer "intelligenten" Organisation. Mit Blick auf die Personen geht es um
das organisationsweite Niveau der Kompetenzen, Ausbildung und Lernfähigkeit der
Mitglieder; bezüglich der Organisation um die Schaffung, Nutzung und Entwicklung
der kollektiven Intelligenz und des Gemeinschaftssinns; hinsichtlich der
technologischen Infrastruktur um die Schaffung und effiziente Nutzung der zur
Organisation passenden Kommunikations- und Informationsinfrastruktur.“
Willke
[Will98, S. 39]
DefinitionAutor(en)
Quelle: Verfasser
Abbildung 6: Auswahl von Definitionen des Begriffs Wissensmanagement
SEITE 18 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
Die Auswahl in Abbildung 6 zeigt, dass die Schwerpunkte stark variieren. Kernpunkte sind in
der Konzentration auf eine möglichst ganzheitliche Sicht oder aber in der Fokussierung auf
einzelne Teilbereiche, wie etwa die Informations- und Kommunikationstechnologie oder Organi-
sationsfragen, zu sehen. Weitergehende Übersichten verschiedener Definitionen des Wissensma-
nagements sind in den Arbeiten von SCHINDLER [Schi01, S. 36] und AMELINGMEYER [Amel02,
S. 28ff.] zu finden.
Die Streuung dieser Definitionen zeigt die große Unsicherheit und Unschärfe in der Diskussion,
die dazu führt, dass Wissensmanagement noch nicht als ein allgemein gültiges Managementkon-
zept verstanden wird [Prim03, S. 103]. Einige Autoren konstatieren, dass ein ganzheitliches
Wissensmanagement nur als die Kombination aus der kreativen, wissensschaffenden Kapazität
des Wissensträgers Mensch mit Daten verarbeitender Technologie gesehen werden kann
[Prim03, S. 103]. BULLINGER/WÖRNER/PRIETO [BuWP98, S. 38] beschreiben ein erfolgreiches
Wissensmanagement zusammengefasst in der Weise, dass die Einführung unterstützender In-
formations- und Kommunikationstechnologien (IuK) nur eine Dimension erfolgreichen Wis-
sensmanagements sein könne. Vielmehr liege die Lösung zur Realisierung der Nutzenpotentiale
in der sorgfältigen Integration technologischer Hilfsmittel, organisatorischer Strukturen sowie
materieller und immaterieller Anreizsysteme und unternehmenskultureller Aspekte zu einem
ganzheitlichen Ansatz des Wissensmanagements.
Diese Ansicht vertritt auch diese Arbeit, so dass das Implementierungsmodell für wissensba-
sierte Informationssysteme alle Aspekte berücksichtigen muss. Dabei muss es sich um eine
durchgehende methodische Bearbeitung im Unternehmen handeln, da nur dies einen im Wettbe-
werb entscheiden Vorsprung zu schaffen verspricht [ScRe99, S. 55].
3.1.3 Grundlegende Wissensmanagement-Strategien
Im Laufe der Entwicklung des Wissensmanagements sind zahlreiche Strategien für den Umgang
mit der Ressource Wissen entwickelt worden. Daher wird an dieser Stelle diskutiert, inwieweit
die bekannten Vorgehensweisen im Implementierungsmodell Anwendung finden können.
DECKER ET AL. [Deck05, S. 19ff.] unterscheiden die folgenden drei Ansätze:
• Kodifizierungs-/ Personalisierungsansatz
• Prozessorientierter Ansatz
• Ansatz des Technik – Organisation – Mensch – Modells (TOM-Modell)
Kodifizierungs-/ Personalisierungsansatz
Bei dem Kodifizierungs- bzw. Personalisierungsansatz handelt es sich um zwei Vorgehens-
weisen, die unterschiedliche Strategien darstellen (Abbildung 7). Je nach Unternehmensumfeld
und Arbeitsgebiet müssen sie zielgerichtet eingesetzt werden [HaNT99, S. 86]. Sie schließen
sich zwar nicht gegenseitig aus, aber ein maximaler Erfolg ist nur durch die Dominanz einer
Strategie zu erwarten [WeSt03, S. 686]. Insbesondere der Versuch, beide Strategien gleichzeitig
anzuwenden, kann zu Problemen führen. Die Ideen aus beiden Strategien werden im Umgang
mit wissensbasierten Informationssystemen angewendet, daher werden die Ansätze kurz erläu-
tert.
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 19
persönlicher, bidirektionaler Austausch
Personalisierungsstrategie
Kodifizierungsstrategie
Wissensweitergabe über Dokumente
Quelle: Verfasser nach [WeSt03, S. 686]
Abbildung 7: Personalisierungs- und Kodifizierungsstrategie
Die Kodifizierungsstrategie legt größten Wert auf die Dokumentation und Speicherung von
Wissen. In der Regel werden hierfür Computer und Datenbanken eingesetzt, um entsprechend
große Datenmengen verwalten zu können und das Wissen leicht zugänglich zu halten [HaNT99,
S.85]. Ein Verfahren für die Bewahrung des Wissens kann beispielsweise das Modell der Wis-
sensbausteine [Weso05, S. 48] sein. Hierbei wird das Wissen eines Mitarbeiters in einem struk-
turierten Interview erfragt und im Ergebnis die Hauptaspekte textlich und bildlich aufbereitet,
beispielsweise über das Intranet unternehmensweit zugänglich gemacht. Dabei ist die Kodifizie-
rungsstrategie rein angebotsorientiert, d.h. nur die bereits explizierten Teile des Wissens stehen
auch zur Verfügung [Deck05, S. 19]. Dies ist insbesondere dort von Nachteil, wo die Dokumen-
tation Schwächen in Stil, Sprache und Aufbau aufweist und nicht zielgruppengerecht aufbereitet
ist [WeSt03, S. 687]. Daneben kann der fehlende Kontext die Verwendbarkeit einschränken.
Die Personifizierungsstrategie dagegen setzt auf die enge Bindung des Wissens an seinen jewei-
ligen Wissensträger. Es bleibt an die Person gebunden und wird nur in persönlichen Gesprächen
weiter gegeben [HaNT99, S. 85]. Damit müssen die Beteiligten in einem regen und kontinuierli-
chen Austausch stehen [WeSt03, S. 686]. Informationssysteme dienen hierbei nicht zur Speiche-
rung des Wissens an sich, sondern zur Erleichterung und Förderung des Wissensaustausches.
Der Wissensaustausch findet bei dieser Strategie nachfrageorientiert und in der Regel in einem
bestimmten Kontext statt [Deck05, S. 20]. Als besonders vorteilhaft an dieser Strategie kann
festgehalten werden, dass das Wissen in den Köpfen der Mitarbeiter ständig weiter entwickelt
und aktualisiert werden kann. Zusätzlich hat der Wissensgeber die Möglichkeit, individuell auf
die Bedürfnisse des Nachfragenden einzugehen [WeSt03, S. 686]. Dieser Vorteil ist auch gleich-
zeitig ein Nachteil, da das Wissen nur dann zur Verfügung stehen kann, wenn der Mitarbeiter
auch anwesend bzw. erreichbar ist. Scheidet er aus dem Unternehmen aus oder ist er krank, ist
das Wissen für die Unternehmung nicht verfügbar [WeSt03, S. 686].
Beide Strategien können in mannigfaltigen Instrumenten umgesetzt werden. Diese sind mittler-
weile in der Praxis so vielfältig geworden, dass sie nicht vollständig dargestellt werden können.
SEITE 20 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
Eine Auswahl aus den Instrumenten beider Strategien haben WESOLY/STOLK [WeSt03, S. 689ff.]
zusammen gestellt. Sie verweisen darauf, dass die Personalisierungsstrategie sich vorrangig auf
organisatorische Maßnahmen stützt und insbesondere die zwischenmenschlichen Faktoren be-
rücksichtigt. Die von den Autoren genannten Systeme zielen darauf ab, Menschen für einen
Wissensaustausch zueinander zu bringen. Ein Expertensystem kann Mitarbeiter bei Fragestel-
lungen unterstützen, die nicht zu ihren Kernaufgaben gehören, indem sie schnellen fachlichen
Rat bieten. Communities of Practice oder Kommunikationsforen sind eher lose Zusammenkünfte
von Personen, die sich über fachliche Themen austauschen. Allen diesen Methoden gemein ist
die Tatsache, dass sie an der eigentlichen Organisation der Unternehmung kaum etwas verän-
dern. Sie stellen lediglich zusätzliche Hilfsmittel dar, die sich bereits in einigen Unternehmen
bewährt haben.
Die Instrumente der Kodifizierungsstrategie bedürfen mehr der Unterstützung durch technische
Hilfsmittel. Hier eignet sich der Einsatz EDV-basierter Werkzeuge besonders. Der Markt für
diese in der Regel als „Wissensmanagementsysteme“ verkauften Produkte ist von einer hohen
Dynamik gekennzeichnet. Regelmäßig werden neue Systeme auf den Markt gebracht, die sich
oft nur marginal von Vorgängerprodukten oder Angeboten der Wettbewerber unterscheiden.
Somit kann trotz immer wieder vermeintlich neuer Produkte von einem eher konstanten Markt
ausgegangen werden [WeSt03, S. 696].
Allen Produkten gemeinsam ist die Tatsache, dass sie zunächst als eine rein technische Lösung
allein im Raum stehen. Wenn ein Unternehmen diese Instrumente sinnvoll nutzen will, muss
nach anerkannter Meinung neben der Technik auch eine organisatorische Implementierung
vorgenommen werden. Zusätzlich ist eine individuelle Anpassung an die jeweiligen Kundener-
fordernisse notwendig. An dieser Stelle setzt das Implementierungsmodell an und entwickelt
eine Vorgehensweise, die es erlaubt, wissensbasierte Informationssysteme erfolgreich in die
Prozesse eines Unternehmens einzubinden.
Prozessorientierter Ansatz
Die Grundlage dieses Ansatzes ist darin zu sehen, dass eine systematische Verankerung des
Wissensmanagements in den Geschäftsprozessen angestrebt wird. Schließlich wird in jedem
Prozess Wissen angewendet, was allerdings ohne gesteuerte Intervention nicht systematisch
geschieht. Das Ziel besteht in einer Optimierung des Umgangs mit Wissen in der Kette der
Wertschöpfung [Deck05, S. 20].
Die Prozessorientierung geht einher mit der Annahme, dass es vor allem eine Managementauf-
gabe ist, eine regelmäßige Auswahl, Umsetzung und Evaluation von prozessorientierten Wis-
sensmanagement-Strategien durchzuführen. REMUS [Remu02, S. 95ff.] bzw. REMUS/SCHUB
[ReSc02, S. 4] sehen das Ziel darin, die Wissensverarbeitung in den wissensintensiven Ge-
schäftsprozessen zu unterstützen, zu verbessern und weiterzuentwickeln, um schließlich zur
Kernwertschöpfung des Unternehmens beizutragen. Hierbei werden Instrumente des Prozess-
und Wissensmanagements auf verschiedenen Interventionsebenen gemeinsam und integrativ
eingesetzt. Der eigentliche wissensintensive Geschäftsprozess ist immer Auslöser und Treiber
aller Maßnahmen. Er regelt Wissensangebot und –nachfrage und bildet den Kontext für die
Anwendung und Weiterentwicklung von Prozesswissen und Kompetenzen auf individueller und
kollektiver Ebene.
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 21
Geschäfts-
prozesse
Wissens-
prozesse
Strategie
Instrumente
und Systeme
Wissensbasis
Wissens-
kreislauf
Quelle: Verfasser nach [ReSc02]
Abbildung 8: Zentrale Konzepte im prozessorientierten Wissensmanagement
Die Abbildung 8 zeigt, welche Zusammenhänge nach REMUS/SCHUB [ReSc02, S. 5f.] zwischen
den einzelnen Ebenen bestehen. Die Strategieebene bildet durch eine Zieldefinition die Basis für
alle weiteren operativen Prozesse. Die Geschäfts- und Wissensprozesse werden durch einen
Wissenskreislauf verbunden, der den Lebenszyklus des Wissens beschreibt und den Wissens-
austausch zwischen den Prozessen fördert. Unterstützung liefern hierbei verschiedene Instru-
mente und Systeme, v.a. Informations- und Kommunikationstechnologien. Die Wissensbasis als
Abbild des in der Organisation vorhandenen Wissens ist integraler Bestandteil des Gesamtsys-
tems. Eine solche Vorgehensweise bietet sich in ähnlicher Weise für das Implementierungsmo-
dell an. Ausgehend von einer Zieldefinition werden die Prozesse im Sinne einer wissensintensi-
ven Arbeitsweise unterstützt.
Von HEISIG/VORBECK [HeVo01, S. 97ff.] werden für den Wissenskreislauf die vier Kernaktivi-
täten „Wissen erzeugen“, „Wissen speichern“, „Wissen verteilen“ und „Wissen anwenden“
genannt, die einen geschlossenen Prozessablauf des Wissensmanagements bilden und den Rah-
men für ein systematisches prozessorientiertes Wissensmanagement darstellen. Möglichkeiten
der Optimierung bestehen einerseits in der Umgestaltung der Geschäftsprozesse, andererseits
darin, die Geschlossenheit des Wissenskreislaufs zu verbessern. Gemäß des Ansatzes von
HEISIG/VORBECK [HeVo01, S. 97ff.] bestehen an sechs Gestaltungsfeldern unmittelbare Beein-
flussungsmöglichkeiten. Die Abbildung 9 zeigt den zugehörigen Regelkreis mit den sechs zu
beeinflussenden Größen in einer Übersicht. Wird eine Intervention im Wissenskreislauf durch
eine der dargestellten Maßnahmen vorgenommen, so ist grundsätzlich ein Controlling dieser
Maßnahme sowie eine kontinuierliche Messung des identifizierten Wissens notwendig.
SEITE 22 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
Personalmanagement
Unternehmenskultur
Prozessorganisation
Führungssysteme
Informationstechnik
Controlling
Geschäftsprozesskette
Wissen
anwenden
Wissen
erzeugen
Wissen
verteilen
Wissen
speichern
Quelle: Verfasser nach [HeVo01]
Abbildung 9: Gestaltungsrahmen des prozessorientierten Wissensmanagements
Für die konkrete Ausführung eines prozessorientierten Wissensmanagements ist das Genfer
Modell nach PROBST/RAUB/ROMHARDT [PRRo03] richtungsweisend. Es gilt als eines der ersten
durchgängigen Konzepte dieser Art. Die Autoren schlagen insgesamt acht Elemente als Bau-
steine in einem Regelkreis vor (vergleiche Abbildung 10). Die Elemente bilden die möglichen
Interventionsfelder in der unternehmerischen Praxis. Als Kernprozesse lassen sich die sechs
Bausteine Wissensidentifikation, Wissenserwerb, Wissensentwicklung, Wissens(ver)teilung,
Wissensnutzung und Wissensbewahrung bezeichnen. Eine vorhergehende Definition von Wis-
senszielen und abschließende Bewertung des Wissens ergeben über einen Feedbackprozess den
gesamten Managementkreislauf.
Die Autoren weisen darauf hin, dass eine Intervention in einem der Bereiche zwangsläufig Aus-
wirkungen auf andere Prozesse nach sich ziehen wird [PRRo03, S. 28]. Diese Anmerkung er-
scheint insbesondere wichtig im Hinblick auf die Entwicklung eines ganzheitlichen Implemen-
tierungsmodells. Es muss möglichst weitreichend die Auswirkungen einzelner Maßnahmen
betrachten, da durch den Umgang mit einem wissensbasierten Informationssystem alle Wissens-
prozesse tangiert werden.
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 23
Wissens-
erwerb
Wissens-
identifikation
Wissens-
entwicklung
Wissens-
(ver)teilung
Wissens-
nutzung
Wissens-
bewahrung
Wissens-
ziele
Wissens-
bewertung
Kernprozesse
Managementkreislauf
Feedback
Quelle: [PRRo03, S. 32]
Abbildung 10: Bausteine des Wissensmanagementkreislaufs nach PROBST/RAUB/ROMHARDT
Technik – Organisation – Mensch – Modell
Die Kernaussage des Modells ist gemäß Abbildung 11 in einer ganzheitlichen Betrachtung der
Faktoren Technik, Organisation und Mensch zu sehen. Diese von
BULLINGER/WARSCHAT/PRIETO/WÖRNER [BWPW98, S. 8f.] vorgestellte Wissensmanagement-
strategie setzt neben der Informations- und Kommunikationstechnologie auf den Aufbau eines
kompletten Wissensmanagement-Szenarios, dass notwendige Methoden zum Wissenserwerb, zur
Wissensspeicherung und zur Wissensaufbereitung in der Organisation verankert.
Damit wird ersichtlich, dass in diesem Ansatz der Faktor Mensch im Sinne eines Human
Resource Management nicht nur mit einbezogen, sondern sogar in den Vordergrund gestellt
wird. Dies äußert sich etwa in der aktiven Gestaltung einer adäquaten Unternehmenskultur.
Hinter diesem Modell steht die Überzeugung, dass Wissensmanagement in einem Unternehmen
nicht durch eine einzige Aktion oder die Betrachtung einer einzigen Dimension umgesetzt wer-
den kann [Deck05, S. 21]. Beispielsweise kann der Einsatz eines Datenbanksystems ein ent-
scheidendes Element darstellen, was aber ohne begleitende Maßnahmen wenig erfolgverspre-
chend ist. Das Modell fordert auch die Schaffung von entsprechenden Randbedingungen, die die
Mitarbeiter dazu veranlassen, ihr Wissen zu teilen. BULLINGER/WARSCHAT/PRIETO/WÖRNER
[BWPW98, S. 8] schlagen zwar die Einführung von materiellen oder immateriellen Anreiz-
systemen sowie einer entsprechenden Unternehmenskultur vor, eine konkrete Ausgestaltung
wird allerdings nicht aufgezeigt. Hier liegt ein Ansatzpunkt für das Implementierungsmodell.
Die genannten Gestaltungsdimensionen sind nicht im Sinne einer Reihenfolge oder Wertigkeit
zu betrachten, sondern müssen für einen Erfolg der Wissensmanagementidee zusammenwirken.
Bei der Veränderung jeder Dimension ist mit internen Widerständen und Barrieren zu rechen.
SEITE 24 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
Eine Zusammenfassung der wichtigsten Konfliktpunkte kann Abbildung 11 entnommen werden.
Der Einfluss der einzelnen Ebenen ist unterschiedlich.
Mensch
Informations- und
Kommunikations-
Technologien Organisation
Barrieren:
• Fehlender Wissensaustausch
innerhalb und zwischen Unternehmen
• Fehlende Mechanismen zur Wissens-
akquisition, -speicherung und –transfer
• Fehlendes Schnittstellenmanagement
Barrieren:
• Inkonsistente Daten
• starre Wissensaufbereitung
• Mangelhafte Informations- und
Kommunikationsflüsse
Barrieren:
• Wissensverlust durch
Personalfluktuation
• Wissen als persönliches Eigentum
• Ungeeignete Unternehmenskultur
Wissensmanagement
Aufbereitung
Erwerb
Speicherung
Quelle: Verfasser nach [BWPW98, S. 8]
Abbildung 11: Technik-Organisation-Mensch Modell
Zimmermann [Zimm06, S. 10] schätzt den Menschen in der Trias Technik, Organisation und
Mensch als immer bedeutsameren Faktor ein. Zusätzlich postuliert er, dass die Informationstech-
nologie und deren Infrastruktur in ihrer Bedeutung lange Zeit überschätzt wurde. Die Abbildung
12 zeigt diesen Zusammenhang in Form eines Dreiecks auf.
Mensch
Technik
Organisation
Soft- und Hardware, Plattformen
Kommunikationsstrukturen,
Kultur des Miteinander
Prozessorganisation,
Ablauforganisation
Quelle: Verfasser
Abbildung 12: Anteile der drei Ebenen im TOM-Modell
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 25
In der neueren Einschätzung wird der Anteil der Ebene Technik durch die kleine Spitze gebildet,
während der größte Flächenanteil durch den Faktor Mensch eingenommen wird. Dieser Trend
bildet eine Basisannahme für das Implementierungsmodell wissensbasierter Informationssys-
teme.
3.1.4 Eingesetzte Werkzeuge zur Realisierung eines Wissensmanagements
Nach der Analyse der Strategien des Wissensmanagements sollen die Werkzeuge zur
Realisierung von Wissensmanagement-Ansätzen untersucht werden. In der Literatur wird eine
große Anzahl Werkzeuge beschrieben, die häufig schon vor dem Erscheinen des Begriffs
„Wissensmanagement“ bekannt waren [Bode03, S. 124]. An dieser Stelle wird insbesondere zur
Abgrenzung und zur Ableitung von Erkenntnissen für das Implementierungsverfahren
wissensbasierter Informationssysteme ein kurzer Überblick der Methoden gegeben. Aufgrund
der Ausrichtung dieser Arbeit kommen technologische und mitarbeiterorientierte Werkzeuge in
Betracht.
Technologien des Wissensmanagements
BODENDORF [Bode03, S. 125] hat eine Kategorisierung der existierenden Technologien des
Wissensmanagements anhand der Maßnahmen Darstellung, Verteilung, Zugriff, Verwaltung und
Speicherung des Wissens (Abbildung 13) vorgenommen. Die Bezeichnung der eingesetzten
Technologien zeigt, dass es sich meist nicht um neuartige Technologien handelt, sondern nur um
die Anwendung bekannter Strukturen auf die Problembereiche im Umgang mit Wissen.
Darstellung
Speicherung
Verteilung
Zugriff
Verwaltung
Elektronische Dokumente, Multimediale Präsentationen
Messaging, Push-Techniken
Directory Services WissensnetzwerkeWissenskarten
Softwareagenten Filter Data Mining
Retrieval-
Mechanismen
Dokumenten- und Content-
Management-Systeme
Data
Warehouses
Datenbank-
Systeme
Datei-
systeme
Quelle: [Bode03, S. 125]
Abbildung 13: Technologien und Anwendungen des Wissensmanagements
Aufgrund dieser Feststellung zeigt sich auch die Notwendigkeit neuer Verfahren zur Einführung
und Umsetzung der Wissensmanagementwerkzeuge in einer Organisation. Die technischen
Verfahren sind zwar größtenteils bekannt, jedoch mangelt es an Methoden zur effizienten Um-
setzung in Unternehmen. Es handelt sich bei den Technologien in der Regel auch nicht um
SEITE 26 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
selbständige informationstechnische Systeme, sondern vielmehr um die Kombination unter-
schiedlicher, teils sehr innovativer Ansätze [Bode03, S. 127]. Den Versuch der Zuordnung ein-
zelner Technologien und Anwendungen zu den Phasen des Wissensmanagements nach PROBST
hat BODENDORF gemäß Abbildung 14 durchgeführt. Daraus ist die große Streubreite der Instru-
mente ersichtlich, wobei das Implementierungsmodell in ähnlicher Weise für alle Systemklassen
durchgeführt werden kann, da eine strukturierte, wissensorientierte Vorgehensweise in jedem
Fall erforderlich ist.
Mensch, betriebliche AnwendungssystemeExpertensysteme, Fuzzy-Logic-
Systeme, Künstliche Neuronale Netze,
Genetische Algorithmen
Wissensanwendung
Content-Management-Systeme, Workflow-
Management-Systeme, Information Filtering
Informationsagenten, Push-
Mechanismen, E-Mail, Retrieval-
Mechanismen, Filter
Wissensverteilung
Dokumenten-Management-Systeme, Content-
Management-Systeme, Expertensysteme
Dateisysteme, Datenbanken,
Directory-Services, Wissensnetzwerke
Wissensspeicherung
Skill Management, Knowledge Mapping, Assignment
Management, Virtual Teaming, E-Learning, Content-
Management-Systeme, Expertensysteme, Knowledge
Discovery
E-Mail, Data Mining,
Beobachtungsagenten
Wissensentwicklung
Skill Management, Knowledge Mapping,
Suchmaschinen, Knowledge Discovery
Data Mining, Retrieval-Mechanismen,
Wissenskarten
Wissensidentifikation
AnwendungTechnologiePhase
Quelle: [Bode03, S. 127]
Abbildung 14: Technologien und Anwendungen im Wissensmanagementprozess nach PROBST
Neben diesen rein thematisch-sachlichen Zuordnungen einzelner Systemklassen zu Wissens-
managementprozessen haben andere Autoren spezielle auf dem Markt befindliche Anwendungen
den Prozessstufen nach PROBST angegliedert. Einen Überblick über Software-Systeme als Werk-
zeug für ein Wissensmanagement gibt beispielsweise FÖCKER [Föck01]. Sein Fazit der Zuord-
nung einzelner Systeme zu den Prozessen des Wissensmanagements fällt so aus, dass er den
isolierten Einsatz von Wissensmanagement-Basistechnologien ablehnt, da dieser in der Regel
einen vergleichsweise kleinen Nutzen bringt. Seiner Ansicht nach führt eine intelligente Kombi-
nation mit einer integrierten Wissensmanagement-Gesamtlösung zu einer vielfachen Nutzen-
erhöhung für eine Organisation. Als besonderen Aspekt stellt er genau den Anknüpfungspunkt
dieser Arbeit heraus, dadurch dass er der Meinung ist, dass die Einführung und auch der Betrieb
einer solchen Lösung umfangreiche Maßnahmen erfordern.
Personalzentrierte Methoden
Die individuellen Fähigkeiten von Wissensarbeitern sind eine grundlegende Basis für das erfolg-
reiche Agieren von Unternehmen. Darüber hinaus hängt das Gelingen vieler Projekte und Strate-
gien entscheidend davon ab, ob verschiedene Wissensbestandteile und Wissensträger effizient
kombiniert werden können [PRRo03, S. 20]. Hierfür kommen neben den technologieorientierten
Methoden die personalorientierten Methoden in Frage. Das Ziel liegt darin, die Fähigkeiten
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 27
hochqualifizierter „Wissensarbeiter“ und kollektive „organisationale Fähigkeiten“ als das Prob-
lemlösungspotenzial eines Unternehmens [PRRo03, S. 23] zu aktivieren.
Hilfreich ist es, zusammen mit den Mitarbeitern eine sogenannte „win-win situation“, d.h. posi-
tive Effekte für alle Beteiligten, zu schaffen [DFGr02, S. 67]. Die Akzeptanz jeglicher Maßnah-
men durch die Vermittlung dieses Grundgedankens kann dadurch erheblich gefördert werden.
Der wirkliche Flaschenhals ist nicht in der Technik, der Zeit oder dem Budget zu erwarten,
sondern in den Menschen, die später die Gedanken des Wissensmanagements mit Leben füllen
sollen [BeWe03, S. 158].
Als Entwicklungsmaßnahmen für die beteiligten Mitarbeiter gilt es während der Systemimple-
mentierung neben konkreten, bedarfsorientierten Schulungen ein Verständnis für den Aufbau
persönlicher Netzwerke zu aktivieren sowie die Gruppen- und Teamarbeit zu fördern. Die Be-
gründung liegt darin, dass ein Austausch von Wissen, bei dem auch Erfahrungen vermittelt
werden, nicht allein über eine Technologie erfolgen kann. Hier wird eine persönliche Zusam-
menkunft von Mensch zu Mensch fruchtbarer sein [ScRe99, S. 134]. Die Schaffung von geeig-
neten Infrastrukturumgebungen kann die Entstehung von informellen Wissensnetzwerken unter-
stützen [PRRo03, S. 151]. Es muss aber beachtet werden, dass der persönliche Kontakt zwischen
Kollegen nur schwer durch das Management steuerbar ist [PRRo03, S. 151]. Die Rahmenbedin-
gungen müssen die Sozialisierung, d.h. die Kontakt- und Austauschbereitschaft, unter den Mitar-
beitern fördern, so dass ein „vertraut machen“ mit organisationalen Werten, Normen, Verhal-
tensweisen und Rollenerwartungen stattfinden kann [PRRo03, S. 149].
Eine Unterstützung der geforderten Sozialisierung kann in einem Implementierungsvorhaben
beispielsweise durch eine Einbindung der Mitarbeiter in den Veränderungsprozess geschaffen
werden. Die Zusammensetzung der notwendigen Teams sollte nach verschiedenen Gesichts-
punkten wie beispielsweise Sozialkompetenzen oder Fachkompetenzen erfolgen. Eine gewisse
Heterogenität in der Zusammensetzung der Teams ist aus wissensorientierter Sicht wünschens-
wert [Prim03, S. 124]. Durch eine solche Beteiligung der Mitarbeiter kann nicht nur Wissen in
den Köpfen der Mitarbeiter genutzt und verfestigt werden, sondern es bieten sich auch unter
Motivationsgesichtspunkten Vorteile, da die Mitarbeiter später im Produktivbetrieb Strukturen
anwenden, die sie selbst mit entwickelt haben.
Zusammenfassend gesehen sind die vorgestellten Werte im Rahmen des zu entwickelnden
Implementierungsmodells zu berücksichtigen. Eine zentrale Fokussierung muss neben der tech-
nischen Komponente die Sozialisierung des wissensbasierten Informationssystems und der neuen
Prozesse sein.
3.2 Die Lernende Organisation
Das Konzept der Lernenden Organisation beschreibt die zielgerichtete Weiterentwicklung einer
Organisation durch systematische Lerneffekte. Daher wird zunächst geklärt, was unter dem
organisationalen Lernen verstanden wird, um anschließend die wesentlichen Erkenntnisse zur
Förderung des Lernens und zur Vermeidung einer Lernhemmung im Rahmen des Implemen-
tierungsmodells herauszuarbeiten. Das im vorigen Kapitel dargestellte Wissensmanagement zielt
allgemein auf eine höhere Qualität und Zufriedenheit, was auch auf eine lernende Organisation
und eine effizientere Nutzung von Informationen und Wissen abzielt [Kate03]. Das Schlagwort
SEITE 28 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
der „Lernenden Organisation“ ist insofern ein zentraler Punkt, als unter diesem Konzept die
Fähigkeit einer Organisation verstanden wird, auf Veränderungen mit Hilfe einer entsprechenden
Organisationskultur adäquat zu reagieren. Dabei ist immer zu beachten, dass das Lernen als
solches zunächst von einem Individuum ausgeht. Dadurch ist der Ausgangspunkt der meisten
psychologischen Definitionen des Lernens das Individuum [PrBü98, S. 17]. SENGE [Seng98]
versteht in seiner umfassenden und mitarbeiterorientierten Definition unter einer „Lernenden
Organisation“ eine
„Organisation, in der die Menschen kontinuierlich die Fähigkeit entfalten, ihre wah-
ren Ziele zu verwirklichen, in der neue Denkformen gefördert und gemeinsame Hoff-
nungen freigesetzt werden und in der Menschen lernen, miteinander zu lernen“
[Seng98, S. 11].
3.2.1 Das organisationale Lernen
Das organisationale Lernen stellt das zentrale Element des Konzepts der lernenden Organisation
dar und wird von PROBST/BÜCHEL [PrBü98, S. 17] wie folgt definiert:
„Unter organisationalem Lernen ist der Prozess der Veränderung der organisatio-
nalen Wissensbasis, die Verbesserung der Problemlösungs- und Handlungskom-
petenz sowie die Veränderung des gemeinsamen Bezugsrahmens von und für Mit-
glieder der Organisation zu verstehen.“
Die Autoren gehen besonders auf die bisher fehlende Verbindung zwischen einer organisationa-
len und individuellen Bezugsebene ein. Ein wissensbasiertes Informationssystem (vergleiche
Abgrenzungen in den Kapiteln 2.2 und 4.1) ist in der Lage, genau diese Brücke herzustellen, da
das Wissen einzelner Individuen für die Organisation insgesamt bereitgestellt werden kann. Aber
auch hier gilt die Feststellung, dass für einen Wandel immer die Organisationsmitglieder selbst
den zentralen Ansatzpunkt darstellen und das Unternehmen nur den Bezugsrahmen liefert
[PrBü98, S. 19].
KREMS [Krem04] fasst die Anforderungen an eine lernende Organisation zusammen und fordert
als Minimum die folgenden vier Eigenschaften:
• Generierung kontinuierlicher Lernimpulse durch ein Informationssystem
• Etablierung eines Anreizsystems zur Unterstützung der Veränderungen
• Förderung einer Kultur der Veränderungsbereitschaft
• Führung zum Vorantreiben ständiger Anpassungen und Vorleben der Veränderungsbereit-
schaft
Diese Erfordernisse können durch das Implementierungsmodell mit Hilfe eines wissensbasierten
Informationssystems unterstützt werden. Damit können nicht nur die individuellen Lernprozesse
gefördert werden, die dadurch charakterisiert sind, dass Individuen über das „trial and error“-
Verfahren optimierte Vorgehensweisen ermitteln [PrBü98, S. 19]. Es können vielmehr auch die
organisationalen Lerneffekte realisiert werden, die eine ganz andere Qualität als die Summe der
individuellen Lernprozesse darstellen. Durch die größere Tragweite des Lerneffektes können
bessere Ergebnisse erzielt werden. Um diesen Transfer von der individuellen zur organisationa-
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 29
len Ebene zu erreichen, müssen die drei Transformationsbedingungen Kommunikation, Transpa-
renz und Integration gegeben sein [PrBü98, S. 22] (vergleiche Abbildung 15).
Organisation
Individuum Kommunikation
Transparenz
Integration
Quelle: [PrBü98, S. 22]
Abbildung 15: Transformation von individuellem zu organisationalem Wissen
Der Transformationsprozess bedeutet, dass es durch die Kommunikation des Wissens zu einer
Übertragung zwischen den Individuen kommt. Die Transparenz führt zu einem qualitativen
Sprung, der das Wissen einer kollektiven Argumentation unterzieht und anschließend in einer
neuen Qualität für die Gesamtorganisation nutzbar macht. Dieses Wissen muss in einem Spei-
chermedium, wie etwa dem wissensbasierten Informationssystem abgelegt werden. Der dritte
Schritt der Integration bewirkt, dass das neu erworbene Wissen in weiteren Anwendungsfällen
für neue Problemlösungen kombiniert werden kann.
Es lassen sich dabei grundsätzlich drei Ebenen des Lernens identifizieren, die sich in ihrem
Inhalt und in der Tiefe unterscheiden. Dies sind die Ebenen des
• Anpassungslernens,
• Veränderungslernens und
• Prozesslernens.
Ziele Handlungen Ergebnisse
Korrekturen
Quelle: Verfasser nach [ArSc78, S. 18]
Abbildung 16: Anpassungslernen
Das Anpassungslernen ist die niedrigste Stufe und wird nach ARGYRIS/SCHÖN [ArSc78, S. 18]
auch als „single-loop learning“ bezeichnet (Abbildung 16). Hierbei handelt es sich um das
Aufgreifen und die Interpretation von neuen Informationen durch Organisationsmitglieder.
Werden diese neuen Informationen als Fehler der im Gebrauch befindlichen Handlungstheorie
aufgefasst und diese im Anschluss korrigiert, so hat ein Lernprozess durch eine Anpassung
SEITE 30 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
stattgefunden [PrBü98, S. 35]. Die Regulierung findet auf Basis einer vorhandenen Norm statt,
wobei der Stimulus in dem Auseinanderklaffen von Ziel und Ergebnis zu sehen ist.
Im Ergebnis wird der Lernprozess an den bestehenden Normen und Werten der Organisation
festgemacht. PROBST/BÜCHEL [PrBü98, S. 36] definieren, dass das Anpassungslernen „die effek-
tive Adaption an vorgegebene Ziele und Normen durch die Bewältigung der Umwelt ist“.
Das Veränderungslernen geht eine Ebene weiter, indem zusätzlich zu den Korrekturen an
Handlungen auch die ursprünglichen Ziele in Frage gestellt und gegebenenfalls verändert werden
(Abbildung 17). Daher gilt das Veränderungslernen auch als die „Hinterfragung von organisa-
tionalen Normen und Werten, sowie die Restrukturierung dieser in einem neuen Bezugsrahmen“
[PrBü98, S. 37]. Als wichtigste Voraussetzung für das Veränderungslernen stellen
ARGYRIS/SCHÖN eine offene Informationsdarlegung heraus, also genau den Prozess, der durch
wissensbasierte Informationssysteme unterstützt werden kann.
Ziele Handlungen Ergebnisse
Korrekturen
Korrekturen
Quelle: Verfasser nach [ArSc78, S. 20]
Abbildung 17: Veränderungslernen
Die höchste Ebene des Lernens stellt das Prozesslernen dar (Abbildung 18). Dieser Prozess kann
auch als „Lernen zu lernen“ bezeichnet werden, da es nicht um ein „Etwas“ geht, sondern die
Prozesse des Lernens selbst im Vordergrund stehen und zum Gegenstand werden [PrBü98, S.
38]. Der Gesamtprozess kann als die Erkenntnis über den Vorgang des Anpassungs- und Verän-
derungslernens bezeichnet werden. Der zentrale Bestandteil dieser hohen Lernebene ist die
Verbesserung der Lernfähigkeit, indem Lernen selbst zum Gegenstand des Lernens wird
[PrBü98, S. 38]. Hierbei ist sehr stark das soziale System einbezogen, welches wiederum in
seiner Vernetzung durch wissensbasierte Informationssysteme unterstützt werden kann. Jeder
Akteur bekommt die Möglichkeit, nicht nur das eigene Umfeld zu optimieren, sondern den
maximalen Nutzen innerhalb des komplexen Beziehungsgefüges der Organisation zu erreichen
[PrBü98, S. 38].
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 31
Ziele Handlungen Ergebnisse
Korrekturen
Korrekturen
Reflexion,
Analyse und
Herstellung
eines
Sinnbezugs
Korrekturen
Quelle: Verfasser nach [ArSc78, S. 26]
Abbildung 18: Prozesslernen
3.2.2 Lernfördernde und lernhemmende Mechanismen in lernenden Organisationen
Eine lernende Organisation befindet sich immer in Bewegung. Dieser Prozess ist mit folgendem
Bild zu veranschaulichen:
„Lernen ist wie Rudern gegen den Strom. Sobald man aufhört, treibt man zu-
rück.“(chinesisches Sprichwort)
Alle neuen Ereignisse dürfen nicht als störend, sondern müssen als anregend empfunden und für
neue Entwicklungsprozesse genutzt werden, um die Wissensbasis und die Handlungsspielräume
an die neuen Erfordernisse anzupassen. Die Grundlage hierfür ist eine offene und von Individua-
lität geprägte Organisation, die ein innovatives Lösen von Problemen erlaubt und unterstützt.
FRIELING/REUTHER [FrRe93] nennen u.a. folgende Mechanismen, die die Lernprozesse unter-
stützen können:
• Gut funktionierende Informations- und Kommunikationssysteme
• Gemeinsame Visionen und Ziele
• Gemeinsame Vertrauensbasis sowie Kooperations- und Konfliktlösungsfähigkeit
• Fehlertoleranz bei riskanten Vorhaben sowie Belohnung von Engagement
• Unterstützung neuer Ideen, Integration von Personal- und Organisationsentwicklung
Einen weiteren Ansatz liefert SENGE [Seng98], der das Lernen in Organisationen durch fünf
Vorgehensweisen bzw. Disziplinen gefördert sieht. Die Gesamtheit der Disziplinen lässt sich
folgendermaßen charakterisieren:
• 1. „Personal Mastery“: Diese beschreibt, was die Entwicklung des Einzelnen bedeutet,
indem durch die Entwicklung des Potenzials einzelner Mitglieder einer Organisation das
Niveau des gesamten Unternehmens angehoben wird.
SEITE 32 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
• 2. „Mentale Modelle“: Hier wird die Überprüfung der althergebrachten Denk- und
Verhaltensweisen gefordert, um ein freies und unvoreingenommenes Denken zu errei-
chen. Das bedeutet vor allem das Lösen von alten Gewohnheiten.
• 3. „Gemeinsame Vision“: Diese Disziplin stellt die Zielvorgabe dar, nach der die
Gemeinschaft handelt, die sie zusammenhält und der sich die Organisation verschrieben
hat. Hier wird insbesondere die emotionale Komponente offenbar.
• 4. „Team Learning“: Das Ziel des „Team Learnings“ ist es, die Mitglieder eines Teams
kontinuierlich, konsequent und gemeinsam auf die Zielerreichung auszurichten. Dies
vermeidet die Verschwendung von Energien, setzt aber bei den Teammitgliedern ein ho-
hes Maß an Dialog- und Diskussionsfähigkeit voraus.
• 5. „Systemdenken“: Die letzte Disziplin zielt darauf ab, die ganzheitliche Sicht und das
Erkennen von Wechselbeziehungen zu fördern. Dies kann auch als die konzeptionelle
Grundlage aller Disziplinen bezeichnet werden.
Diese Mechanismen gilt es in dem zu erstellenden Implementierungsmodell zu beachten, wobei
nicht alle Merkmale vollständig integrierbar sind. Wichtig ist die Tatsache, dass der Träger eines
Lernprozesses immer das Individuum ist und das Lernen von ihm ausgeht. Um zu einem opti-
malen Erfolg zu gelangen, müssen die Lernprozesse der Organisation in Einklang gebracht
werden. Die Lernerfolge Einzelner können mit Hilfe des Unterstützungsmediums des wissensba-
sierten Informationssystems gemäß Systemabgrenzung in Kapitel 2.2 das organisationale Lernen
insgesamt fördern.
In der Literatur werden aber auch verschiedene Faktoren genannt, die das Lernen hemmen und
die es durch das Implementierungsmodell von vornherein so weit wie möglich zu vermeiden gilt.
SENGE [Seng98, S. 28ff.] führt hierzu sieben im wesentlichen individuell geprägte Lernhemm-
nisse in Organisationen auf:
• „Ich bin meine Position“: Dies meint eine übertriebene Konzentration auf die eigene
Stellung, wodurch es zu einer fehlgeleiteten Identität kommen kann. Die ganzheitliche
Sichtweise geht verloren und die wahren Ursachen, beispielsweise für prozessuale
Fehler, werden nicht mehr erkannt.
• „Der Feind da draußen“: Die Schuld wird grundsätzlich bei anderen gesucht. Dies
versperrt die Sicht auf wirklich effektive Maßnahmen und Interventionen zur Behe-
bung eines Missstandes.
• „Angriff ist die beste Verteidigung“: Eine „Proaktivität“ ist modern. Eine massive
Reaktion führt jedoch nur dann zum gewünschten Ergebnis, wenn das wahre Problem
erkannt wird. Meist entsteht nur eine Aggressivität, die aus einer emotionalen Befind-
lichkeit rührt.
• „Fixierung auf Ereignisse“: Viele Gespräche oder Diskussionen konzentrieren sich auf
vorgefallene Geschehnisse, aber nicht auf zugrunde liegende Wurzeln oder Zusam-
menhänge. Genau diese zu erkennen, ist wichtig für generatives Lernen und kreatives
Gestalten.
• „Das Gleichnis vom gekochten Frosch“: Wenn ein Frosch in heißes Wasser geworfen
wird, wird er sofort versuchen herauszuklettern. Wird allerdings das Wasser ganz lang-
sam erwärmt, wird er zunächst Wohlbehagen verspüren und anschließend müde, bis er
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 33
verkocht. Der innere Wahrnehmungsapparat versagt, da er auf schnelle Wechsel der
Umgebungsbedingungen eingestellt ist. Ähnliche Effekte lassen sich auch in Organisa-
tionen erkennen, wo oft schleichende Prozesse nicht erkannt werden, die aber die
größten Bedrohungen darstellen.
• „Die Illusion, dass wir aus Erfahrungen lernen“: Der Mensch lernt am meisten aus di-
rekten Erfahrungen. In einer Organisation liegen Reiz und erfahrene Reaktion meist
weit auseinander, so dass sich das System der Lernerfahrung selbst im Weg steht.
• „Der Mythos vom Managementteam“: Eine Teamarbeit wird in Arbeitsgruppen durch
das Ausfechten von Revierkämpfen regelmäßig unterdrückt. Managementteams funk-
tionieren solange gut, wie sie sich mit Routineproblemen beschäftigen. Unter Belas-
tung brechen sie in sich zusammen, weil bei komplexen Sachverhalten der fehlende
Teamgeist offenbar wird.
3.2.3 Defizite im Umgang mit Wissen
Defizite im Umgang mit Wissen müssen von einer lernenden Organisation so schnell wie mög-
lich aufgedeckt werden, um gezielte Maßnahmen zur Gegensteuerung zu ergreifen. Wissensin-
tensive Prozesse laufen in allen Teilen eines Unternehmens ab, so dass ein Gesamtblick erfor-
derlich ist. WESOLY/STOLK [WeSt03, S. 688] haben einige betriebliche Problemsituationen, die
auf Defizite in wissensintensiven Bereichen deuten, zusammen gestellt. Sie sollen hier in einer
kurzen Übersicht angeführt werden, da sie für das Implementierungsmodell Hinweise liefern, auf
welche Situationen verstärkt zu achten ist. Insbesondere diese leicht erkennbaren Aspekte sind
zu sehen, bei deren Lösung ein wissensbasiertes Informationssystem (vergleiche Kapitel 2.2) wie
folgt unterstützen kann:
• Es dauert sehr lange, bis neue Mitarbeiter eingearbeitet sind. Hier werden Abläufe und
Prozesse, die für erfahrene Mitarbeiter selbstverständlich sind, jungen Mitarbeitern nicht
in geeigneter Form vermittelt. Das wissensbasierte Informationssystem kann einen Über-
blick aller laufenden Prozesse mit weitergehenden Informationen liefern.
• Unterschiedliche Schichten des gleichen (Produktions-)Prozesses oder gleiche Abteilun-
gen an unterschiedlichen Standorten haben unterschiedliche Performance. Dies deutet
auf einen unterschiedlichen Wissensstand der Mitarbeiter hin, der mit Hilfe der Datenba-
sis eines wissensbasierten Informationssystems angeglichen werden kann.
• Die gleichen Fehler werden immer wieder gemacht. Notwendig ist eine ausreichende Do-
kumentation der Fehler und eine geeignete Bereitstellung des Wissens über gelöste Feh-
ler über Schicht- und Abteilungsgrenzen hinweg.
• Der einzige Mitarbeiter, der bestimmte Probleme lösen kann, ist vor kurzem in Rente ge-
gangen. Entscheidend ist hierbei die Motivation des Mitarbeiters sein Wissen rechtzeitig
weiterzugeben und - soweit möglich - wesentliche Teile in einem wissensbasierten In-
formationssystem zu dokumentieren.
• Das Treffen von Entscheidungen fällt schwer, weil Informationen nicht vorhanden sind.
Oftmals sind die Informationen sogar vorhanden. Nur sind sie in einer allgemeinen In-
formationsflut verloren gegangen. Eine wichtige Zielorientierung bei der Implementie-
rung von wissensbasierten Informationssystemen muss daher eine für Führungskräfte ge-
SEITE 34 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
eignete Datenaufbereitung sein, die in Entscheidungsprozessen regelmäßig und schnell
abgefragt werden kann.
• Das Rad wird immer wieder neu erfunden. Entscheidend ist die schnelle und einfache
Wiederauffindbarkeit von Informationen und bereits vorhandenen Wissensbeständen.
Dadurch werden Mehrfachentwicklungen bereits im Vorfeld vermieden.
Der Umgang mit Wissen darf nicht dazu führen, dass das Wissen selbst von den Individuen
abgetrennt wird. Dies würde genauso wie die Substitution von persönlichen Kontakten durch
Softwaresysteme dazu führen, dass das Wissen nicht mehr greifbar bzw. kontextgebunden und
damit nutzlos wird. Ein wichtiger Aspekt ist auch das Erkennen der Bedeutung des menschlichen
Denkens für die Weiterentwicklung von kodifiziertem Wissen. Das dokumentierte Wissen allein
ist nicht in der Lage ein Problem zu lösen. Dies kann nur durch die Verarbeitung und Anwen-
dung der Ressource durch ein Individuum geschehen.
3.3 Anforderungen an die Unternehmenskultur
Die Überlegungen zur Lernenden Organisation führen direkt zum Begriff der Unternehmens-
kultur, denn die darin verankerte Kultur des Lernens entscheidet über den Erfolg jeglicher Wis-
sensaktivitäten [Borm02, S. 41]. Der Begriff der Unternehmenskultur ist äußerst komplex, ent-
scheidet in einem Unternehmen aber maßgeblich über das Denken und Handeln der Mitarbeiter.
Die Unternehmenskultur kann als einer der wichtigsten Größen für die Veränderungsbereitschaft
innerhalb einer Organisation angesehen werden [BeWe03, S. 155]. Besonders wichtig ist die
Akzeptanz von emotionalen Entscheidungen, da Menschen eine Entscheidung in der Regel
zunächst emotional treffen und sie erst danach rational begründen [ScRe99, S. 199].
Aus diesem Bereich der Unternehmenskultur muss bei jeglichen Reorganisationsgedanken mit
Widerständen gerechnet werden. Weitgehend planbar und damit auch steuerbar sind Faktoren
wie limitierte Budgets oder administrative Hürden. Das Verhalten der Menschen aber ist in
keiner Weise verlässlich, geschweige denn plan- und steuerbar [BeWe03, S. 156]. Daher ist ein
frühzeitiges Eingehen auf die dynamische Unternehmensinnenwelt notwendig. Das erste Ziel ist,
eine Veränderungsbereitschaft durch Abbau von Ängsten zu erzeugen. Schließlich bedeutet jede
Veränderung die Aufgabe von liebgewonnenen Gewohnheiten. Der innere Widerstand dagegen
ist eine nur allzu menschliche Eigenschaft [BeWe03, S. 156]. An die Unternehmenskultur muss
ein hoher Anspruch gestellt werden, der darauf abzielt, eine Bereitschaft zum aktiven Mittragen
des organisatorischen Wandels zu erzeugen. Die Kultur gilt als zentraler Faktor für den Erfolg
oder Nichterfolg von ganzen Unternehmen und Projekten [Dier03, S. 313]. Sie wird im Folgen-
den näher untersucht.
3.3.1 Die Bedeutung der Unternehmenskultur
Der Begriff „Unternehmenskultur“ fasst die Unternehmung insgesamt als Kultursystem auf und
geht davon aus, dass sich Unternehmen eigene, unverwechselbare Vorstellungs- und Orientie-
rungsmuster aufbauen, die das Verhalten der Mitglieder und der betrieblichen Funktionsbereiche
nachhaltig prägen [StSc05, S. 710]. SCHEIN [Sche95, S. 29ff.] erklärt die Unternehmenskultur als
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 35
Resultat des Zusammenspiels dreier Kulturebenen. Die drei Ebenen sind laut Abbildung 19
Artefakte, Werte und Grundannahmen.
Die Artefakte sind beobachtbare, nicht einfach deutbare Verhaltensmuster und Ausdrucksformen
einer Unternehmenskultur. Die angenommenen und internalisierten Werte definieren das in einer
Unternehmung vorherrschende Weltbild. Die Basis bilden in diesem Modell die Grundannah-
men, die die grundlegenden Ansichten über eine Kultur umfassen, in aller Regel als selbstver-
ständlich gelten und dadurch unsichtbar sind.
Grundannahmen
Beziehung zur Umwelt, Menschenbild
Wissen von Realität, Zeit und Raum
Wesen menschlicher Aktivitäten und Beziehungen
Werte
Angenommene Werte, z.B. Unternehmensgrundsätze
Internalisierte Werte, z.B. Leistung
Artefakte
Architektur, Bekleidung, Dokumente, Slang, Jargon
Rituale, Zeremonien
Geschichten, Mythen, Anekdoten
Quelle: [Sche95, S. 30]
Abbildung 19: Ebenen einer Unternehmenskultur
STEINMANN/SCHREYÖGG [StSc05, S. 711f.] identifizieren einige Kernelemente, die heute mehr-
heitlich mit einer Unternehmenskultur in Verbindung gebracht werden:
• Es handelt sich bei einer Unternehmenskultur um ein implizites Phänomen. Sie ist
nicht als quasi physische Existenz direkt zu beobachten, sondern liegt als eine Art
Muster dem Handeln zugrunde. Dadurch prägt sie das Selbstverständnis der Handeln-
den und die Identität einer Organisation.
• Unternehmenskulturen werden gelebt. Im Handeln der Mitarbeiter sind ihre Orientie-
rungsmuster zu erkennen, wobei die Selbstreflexion nicht die Regel ist.
• Unternehmenskulturen beziehen sich auf gemeinsame Orientierungen und Werte und
prägen dadurch das Handeln der Individuen. Somit macht die Kultur das organisatori-
sche Handeln bis zu einem gewissen Grad kohärent.
• Die Unternehmenskultur ist Ergebnis eines Lernprozesses im Umgang mit internen
und externen Problemen. Durch die Anerkennung bestimmter Handlungsweisen als er-
folgreiche Problemlösung kristallisieren sich Zug um Zug bevorzugte Wege des Den-
SEITE 36 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
kens heraus, bis diese Orientierungsmuster zu mehr oder weniger selbstverständlichen
Voraussetzungen des organisatorischen Handelns werden. Daher hat eine Unterneh-
menskultur immer eine Entwicklungsgeschichte.
• Die Unternehmenskultur repräsentiert die konzeptionelle Welt aller Organisa-
tionsmitglieder. Sie gibt die Muster für die Wahrnehmung und Interpretation von Er-
eignissen vor. Dadurch verschaffen sich die Organisationsmitglieder ein Bild von der
Aufgabenumwelt auf Basis eines gemeinsam verfügbaren Grundverständnisses.
• Die Unternehmenskultur wird in einem Sozialisierungsprozess vermittelt und nur in
den seltensten Fällen bewusst gelernt. Organisationen entwickeln in ihrer Geschichte
eine Reihe von Mechanismen, die dem neuen Organisationsmitglied verdeutlichen, wie
im Sinne der kulturellen Tradition zu handeln ist und welches Verhalten richtig oder
falsch ist.
Die obigen Punkte zeigen, dass eine Unternehmenskultur nicht direkt sichtbar, aber dennoch
veränderbar ist. Um zu einer Beeinflussung der Unternehmenskultur durch das Implementie-
rungsmodell zu gelangen, wird im Folgenden die Frage geklärt, wie eine wissensorientierte
Unternehmenskultur aufgebaut ist und an welchen Stellen eine potenzielle Einflussnahme mög-
lich ist.
3.3.2 Charakterisierung einer wissensorientierten Unternehmenskultur
Eine wissensorientierte Unternehmenskultur setzt eine Vielfalt von Eigenschaften der Individuen
voraus. In einer lern- und wissensorientierten Kultur mit einem aufnahmebereiten Umfeld be-
steht überhaupt erst die Möglichkeit, wissensorientierte Technologien effizient einzusetzen
[PRRo03, S. 159]. Die Elemente für den Veränderungsprozess hin zu einer wissensorientierten
Unternehmenskultur gilt es aktiv zu gestalten [Borm02, S. 41]. Es bedarf grundsätzlicher Werte
wie Offenheit, Transparenz, einer größeren individuellen Selbstverantwortung und eines verbin-
denden Gemeinschaftsgefühls [Panh04, S. 45]. Als Voraussetzungen für kooperatives Lernen
und den gemeinsamen Umgang mit Wissen gelten ein positives soziales Klima und eine ausge-
prägte Kommunikationskultur zu schaffen. Wesentliche Charakteristika der Organisationsmit-
glieder sollen sein [Panh04, S. 45]:
• das Vertrauen in die Organisation und in die Kollegen,
• eine ausgeprägte Kommunikationsfähigkeit,
• ein eigenes Selbstwertgefühl,
• die Fähigkeit, kritisch zu denken und das Wissen, kritisch denken zu dürfen,
• die Fähigkeit, Konflikte zu lösen,
• die Fähigkeit, Entscheidungen zu treffen und das Wissen, sie auch treffen zu dürfen,
• das Gefühl der Zusammengehörigkeit.
Insbesondere der letzte Punkt wird in der heutigen Konkurrenzsituation in einem Prinzip des
„survival of the fittest“ vernachlässigt und schafft ein Klima des internen Wettbewerbs und
Argwohns. Aber gerade der Wille der Wissensträger einer Unternehmung ihr Wissen zu teilen,
muss in der Kultur der Unternehmung verankert sein. Dazu sind als Voraussetzung Bekenntnisse
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 37
der Entscheidungsebene zu diesem Prozess notwendig, welche vor allem durch ein entsprechen-
des Vorleben der handelnden Personen sichtbar werden müssen [Prim03, S. 215].
Im Zusammenhang mit Wissen wird im Rahmen der Unternehmenskultur auch von einigen
Autoren von einer Wissenskultur gesprochen. Hierbei muss in starkem Maße zwischen dem, was
wünschenswert ist und dem, was tatsächlich das Handeln bestimmt, unterschieden werden. Laut
HERBST [Herb00, S. 30f.] zeigen sich die Eigenschaften einer Wissenskultur darin:
• ob Wissen regelmäßig und hierarchieübergreifend geteilt oder gehütet wird,
• ob Wissen allgemein zugänglich ist und als wichtig erachtet wird,
• und ob die Organisation eine Kultur hat, die das Entstehen, den Austausch und das
Anwenden von Wissen fördert.
Der Aufbau einer Wissenskultur setzt eine Offenheit für den Austausch von Wissen voraus.
Nicht mehr das Wissen an sich, sondern dessen Anwendung in verschiedenen Situationen und
die effiziente Gewinnung neuen Wissens sind für den entscheidenden Wettbewerbsvorsprung
ausschlaggebend [ScRe99, S. 113]. Zur Verbesserung und effizienteren Nutzung des geistigen
Potenzials der Mitarbeiter und zur Förderung einer Wissenskultur sind Werte, Normen, Emotio-
nen und Motivation die entscheidenden Einflussfaktoren.
Bei allen Überlegungen darf nicht vergessen werden, dass die Führungskräfte konsequent in
einer Vorbildfunktion handeln müssen. Sie schaffen dadurch eine Vertrauenskultur, in der die
Mitarbeiter aktiv und eigenständig beginnen, aus eigenem Interesse neue Ideen zu entwickeln
und zu erproben. Bei dem Aufbau des notwendigen Vertrauens nimmt die persönliche Kommu-
nikation eine herausragende Rolle ein [Herb00, S. 37]. Ein Vertrauen kann durch viele positive
Beispiele nur langsam aufgebaut werden, aber durch nur ein negatives, oder als negativ empfun-
denes Ereignis sehr schnell wieder zerstört werden. In diesem Zusammenhang ist der Umgang
mit Fehlern ein wichtiger Bestandteil einer Wissenskultur. Ein Klima der Fehlerfreundlichkeit ist
in einer lernenden Organisation selbstverständlich, da eine Fehlervermeidungskultur Neues im
Keim erstickt [PRRo03, S. 120]. Mitarbeiter dürfen nicht dafür bestraft werden, dass ihnen auf
der Suche nach innovativen Lösungen auf unbekanntem Terrain Fehler unterlaufen, die selbst bei
sorgfältigem Vorgehen unvermeidlich sind.
3.3.3 Verknüpfung mit den Unternehmenszielen
Ziele fokussieren die Aufmerksamkeit und sollen Aktivitäten zur Zielerreichung mobilisieren
[StSc05, S. 547]. Sie haben nach BEST/WETH [BeWe03, S. 92] im Unternehmensumfeld weit
reichende Funktionen wie:
• eine Informationsfunktion, die für alle Mitarbeiter das zu erreichende Ziel eindeutig
definiert,
• eine Koordinationsfunktion zur Steuerung aller unternehmensinterner Aktivitäten, um
dadurch zur Konfliktvermeidung zwischen verschiedenen Bereichen und Abteilungen
beizutragen und
• eine Motivationsfunktion, um die Mitarbeiter dazu zu aktivieren, Lösungen zum
Schließen der Lücke zwischen Ist-Zustand und Soll-Zustand zielorientiert zu erarbei-
ten.
SEITE 38 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
Daher muss im Rahmen einer Zieldefinition für das Implementierungsmodell im Unternehmen
ein Wissensleitbild oder eine Wissensvision integriert werden. Dieses Wissensleitbild ist, im
Gegensatz zu der historisch gewachsenen Unternehmenskultur, in die Zukunft gerichtet und
beinhaltet daher eine visionäre Komponente [Herb00, S. 38]. Durch die Zukunftsorientierung
wird der Gefahr entgegen gewirkt, dass das Wissen nur auf Erfahrungen aus der Vergangenheit
aufbaut und die Sicht auf Neues verstellt wird. Die visionäre Komponente dagegen ist eng an die
Frage gebunden, inwieweit sich eine Wissenskultur aus der bestehenden Unternehmenskultur
heraus aufbauen lässt. Aus den zuvor dargestellten Eigenschaften der Unternehmenskultur ist es
notwendig, alle Maßnahmen in Einklang mit diesen Kultureigenschaften und den Unterneh-
menszielen zu planen. Hilfreich ist die Ausgabe einer Vision, die das Ziel in wenigen Worten
plakativ verdeutlicht [BeWe03, S. 15]. Diese schafft ein klares Bild von der Intention des Vor-
habens und hilft, das ausgegebene Ziel nicht aus den Augen zu verlieren. Besonders im Anfangs-
stadium, wo die Hürden noch unüberwindbar scheinen und das Vorhaben abstrakt ist, spielt die
griffige Vision die entscheidende Rolle als Gesicht und Leitfaden für die folgenden Aktivitäten
[BeWe03, S. 15]. Mit Hilfe der Ziele wird eine Neuorientierung und eine Fixierung auf die
weichen Faktoren wie Vertrauen und Offenheit festgelegt.
Die Erwartungen an die Ergebnisse eines Implementierungsvorhabens müssen langfristig ausge-
richtet und insgesamt konsistent mit den weiteren Zielen, Strategien und Taktiken abgestimmt
sein. Die Positionierung des Leitbildes und der dahinter stehenden Vision muss als Wegweiser
für die Mitarbeiter verständlich sein. Gezielte Veränderungen der Unternehmenskultur sind mit
vielen Unwägbarkeiten versehen. Im Normalfall wird nur eine Beeinflussung der Rahmenbedin-
gungen möglich sein, denn eine Verhaltensänderung des Einzelnen kann nicht befohlen werden
[PRRo03, S. 43].
3.3.4 Möglichkeiten eines Kulturwandels
Eine wissensorientierte Unternehmenskultur kann durch den schwierigen Sozialisationsprozess
nur langsam und behutsam aufgebaut werden. Im Rahmen der Frage nach einem Wandel einer
bestehenden Unternehmenskultur hin zu einem wissensförderlichen Verhalten von Mitarbeitern
muss ein besonderes Augenmerk auf die in jeder Organisation geltenden „heimlichen“ Spielre-
geln gelegt werden. Sie sind in besonderem Maße dazu geeignet, die Nutzung fremdem Wissens
zu blockieren [PRR003, S. 178]. Problematisch ist die Tatsache, dass die geheimen Spielregeln
den offiziellen Spielregeln oft zuwider laufen [Herb00, S. 32]. Einige Beispiele sind in der
Abbildung 20 aufgeführt. Sie zeigen, dass die offiziellen Spielregeln als Betrachtungsbasis auf
keinen Fall ausreichen.
Die Möglichkeiten des Kulturwandels hängen weiter sehr stark von den Erfahrungen der Mitar-
beiter mit vorangegangenen Veränderungen ab. Wurden in der Vergangenheit bereits negative
Erfahrungen mit „versteckten“ Zielen oder aus dem Ruder gelaufenen Projekten gemacht, so ist
mit einer anfänglichen Bereitschaft von „Null“ zu rechnen [BeWe03, S. 156]. In einer solchen
Konstellation gilt noch mehr als ohnehin schon erforderlich,
• einen Konsens aller Beteiligten zu schaffen,
• eine eindeutige Unterstützung der Unternehmensleitung zu erhalten und
• diese in einem großen Kreis zu signalisieren.
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 39
„Sei zuverlässig und seriös.“„Sei offen und ehrlich.“
„Bonus gibt es nur für Einzelleistungen.“„Das Ergebnis der Gruppe zählt.“
„Profiliere dich damit allein.“„Teile das Wissen mit deinen Kollegen.“
„Schlachte Fehler anderer aus.“„Toleriere Fehler.“
„Zeige Ellbogen.“„Arbeite Kooperativ.“
Heimliche SpielregelOffizielle Spielregel
Quelle: Verfasser nach [Herb00, S.32]
Abbildung 20: Offizielle und heimliche Spielregeln einer Unternehmenskultur
Für den Prozess des Wandels der Unternehmenskultur sind mehrere Dimensionen zu beachten.
Laut PANHANS [Panh04, S. 46] ist die Kommunikation der entscheidende Faktor. Gerade bei
dem Vorhandensein von computergestützten Informations- und Kommunikationsplattformen
muss die Kommunikation zur Förderung eines kooperativen Lernens aktiv gelebt werden. Zur
Veränderung der Unternehmenskultur im Rahmen der Implementierung eines wissensbasierten
Informationssystems müssen ganz klare Vorstellungen über Werte, Verhaltensnormen, Denk-
weisen und Handlungsrichtlinien entwickelt und kommuniziert werden. Sie dienen dem Aufbau
einer Vertrauenskultur, eines Gemeinschaftssinns, der Transparenz und Offenheit sowie der
Wertschätzung eines jeden Einzelnen. Die Autorin stellt fest: Eine Veränderungsstrategie ist nur
so gut wie das Konzept, mit dem sie kommuniziert wird.
BORMANN [Borm02, S. 42f.] beschreibt neben dem wesentlichen Aspekt der Kommunikation als
Ziel der Kulturveränderung die Integration von auftretenden Widersprüchen. Die Gegensätze
können sich in vielen Integrationsvariablen äußern, z.B.:
• Person vs. Organisation,
• Verändern vs. Bewahren oder
• Technische vs. soziale Systeme.
Zur Realisierung eines wirksamen Integrationsprozesses verlangt BORMANN [Borm02] eine klare
Zieldefinition, die Gestaltung eines Rahmens für Zeit, Ressourcen, Arbeitsklima, die Zulassung
einer Selbstorganisation sowie die Reflexion erzielter Ergebnisse. Insbesondere die Reflexion
führt zu neuen Entscheidungen für das weitere Vorgehen. Allerdings bedingt dies auch, dass die
Prozesse immer wieder neu gestaltet werden müssen und das ausgegebene Ziel mehr eine Rich-
tung denn einen konkreten Zielpunkt darstellt. Der Vorteil liegt klar in der Möglichkeit der
situationsbedingten Anpassung und in dem Wegfall von starren, korsettartigen Strukturen.
Im Zusammenhang mit den in Kapitel 2.2 abgegrenzten wissensbasierten Informationssystemen
müssen obige Punkte berücksichtigt werden, wobei insbesondere der in der Wissenskultur ver-
ankerte Umgang mit Fehlern von Bedeutung ist. Eine Intoleranz gegenüber Fehlern hat negative
Auswirkungen in einer lernenden Organisation, daher muss sowohl in der Kultur als auch in den
Unternehmenszielen eine „Kultur des Experimentierens“ [Herb00, S. 34] verankert werden. Eine
solche Atmosphäre führt einerseits für den Mitarbeiter bei Begehen eines Fehlers nicht zu einem
SEITE 40 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
Statusverlust [DaPr98, S. 196], andererseits können die begangenen Fehler als Ausgangspunkt
für gezielte Verbesserungen sowohl am wissensbasierten Informationssystem selbst als auch an
der Prozessstrukturierung genutzt werden.
3.4 Messung und Bewertung von Wissen
Seit das Thema Wissensmanagement diskutiert wird, tritt immer wieder die Frage nach einer
geeigneten Methode für die Messung und Bewertung von Wissen zu Tage. Einige Autoren haben
bereits Ansätze unter verschiedenen Blickwinkeln erarbeitet, die jedoch alle noch keine umfas-
sende „Patentlösung“ darstellen. Dies ist umso erstaunlicher, als dass für jegliche Art von Pro-
jekten insbesondere in finanzwirtschaftlicher Sicht ausgefeilte Kennzahlensysteme vorhanden
sind. Eine Differenzierung von Aufwendungen, Auszahlungen oder Kosten ist problemlos mög-
lich, aber selbst der Unterschied zwischen Daten, Information und Wissen macht häufig noch
sprachlos [PRRo03, S. 13]. Im Rahmen eines Wissensmanagements kann nicht auf ein erprobtes
Instrument von Indikatoren und Messverfahren zurückgegriffen werden, sondern es bedarf viel-
mehr der Beschreitung neuer Wege [BuWP98, S. 33]. Nach einer anfänglichen Euphorie hat sich
die Bewertung von Projekten und strategischen Maßnahmen im Wissensmanagement zu einem
drängenden, aber weitgehend ungelösten Thema entwickelt [Gaed04, S. 10].
Wissen
Wissens-
management
Messen und
Bewerten von
Wissen
Lernende
Organisation
Steuerung durch
Rückkopplung der
Messergebnisse
Abhängigkeit der
Kernelemente untereinander
Quelle: Verfasser
Abbildung 21: Notwendigkeit der Messung und Bewertung von Wissen als Impulsgeber für die
Steuerung
Obwohl die Messung und Bewertung von Wissen ein schwieriges Feld darstellt, handelt es sich
dennoch um eine zentrale Fragestellung in jedem wissensorientierten Projekt. Eine intangible
Ressource wie Wissen ist nicht unbeschränkt steuerbar, so dass eine Kontrollillusion vermieden
werden muss [PRRo03, S. 57]. Das Lernen besteht aber auch in der Überprüfung, ob die einge-
leiteten Maßnahmen den gewünschten Erfolg gebracht haben [ScRe99, S. 82], wobei Kennzah-
len allein noch kein Wissen darstellen [ScRe99, S. 83]. Abbildung 21 zeigt die Notwendigkeit
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 41
der Messung und Bewertung von Wissen, da die Ergebnisse als Impulse für die Steuerung direkt
zu einer Ressource Wissen, zu dem gewählten Wissensmanagementansatz sowie zu den Überle-
gungen der lernenden Organisation widergespiegelt werden. Jedes Ergebnis aus der Messung
und Bewertung kann zu einer Nachjustierung der genannten Elemente genutzt werden.
Wichtig erscheint insbesondere die Feststellung, dass die Phase der Messung des Wissens die
Sichtbarmachung von Veränderungen der organisatorischen Wissensbasis beinhaltet und die
Phase der Bewertung auf die Beantwortung der Frage abzielt, ob die Wissensziele erreicht wor-
den sind [PRRo03, S. 213]. Die Bewertung darf nicht in einer monetären Dimension erfolgen, da
sich dieser Maßstab als völlig ungeeignet erwiesen hat.
3.4.1 Problemfeld Messung und Bewertung von Wissen
Das Messen und Bewerten wirft eine Vielzahl von Schwierigkeiten auf. Die Frage ist, „was man
misst“ oder besser „was man messen will“, um die Erreichung der Wissensziele zu überprüfen.
Skeptiker können diese Unschärfe nutzen, um zu betonen, dass die Maßnahmen des Wissensma-
nagements sinnlos sind, und ein Manager ist unsicher, weil er die Aktivitäten des Wissensmana-
gements nur auf der Kostenseite bemessen kann. In diesem Rahmen werden derzeit u.a. folgende
Problemfelder diskutiert [PRRo03, S. 216 ff.]:
• Wichtiges wird nicht gemessen,
• das Falsche wird gemessen,
• es wird mit dem falschen Maßstab gemessen,
• es wird gemessen, aber niemand weiß wofür.
Die Messung des „Wichtigen“ hat zur Voraussetzung, dass im Vorfeld überhaupt geeignete Ziele
formuliert werden, die anschließend verfolgt werden können. Zur Überwachung der als wichtig
identifizierten Faktoren müssen individuelle Monitoring-Systeme entwickelt werden, die die
Veränderungen im Zusammenhang mit dem Management von Wissen aufzeigen [PRRo03, S.
216]. Die Identifikation der Faktoren darf nicht dazu führen, dass diejenigen Größen aufgezeigt
werden, die leicht zu messen sind. Eine solche Vorgehensweise führt schnell zu der „Messung
des Falschen“. Ein weiterer häufiger Fehler ist die Konzentration auf Input-Größen, z.B. Ausbil-
dungsaufwand, mit einer Vernachlässigung des Outputs, etwa dem Ausbildungserfolg oder dem
Beitrag zum Geschäftserfolg [Nort02, S. 221]. Gerade solche Aspekte wie etwa der Erfolg einer
Ausbildung können nur mit qualitativen Aspekten sinnvoll gemessen werden. Meist werden in
der Praxis quantitative Messgrößen verwendet, da ein solcher Maßstab wesentlich einfacher zu
handhaben ist. Im Rahmen der Anwendung eines sinnvollen Maßstabes gilt es auch, einen hin-
reichend langen Zeithorizont anzulegen, da der Erfolg wissensorientierter Maßnahmen innerhalb
kurzfristiger Beurteilungszeiträume ohne Ergebnis bleiben kann [Nort02, S. 222].
Neben der Schwierigkeit geeignete Messgrößen und Maßstäbe zu finden, müssen auch die Be-
wertungsmethoden selbst einigen grundlegende Anforderungen entsprechen. Da das Wissen stets
an einen Wissensträger gebunden ist und nur in einem Kontext wertvoll ist, müssen diese Fakto-
ren von den Methoden berücksichtigt werden. Als Anforderungsmaßstäbe kommen ein geringer
Aufwand, valide und reproduzierbare Ergebnisse sowie eine einfache Verständlichkeit bzw.
Durchschaubarkeit für jeden Mitarbeiter in Betracht [WoFA05, S. 44].
SEITE 42 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
Weiterhin ist zu klären, welches Ziel mit der Messung und Bewertung des Wissens verfolgt
werden soll. Es können sowohl Ziele im Sinne einer „Buchhaltung“ von Wissensressourcen
verfolgt werden, als auch ein „Controlling“ in Form einer Zielverfolgung [NoPR98, S. 159],
beispielsweise für ein spezielles Projekt. Insbesondere letzteres Ziel ist für das Implementie-
rungsmodell wichtig, so dass gemäß obiger Ausführungen zunächst ein individuelles Messsys-
tem entwickelt werden muss.
3.4.2 Die Balanced Scorecard – Das Grundmodell von KAPLAN/NORTON
Zur Umsetzung der Messung und Bewertung von wissensintensiven Projekten wird vielfach die
Balanced Scorecard diskutiert. Das Konzept der Balanced Scorecard stellten KAPLAN/NORTON
[KaNo92] Anfang der 90er Jahre des letzten Jahrhunderts vor. Anlass war eine Reaktion auf eine
zuvor starke Fokussierung auf rein finanzielle Kennzahlen in den gängigen Steuerungs- und
Kontrollsystemen für das Management. Die klassischen Instrumente sind darüber hinaus rein
vergangenheitsorientiert [Fors00]. Die nichtfinanziellen Dimensionen gewinnen zunehmend an
Bedeutung und werden in der Balanced Scorecard in besonderem Maße berücksichtigt. Diese
Eigenschaft führt dazu, dass das Instrument für die nachhaltige Steuerung von Wissensmanage-
mentaktivitäten in Frage kommt, da eine rein monetäre Bewertung dem Wissensmanagementge-
danken nicht gerecht wird. Die Balanced Scorecard vermag die Lücke zwischen der Entwicklung
einer Strategie und deren operativer Umsetzung zu überbrücken [Gaed04, S. 10].
Finanzperspektive
Wie wird der finanzielle Erfolg
gesichert?
Kundenperspektive
Wie tritt das Unternehmen
gegenüber Kunden zur
Verwirklichung der eigenen
Vision auf?
Lern- und
Entwicklungsperspektive
Wie werden Potenziale zur
Verwirklichung der Vision
gefördert?
Prozessperspektive
Wie können die Kunden der
Prozesse befriedigt werden?
Vision
und
Strategie
Quelle: Verfasser nach [KaNo97, S. 9]
Abbildung 22: Vier Basisperspektiven einer Balanced Scorecard
In der ursprünglichen Intention ist die Balanced Scorecard nicht primär zur Messung und Be-
wertung von intellektuellem Kapital oder gar der Steuerung von Wissensmanagementaktivitäten
entwickelt worden, sondern vor allem zur Erweiterung der klassischen Sichtweise des Manage-
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 43
ments. Das Instrument vereint einerseits die Funktion eines Kennzahlensystems und andererseits
die eines Managementsystems zur Umsetzung von Strategien [Fors00]. Die ursprünglich von
KAPLAN/NORTON [KaNo97] angenommenen vier Perspektiven des Kennzahlensystems gemäß
Abbildung 22 werden als Basis für die weiteren Überlegungen gemäß den Ausführungen der
Autoren kurz erläutert.
Die Finanzperspektive ist eine im wesentlichen vergangenheitsorientierte Größe und hält die zu
erreichenden strategischen Ziele anhand von Kennzahlen wie beispielsweise einer Rendite fest.
Hiermit soll gezeigt werden, dass die Implementierung bzw. Ausführung einer zuvor geplanten
Aktion auch einen Niederschlag im Ergebnis des Unternehmens findet.
Der Fokus der Kundenperspektive liegt in der Außenwirkung des Unternehmens auf die Abneh-
mer der Güter oder Dienstleistungen. Es muss sich hierbei nicht zwangsweise um externe Perso-
nen handeln. Es können je nach Betrachtungsweise auch interne Sichten im Sinne von Kunden
eines Prozesse im eigenen Haus aufgebaut werden.
Die Prozessperspektive wird nach einer Zielformulierung für die Kundenperspektive erarbeitet.
Besonders wichtig sind die langfristig erfolgskritischen Prozesse einer Unternehmung. Es
empfiehlt sich der Aufbau einer vollständigen Wertschöpfungskette mit dem Ziel, über den
Abgleich mit den Kundenerwartungen sämtliche verbesserungsbedürftigen Prozesse offen zu
legen. Als besonders kritisch sind der Innovationsprozess, also die Umsetzung der Kundenwün-
sche in wettbewerbsfähige Produkte, und der Betriebsprozess, der die aktuellen Produkte und
Dienstleistungen erstellt und ausliefert, zu sehen.
Die Lern- und Entwicklungsperspektive schafft die zur Zielerreichung der drei anderen Perspek-
tiven notwendige Infrastruktur. Die ausgegebenen Ziele sind die treibenden Faktoren für heraus-
ragende Ergebnisse in den drei ersten Sichten. Es gilt in dieser Perspektive, die Potenziale der
drei Hauptkategorien Mitarbeiter, Informationssysteme und Motivation durch geeignete Zielset-
zungen zu aktivieren.
Die beschriebene Funktionsweise der Balanced Scorecard impliziert, dass es sich nicht um ein
starres und vorgefertigtes Instrument handelt. Vielmehr ist es für jedes Unternehmen und in
jedem Einsatzbereich individuell zu konfigurieren. Dies mag durch den zu treibenden Aufwand
zunächst als ein großer Nachteil erscheinen, bei näherem Hinsehen fällt aber auf, dass eine Re-
flexion der Ziele im Managementkreis erst zu einem einheitlichen Zielverständnis aller Beteilig-
ten führt [KaNo97, S. 11]. Mindestens ebenso wichtig ist die große Flexibilität des Instruments,
da selbst die vorgeschlagenen Perspektiven nicht zwangsweise bindend sind, um das Ziel der
Umsetzung einer Vision bzw. Strategie zu erreichen.
3.4.3 Die Balanced Scorecard – Anwendung im Wissensmanagement
Aufgrund der Vielfältigkeit des Instruments sind die vorgeschlagenen Perspektiven von
KAPLAN/NORTON [KaNo97] bereits in verschiedener Weise verändert worden und begründen die
Attraktivität des Modells. NOHR [Nohr01] hat sich mit der Thematik der Steuerung und Erfolgs-
messung von Wissensmanagement-Projekten mittels einer Balanced Scorecard beschäftigt. Der
Autor verlangt, dass die Balanced Scorecard konkret auf das jeweilige Wissensmanagement-
Modell eines Unternehmens angepasst wird [Nohr01, S. 21]. Seinem Beitrag legt er das prozess-
orientierte Genfer Modell des Wissensmanagements nach PROBST zu Grunde (vergleiche Kapitel
SEITE 44 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
3.1.3). Für die Wahl der Perspektiven werden die Bausteine der operativen Ebene herangezogen.
Allerdings entfällt die „Wissensidentifikation“, da dieser Prozess der Erstellung einer Balanced
Scorecard nicht unbedingt notwendig vorausgehen muss [Nohr01, S. 22]. Weiterhin fasst NOHR
den „Wissenserwerb“ und die „Wissensentwicklung“ zu der Perspektive des „Wissensaufbaus“
zusammen, so dass sich mit einer Finanzperspektive eine Balanced Scorecard gem. Abbildung
23 ergibt.
Finanz-
perspektive
Wissens-
aufbau
Wissens-
(ver)teilung
Wissens-
nutzung
Wissens-
bewahrung
: Kernperspektiven bei der Implementierung wissensbasierter Informationssysteme
Quelle: Verfasser nach [Nohr01, S. 22]
Abbildung 23: Vier Perspektiven einer wissensorientierten Balanced Scorecard nach NOHR
Für die vier genannten wissensorientierten Perspektiven schlägt NOHR [Nohr01, S. 23] jeweils
exemplarisch strategische Ziele sowie entsprechende Kennzahlen laut Abbildung 24 vor. Die
Ziele sollen im konkreten Fall aus den Unternehmenszielen abgeleitet werden und die Verbin-
dung zur Strategie des Unternehmens herstellen. NOHR bezeichnet die von ihm vorgestellten
Kennzahlen als noch nicht etabliert, so dass der Anwender die eigene Kreativität spielen lassen
kann, um geeignete Messgrößen zu definieren. Bei der Definition der Größen wird klar, ob die
Ziele zuvor eindeutig und klar definiert wurden, da sich sonst keine geeignete Messgrößen fin-
den lassen [Nohr01, S. 23].
ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG SEITE 45
AbdeckungsgradWissen erschließen und aufbereiten
QualitätsindexQualität der Wissensbasis erhöhenWissensbewahrung
Ausstattung der ArbeitsplätzeIntranet nutzen
Anschluss der Mitarbeiter an SystemeGroupware-Systeme nutzenWissens(ver)teilung
Umsetzung von Verbesserungs-
vorschlägen, Anzahl neuer Projekte
Innovationsfähigkeit der Mitarbeiter
steigern
Befragung der Mitarbeiter, Anzahl der
Zugriffe
Nutzungsmotivation steigern
Befragung der NutzerIntranets oder Datenbanken
benutzerfreundlich gestalten
Wissensnutzung
WissensportfolioSpezifisches Wissen aufbauen
Anzahl der ExpertenExperten anwerbenWissensaufbau
KennzahlenStrategische ZielePerspektive
Quelle: Auswahl aus [Nohr01, S. 23]
Abbildung 24: Ziele und Kennzahlen der Perspektiven einer Balanced Scorecard nach NOHR
Das Modell einer Balanced Scorecard für das Wissensmanagement von NOHR hat GAEDE
[Gaed04, S. 10ff.] zu einem Instrument zur Bewertung von konkreten Wissensmanagement-
Projekten weiter entwickelt. Da diese dem hier zu entwickelnden Implementierungsvorhaben
ähneln, wird dieser spezielle Ansatz als Basis für die Überlegungen zur Messung des Erfolgs der
Implementierung eines wissensbasierten Informationssystems hier vorgestellt.
Nach GAEDE [Gaed04, S. 10ff.] wird die Steuerung der Projekte ohne den Umweg über die
Wissensperspektiven vorgenommen, da mit den klassischen vier Perspektiven gearbeitet werden
kann. GAEDE definiert im Rahmen der Erstellung einer Balanced Scorecard bereits Ziele in den
einzelnen Perspektiven im Hinblick auf strategische Wissensmanagementmaßnahmen. Für diese
Ziele sind im Anschluss Kennzahlen zu suchen, die sich an den ausgegebenen Geschäftszielen
orientieren. Die Ableitung von konkreten Maßnahmen zur Zielerreichung führt schließlich auf
wissensintensive Projekte, deren Erfolg sich direkt anhand der zuvor aufgestellten Kennzahlen
nachweisen lässt.
Der von GAEDE vorgestellte Ansatz ist einerseits ein geeignetes Verfahren zur Messung von
Projekterfolgen und unterstützt andererseits eine Vorgehensweise, die bewährte Teillösungen
zuverlässig in einen Gesamtkontext zu migrieren vermag [Gaed04, S. 13]. Die Methode ist auch
dann anwendbar, wenn ein Unternehmen zuvor keine Balanced Scorecard besitzt, da durch die
Skalierbarkeit auch eine Nutzung für Teilbereiche sinnvoll ist. In jedem Fall wird ein Kompe-
tenzaufbau im Sinne einer festgelegten Gesamtstrategie unterstützt und der Aufwand ist eben-
falls begrenzt. Daher kann diese Herangehensweise zur Entwicklung einer Scorecard auch im
Implementierungsmodell Anwendung finden, um eine Implementierungs-Scorecard zu entwer-
fen.
SEITE 46 ANALYSERAHMEN DER WISSENSMANAGEMENTFORSCHUNG
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 47
4 Erkenntnisse aus den Verfahren zur Implementierung von Stan-
dardsoftware-Systemen
Vielleicht sind andere nicht so freimütig.
Ich jedenfalls habe immer rückhaltlos bekannt,
dass ich jederzeit ein Lernender war.
(Marcus Tullius Cicero)
Seit Anfang der 90er Jahre des letzten Jahrhunderts ist eine starke Ausweitung von Funktionali-
tät und Einsatzmöglichkeiten bei industrieller Standardsoftware zu beobachten [Gron01, S. 16].
Sie bietet gegenüber Individualentwicklungen für einzelne Unternehmen deutliche Vorteile, aber
auch den Nachteil, dass ein Anpassungsaufwand sowohl im Unternehmen, als auch bei der Stan-
dardsoftware selbst entsteht. Es kann sogar die Aussage getroffen werden, dass die Implementie-
rung einer Standardsoftware häufig von umfangreichen Reorganisationsmaßnahmen der betrieb-
lichen Organisation begleitet wird [Krcm03, S. 109]. Die Implementierung selbst ist dabei im
komplexen Ablauf einer Systemeinführung der letzte Schritt, dem gemäß Abbildung 25 einige
andere voraus gehen.
Festlegen des
Bereichs und
Planung
Entwicklung
einer
Vision
Design Aufbau Implemen-
tierung
Quelle: [Shie02, S. 44]
Abbildung 25: Die Implementierung im Gesamtkontext einer Standardsoftwareeinführung
In diesem Gesamtzusammenhang wurden für Standardsoftwaresysteme bereits Implementie-
rungsmodelle entwickelt und erfolgreich angewendet. In diesem Kapitel werden die Erkenntnisse
daraus aufbereitet, um sie weiter zu entwickeln und in das Implementierungsmodell eines wis-
sensbasierten Informationssystems einfließen zu lassen.
4.1 Standardsoftware vs. wissensbasiertes Informationssystem
Mit dem Begriff Standardsoftware wird im allgemeinen Sprachgebrauch eine große Gruppe
verschiedener Softwaretypen bezeichnet. Nach ÖSTERLE [Öste01, S. 435] werden unter einer
Standardsoftware Anwendungssysteme verstanden, die ohne Änderung in unterschiedlichen
Unternehmen einsetzbar sind. Als Beispiele können Betriebssysteme, Textverarbeitungssysteme,
Internet-Browser, Groupwaresysteme oder im betrieblichen Einsatz insbesondere auch umfas-
sende Planungs-, Dispositions- und Administrationssysteme gelten.
In einer engeren Abgrenzung verwenden einige Autoren auch den Begriff des Standardanwen-
dungssystems um eine Differenzierung zur Systemsoftware vorzunehmen [Barb96, S. 9]. Spe-
zielle Kennzeichen dieser standardisierten Anwendungssysteme können eine Branchenneutra-
SEITE 48 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
lität, eine Anpassungsfähigkeit über Customizing, eine Internationalität oder ihr Funktionsum-
fang sein [Gron01, S. 14]. Ein entscheidendes Kennzeichen ist eine große Zahl an gleichartigen
oder zumindest sehr ähnlichen Installationen.
Die Funktionalitäten der Softwaresysteme sind zwar durch den Aufbau der jeweiligen Software
generell auf bestimmte Einsatzbereiche beschränkt, allerdings sind mittlerweile Standardsoft-
waresysteme auf dem Markt zu finden, die annähernd einen kompletten betrieblichen Leistungs-
erstellungsprozess abdecken können. Dazu gehören in erster Linie die ERP-Systeme, die einen
großen Bereich der betrieblichen Prozesse abdecken. Daneben existieren eine Vielzahl von PPS-
Systemen, die eher bei repitetiven Produktionsformen eingesetzt werden. Eventuell nicht vorge-
sehene Aufgaben müssen mit gesonderten individuellen Erweiterungen oder aber mit einer ande-
ren Software abgedeckt werden [Gron01, S. 14]. Diese Fragen sind im Vorfeld einer Implemen-
tierung zu klären und müssen im Zusammenhang mit der Parametrierbarkeit betrachtet werden.
Diese bedeutet den Grad der Anpassungsfähigkeit an die Kundenanforderungen ohne eine Ver-
änderung des Quellcodes [Öste01, S. 435].
Es bestehen einige Parallelen zu wissensbasierten Informationssystemen, die die Betrachtung der
bereits entwickelten Implementierungsmodelle für Standardsoftware begründen. Es wird zwar
häufig von der „Einführung“ einer Standardsoftware gesprochen, jedoch ist der Begriff irrefüh-
rend, da es eher um die Reorganisation eines Betriebes unter Benutzung von Standardsoftware
geht [Öste01, S. 437]. Es steht mehr eine organisatorische Lösung im Vordergrund als das In-
formationssystem [Öste01, S. 437]. Der Aspekt der Einbindung in die Prozesse kommt auch bei
wissensbasierten Informationssystemen zum Tragen, wobei an Stelle der umfangreichen Reor-
ganisationsmaßnahmen die umfangreichen Wissensaspekte zu berücksichtigen sind. Zusätzlich
entsteht sowohl bei einer Standardsoftware als auch bei einem wissensbasierten Informations-
system ein spezifischer Anpassungsbedarf der Software auf die Kundenbedürfnisse. Dieser
Vorgang ist ähnlich einem „Customizing“, das einen großen Einfluss auf die Komplexität des
Einführungsvorhabens hat.
Aus der großen Gruppe der Standardanwendungssoftware wird für eine beispielhafte Betrach-
tung die Klasse der Enterprise Resource Planning - Systeme (ERP-Systeme) herausgegriffen.
Die Begründung liegt darin, dass diese Systeme in der Lage sind, die Geschäftsprozesse eines
Unternehmens sehr breit abdecken und somit parallel zu einem wissensbasierten Informations-
system nahezu alle Unternehmensbereiche tangieren.
Die Komplexität eines ERP-Systems und damit auch der große Aufwand bei seiner Einführung
stammt primär aus der Vielzahl der von einem ERP-System berührten Unternehmensbereiche.
Das Ziel liegt in einer möglichst umfassenden Unterstützung der betriebswirtschaftlichen Funk-
tionen in einem Unternehmen wie dem Vertrieb, der Beschaffung, der Materialwirtschaft, dem
Rechnungswesen, der Personalwirtschaft und der Produktion mit den Bereichen Produktionspla-
nung, Disposition und Produktionssteuerung [DoZl04, S. 85f.]. Auch aus dieser umfassenden
Sichtweise bietet sich die Analyse dieser Vorgehensweisen als Basis für die Implementierung
eines wissensbasierten Informationssystems an, da dort zwar das Softwaresystem selbst als
weniger komplex einzuschätzen ist, aber die Umsetzung der wissensintensiven Projektaufgaben
einen großen Anteil einnimmt.
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 49
4.2 Implementierung von Standardsoftware mit Hilfe eines Projekts
Die Implementierung eines komplexen Softwaresystems stellt eine in allen Belangen anspruchs-
volle Aufgabe dar [vArb97, S. 155]. Die Auswahl und vor allem die anschließende Einführung
einer umfassenden Standardsoftwarelösung werden in der Regel in der Form eines Projekts
durchgeführt [Gron01, S. 33] [Wahl03, S. 81]. Die Komplexität solcher Projekte ist sehr hoch
und kann bereits daran gemessen werden, dass die Implementierung eines ERP-Systems sehr
zeitaufwändig ist und je nach Unternehmens- oder Konzerngröße Monate oder Jahre in An-
spruch nimmt [DoZl04, S. 49]. Laut einer Studie der Meta Group ist im Durchschnitt etwa mit
einer Zeitdauer von 23 Monaten zu rechnen [Wahl03, S. 81].
Im Folgenden werden die Vorgehensweisen bei der Implementierung einer Standardsoftware
unter dem Gesichtspunkt der Durchführung mit einer Projektorganisation näher betrachtet. Als
besondere Schwierigkeit ist mit dem Auftreten von Zielkonflikten zwischen den Teilnehmern
des Projekts zu rechnen, da alle Beteiligten eine unterschiedliche Zielrichtung verfolgen. Die
Unternehmensleitung ist daran interessiert, mit der Einführung der Software die Rationalisie-
rungsmöglichkeiten voll auszuschöpfen, verkrustete Unternehmensstrukturen aufzubrechen und
das Paradigma der Ablauforganisation im Unternehmen zu verwirklichen. Fachabteilungen
wollen dagegen einen Verlust an Verantwortlichkeiten vermeiden. Der Betriebsrat hat ein Betei-
ligungsrecht und versucht, die Interessen der Arbeitnehmer zu wahren [Wahl03, S. 82]. Diese
Konfliktsituationen stehen auch bei der Implementierung von wissensbasierten Informations-
systemen in Aussicht, da eine ähnlich breite Streuung der betroffenen Unternehmensbereiche
und ihrer jeweiligen Interessen vorliegen kann.
Weiterhin wurden für allgemeine Softwareeinführungsprojekte bereits eine Reihe von Vorge-
hensmodellen entwickelt [DoZl04, S. 51]. Diese speziellen Modelle stellen vordefinierte Pro-
jektpläne zur Verfügung, die zum Teil auch von den Softwarehäusern angeboten werden, wie
etwa die „Implementation Roadmap“ als Referenzmodell eines großen deutschen Standardsoft-
wareherstellers [ApRi00, S. 77]. Diese Ansätze müssen auf eine Tauglichkeit für wissensbasierte
Systeme analysiert werden.
Die Basis zur Sicherstellung einer vollen Zielerreichung eines Einführungsprojektes ist die Er-
stellung einer Zieldefinition, nach der alle weiteren Planungen ausgerichtet werden können.
Diese Ziele sind mit allen Beteiligten abzustimmen und die Ergebnisse im Unternehmen zu
kommunizieren.
4.2.1 Grundlagen einer Projektorganisation im Implementierungskontext
Ein Projekt als solches ist in der DIN 69901 [DIN87, S. 1] definiert. Es ist ein Vorhaben, das im
wesentlichen durch die Einmaligkeit der Bedingungen in seiner Gesamtheit gekennzeichnet ist.
Dazu gehören eine Zielvorgabe, zeitliche, finanzielle, personelle oder andere Begrenzungen, eine
Abgrenzung gegenüber anderen Vorhaben und eine projektspezifische Organisation. In diesem
Zusammenhang ist auch eine Neuartigkeit der durchgeführten Aufgabe zu nennen, die neben den
anderen Kriterien in jedem Falle sowohl bei der Implementierung einer Standardsoftware als
auch bei einem wissensbasierten Informationssystem gegeben ist.
Bei Standardsoftwareprojekten ist regelmäßig eine Größe anzunehmen, die mit einer Vielzahl
beteiligter Personen und Teilaufgaben einhergeht. In einer engen Definition laut DIN 69901 wird
SEITE 50 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
unter der Projektorganisation die „Gesamtheit der Organisationseinheiten und der aufbau- und
ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projektes“ [DIN87, S. 3]
verstanden. STEINBUCH [Stei00, S. 25f.] fasst den Begriff weiter und sieht in der Aufgabe der
Projektorganisation die Organisation eines Projektes mit folgenden Teilbereichen:
• die Strukturierung und damit Verringerung der Komplexität,
• die Gliederung des Umfangs, damit dieser übersehbar und handhabbar wird,
• die Abstimmung unterschiedlicher Fachgebiete und
• die Sicherstellung der Zielerreichung im abgesteckten Zeitrahmen.
Für komplexe Implementierungsvorhaben scheint diese Fassung angebracht, da eine Besonder-
heit bei Standardsoftwareprojekten eine umfangreiche interdisziplinäre Zusammenarbeit zwi-
schen Fachleuten unterschiedlicher Gebiete ist, die eine von vornherein standardisierte Projekt-
organisation verhindern [Gron01, S. 33f.] und weit reichende Planungen verlangen. Zielände-
rungen während des Projektverlaufs sind üblicherweise nicht vorgesehen, da die Ziele dem
Projektmanagement von der Geschäftsleitung individuell und zwingend vorgegeben werden
[Stei00, S. 26]. Bei einem innovativen Projekt wie der Implementierung eines wissensbasierten
Informationssystems bestehen kaum Erfahrungswerte, so dass die Planungen nicht als endgültig
angesehen werden dürfen. Es erscheint eine Vorgehensweise mit der Möglichkeit von späteren
Anpassungen der Projektorganisation im fortschreitenden Projektverlauf sinnvoll.
Projektplanung
- Personalplanung
- Terminplanung
- Kostenplanung
- Sachmittelplanung
Projektdesign
- Einbindung in die
Aufbauorganisation
- Gestaltung des
Projektablaufs
- Stellung des
Projektmanagers
Projektvorgaben
- alle weiteren
projektrelevanten
Vorgaben wie bspw.
der Projektauftrag
Projekt-
organisation
Quelle: Verfasser nach [Stei00, S. 26f.]
Abbildung 26: Teilaufgaben der Projektorganisation
Als Teilaufgaben der Projektorganisation können im wesentlichen die Themen laut Abbildung
26 angesehen werden. Im Rahmen des Designs ist die Einbindung in die Aufbauorganisation des
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 51
Unternehmens eine wichtige Fragestellung. Es können mehrere Verfahren unterschieden werden
[HHMS04, S. 170ff.]:
• Stammorganisation: Die Projekte werden innerhalb der Stammorganisation, d.h. inner-
halb einer Abteilung durchgeführt. Vorteilhaft ist der geringe Aufwand, der Nachteil
ist darin zu sehen, dass das Projekt neben dem Tagesgeschäft erledigt werden muss und
dadurch häufig untergeht.
• Stabs-/ Einfluss-Projektorganisation: Der Projektleiter koordiniert die Teammitglieder,
die aus verschiedenen Abteilungen stammen können. Auch hier entsteht kein Eingriff
in die ursprüngliche Organisationsstruktur, was ähnliche Nachteile wie bei der Stamm-
organisation mitbringt. Eine zusätzliche Gefahr ist eine mangelnde Akzeptanz des
Projektleiters, was zu Lasten des Projekts gehen kann, da er über kein Weisungsrecht
verfügt. Zudem können die Abteilungsleiter dem Tagesgeschäft Vorrang vor dem Pro-
jekt geben.
• Matrix-Projektorganisation: In dieser Organisationsform erhält der Projektleiter im
Gegensatz zur Stabsorganisationsform auch die fachliche Führungsverantwortung. Die
Personalverantwortung bleibt weiterhin beim Abteilungsleiter, wodurch eine Matrix
entsteht. Der wesentliche Vorteil liegt in der Personifizierung der fachlichen Verant-
wortung mit dem Projektleiter. Allerdings steigt auch der Kommunikationsaufwand er-
heblich, so dass es sinnvoll ist, die Mitarbeiter in einem Projektraum zusammen zu fas-
sen. Dies bringt jedoch nur Sinn, wenn die Mitarbeiter nicht an mehreren Projekten pa-
rallel arbeiten müssen.
• Reine Projektorganisation: Hier werden die Mitarbeiter aus der bestehenden Organisa-
tion herausgelöst und in Projektteams einem Projektleiter fachlich und personell unter-
stellt. Die Ressourcen sind dadurch fest dem Projekt zugeordnet und tragen mit den
weit reichenden Kompetenzen des Projektleiters zu dem Projekterfolg bei. Der große
Nachteil dieser Projektform liegt zum einen in dem Aufwand für die Umorganisation
des Unternehmens begründet und zum anderen in möglichen Konflikten mit den Be-
reichsleitern, da ihnen Mitarbeiter entzogen werden. Zusätzlich müssen die Projekt-
teammitglieder am Ende des Projekts wieder in die Organisationsstruktur eingegliedert
werden können.
WELTI [Welt99, S. 21ff.] fordert bei der Auswahl der organisatorischen Projektstruktur eine
möglichst flache Hierarchie und kurze Kommunikationswege. Die Verantwortlichkeiten und
Aufgaben müssen eindeutig an die Teammitglieder verteilt sein. Zur Verkürzung der Wege
empfiehlt er eine direkte Einbindung des Topmanagements in einen Lenkungsausschuss, der bei
Bedarf direkt entscheiden kann.
Unabhängig von der gewählten Struktur wird im Rahmen der Implementierung von ERP-Syste-
men als ein wesentlicher Erfolgsfaktor allgemein die Freistellung kompetenter Mitarbeiter aus
Fachabteilungen gefordert. Diese Mitarbeiter sind auch dann mindestens anteilig vom Tagesge-
schäft freizustellen, wenn sie besonders in mittelständischen Unternehmen „unabkömmlich“
erscheinen [ApRi00, S. 79]. Die Projektorganisation und Teambildung bzw. Auswahl der
Teammitglieder sind als kritische Erfolgsfaktoren zu sehen [vArb97, S. 181] und entsprechend
sorgfältig durchzuführen.
SEITE 52 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
Bei Implementierungsvorhaben mit wissensintensiven Themen ist ein interdisziplinär aufge-
stelltes Projektteam zu empfehlen. Da eine möglichst große fachliche Breite erreicht werden soll,
ist ein Einsatz von Mitarbeitern in anteiliger Zeit anzustreben. Dadurch können viele Personen
eingebunden werden, die aber einer guten Kommunikationsstruktur bedürfen, damit an dieser
Stelle keine Ressourcen verschwendet werden. Eine Stabs- oder Matrix-Projektorganisation ist
für die Implementierung wissensbasierter Informationssysteme zu befürworten, da die fachliche
Verantwortung und Führung des Projekts bei einem Projektleiter gebunden ist, der von Mitar-
beitern aus vielen Abteilungen unterstützt wird. Dadurch ist das Projekt in vielen Köpfen in-
tegriert und zu erwarten, dass die Akzeptanz innerhalb des Unternehmens steigt.
Nach der Klärung des personellen und organisatorischen Aufbaus müssen die weiteren Schritte
wie die Gestaltung des Projektablaufs vorgenommen werden. Bei großen Projekten empfiehlt
sich eine Verringerung der Komplexität durch eine Strukturierung, die das Projekt in einzelne,
abgegrenzt bearbeitbare Aufgaben aufteilt [Gron01, S. 36].
Zu unterscheiden sind nach Abbildung 27 ablauforientierte- und objektorientierte Zerlegungsme-
chanismen. Regelmäßig wird zunächst eine objektorientierte Gliederung vorgenommen, deren
Ergebnis einzelne Teilprojekte sind. Diese können anschließend in der ablauforientierten Be-
trachtung in einzelne, zeitlich begrenzte Phasen zerlegt werden. Je nach Umfang können diese
noch einmal in einzelne Arbeitsschritte unterteilt werden. [Gron01, S. 36f.]
Teilprojekt 1
Teilprojekt 2
Teilprojekt 3
Projekt
Phase 1 Phase 3
Phase 2
Quelle: Verfasser nach [Gron01, S. 37]
Abbildung 27: Ablauf- und objektorientierte Projektstrukturierung
Die konkrete Gestaltung der Projektstruktur ist in jedem Projekt individuell zu erarbeiten. Es
kann aufgrund der stark divergierenden Projektumfänge und der unterschiedlichen eingeführten
Systeme nur der Rahmen abgesteckt werden. Die Strukturierung des Projekts für die Implemen-
tierung wissensbasierter Informationssysteme wird im nächsten Kapitel ausführlich dargestellt.
4.2.2 Projektplanung und -vorbereitung
Im Rahmen der Projektplanung sind für das Implementierungsmodell wichtige Schritte zu be-
achten. Der erste Teilaspekt ist der Projektauftrag. In ihm werden die Projektziele und die Be-
urteilungsgrößen zur Feststellung der Zielerreichung festgehalten. Damit ist er unabdingbare
Voraussetzung für die weiteren Planungsschritte. Er enthält Informationen zu dem notwendigen
Aufwand und dem angestrebten Nutzen sowie eventuellen Randbedingungen des Projekts
[Gron01, S. 67]. Zugleich wird die Projektorganisation im wesentlichen festgelegt und die Pro-
jektleitung benannt.
Die weiteren Planungsphasen sind Abbildung 28 zu entnehmen. Wichtig ist, dass die Schritte
nicht sequenziell, sondern iterativ ablaufen. Das Ergebnis der Planung wird im Anfangsstadium
des Projekts nicht endgültig sein, sondern bedarf während des Projektzeitraums einiger Anpas-
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 53
sungen. Im Sinne einer lebendigen Planung muss sie im Rahmen von Softwareprojekten ständig
aktualisiert, überarbeitet und weiter detailliert werden [HHMS04, S. 41]. Gerade bei innovativen
wissensbasierten Informationssystemen ist während der Projektlaufzeit mit neuen Fragestellun-
gen zu rechnen, die vor dem Projektstart nicht absehbar sind. Diese neuen Fragen dürfen aller-
dings nicht zu einem „Ausufern“ des Projekts führen.
Projektumfang und
Meilensteine festlegen
Projektstrukturen erstellen
Größen-, Aufwands- und
Kostenschätzung durchführen
Aktivitätenzeitplan erstellen
Kostenplanung aufstellen
Zusammenstellen des Projektplans
Quelle: [HHMS04, S. 41]
Abbildung 28: Übersicht Projektplanungsschritte
Der Projektumfang ist weitgehend durch den Projektauftrag mit den darin enthaltenen Zielen
vorgegeben. Wichtig ist die sinnvolle Strukturierung des Gesamtprojekts durch die Festlegung
von Meilensteinen. Zu ihnen werden bestimmte Ergebnisse zu einem zuvor festgelegten Termin
benannt, so dass sie als Abschlüsse einzelner Projektphasen zu sehen sind. Im Rahmen von
Standardsoftwareprojekten kommt beispielsweise die vollständige Analyse der Produktanforde-
rungen, die Fertigstellung eines Prototypen oder der erfolgreiche Abschluss einer Testphase in
Betracht [HHMS04, S. 43]. Diese Vorgehensweise bringt einerseits eine Motivation für das
Projektteam durch das Erreichen von Zwischenzielen, andererseits kann bei Abweichungen eine
Planungsanpassung nach realistischen Werten vorgenommen werden [Gron01, S. 70].
Laut DIN [DIN87, S. 1] legt die Projektstruktur die Gesamtheit der wesentlichen Beziehungen
zwischen den Elementen eines Projekts fest. Die Darstellung erfolgt in einem Projektstrukturplan
(vergleiche auch Abbildung 27), der das Gesamtprojekt in einzelne Arbeitsschritte splittet. Je
nach Umfang des Projekts können nach den Meilensteinen eine oder auch mehrere Gliederungs-
ebenen notwendig sein. Eine zu kleine Aufteilung der Arbeitsschritte sollte vermieden werden,
damit der Aufwand für das Controlling der Teilschritte nicht immens groß wird [HHMS04, S.
45]. Handelt es sich um ein großes Projekt, so kommt als Planungsinstrument die Netzplantech-
nik zum Einsatz, die speziell den für die Terminplanung kritischen Weg berücksichtigt. Im Rah-
men einer Standardsoftwareeinführung existieren von einigen Herstellern vordefinierte Projekt-
SEITE 54 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
pläne, die die zeitliche und logistische Abfolge der Aktivitäten vorgeben. APPELRATH/RITTER
[ApRi00, S. 85] zeigen die zur Verfügung gestellten Instrumente an einem Beispiel auf. Für
wissensbasierte Informationssysteme sind solche Vorgehensweisen noch nicht entwickelt, so
dass keine erprobten Projektpläne angewendet werden können.
Die Aufwands- und Kostenschätzung wird im Anschluss durchgeführt und kann als problema-
tisch bezeichnet werden [Gron01, S. 72]. Da die Abschätzungen in der Startphase entstehen, sind
sie meist sehr unsicher und können von Projektmitglied zu Projektmitglied um den Faktor zwei
oder mehr variieren [HHMS04, S. 47]. Für die Implementierung von Standardsoftware werden
auch hier vorgefertigte Budgetpläne angeboten, die Softwarelizenzen, Schulungskosten, Service-
kosten etc. bereits einbeziehen [ApRi00, S. 85f.]. Als Verfahren für die Schätzung wird häufig
eine Expertenschätzung eingesetzt, d.h. mehrere Experten führen eine Abschätzung durch, wo-
von der Mittelwert genommen wird. Alternativ ist eine Analogieschätzung auf der Basis von
Erfahrungen aus vorangegangenen Projekten möglich. Wie im Kapitel zu der Wissensmanage-
mentforschung herausgearbeitet, ist bei wissensintensiven Projekten eine Bewertung in der
monetären Dimension fragwürdig. Daher wird im folgenden Teil dieser Arbeit eine Vorgehens-
weise zur Messung und Bewertung des Projekterfolgs entwickelt.
Der Aktivitätenzeitplan wird unter der Berücksichtigung der terminlichen Ziele des Projekts
erstellt und beinhaltet die Ressourcenzuordnung sowie die zeitliche Feinplanung der Einzel-
schritte. Nach Durchführung der Planung steht für jedes Projektteammitglied fest, welche Arbeit
in welchem Zeitraum zu leisten ist und welche weiteren Ressourcen hierzu zur Verfügung ste-
hen. Bei Standardsoftwareprojekten werden externe Mitarbeiter für Aufgaben wie Customizing
und organisationsinterne Systemimplementierung eingesetzt, deren Einsatz es mit den Voraus-
setzungen im Unternehmen abzustimmen gilt.
Bei wissensbasierten Informationssystemen ist der Personaleinsatz im Aktivitätenzeitplan in
zwei Teile zu trennen. Für die technische Weiterentwicklung und Anpassung des Softwaresys-
tems empfiehlt sich der Einsatz externer Spezialisten, die das System bereits entwickelt haben
und mit dem entsprechenden Know-how kundenspezifisch weiter ausarbeiten. Die Neugestal-
tung der Wissensprozesse im Unternehmen sollte überwiegend mit internem Personal ausgear-
beitet werden, damit die Mitarbeiter die Möglichkeit bekommen, auch sich selbst wissensorien-
tiert weiter zu entwickeln. Wird diese Arbeit von unternehmensfremden und nur kurzzeitig
anwesenden Personen durchgeführt, besteht die Gefahr, dass die neuen Methoden nur unzurei-
chend in der Organisation verankert werden.
Die endgültige Kostenplanung beinhaltet die Zuordnung der geschätzten Kosten zu den einzel-
nen Aktivitäten. Hierbei ist darauf zu achten, grundsätzlich eine Kostenbetrachtung über den
gesamten Lebenszyklus der Standardsoftware durchzuführen, da Einsparungen von Entwick-
lungskosten häufig steigende Betriebskosten zur Folge haben, die die vorigen Ersparnisse über-
kompensieren können [HHMS04, S. 68]. Die Kostenplanung ist aufgrund fehlender Erfahrungs-
werte für die Implementierung eines wissensbasierten Informationssystems schwer abzuschät-
zen. Dieser Sachverhalt muss frühzeitig allen Beteiligten kommuniziert werden, um keine fal-
schen Erwartungen zu erzeugen.
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 55
4.2.3 Durchführung des Projekts
Nach dem Start eines Projekts ist ein stetiges Projektcontrolling notwendig. Die Überwachung
und Steuerung ist notwendig, damit die ausgegebenen Projektziele innerhalb des geplanten
Terminrahmens erreicht werden. Zweifelsohne ist eine Kontrolle der Leistung besonders bei den
Projekten eine schwierige Aufgabe, bei denen mit Software gearbeitet wird [Rinz98, S. 32]. Das
bedeutet, dass die im Termin- und Aktivitätenplan vereinbarten Inhalte unbedingt einzufordern
sind. Besonderes Augenmerk bei der Implementierung wissensbasierter Informationssysteme ist
auf die Realisierung der Wissensziele zu legen.
In der Phase der Durchführung ist ein stetiger Abgleich der Ist-Zustände mit den geplanten Soll-
Zuständen laut Projektplanung durchzuführen. Ebenso wichtig ist die Schaffung der Vorausset-
zungen eines Wissensmanagements: die Förderung der Kommunikation und des Informations-
austausches zwischen den Projektteammitgliedern. Hierfür empfehlen sich regelmäßige Projekt-
fortschrittsbesprechungen, die vom Projektmanagement sorgfältig zu planen sind, damit sie die
gewünschten Ergebnisse erreichen [HHMS04, S. 95ff.]. Bei Besprechungen ist der fachlich
qualifizierte Teilnehmerkreis anzusprechen, der zuvor Dokumente zur persönlichen Vorberei-
tung erhält.
Trotz der sorgfältigen Durchführung können bei Standardsoftwareprojekten viele Gründe zu
Terminverzögerungen führen [Gron01, S. 89]. Eventuelle Gegenmaßnahmen sind frühzeitig
einzuleiten. Die folgende Auswahl von Gründen kann auch auf Projekte zur Implementierung
wissensbasierter Informationssysteme zutreffen:
• Die Planung zu Beginn war zu optimistisch.
• Zusätzliche nicht im Projektplan aufgeführte Arbeiten werden erforderlich.
• Liefertermine von Fremdfirmen werden nicht eingehalten.
• Projektziele werden während der Projektlaufzeit vom Auftraggeber geändert oder erwei-
tert.
• Daten zur Bearbeitung des Projekts treffen nicht rechtzeitig ein.
Auch für die Überschreitung der geplanten Kosten kommen einige Gründe in Betracht, die
rechtzeitig zu erkennen und zu vermeiden sind: [Gron01, S. 89f.]
• Ein externer Anbieter hat ein Angebot unter dem Deckungsbeitrag abgegeben, um den
Auftrag zu erhalten.
• Das Aufholen von Terminverzögerungen kann zusätzliche Kosten verursachen.
• Technische Schwierigkeiten verursachen zusätzliche Kosten
• Die Kostenschätzung war aufgrund unrealistischer Mengenannahmen zu gering.
Standardsoftwareprojekte können aufgrund von vielen vorhandenen Erfahrungswerten in der
Regel gut geplant werden, so dass bei der Durchführung insbesondere bei Unterstützung durch
erfahrene Berater mit geringen Abweichungen von der Planung zu rechnen ist. Bei der Imple-
mentierung wissensbasierter Informationssysteme muss dagegen ein Bewusstsein für einen
gewissen Unsicherheitsfaktor in der Planung geschaffen werden. Nach mehrmaliger Anwendung
des hier aufgezeigten Implementierungsmodell ist mit einem sicheren Basiswissen für künftige
exakte Planungen zu kalkulieren.
SEITE 56 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
4.3 Vorgehensweisen zur Implementierung von Standardsoftware
Die Einführung einer Standardsoftware ist auch aus dem Grund äußerst komplex, da sie in der
Regel eine Vielzahl von Funktionen und eine große Menge von Anpassungsmöglichkeiten be-
sitzt. Zusätzlich ist der Funktionsumfang und der potenzielle Nutzen von Standardsoftware in
den vergangenen Jahren durch Internet-Protokolle, Web-Server, drahtlose Kommunikation,
tragbare Geräte oder grafische Benutzeroberflächen exponentiell angestiegen [Shie02, S. XIV].
Dies ist als ein wesentlicher Grund zu sehen, weshalb in den vorausgegangenen Jahren die
Mehrzahl aller Implementierungen aufgrund fehlender Schnittstellen und einer unzureichenden
Geschäftsprozessintegration Fehlschläge waren, die nicht die erwarteten Ergebnisse gebracht
haben [Shie02, S. XIVff.].
Die bereits entwickelten Projektskizzen und Erfahrungen werden im Folgenden als Basis für die
Implementierung eines wissensbasierten Informationssystems gebündelt dargestellt. Die Modelle
beziehen sich auf das ERP-System eines großen marktbeherrschenden Herstellers, da für diese
Software eine Reihe gut dokumentierter Vorgehensweisen vorliegen und zudem der Verbrei-
tungsgrad hoch ist, so dass von einem großen Erfahrungsschatz der Anwender der Implementie-
rungsmodelle ausgegangen werden kann.
4.3.1 Grundlegende Einführungsstrategien
Die Einführung einer Software kann gemäß Abbildung 29 auf mehrere Arten geschehen und
stellt zu Beginn des Projekts eine fundamentale Entscheidung dar [Welt99, S. 7]. Die erste Al-
ternative liegt in einer schlagartigen Einführung, „Big Bang“ genannt. Das bedeutet, dass alle
Module zu einem Zeitpunkt produktiv geschaltet werden. Die zweite Möglichkeit ist die stufen-
weise Einführung „step by step“, d.h. die neuen Softwaremodule werden nacheinander Zug um
Zug eingeführt. Wenn bereits ein Softwaresystem in Gebrauch ist, kann die neue Software auch
parallel zum alten System eingeführt werden, so dass beide Systeme eine gewisse Zeit nebenein-
ander arbeiten [Joch97, S. 57] [Welt99, S. 7ff.].
Altes System Neues System
t
Altes System
Neues System
Altes System Neues System
Schlagartige
Einführung
Stufenweise
Einführung
parallele
Einführung
Quelle: [Joch97, S. 59]
Abbildung 29: Einführungsstrategien für Standardsoftware
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 57
Diese Einführungsstrategien kommen besonders dann zum Tragen, wenn es sich um Software-
systeme mit mehreren Modulen handelt oder eine alte Vorgehensweise abgelöst werden soll. Die
schlagartige Einführung bringt den großen Vorteil mit sich, dass keine temporären Schnittstellen
zu einem eventuell genutzten Altsystem entstehen [Gron01, S. 155] [Welt99, S. 8] und keine
lange Wartezeit erforderlich ist, bis das neue System vollständig aufgebaut ist. Die entscheiden-
den Nachteile liegen darin, dass die Mitarbeiter aufgrund eines hohen Erfolgsdrucks enormen
Belastungen ausgesetzt sind und solche Großprojekte erhebliche Risiken bezüglich Terminen,
Kosten und Durchführbarkeit bergen [Joch97, S. 57f.]. Zusätzlich besteht die Gefahr, dass die
Geschäftsprozesse beeinträchtigt werden, da das neue System fehlerhaft ist und das Altsystem
nicht mehr zur Verfügung steht [Gron01, S. 155]. Eine solche Vorgehensweise der Einführung
ist nur mit massiver Unterstützung externer Partner realisierbar, was in der Kostenkalkulation
berücksichtigt werden muss [Welt99, S. 9]. Im Zuge der Implementierung wissensbasierter
Informationssysteme erscheint diese Möglichkeit eher ungünstig, da aus der Wissensperspektive
mit einem größeren Zeitbedarf für die Antizipierung der Veränderungen durch die Mitarbeiter zu
rechnen ist.
Die stufenweise Einführung besteht dagegen aus mehreren kleineren und überschaubaren Pro-
jekten. Sie belasten den betrieblichen Alltag weniger stark und die kleinen Projekte sind einfa-
cher zu steuern. Die Gesamtfunktionalität der neuen Software kommt jedoch erst spät zum Tra-
gen, wenn alle Teilmodule installiert sind [Welt99, S. 8]. Es besteht die Gefahr, dass die Anfor-
derungen der später einzuführenden Komponenten nicht rechtzeitig berücksichtigt werden, da
auf Sicht des Gesamtprojekts nicht genügend im Voraus geplant wird [Joch97, S. 57].
Die parallele Einführung ist eine sichere Variante, da auf jeden Fall ein funktionierendes System
zur Verfügung steht. Allerdings besteht hier die Gefahr von einem hohen Mehraufwand durch
die Bearbeitung von Vorgängen in beiden Systemen, wenn keine Schnittstellen für den Abgleich
existieren. Gleichzeitig kann diese Vorgehensweise durch die Verwendung zweier Softwarety-
pen Verwirrung bei den Mitarbeitern auslösen.
Beide vorherigen Varianten erscheinen für die Implementierung wissensbasierter Informations-
systeme besonders geeignet, da sie einen kontinuierlichen Veränderungsprozess erlauben. Prin-
zipiell sind sogar beliebige Mischformen der oben beschriebenen Vorgehensweisen denkbar
[Joch97, S. 58]. Die Entscheidung für eine der Varianten muss individuell in Abhängigkeit von
der Größe des Projekts und den Rahmenbedingungen im Unternehmen getroffen werden. Neben
der rein softwareorientierten funktionalen Betrachtungsweise können die oben beschriebenen
Überlegungen auch auf eine geschäftsprozessorientierte Sicht angewendet werden, indem die
Bearbeitung bestimmter oder aber auch aller Geschäftsprozesse auf das neue System migriert
wird.
4.3.2 Phasenkonzepte zur Systemeinführung
Für die Einführung von Standardsoftware haben bereits einige Autoren Konzepte und Phasen-
modelle entwickelt. Die Modelle sind für diesen Softwaretyp in Theorie und Praxis mittlerweile
„wie Sand am Meer“ zu finden [Joch97, S. 180]. Sie unterscheiden sich in der Gewichtung,
Ausgestaltung und Benennung einzelner Phasen, wobei die prinzipielle Vorgehensweise bei
allen ähnlich ist. Einige Vorschläge sind eher auf die technische Systementwicklung fokussiert,
während andere mehr die organisatorische Einbindung behandeln [Joch97, S. 181].
SEITE 58 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
Der in dieser Arbeit behandelte Teil der Implementierung wird dabei in den meisten Modellen
unscharf gefasst. Einige Autoren verstehen unter der Implementierung die auch hier vertretene
Auffassung der vollständigen Systemeinführung im Unternehmen, andere beschränken den
Implementierungsbegriff auf die programmtechnische Umsetzung der ermittelten Systemanfor-
derungen. JOCHEM [Joch97, S. 213ff.] entwickelt ein Phasenkonzept für die Standardsoftwareein-
führung, das sich weniger auf die technische Realisierung der Software, sondern mehr auf ein
umfassendes organisatorisches Vorgehen bezieht. Das Konzept berücksichtigt neben der reinen
Einführung auch die Unterstützung in der ersten Betriebsphase der Software. Die vorgestellten
Phasen können als richtungsweisend für die Entwicklung eines Einführungskonzepts für wis-
sensbasierte Informationssysteme gelten und werden hier als Basis für eine Weiterentwicklung
angeführt. Eine ähnlich umfassende Vorgehensweise mit einer Berücksichtigung der Produktiv-
phase nach dem Systemstart findet sich bei WELTI [Welt99].
JOCHEM [Joch97] teilt das Gesamtprojekt gemäß Abbildung 30 in insgesamt sieben Phasen auf.
Das Projekt beginnt in der ersten Phase mit der Projektvorbereitung und endet in Phase sieben
mit der Stabilisierung nach der Inbetriebnahme. Diese Basisüberlegungen sind auch bei der
Implementierung von wissensbasierten Informationssystemen durchzuführen.
Phase 1
Projektvorbereitung
Phase 2
Systemplanung
Phase 3
Prototyping
Phase 4
Realisierung
Phase 5
Systemtest
Phase 6
Produktionsvorbereitung
Phase 7
Stabilisierung
• Projektorganisation erstellen und einbinden
• Istaufnahme und Schwachstellenanalyse
• Erarbeitung des Sollkonzepts
• Einarbeitung des Projektteams
• Abbildung der Unternehmensstruktur
• Test des Standardsystems
• Repräsentative Geschäftsvorfälle auswählen
• Gestaltung der Geschäftsvorfälle diskutieren
• Eigenentwicklungen testen
• Festlegungen aus dem Prototyping umsetzen
• Benutzerdokumentation erstellen
• Qualitätssicherung beachten
• Detaillierte Planung des Systemtests
• Durchführung des Systemtests
• Testergebnisse dokumentieren und auswerten
• Installation aller Hard- und Softwarekomponenten
• Schulung der künftigen Anwender
• Durchführung der Datenübernahme
• Organisatorische und technische Systemoptimierung
• Änderungswünsche dokumentieren
• Wartungshandbuch erstellen und Systemübergabe
Quelle: Verfasser nach [Joch97, S. 213ff.]
Abbildung 30: Phasenmodell einer Standardsoftwareeinführung nach JOCHEM
Die Phase der Projektvorbereitung hat zum Ziel, die Voraussetzungen für eine erfolgreiche
Projektdurchführung zu schaffen. Dies beginnt mit der Auswahl eines Projektleiters und der
Projektteammitglieder. Dabei sind schon die von der Softwareeinführung betroffenen Organisa-
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 59
tionseinheiten zu berücksichtigen, da diese neben der Datenverarbeitungsabteilung in jedem Fall
einen Vertreter in das Projektteam entsenden sollten. Ein wichtiger Punkt in dieser Phase ist die
Durchführung einer sorgfältigen Istaufnahme und Schwachstellenanalyse durch Befragung der
betroffenen Bereiche. Daraus ist ein Sollkonzept zu erstellen, das zum einen die Schnittstellen zu
vor- und nachgelagerten Anwendungen festlegt und zum anderen die einzusetzenden Funktionen
der Standardsoftware definiert. Je nach betroffenen Bereichen ist darauf zu achten, den Betriebs-
rat an den Planungen zu beteiligen.
Mit der anschließenden Systemplanungsphase erfolgt der eigentliche Projektstart. Hierzu wird
ein Kickoff-Meeting veranstaltet, das allen Mitarbeitern den gleichen Informationsstand über das
Projekt verschafft und über die Ziele, Termine und verfügbaren Mittel informiert. Die eigent-
liche Projektarbeit wird nach der Formierung des Projektteams organisiert. Dies beinhaltet die
Festlegung von Abläufen und Zuständigkeiten beispielsweise für die Berichterstattung, Be-
sprechungs- und Abstimmungstermine oder Genehmigungsverfahren für Modifikationen. Paral-
lel ist für eine ausreichende Ausbildung des Projektteams zu sorgen, die durch interne und ex-
terne Schulungen ergänzt werden kann. Auf der technischen Seite ist eine erste Systeminstalla-
tion für das Prototyping notwendig. In dieser Arbeitsumgebung können mit Musterdaten erste
Tests durchgeführt werden. Als Testpersonen kommen vor allem die Mitglieder des Projekt-
teams in Frage. Im Idealfall decken sie bereits das Anwenderspektrum aus allen Bereichen des
Unternehmens ab und ihre Benutzerprofile entsprechen bereits denen der späteren Nutzer im
realen Betrieb. Wesentlich ist die korrekte Abbildung der Unternehmensstruktur auf Basis der
Istaufnahme bzw. des Sollkonzepts.
Mit der Phase des Prototyping wird das Ziel verfolgt, die unternehmensneutral ausgelieferten
Funktionen einer Standardsoftware auf die Bedürfnisse des Unternehmens anzupassen. Hierzu
werden repräsentative Geschäftsvorfälle ausgesucht und die Gestaltungsmöglichkeiten im An-
schluss diskutiert. Erweisen sich die Funktionen nach ersten Tests als sinnvoll und machbar, so
werden sie festgehalten und in einer Zusammenfassung den Fachabteilungen vorgestellt. Es ist
ein Konsens über die Funktionen durch die permanente Abstimmung aller Bereiche zu erzielen.
In dieser Phase ist ebenfalls der Bedarf an Berichten und Formularen zu ermitteln, die die Soft-
wareanwendung den Nutzern liefern soll. Ihre individuelle Ausgestaltung ist detailliert zu defi-
nieren. Diese Eigenentwicklungen müssen besonders intensiv betrachtet werden, da sie im Ge-
gensatz zu den Standardkomponenten noch nie verwendet wurden und die Gefahr von Fehlern
sehr hoch ist.
Die Realisierungsphase beginnt, wenn der erstellte Prototyp des künftigen Systems abgenommen
ist. Hier kann es Überlappungen oder Rücksprünge zwischen beiden Phasen geben, wenn sich
Teile der Festlegungen als ungünstig erweisen oder für einige Module das Prototyping abge-
schlossen ist und für andere nicht. Wichtig ist in dieser Phase die Erstellung einer Benutzerdo-
kumentation, die die Arbeits- und Funktionsabläufe darstellen muss und dabei als Überprüfung
der gedachten Abläufe, Verantwortlichkeiten und Kompetenzen zu sehen ist. Am Ende der Phase
ist eine Qualitätssicherung durch Prüfung der Arbeiten auf Vollständigkeit anhand einer Check-
liste zu durchlaufen.
Der Systemtest betrifft nun erstmals das System in seiner Gesamtheit und nicht nur die Einzel-
komponenten. Ziel ist die Sicherstellung eines fehlerfreien Gesamtsystems. Dazu ist eine detail-
lierte Planung sowie eine sorgfältige Durchführung und Dokumentation erforderlich. Der Test
SEITE 60 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
soll möglichst sämtliche Fehler in der Hard- und Software aufdecken, die im Anschluss noch vor
dem Produktivstart behoben werden können.
Die Produktionsvorbereitung kann teilweise parallel zu den Systemtests durchgeführt werden, da
hier sämtliche Voraussetzungen für die spätere Nutzung geschaffen werden. Dies betrifft vor
allem die vollständige Installation von Hard- und Software sowie die Schulung der späteren
Anwender. Möglicherweise sind auch Daten von einem Altsystem in das neue System zu über-
nehmen. Am Ende der Phase ist im Rahmen einer Qualitätssicherung mit einer Checkliste zu
prüfen, ob alle notwendigen Voraussetzungen für die Aufnahme des Produktivbetriebs erfüllt
sind. Ist dies erfolgreich, so kann das System gestartet werden.
Die Stabilisierungsphase beschäftigt sich nach dem Systemstart mit der Aufnahme von Ände-
rungswünschen sowie der technischen und organisatorischen Systemoptimierung. Es geht vor
allem um das Abarbeiten von „Anlaufschwierigkeiten“, die aus den vielfältigsten Gründen auf-
treten können und nicht vollständig zu vermeiden sind. Im Abschluss wird das System vom
Projektteam den zuständigen Fachabteilungen übergeben.
Definition der
Geschäfts-
prozesse
Definition des
möglichen
Standardsoft-
wareeinsatzes
Einführungs-
strategie
erarbeiten
Organisations-
maßnahmen
vorbereiten und
durchführen
DV-Maßnahmen
vorbereiten und
durchführen
Produktivstart
durchführen
Optimierung der
Geschäfts-
prozesse im
Produktivbetrieb
Zielerreichung
prüfen und ggf.
Anpassungen
vornehmen
Anpassungen sind in der Software,
aber auch im Konzept der
Geschäftsprozesse möglich.
Auf Basis einer Istanalyse wird ein Ziel-
system erarbeitet, für das der Einsatz einer
Standardsoftware geprüft wird.
Sind die Tests erfolgreich verlaufen, kann der
Produktivstart vorgenommen werden.
Hierzu gehört auch die Festlegung von
Terminen und die Konzeptdetaillierung.
Quelle: Verfasser nach [Kirc96]
Abbildung 31: Geschäftsprozessorientierte Einführung einer Standardsoftware nach KIRCHMER
Neben der am Projektmanagement orientierten Herangehensweise liefert KIRCHMER [Kirc96] in
seinem geschäftsprozessorientierten Modell der Einführung von Standardsoftware einen weite-
ren wichtigen Ansatz. Der Autor legt in seiner Vorgehensweise sehr großen Wert auf eine sorg-
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 61
fältige Analyse der Geschäftsprozesse und die Entwicklung eines Sollkonzepts, das anschließend
mit Hilfe einer Standardsoftware realisiert wird. Dieser Teilaspekt ist besonders wichtig, da die
Orientierung an den Ansätzen des Wissensmanagements eine Prozessorientierung auch für die
Implementierung wissensbasierter Informationssysteme erwarten lässt.
Die prinzipielle Vorgehensweise von KIRCHMER lässt sich Abbildung 31 entnehmen. Sie zeigt,
wie die Prozesse und die Software in mehreren Schritten aufeinander abgestimmt werden. Aus-
gangspunkt ist eine Ist-Analyse der Prozesse, die als Basis für die Auswahl und den Einsatz einer
Standardsoftware dient. Typisch für das Modell ist die spätere Optimierung der Geschäfts-
prozesse im Produktivbetrieb zu den Eigenschaften des Standardsoftwaresystems hin.
4.4 Customizing und Business Process Reengineering
Im Zusammenhang mit der Implementierung einer Standardsoftware werden regelmäßig die
Methoden des „Customizing“ und des „Business Process Reengineering“ verwendet. Die Vorge-
hensweisen werden im Folgenden auf ihre Anwendbarkeit für die Implementierung eines wis-
sensbasierten Informationssystems näher untersucht.
4.4.1 Customizing einer Standardsoftware
Mit „Customizing“ wird die Anpassung einer Standardsoftware an die unternehmensindividuel-
len Bedürfnisse bezeichnet [StHa05, S. 297]. Die Notwendigkeit ergibt sich dadurch, dass eine
Standardsoftware im Gegensatz zu einer Individualsoftware für die Lösung eines branchenüber-
greifenden, abstrakten Anwendungsfalls konzipiert wird [StHa05, S. 297]. Als grundlegende
Möglichkeiten der Anpassung kommt die Parametrisierung und die Konfigurierung in Betracht.
Mittels der Parametrisierung lassen sich das Verhalten einer Standardsoftware und die Ergeb-
nisse von Benutzeraktionen beeinflussen. Die Konfigurierung dient der Anpassung des Umfangs
und des Aussehens der Oberfläche.
Die Individualprogrammierung einzelner Zusatzanwendungen zur Anpassung an Kundenwün-
sche ist eine ebenso denkbare Lösung. Sie wird aufgrund des großen Aufwands selten durchge-
führt und bringt neben den daraus resultierenden Kosten auch noch weitere Nachteile mit sich,
wie beispielsweise das Risiko einer Unvereinbarkeit der individuell programmierten Softwarebe-
standteile mit neuen Releases. Dies kann weitere aufwändige Pflegemaßnahmen bei jedem
Releasewechsel nach sich ziehen.
Die Aktivitäten eines Customizing umfassen weite Teilbereiche der Software. Die folgenden
Merkmale werden beeinflusst [Görk01, S. 127]:
• Organisatorische Parameter, wie beispielsweise die Produktionsstätten eines Unterneh-
mens,
• Verfahrens- oder Prozessparameter, die den Prozessablauf beeinflussen,
• beschreibende Parameter wie Texte,
• Anpassung von Menüs und Bildern,
• Gestaltung von Reports und Formularen,
• Datenübernahme aus einem Vorsystem,
SEITE 62 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
• Steuerung der Systemzugriffsberechtigungen,
• Programmerweiterungen.
Einige Erfahrungsberichte belegen unabhängig vom Hersteller der Standardsoftware die enorme
Bedeutung des Customizing für den Erfolg der Implementierung [NiRe05, S. 82]. Gleichzeitig
entsteht dadurch neben den reinen Softwarelizenzkosten ein erheblicher Teil der Gesamtkosten
bei der Softwareeinführung [NiRe05, S. 80]. Es steht fest, dass mit einem steigenden Customi-
zing-Bedarf grundsätzlich von einem erhöhten Ressourcenbedarf ausgegangen werden kann
[NiRe05, S. 82]. Die Anpassungsmaßnahmen machen auch einen Teil der Vorteile einer Stan-
dardsoftware wie die uneingeschränkte Kompatibilität mit Folgeversionen wieder zunichte und
erfordern aufgrund ihrer Komplexität regelmäßig den Einsatz externer Experten, deren Wissen
meist nicht im Unternehmen gehalten werden kann.
Als Lösungsansatz bietet sich die Beschränkung des Customizing auf strategisch wichtige Be-
reiche an. Dadurch können die Vorteile der Standardsoftware weitgehend erhalten werden und
die Kosten können ebenfalls im Rahmen gehalten werden. Allerdings hat diese Vorgehensweise
zwei wesentliche Voraussetzungen. Erstens müssen sich die strategisch wichtigen Kernprozesse
mittels Parametrisierung in der Software abbilden lassen und zweitens müssen die weiteren
Prozesse so weit anpassbar sein, dass sie mit der gewählten Standardsoftware abgedeckt werden
können. [NiRe05, S. 84]
Zur Vereinfachung und Beschleunigung des Customizing werden zunehmend Lösungen ent-
wickelt, die beispielsweise branchenspezifische Voreinstellungen anbieten oder aber die Art und
Größe des Unternehmens bereits in Form einer vorgefertigten Konfiguration abbilden. Dennoch
kann die Softwareanpassung nur so gut sein wie die Anforderungsanalyse, die zuvor durchge-
führt wurde.
Das bedeutet, die Vorarbeiten zur Implementierung eines wissensbasierten Informationssystems
müssen sorgfältig durchgeführt werden. Der Aufwand für eine Softwareanpassung muss in
geringem Rahmen gehalten werden, indem eine passende Software vom Markt gewählt wird und
möglichst wenige Parameter verändert werden müssen. Gleichzeitig ist darauf zu achten, dass
dennoch eine große Flexibilität erhalten bleibt und die Kompatibilität zu anderen DV-Systemen
gegeben ist.
4.4.2 Business Process Reengineering – Eine Voraussetzung?
Das Business Process Reengineering kommt immer dann zum Tragen, wenn eine Anpassung der
Standardsoftware auf die individuelle Prozesslandschaft des Unternehmens als zu aufwändig
erscheint, oder eine Neustrukturierung nach den Vorgaben einer Standardsoftware gewünscht
wird. Das Konzept geht zurück auf eine Arbeit von HAMMER/CHAMPY [HaCh96] und meint das
vollständige Überdenken sowie die anschließende Neugestaltung der Prozessabläufe. Die Infor-
mationstechnologie spielt dabei eine tragende Rolle, indem sie es dem Unternehmen ermöglicht,
die Prozesse neu zu gestalten [HaCh96, S. 112].
Es werden verschiedene Meinungen über das Business Process Reenigineering im Zusammen-
hang mit der Einführung von Standardsoftware diskutiert. SHIELDS [Shie02, S. 203ff.] geht
davon aus, dass ein Reengineering der Prozesse zumindest bei einer schnellen Einführung nicht
durchgeführt werden darf. Das Konzept sei nicht in Einklang zu bringen mit der Idee, eine Stan-
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 63
dardsoftware möglichst ohne Modifikationen zur Unterstützung von Geschäftsprozessen einzu-
setzen. Für das Reengineering ist eine völlig offene Designbasis für radikale und tief greifende
Veränderungen notwendig. Ebenso wird häufig vergessen, dass die Mitarbeiter nicht unbedingt
über die Fähigkeiten verfügen, die neu gestalteten Prozesse durchzuführen. Die Umstrukturie-
rung und Erweiterung der Aufgabenbereiche hat zur Folge, dass entweder ein Austausch oder
aber zumindest eine Ergänzung der Qualifikationen und Kenntnisse der Beschäftigten erforder-
lich wird. Nicht zuletzt sieht SHIELDS durch den großen Zeitbedarf auch die Verbindung der
Prozessveränderungen mit der Implementierung der Software als problematisch an, da in einem
hochdynamischen Geschäftsumfeld die Prozesse erst definiert und dann in der Software umge-
setzt werden müssen. Bis dahin sind sie häufig schon wieder veraltet. Daher schlägt der Autor
viele kleine aufeinanderfolgende Projekte vor, die zu einer kontinuierlichen Prozessverbesserung
führen.
Einen anderen Ansatz verfolgt WELTI [Welt99, S. 91ff.]. Er empfiehlt die Durchführung eines
Reengineering Projekts nach der erfolgreichen Realisierung des Implementierungsprojekts.
Diese Vorgehensweise wird wie folgt begründet:
• Zur Durchführung eines Business Reengineering Projekts sind gute Kenntnisse der
Standardsoftware notwendig, um die Funktionen und Potenziale voll auszuschöpfen.
Dies ist erst nach der Implementierung gegeben.
• Ein gleichzeitiges Implementierungs- und Reengineering-Projekt übersteigt die
Aufnahmekapazität der meisten Mitarbeiter.
• Die Komplexität des Reengineering-Projekts wird verringert, da die Organisation und
Prozesse von der bereits bestehenden Standardsoftware bestimmt werden.
• Nach dem Implementierungsprojekt sind mehr Mitarbeiter mit dem notwendigen Wis-
sen über Prozesse verfügbar.
BARBITSCH [Barb96, S. 17ff.] verwendet in seinem Ansatz den Begriff des „Business Process
Redesign“ und unterstreicht damit, dass nicht nur qualitative Verbesserungen erzielt werden
sollen, sondern neben der Überarbeitung der bisherigen Prozesse auch ihre vollständige funktio-
nale Neudefinition ermöglicht werden soll. Der Autor geht davon aus, dass dem Ansatz des
Business Process Redesign bei einer Einführung zusammen mit einer Standardsoftware etwas
von seiner Radikalität genommen wird, aber trotzdem eine Kombination sinnvoll ist. Die Vorge-
hensweise soll die jeweils spezifischen Eigenschaften beider Komponenten in jedem Projekt
angemessen berücksichtigen.
4.4.3 Anwendung des Customizing und Business Process Reengineering
Wie die Ausführungen zeigen, ergibt sich ein Spannungsfeld zwischen dem Customizing einer-
seits und dem Business Process Reengineering andererseits. Softwareanpassungen über ein
Customizing sind bis zu einem gewissen Grad möglich und sinnvoll, ab einem individuell fest-
zulegenden Grad ist es aber unumgänglich, eine Angleichung der Prozesse vorzunehmen. Auf
diese Weise können die Vorteile einer standardisierten Software erhalten werden und die Kosten
der Einführung bleiben im Rahmen.
Im Ergebnis kann für die Implementierung einer Standardsoftware keine Pauschalaussage getrof-
fen werden, welchen Anteil die Customizing- und Reengineering-Aktivitäten für ein erfolgrei-
SEITE 64 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
ches Einführungsprojekt haben müssen. Vielmehr ist eine individuelle Abstimmung der Aktivi-
täten in Abhängigkeit des vorgefundenen Umfelds erforderlich. Eine extrem wichtige Vorausset-
zung ist in jedem Fall die sorgfältige Analyse des Umfelds, das den Einsatzbereich der Standard-
software bilden soll.
Die Analyse der Ansätze des Customizing und des Business Process Reengineering zeigt, dass
im Zusammenhang mit der Entwicklung eines Implementierungsmodells für wissensbasierte
Informationssysteme ein wichtiger Teilbereich die Berücksichtigung der Anpassbarkeit des
Softwaresystems sowie die Untersuchung und Analyse der Geschäftsprozesse ist. Im Bereich der
Prozesse gilt es, die Verbindung zu den Ansätzen des Wissensmanagements herzustellen und
gleichzeitig die Unterstützung durch das Softwaresystem zu ermöglichen. Ein vollständiges
Business Process Reengineering läuft den Grundannahmen eines Wissensmanagements mit
kontinuierlichen Anpassungen und konsequenter Weiterentwicklung in jedem Fall zuwider. Es
sind vielmehr Parallelen zu dem Ansatz von WELTI zu erkennen, da eine Neu- oder Umgestal-
tung der Prozesse nach erfolgter Softwareeinführung vorgenommen wird.
4.5 Change Management in Standardsoftwareprojekten
Das „Change Management“ oder Veränderungsmanagement bildet eine wichtige Größe in Pro-
jekten zur Einführung von Standardsoftware. Die Veränderungen wirken sich in allen Bereichen
des Unternehmens aus, wie etwa der Unternehmenskultur und –struktur, dem Arbeitsablauf, den
Verantwortungsbereichen der Beschäftigten, der Mitarbeitermotivation, den Kommunikations-
wegen, den Richtlinien und Verfahren oder aber in dem Einsatz neuartiger Technologien
[Shie02, S. 192]. Da es sich bei einem Unternehmen um ein sensibles soziales System handelt,
müssen diese Veränderungen gezielt gesteuert werden. Die Notwendigkeit der Steuerung rührt
daher, dass das Wesen des Menschen jede Veränderung mit Zweifeln und Unwägbarkeiten
verbindet. Die Reaktion darauf äußert sich häufig in offenem oder verborgenem Widerstand
[Shie02, S. 193], der zu vermeiden ist.
Der Begriff des Change Management wird in einer großen inhaltlichen Spannbreite verwendet
und reicht von „allgemeiner Veränderung“ über „Coaching“ bis zu „Beraten und Verkaufen“
[NjKo02, S. 219ff.]. Meist findet die Verwendung im Zusammenhang mit Implementierungs-,
Innovations- oder Veränderungsprojekten statt. Dominiert wird die derzeitige Diskussion von
Praxiserfahrungen und weniger von theoretischen Hintergründen [NjKo02, S. 219ff.]. Die
zentralen Bausteine des Change Managements sind teilweise ähnlich mit denen, die für Ziel-
vereinbarungssysteme oder Balanced Scorecard Konzepte verwendet werden [Bung05, S. 28].
Daher ist in dieser Arbeit die Einbettung sowohl in die Frage der Begleitung der Veränderungen
durch die Implementierung, aber auch in der Erfolgsmessung gegeben.
Hier wird im Zusammenhang mit der Implementierung wissensbasierter Informationssysteme die
Auffassung des Change Management von KOHNKE [Kohn05, S. 52ff.] als Basis herangezogen.
Der Autor bezieht das Change Management in erster Linie auf die Menschen im Unternehmen,
während er den rein sachbezogenen Aspekt durch das Projektmanagement abgedeckt sieht. Das
Change Management adressiert den Prozess der Veränderung von der Initiierung bis hin zu einer
abschließenden Evaluation, wobei es nicht Aufgabe des Change Managements ist, Aussagen zu
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 65
den möglichen Inhalten zu machen. Diese werden bereits in der Zieldefinition der Standardsoft-
wareimplementierung festgelegt. Eine Veranschaulichung dazu zeigt Abbildung 32.
Management-
konzepte zeigen
das Ziel
Change Management zeigt den Weg
Prozessebene
Wie?
Inhaltsebene
Was?
Quelle: [Kohn05, S. 53]
Abbildung 32: Das Change Management als Prozess nach KOHNKE
4.5.1 Phasenmodell der Veränderung und seine Akteurs- und Handlungsebenen
Die bisher in Kapitel 4.3 aufgezeigten Vorgehensweisen zur Einführung einer Standardsoftware
wird der Veränderungsprozess regelmäßig so gestaltet, dass die neue Software als Standard
gesetzt wird und die Nutzer nur in geringem Umfang die Möglichkeit haben, die Veränderung
hin zum neue Standard mitzugestalten. Für wissensintensive Prozesse ist die aktive Beteiligung
der Mitarbeiter an der Veränderung jedoch eine wesentliche Voraussetzung. Diesen Verände-
rungsprozess unter Einbeziehung der Mitarbeiter beschreiben BRETTEL ET AL. [BrRP05, S. 88ff.]
und STREICH [Stre97, S. 237ff.]. Ein gegenwärtiger Zustand A geht in einen angestrebten Zu-
stand B in drei Phasen über. Die bereits in Abbildung 32 gezeigte Auffassung der Veränderung
als Prozess, ist laut BRETTEL ET AL. [BrRP05, S. 88ff.] gemäß Abbildung 33 in die Phasen
„unfreeze“, „move“ und „refreeze“ zu unterscheiden. Das Phasenmodell erweitert die bisher in
den Implementierungsmodellen vorgenommenen Betrachtungen durch das „Hineinwachsen“ in
einen neuen Zustand mit anschließender Konsolidierung der neuen Vorgehensweisen. Eine
solche Herangehensweise ist auch eine Voraussetzung für Veränderungen im Zuge der Imple-
mentierung von wissensbasierten Informationssystemen zu und wird daher im Folgenden erläu-
tert.
Veränderungsprozess
gegenwärtiger
Zustand A Zielzustand B
unfreeze move refreeze
Quelle: [BrRP05, S. 91]
Abbildung 33: Die drei Phasen des Veränderungsprozesses
Die Phase „unfreeze“ beginnt, wenn ein Handlungsbedarf erkannt wird. Gewöhnlich entsteht der
Bedarf durch die Unzufriedenheit eines Entscheidungsträgers über einen aktuellen Zustand. In
SEITE 66 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
dieser Phase sind folgende Arbeitsschritte zur Erzeugung der gewünschten Veränderung erfor-
derlich [BrRP05, S. 89]:
• Analyse des derzeitigen Zustands der Organisation und der Prozesse,
• Bestimmung des Zielzustands mit einem konkreten Zielsystem für das Veränderungs-
projekt,
• Auswahl von Projektteammitgliedern,
• Kommunikation mit den betreffenden Organisationsmitgliedern,
• Grobplanung des Projektablaufs,
• Schulung und Information der Projektmitarbeiter.
Diese Struktur ist bis zu dieser Phase ähnlich zu der des in Kapitel 4.3.1 beschriebenen Projekt-
managements für die Standardsoftwareimplementierung und zeigt auf, dass es zwischen dem
Change Management und der Projektdurchführung viele Parallelen gibt, die bei ausreichender
Betrachtung zu Synergieeffekten und damit einem effizienten Gesamtprojekt führen können. Im
Gegensatz zum vorigen Modell werden hier die Elemente der Kommunikation und Information
der Projekt- und Organisationsmitglieder hervorgehoben. Entscheidend ist es, in dieser ersten
Phase sicher zu stellen, dass der Nutzen der Veränderung von einer „kritischen Masse“ der Or-
ganisationsmitglieder positiv bewertet wird. Diese Mehrheit muss die geplanten Veränderungen
aktiv fördern und größer sein als die zweite Gruppe, die sich regelmäßig als Verhinderungsmacht
darstellt und die Veränderungen zu stoppen versucht.
Die Bewegung hin zum neuen Zustand wird in der Phase „move“ durchgeführt. Dabei befindet
sich die Organisation im ersten Moment in einer Umgebung des „Ausprobierens“ der angedach-
ten Neuerungen. Auch dies steht im Gegensatz zum zuvor beschriebenen Projektmodell für
Standardsoftware. Dort ist es nicht die Intention etwas „auszuprobieren“, sondern vielmehr einen
neuen Zustand mit der Standardsoftware durchzusetzen. Die Aufgabe des hier angesprochenen
Veränderungsmanagements ist jedoch die Steuerung der notwendigen Aktivitäten um zu einem
gemeinsam entwickelten Zielzustands zu kommen. Es müssen gemäß der Veränderungslogik
folgende Schritte in der Phase „move“ durchgeführt werden [analog zu BrRP05, S. 90]:
• erstes „Ausprobieren“ der neuen Ansätze, z.B. das erstmalige Verwenden der neuen
Software,
• Schulung der von der Veränderung betroffenen Mitarbeiter, v.a. der Erstanwender,
• Evaluierung und Auswertung der Anwendung der neuen Ansätze zur Prüfung, ob die
geplanten Vorteile tatsächlich realisiert werden.
Zur Konservierung der neuen Ansätze wird die abschließende Phase „refreeze“ verwendet, die
dazu dient, den neuen Zustand zu festigen und über die gesamte Organisation zu verbreiten.
Dabei helfen vor allem kleine Zwischenerfolge, die ein Zurückfallen in den alten Zustand zu
verhindern. Im Rahmen der Standardsoftwareeinführung laut Kapitel 4.3 sind diese Arbeits-
schritte implizit ebenfalls enthalten, wobei keinerlei kontinuierliche Überleitung auf den neuen
Zustand stattgefunden hat. Die folgenden Schritte sind der Phase „refreeze“ zuzuordnen
[BrPR05, S. 90]:
• die Standardsoftware entwächst dem erfolgreichen Pilotbetrieb und wird flächende-
ckend eingeführt,
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 67
• Möglichkeiten des Zurückfallens in den alten Zustand werden beseitigt, beispielsweise
durch die Deinstallation der alten Software oder Tilgung alter Prozessschritte,
• fortlaufende Evaluation des neuen Ansatzes im laufenden Produktivbetrieb,
• weitere Optimierung und Anpassung des neuen Ansatzes aus den Erfahrungen des Pro-
duktivbetriebs.
Bei der Gestaltung der beschriebenen drei Phasen sind drei Hierarchieebenen von Akteuren zu
unterscheiden [BrPR05, S. 91ff.]. Die oberste Ebene ist die der Gesamtorganisation, die den
Umfang der Veränderung bestimmt. Es kann sich dabei um eine Abteilung, aber auch um ein
gesamtes Unternehmen handeln. In der zweiten Ebene können einzelne Gruppen identifiziert
werden, die den Veränderungsprozess beeinflussen können. Es gilt, diese Einflüsse abzuschätzen
und nutzbar zu machen. Die besondere Schwierigkeit besteht in der Identifikation der informel-
len Gruppen, die nicht direkt sichtbar sind. Jede Gruppe besteht aus einzelnen Individuen, die die
dritte Ebene darstellen. Jedes Individuum kann Mitglied in einer oder mehreren Gruppen sein,
wobei für den Veränderungsprozess insbesondere die Individuen interessant sind, die einerseits
einen hohen Einfluss innerhalb der Gruppe haben und andererseits in mehreren Gruppen vertre-
ten sind.
Zur zielorientierten Steuerung des Veränderungsprozesses müssen zusätzlich die Bestimmungs-
größen des Handelns der Akteure näher betrachtet werden. Diese Größen wirken sich direkt auf
das Verhalten der Individuen aus, die versuchen, die Auswirkungen ihrer Handlungen bzw.
eintretender Ereignisse zu antizipieren. Für das Veränderungsmanagement lassen sich gemäß
Abbildung 34 drei Komponenten als Ansatzpunkte identifizieren: das Wollen, das Können und
der Handlungsrahmen [BrRP05, S. 93].
Können
(Fähigkeiten)
- Fachkompetenz
- Methodenkompetenz
- Sozialkompetenz
Wollen
(Motivation)
- Ziele der Individuen
- Präferenzstruktur
- Wünsche
Handlungsrahmen
(Regeln, „Dürfen“, Umwelt)
- Gesetze
- Anweisungen
- Prozeduren, Routinen
- Werte, Normen, Kultur
Denkmodell
eines
Akteurs
Quelle: Verfasser nach [BrRP05, S. 95]
Abbildung 34: Bestimmungsgrößen des Handelns der Akteure
Das Wollen ist die Abbildung der Motivation des menschlichen Handelns. Die Wollenskompo-
nenten eines Individuums sind beispielsweise ein interessantes Aufgabenspektrum, sozialer
Status und Prestige oder ein kollegiales Arbeitsklima. Dabei können einzelne Ziele auch im
SEITE 68 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
Widerspruch zueinander stehen. Wichtig für den Prozess der Veränderung ist, die Menschen
entsprechend ihres tatsächlichen Willens einzusetzen.
Das Können bildet die körperlichen und mentalen Fähigkeiten der Akteure ab. Oft kommen im
Zuge der Veränderung neue Herausforderungen auf die Mitarbeiter zu, für die die notwendigen
Fähigkeiten zu ermitteln sind. Vorab ist zu prüfen, ob diese neuen Aufgaben mit den vorhande-
nen Befähigungen bewältigt werden können. Im Zweifel sind vorbereitende Maßnahmen wie
Schulungen durchzuführen oder geeignete Handbücher zur Verfügung zu stellen. Der Umfang
muss so bemessen sein, dass einerseits genügend Wissen vermittelt und andererseits eine „Über-
frachtung“ des Mitarbeiters vermieden wird.
Der Handlungsrahmen erlaubt jedem Akteur ein bestimmtes Repertoire an Handlungsmöglich-
keiten und schließt andere Optionen aus. Dadurch wird ein Korridor abgesteckt, innerhalb dessen
sich die Akteure bewegen. Das Veränderungsmanagement hat die Aufgabe, diesen Korridor zu
ermitteln und zu prüfen, ob die Veränderungsmaßnahmen innerhalb des gegebenen Rahmen
durchgeführt werden können. STREICH [Stre97, S. 241] führt für die Realisation eine zusätzliche
Dimension „Tun“ ein, die die konsequente Umsetzung abbildet. Diese ist häufig nicht gegeben,
da sich die meisten Menschen aufgrund ihres Wesens vor Veränderungen scheuen.
Was bei allen Bemühungen zu beachten ist, ist die Tatsache, dass die Entwicklung sozialer
Systeme nicht exakt prognostizierbar ist, da die geringste Variation großen Einfluss ausüben
kann. Hierzu kann als Vergleich das Bild einer Kugel auf einem Berg einer komplexen Hügel-
landschaft herangezogen werden: Es ist nicht vorhersagbar, in welches der angrenzenden Täler
sie rollen wird [MüLe05, S. 559]. Was aber die Führung in dieser Situation tun kann und muss
ist, für die Veränderung die Rahmenbedingungen zu schaffen, in denen die Bildung einer neuen
Ordnung begünstigt wird. Das Ziel könnte beispielsweise eine „Quasi-Standardisierung“ des
angewendeten Konzepts in der Organisation sein, wie dies bei Prozessen der Fall ist, die von
Standardsoftware eines großen Softwarehauses unterstützt werden. Solche Artefakte gelten nach
einer gewissen Zeit als selbstverständlich [FrSc01, S. 175].
4.5.2 Unterstützung von Erfolgsfaktoren bei ERP-Projekten durch Change Manage-
ment
Es gibt eine Vielzahl von Berichten über die Implementierung von Standardsoftware des ERP-
Typs. Obwohl die Bedeutung eines ERP-Systems für die Wettbewerbsfähigkeit sehr hoch ist,
wird dennoch von etlichen Misserfolgen berichtet [Kohn05, S. 41]. Meist werden in Form von
Praxisberichten und empirischen Fallstudien die entscheidenden Erfolgsfaktoren identifiziert.
KOHNKE [Kohn05, S. 42ff.] hat in seinem Aufsatz die wichtigsten Aussagen gesammelt und
gruppiert, die als Hinweise für die Vermeidung von Fehlern auch bei der Einführung von wis-
sensbasierten Informationssystemen dienen.
Die Abbildung 35 fasst ausgewählte Kategorien und Einzelfaktoren zusammen, wobei diejeni-
gen, die durch Change Management unterstützt werden können, mit einem Balken unterlegt sind.
Die übrigen Faktoren werden durch das Projektmanagement sowie die intensive Einbeziehung
von Menschen und der Organisation im Implementierungsmodell für wissensbasierte Informati-
onssysteme abgedeckt.
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 69
Top-Management-Commitment
Vision
Klare Projektziele
Lenkungsausschuss
Zusammensetzung des Projektteams
Ausreichend Ressourcen
Planung und Controlling
Geschäftsprozessoptimierung
Minimale Softwareanpassung
Kommunikation
Kooperation und Einbindung
Training
Auswahl des Softwarepakets
Systemintegration
Datenmanagement und -migration
Leistungskennzahlen
Zielvereinbarungs- und Anreizsystem
Kritische Erfolgsfaktoren
Kategorien
Top-Management-
Unterstützung
Projekt-
Management
Organisations-
Management
Stakeholder-
Management
Technologie-
Management
Leistungs-
Management
Erfolg des
ERP-Projekts
= Unterstützung durch Change Management
Quelle: Verfasser nach [Kohn05, S. 41ff.]
Abbildung 35: Die kritischen Erfolgsfaktoren bei ERP-Projekten und deren Unterstützung durch
Change Management
Der Unterstützung durch das Top-Management wird laut KOHNKE [Kohn05, S. 58] eine hohe
Bedeutung zugemessen, da die Implementierung einer Standardsoftware viele Bereiche eines
Unternehmens tangiert. Das Management muss die Veränderungen aktiv durch Beteiligung an
Besprechungen begleiten und die Vision, die den Veränderungsbedarf aufzeigt, mitgestalten und
mittragen. Die Vision stellt die langfristige Perspektive sicher, was den Aspekt berücksichtigt,
dass insbesondere kulturelle Veränderungen Zeit benötigen. Bei einer ERP-Einführung gibt die
Vision das Ziel für die nächsten drei bis fünf Jahre an [Kohn05, S. 44].
Das Stakeholder-Management meint die Einbindung der an dem Veränderungsprozess beteilig-
ten Personen. Das Ziel liegt darin, möglichst frühzeitig die Widerstände, Ängste und Unsicher-
heiten im Rahmen der Implementierung der Informationstechnologie zu beseitigen [Kohn05, S.
47f.]. Diese Zielsetzung kann mit einem Change Management begleitet werden. Dafür ist eine
umfassende Kommunikation und Kooperation mit den betroffenen Mitarbeitern notwendig. Die
Kommunikation muss regelmäßig erfolgen und vor allem den Nutzen des neuen Softwaresys-
tems in den Vordergrund stellen [Kohn05, S. 48]. Die Kooperation mit den zukünftigen Nutzern
bedeutet deren Einbeziehung in die Gestaltung des Systems. Dabei hilft auch die rechtzeitige und
umfassende Schulung der Anwender, die dadurch auch ein Verständnis für die neuen Funktiona-
litäten erhalten und mit dem neuen System in kurzer Zeit produktiv arbeiten können.
SEITE 70 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
Das Leistungs-Management beobachtet zuvor festgelegte Faktoren in Form von Kennzahlen.
Damit kann der Erfolg der Implementierung bzw. des Change Managements nachgewiesen
werden. Zur Steuerung dieser Zielerreichung bietet sich die Verknüpfung mit einem Anreizsys-
tem zur Verhaltenssteuerung der Mitarbeiter an [Kohn05, S. 51].
4.5.3 Gestaltung und Akzeptanz eines Veränderungsprojektes
Die Gestaltung eines Veränderungsprojekts kann auf verschiedene Arten geschehen. Aufgrund
der großen Gestaltungsfreiheit erscheint als Basis die Betrachtung der beschriebenen Fehler, die
auf keinen Fall begangen werden dürfen, sinnvoll. KOTTER [Kott95, S. 59ff.] stellt anhand der
Fehlerauswertung ein achtstufiges Modell vor, wie ein Veränderungsprozess gestaltet werden
kann. Die Stufen zur Transformation einer Unternehmung, die auch für den Implementierungs-
prozess eines wissensbasierten Informationssystems gelten, sind die Folgenden:
• Erzeugung eines Gefühls der Dringlichkeit
Die Mitarbeiter müssen ein Bild von der Notwendigkeit und den Zielen der Maßnah-
men erhalten. Dazu muss sowohl die derzeitige Situation als auch der gewünschte Soll-
Zustand kommuniziert werden. Menschen dürfen nicht wie bei einem „Kaltstart“ mit
Dingen konfrontiert werden, deren Sinn sie nicht einsehen [DoLa02, S. 82]. Die besten
Resultate sind zu erwarten, wenn die Mitarbeiter einen persönlichen Nutzen aus dem
Veränderungsprojekt ziehen können.
• Aufbau einer starken Führungskoalition
Innerhalb der Organisation muss es eine weitreichende Unterstützung des Vorhabens
von Seiten der Unternehmensführung geben. Das Ziel sollte die Einbindung aller Hie-
rarchieebenen sein, damit das Projekt nicht auf eine Ebene beschränkt bleibt.
• Aufbau einer Vision
Bereits bei Start des Veränderungsprojekts muss das Ziel eindeutig formuliert sein und
als solches verfolgt werden. Aus der Vision heraus lässt sich eine Strategie zur Errei-
chung der formulierten Ziele entwickeln. Die Vision wirkt als eine Art „Stern von
Bethlehem“, der zwar nicht erreichbar ist, aber den Weg zeigt, der beschritten werden
soll [DoLa02, S. 170].
• Kommunikation der Vision
Auch wenn dieser Schritt selbstverständlich scheint, so muss doch erwähnt werden,
dass die Kommunikation der Vision die Voraussetzung dafür ist, dass sie gelebt wer-
den kann. Die Führungskräfte sind diejenigen, die zuerst nach der neuen Vision han-
deln müssen und sie dadurch in der Organisation verbreiten. Der Faktor Kommunika-
tion ist entscheidend, da Menschen fast nur durch direkte Kommunikation lernen und
ihr Verhalten ändern [DoLa02, S. 337].
• Vision auf breite Basis stellen
Die Vision muss auf einer breiten Basis gelebt werden können. Daher müssen alle be-
teiligten Mitarbeiter unabhängig von ihrem Hierarchiestatus die Handlungskompetenz
haben, die Veränderungen in ihrem Bereich auszuführen. Das erzeugte Gefühl, durch
eigenes Handeln einen Einfluss nehmen zu können, dient gleichzeitig als Motivation.
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 71
• Kurzfristige Ziele anstreben
Veränderungsprojekte sind in der Regel sehr langfristig angelegt. Zwischenzeitliche
kleine Erfolgserlebnisse können das Vorhaben immer wieder aufs Neue bestätigen und
werden zusätzlich als Erfolg wahrgenommen. Dazu muss das Projekt von vornherein in
kleine überschaubare Einheiten zerlegt werden (vergleiche auch Kapitel 4.5.1), an de-
ren Ende jeweils ein Ziel steht, bei dessen Erreichung ein Erfolgserlebnis darstellt.
• Konsolidieren der Verbesserungen und weitere Veränderungen ableiten
Die erreichten Erfolge müssen weiterhin gelebt und über die gesamte Organisation
ausgeweitet werden. Aus den bereits bestehenden Verbesserungen können immer wie-
der neue Maßnahmen abgeleitet werden, damit eine stetige weitere Optimierung reali-
siert werden kann.
• Verankerung neuer Ansätze in der Kultur
In diesem letzten Schritt müssen die neuen Ansätze nachhaltig gesichert werden, indem
sie in die Kultur des Unternehmens übergehen.
Ein weiterer wichtiger Faktor ist die Akzeptanz eines Veränderungsvorhabens. Die betroffe-
nen Mitarbeiter müssen eine möglichst positive Einstellung zu der geplanten Veränderung
aufzeigen. Zur Klärung der Frage, ob die Akzeptanzziele erreicht wurden, können laut REIß
[Reiß97, S. 92] Akzeptanzindikatoren herangezogen werden. Als Indikator kann etwa die Be-
obachtung des Verhaltens der Mitarbeiter herangezogen werden. Eine Verifizierung kann
durch eine Mitarbeiterbefragung durchgeführt werden. Nehmen die Mitarbeiter die neue Ord-
nung bzw. das neue System freiwillig an, so ist dies ein überzeugender Hinweis auf die Ak-
zeptanz. Als dokumentierte Indikatoren gelten persönliche Zielvereinbarungen oder kollektive
Betriebsvereinbarungen zur Anwendung der neuen Ordnung [Reiß97, S. 92].
Als Bestimmungsgrößen für den Grad der Akzeptanz besitzen Akzeptanzfaktoren eine
zentrale Bedeutung [Reiß97, S. 93]. Sie fungieren auch als Ansatzpunkte und Stellgrößen für
gezielte Förderaktivitäten. REIß [Reiß97, S. 93] unterscheidet laut Abbildung 36 vier Akzep-
tanzfaktoren. Die Förderung der Akzeptanz kann dadurch geschehen, dass die Betroffenen die
Veränderung kennen, mit ihr umgehen können und sie vor allem selbst wollen.
Als Gründe für das Scheitern von Veränderungsprojekten werden regelmäßig mitarbeiterbe-
zogene Faktoren genannt wie die fehlende Identifikation oder Widerstände gegen Neuerungen
[KoMö02, S. 13]. Es kommen noch eine Vielzahl von weiteren Gründen sowohl aus dem Be-
reich der Änderungsfähigkeit als auch aus dem Bereich der Änderungsbereitschaft in Be-
tracht, die gegen eine Akzeptanz der Änderung sprechen. Bei rechtzeitiger Betrachtung lassen
sich viele dieser Faktoren bereits im Vorfeld vermeiden. Im Rahmen der Änderungsfähigkeit
spielt vor allem das Kennen eine Rolle. Bei ungenügender Information der Mitarbeiter ist eine
Ablehnung der Neuerung zu erwarten, da niemand bereit ist, etwas zu unterstützen, das ihm
unbekannt ist und wo die Vorteile nicht ersichtlich sind. Im engen Zusammenhang mit dem
Kennen ist das Können zu sehen, da die Veränderungsbereitschaft auch dann steigt, wenn der
Mitarbeiter neben einer Information zusätzliche Kompetenzen vermittelt bekommt. Als Ab-
hilfe sind beispielsweise regelmäßige Informations- und Schulungsmaßnahmen vorzusehen,
die den Mitarbeiter dabei unterstützen, an der Veränderung aktiv mitzuarbeiten und diese mit-
zugestalten.
SEITE 72 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
Die Änderungsbereitschaft im Rahmen des Sollens lässt sich dadurch erhöhen, dass die Pro-
jektteammitglieder so ausgewählt werden, dass sie in ihren Bereichen als Multiplikatoren
auftreten und den Veränderungsprozess gemeinsam mit ihren Kollegen aktiv begleiten. Eine
zusätzliche Unterstützung des Wollens bieten immaterielle und monetäre Anreize, die für die
erfolgreiche Anwendung der veränderten Prozesse ausgelobt werden.
Akzeptanz der Änderung
Änderungsfähigkeit Änderungsbereitschaft
• Mitarbeiterzeitschrift
• Visualisierung
• Informationsmarkt
• Beratung
•...
Kennen
• Fachkompetenz
• Mitarbeiterkompetenz
• Sozialkompetenz
•...
Können
• Intrinsische Anreize
• Extrinsische Anreize
• Kompensatorische
Anreize
• Transparenz
•...
Wollen
• Projektorganisation
• Promotoren
• Multiplikatoren
• Partizipation
•Begleitung
•...
Sollen
Quelle: [Reiß97, S. 93]
Abbildung 36: Akzeptanzfaktoren bei Veränderungsprojekten
4.6 Kernpunkte erfolgreicher Standardsoftware-Implementierungen und Adap-
tionsmöglichkeiten für wissensbasierte Informationssysteme
In diesem Kapitel wurden die wesentlichen Erfolgsfaktoren Projektorganisation, Vorgehenswei-
sen, Change Management und Business Process Reengineering bei einem Standardsoftware-
Implementierungsprojekts diskutiert. Rückblickend kommen einige der Aspekte für das Vorge-
hen bei wissensbasieren Informationssystemen nicht in Betracht, während sich andere Bestand-
teile nach Anpassung übernehmen lassen.
Zu den Inhalten, die für eine weitere Verwendung nicht in Frage kommen, gehört vor allem der
Ansatz des Business Process Reengineering. Wie in Kapitel 4.4.3 dargestellt, ist es für wissens-
basierte Informationssysteme ein wichtiger Teilbereich, sich den gegebenen Geschäftsprozessen
flexibel anpassen zu können. Die Grundannahme des Business Process Reengineering, alle
Prozesse in Frage zu stellen und zu überarbeiten, läuft den Gedanken des wissensorientierten
Arbeitens entgegen. Es sind die im Unternehmen bereits etablierten Prozesse zu verwenden, die
von den Mitarbeitern praktiziert und gelebt werden. Diese Prozesse sind bereits erprobt und
bewährt und bedürfen keiner Erneuerung. Die Mitarbeiter sind außerdem nicht in der Lage,
sowohl neue Prozesse als auch die Wandlung hin zu einer wissensorientierten Arbeitsweise
gleichzeitig zu vollziehen.
VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE SEITE 73
Ein weiterer Ansatz, der sich für die weitere Verwendung nicht eignet, ist die „Big Bang“-
Einführungsstrategie (vergleiche Kapitel 4.3.1). Durch die schlagartige Einführung eines neuen
Systems fehlt in der wissensorientierten Vorgehensweise die Zeit für die Antizipierung der
neuen Verhaltensweisen durch die Mitarbeiter. Vielmehr kommen Einführungsstrategien in
Frage, die ein kontinuierlichen Übergang auf ein neues System erlauben.
Insbesondere die Strukturierung der Vorgehensweise in einem Projekt mit hinterlegtem
Phasenkonzept, die die Kapitel 4.2 und Kapitel 4.3.2 beschreiben, ist mit einigen Anpassungen
für die wissensorientierte Implementierung anwendbar. Die Einteilung der großen
Gesamtaufgabe in kleinere Teilbereiche und die schrittweise Abarbeitung in Projektteams mit
jeweils unterschiedlicher Mitarbeiterbesetzung ist angebracht. Ähnliches gilt für das in Kapitel
4.5 angeführte Change Management in Standardsoftwareprojekten. Ein Change Management ist
für die Einführung eines wissensbasierten Informationssystems unbedingt erforderlich, muss im
Hinblick auf die langsame Veränderung der Organisation hin zu einer wissensbasierten
Zusammenarbeit angepasst werden.
Zusammenfassend können einige weitere Kernpunkte analog zu Standardsoftware-Implementie-
rungen nach SHIELDS [Shie02, S. 30ff.] genannt werden, die gemäß den Ausführungen dieses
Kapitels als Grundsätze für eine schnelle und gezielte Implementierung eines wissensbasierten
Informationssystems übernommen werden können.
• Entscheidungen müssen schnell getroffen werden
Zur Umsetzung dieser Forderung muss das Implementierungsteam aus eigener Fach-
kompetenz heraus entscheiden dürfen. Bei Meinungsverschiedenheiten oder der Erfor-
dernis der Geschäftsführungsmitwirkung müssen kurze Instanzwege eine schnelle Ent-
scheidung ermöglichen.
• Die technologische Infrastruktur muss von Beginn an stehen
Das Projektteam benötigt eine „Sandkasten-Umgebung“, in der von Beginn an getestet
werden kann. Es darf keine Verzögerungen durch vorweg vorzunehmende Hardware-
installationen oder langwierige Vertragsverhandlungen geben.
• Einsatz kleiner, abteilungsübergreifender Projektteams
Die Teammitglieder sollen möglichst Vollzeit an dem Projekt arbeiten, damit sie auf-
grund ihres Erfahrungswissen und ihrer Qualifikation schnell Entscheidungen treffen
können. Die Mitarbeiter müssen primär selbständig entscheiden, da sie später selbst mit
dem System leben müssen.
• Management der Projektinhalte
Der Umfang und die Dauer des Projekts müssen im Vorfeld genau bestimmt werden
und während der Laufzeit nachvollziehbar bzw. steuerbar bleiben. Es ist eine klare
Zieldefinition notwendig, da der Projektinhalt während des Projekts nicht beliebig er-
weitert und verändert werden darf. Bei größeren Projekten sind Teilziele zu definieren,
die eine regelmäßige Statuskontrolle ermöglichen.
• Verwendung eines vorkonfigurierten Softwaresystems
Umfangreiche Grundkonfigurationen dürfen nicht in einem Implementierungsprojekt
abgebildet werden. Es ist allenfalls eine Anpassung der Softwarekonfiguration im
Rahmen der Implementierung sinnvoll, da sonst zu viel Zeit benötigt wird.
SEITE 74 VERFAHREN ZUR IMPLEMENTIERUNG VON STANDARDSOFTWARE
• Wahl eines prozessorientierten Ansatzes
Die Technologie ist ein wesentlicher Bestandteil, aber es gilt, die Geschäftsprozesse zu
unterstützen. Die Mitarbeiter müssen daher die Prozesse sehr gut kennen und verste-
hen, um zu entscheiden, auf welche Prozesse das Projekt fokussiert werden soll.
• Parallele Durchführung von Aufgaben
Um den Implementierungsprozess nicht unnötig lang zu gestalten, muss von vorn-
herein auf eine mögliche parallele Abarbeitung von Aufgaben geachtet werden.
Voraussetzung dafür ist eine intensive Kommunikation innerhalb des Teams.
Der Ansatzpunkt für die Implementierung wissensbasierter Informationssysteme ist dort zu
sehen, wo die gängigen Verfahren für Standardsoftware aufhören. Beispielsweise eine ERP-
Software stellt für die Prozesslandschaft bereits einen Standard dar [Pete05, S. 69], wodurch sich
der Prozess der Standardsoftware anpassen muss und nicht umgekehrt. Wie bereits im Kapitel 3
dargestellt sind die Inhalte und Methoden des Wissensmanagements individuell auf die Gege-
benheiten in einer Organisation abzustimmen. Das bedingt die Notwendigkeit, im wissensorien-
tierten Implementierungsprozess zunächst einen Geschäftsprozess zu analysieren und für diesen
zu überprüfen, ob auf dem Wissensmanagement basierende Unterstützungsmöglichkeiten in
Betracht kommen. Im Anschluss ist zu ermitteln, inwieweit eine Software für die Zielerreichung
benötigt wird. Das Spektrum kann dabei von einem bereits vorhandenen Tool bis hin zu einer
vollständigen Neuentwicklung reichen. Das Projektmanagement ist dabei in der Form zu adap-
tieren, dass es zunächst die Modellierung geeigneter Prozessstrukturen unterstützt und im An-
schluss eine Strukturierung für die Entwicklung und Implementierung einer unterstützenden
Software vorgibt.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 75
5 Implementierungsmodell für wissensbasierte Informations-
systeme in die industrielle Prozessumgebung
Die Pflanze gleicht den eigensinnigen Menschen,
von denen man alles erhalten kann,
wenn man sie nach ihrer Art behandelt.
(Johann Wolfgang von Goethe)
In diesem Kapitel wird ein Implementierungsmodell für wissensbasierte Informationssysteme
entwickelt, das auf den Annahmen des Wissensmanagements beruht und eine Verbindung zu den
erprobten Implementierungsschritten für Standardsoftware herstellt. Einen Überblick über die
hier aufgezeigte Vorgehensweise der Implementierung eines wissensbasierten Informationssys-
tems zeigt die Abbildung 37. Das Modell ist so aufgebaut, dass es unabhängig von einem
speziellen wissensbasierten Informationssystem zu verwenden ist. Die Entscheidung für ein
bestimmtes Softwaresystem kann bereits in einer Vorstudie vor dem Implementierungsprojekt
oder nach Abschluss der Vorbereitungsphase gefällt werden. Durch den Zeitpunkt dieser Ent-
scheidung wird auch beeinflusst, ob der Softwareanbieter bereits an den frühen Projektphasen
mitarbeitet, oder ob er in der Pilotphase im Zusammenhang mit der Einführung seines Produkts
in das Projekt aufgenommen wird.
Phasenkonzept zur prozessualen Integration
des wissensbasierten Informationssystems
Mitarbeiterorientiertes
Change Management
Anpassung des Softwaresystems
Langfristige Erfolgssicherung
Kick-off des Projekts
Zieldefinition
Wissensmanagement als Basis
P r o j e k t m a n a g e m e n t
Quelle: Verfasser
Abbildung 37: Aufbau des Implementierungsmodells
SEITE 76 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
Bevor in den folgenden Unterkapiteln näher auf die einzelnen Phasen eingegangen wird, soll die
Gesamtausrichtung des Modells an dieser Stelle kurz erläutert werden. Das vorgeschlagene
Implementierungsmodell basiert auf der Annahme, dass die Implementierung in der Organisa-
tionsform eines Projekts durchgeführt wird. Mit dieser auf einen befristeten zeitlichen Umfang
angelegten Projektorganisation lassen sich die interdisziplinären Ansätze des Wissensmana-
gements optimal verwirklichen. Weiterhin soll das Projekt neben den Teilbereichen Technik,
Organisation, Mensch (vergleiche mit dem TOM-Modell von BULLINGER ET AL.) eine ausge-
prägte Integrationskomponente beinhalten, die die Einbettung des wissensbasierten Informati-
onssystems in die vorhandene Prozessstruktur des Unternehmens berücksichtigt. Die Vorausset-
zung für den Start des Projekts mit einer Kick-off Veranstaltung ist die klare Definition von
Zielen, die das Projekt erfüllen soll.
Nach dem Projektstart lassen sich zwei Dimensionen unterscheiden. Einerseits wird ein Phasen-
konzept zur Sicherstellung der prozessualen Integration des wissensbasierten Informationssys-
tems aufgezeigt. Die Planung und Steuerung kann mit den Instrumenten des Projektmanage-
ments durchgeführt werden. Andererseits müssen während der Projektlaufzeit als Begleitpro-
zesse drei weitere Themenbereiche berücksichtigt werden, die im Vergleich zu einer in Kapitel 4
dargestellten Einführung einer Standardsoftware wesentlich genauer und sensibler zu betrachten
sind:
• ein mitarbeiterorientiertes Change Management,
• eine kontinuierliche Softwareanpassung auf die Unternehmensprozesse sowie
• die stetige Bemühung, das Projekt auch langfristig zu einem Erfolg werden zu lassen.
Bei allen genannten Aktivitäten kommen die im Kapitel 3 behandelten Ansätze des Wissens-
managements als Ausgangspunkt der Überlegungen zum Einsatz.
Die Abbildung 37 ist im Sinne einer horizontalen Zeitachse bewusst nach rechts hin offen gehal-
ten, da die Implementierung des wissensbasierten Informationssystems niemals als „abgeschlos-
sen“ gelten darf. Vielmehr müssen die Prozesse und Strukturen stets neu hinterfragt werden,
auch wenn die ursprünglich definierten Projektziele bereits erreicht worden sind, da sich nur so
eine laufende Verbesserung und damit eine Stärkung im Wettbewerb erreichen lässt.
5.1 Das Wissensmanagement als Grundlage
Das hier entwickelte Implementierungsmodell beruht auf den Annahmen und Voraussetzungen
des Wissensmanagements. Diese müssen im Prozess der Einführung eines wissensbasierten
Informationssystems unbedingt beachtet werden, wodurch sich die Unterschiede in der Vorge-
hensweise im Vergleich zur Einführung einer Standardsoftware ergeben. Die Beachtung dieses
Hintergrunds ist unabhängig von einem bestimmten wissensbasierten Informationssystem zu
sehen, da die Systeme zwar in verschiedenen Unternehmensbereichen eingesetzt werden können,
der Umgang mit den Mitarbeitern und deren notwendige positive Einstellung aber immer die
gleiche Voraussetzung bilden. Die Abbildung 37 zeigt bereits die Wissensmanagement-
grundlage, die von den weiteren Kernprozessen des Implementierungsmodells überlagert wird.
Wie im Folgenden gezeigt wird, deckt die Implementierung eines wissensbasierten Informa-
tionssystems breite Teile der Aufgaben ab, die gemäß Kapitel 3 im Rahmen eines Wissens-
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 77
managements gefordert werden. Die Intention des Implementierungsmodells liegt darin, das
Wissensmanagement einzubinden, um eine erfolgreiche Nutzung des wissensbasierten Informa-
tionssystems zu gewährleisten.
5.1.1 Anwendung eines integrationsorientierten TOM-Modells
Das Modell Technik, Organisation, Mensch von BULLINGER [BWPW98] bildet die zentrale
Größe dieses Implementierungsmodells. Die Komponente Technik ist der Verankerungspunkt,
der das wissensbasierte Informationssystem fokussiert. Ausgehend von dem softwaretechnischen
System werden die Organisation und die in ihr ablaufenden Prozesse unter Beachtung der vor-
herrschenden Unternehmenskultur im Rahmen einer Vorstudie analysiert und im Anschluss
während der Implementierung kontinuierlich und gezielt verändert. Der Faktor Mensch wird im
Implementierungsprojekt als wichtigste Komponente betrachtet, da mittels einer intensiven
Kommunikation der Ziele und einer Beteiligung von Schlüsselmitarbeitern an der Bearbeitung
der Projektaufgaben eine breite Akzeptanz zu erreichen ist.
Neben dem standardisierten TOM-Modell (Kapitel 3.1.3) verfolgt das hier aufgezeigte Imple-
mentierungsmodell eine zusätzliche Integrationskomponente, indem durch die starke Einbezie-
hung und Beteiligung der Mitarbeiter an der systematischen Einführung und Weiterentwicklung
von Software und Prozessen das Ziel erreicht werden soll, eine Überführung der neu erprobten
Vorgehensweisen in die Unternehmenskultur zu realisieren. Dies ist vergleichbar mit einer Stan-
dardisierung, die auch bei einer Bearbeitung von Prozessabläufen mit einer Standardsoftware
verfolgt wird. Das wissensbasierte Informationssystem und der gezielte Umgang mit Wissens-
ressourcen soll von den Mitarbeitern als Selbstverständlichkeit aufgefasst und ohne neuerliche
Überlegungen automatisiert durchgeführt werden können. Die Veranschaulichung dieser Vorge-
hensweise zeigt die Abbildung 38.
mit dem
Implementierungs-
projekt
Wissensbasiertes
Informationssystem
Technik
Unternehmenskultur
Prozessbetrachtung
Organisation
Integration
Intensive Einbeziehung im
Implementierungsprojekt
Mensch
Quelle: Verfasser
Abbildung 38: Integration von Technik, Organisation und Mensch
SEITE 78 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
Die Integrationskomponente beinhaltet auch eine zusammenhängende Anwendung der Persona-
lisierungs- und Kodifizierungsstrategie. Die gemeinsame Anwendung wird in der Literatur ge-
mäß Kapitel 3.1.3 zwar vielfach kritisiert, dennoch bietet ein wissensbasiertes Informationssys-
tem die Möglichkeit, nicht nur einen expliziten Wissensbestand abrufbar zu machen, sondern
zusätzlich auch die Option, Mitarbeiter gezielt zu den gespeicherten Themen in Kontakt zu
bringen, indem zu entsprechenden Einträgen Ansprechpartner hinterlegt werden. Diese Mehr-
fachfunktion bietet viele Möglichkeiten im Rahmen der Systemintegration, Anknüpfungspunkte
in die bestehende Organisation zu verankern, so dass Nachteile wie die Gefahr der unscharfen
Trennung zwischen beiden Vorgehensweisen nicht ins Gewicht fallen. Einige Vorteile sind im
Folgenden aufgelistet:
• Für die Mitarbeiter bietet die hohe Integrationsleistung die Chance auf eine persönliche
Weiterqualifikation, da sie das wissensbasierte Informationssystem von Beginn an mit-
gestalten können und mit den Gedanken des Wissensmanagements vertraut gemacht
werden.
• Im späteren Betrieb des Softwaresystems sind sie in der Lage, ihre Problemstellungen
mit dem großen, im wissensbasierten Informationssystem gespeicherten Wissenspool
erheblich schneller und zielgerichteter zu analysieren und zu lösen.
• Wird das Ziel einer großen Bereitschaft zur Wissensweitergabe konsequent erreicht,
können die explizierten Wissensressourcen einzelner Mitarbeiter von anderen Kollegen
zu neuen Problemlösungen verwendet werden. Das wissensbasierte Informationssys-
tem stellt hierzu nach seiner Integration die Wissensressourcen prozessgerecht bereit,
so dass die im Wissensmanagement geforderte nahtlose Integration von technischem
System, organisatorischer Gestaltung und Mitarbeiter erreicht wird. Die Integration hat
auch zum Ziel, das wissensbasierte Informationssystem zu einer Schnittstelle zwischen
Mitarbeitern zu machen.
5.1.2 Umsetzung einer prozessorientierten Einführungsstrategie
Ein erfolgreiches Wissensmanagement muss, wie bereits in dieser Arbeit in Kapitel 3.1.3 darge-
stellt, in die Prozesse eines Unternehmens integriert sein. Das gleiche gilt auch für wissensba-
sierte Informationssysteme, deren intensive Nutzung nur dann zu erwarten ist, wenn sie bei der
Abarbeitung einzelner Prozessschritte unterstützen. Die in Kapitel 4.2 und 4.3 aufgezeigten
Vorgehensweisen zur Implementierung einer Standardsoftware sind hier nicht umsetzbar, da sie
vor der Softwareeinführung keine Analyse der Ist-Prozesse berücksichtigen. Sie sind vielmehr
darauf ausgerichtet, die Prozesse anhand der Vorgaben der Standardsoftware anzupassen. Zur
Unterstützung der Wissensprozesse ist es unerlässlich, die bereits vorhandenen Strukturen zu
nutzen und zu vertiefen. Daher verwendet dieses Implementierungsmodell eine in mehrere Pha-
sen gegliederte prozessorientierte Implementierungsstrategie für das Softwaresystem gemäß
Abbildung 39.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 79
Pilotphase Ausbau-
phase
Vollbetriebs-
phase
Vorbereitungs-
phase
Prozessintegration des
wissensbasierten Informationssystems
Schwerpunkte der Prozessorientierung:
- Vorauswahl möglicher Prozessketten für das wissensbasierte
Informationssystem
- Durchführung einer Vorstudie mit Prozess- und
Workflowanalysen
- Auswahl eines Softwareherstellers und Softwareanpassung
auf die Prozesse
- Integration in einen Pilotprozess
- Ausrollen auf weitere Prozessketten im Unternehmen
- Beteiligung der Mitarbeiter
Quelle: Verfasser
Abbildung 39: Prozessorientierung des Implementierungsmodells
Zur Umsetzung einer prozessorientierten Integrationsstrategie ist eine klare Strukturierung uner-
lässlich. Das Modell schlägt hierzu eine Vorgehensweise nach vier aufeinanderfolgenden Phasen
vor, die im folgenden Teilkapitel näher erläutert werden. An dieser Stelle wird besonders darauf
verwiesen, dass sich die Prozessorientierung insbesondere dadurch charakterisieren lässt, dass
alle Arbeiten zur Einführung des Softwaresystems direkt entlang der Prozesskette stattfinden.
Dabei werden sowohl die einzelnen Aufgaben, Dokumente und Workflows betrachtet, als auch
die die Prozesse ausführenden Mitarbeiter verstärkt einbezogen.
In der Vorbereitungsphase werden die Eigenschaften und die Einsatzfähigkeit verschiedener
wissensbasierter Informationssysteme abgeschätzt, um sie auf die Eignung für die Unterstützung
der Unternehmensprozesse zu untersuchen. Für die Auswahl des Softwaresystems sind einige
besondere Kriterien zu beachten:
• Möglichkeit der Abbildung der Prozesse in der Software,
• Ermöglichung des Zugriffs auf die Software für alle am Prozess beteiligten Mitarbeiter,
• Hinterlegung aller für den Prozess notwendigen Wissensressourcen in der Software,
• Verwaltung der Inhalte mit geringem Zeitaufwand,
• Möglichkeit der Unterstützung bei der Prozessanalyse sowie der Anpassung und
Konfiguration der Software durch den Hersteller,
• einfache Handhabung,
• intuitive Verständlichkeit,
• Anschaffungskosten und Betriebskosten im Rahmen der bewilligten Investitions-
summe.
Nach der Auswahl des Softwaresystems, wird ein Pilotbereich im Unternehmen bestimmt, der
sich dadurch hervorhebt, dass die Prozesse in ihrer Anzahl überschaubar sind. Insbesondere
SEITE 80 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
müssen die Mitarbeiter offen für neuartige Aufgaben sein und diese innovativ und motiviert
angehen. Im Folgenden kann in diesen Schritten vorgegangen werden:
• Zunächst sind vom Projektteam die Prozesse sowie die Dokumente und Arbeitsflüsse
des ausgewählten Bereichs zu analysieren und auf die Unterstützungsmöglichkeiten
durch das wissensbasierte Informationssystem zu überprüfen. Hierbei sind die Eigen-
schaften des ausgewählten Softwaresystems zu beachten, da eine Anpassung zwar
möglich ist, aber überzogene Anforderungen zu einer völligen Neuentwicklung führen,
die aus Kostengesichtspunkten nicht sinnvoll erscheint. In der ersten Phase ist es erfor-
derlich, für die Integration einfache Prozessschritte auszuwählen, da komplexe Struktu-
ren mit mehr Projekterfahrung besser umsetzbar sind. Der Hersteller der Software kann
wichtige Hinweise zu den Gestaltungsmöglichkeiten seines Systems geben und sollte
daher bereits an der Prozessanalyse beteiligt werden. Er kann auch dabei helfen, bei der
Analyse eine „Betriebsblindheit“ zu vermeiden. Sie tritt auf, wenn die Bedeutung der
eigenen Wissensressourcen durch die tägliche Routine nicht mehr erkannt wird
[PRRo03, S. 177].
• Anschließend ist das neue Softwaresystem im Prozesskontext zu integrieren. Ziel ist
es, ähnlich einer Standardsoftware, einen automatisierten und selbstverständlichen Ar-
beitsablauf zu erzeugen. Dies kann dadurch geschehen, dass das wissensbasierte In-
formationssystem als Medium zur Vorbereitung von regelmäßigen Besprechungen ein-
gesetzt wird, die zum Ziel haben, das im Laufe eines festen Zeitraums im wissensba-
sierten System neu hinzugekommene Wissen zu hinterfragen und tiefer zu analysieren.
Die Inhalte können auch eine Schnittstelle bzw. Diskussionsgrundlage für die Mitar-
beiter bieten, um neue Erkenntnisse übergreifend zu diskutieren. Mit Hilfe dieser
nachhaltigen prozessorientierten Gestaltung ist ein hoher Akzeptanz- und Nutzungs-
grad zu erwarten, vergleichbar mit einer voll eingeführten Standardsoftware.
• Bereits während der Pilotphase ist mit einer Messung des Systemnutzens zu beginnen,
deren Durchführung und deren Kriterien im Kapitel 6 aufgezeigt werden. Erweist sich
der Pilotversuch in einem eng begrenzten Prozessumfeld als erfolgreich, ist eine Aus-
weitung der Implementierung auf weitere Prozesse anzustreben. Dazu werden die vor-
her beschriebenen Schritte, beginnend mit der Analyse der Bereiche, die zuvor noch
nicht erfasst wurden, erneut durchlaufen. Eine Workflow-Integration, d.h. eine auto-
matisierte Arbeitsabfolge, stellt das zu erreichende Optimum dar.
Diese Vorgehensweise impliziert, dass ein Wissensprozess ähnlich dem „Genfer Modell“ von
PROBST/RAUB/ROMHARDT (vergleiche Kapitel 3.1.3) durchlaufen wird. Bei der Analyse der
Unternehmensprozesse werden Wissenspotenziale identifiziert, deren Bewahrung, Nutzung,
Weiterentwicklung und Verteilung nach der Implementierung mit dem wissensbasierten Infor-
mationssystem automatisiert abläuft. Somit steht nicht das Softwaresystem selbst im Vorder-
grund und verlangt eine Anpassung der Unternehmensprozesse, sondern die Prozesse werden
einerseits durch die Software und andererseits durch den geförderten Umgang mit bereits vor-
handenen Wissensressourcen unterstützt. Je geringer die Widerstände gegen das Softwaresystem
ausfallen, desto eher kann eine Konzentration auf die Zielsetzungen des Wissensmanagements
stattfinden, da keine Blockadehaltung seitens der Mitarbeiter entsteht.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 81
5.1.3 Einbettung in das Konzept der Lernenden Organisation
Das Konzept der lernenden Organisation fordert die Transformation von individuellem zu orga-
nisationalem Wissen (vergleiche die Ausführungen in Kapitel 3.2). Die wesentlichen Bedingun-
gen sind Kommunikation, Transparenz und Integration. Durch die prozessorientierte Vorge-
hensweise der Implementierung werden diese Faktoren stark gefördert. Das wissensbasierte
Informationssystem ist in die Prozessabläufe integriert, so dass es als Kommunikationsschnitt-
stelle zwischen Mitarbeitern dienen kann. Die Transparenz entsteht durch die Dokumentation der
Wissensressourcen der Wissensträger, so dass jedes Organisationsmitglied gemäß seiner Aufga-
benstellung im Prozess zielgerichtet auf expliziertes Wissen zugreifen kann. Durch die Hinterle-
gung von Ansprechpartnern zu den Einträgen wird die Kommunikation auch in späteren Stadien
angeregt, da die Mitarbeiter das Wissen als Diskussionsgrundlage verwenden können.
Ziele Handlungen Ergebnisse
Hinterfragung der
Information durch
die Mitarbeiter
Gestaltung des
Umgangs mit
Wissens-
ressourcen
Reflexion,
Analyse und
Herstellung
eines
Sinnbezugs
Unternehmen
optimiert die eigene
Lernfähigkeit durch
das System
Veränderungslernen
Prozesslernen
Anpassungslernen
Quelle: Verfasser
Abbildung 40: Durchlaufen der Lernformen während der Implementierung
Es werden durch den Implementierungsvorgang des wissensbasierten Informationssystems die in
Kapitel 3.2.1 dargestellten Lernstufen vollständig durchlaufen (vergleiche Abbildung 40). Das
Anpassungslernen wird durch die Hinterfragung der Informationen durch die Mitarbeiter
repräsentiert. In der weiter gehenden Zieldefinition und Vorbereitung des
Implementierungsvorhabens werden die Prozesse beleuchtet und hinterfragt, um zu ermitteln,
wie der Umgang mit den Wissensressourcen des Unternehmens gestaltet werden kann. Hierbei
handelt es sich um ein Veränderungslernen. Der Betrieb des wissensbasierten
Informationssystems führt zu einem Anpassungslernen der Systemnutzer, da sie mit Hilfe der
dokumentierten Wissensressourcen und der Prozessintegration des Systems in die Lage versetzt
werden, die Problemstellungen im Prozess aufzunehmen und zu lösen. Die Tatsache, dass sich
das Unternehmen mit der Implementierung eines wissensbasierten Informationssystems befasst,
zeigt die Ausprägung eines Prozesslernens. Die eigenen, z.T. „eingefahrenen“ Strukturen
SEITE 82 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
werden hinterfragt und mit Hilfe des Softwaresystems sowie den Ansätzen des
Wissensmanagements aufgebrochen und neu strukturiert. Der Vorteil in dieser Vorgehensweise
zur Systemimplementierung und späteren Nutzung kann in der Berücksichtigung der
organisationalen Lernmodelle gesehen werden und bedeutet eine Erhöhung der organisationalen
Wissensbasis.
Die lernende Organisation hat, wie in Kapitel 3.2.2 dargestellt die Eigenschaft ein stetiges „Ru-
dern gegen den Strom“ zu erfordern. Durch die Zielsetzung und abteilungsübergreifende Imple-
mentierung und Nutzung des wissensbasierten Informationssystems werden die lernfördernden
Faktoren Information, Kommunikation sowie die gemeinsame Vision nachhaltig gestärkt. Eine
Vertrauensbasis wird dadurch aufgebaut, dass die Mitarbeiter im Rahmen der Projektarbeit die
Ziele des Wissensmanagements vermittelt bekommen und gemeinsam das von ihnen später
selbst genutzte Informationssystem aufbauen. Im Zuge dieser Optimierung werden bewusst die
genannten Defizite im Umgang mit der Ressource Wissen (vergleiche Kapitel 3.2.3) beseitigt.
Daraus können viele positive Effekte resultieren wie beispielsweise:
• die Einarbeitung von Mitarbeitern wird durch die für jeden Prozess erarbeitete
Wissensbasis beschleunigt,
• die Wiederholhäufigkeit von Fehlern wird durch die gezielte Anwendung von
Erfahrungswissen vermindert und
• die Entwicklung neuer Vorgehensweisen wird durch die Verbreitung des Wissens
einzelner Wissensträger aktiviert.
Die Ergebnisse sind insgesamt umso besser, je mehr die lernhemmenden Faktoren wie Abtei-
lungsegoismus oder mangelnde Kooperation durch die integrative Vorgehensweise der Sys-
temimplementierung zurückgedrängt werden können.
5.1.4 Motivation der Systemnutzer
Die Aufgabe der Erzeugung von Motivation ist bei wissensorientierten Projekten ein elementarer
Bestandteil, der bei Standardsoftwareprojekten in dem Ausmaß nicht zu finden ist. Die
Abbildung 41 zeigt einen Überblick der Ängste und Motivationsfaktoren, die die Hinführung zu
dem Leitsatz darstellen.
Vor allem auf die Notwendigkeit der Wissensteilung und der Schaffung einer gemeinsamen
Vertrauensbasis muss immer wieder hingewiesen werden. Der Umgang und der Austausch von
Wissen ist in Unternehmen ein schwieriges Thema, da von den Mitarbeitern mit solchen Ideen
regelmäßig Nachteile wie Wissensverlust, Machtverlust, Kontrollverlust usw. verbunden wer-
den. Nutzungsbarrieren beruhen oft auf eigener Selbstüberschätzung oder der Angst vor dem
Verlust des eigenen Expertenwissens bzw. der Expertenstellung [PRRo03, S. 177]. Daraus kann
sich eine Vermeidungs- und Blockadehaltung entwickeln, die verhindert, dass das zu implemen-
tierende wissensbasierte Informationssystem angenommen und genutzt wird.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 83
„Betroffene zu Beteiligten machen!“
Machtverlust
Kontrollverlust Wissensverlust
Verlust der
Experten-
stellung
Einbeziehen
bei der
Prozess-
analyse
Befriedigung
des Selbst-
entfaltungs-
bedürfnisses
Mitgestaltung
des Systems
durch die
Mitarbeiter
Umsetzung
von
Mitarbeiter-
vorschlägen
: Ängste der Mitarbeiter
: Reaktionen auf die Ängste im Rahmen der Implementierung
-
+
Quelle: Verfasser
Abbildung 41: Ängste der Mitarbeiter und die Reaktion darauf im Rahmen der Implementierung
Das Implementierungsmodell verfolgt die Strategie, durch eine starke Integration der Mitarbeiter
eine intrinsische Eigenmotivation zu erzeugen. Diese Aussage lässt sich in folgendem Leitsatz
zusammen fassen:
„Die Betroffenen zu Beteiligten machen!“
Die Kernaussage bedeutet, es wird nicht wie bei der Implementierung ein ausgestaltetes Soft-
waresystem mit einigen Kundenanpassungen implementiert, sondern ein Gerüst eines wissensba-
sierten Informationssystem wird mit den Mitarbeitern gemeinsam zu einem Unterstützungsme-
dium weiter entwickelt. Die Betroffenen werden schon bei der Analyse ihres Arbeitsbereichs
bzw. der Prozesse, die sie bearbeiten, einbezogen. Dadurch wird einerseits das Grundbedürfnis
nach Selbstentfaltung [Rose01, S. 114] angesprochen und andererseits erhalten die Mitarbeiter
ein Bewusstsein dafür, wie und in welchem Kontext sie selbst arbeiten und wo Möglichkeiten für
Optimierungen durch den Einsatz eines wissensbasierten Informationssystem liegen.
Im nächsten Schritt können die Mitarbeiter den Inhalt und die grafische Oberfläche des Systems
mit entwerfen, so dass sie bei der späteren Nutzung ihre eigenen Vorschläge und Ideen in umge-
setzter Form wiederfinden. Diese Autonomie der Mitarbeiter gilt in der Motivationsforschung
zum einen als Möglichkeit zur Stärkung des Selbstwertgefühls und zum anderen zur Erzeugung
eines Erlebnisses, das den Mitarbeitern besagt, dass sie nicht einfluss- und bedeutungslos sind
[Nerd03, S. 24].
Die erzeugte intrinsische Arbeitsmotivation, also die Motivation zur Teilung des persönlichen
Wissens, ist in einer solchen selbst gestalteten Umgebung als deutlich höher anzunehmen
SEITE 84 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
[Nerd03, S. 24]. Gleichzeitig lassen sich unterschiedliche Meinungen in einem frühen Stadium
zu einer konstruktiven Lösung zusammenführen, die alle Beteiligten zufrieden stellt. Konflikte
können durch den Test verschiedener Lösungen beseitigt werden oder es wird einer der Aspekte
priorisiert. In jedem Fall kann mit der frühzeitigen Konfliktbereinigung eine teure Nacharbeit zu
einem späteren Zeitpunkt vermieden werden.
Diese Vorgehensweise wird zunächst in einem Pilotprozess umgesetzt, wobei nach der Test-
phase die Option besteht, eventuelle Nachbesserungen vorzunehmen. Es ist das Ziel, diese Pi-
lotimplementierung zu einem Erfolg zu führen und entsprechend zu dokumentieren. Das er-
leichtert die Ausweitung der Systemanwendung insofern, als die Motivation für die nun folgend
einbezogenen Mitarbeiter dem folgenden Leitsatz genügen sollte:
„Die beste Motivation ist der positive Erfahrungsbericht eines Kollegen.“
Jede Organisation verfügt über unsichtbare Kommunikationsstrukturen, die nicht den offiziellen
Wegen folgen. Diese können in Form von Pausengesprächen, privaten Kontakten oder Diskus-
sionen im Umfeld von Besprechungen ausgeprägt sein. Gelingt es, von dem Implementierungs-
projekt ein positives Bild zu erzeugen, so ist eine Motivationssteigerung zu erwarten, da jeder
gern an erfolgreichen Projekten mitarbeitet. Dabei spielt auch die Bedeutsamkeit der Aufgabe
für sich und andere eine wesentliche Rolle, da die Mitarbeiter dann besonders motiviert sind,
wenn die Arbeitsergebnisse anderen nützen können [Nerd03, S. 24]. Dieses positive Bild entsteht
primär dann, wenn das wissensbasierte Informationssystem den Nutzern einen Mehrwert bei
ihrer täglichen Arbeit bringt. Das kann eine Zeitersparnis oder aber auch ein „angenehmeres“
Arbeiten sein. Daneben ist auch die Projektdurchführung entscheidend, wobei ein freundlicher
Umgangston vorherrschen und jede Form von Kritik ernst genommen werden muss.
Zur Förderung der Motivation kommen auch Anreizsysteme in Frage. Im ersten Moment liegt
der Anreiz über die Entlohnung am nächsten, was sich allerdings nur bei Unternehmen anbietet,
die ein Entgeltsystem mit einem variablem Leistungsanteil anwenden oder persönliche Zielver-
einbarungen pflegen. Die Motivationssteigerung über die monetäre Komponente ist jedoch nur
eine von vielen Möglichkeiten. Als wichtige Arbeitsmotive gelten auch das Bedürfnis nach
Selbstverwirklichung und die Anerkennung [Rose01, S. 70]. Daher können auch kleine und nicht
monetäre Gesten einen Mitarbeiter zu mehr Leistung motivieren.
PROBST/RAUB/ROMHARDT [PRRo03, S. 44] merken richtig an, dass es unerlässlich für die Wir-
kung der Maßnahmen ist, dass die Anreizmechanismen, die eine steuernde Wirkung auf das
Verhalten der Mitarbeiter ausüben, in Einklang mit den wissensorientierten Zielen des Unter-
nehmensleitbildes stehen. Weiter müssen sich alle Motivations- und Anreizsysteme an den per-
sönlichen Bedürfnissen der Mitarbeiter ausrichten [PRRo03, S. 198]. Hier ist eine vorherige
Abstimmung vorzunehmen.
5.1.5 Der wissensorientierte Implementierungsprozess
Die vorigen Ausführungen dieses Kapitels zeigen, dass die Beachtung der Wissensmanagement-
Ansätze in jeder Phase der Implementierung eine entscheidende Rolle spielt. Nur wenn viele
kleine Teile ineinander greifen und in die Organisation implementiert werden, lassen sich die
Potenziale eines wissensbasierten Informationssystems voll ausschöpfen.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 85
Es muss von vornherein das Bewusstsein kommuniziert werden, dass nur das Informations-
system und dessen Nutzungsstatistik als Ergebnis direkt sichtbar ist. Die Forcierung der Wis-
sensteilung und die Stärkung der organisationalen Wissensbasis etwa sind zwar ebenso ein Re-
sultat des Implementierungsprojekts, bleiben aber überwiegend im Verborgenen. Der Implemen-
tierungsprozess schafft die Voraussetzungen, dass gerade die entscheidenden wissensintensiven
Prozesse schneller und gezielter durchgeführt werden können.
Die herkömmlichen Werkzeuge des Wissensmanagements stellen ebenso wie die Wissens-
management-Software allein nur isolierte Instrumente dar, die ihre Wirksamkeit schwer entfalten
können. Mit Hilfe der Implementierung lassen sich viele der in Kapitel 3 angesprochenen
Wissensmanagement-Funktionen in einem wissensbasierten Informationssystem zusammen-
fassen und auf die Erfordernisse spezieller Prozesse abstimmen. Ein Teil der Wissensorientie-
rung im Implementierungsmodell besteht in der Einbindung des Softwareherstellers als strategi-
schen Entwicklungspartner, da nur auf diese Weise eine unternehmensspezifische Anpassung
möglich wird.
Ebenso werden personalorientierte Methoden des Wissensmanagements durch die Einbindung
der Mitarbeiter und die Ausrichtung auf die Sozialisation des wissensbasierten Informationssys-
tems angewendet, obwohl im Projekt eine Software vordergründig sichtbar ist. Zusammen mit
den Mitarbeitern wird eine klassische „win-win-Situation“ erzeugt, da sie sich selbst weiter
entwickeln können, aber auch das Unternehmen eine Prozessverbesserung und damit eine Stär-
kung seiner Leistungsfähigkeit gewinnt. Dabei kann das Ziel auch in dem Aufbrechen von unge-
schriebenen, kontraproduktiven Verhaltensweisen liegen, beispielsweise durch die direkte An-
sprache und Einbindung bestimmter Mitarbeiter in das Projekt.
5.2 Projektaufbau und Start des Implementierungsvorhabens
In diesem Teilkapitel werden die in der Abbildung 42 grau hinterlegten Bausteine des Implemen-
tierungsmodells behandelt. Diese Teile betreffen die Vorarbeiten zur Implementierung, die aus
einer klaren Zieldefinition und dem Start des Projekts bestehen.
Im Rahmen der projektorientierten Vorgehensweise zur Implementierung des wissensbasierten
Informationssystems wird Bezug genommen auf die in Kapitel 4.2 dargelegte Vorgehensweise
für Standardsoftware-Einführungen. Die grundlegende Strukturierung des Projekts wird über-
nommen, wobei die konkrete Ausgestaltung immer vor dem Hintergrund einer wissensorientier-
ten Vorgehensweise und den dabei zu beachtenden Besonderheiten erfolgt.
Die Zieldefinition ergibt sich aus der Vorstudie, die möglicherweise schon zur Auswahl des
wissensbasierten Informationssystems geführt hat und aus den Eigenschaften des geplanten
wissensbasierten Informationssystems selbst. Daneben sind frühzeitig die Projektstrukturen im
Sinne einer Benennung von Mitgliedern des Projektteams und einer Strukturierung der Projekt-
aufgaben anzulegen. Das Projektmanagement bildet das zentrale Steuerungsinstrument über die
gesamte Projektlaufzeit.
SEITE 86 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
Phasenkonzept zur prozessualen Integration
des wissensbasierten Informationssystems
Mitarbeiterorientiertes
Change Management
Anpassung des Softwaresystems
Langfristige Erfolgssicherung
Kick-off des Projekts
Zieldefinition
Wissensmanagement als Basis
P r o j e k t m a n a g e m e n t
Quelle: Verfasser
Abbildung 42: Projektstruktur des Implementierungsmodells
Ein Projekt ist per Definition auf eine endliche Zeitdauer ausgelegt (vergleiche 4.2.1). Insofern
erscheint die zum Ende hin offene Gestaltung des Implementierungsprojekts in Abbildung 42
zunächst irritierend. Dadurch wird symbolisiert, dass die Optimierung des Umgangs mit Wissen
in einem Unternehmen niemals als abgeschlossen betrachtet werden darf, auch wenn die zuvor
festgelegten Projektziele erreicht wurden. In den übergeordneten Unternehmenszielen muss eine
visionäre Komponente integriert werden, die eine Richtung aufzeigt, wie das Unternehmen in
Zukunft mit der Ressource Wissen umgehen soll. Sie ist aber als solche noch kein Inhalt des
aktuellen Implementierungsprojekts, da sie zu weitreichend formuliert ist. Selbstverständlich ist
die Zieldefinition des Implementierungsvorhabens bzw. die Projektaufgabe so zu beschreiben,
dass sie in einem absehbaren Zeitraum abgearbeitet werden kann.
5.2.1 Definition von Zielen
Die Definition von Zielen gibt dem Projekt einen Leitfaden, aus dem alle weiteren Aufgaben und
Abläufe abgeleitet werden. Die Zieldefinition ist bei Standardsoftwareprojekten noch relativ
einfach und wird regelmäßig durchgeführt (vergleiche Kapitel 4.2), da meist innerhalb einer
bestimmten Zeit eine Anzahl Funktionsgruppen einer Standardsoftware in einem Unternehmen
integriert sein müssen. Eine solche Festlegung ist bei der Implementierung wissensbasierter
Informationssysteme schwieriger. Prinzipiell bilden die Prozesse der Zieldefinition im Wissens-
management den Anfang [PRRo03, S. 37]. Die Zielsetzung muss nicht nur die technische In-
stallation des Softwaresystems abdecken, sondern vor allem dem anspruchsvollen wissensorien-
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 87
tierten Implementierungsprozess eine Leitlinie geben. Auch die Verankerung des Ansatzes der
ständigen Weiterentwicklung des wissensbasierten Informationssystems findet in den Zielen
Niederschlag. Aus diesen Gründen bietet sich eine mehrdimensionale Zieldefinition an, die sich
aus den übergeordneten Unternehmenszielen ableitet und somit in der Organisation fest veran-
kert ist. Als wesentliche Eigenschaft müssen die Ziele sinnvoll und realistisch definiert sein
[PRRo03, S. 128]. Die Abbildung 43 zeigt für das Implementierungsmodell die mehrstufige
Ableitung der Projektziele aus den Unternehmenszielen.
Unternehmensziele
strategisch/langfristig
taktisch/mittelfristig
operativ/kurzfristig
Projektziele
-leicht verständlich
- geeignet für Controlling
Quelle: Verfasser
Abbildung 43: Ableitung mehrstufiger Projektziele aus den Unternehmenszielen
Die Unternehmensziele geben eine langfristige Vision an, die das Handeln aller Mitarbeiter
leitet. Das kann beispielsweise eine Aussage zur Entwicklung der Unternehmenskultur sein, wie:
„Wir bauen mit Hilfe einer vertrauensvollen Wissensteilung und Zusammenarbeit eine Wissens-
kultur in unserem Unternehmen auf!“ Wenn das Unternehmen noch keine Unternehmensziele
definiert hat, oder noch keine wissensorientierten Zielsetzungen ausgegeben hat, so ist vor dem
Start des Implementierungsprojekts eine solche Leitlinie zu entwerfen. Geschieht dies nicht, ist
die Gefahr gegeben, dass sich die wissensbasierte Arbeitsweise nicht durchsetzen kann.
Aus der Vision können für das Implementierungsprojekt strategische, langfristig orientierte
Zielsetzungen abgeleitet werden. Diese dürfen einen visionären Charakter haben, da ein ideali-
siertes Ergebnis des Implementierungsprozesses vorweg genommen wird und je nach Projektum-
fang ein Zeitraum von mehreren Jahren abgedeckt wird. Als Beispiele für diese langfristigen
Ziele der Implementierung können folgende Aussagen gelten:
• Etablierung einer wissensorientierten Arbeitsweise unter Verwendung des
wissensbasierten Informationssystems,
• alle Mitarbeiter beteiligen sich an der kollektiven Wissensteilung,
• Akzeptanz des wissensbasierten Informationssystems durch alle Mitarbeiter,
• kontinuierliche Weiterentwicklung des wissensbasierten Informationssystems mit dem
Softwarehersteller als strategischen Partner,
• Verbesserung der Geschäftsprozesse durch den Einsatz von Wissensmanagement.
In einem zweiten und dritten Schritt werden diese langfristigen Ziele auf eine mittel- und kurz-
fristige Sicht heruntergebrochen. Hierbei bietet sich die Möglichkeit, je nach Umfang des
SEITE 88 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
Implementierungsprojekts eine Skalierung vorzunehmen. Ist ein sehr umfangreiches Projekt
geplant, so ist die Abstufung aus kurz- und mittelfristiger Sicht sinnvoll. Wenn nur eine Erpro-
bung des wissensbasierten Informationssystems stattfindet, kann auf diese erneute Unterteilung
verzichtet werden. Wichtig ist, dass aus den Zielen der kurzfristigen Sicht einzelne Teilaufgaben
zur Erreichung des entsprechenden Ziels ableitbar sind. Analog zu den Vorgehensweisen bei der
Implementierung von Standardsoftware (vergleiche Kapitel 4.5.3) werden die Ziele den Meilen-
steinen der Projektstruktur zugeordnet. Insbesondere die zuerst zu erreichenden Teilziele müssen
so aufgebaut sein, dass sie mit sehr großer Wahrscheinlichkeit erfolgreich abgeschlossen werden.
Diese ersten Erfolge dienen der Motivationssteigerung aller am Projekt beteiligten Mitarbeiter,
was gerade im Hinblick auf die Bereitschaft zur Teilung von Wissen besonders wichtig ist. Zur
besseren Verständlichkeit und Übersichtlichkeit muss darauf geachtet werden, die Teilziele
griffig und leicht verständlich zu formulieren. Als Beispiele für die Gruppe der kurz- und mittel-
fristigen Ziele kommen diese Aussagen in Betracht:
• In der Pilotphase wird der Unternehmensbereich „Fertigung“ unterstützt.
• In einer ersten Ausbaustufe sollen 25 Nutzer an das wissensbasierte
Informationssystem angebunden werden.
• In einer zweiten Ausbaustufe steht das wissensbasierte Informationssystem weiteren 50
Nutzern zur Verfügung.
• Alle Systemnutzer beteiligen sich aktiv an der Wissensteilung.
• Das wissensbasierte Informationssystem wird mit fünf Features eingeführt.
• Je Betriebsjahr werden für das wissensbasierte Informationssystem drei weitere
Funktionen entwickelt.
Aus den Zieldefinitionen müssen später im Verlauf des Projekts nachvollziehbare bzw. über-
prüfbare Größen entwickelt werden. Diese kurzfristigen (Wissens-)Ziele sichern die Umsetzung
auf der operativen Ebene und ermöglichen eine gezielte Intervention [PRRo03, S. 52]. Die Ziele
müssen generell im Rahmen der Erfolgsmessung messbar sein [ÖsWi03, S. 376]. Beispielsweise
lässt sich die Beteiligung der Nutzer an der Wissensteilung in einer Anzahl von neuen Einträgen
im wissensbasierten Informationssystem überprüfen. Dabei ist darauf zu achten, gerade die
wissensorientierten Zielsetzungen nicht mit monetären Messgrößen zu belegen, da diese keinen
geeigneten Maßstab bilden und das Bild verzerren können. Über den Zielerreichungsgrad ist
regelmäßig zu berichten.
Die exakten Zielsetzungen sind für jedes Implementierungsprojekt individuell zu entwickeln.
Die an dieser Stelle genannten Ziele sind als Richtlinie oder Anregung zu verstehen. Die Ziele
sind im Unternehmen und Projektteam geeignet zu kommunizieren und müssen eine realistische
Erwartungshaltung darstellen. Zu hohe Zielsetzungen führen schnell zu Enttäuschungen, die
durch die folgende Demotivation das Projekt gefährden können.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 89
5.2.2 Aufgaben des Projektmanagements
Projekt in Teilaufgaben
strukturieren
Lenkungsausschuss
bilden
Projektauftrag formulieren
Projektleiter intern/extern
benennen
Projektorganisationsform
festlegen
Kick-off kontinuierliche Aufgaben
einmalige Aufgaben
Koordination interner/externer Arbeiten
Reporting der Ergebnisse
Koordination des Projektteams
Kommunikationsförderung
: Durchführung der Aufgabe obliegt dem Management des Unternehmens
: Durchführung der Aufgabe obliegt dem Projektleiter
: Durchführung der Aufgabe obliegt dem Projektleiter
Quelle: Verfasser
Abbildung 44: Aufgaben des Projektmanagements im Implementierungsprojekt
Das Projektmanagement bildet die kontinuierliche Steuerungsinstanz während des Implementie-
rungsvorhabens. Die Steuerungsaufgaben sind analog zu den in Kapitel 4.2 vorgestellten Aufga-
ben bei Standardsoftware-Implementierungen zu sehen. Die Aufgaben bei der wissensorientier-
ten Vorgehensweise sind als komplexer einzustufen, da sie mehr Feingefühl für die Durchfüh-
rung der Veränderung verlangen. Diese Aufgabe wird dem Projektleiter übertragen, der für deren
Ausführung verantwortlich ist. Aufgrund der hohen Anforderungen arbeitet der Projektleiter
möglichst Vollzeit an dem Projekt und ist fachlich mit den Themengebieten des Wissensmana-
gements und Projektmanagements vertraut. Es sind generell Aufgaben zu unterscheiden, die vor
dem Start des Projekts einmalig und während der Projektlaufzeit kontinuierlich abgearbeitet
werden müssen. Eine Übersicht hierzu zeigt die Abbildung 44.
Die vorbereitenden einmaligen Aufgaben sind bei Implementierungsvorhaben wissensbasierter
Informationssysteme besonders wichtig, da von Beginn an eine konsequente Vorgehensweise
erforderlich ist, die einen Willen zur nachhaltigen Einführung einer wissensorientierten Vorge-
hensweise gegenüber allen Mitarbeitern ausstrahlt. Das beinhaltet auch die konsequente Förde-
rung durch das Top-Management sowie die zügige Benennung eines Projektleiters und Bildung
eines Lenkungsausschusses. Der Projektleiter übernimmt alle weiteren in Abbildung 44 genann-
ten Aufgaben. Vor allem im Vergleich zu einer Standardsoftwareeinführung ist die Bedeutung
dieser Pflichten hervorzuheben, da das wissensbasierte Informationssystem nicht von einem Tag
SEITE 90 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
auf einen anderen ein Altsystem ersetzt, sondern vielmehr langsam in das Bewusstsein der Orga-
nisation vorrücken muss.
Dazu ist vor dem Kick-off (vergleiche Phasenkonzept zur Standardsoftware in Kapitel 4.3.2) ein
Lenkungsausschuss mit Personen aus dem Top-Management zu besetzen, die das Projekt befür-
worten und durch regelmäßige Präsenz bei Projektgesprächen zeigen, dass sie an dem Erfolg der
Implementierung ernsthaft interessiert sind. Die Erarbeitung eines Vorschlags zur Strukturierung
des Projekts obliegt dem Projektleiter. Diese Person wird bereits zu dem Zeitpunkt benannt, an
dem die Idee für das Projekt geboren wird. Er sorgt für die vorbereitenden Arbeiten vor dem
Kick-off und steuert in der Folgezeit die Einhaltung des vorgegebenen Rahmens. In einer Analo-
gie zu WELTI [Welt99, S. 21ff.] und den in Kapitel 4.2 aufgezeigten Vorgehensweisen bei
Projekten erscheint es zur Erzielung flacher Hierarchien und möglichst kurzer Kommunika-
tionswege sinnvoll, ebenso einen Projektleiter bei dem Softwarehersteller zu benennen. Er fun-
giert als erster Ansprechpartner und Schnittstelle zur Systementwicklung in dessen Haus.
Im Vergleich zur Einführung einer Standardsoftware (Kapitel 4.3) ist der Projektauftrag nicht so
zu formulieren, dass das Softwaresystem bestimmte zuvor bekannte Funktionsumfänge enthalten
soll. Es sind interne und externe Aufgaben von vornherein zu unterscheiden. Das interne Pro-
jektteam bekommt einen Auftrag, der die Überprüfung der Prozesse auf die Unterstützungsmög-
lichkeiten durch das wissensbasierte Informationssystem fordert. Erst bei diesen Untersuchungen
lässt sich feststellen, inwieweit ein Einsatz der Software sinnvoll ist. Haben einige Prozesse eine
sehr geringe Wissensintensität, so ist die Softwareeinführung im Vergleich zu dem zu erwarten-
den Ergebnis zu aufwändig. Bei der Durchführung dieser Aufgabe kann der Softwarehersteller
mit seinem gesammelten Know-how unterstützen. Die Arbeiten zur Anpassung der Software auf
die Ergebnisse der Prozessuntersuchungen gemäß dem daraus folgenden Lastenheft werden
ausschließlich unternehmensextern vom Softwarehersteller durchgeführt.
Analog zur Implementierung einer Standardsoftware ist ein Projektstrukturplan (vergleiche
Kapitel 4.2.1) zu erstellen, der die Gesamtaufgabe in Teilaufgaben gliedert. Da es sich um eine
offene Vorgehensweise handelt, sind die Aufgaben nur über einen Zeithorizont bis zum ersten
Piloteinsatz des wissensbasierten Informationssystems exakt abzuschätzen. Je nach Ergebnis
dieser Pilotphase und je nach ausgewähltem Bereich zur Fortführung des Einsatzes können die
weiteren Aufgaben differieren. Eine Prognose ist in jedem Fall aufzustellen und regelmäßig
anzupassen, wenn neue Erkenntnisse über den weiteren Projektverlauf vorliegen.
Die Organisationsform des Projekts muss so gewählt werden, dass die internen Projektmitarbei-
ter in jedem Fall ihren angestammten Abteilungen erhalten bleiben, damit sie sich gedanklich
nicht zu weit von der Ausführung der Prozessaufgaben entfernen. Analog zu Standardsoftware-
projekten kann die Organisationsform bei dem extern arbeitenden Softwarehersteller nicht vor-
geschrieben werden, wobei der Einsatz der Mitarbeiter in Vollzeit wünschenswert ist. Dies lässt
sich nur bei einem entsprechend großen Auftragsumfang realisieren. Auf diese Weise sind je-
doch feste Ansprechpartner definiert und eine Konstanz im Projekt zu erwarten. Gleichzeitig
muss eine große Offenheit und ein hohes Vertrauensniveau gegenüber den Mitarbeitern des
Softwareherstellers bestehen, da sie tiefe Einblicke in die Prozesse und die Organisation des
Unternehmens erhalten und diese nicht missbrauchen dürfen.
Nach der Kick-off-Veranstaltung, dem offiziellen Start des Implementierungsprojekts, müssen
im Rahmen des Projektmanagements vom Projektleiter einige Aufgaben kontinuierlich wahrge-
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 91
nommen werden. In erster Linie ist die klassische Projektmanagementaufgabe wie der Koordi-
nation und Steuerung der Abarbeitung der Teilaufgaben sowie die Koordination der Projekt-
teammitglieder zu nennen. Analog zu den Projekten bei der Einführung von Standardsoftware ist
er dafür verantwortlich, dass die Projektteammitglieder zu den vereinbarten Zeitpunkten die
Ergebnisse der Teilaufgaben vorlegen. Sollten Terminabweichungen auftreten, so muss er diese
rechtzeitig erkennen und mögliche Gegenmaßnahmen wie beispielsweise den Einsatz zusätz-
lichen Personals einleiten.
Bei dieser wissensorientierten Vorgehensweise ist in besonderem Maße die Kommunikation zu
fördern. Das gilt sowohl für die Projektteammitglieder intern, als auch für den Austausch mit
dem externen Partner. Wenn möglich, sollte das Vorhaben nach ersten Teilerfolgen im größeren
Kreis im Unternehmen bekannt gemacht werden, damit erstens eine Sensibilität für Wissens-
fragen entsteht und zweitens eine erste Form des Projektmarketings betrieben wird. Ziel dieses
Vorgehens ist es, Mitarbeiter später schneller begeistern zu können, wenn auch in ihrem Bereich
das wissensbasierte Informationssystem eingeführt werden soll. Dieser Prozess wird durch das
Change Management begleitet, das in Kapitel 5.4 weiter erläutert wird.
Im Rahmen dieser sehr offenen Vorgehensweise ist ein regelmäßiges Reporting von Teilergeb-
nissen sicherzustellen. Es können weite Teile des Unternehmens in die Thematik eingebunden
werden, wobei eine stetige Information aller Beteiligten Transparenz schafft, so dass Ideen
angeregt werden und das Interesse erhalten bleibt. Das Vorgehen ist auch dadurch zu fördern,
dass die Projektleitung mit einem guten Beispiel vorangeht und ihr Wissen genauso teilt, wie sie
es von den Mitarbeitern erwartet. Geschieht dies nicht, kann eine Blockadehaltung der Mitar-
beiter die Folge sein. Das Implementierungsprojekt kann in diesem Fall als auf lange Sicht ge-
scheitert angesehen werden, da eine erneute Motivation nur schwer bis gar nicht zu erzeugen ist.
5.2.3 Durchführung einer Kick-off Veranstaltung
Die Kick-off-Veranstaltung bildet den offiziellen Startpunkt für das Implementierungsprojekt.
Sämtliche Vorbereitungsarbeiten müssen bis zu diesem Zeitpunkt abgeschlossen sein, wie insbe-
sondere die Auswahl eines Softwarelieferanten als strategischen Entwicklungspartner. Zusätzlich
hat die Projektleitung einen Entwurf erarbeitet, wie das Projekt strukturiert und organisiert wird.
Dazu gehört auch die Durchführung von vorbereitenden Gesprächen mit den zukünftigen Pro-
jektteammitgliedern, in denen das Interesse und der Kenntnisstand in Bezug auf Wissensmana-
gement zu erfragen ist. Daraus können bereits Rückschlüsse auf die notwendige Schulungsinten-
sität und die Verteilung einzelner Aufgaben geschlossen werden. Die Projektleitung muss bereits
bei diesen Gesprächen versuchen, die Mitarbeiter von dem Vorhaben zu begeistern und ihr
Interesse und ihre Eigenmotivation zu wecken.
An der Kick-off Veranstaltung nehmen alle am Projekt beteiligten Mitarbeiter teil und erhalten
umfassende Informationen über das Vorhaben selbst sowie über die vorgesehene Verteilung der
geplanten Aufgaben. Der Teilnehmerkreis umfasst mindestens den in Abbildung 45 dargestellten
Personenkreis.
SEITE 92 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
Teilnehmer
am
Kick-off
Projektleiter
intern
Projektleiter
extern
Mitarbeiter
Pilotbereich
Abteilungsleiter
Pilotbereich
Vertreter
Management
Mitarbeiter
Pilotbereich
Vertreter
Betriebsrat
Mitarbeiter
extern
: unternehmensexterne Mitarbeiter
: unternehmensinterne Mitarbeiter aus dem Pilotbereich
: unternehmensinterne Führungsfunktionen
Quelle: Verfasser
Abbildung 45: Teilnehmer an der Kick-off-Veranstaltung
Die persönliche Anwesenheit des Managements ist in dieser Veranstaltung entscheidend, da
damit ein besonderes Interesse und die Förderung der Idee der wissensorientierten Arbeit doku-
mentiert werden kann. Bei Unternehmen, die sich zuvor nicht mit einer solchen Thematik aus-
einander gesetzt haben, ist die Beteiligung der Geschäftsführung sogar als unerlässlich zu be-
zeichnen. Der Vertreter des Managements beginnt die Veranstaltung mit einigen einführenden
Worten und stellt den Softwarehersteller als Entwicklungspartner vor, der im Rahmen der Vor-
studie aus mehreren Anbietern ausgewählt wurde. Der Softwarehersteller ist seinerseits mit dem
Projektleiter und einem oder mehreren hauptamtlich mit dem Projekt betrauten Mitarbeitern vor
Ort. Die Beteiligten können sich untereinander kennen lernen und wissen, wer auf der jeweils
anderen Seite der Ansprechpartner ist.
Weiterhin ist die Einbeziehung der Arbeitnehmerseite durch einen Vertreter des Betriebsrats von
Beginn an sehr bedeutend. Bei der Implementierung von wissensbasierten Informationssystemen
können wie bei einer Standardsoftwareeinführung gemäß Kapitel 4.2 Mitarbeiterrechte berührt
werden. Dies kann bereits darin begründet sein, dass die Mitarbeiter ihr Wissen zugänglich
machen und prinzipiell eine Auswertung dieses Wissens über das Informationssystem möglich
sein könnte. Zur Vermeidung von späteren Diskussionen oder sogar einem Stopp des Projekts
durch den Betriebsrat ist dieser zu allen Informationsveranstaltungen mit einzuladen und über
den Fortgang des Projektes und die Systementwicklung zu unterrichten. Einwände gegen ein-
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 93
zelne Features des Systems können auf diese Art sofort besprochen und geklärt werden. Das ist
auch aus Kostensicht zu begrüßen, da Änderungen zu einem späteren Zeitpunkt immer größere
Kosten nach sich ziehen. Bei diesem Vorgehen kann auch die Chance genutzt werden, den Be-
triebsrat für die Fragestellungen des Wissensmanagements zu begeistern und dadurch die Mög-
lichkeit für Folgeprojekte zu schaffen.
Die Benennung der Teilnehmer erfolgt durch das Projektmanagement, das gemäß seiner in Ka-
pitel 5.2.2 beschriebenen Aufgaben bereits vor dem Kick-off Voruntersuchungen durchgeführt
hat und dabei geeignete Personen identifiziert hat. Aus dem für einen Pilotbetrieb geeigneten
Bereich sind der Abteilungsleiter sowie weitere Mitarbeiter zur Kick-off-Veranstaltung einzula-
den. Die Anzahl der Personen variiert je nach Größe des Unternehmensbereichs. Je Arbeits-
gruppe ist nach Möglichkeit mindestens ein Mitarbeiter anwesend.
Inhaltlich erläutert der Projektleiter zunächst die Ziele und die Vorgehensweise der Projekt-
durchführung. Dazu hat er einen Projektstrukturplan und einen Zeitplan vorbereitet. Sinnvoll ist
es, die Teilaufgaben des Projekts zuvor mit den Projektmitarbeitern durchzusprechen und even-
tuelle Unklarheiten oder Unwägbarkeiten auszuräumen. In diesem Zusammenhang kann auch
eine Abstimmung der Termine im voraus vorgenommen werden, damit das Projekt später im
Zeitrahmen bleibt.
Neben den rein sachlichen Inhalten und den Zielsetzungen des Projekts ist die verfolgte Vision
zu kommunizieren. Dadurch sind die Teilnehmer der Veranstaltung für die vollständige Umset-
zung einer wissensintensiven Arbeitweise als Fernziel zu sensibilisieren. Es ist nicht zu erwarten,
dass alle Teilnehmer den Ansatz sofort nachvollziehen und umsetzen können. Aber durch die
folgenden Maßnahmen und eine offenen Arbeitsweise innerhalb des Projektteams ist es die
Zielsetzung, mit der Kick-off Veranstaltung den Start zu geben, die Idee der Wissensteilung
allmählich über die Pilotabteilung und die anschließend einbezogenen Unternehmensbereiche in
der Unternehmenskultur zu verankern. Dazu gehört auch die Benennung fester Ansprechpartner
von Beginn an, die bereitwillig über alle Fragestellungen Auskunft geben.
5.3 Das Implementierungsprojekt als Phasenkonzept
Die Implementierung des wissensbasierten Informationssystems muss systematisch und nach-
haltig erfolgen. Für Standardsoftwareprojekte werden dabei wie in Kapitel 4.3.2 regelmäßig
Phasenkonzepte herangezogen. Aufgrund der Wirkung einer Strukturierung soll auch für dieses
Implementierungsmodell wissensbasierter Informationssysteme eine ähnliche Strukturierung
vorgenommen werden. Dabei wird, wie bereits dargestellt, nicht nur das primäre Ziel der tech-
nischen Integration der Software verfolgt. Es ist eine Begeisterung der Mitarbeiter für eine Wis-
sensteilung und wissensorientierte Unterstützung ihrer Arbeitsprozesse zu schaffen. Eine plötz-
liche Einführung (vergleiche Big-Bang-Strategie bei der Einführung von Standardsoftware,
Kapitel 4.3.1) scheidet daher aus, da der wissensorientierte Veränderungsprozess Zeit benötigt
und über einen großen Unternehmensbereich schwer zu steuern ist. Es bietet sich eine phasen-
weise Einführung „step by step“ an, die eine kontinuierliche Anpassung der Mitarbeiter und eine
stetige Weiterentwicklung des Softwaresystems erlauben. Die grau eingefärbten Flächen in
Abbildung 46 zeigen die in diesem Kapitel angesprochenen vier Phasen des Implementierungs-
SEITE 94 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
modells. Diese vierstufige Vorgehensweise ist als Kernprozess zu betrachten, nach dessen
Fortgang die Begleitprozesse gesteuert wird.
Eine wesentliche Voraussetzung zur Durchführung des Implementierungsmodells ist eine kon-
stante Personalpolitik in den involvierten Abteilungen. Ein reger Personalwechsel verursacht viel
Unruhe, einen zu hohen Einarbeitungsaufwand, große Vertrauenseinbußen und die in Wissens-
fragen bereits angelernten Mitarbeiter gehen verloren. Ebenso sollte das Aufgabengebiet der
Mitarbeiter weitgehend konstant bleiben, um Freiräume für ein wissensbasiertes Umdenken zu
schaffen. Generell hilfreich erscheint die Auswahl von Projektmitarbeitern, die ein offenes We-
sen und starkes Interesse an neuen Ansätzen haben.
Phasenkonzept zur prozessualen Integration
des wissensbasierten Informationssystems
Mitarbeiterorientiertes
Change Management
Anpassung des Softwaresystems
Langfristige Erfolgssicherung
Kick-off des Projekts
Zieldefinition
Wissensmanagement als Basis
P r o j e k t m a n a g e m e n t
Vorbe-
reitungs-
phase
Pilot-
phase
Ausbau-
phase
Voll-
betriebs-
phase
Quelle: Verfasser
Abbildung 46: Das Phasenkonzept als Kernprozess des Implementierungsmodells
Die Inhalte der einzelnen Phasen werden in den folgenden Teilkapiteln erläutert. Einen ersten
Vorschlag für die Inhalte wissensorientierter Projekte hat HAUN [Haun02, S. 324 ff.] unter-
breitet. Er schlägt vor, bei Wissensmanagementprojekten in folgender Reihenfolge vorzugehen:
• Sensibilisierung,
• Definition von Wissenszielen,
• Schwachstellenanalyse,
• Definition von Potenzialen,
• Projektierung,
• Entwicklung und Implementierung,
• Kontrolle und Weiterentwicklung.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 95
Die Inhalte dieses Ansatzes werden in diesem Ansatz mit einem Phasenkonzept in Verbindung
gebracht, das wissensbasierte Informationssystem prozessorientiert einzuführen.
5.3.1 Anwendung einer Domino-Strategie
Die Einführung eines wissensbasierten Informationssystems ist aufgrund der Kombination aus
Softwaretechnik, Prozessgestaltung und Mitarbeitermotivation ein sehr anspruchsvoller Prozess.
Zur strukturierten Gestaltung dieser Aufgabe, bietet sich für das Implementierungsmodell eine
Domino-Strategie an. In der Übertragung auf das Implementierungsproblem bedeutet dies, es
muss zur besseren Übersichtlichkeit und Steuerbarkeit mit einem kleinen Teilbereich des Unter-
nehmens begonnen werden, wo auch nur ein Teil der Softwarefeatures eingesetzt wird (ver-
gleiche Einführungsstrategien bei Standardsoftware Kapitel 4.3.1). Bei dieser ersten Anwendung
geht es primär um die Sammlung von Erfahrungen und der Ermittlung von Optimierungspoten-
zialen zur Anpassung der Software-Features. Weiterhin können auch Erkenntnisse zur Anpas-
sung der wissensorientierten Arbeitsweise gewonnen werden. Es ist nicht zu erwarten, dass alle
Prozessschritte von Beginn an wie erwartet funktionieren, da das Verhalten und die Reaktionen
von Menschen im Vorfeld schwer abschätzbar sind.
Die Ausweitung des Softwareeinsatzes und die Unterstützung weiterer Prozesse sind kontinuier-
lich, aber nicht zu rasch vorzunehmen, damit sich die Denkweise und Einstellung der Mitarbeiter
mitentwickeln kann. Die Bereitstellung weiterer Softwarefeatures kann aus technischer Sicht
zwar kurzfristig geschehen, aber deren Einführung ist nur dann sinnvoll, wenn die ersten Schritte
angenommen und verinnerlicht wurden. Die Veränderung der Arbeits- und Unternehmenskultur
benötigt ausreichend Zeit, wie in Kapitel 3.3.4 dargestellt.
Die Zielsetzung besteht darin, bereits zu Beginn eine Begeisterung im Projektteam zu erzeugen
und eine positive Grundstimmung aus der ersten Projektphase auf die weiteren Phasen zu über-
tragen. Dazu sind die am Anfang einbezogenen Mitarbeiter mit Bedacht auszuwählen, da sie
später als Multiplikatoren in der Organisation dienen. Das führt zu einem sehr hohen Anspruch
an die Projektergebnisse besonders am Projektanfang, da die Erfolge hier zur Motivations-
steigerung und Projektausweitung unbedingt erforderlich sind.
In diese Strategie des Beginns der Abbildung von einfachen Prozessabläufen, die nach erfolg-
reicher Pilot-Umsetzung im weiteren Verlauf breit gefächert werden kann, ist der Software-
hersteller von Beginn an als Partner und Ideengeber einzubinden. Mit zunehmender Erfahrung
auf beiden Seiten können mit der Zeit komplexere Prozesse mit den erprobten Vorgehensweisen
und Softwarefeatures einbezogen werden. Für den Softwarehersteller ist die Domino-Strategie
ebenso von Vorteil, da auch er auf diese Weise an überschaubaren Pilotprozessen lernen kann
und nicht sofort eine große Lösung bieten muss.
Auch bei dieser individuellen Gestaltung der Software muss die langfristige Stabilität der Soft-
ware gesichert werden. Genauso wie bei einer Standardsoftware muss auch ein wissensbasiertes
Informationssystem zu den gewöhnlichen Betriebszeiten zur Verfügung stehen und regelmäßig
gesichert werden. Sollte es zu einem Ausfall kommen, so muss dieser schnellstmöglich beseitigt
werden, um den Produktionsbetrieb nicht zu gefährden.
SEITE 96 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
5.3.2 Vorbereitungsphase
Bevor die Implementierung in einer Pilotphase startet, muss im Kontext mit wissensbasierten
Informationssystemen eine detaillierte Analysephase vorgenommen werden. Sie untersucht und
dokumentiert die Prozesse des Unternehmens vor der Anpassung und Einführung des Software-
systems sehr genau. Die wesentlichen Inhalte und Ergebnisse der Analysephase zeigt die
Abbildung 47. Diese Phase ist Ausdruck der Anpassung des in Kapitel 4.3.2 vorgestellten
Phasenmodells von JOCHEM [Joch97, S.213ff.] auf die Bedürfnisse einer wissensorientierten
Vorgehensweise.
Pilotphase Ausbau-
phase
Vollbetriebs-
phase
Ergebnisse:
Vorbereitungsphase
- Analyse der Unternehmensprozesse
- Dokumente und Workflow aufzeichnen
- Integration der Fachabteilungen
- Schnittstellen zum System betrachten
- Klärung des Systemdesigns
- Festlegung eines Pilotbereichs
- Sollkonzept der Software
- Sollkonzept des Einführungsszenarios
Quelle: Verfasser
Abbildung 47: Vorbereitungsphase im Implementierungsmodell
Für die einzelnen Schritte der Analyse der Unternehmensprozesse (vergleiche auch Abbildung
48) ist das gesamte Projektteam aus Mitarbeitern der Fachabteilungen, den Softwareentwicklern
sowie die Managementvertretung gleichermaßen gefordert. Die im Workflow anfallenden Do-
kumente und die vorhandenen Wissensressourcen sind zur Schaffung eines Überblicks möglichst
vollständig zu erfassen. Dazu werden von der internen Projektleitung und der Projektleitung des
Softwareherstellers zunächst die im Unternehmen vorhandenen Prozessbeschreibungen und
–dokumentationen sowie Organisationsstrukturen ausgewertet. Soweit entspricht das Vorgehen
dem der Standardsoftwareeinführung. An diesem Punkt wird die Standardsoftware konfiguriert
und die Mitarbeiter müssen sich den neuen durch die Software abgegrenzten Strukturen anpassen
(vergleiche Phasenkonzepte zur Standardsoftwareeinführung in Kapitel 4.3.2).
Dieses Vorgehen wird analog bei wissensbasierten Informationssystemen angewendet. Der
Schwerpunkt liegt jedoch nicht auf der Prozessanalyse mit dem anschließenden Ziel der
Neugestaltung, sondern in der Unterstützung der bestehenden Prozesse. Um dies zu erreichen
werden in besonderem Maße die Mitarbeiter an der Prozessanalyse beteiligt. Ihnen wird die
Möglichkeit eingeräumt, als Betroffene die neue Softwareumgebung selbst mitzugestalten.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 97
Analyse der Unternehmensprozesse
Einholen
vorhandener
Informationen
zu Ist-
Prozessen
Auswertung
der
Datenbasis
Durchführung
strukturierter
Mitarbeiter-
interviews
Gesamtkon-
solidierung
der
Ergebnisse
Auswahl
des Bereichs
für die Pilot-
anwendung
Quelle: Verfasser
Abbildung 48: Vorgehen bei der Analyse der Unternehmensprozesse
Bei wissensbasierten Informationssystemen sind die offiziell strukturierten Funktionsweisen
nicht allein entscheidend, da sie im Umgang mit Wissen zweitrangig sein können. Wichtiger ist
es, auf Basis dieses Wissens die inoffiziellen Vorgehensweisen und Kommunikationsstrukturen
durch Beobachtungen und Interviews mit den Mitarbeitern zu erfassen. Die Akzeptanz und
Wirkung eines wissensbasierten Informationssystems ist dann als besonders hoch einzuschätzen,
wenn die Mitarbeiter bei ihrer tatsächlichen Arbeit wichtige Informationen zur Verfügung ge-
stellt bekommen und das System nicht an den beschriebenen theoretischen Prozessmodellen des
Unternehmens ausgerichtet wird. Der Aufwand für die Ermittlung der realen Struktur ist hoch
einzuschätzen, aber der zu erwartende größere Erfolg der Implementierung rechtfertigt diese
Aktivitäten (vergleiche Kapitel 3 zum Umgang mit Wissen).
Die Interviews müssen die Vorgehensweisen der Mitarbeiter zur Erledigung ihrer Aufgaben
visualisieren. Dazu gehören die zu bearbeitenden Dokumente sowie die geführten Gespräche,
wobei es keine Rolle spielt, ob diese in Besprechungen, per Telefon oder bei zufälligen Begeg-
nungen in den Räumen des Unternehmens stattfinden. Wichtig ist herauszufinden, welche In-
formationen ein Mitarbeiter benötigt, um möglichst schnell ein Problem lösen zu können oder
eine Entscheidung zu fällen. Je größer die Wiederholhäufigkeit eines Informationsbedarfs ist,
desto eher rentiert sich der Einsatz eines wissensbasierten Informationssystems.
Als Ergebnis wird der Unternehmensbereich als Pilotanwendung bestimmt, der einerseits über-
schaubare Prozesse sowie Informationsflüsse besitzt und der andererseits für die Fragen der
Wissensteilung besonders offene Mitarbeiter aufweist. Anschließend erarbeitet der Softwareher-
steller in Zusammenarbeit mit den Mitarbeitern dieser Abteilung und der Projektleitung einen
Vorschlag, wie das wissensbasierte Informationssystem in einer ersten Version nutzbringend
eingesetzt werden kann. Die Ziele des Einsatzes können beispielsweise eine Hilfestellung bei der
präventiven Vermeidung von Fehlern, der Beseitigung von aufgetretenen Fehlern, der Beschleu-
nigung der Prozessabarbeitung oder in der Vermittlung eines besseren Wissensstandes bei den
Mitarbeitern gesehen werden.
Bereits zu diesem frühen Zeitpunkt der Analysephase sind mit Hilfe der Fachabteilungen und der
Informationstechnikabteilung Schnittstellen des wissensbasierten Informationssystems zu ande-
ren DV-Systemen zu betrachten. Dabei ist unbedingt die Unterstützung des Softwareherstellers
erforderlich, der die technische Realisierbarkeit und den Arbeitsaufwand abschätzen kann. Die
Anbindung an die angenommenen und etablierten DV-Systeme sind ebenso wie funktionierende
und akzeptierte Prozesse eine Voraussetzung einer wissensbasierten Arbeit. Auch wenn in der
Pilotphase die Integration der Altsysteme noch nicht ein primäres Ziel ist, so sind die Strukturen
SEITE 98 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
und Funktionen des wissensbasierten Informationssystems von vornherein darauf auszurichten,
um die spätere Übernahme von Daten oder den Zugriff darauf zu ermöglichen. Es darf keine
Überladung mit Informationen stattfinden, die die Nutzer später abschreckt oder die Inhalte
unübersichtlich macht. Generell ist darauf zu achten, dass die Eintragungen per Hand in sehr
engen Grenzen bleiben, da von den Mitarbeitern zunächst nur der Aufwand gesehen wird und
das wissensbasierte Informationssystem womöglich nicht angenommen wird. Besser sind Lö-
sungen, die bereits vorhandene Datenbestände zu den entsprechenden Prozessen lösungs-
orientiert bündeln und dem Anwender komprimiert zur Verfügung stellen. Dazu ist es von Vor-
teil, wenn sich vorhandene Datenbestände möglichst früh und komfortabel integrieren lassen.
Außerdem muss bereits in der Analysephase eine Abschätzung durchgeführt werden, wie sich
die Datenbestände durch Eingaben im wissensbasierten Informationssystem entwickeln und wie
diese Weiterentwicklung mit Hilfe von Anreizsystemen gefördert werden kann.
Die Gestaltung des Systems ist mit dem Softwarehersteller so abzustimmen, dass die Anwender
für ihre Aufgaben im Prozess mit wenigen Eingabeschritten auf die notwendigen Informationen
zugreifen können. Der Prototyp ist noch in der Vorbereitungsphase den späteren Anwendern
vorzustellen, damit Verbesserungswünsche zur Bedienbarkeit rechtzeitig aufgenommen und
umgesetzt werden können. Dies wird analog auch in den Vorgehensmodellen in Kapitel 4.3.2 in
einer frühen Phase durchgeführt. Die Optimierungen können sowohl die Gestaltung der System-
oberfläche als auch die Inhalte selbst betreffen. Das Ziel eines solchen Workshops mit den An-
wendern muss es sein, den Nutzern maximal möglichen Komfort und mit wenigen Mausklicks
Zugriff auf die für sie relevanten Informationen im System zu gewähren. Sind die gesammelten
Anregungen nach dem Workshop umgesetzt, so ist der Prototyp des Softwaresystems auf seine
Fehlerfreiheit hin zu testen. Idealerweise sind an diesen Tests auch einige der späteren Anwender
beteiligt, um sie mit der Software vertraut machen zu können.
Die Anwender sind schon in der Vorbereitungsphase durch intensive Gespräche mit der Not-
wendigkeit einer kollektiven Wissensteilung vertraut zu machen. Diese Überzeugungsarbeit
muss auch bei den Abteilungsleitern und dem Top-Management vorgenommen werden, damit
das System im Betrieb genügend Ressourcen und regelmäßige Unterstützung erhält.
Die Vorbereitungsphase schließt mit der Dokumentation der während der Phase gewonnenen
Erfahrungen und getroffenen Entscheidungen, um sie bei einer späteren Ausweitung des Sys-
temeinsatzes erneut verwenden zu können. Diese Dokumentation ist auch insofern hilfreich, da
mit vielen Mitarbeitern aus den Fachabteilungen zusammen gearbeitet wird, die in den späteren
Phasen an der Weiterentwicklung nicht mehr direkt im Projektteam, sondern als erfahrene Nut-
zer verteilt im Unternehmen zur Verfügung stehen.
5.3.3 Pilotphase
Die Pilotphase orientiert sich an der in Kapitel 4.3.2 beschriebenen Phase 5 des Modells der
Standardsoftwareeinführung nach JOCHEM [Joch97, S. 213ff.]. Die Intention des Systemtests ist
ähnlich, wobei in diesem hier entwickelten Modell die Pilotphase mit dem Einpflegen einiger
Initialdatensätze beginnt, damit der Test in der Produktivumgebung mit einem bereits teilweise
gefüllten wissensbasierten Informationssystem starten kann. Diese Datensätze können aus dem
Prototypen übernommen werden, so dort mit echten Daten gearbeitet wurde. Ansonsten sind mit
den Mitgliedern des Projektteams einige Initialdaten zu generieren, die Inhalt und Funktions-
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 99
weise des Systems veranschaulichen. Dazu ist das Softwaresystem auf einem Unternehmens-
server mit den Features der Initialanwendung zuvor vollständig zu installieren und es ist sicher-
zustellen, dass die Anwender mit einer ausreichenden Anzahl Clients auf diesen Server zugreifen
können. Wenn bereits in dieser frühen Phase eine Anbindung an weitere DV-Systeme des Unter-
nehmens durchgeführt wird, ist das Funktionieren dieser Schnittstellen unbedingt zu überprüfen
und die Integrität des Gesamtsystems zu garantieren. Eine weitere wichtige Voraussetzung ist,
dass der Prototyp bereits während der Systementwicklung mit dem Management abgestimmt
wurde und in der Initialphase unterstützt wird. Die weitere intensive Einbindung aller Beteiligten
ist zu gewährleisten. Eine zusammenfassende Skizze der Aktivitäten dieser Phase zeigt die
Abbildung 49.
Pilotphase Ausbau-
phase
Vollbetriebs-
phase
Ergebnisse:
Vorbereitungs-
phase
- Schulung der Mitarbeiter in der System-
bedienung und Idee der Wissensteilung
- Systeminstallation mit Initialfeatures
- Initialdatensätze einpflegen
- Einrichtung eines Feedback-Prozesses
- Support sicherstellen
- Akzeptanz der Initialfeatures
- Beginn der Wissensteilung
- Generierung eines Nutzens im Prozess
Quelle: Verfasser
Abbildung 49: Pilotphase im Implementierungsmodell
Die Testphase startet an dem Zeitpunkt, an dem das wissensbasierte Informationssystem erstmals
produktiv in der Pilotabteilung eingesetzt wird. In dieser Abteilung sind sämtliche Mitarbeiter
intensiv in der Handhabung des wissensbasierten Informationssystems zu schulen und ihnen sind
die Vorteile der Wissensteilung aufzuzeigen. Ideal ist es, wenn die Schulungsmaßnahme von den
bereits im Projektteam vertretenen Mitgliedern der Fachabteilung durchgeführt wird, da ein
Mitarbeiter aus den eigenen Reihen überzeugender wirkt als eine nicht in dem Maße bekannte
und akzeptierte Person. Die Wissensteilung und deren Vorzüge sind anhand eines Beispiels aus
der täglichen Routine der Fachabteilung zu visualisieren, um ein tiefgehendes Verständnis zu
erreichen. Für eventuelle Nachfragen oder Unklarheiten stehen der interne Projektleiter sowie
ein Mitarbeiter des Softwareherstellers zur sofortigen Klärung zur Verfügung.
Die Testphase muss ein so langen Zeitraum umfassen, dass sichergestellt ist, dass ein Großteil
aller Aktivitäten der Abteilung mindestens einmal auftritt und als Testobjekt über das wissensba-
sierte Informationssystem abgebildet werden kann. Zu diesem Zeitpunkt ist es nicht zu empfeh-
len, ein eventuell vorhandenes Altsystem vollständig durch das neue abzulösen, da die Funktion
SEITE 100 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
des neuen noch nicht einwandfrei erwiesen ist. Es ist außerdem zu prüfen, inwieweit sämtliche
Aufgaben von dem neuen System erfüllt werden können.
Während der Pilotphase ist ein regelmäßiger Feedback-Prozess einzurichten, der einem Ablauf
gemäß Abbildung 50 folgt. Mit Hilfe dieser Methode erhalten die Initialnutzer eine Möglichkeit,
ihre Erfahrungen direkt an die Entwickler und Betreuer des wissensbasierten Informations-
systems zurückzumelden. Systemfehler können schnell behoben werden und das Bedienkonzept
kann genauer auf die rückgemeldeten Wünsche und Anforderungen der Nutzer zugeschnitten
werden.
Idee des
Mitarbeiters
Mitarbeiter
meldet Idee
direkt an die
Projektleitung
Mitarbeiter stellt
Idee in
„Meckerkasten“
Projektleitung
hält persönliche
Rücksprache
mit Ideengeber
Umsetzung
durch
Projektteam
Zurückstellung
oder
Verwerfung
Bewertung der
Idee
positive
Rückmeldung
an Einreicher
Rückmeldung
an Einreicher
mit Begründung
Quelle: Verfasser
Abbildung 50: Feedback-Prozess im Detail
Damit auch spontane Einfälle nicht vergessen werden, empfiehlt sich die Einrichtung eines
„Meckerkastens“ entweder in Form einer kleinen Zettelbox oder in Form einer elektronischen
Mailbox, die über einen Button innerhalb des wissensbasierten Informationssystems erreichbar
ist. Zusätzlich muss für akute Schwierigkeiten ein ständiger Ansprechpartner bei dem Software-
lieferanten definiert werden, der telefonisch Soforthilfe leisten kann. Weitere Erläuterungen zur
detaillierten Ausgestaltung des Feedback-Prozesses finden sich in Kapitel 5.6.
Gegen Ende der Pilotphase kann damit begonnen werden, die Ergebnisse des Tests etwa durch
eine Nutzerbefragung oder Auswertung der Zugriffe der Initialnutzer zu ermitteln (detaillierte
Ausführungen vergleiche Kapitel 6). Weiterhin sollten die neu hinzugekommenen Einträge im
wissensbasierten Informationssystem daraufhin analysiert werden, ob sie den zuvor gesetzten
Erwartungen entsprechen und sich auch für eine spätere Wiederverwendung eignen, d.h. die
Intention der Wissensteilung erfüllen. Ist dies nicht der Fall, ist der Prozess auf seine Eignung für
dessen Abbildung im wissensbasierten Informationssystem erneut zu hinterfragen. Wird er im
Ergebnis weiterhin als geeignet angesehen, sind die Mitarbeiter wiederholt auf das Vornehmen
solcher Eintragungen hin zu schulen.
Das Ergebnis dieser Pilotphase stellt die Akzeptanz der bis dato eingeführten Systemfeatures dar
sowie den Beginn einer Arbeitsweise unter Anwendung einer Wissensteilung durch die Mitar-
beiter der Pilotabteilung. Weiter ist es notwendig, gleich zu Beginn des Projekts mit der Soft-
ware einen Nutzen für den Prozess nachweisen zu können. Da monetäre Größen im Zusammen-
hang mit Wissen ungeeignete Messgrößen sind, können beispielsweise eine Verkürzung der
Reaktions- oder Bearbeitungszeiten für einzelne Prozessschritte herangezogen werden (ver-
gleiche Kapitel 6).
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 101
5.3.4 Ausbauphase
Die Ausbauphase spricht zwei Richtungen der Ausweitung an. Zum einen können weitere
Features für das wissensbasierte Informationssystem eingeführt werden und zum anderen kann
eine Ausweitung des Einsatzes der bereits bewährten Softwarefeatures auf weitere Abteilungen
oder Unternehmensbereiche erfolgen. Eine Zusammenfassung der notwendigen Aktivitäten zeigt
die Abbildung 51. Diese Ausbauphase ist deutlich differenziert gegenüber den Phasenmodellen
für Standardsoftware, da sie von einer zuvor feststehenden Softwareumgebung ausgehen, die nur
durch Customizing-Aktivitäten veränderbar ist. In dem hier entwickelten Modell ist eine größere
Flexibilität notwendig, weshalb eine deutliche Abweichung zu den in Kapitel 4.3 und 4.4 dis-
kutierten Modellen angestrebt wird.
Pilot-
phase Ausbauphase Vollbetriebs-
phase
- Umsetzung der Anregungen aus dem
Feedback-Prozess
- Integration weiterer Systemfeatures
- Integration weiterer (Teil-)Prozesse oder
Unternehmensbereiche
- Intensive Kommunikation des Projektes
Ergebnisse:
- Akzeptanz der weiteren Systemfeatures
- Beginn der Verankerung der neuen
Arbeitsweise in der Unternehmenskultur
Vorbereitungs-
phase
Quelle: Verfasser
Abbildung 51: Ausbausphase im Implementierungsmodell
Sind von den Nutzern in der Pilotphase sehr viele Änderungswünsche an der Software selbst
oder am Vorgehen eingegangen, so sind in jedem Fall zuerst diese Optimierungen abzuarbeiten.
Eventuell ist ein erneuter Testlauf durchzuführen, um zu überprüfen, ob die Verbesserungen den
gewünschten Erfolg im Echtbetrieb bringen. Erst, wenn sich das Projektteam sicher ist, dass die
eingesetzten Module des wissensbasierten Informationssystems und die wissensorientierte Ar-
beitsweise einwandfrei funktionieren, ist eine Ausweitung des Systemeinsatzes in weitere Ab-
teilungen anzustreben. Dieses iterative Vorgehen ist analog zu dem Projektplanungsverfahren zu
verstehen, das in Kapitel 4.2.2, Abbildung 28 vorgestellt wurde.
Wenn sich das wissensbasierte Informationssystem in der Pilotphase bewährt hat, kann der
Wunsch auftreten, weitere Abteilungen oder Unternehmensbereiche einzubinden. Diese System-
einführung muss ebenso sorgfältig vorgenommen werden wie die des Piloten. Es sind die glei-
chen Schritte zu durchlaufen wie im Vorfeld, d.h. die Prozesse des neuen Bereichs sind zu analy-
sieren und das wissensbasierte Informationssystem ist anschließend nach den Ergebnissen der
Analyse neu zu gestalten. Keinesfalls dürfen Module „blind“ auf andere Abteilungen übertragen
SEITE 102 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
werden, ohne zuvor die Verwendbarkeit zu überprüfen. Es ist zu erwarten, dass wesentliche
Teile wieder verwendet werden können, so es sich um Abteilungen oder Unternehmensbereiche
mit ähnlichen Aufgaben handelt. Daher bleibt der Anpassungsaufwand in engen Grenzen.
Idealerweise wurden die weiteren Bereiche bereits in der Analysephase betrachtet, so dass einer-
seits die Analyseergebnisse hier Verwendung finden können und andererseits das Softwaresys-
tem auf die Anforderungen abgestimmt ist.
Der Ausweitung des Systemeinsatzes sind dort Grenzen gesetzt, wo die Unternehmensbereiche
verschiedene Geschäftsfelder mit unterschiedlich gestalteten Prozessketten abdecken. Die erar-
beiteten Methoden zur Unterstützung der Wissensarbeit müssen anwendbar bleiben, was auch
bedeutet, dass die Unternehmenskultur sich nicht zu stark unterscheiden darf. Eine weitere Be-
grenzung stellt auch das Implementierungsprojekt selbst dar, da es aufgrund der starken Mitar-
beitereinbindung nur bis zu einem gewissen Umfang steuerbar bleibt. Der Projektleiter muss in
jedem Fall genügend Zeit haben, sich mit allen Beteiligten intensiv zu befassen.
Auf einem zweiten Weg können während dieser Phase weitere Module des wissensbasierten
Informationssystems eingeführt werden. Diese werden erst in der Pilotabteilung zum Einsatz
gebracht, da die Mitarbeiter dort bereits mit den Arbeitsweisen und dem System vertraut sind
und sie die neuen Features schneller auffassen und anwenden können. Zusätzlich kann mit dem
wissensbasierten Informationssystem in diesem Schritt ein Informationsmanagement realisiert
werden, das die für einen Prozess notwendigen Informationen aufbereitet zur Verfügung stellt.
Das bedeutet, für jeden Prozessschritt werden Hintergrundinformationen (z.B. Ansprechpartner,
Maschinenparameter, Servicepartner) abgelegt. Dazu gehört auch die Einbindung von Schnitt-
stellen an weitere informationsverarbeitende Systeme. Somit stehen die Dokumente in der Ober-
fläche zur Verfügung, in der sie benötigt werden.
Der Feedback-Prozess als solcher ist während der Ausbauphase konstant aufrecht zu erhalten um
einen kontinuierlichen Optimierungsprozess zu gewährleisten. Die regelmäßigen Gespräche
zwischen Projektleitung und den Systemnutzern sind weiterhin von den Projektleitern aktiv zu
forcieren, wobei die zeitlichen Abstände mit fortlaufender Laufzeit des Softwaresystems ver-
größert werden können.
Neben dem Feedback sind in dieser Phase die bereits erzielten Erfolge aus der Pilotphase auf
breiterer Ebene zu kommunizieren, um eine positive Grundstimmung zu einer wissensorien-
tierten Arbeit in der Organisation zu erzeugen und die Akzeptanz bei der Ausweitung des Sys-
tems zu erleichtern bzw. zu beschleunigen. Je nach Ebene wie Geschäftsführung, Abteilungs-
leiter oder Mitarbeiter sind unterschiedliche Kommunikationsformen einzusetzen. Dies können
beispielsweise persönliche Gespräche der Projektleitung, Präsentationen oder Beiträge in einer
Unternehmenszeitung sein.
Die Ziele dieser Phase liegen in folgenden Aspekten:
• Einführung weiterer Systemfeatures
• Ausweitung der in der Pilotphase eingeführten Features auf weitere Abteilungen
• Akzeptanz des Softwaresystems durch die Mitarbeiter
• regelmäßige Verwendung des Softwaresystems durch die Mitarbeiter
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 103
• Erhöhung des Verbreitungs- und Anwendungsgrades, um die Verankerung der
wissensorientierten Arbeitsweise in der Unternehmenskultur zu unterstützen
• Etablierung der Wissensteilung als Selbstverständlichkeit für jeden beteiligten
Mitarbeiter
5.3.5 Vollbetriebsphase
Die Vollbetriebsphase schließt die primäre Implementierung ab. Bis zu dieser Phase sind die zu
Beginn definierten Ziele erreicht und das wissensbasierte Informationssystem ist im Ergebnis ein
vollwertiger und selbstverständlicher Teil der Arbeit im Unternehmen geworden. Bis zu diesem
Punkt entspricht der Status dem Ergebnis der Implementierungsverfahren für Standardsoftware
(vergleiche Kapitel 4.3). Gemäß der Devise „Stillstand ist Rückschritt“ empfiehlt es sich, in der
wissensorientierten Vorgehensweise während der Vollbetriebsphase weiterhin neue Ideen zu ent-
wickeln und umzusetzen. Einige Beispiele für die Inhalte der Phase zeigt die Abbildung 52.
Pilot-
phase
Ausbau-
phase
Vollbetriebs-
phase
- Sicherung der Datenpflege und -qualität
- Ausbau der Schnittstellen zu anderen
DV-Systemen
- Anstoß weiterer wissensorientierter
Projekte
- Einbindung weiterer Standorte prüfen
Ergebnisse:
- Erreichen der definierten Ziele
- Aktive Weiterentwicklung des Systems
- volle Verankerung wissensorientierter
Arbeitsweisen in der Unternehmenskultur
Vorbereitungs-
phase
Quelle: Verfasser
Abbildung 52: Vollbetriebsphase des Implementierungsmodells
Besonders wichtig bei den in Abbildung 52 genannten Aktivitäten erscheint insbesondere der
Punkt der Sicherung der Datenpflege und Datenqualität. Die Mitarbeiter bekommen ein hohes
Maß an Kompetenz zugestanden, ihr Wissen nach ihren Vorstellungen in das System selbständig
einzupflegen. Daher ist es sinnvoll die Einträge in bestimmten Zeitabständen daraufhin zu
überprüfen, ob sie den gewünschten Standards entsprechen. Alternativ kann auch eine Freigabe
der Einträge im System durch einen übergeordneten Fachexperten im Unternehmen erfolgen.
Dieser hat dafür Sorge zu tragen, dass nur korrekte und keine redundanten Einträge in seinem
Fachgebiet im System gehalten werden.
Die Dimensionen des Ausbaus orientieren sich am TOM-Modell und können Abbildung 53
entnommen werden. In einer Gesamtsicht bieten sich außerhalb der ursprünglichen Zieldefinition
SEITE 104 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
besonders in Großunternehmen Überlegungen zum Einsatz des an einem Standort entwickelten
wissensbasierten Informationssystems an weiteren Niederlassungen an. Hierbei können für die
Weiterentwicklung aller Dimensionen die Erfahrungen aus dem Projekt genutzt und die daraus
resultierende wissensorientierte Arbeitsweise im Sinne eines „best practice“-Modells übertragen
werden. Dabei ist es hilfreich, wenn das wissensbasierte Informationssystem selbst von vorn-
herein modular und flexibel aufgebaut wurde. Dadurch wird eine Anpassung auf ähnliche Pro-
zesse erheblich erleichtert und die Kosten für eine Ausweitung des Systemeinsatzes können
gering gehalten werden.
technische
Integration
prozessuale
Integration Integration
in den Köpfen
: Basis der Implementierung
: Gesamtintegrationsumfang des Projekts
: Ausbau der Integration
Quelle: Verfasser
Abbildung 53: Integrationsaspekte in der Vollbetriebsphase
In der Betrachtung der technischen Integration (vergleiche Abbildung 53) kann es auch
erforderlich werden sehr komplexe Features, wie etwa eine Mehrsprachigkeit, einzuführen, so
der Einsatz in verschiedenen Ländern erfolgt. Diese oder ähnlich aufwändige Funktionen sind in
Form eines neuen (Teil-)Projektes zu implementieren, da sie aufgrund des
Softwareentwicklungsaufwands eher technisch orientiert sind und weniger die Wissensthematik
betreffen. Die Abwicklung kann mittels eines klassischen Softwareprojektmanagements
erfolgen. Zeitlich ist dieses Projekt in der Vollbetriebsphase anzusiedeln, da hier die Thematik
der Wissensteilung bereits abgearbeitet ist und mehr Raum für technische Projekte gegeben ist.
Ein weiteres Augenmerk muss auf die technische Integration des wissensbasierten Informations-
systems mit Schnittstellen zu weiteren DV-Systemen gelegt werden. Je tiefer das System in die
Datenverarbeitung des Unternehmens eingebunden ist, desto mehr Informationen können den
Nutzern prozessgerecht aufbereitet präsentiert werden, was zu einer schnelleren Bearbeitung
führt. In der Phase des Vollbetriebs können die zuvor definierten Schnittstellen zu anderen Sys-
temen dazu genutzt werden, das System weiter zu integrieren. Diese weiteren Wissensressourcen
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 105
werden systematisch nach Bedarf über Softwareschnittstellen angebunden, wodurch Redundan-
zen ausgeschlossen werden. Damit ergibt sich ein Zusammenhang zur zuvor beschriebenen
Vorbereitungsphase. An dieser Stelle können nun alle Ressourcen integriert werden, die in der
Vorbereitungsphase bereits als notwendig erachtet wurden, deren Realisierung bis zur Pilotphase
jedoch zu aufwändig war.
In einem weiteren Schritt kann nun in der prozessualen Integration (vergleiche Abbildung 53)
auch eine Strukturierung der Unternehmensprozesse nach Wissensgesichtspunkten
vorgenommen werden, da die Idee der kollektiven Arbeit mit Wissen und die stetige Reflexion
der eigenen Tätigkeit bereits in der Kultur verankert ist. Durch die breit zur Verfügung stehenden
Informationen ist es einzelnen Mitarbeitern möglich, wesentlich komplexere Aufgaben in
kürzerer Zeit zu erledigen, so dass die frei werdende Zeit für innovative Projekte zur Stärkung
der eigenen Wettbewerbsfähigkeit des Unternehmens verwendet werden kann.
Im Ergebnis darf die Integration in den Köpfen als dritte Dimension nicht außer Acht gelassen
werden. Sie trägt genauso wie die technische und prozessuale Integration erheblich zum Gesamt-
erfolg des Projekts bei. Ihre Förderung bedarf individueller Maßnahmen, die im speziellen Fall
aus Motivationsanreizen, Schulungen, Einforderung durch Führungskräfte etc. zu zusammen zu
stellen sind.
5.3.6 Vergleich mit Verfahren für Standardsoftware
In einem Abgleich mit dem in Kapitel 4.3.2 vorgestellten Implementierungsmodell von JOCHEM
[Joch97] sollen die Unterschiede des wissensorientierten Verfahrens zum Standardvorgehen
dargestellt werden. Die Abbildung 54 zeigt auf, dass die wesentlichen Unterschiede zwischen
beiden Verfahren vor allem in folgenden Aspekten zu sehen sind:
• Das wissensorientierte Modell geht nicht von einer bereits zu Beginn feststehenden
Software aus, die in diesem Zustand mit einigen kundenspezifischen Anpassungen ein-
geführt wird.
• Die Software ist ein Produkt, das nach den Erfordernissen des Prozesses entwickelt
wird. Sie ist in allen Phasen als variabel anzusehen im Gegensatz zur Standardsoft-
ware.
• Zur Erreichung der Wissensziele legt das neue Implementierungsverfahren großen
Wert auf die Integration und Mitarbeit aller Beteiligten beispielsweise durch den Feed-
back-Prozess. Die Integration der Mitarbeiter erfolgt im Standardverfahren erst spät
durch Schulungsmaßnahmen in der Phase sechs. Das wissensbasierte Verfahren for-
ciert die Integration bereits ganz zu Beginn, indem die Ideen der Mitarbeiter in das
System einfließen sollen.
• Das wissensbasierte Verfahren will die Prozesse im Gegensatz zum Standardsoftware-
verfahren nicht neu gestalten, sondern nach den Methoden des Wissensmanagements
unterstützen.
• Die Phasen sind im wissensbasierten Verfahren durch die kontinuierliche Software-
integration nicht so feinstufig abgegrenzt. Vielmehr soll durch die größeren Blöcke den
Mitarbeitern die Möglichkeit gegeben werden, sich mit der wissensorientierten Ar-
beitsweise auseinander zu setzen.
SEITE 106 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
• Im Standardsoftwarevorgehen wird zum Abschluss nur noch die Wartung der Software
angestrebt. Das wissensorientierte Verfahren geht am Ende nicht von einem „fertigen“
Standard aus. Die Dynamik in der Wissensnutzung kann dazu genutzt werden, stetig
nach neuen Verbesserungspotenzialen zu suchen. Falls dies möglichst ist, können diese
zeitnah umgesetzt werden.
Vorbereitungs-
phase
Pilotphase
Ausbauphase
Vollbetriebs-
phase
• Analyse der Unternehmensprozesse
• Dokumente und Workflow
aufzeichnen
• Integration der Fachabteilungen
• Schnittstellen zum System betrachten
• Klärung des Systemdesigns
• Schulung der Mitarbeiter in
Systembedienung und Wissensteilung
• Systeminstallation mit Initialfeatures
• Initialdatensätze einpflegen
• Einrichtung eines Feedback-
Prozesses
• Support sicherstellen
• Umsetzung der Anregungen aus dem
Feedback-Prozess
• Integration weiterer Systemfeatures
• Integration weiterer (Teil-)Prozesse
oder Unternehmensbereiche
• Intensive Kommunikation des
Projektes
• Ausbau der Schnittstellen zu anderen
DV-Systemen
• Anstoß weiterer wissensorientierter
Projekte
• Einbindung weiterer Standorte prüfen
• Verankerung der wissensorientierten
Arbeitsweisen in der
Unternehmenskultur
Phase 1
Projekt-
vorbereitung
Phase 2
Systemplanung
Phase 3
Prototyping
Phase 4
Realisierung
Phase 5
Systemtest
Phase 6
Produktions-
vorbereitung
Phase 7
Stabilisierung
• Projektorganisation erstellen und
einbinden
• Istaufnahme und Schwachstellenanalyse
• Erarbeitung des Sollkonzepts
• Einarbeitung des Projektteams
• Abbildung der Unternehmensstruktur
• Test des Standardsystems
• Repräsentative Geschäftsvorfälle
auswählen
• Gestaltung der Geschäftsvorfälle
diskutieren
• Eigenentwicklungen testen
• Festlegungen aus Prototyping umsetzen
• Benutzerdokumentation erstellen
• Qualitätssicherung beachten
• Detaillierte Planung des Systemtests
• Durchführung des Systemtests
• Testergebnisse dokumentieren und
auswerten
• Installation aller Hard- und
Softwarekomponenten
• Schulung der künftigen Anwender
• Durchführung der Datenübernahme
• Organisatorische und technische
Systemoptimierung
• Änderungswünsche dokumentieren
• Wartungshandbuch erstellen und
S
y
stemüber
g
abe
Quelle: Verfasser
Abbildung 54: Vergleich des wissensbasierten Implementierungsmodells mit dem Verfahren für
Standardsoftware von JOCHEM
5.4 Mitarbeiterorientiertes Change Management
Die Phasen der Implementierung werden begleitet von einem Change Management. Dieses
Instrument zeigt wie in Kapitel 4.5 in Standardprojekten den Weg zur Realisierung der Ziele auf.
Im Zusammenhang mit der Einführung eines wissensbasierten Informationssystems ist dieser
Prozess zu nutzen, um auf die Bedürfnisse der Mitarbeiter einzugehen. In den folgenden Teilka-
piteln wird der Prozess näher erläutert. Die Positionierung im Gesamtkontext ist der Abbildung
55 zu entnehmen.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 107
Phasenkonzept zur prozessualen Integration
des wissensbasierten Informationssystems
Mitarbeiterorientiertes
Change Management
Anpassung des Softwaresystems
Langfristige Erfolgssicherung
Kick-off des Projekts
Zieldefinition
Wissensmanagement als Basis
P r o j e k t m a n a g e m e n t
Vorbe-
reitungs-
phase
Pilot-
phase
Ausbau-
phase
Voll-
betriebs-
phase
Quelle: Verfasser
Abbildung 55: Der Begleitprozess des mitarbeiterorientierten Change Management
5.4.1 Notwendigkeit einer Mitarbeiterorientierung
Die Notwendigkeit eines mitarbeiterorientierten Change Managements ergibt sich daraus, dass
ein wissensintensives Projekt wesentlich größere Anforderungen an die Mitarbeiter stellt als
beispielsweise die Einführung einer Standardsoftware wie in Kapitel 4.5 aufgezeigt. Die
Standardsoftware erwartet von den Menschen im Betrieb standardisierte Eingaben oder liefert
einem Mitarbeiter nach Anforderung eine Information aus einer Datenbank. Das Change Mana-
gement unterstützt in diesem Fall die Mitarbeiter gemäß Kapitel 4.5 dabei, die Vorgehensweise
gemäß des neuen Systems zu antizipieren. Ein wissensbasiertes Informationssystem verlangt
jedoch eine wesentlich unspezifischere Anwendung. Jeder Mitarbeiter muss selbst entscheiden,
in welchem Moment er explizites Wissen in dem System abfragt und wann es sinnvoll ist, sein
eigenes implizites Wissen wieder hinein zu geben. Dies erfordert eine andere Motivationslage als
bei einem Standardsystem, da es keine vollständig automatisierten Arbeitsabläufe geben kann.
Dahinter steht die Einsicht, dass Wissen von Menschen generiert und von Menschen wieder
verwendet wird. Daher muss der Mensch mit seinen Ansichten, Wertvorstellungen und persön-
lichen Vorlieben im Mittelpunkt stehen. In erster Linie sind dies die Projektteammitglieder und
die späteren Nutzer des Softwaresystems. Bereits DOPPLER/LAUTERBURG [DoLa02, S. 234f.]
fordern für ein erfolgreiches Change Management die Einbeziehung derjenigen, die die Arbeiten
verrichten. Der entscheidende Punkt ist, diese Mitarbeiter zu befragen, wo aus ihrer Sicht der
Ablauf optimal ist, wo es „Reibungsverluste“ gibt und was verändert werden kann. Ihre Erfah-
SEITE 108 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
rung ist zu berücksichtigen, da sie die einzigen sind, die über tägliche Praxis, eine genaue Sach-
kenntnis und viele Praxisinformationen verfügen, die für eine erfolgreiche Veränderung ent-
scheidend sind.
Das hier propagierte mitarbeiterorientierte Change Management beschreibt die Einbindung der
Mitarbeiter in allen Entwicklungsstufen der Software sowie im Prozess der organisatorischen
Einbindung. Die Mitarbeiter dürfen an keiner Stelle zu einer Arbeit mit dem wissensbasierten
Informationssystem „gezwungen“ werden, da in diesem Fall nicht erwartet werden kann, dass
das im System eingegebene Wissen tatsächlich für andere nutzbringend ist. Vielmehr ist der
Weg der Überzeugung zu beschreiten, der den Menschen den Sinn und Hintergrund des System
vermittelt, so dass sie in der Folge selbst mit der Software arbeiten wollen. Wollen Menschen
von sich aus etwas erreichen, so sind sie auch hoch motiviert.
Zur Umsetzung dieses Konzepts hat die Projektleitung die Aufgabe, von Beginn an gemeinsam
mit den Mitarbeitern das Projekt zu gestalten. Wichtigstes Mittel der Gestaltung ist die klare
Definition und Kommunikation von Projektzielen. Die Mitarbeiter brauchen Sicherheit und
einen Überblick, welche Auswirkungen das wissensbasierte Informationssystem auf ihre Arbeit
und ihren Arbeitsplatz hat. Sie sind gedanklich dort abzuholen, wo sie sich befinden und werden
nur dann zur Mitarbeit bereit sein, wenn sie erkennen, dass die Software als Mittel zur
Optimierung und Unterstützung ihrer Arbeit dient und keine Bedrohung darstellt. Um zu zeigen,
dass kein Interesse an der Verletzung von Arbeitnehmerrechten besteht, ist die Einbindung des
Betriebsrates als ständige Vertretung der gesamten Arbeitnehmerschaft unbedingt notwendig.
Sowohl das Ziel selbst als auch der Weg kann für die Mitarbeiter bedrohlich wirken. Daher ist
den Mitarbeitern eine Perspektive aufzuzeigen, welche Rolle sie im Veränderungsprozess
spielen. Ein gutes Change Management bedeutet auch, dass alle durchgeführten Maßnahmen wie
die Motivation, der Feedback-Prozess usw. den Mitarbeitern gegenüber ausreichend vorgestellt
und erläutert werden.
Die Mitarbeiterorientierung ist auch deshalb zu forcieren, da die Entscheidungen auf eine mög-
lichst breite Basis gestellt werden müssen. Folgende Vorteile ergeben sich daraus:
• Je weniger Mitarbeiter sich gegen die Wissensarbeit stellen, desto erfolgreicher und
ruhiger kann das Projekt durchgeführt werden. Bereits wenige „Störer“ können den Er-
folg gefährden, da sie durch ihre negative Einstellung viele andere Mitarbeiter beein-
flussen und auf ihre Seite ziehen können.
• Die Mitarbeiter müssen die Idee der wissensorientierten Arbeit mit einem wissens-
basierten Informationssystem als ein „eigenes Kind“ betrachten und sich bewusst
machen, dass die Erfolge ihre Eigeninteressen dadurch stärken, dass das Unternehmen
wettbewerbsfähig bleibt oder wird.
• Die Mitarbeiter bekommen die Chance, die wissensbasierte Arbeit gemeinsam im
Kollektiv anzugehen. Es werden nicht nur einzelne aus der Gesamtheit herausgegrif-
fen.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 109
5.4.2 Ableitung des Veränderungsbedarfs aus den Unternehmens- und Projektzielen
Der Veränderungsbedarf und die Vorgehensweise leiten sich aus vielen Faktoren im
Unternehmen ab. Die Abbildung 56 zeigt einige von ihnen auf.
Unternehmenskultur
Kenntnisse der Mitarbeiter
Unternehmensphilosophie bei Veränderungen
Synergieeffekte aus anderen Wissensprojekten
Veränderungsbereitschaft der Mitarbeiter Generierung eines
angepassten
Veränderungs-
szenarios
Quelle: Verfasser
Abbildung 56: Ableitung des Veränderungsbedarfs aus unternehmensinternen Faktoren
Die von dem Change Management begleitete wissensbasierte Veränderung muss wie die Pro-
jektziele aus den Unternehmenszielen abgeleitet werden, da ein Erfolg nur dann wahrscheinlich
ist, wenn die Veränderung selbst mit der grundsätzlichen Ausrichtung und Philosophie des Un-
ternehmens vereinbar ist. Sind in den Unternehmenszielen keine Wissensziele eingebunden, so
sind diese in jedem Fall zu integrieren und durch entsprechende Projekte wie das Implementie-
rungsvorhaben zu leben. Eine solche Situation stellt einen schwierigen Startpunkt dar, weil auf
diese Art erst ein Bewusstsein für die Wissensthematik geschaffen werden muss. Da dies eine
längere Zeit braucht, darf nicht mit schnellen Erfolgen gerechnet werden. Hier ist ein erstes
Projektziel bereits in der erfolgreichen Schulung der Mitarbeiter in den Vorgehensweisen des
Wissensmanagements zu sehen.
Ein Unternehmen, dass schon erste Projekte im Bereich des Wissensmanagements durchgeführt
hat, kann dagegen von den dort gemachten Erfahrungen profitieren und Synergieeffekte zwi-
schen den Projekten ausnutzen. Das Change Management kann an die vorangegangenen Projekte
anknüpfen und die dort begonnenen Veränderungen systematisch fortsetzen. Hier ist ein Be-
wusstsein für die Notwendigkeit einer Wissensteilung bereits vorhanden und muss nicht mehr
mühsam erarbeitet werden.
Selbstverständlich darf im Projekt kein künstlicher Veränderungsbedarf generiert werden. Stellt
sich bei der Voruntersuchung heraus, dass die Prozesse mit einem wissensbasierten Informa-
tionssystem nur mit großem Aufwand zu unterstützen sind, so ist kein Implementierungsversuch
zu unternehmen. Dafür sind nach Bedarf andere wissensorientierte Maßnahmen durchzuführen,
wie etwa eine Änderung der Besprechungskultur oder die Installation von Informationswänden.
5.4.3 Förderung des Veränderungsprozesses in den Phasen der Implementierung
Der Veränderungsprozess muss in den einzelnen Phasen der Implementierung auf unterschied-
liche Art und Weise unterstützt werden. Ein Zitat von ANTOINE DE SAINT-EXUPÉRY hilft dabei,
die globale Intention der Maßnahmen zu erschließen:
SEITE 110 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
„Dans la vie, il n’y a pas des solutions. Il n’y a que des forces en marche: il faut les
créer et les solutions suivent.“ Antoine de Saint-Exupéry, Vol de Nuit (Nachtflug)
(Im Leben gibt es keine Lösungen. Es gibt nur Kräfte, die in Bewegung sind: Man
muss sie erzeugen und die Lösungen werden folgen.)
Der Veränderungsprozess hat die Aufgabe in den Projektphasen die Kräfte zu erzeugen, die
notwendig sind, um zu der Implementierung des wissensbasierten Informationssystems zu ge-
langen und orientiert sich an dem in Kapitel 4.5.1 vorgestellten Modell der Veränderung. Bei der
Gestaltung der Veränderung ist in jedem Fall die vorherrschende Unternehmenskultur zu beach-
ten, da kulturbewusste Führungsmaßnahmen immer den Grundstein zur Förderung der Nut-
zungsbereitschaft darstellen [PRRo03, S. 178]. Dadurch kann ein ähnlicher Prozess in den Pha-
sen „unfreeze“, „move“ und „refreeze“ stattfinden, wie nach dem Modell von BRETTEL ET AL.
in Kapitel 4.5.1 aufgezeigt. Die Abbildung 57 zeigt den Vergleich des Veränderungsprozesses
für die Standardsoftware und das wissensbasierte Informationssystem.
Veränderungsprozess
gegenwärtiger
Zustand A Zielzustand B
unfreeze move refreeze
Phaseninhalte im Fall einer Standardsoftwareeinführung:
Phaseninhalte im Modell der Implementierung eines
wissensbasierten Informationssystem:
• Bedarf für ein neues
System erkennen
•Projekt aufsetzen
• Software auswählen
• Prozessanalyse
• Customizing der
Software
• Ausrollen im
Unternehmen
• Schulung der
Mitarbeiter
• Anwendung auf alle
Prozesse
• Projektabschluss
• Integration der
Mitarbeiter in
Prozessanalyse
• Identifikation
wissensbasierter
Unterstützung
• Auswahl des
Softwareanbieters als
strat. Partner
•Projektbeginn
• Anpassung der
Software auf die
Prozesse
• Integration der
Mitarbeiter in
wissensorientierten
Veränderungsprozess
• stetige Einbindung der
Software in die
Prozesse
• Verankerung der
wissensintensiven
Arbeit in der
Unternehmenskultur
• Einfordern stetiger
Verbesserungen
• Nachhalten der
Zielerreichung
Quelle. Verfasser
Abbildung 57: Die drei Phasen des Veränderungsprozesses im Vergleich
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 111
Die Aufgabe der Steuerung der Veränderung obliegt dem Projektmanagement, dem im wesentli-
chen die folgenden Ansätze zur Verfügung stehen:
• Förderung der Kommunikation
Der Aufbau der Kommunikation erfolgt in drei Dimensionen. Die erste Dimension ist
die des Projektteams, die aufgrund der notwendigen starken Einbindung des externen
Softwareherstellers sorgfältig zu planen ist. Gesprächstermine sind rechtzeitig abzu-
stimmen, damit sowohl interne als auch externe Projektmitarbeiter an den gemeinsa-
men Treffen teilnehmen können und über den aktuellen Diskussionsstand informiert
sind. Eine zweite Dimension ist die Kommunikation der unternehmensinternen Mitar-
beiter untereinander unabhängig vom Projekt selbst. Viele Ideen werden bei einem
Meinungsaustausch von Kollegen untereinander geboren. Die Projektmitarbeiter sind
zu ermutigen, auch mit „unbeteiligten“ Kollegen über das Projekt zu sprechen, so dass
daraus resultierende Gedanken eingebracht werden können und bereits im Vorfeld
weitere Kollegen über die Idee einer wissensbasierten Arbeit und die damit verbunde-
nen Veränderungen informiert sind. Die dritte Dimension ist die der Kommunikation
mit dem Management. Zum einen muss das Projektteam das Management über den
Projektstand stetig informieren und zum anderen muss das Management mit einem
guten Beispiel vorangehen und die gewollte Veränderung der Wissensteilung aktiv
vorleben.
• Motivation als zentralen Antrieb erzeugen
Eine Motivation muss durch die Überzeugung entstehen, das Richtige zu tun und den
Willen, ein bestimmtes Ergebnis zu erreichen. Dazu muss die Projektleitung aufzeigen,
welche Ziele mit dem Projekt verfolgt werden sollen und wo die Vor- und Nachteile
liegen. Die Veränderung muss dabei realistisch und ehrlich dargestellt werden, damit
eine spätere Frustration vermieden wird.
• Entwicklung einer Gruppendynamik
Die Entwicklung einer Gruppendynamik hängt eng mit der Motivation der einzelnen
zusammen. Die Veränderung muss akzeptiert und gelebt werden. Um dies zu errei-
chen, müssen Schlüsselpersonen aus der Gruppe der Mitarbeiter von der Veränderung
überzeugt werden und sie aktiv vorleben. Die anderen Gruppenmitglieder schließen
sich gemäß der Gruppendynamik an, so dass sich die Veränderung durchsetzt.
• Schulung der Mitarbeiter
Eine Schulung der Mitarbeiter ist im Rahmen der Veränderung dann notwendig, wenn
sich abzeichnet, dass die Ziele weiterer Erklärungen bedürfen und die Mitarbeiter wei-
tere Kenntnisse zur Umsetzung einzelner Projektschritte brauchen. Es sind immer eher
Diskussionsrunden anstatt klassischer Frontalschulungen zu verwenden, damit die In-
halte optimal vermittelt werden. Es darf dabei nicht der Eindruck erweckt werden, es
solle etwas „durchgedrückt“ werden.
Die genannten Ansätze müssen kontinuierlich, aber in den jeweiligen Phasen in unterschiedli-
cher Intensität angewendet werden. Mit dem Beginn der Analysephase ist insbesondere die
Management- und Projektteamkommunikation entscheidend, damit die Grundlagen für die
Implementierung erarbeitet werden können. In den weiteren Phasen tritt die Mitarbeiterkommu-
SEITE 112 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
nikation hinzu. Während der Pilot- und Ausbauphase ist die Veränderung mittels Erzeugung
einer Motivation und der Entwicklung einer Gruppendynamik voranzutreiben. Die Vollbetriebs-
phase beinhaltet primär die Kommunikation im Sinne der Erarbeitung von Optimierungsvor-
schlägen.
5.4.4 Kultivierung der Veränderungen
Die Kultivierung der Veränderung zielt darauf ab, die wissensorientierte Arbeit mit dem wis-
sensbasierten Informationssystem zu einem Standard zu machen (vergleiche die Phase „refreeze“
im Modell von BRETTEL ET AL. [BrRP05, S. 91] laut Kapitel 4.5.1). Damit ist das Wissen laut
PROBST/RAUB/ROMHARDT [PRRo03, S. 178] als eine Ressource zu verstehen, die unabhängig
von ihrem Ursprung zum gemeinsamen Nutzen der Organisation eingesetzt wird. Das setzt einen
sehr selbständigen Umgang der Mitarbeiter mit der Software und eine Einbindung in die Pro-
zesse des Unternehmens voraus, was im Rahmen des Implementierungsprojekts sichergestellt
wird. Die Kultivierung kann nie als vollständig abgeschlossen gelten, da es eine lange Zeit
braucht, bis alle Mitarbeiter die Veränderungen angenommen haben und im kontinuierlichen
Verbesserungsprozess stets Optimierungsmöglichkeiten gefunden werden. Im Rahmen der Kul-
tivierung muss auch versucht werden, die „Verweigerer“ von den Veränderungen zu überzeugen.
Es ist anzunehmen, dass die Gruppe der Verweigerer einlenken wird, desto kleiner sie wird.
Zusätzlich kann zur Kultivierung der Systemnutzung eine Anreizsystematik für die Mitarbeiter
eingesetzt werden. Dazu sind Zielvereinbarungen mit jedem Mitarbeiter oder den Arbeitsgrup-
pen notwendig, die wiederum personenbezogene Auswertungen der Systemverwendung notwen-
dig machen. Diese sind zuvor im Rahmen einer Betriebsvereinbarung festzulegen. Generell sind
auch Sachprämien oder immaterielle Anreize denkbar. Die Gestaltung ist individuell mit den im
Unternehmen angewendeten Grundsätzen abzustimmen und bedarf einer Zustimmung durch den
Betriebsrat.
Der Erfolg der Veränderungsbemühungen hängt jedoch nicht nur vom Implementierungsprojekt
selbst, sondern auch von anderen Rahmenbedingungen ab. Ist das Unternehmen etwa in einer
wirtschaftlich angespannten Lage und drohen Kündigungen, so ist unter den Mitarbeitern ein
Egoismus zu erwarten, der eine Wissensteilung verhindert. Ein wissensbasiertes Informations-
system hat in einer solchen Umgebung kaum Möglichkeiten angenommen zu werden. Als ein
Erfolg kann die Kultivierung der Veränderungen beispielsweise dann gesehen werden, wenn ein
neuer Mitarbeiter eingearbeitet wird und ihm gleich zu Beginn das wissensbasierte Informations-
system und die unternehmensweite Teilung des Wissens als Selbstverständlichkeit erläutert wird.
Dadurch nehmen die Mitarbeiter sofort die neue Kultur an und müssen nicht zu einem späteren
Zeitpunkt von ihr überzeugt werden.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 113
5.5 Anpassung des Softwaresystems
Phasenkonzept zur prozessualen Integration
des wissensbasierten Informationssystems
Mitarbeiterorientiertes
Change Management
Anpassung des Softwaresystems
Langfristige Erfolgssicherung
Kick-off des Projekts
Zieldefinition
Wissensmanagement als Basis
P r o j e k t m a n a g e m e n t
Vorbe-
reitungs-
phase
Pilot-
phase
Ausbau-
phase
Voll-
betriebs-
phase
Quelle: Verfasser
Abbildung 58: Der Gedanke der Softwareanpassung im Implementierungsmodell
Die Anpassung des wissensbasierten Informationssystems auf die Prozesse gehört zur zentralen
Denkweise dieses Implementierungsmodells. Bereits bei der Auswahl des wissensbasierten
Informationssystems ist die Idee der Softwareanpassung zu berücksichtigen, indem ein Soft-
warelieferant ausgewählt wird, der veränderungsfähige Softwaremodule liefern kann, die kein
vollstandardisiertes System darstellen. Die Abbildung 58 zeigt die Intention der Anpassung als
stetige Größe der Vorgehensweise.
Mittels dieses Konzepts wird die Einsatzbreite eines wissensbasierten Informationssystems
deutlich vergrößert, da es nicht für einen speziellen Anwendungszweck im Unternehmen ent-
wickelt werden muss. Ähnlich zur Einführung einer Standardsoftware können einmal gesam-
melte Erfahrungen unternehmensintern oder in externen Projekten wieder verwendet werden.
Insbesondere die Softwarehersteller können ihre Position stärken, indem sie Erfahrungen auf-
bauen und diese für den Kundenstamm und die Neukundenaquisition gewinnbringend einsetzen.
5.5.1 Notwendigkeit einer anpassbaren Software
Die Entwicklung einer Software verursacht hohe Kosten, wenn sie für einen einzigen spezifi-
schen Anwendungsfall aufgebaut wird. Eine vollstandardisierte Software ist für die wissens-
orientierte Arbeit nicht einsetzbar, da sie sich nach dem hier vorgeschlagenen Konzept nicht an
den Prozessen des Unternehmens orientieren kann. Dennoch bieten sich Möglichkeiten für den
SEITE 114 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
Aufbau von Standards, die sowohl dem Hersteller als den Kunden Vorteile bieten. Beispiels-
weise kann der Hersteller durch Standards seine Entwicklungskosten reduzieren und der Kunde
bekommt eine ausgereifte Lösung für einen geringeren Preis. Insofern bestehen Parallelen zu
dem in Kapitel 4.4.1 vorgestellten Verfahren des Customizing. Allerdings sind dort weitaus
größere Teile der Software als feststehend zu betrachten, so dass nur noch eine Anpassung der
Parameter erfolgt und weniger der Software selbst. Einige Möglichkeiten der Softwareanpas-
sung, die im Folgenden aufgezeigt werden, sollten bei einer wissensorientierten Vorgehensweise
in jedem Fall gegeben sein.
Folgende Möglichkeiten bieten sich für die Erzeugung von Standards: Es bietet sich an, im
Rahmen der Anpassung eine Oberfläche zu entwerfen, die den Erfordernissen eines Prozesses
entspricht. Durch die Wissensorientierung ist größter Wert auf die Übersichtlichkeit und Infor-
mationsdarstellung zu legen. Das bedeutet auch die individuelle Gestaltung der Ein- und Ausga-
ben für jeden Prozess. Auch wenn die optische Gestaltung und funktionale Gliederung in jedem
Prozess ein anderes Aussehen hat, so ist dennoch die Systematik identisch, so dass sich die
Anpassungen mittels einfacher Maßnahmen realisieren lassen. Eine weitere Option ist die Er-
zeugung eines einheitlichen Systems zur Modellierung von Prozessen innerhalb des wissensba-
sierten Informationssystems. Wird diese Methodik für Prozesse allgemein und nicht für einen
speziellen Einsatzzweck entworfen, bietet sich für das System ein sehr breites Einsatzfeld.
Die danach noch notwendigen Anpassungen sind analog zu dem o.g. Customizing bei einer
Standardsoftware zu verstehen, da bereits vorhandene Module auf ihren spezifischen Einsatz-
bereich hin ausgerichtet werden. Je nach technischer Gestaltung der Software ist darauf zu ach-
ten, die Grenze zu einer Weiterentwicklung nicht zu überschreiten, damit eine Kompatibilität mit
Folgeversionen besteht. Diese Methodik bietet die Chance, die Qualität und den Einsatzbereich
des wissensbasierten Informationssystems für zukünftige Anwendungen stetig zu verbreitern.
Die Vorteile sind sowohl auf der Seite des Herstellers zu sehen, der seine Software mit jedem
Implementierungsprojekt weiter optimiert, als auch auf Seiten des Kunden, der ohne eine Indivi-
dualentwicklung trotzdem ein auf seine Bedürfnisse zugeschnittenes wissensbasiertes Informa-
tionssystem erhält.
5.5.2 Einbindung der Software in die Prozesse
Die Einbindung des wissensbasierten Informationssystems in die Prozesse wird in der Analyse-
phase vorbereitet und in den Phasen des Pilotbetriebs und des Ausbaus vollzogen. Es ist während
der Projektlaufzeit stetig zu hinterfragen, ob die gewählte Einbindung optimal ist, oder ob sich
noch bessere Lösungen bieten. Das wissensbasierte Informationssystem ist von vornherein flexi-
bel gestaltet, so dass es in der Lage ist, sich mit den Prozessen weiter zu entwickeln und weiter
zu wachsen.
Es ist wichtig, zuerst die Prozesse und die Softwarefeatures einzubinden, die den größten Nutz-
wert für die Arbeit im Tagesgeschäft bringen und möglichst auch von den Mitarbeitern ge-
wünscht werden. Ebenso ist die Workflowintegration an den Stellen voranzutreiben, die in der
Analysephase ein deutliches Unterstützungspotenzial aufgewiesen haben. Die Anpassung der
Software ist im Vorfeld der Realisierung mit dem Projektteam abzustimmen. Eine etwaige Pro-
zessoptimierung ist nur dann im voraus durchzuführen, wenn sich abzeichnet, dass mit den
vorhandenen Strukturen keine Erfolge zu erzielen sind.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 115
5.5.3 Einbindung des Softwareherstellers im Gesamtprojekt
Die Einbindung des Softwareherstellers ist grundsätzlich als strategische wichtige Maßnahme zu
betrachten. Anhand des aufgezeigten Implementierungsmodells lässt sich gemäß Abbildung 59
ersehen, dass der Softwarehersteller in allen Teilprozessen entweder voll integriert ist oder zu-
mindest eine beratende Funktion hat. Die wesentlichen Aspekte der Zusammenarbeit werden
hier zusammenfassend dargestellt.
Phasenkonzept zur prozessualen Integration
des wissensbasierten Informationssystems
Mitarbeiterorientiertes
Change Management
Anpassung des Softwaresystems
Langfristige Erfolgssicherung
Kick-off des Projekts
Zieldefinition
P r o j e k t m a n a g e m e n t
Vorbe-
reitungs-
phase
Pilot-
phase
Ausbau-
phase
Voll-
betriebs-
phase
: beratende Funktion
: volle Integration in das Projekt
Quelle: Verfasser
Abbildung 59: Einbindungsgrad des Softwareherstellers nach Teilprozessen
Die intensive Beteiligung des Softwareherstellers bringt für das Gesamtprojekt der Implemen-
tierung des wissensbasierten Informationssystems eine Vielzahl von Vorteilen, die im Folgenden
dargestellt werden:
• Das Know-how des Softwareherstellers und seine Mitarbeiter sind frühzeitig in das
Projekt zu integrieren. In der Regel ist davon auszugehen, dass der Hersteller bereits
Erfahrungen aus anderen Implementierungsprojekten vorweisen kann. Diese können
im Rahmen einer Integration beispielsweise dadurch im neuen Projekt umgesetzt
werden, dass die Mitarbeiter sofort nach der Auswahl des Softwarelieferanten im
Projektteam integriert werden und bei den Planungen beratend zur Seite stehen. Im
SEITE 116 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
Phasenbezug zum vorgestellten Implementierungsmodell sollte dies spätestens zum
Kick-off der Fall sein.
• Das Projektmanagement ist in enger Abstimmung mit dem Softwarehersteller zu
führen. Dies betrifft in Ergänzung zu Kapitel 5.2.2 vor allem die enge Zusammenarbeit
des internen und externen Projektleiters. Beide sollten sich in kurzen Abständen
abstimmen und haben dafür Sorge zu tragen, dass die unternehmensinternen Spezifika
und die softwarebedingten Eigenschaften optimal zusammengeführt werden.
• Unterstützung der Prozessanalyse durch den Hersteller. Gemäß der in Kapitel 5.3.2
aufgezeigten Vorbereitungsphase werden die Geschäftsprozesse eingehend untersucht.
Hierbei ist es hilfreich den Softwareanbieter zu integrieren, damit er bereits in diesem
Stadium die Analyse gezielt auf das von ihm angebotene Produkt durchgeführt wird.
• Anpassung und Konfiguration der Software durch den Hersteller. Im Rahmen der
prozessorientierten Implementierung übernimmt der Softwarehersteller die spezifische
Anpassung und Konfiguration der Software auf die Bedürfnisse des Unternehmens
gemäß der Prozessanalyse und dem daraus erstellten Lastenheft (Kapitel 5.2.2). Bereits
bei der Auswahl des Anbieters (vergleiche Kapitel 5.1.2) ist die Fähigkeit des
Hersteller zur Anpassung und Konfiguration seines Produkts ein entscheidendes
Kriterium.
• Gemeinsame Durchführung der Schnittstellendefinition. Der Softwareanbieter ist bei
der Analyse und Erarbeitung der Schnittstellen zu anderen DV-Systemen einzubinden,
da er die Optionen für die Integration von Schnittstellen in seinem System am besten
einschätzen und in der Lage ist, die Ideen direkt mit den Unternehmensexperten zu
diskutieren (vergleiche Kapitel 5.3.2).
• Sicherung der Stabilität der Software. Zur Sicherung der dauerhaften Stabilität der
Software bieten sich zwei Vorgehensweisen an. In einer ersten Variante kann mit dem
Hersteller der Software ein langfristiger Wartungsvertrag geschlossen werden, der
allerdings die dauerhafte Präsenz des Unternehmens am Markt voraus setzt. Analog zu
den Kriterien bei der Einführung einer Standardsoftware können folgende Punkte für
eine längerfristige Marktperspektive sprechen:
• bereits abgeschlossene Referenzprojekte bei anderen Kunden,
• Berichte zufriedener Kunden,
• stetiges Umsatzwachstum in den letzten drei Jahren,
• konstante oder zunehmende Mitarbeiterzahl in den letzten drei Jahren.
In einer alternativen Vorgehensweise ist es möglich, die laufende Wartung des wissensbasierten
Informationssystems im eigenen Haus zu übernehmen. Dafür müssen die eigenen Mitarbeiter
zum einen genügend Kenntnisse in den verwendeten Programmiersprachen und Datenbank-
anwendungen haben und zum anderen muss der Quellcode vom Softwarehersteller offen gelegt
werden.
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 117
5.6 Sicherstellung des langfristigen Erfolgs
Phasenkonzept zur prozessualen Integration
des wissensbasierten Informationssystems
Mitarbeiterorientiertes
Change Management
Anpassung des Softwaresystems
Langfristige Erfolgssicherung
Kick-off des Projekts
Zieldefinition
Wissensmanagement als Basis
P r o j e k t m a n a g e m e n t
Vorbe-
reitungs-
phase
Pilot-
phase
Ausbau-
phase
Voll-
betriebs-
phase
Quelle: Verfasser
Abbildung 60: Die langfristige Erfolgssicherung
Bei wissensorientierten Projekten ist auf eine langfristige Sicht mit spürbaren Erfolgen zu rech-
nen. Die Veränderungen in der Kultur benötigen, wie in Kapitel 3.3.4 dargestellt, einen Zeitraum
von einigen Jahren. Dieser Sachverhalt ist nicht nur bei der Auswahl der Zielgrößen wichtig,
sondern muss auch in der Vorgehensweise der Systemimplementierung Niederschlag finden.
Daher beinhaltet das Implementierungsmodell gemäß Abbildung 60 einen begleitenden Prozess
zur langfristigen Erfolgssicherung, der in diesem Kapitel beleuchtet wird.
Die langfristige Erfolgssicherung gibt einen Handlungsrahmen, der während der gesamten Pro-
jektlaufzeit beibehalten werden muss. Eine wichtige Voraussetzung ist die sorgfältige Planung,
die den am Projekt beteiligten Mitarbeitern von Beginn an die langfristig geplanten Ziele auf-
zeigt. Zur Integration der Mitarbeiter in die aktive Arbeit bieten sich die Einrichtung eines Vor-
schlagswesens, regelmäßige Review-Gespräche und eine direkte Rückkopplung zur Entwicklung
des wissensbasierten Informationssystems an. Wenn einige der geplanten Arbeitsschritte nicht
wie vorgesehen durchgeführt werden können, werden von der Projektleitung flexibel neue Vor-
schläge zur Zielerreichung erarbeitet. Ein starres Festhalten am ursprünglichen Terminplan führt
möglicherweise zu einer unsauberen Arbeit, die unbedingt zu vermeiden ist. Zur Vorbereitung
des Systemausbaus und zur Förderung des Übergangs der wissensorientierten Arbeitsweise in
die Unternehmenskultur ist bereits in den frühen Projektphasen mit einem Projektmarketing zu
beginnen.
SEITE 118 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
5.6.1 Einrichtung eines Vorschlagswesens für die Systemnutzer
Ein langfristiger Erfolg stellt sich primär durch eine rege Beteiligung der Mitarbeiter auf allen
Ebenen ein. Daher ist ein Vorschlagswesen einzurichten, mit dem es möglich wird, auf die Wün-
sche der Mitarbeiter einzugehen. Zur Erfassung der Erfahrungen ist bereits in der Pilotphase ein
Feedback-Prozess anzuwenden. Gegenüber den Mitarbeitern muss diese Methode als Möglich-
keit kommuniziert werden, alle das wissensbasierte Informationssystem betreffende Anregungen
und Kritik anzubringen. Es gelten dafür die folgenden Regeln:
• Es darf alles konstruktiv kritisiert werden, positiv wie negativ.
• Die Software gilt nicht als „fertig“, sondern als anpassbar.
• Die Anwenderwünsche sind zu dokumentieren und mit ihnen zu diskutieren.
• Es gibt keine „schlechten“ Vorschläge, sondern jede Anregung ist wertvoll. Dabei ist
zweitrangig, ob sie sich später tatsächlich als zielführend herausstellt.
• Die eingegangenen Vorschläge sollen zeitnah umgesetzt werden.
Spontane Ideen können auf einem vorbereiteten Blatt am schwarzen Brett der Abteilung oder
neben dem entsprechenden Arbeitsplatz notiert werden, damit sie nicht in Vergessenheit geraten.
Gerade diese Einfälle, die bei der direkten Systemanwendung aufkommen, sind die, die häufig
einen großen Nutzwert haben. Sie sind dadurch zu fördern, dass die Mitarbeiter immer wieder
aufgefordert werden diese abzugeben.
Eine weitere Möglichkeit besteht in der Installation eines Rückmeldebuttons innerhalb der Ober-
fläche des wissensbasierten Informationssystems zum Einreichen von Vorschlägen „online“. So
können im laufenden Betrieb direkt im System Anregungen notiert werden. Daraus kann bei-
spielsweise eine Mail an die Projektleitung generiert werden, die sich anschließend mit dem
Nutzer in Verbindung setzt, der den Vorschlag eingereicht hat. Bei der Diskussion mit dem
Einreicher ist festzustellen, ob und wie der Vorschlag umsetzbar ist.
Das Instrument ist kontinuierlich in allen Phasen der Implementierung anzuwenden. Besondere
Relevanz hat es in der Pilot- und Ausbauphase, da hier die Möglichkeit der Umgestaltung des
Softwaresystems und der wissensorientierten Arbeitsweise noch besonders groß ist. Inwieweit
die Schaffung von materiellen oder immateriellen Anreizen in Frage kommt, muss gemäß der
vorherrschenden Unternehmenskultur abgestimmt werden.
5.6.2 Durchführung von Review-Gesprächen
Zur Intensivierung des Vorschlagswesens sind regelmäßige Review-Gespräche mit den System-
nutzern durchzuführen. Hierbei werden die Anwender direkt befragt. Während der Pilotphase
sollte ein solches Review-Gespräch zur Erfassung des Feedbacks zwischen der Projektleitung
und den Initialanwendern in kürzeren Abständen stattfinden. Inhaltlich stellen die Nutzer einen
ausführlichen Erfahrungsbericht vor, der für die System- und Prozessentwicklung den Input für
die weitere Optimierung bildet. Die Erfahrungen sind zu bündeln und in konkrete Maßnahmen
zu kanalisieren. Auch hier gelten die gleichen Regeln wie im Vorschlagswesen, nach denen es
keine „falschen“ Anregungen gibt.
Die Dauer eines Gesprächs kann nach Bedarf angepasst werden und hängt auch von dem Zeit-
raum zwischen zwei Gesprächen ab. Es sollte ein Umfang von 15 bis maximal 30 Minuten aus-
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 119
reichend sein. Dabei sollten die Mitarbeiter von sich aus aufzeigen, was ihnen gefällt und wo sie
Verbesserungsbedarf sehen. Die Projektleitung fungiert als Moderator und nimmt die Anregun-
gen entgegen. Wenn bei einzelnen Mitarbeitern weiterer Gesprächsbedarf besteht, so sollten
diese Fragen in einem persönlichen Gespräch geklärt werden.
Der zeitliche Abstand der Gespräche kann in den späteren Projektphasen größer gewählt werden,
so dass in der Ausbauphase der Gesprächsabstand etwa verdoppelt wird und in der Vollbetriebs-
phase der Abstand noch einmal eine Verdopplung erfährt. Die Intervalle können hier größer
werden, da der große Rahmen bereits abgesteckt ist und weniger Anregungen aufkommen. Ge-
nerell können die Gespräche auch ausschließlich nach Bedarf stattfinden, was allerdings die
Gefahr birgt, dass sie aufgrund eines fehlenden Standardtermins im Tagesgeschäft untergehen.
5.6.3 Rückkopplung zur Systementwicklung
Eine direkte Rückkopplung zur Systementwicklung ist ein wichtiger Faktor für die Schaffung
eines langfristigen Erfolgs. Der erste Schritt ist bereits die Einbindung des Systemherstellers als
strategischer Partner. Zweitens müssen die Anregungen aus dem Vorschlagswesen und aus den
Review-Gesprächen möglichst unverzüglich umgesetzt werden, damit keine Frustration bei den
Nutzern auftritt. Eventuell gegensätzliche oder widersprüchliche Vorschläge müssen bewertet
werden und nach der Bewertung werden sie von Projektleitung oder dem Management diskutiert
und entschieden.
Die Projektleitung muss sich bewusst sein, dass die regelmäßigen Gespräche eine hohe Erwar-
tungshaltung schaffen, die erfüllt werden muss. Daher ist gerade zu Beginn auf eine zügige
Umsetzung zu achten. Es ist nicht ungewöhnlich, dass am Anfang des Betriebs einige Fehler
auffallen, die bei den Systemtests beim Hersteller und im Haus zuvor nicht gefunden werden
konnten.
Eine schnelle Rückkopplung lässt sich per Mail oder Telefon zur externen Systementwicklung
und zur internen Projektleitung realisieren. Zur Betreuung der Nutzer gehört auch die Bereit-
stellung eines Supports, der Fragen zum laufenden Betrieb klärt und aus den Anfragen Vorbe-
reitungsmaßnahmen extrahiert. Die Supportanfragen müssen zu den gewöhnlichen Betriebs-
zeiten beantwortet werden. Sinnvoll ist es, einen internen Ansprechpartner im Sinne einer telefo-
nischen Hotline zu benennen, der zunächst versucht alle Fragen zu klären, bevor sie an den
Softwarehersteller weitergeleitet werden. Der Softwarehersteller sollte sich möglichst aus-
schließlich um die Weiterentwicklung des Systems kümmern und nicht mit Tagesgeschäft kon-
frontiert werden.
Der interne Projektleiter hat die Aufgabe alle Anregungen aus den Review-Gesprächen, Vor-
schlagswesen und Support-Hotline zu sammeln und vorab auszuwerten, so dass die umzusetzen-
den Ideen gebündelt zu dem Softwarehersteller gelangen. Über diesen Weg können die Kapazi-
täten der Systementwicklung optimal genutzt und mehrfache Diskussionen der internen und
externen Projektleitung mit den Nutzern vermieden werden.
5.6.4 Erfolgsorientiertes Projektmarketing
Ein langfristiger Erfolg wird dadurch gefördert, dass das Implementierungsprojekt positiv prä-
sentiert und bekannt gemacht wird. Die Kommunikation wird von der Projektleitung sowohl auf
SEITE 120 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
der Ebene der Nutzer als auch auf der Managementebene vorangetrieben. Der Kreis der ange-
sprochenen Mitarbeiter erhöht sich stetig mit der Laufzeit des Projekts. Die Ansprache der Mit-
arbeiter kann persönlich, in einer Präsentation oder indirekt über Artikel in einer Mitarbeiter-
zeitung bzw. über Aushänge am schwarzen Brett erfolgen.
Hilfreich ist es, im Rahmen der Kommunikation bereits mit dem Projekt erzielte Erfolge ein-
fließen zu lassen. Dadurch können die Mitarbeiter motiviert und zum aktiven Mitmachen be-
geistert werden.
5.7 Goldene Regeln für die Implementierung eines wissensbasierten Informa-
tionssystems
Die Goldenen Regeln für die Implementierung eines wissensbasierten Informationssystems sind
als generelle Handlungsanweisungen zu verstehen, die für das Implementierungsprojekt von
entscheidender Bedeutung sind und das vorangegangene Kapitel zusammenfassen.
• Das Wissensmanagement ist als Basis für das Implementierungskonzept zu verwenden.
Die Anwendung eines wissensbasierten Informationssystems ist sehr eng verwandt mit
den Konzepten der lernenden Organisation und denen des Wissensmanagements. Das
Projektmanagement muss sich im Vorfeld des Projekts mit den Inhalten vertraut ma-
chen, um diese Ansätze gezielt einsetzen zu können.
• Das wissensbasierte Informationssystem ist in die Prozesse des Unternehmens ein-
zubinden. Das Softwaresystem kann nur dann seinen umfassenden Nutzen entfalten,
wenn es vollständig in die Arbeitsabläufe integriert wird. Mit dieser Einbindung wird
es in den Prozessen regelmäßig verwendet, bringt den Mitarbeitern einen Mehrwert
und stellt keinen Zusatzaufwand dar.
• Die Mitarbeiter sind von der Idee einer kollektiven Wissensteilung zu überzeugen. Der
Erfolg des Einsatzes des wissensbasierten Informationssystems hängt davon ab, in-
wieweit die Mitarbeiter zur Teilung ihres Wissens motiviert werden. Das Ziel ist es,
dass alle Mitarbeiter die Notwendigkeit der Weitergabe ihres persönlichen Wissens für
den Erfolg aller erkennen und praktizieren.
• Das Projektteam pflegt offene und ehrliche Umgangsformen. Bei der Projektarbeit
wird die Basis für den Erfolg gelegt und die zukünftig erwarteten Werte müssen so
vorgelebt werden, wie sie nach der Systemeinführung von allen Mitarbeitern ge-
wünscht werden.
• Das wissensbasierte Informationssystem wird auf die Einsatzumgebung angepasst. Das
Softwaresystem muss sich den Prozesse des Unternehmens anpassen und dadurch sei-
nen Nutzwert entfalten. Im Rahmen der Implementierung wird keine grundlegende
Neuordnung der Prozesse wie bei einem Business Process Reengineering durchgeführt.
Dieses Vorgehen erfordert eine sorgfältige Analyse der Einsatzumgebung. Die Unter-
nehmensprozesse sind auf durchlaufende Dokumente, beteiligte Mitarbeiter und den
Workflow hin zu analysieren und zu dokumentieren.
• Der Softwarehersteller ist als strategischer Partner in das Implementierungsprojekt
einzubinden. Da keine vollstandardisierte Software verwendet wird, ist der Hersteller
IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME SEITE 121
für die Anpassungen in das Projekt einzubeziehen. Es ist von Vorteil, wenn der Her-
steller bereits ähnliche Projekte durchgeführt hat und seine eigenen Erfahrungen in das
Implementierungsprojekt einfließen lassen kann.
• Die Mitarbeiter und zukünftigen Systemnutzer sind als Experten ihres Arbeitsbereichs
intensiv bei der Gestaltung des Softwaresystems und der Arbeitsabläufe einzubeziehen.
Niemand kennt die Arbeit so gut wie diejenigen, die sie täglich ausführen. Daher sind
die späteren Nutzer des wissensbasierten Informationssystems bereits in den frühen
Projektphasen an der Gestaltung des Systems zu beteiligen. Zur Vermeidung einer Be-
triebsblindheit ist eine Unterstützung von außen, wie beispielsweise durch den Soft-
warehersteller, unerlässlich.
• Zielsetzung ist neben der Akzeptanz des wissensbasierten Informationssystems die
Übernahme der wissensorientierten Arbeit in die Unternehmenskultur. Die Akzeptanz
des Softwaresystems und der Idee der Wissensteilung ist die Voraussetzung für die er-
folgreiche Arbeit mit dem System. Später muss das System standardisiert eingesetzt
werden und die wissensorientierte Arbeitsweise in die Unternehmenskultur übergehen.
• Zur Unterstützung des Veränderungsprozesses wird ein mitarbeiterorientiertes Change
Management eingesetzt. Das Change Management bezieht die Mitarbeiter in die Ver-
änderung ein, mit dem Ziel, sie zu der Anwendung der neuen Arbeitsweisen zu moti-
vieren. Dies darf nicht durch Zwang geschehen, sondern durch die Überzeugung der
Mitarbeiter, den richtigen Weg zu beschreiten.
SEITE 122 IMPLEMENTIERUNGSMODELL FÜR WISSENSBASIERTE INFORMATIONSSYSTEME
INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS SEITE 123
6 Instrumentarium zur Messung des Implementierungserfolgs
Nur vom Nutzen wird die Welt regiert.
(Friedrich von Schiller)
Dieses Kapitel zeigt ein Instrumentarium zur Messung des Erfolgs des Implementierungsprojekts
auf. Messungen im Zusammenhang mit wissensorientierten Projekten werden in der Literatur als
schwierig und noch nicht ausgereift dargestellt (vergleiche Kapitel 3.4). Daher werden hier für
den Sachverhalt der Implementierung eines wissensbasierten Informationssystems im Unter-
nehmenskontext geeignete Kennzahlen ausgesucht und im Anschluss in einer Implementierungs-
Scorecard aufbereitet. Dabei orientieren sich die ausgewählten Kennzahlen an dem in Kapitel 5
entworfenen Implementierungsmodell. Den inhaltlichen Aufbau dieses Kapitels zeigt die
Abbildung 61. Zunächst werden die notwendigen Eigenschaften von geeigneten Kennzahlen
erläutert, bevor direkte und indirekte Messgrößen vorgestellt werden, die in die Scorecard für die
Implementierung münden.
Kennzahlensystematik für die
Implementierung wissensbasierter
Informationssysteme
Scorecard für die
Implementierung
Direkte
Kennzahlen
Indirekte
Kennzahlen
Quelle: Verfasser
Abbildung 61: Aufbau des Kapitels zur Messung des Implementierungserfolgs
Es wird das Ziel verfolgt, eine Methodik für die Erfolgsmessung vorzustellen, die mit einem
vertretbaren Aufwand zu realisieren ist, d.h. im praktischen Einsatz von einem Projektmitarbeiter
anteilig übernommen werden kann. Die Betrachtung der Auswirkungen und Ergebnisse des
Projekts ist sehr wichtig, aber dennoch müssen die vorhandenen Ressourcen primär für die Er-
reichung der eigentlichen Projektziele verwendet werden. Es muss mit leicht erfassbaren Indi-
katoren der Nachweis gelingen, dass die in das Implementierungsprojekt projizierten Erwartun-
gen dauerhaft erfüllt werden.
Es muss beachtet werden, dass eine möglichst isolierte Betrachtung des Implementierungsergeb-
nisses durchgeführt wird. Gerade in größeren Unternehmen wird eine Vielzahl von organisato-
SEITE 124 INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS
rischen Optimierungsprojekten parallel durchgeführt, so dass genau abzuwägen ist, welche
Aussagekraft die ermittelten Kennzahlen besitzen bzw. von welchen weiteren Rahmenbedingun-
gen sie beeinflusst werden.
6.1 Kennzahlen für die Implementierung wissensbasierter Informationssysteme
Dieses Kapitel erläutert die Grundlagen, wie die Kennzahlen für die Implementierung definiert
und begründet werden. Bei der Auswahl und Definition von Kennzahlen für wissensorientierte
Projekte erscheint immer wieder das Problem, dass monetäre Größen ungeeignet sind, um einen
Erfolg darzustellen. Nur der Investitionsaufwand für das Projekt lässt sich im Vorfeld gut ab-
schätzen, indem eine Summe der Kosten für Hardware, Software und die Personalstunden des
Projektteams gebildet wird. Mit dieser Betrachtung kann das Management allenfalls entscheiden,
ob es bereit ist, das Implementierungsprojekt durchzuführen und die notwendige Investition zu
tätigen.
Wesentlich schwieriger ist die Bestimmung der Ergebnisse der Implementierung des wissens-
basierten Informationssystems und der damit verbundenen wissensorientierten Arbeitsweise. Es
lässt sich kein neuer Prozess mit klassischen Controllingmethoden analysieren, sondern es müs-
sen vielmehr viele kleine Verbesserungen aufgezeigt werden, die durch den optimierten Wis-
sens- und Informationsfluss entstanden sind. Da es sich um Vorgänge in einem sehr komplexen
Gesamtumfeld handelt, sind die Auswirkungen nur schwer zu ermitteln. Sehr viele Einflüsse
kommen zusammen, deren Trennung mitunter schwer fällt. Hierfür können in keinem Fall mo-
netäre Größen verwendet werden.
Generell müssen die Kennzahlen geeignet sein, einen Systemnutzen nachzuweisen. Der zu errei-
chende Nutzen wird in der Zieldefinition des Projekts festgelegt (vergleiche Kapitel 5.2.1). Im
Rahmen von ERP-Implementierungen wird ein positiver Nutzen dann angenommen, wenn sie
einen Beitrag zu den übergeordneten Unternehmenszielen leistet [MMGe02, S. 110]. Das ist
gleichbedeutend mit der Annahme, dass nicht allein technische Eigenschaften als Nutzengröße
betrachtet werden können. Vielmehr ist es wichtig, da die Einführung eines ERP-Systems, wie
die eines wissensbasierten Informationssystems, eine große organisatorische Herausforderung
darstellt, zur Beurteilung von Nutzeneffekten die Auswirkungen der Maßnahmen auf die Unter-
nehmensprozesse zu untersuchen.
6.1.1 Anforderungen und Ableitung einer Kennzahl
Betriebswirtschaftliche Kennzahlen stellen eine überprüfbare quantitative Zielsetzung dar und
sind nach HOPFENBECK [Hopf02, S. 806]
• für interne und externe Zwecke einsetzbare Messgrößen,
• die in konzentrierter, stark verdichteter Form,
• auf relativ einfache Weise,
• schnell,
• als Ausdruck eines erfassbaren und quantifizierbaren Vorganges,
• über einen betrieblichen Tatbestand informieren.
INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS SEITE 125
Die Kennzahlen müssen für das Implementierungsprojekt aus den Projekt- und Unternehmens-
zielen abgeleitet werden (vergleiche Kapitel 5.2.1). Durch die Kennzahlendefinition werden die
Zieldimensionen in real messbare und nachprüfbare Größen umgewandelt. Grundvoraussetzung
für die Ableitung ist die Überlegung durch die Projektleitung und das Projektteam, welche kon-
kreten Nutzeneffekte mit der Systemimplementierung erreicht und damit Basis der Messung
werden sollen. Oberstes Ziel ist die Erreichung eines zuvor definierten Nutzens im Prozessablauf
des Unternehmens.
Kennzahlen für die Erfolgsmessung bei der Implementierung von wissensbasierten Informa-
tionssystemen müssen einigen grundsätzlichen Anforderungen genügen. Wichtig ist, dass sie
leicht zu erheben und dauerhaft zu verfolgen sind. Diese einfache Messbarkeit kann sich dadurch
äußern, dass sie sich mit dem wissensbasierten Informationssystem automatisch erfassen lassen
oder ohnehin durch andere Controlling-Instrumente des Unternehmens erfasst werden. Jede
dieser Kennzahlen muss vor Beginn des Implementierungsprojekts einmalig als Ausgangswert
erhoben werden.
Die Absicht besteht darin, Kennzahlen zu finden, die eine hohe Aussagekraft über die Ergebnisse
des Implementierungsprojekts haben und dabei möglichst wenig von anderen Projekten beein-
flusst werden. Es ist zu beachten, dass gerade in größeren Unternehmen häufig mehrere parallele
Projekte zur Optimierung von Prozessen oder der Organisationsgestaltung durchgeführt werden,
die ebenso Auswirkungen auf die Kennzahlen haben können. Organisationen sind komplexe
Gebilde mit vielen Abhängigkeiten, so dass eine gegenseitige Beeinflussung der Kennwerte
durch verschiedene Projekte nicht immer vermeidbar ist. Dieser Umstand muss bei der Auswer-
tung Berücksichtigung finden, indem die Beeinflussung der Kenngrößen durch andere Projekte
hinterfragt wird. Zu Beginn des Implementierungsprojekts ist eine Abschätzung durchzuführen,
ob eine der Kennzahlen während der Projektlaufzeit Veränderungen unterliegen wird. Nur bei
konstanten Bedingungen bleibt ihre Aussagekraft erhalten.
Die folgende Analyse einer Kennzahl kann laut HOPFENBECK [Hopf02, S. 807] zwei Fragen
beantworten:
• Die Frage der Verhältnismäßigkeit, d.h. ist die Kennzahl oder der Aufwand zu hoch
oder zu niedrig.
• Die Frage nach den Ursachen, d.h. die Konstellation der Kennzahlen gibt Anhalts-
punkte für die Gründe der Abweichungen.
6.1.2 Dimensionen für Kennzahlen
Als Dimensionen für die Kennzahlen zur Implementierung eines wissensbasierten Informations-
systems kommen eine direkte und die indirekte Betrachtungsweise in Frage. Die direkten Kenn-
zahlen bilden dabei das wissensbasierte Informationssystem selbst bzw. dessen Verwendung
durch die Nutzer ab. Mit ihnen kann die Frage beantwortet werden, ob und wie das Software-
system angenommen und genutzt wird. Die vollständige Annahme und Nutzung des Systems ist
als ein primäres Ziel zu sehen, so dass Kennzahlen, die dies bestätigen oder widerlegen, in der
Systematik inbegriffen sein müssen. Hohe Akzeptanzwerte lassen auch auf eine sinnvolle und
richtige Einbindung in die Prozesse schließen. Allein diese eher technischen Faktoren lassen
jedoch noch keinen Rückschluss auf einen Implementierungserfolg für das Unternehmen zu.
SEITE 126 INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS
Dafür muss das Softwaresystem auch im Prozessablauf gemäß den Zielen des Implemen-
tierungsmodells von den Mitarbeitern nutzbringend eingesetzt werden.
Diese Untersuchung der Prozesse bzw. des gesamten Unternehmensbereichs geschieht mit indi-
rekten Kennzahlen. Sie beziehen sich nicht auf das Softwaresystem selbst, sondern stellen Kenn-
größen der ausgeführten Prozesse dar. Die Kennzahlen sind individuell auszuwählen und fallen
in einem Entwicklungsbereich anders aus als in einem Fertigungsbereich oder in einem Dienst-
leistungsunternehmen. In den meisten Unternehmen werden Kennziffern wie Qualitätszahlen,
eine Personaleffizienz, Ressourcenverwendung o.ä. im Rahmen des standardisierten Controllings
betrachtet. Hier empfiehlt es sich, die Zahlen auszuwählen, auf die das wissensbasierte Informa-
tionssystem einen großen Einfluss hat. Der Vorteil liegt darin, dass sie nicht gesondert erhoben
werden müssen und dadurch mit geringem Aufwand zur Verfügung stehen.
Eine weitere wesentliche Ausprägung der indirekten Betrachtungsweise ist die Beobachtung der
Veränderungen in der Unternehmenskultur und im Umgang der Mitarbeiter untereinander. Der
Nachweis solcher Veränderungen wird erst gegen Ende des Implementierungsprojekts möglich
sein, da eine Kulturanpassung lange Zeiträume beansprucht. In Frage kommen beispielsweise die
Betrachtung der Art des Einbindens neuer Mitarbeiter oder Bestrebungen des Ausbaus des wis-
sensbasierten Informationssystems als eine „best practice“-Lösung über weitere Unternehmens-
bereiche oder andere Standorte. Das hier vorgestellte Implementierungsmodell ist durch das
gewählte Domino-Verfahren (vergleiche Kapitel 5.3.1) darauf ausgelegt, diese Schritte zu gehen
und zu begleiten, so dass die langfristige Sicht bei der Messung zu berücksichtigen ist. Weiterhin
kann auch die Quote der wechselwilligen Mitarbeiter einer Abteilung ein entscheidender Indi-
kator für ein gutes Arbeitsklima sein.
6.2 Nutzenmessung durch direkte Kennzahlen des wissensbasierten Informa-
tionssystems
In dem System der direkten Kennzahlen werden die Größen abgebildet, die das wissensbasierte
Informationssystem als solches betreffen. Dazu gehören in erster Linie die Auswertung von
protokollierten Nutzungsstatistiken und eine Befragung der Systemnutzer, inwieweit sie mit dem
Softwaresystem arbeiten können. Die Eigenschaften der Software selbst, wie etwa der Rück-
schluss auf eine Softwarekomplexität durch die Anzahl der Codezeilen und weiterer Faktoren,
sollen bei dieser Betrachtung nicht berücksichtigt werden. Es geht bei dem Implementierungs-
modell weniger um die Softwaretechnik, als vielmehr um die geeignete Unterstützung der Pro-
zesse.
6.2.1 Messung der Nutzung des Systems
Die Messung der Nutzung des Systems dient zur Beantwortung der Frage, inwieweit das Soft-
waresystem von den Mitarbeitern angenommen wird. Da das System zur Wissensteilung dient,
bietet sich die Analyse der Entwicklung der Zugriffe über den Zeitverlauf an. Für eine detail-
lierte Auswertung werden folgende Kennzahlen vorgeschlagen:
INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS SEITE 127
• Entwicklung der Anzahl der Systemabfragen pro Tag bzw. pro Woche: damit kann ge-
zeigt werden, wie häufig das wissensbasierte Informationssystem bei der Abarbeitung
von Prozessschritten genutzt wird.
• Wöchentliche Zugriffe je Mitarbeiter zu der Anzahl der Prozessdurchläufe: dieser Pro-
zentwert gibt an, wie häufig das System in der Abarbeitung der Prozesse eingesetzt
wird und ist ein Indiz für die Prozessintegration.
• Anzahl der neuen Einträge in das System pro Woche: Dies zeigt die Weiterentwicklung
der Software als Wissensbasis und lässt auf die Einbindung in den Prozess schließen.
• Auswertung der mitarbeiterspezifischen Zugriffe: Hier lässt sich ersehen, ob bestimmte
Mitarbeiter besonders häufig auf das Softwaresystem zurückgreifen. Später lässt sich
in persönlichen Mitarbeiterinterviews die Motivation für die Nutzung bzw. Nichtnut-
zung erfragen. Da es sich hierbei um eine personenbezogene Auswertung handelt, ist
hierzu ist die Zustimmung durch die Mitarbeiter und den Betriebsrat einzuholen.
• Auswertung der mitarbeiterspezifischen Neueinträge: Hier lässt sich erkennen, welche
Mitarbeiter besonders aktiv neue Einträge verfassen. Deren Motivation kann in Inter-
views erfragt werden mit dem Ziel, die übrigen Nutzer in eine ähnliche Motivations-
lage zu versetzen.
• Bestimmung der Qualität der Neueinträge anhand ihrer Wiederverwendungshäufig-
keit: Eine direkte Qualitätsbestimmung per Bewertung ist bei wissensorientierten Sys-
temeinträgen schwierig, da bereits ein kleiner Hinweis eine große Hilfe im Prozess
darstellen kann. Allerdings lässt sich annehmen, dass häufig verwendete Einträge eine
gewisse Qualität besitzen, da sie sich für die Nutzer als hilfreich erwiesen haben. Als
Alternative bietet sich die stichprobenartige Bewertung von Einträgen durch Experten
des jeweiligen Fachgebietes an, die einschätzen können, ob die Einträge sinnvoll ver-
fasst sind und potenzielle Hilfen darstellen.
• Entwicklung der Anzahl der eingereichten Verbesserungsvorschläge für das System:
Dies zeigt die aktive Arbeit und das Interesse der Mitarbeiter an dem Softwaresystem,
seiner Nutzung und seiner Gestaltung.
Viele dieser Kennzahlen können automatisiert über das wissensbasierte Informationssystem
erhoben werden. Dadurch sind sie leicht zu handhaben und „auf Knopfdruck“ zu erhalten.
Ebenso sind sie kontinuierlich ermittelbar, so dass sie über einen zeitlichen Verlauf ver-
gleichbare Ergebnisse liefern.
6.2.2 Befragung der Systemnutzer
Die Befragung der Systemnutzer in kurzen Interviews setzt an der Auswertung der direkten
Systemkennzahlen an. Die mitarbeiterspezifischen Analysen können nur dann verwendet wer-
den, wenn der Betriebsrat dem zugestimmt hat (vergleiche Kapitel 4.2 und 5.2.3 zur Beteiligung
des Betriebsrats). Die direkten Kennzahlen können als Gesprächsleitfaden dienen, indem sie als
Ansatzpunkte für die Interviews genutzt werden. Die Mitarbeiter können sich zu den Kriterien
äußern und ihre Sicht darstellen. Dadurch lassen sich auch wertvolle Erkenntnisse über die Mo-
tivation einzelner Personen liefern. Die Befragung selbst darf einen zeitlichen Umfang von 15
bis maximal 30 Minuten nicht überschreiten und die folgende Themen beinhalten:
SEITE 128 INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS
• Aufgreifen der aus der Auswertung des Softwaresystems ersichtlichen Motivationslage:
Das bedeutet die Erörterung der Einstellung zur Software und der Gründe für die Art
der Nutzung durch den Mitarbeiter.
• Erfassen von Verbesserungswünschen für das System: Zusätzlich zum Feedback-Pro-
zess werden die Mitarbeiter auf ihre Anregungen und Wünsche befragt.
• Überprüfung des Einführungskonzepts: Bei dem Interview wird die Frage gestellt, ob
die gewählte Vorgehensweise aus Sicht der Betroffenen zur Implementierung und zur
Einbindung der Mitarbeiter richtig und ausreichend war. Dadurch können wichtige
Rückschlüsse für den umfassenderen Einsatz des Softwaresystems gezogen werden.
• Analyse der Wissensteilung durch die Mitarbeiter: Im Interview wird erfragt, welche
Meinung die einzelnen Mitarbeiter zu der unternehmensweiten Wissensteilung wäh-
rend des Implementierungsprojekts entwickeln. Idealerweise wird die Einstellung ste-
tig positiver.
Eine solche Befragung scheint nach Abschluss jeder Phase des Phasenmodells (vergleiche Ka-
pitel 5.3) sinnvoll. Eine Befragung in kürzeren Zeitabständen ist nicht zu empfehlen, da sich die
Motivation nur langsam verändert und der Aufwand für die Interviews vergleichsweise groß ist.
Bei einer großen Nutzergruppe können auch Mitarbeiter für die Befragung per Zufallsprinzip
ausgewählt werden.
Die Rückschlüsse aus einer solchen Befragung müssen ebenso wie die Systemkennzahlen sofort
in die Projektdurchführung einfließen. Sämtliche geplante Maßnahmen müssen auf Basis der
Ergebnisse kritisch hinterfragt und nach Bedarf angepasst werden.
6.3 Beobachtung indirekt beeinflusster Kenngrößen
An dieser Stelle sind verschiedene Kennzahlen in Erwägung zu ziehen, die abbilden, welche
Einflüsse das wissensbasierte Informationssystem auf den anwendenden Initialbereich bzw. die
dort ablaufenden Prozesse hat. Diese Zahlen sollen nicht das Softwaresystem selbst evaluieren,
sondern seine Einbettung in Unternehmensprozesse. In Betracht kommen hier die Zusammen-
hänge mit dem Mitarbeiterverhalten, mit der Unternehmenskultur und mit den Kennzahlen der
beteiligten Organisationseinheiten.
6.3.1 Einflüsse der Implementierung auf die Mitarbeiter und die Unternehmenskultur
Die Einflüsse der Implementierung des wissensbasierten Informationssystems auf die Mitarbeiter
erscheinen auf den ersten Blick eher gering, da zunächst nur die Installation einer neuen Soft-
ware sichtbar ist. Dennoch sind die Neuerungen gravierend. Dies beginnt bei der Einbeziehung
der Mitarbeiter in das Projektteam und setzt sich fort über die Vermittlung der Wissensteilung.
Wichtig ist in dieser Phase die Beobachtung des Umgangs der Mitarbeiter untereinander, um die
Verhaltensänderungen in Bezug auf die Anwendung der Wissensteilung zu erkennen. Die Beo-
bachtungen erfolgen durch regelmäßige Gespräche der Projektleitung mit den Mitarbeitern, die
das wissensbasierte Informationssystem anwenden.
INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS SEITE 129
Als positiv sind insbesondere Berichte einzustufen, die darauf hindeuten, dass auch außerhalb
des Projektteams positiv über das wissensbasierte Informationssystem gesprochen wird. Daraus
kann gefolgert werden, dass ein großes Interesse besteht, die Mitarbeiter mit dem Erreichten
zufrieden sind und die Idee sowie das Projekt in weitem Kreis bekannt gemacht wird. Gleichzei-
tig ist dies ein Indiz dafür, dass sich die Mitarbeiter mit dem Projekt identifizieren und es als ihr
eigenes weiter vorantreiben wollen.
Weiter ist die Frage nach der Veränderung der Tätigkeiten der Mitarbeiter zu untersuchen. Ziel
ist es, sie in die Lage zu versetzen ihre eigene Arbeitsqualität dadurch zu steigern, dass sie das
Wissen anderer verwenden. Dabei ist nicht nur die Ergebnisqualität relevant, sondern auch die
Zeit, in der das Ergebnis erzielt wird. Die Veränderung drückt sich in einer Recherche im wis-
sensbasierten Informationssystem aus, die dazu führt, dass bei Bedarf gezielt ein hinterlegter
Ansprechpartner hinzugezogen wird. Eine weitere Tätigkeitsveränderung ist das selbstverständ-
liche Einpflegen von eigenen Wissensressourcen in das wissensbasierte Informationssystem.
Mit den Veränderungen der Tätigkeiten ist ein weiteres Ziel des Implementierungsprojekts die
Anpassung der Unternehmenskultur hin zu einer offenen und vertrauensvollen Zusammenarbeit.
Die Nachhaltigkeit dieser Veränderungen lässt sich an folgenden Punkten überprüfen:
• Anzahl und Einfluss der Verweigerer: Es ist nachzuhalten, ob und wie viele Mitarbeiter
von der Arbeitsweise nicht überzeugt sind. Je geringer deren Anzahl und je weniger
Einfluss sie auf andere Mitarbeiter nehmen, desto weitreichender ist die Kulturverände-
rung angenommen worden.
• Einarbeitung neuer Mitarbeiter: Ist die Kultur durchgehend angenommen worden, so
werden neue Mitarbeiter wie selbstverständlich an die wissensorientierten Arbeitswei-
sen herangeführt. Die Einarbeitungsphase von neuen Mitarbeitern ist daher sorgfältig
zu beobachten.
• Weitere wissensorientierte Folgeprojekte: Solche weiteren Projekte werden durchge-
führt, wenn eine Organisation von der wissensorientierten Arbeitsweise überzeugt ist.
Dies ist als positives Ergebnis der Implementierung zu betrachten, da die Resultate
weiter ausgeweitet werden sollen.
6.3.2 Verbesserung von Kennzahlen der Organisationseinheiten und Benchmarking
Die Implementierung eines wissensbasierten Informationssystems findet auch einen Nieder-
schlag in den Kennzahlen der Organisationseinheiten. Regelmäßig werden in Unternehmen über
ein standardisiertes Controlling Größen wie die Qualität, die Effizienz des Personal- und
Maschineneinsatzes oder die Auslastung beobachtet. Die Beeinflussung dieser Kennzahlen durch
das wissensbasierte Informationssystem kann nur schwer in absoluten Zahlen angegeben werden,
jedoch ist zu erwarten, dass sich durch die optimierte Arbeitsweise beispielsweise fehlerbedingte
Kosten senken lassen, das Qualitätsniveau ansteigt sowie die durchschnittliche Bearbeitungs-
dauer eines Prozesses reduziert wird. Die Auswahl entsprechender Größen muss in jedem Pro-
jekt individuell erfolgen.
Welche Größen über den Implementierungszeitraum hinweg betrachtet werden können, hängt
zum einen von der Art des Bereiches ab, in dem das wissensbasierte Informationssystem einge-
setzt wird (Fertigungsbereich, Entwicklungsbereich, Overhead, Dienstleistungen), und zum an-
SEITE 130 INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS
deren von den eingesetzten Controlling-Instrumenten. Wichtig ist, dass möglichst wenige neue
Kennzahlen erfasst werden müssen, da dies einen erheblichen Aufwand bedeutet.
Im Rahmen der Kennzahlenbetrachtung hilft für eine Einordnung der Ergebnisse die Durchfüh-
rung eines Prozess-Benchmarks. Unter dem Begriff Benchmark wird ein laut STEIN-
MANN/SCHREYÖGG [StSc05, S. 188] systematischer Abgleich von Ressourcen und Fähigkeiten
mit den besten bisher innerhalb oder außerhalb des Unternehmens erreichten Ergebnissen ver-
standen. Ein Prozess-Benchmark bedeutet damit die Sichtbarmachung von Stärken und Schwä-
chen eines Prozesses durch den Vergleich mit einem gleichen oder sehr ähnlichen Prozess in
einem anderen Unternehmen oder Unternehmensbereich. Für diesen Vergleich sind die Daten
von mindestens zwei Prozessen in definierten zeitlichen Abständen möglichst gleichzeitig zu
erheben.
In der ersten Phase der Implementierung ist das Auffinden von Vergleichsprozessen für einen
Benchmark vergleichsweise unkompliziert, da nur ein kleiner Teil des Unternehmens in das
Projekt einbezogen ist. In weiteren Phasen, in denen das Projekt eine größere Ausdehnung hat,
müssen Vergleichsprozesse auch in anderen Unternehmen gesucht werden, da intern bereits eine
zu große Beeinflussung stattgefunden haben kann.
Durch einen Vergleich der Prozesse mit Hilfe der o.g. Kennzahlen können Erkenntnisse über die
Auswirkungen des wissensbasierten Informationssystems auf den Prozess herausgelesen werden.
Dabei ist zu prüfen, welche weiteren optimierenden Maßnahmen parallel durchgeführt wurden,
um deren Einflüsse gegeneinander abgrenzen zu können.
6.4 Entwurf einer Implementierungs-Scorecard
Die Scorecard für die Implementierung leitet sich ab aus dem in Kapitel 3.4 dargestellten Kon-
zept der Balanced Scorecard. Es wird eine enge Verknüpfung zwischen den strategischen Zielen
bzw. der Vision des Implementierungsvorhabens (vergleiche Kapitel 5.2.1) zu den zuvor darge-
stellten Messgrößen (vergleiche Kapitel 6.2 und 6.3) hergestellt. Die hier vorgestellte Scorecard
für die Implementierung eines wissensbasierten Informationssystems verwendet die aufgezeigten
Kennzahlen zur Messung der Zielerreichung.
6.4.1 Aufbau der Implementierungs-Scorecard
Die Implementierungs-Scorecard ist parallel zu den Anforderungen der Balanced Scorecard
(vergleiche Kapitel 3.4.2) aus vier Perspektiven zusammen gesetzt, die sich aus den Zielen bzw.
dem Vorgehen bei der Implementierung ableiten. Sie fokussieren den Blick auf die Kernaspekte
und manifestieren sich in einer Mitarbeiterperspektive, einer Informationssystemperspektive,
einer Prozessperspektive und einer Unternehmenskulturperspektive.
Die Abbildung 62 zeigt die Perspektiven der Scorecard für das Implementierungsprojekt in einer
Übersicht. Die Perspektiven leiten sich aus den Forderungen für das Implementierungsvorgehen
ab, das besagt, es solle eine besondere Berücksichtigung der Mitarbeiterbedürfnisse, der Pro-
zesseinbindung, der Unternehmenskultur und des Informationssystems stattfinden (vergleiche
Kapitel 5.1).
INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS SEITE 131
Diese Scorecard deckt insbesondere die langfristige Zielverfolgung ab, da die kurzfristige Sicht
bereits durch das Nachhalten der einzelnen Teilziele im Projekt durch das Projektmanagement
abgedeckt ist. In diesen Perspektiven wird auf die Anführung einer Finanzperspektive wie bei
einer klassischen Balanced Scorecard verzichtet. Der Grund liegt darin, dass nur die Kostenseite
hinreichend genau zu erfassen ist und diese bereits mit den Hilfsmitteln des Projektmanagements
gesteuert werden kann. Die Implementierungs-Scorecard hat jedoch die Aufgabe, die Resultate
der Implementierung sichtbar zu machen und dadurch Ansätze für eine gezielte Steuerung zu
liefern. Eine Entscheidung für den Start eines Implementierungsvorhabens auf Basis der Kosten
ist grundlegender Natur und es darf nicht der Versuch einer Rechtfertigung mit monetären Er-
gebnissen angestrebt werden, da wie in Kapitel 3.4 dargestellt, die Bewertung von Wissen in
Finanzgrößen schwierig ist. Das führt zu einer falschen Fokussierung, da vielmehr das Wollen
und konsequente Durchhalten einer solchen Kulturveränderung Voraussetzung ist. Die Perspek-
tivengestaltung der Implementierungs-Scorecard ist ein Ausdruck der Prozessorientierung und
der Anwendung des TOM-Modells aus Kapitel 5.1.
Ziele des
Implementierungs-
projekts
Mitarbeiter-
perspektive
Informationssystem-
perspektive
Unternehmenskultur-
perspektive
Prozess-
perspektive
Quelle: Verfasser
Abbildung 62: Perspektiven einer Scorecard für die Implementierung
6.4.2 Vier Perspektiven der Implementierungs-Scorecard
Die vier Perspektiven werden jeweils mit charakteristischen Teilzielen und Kennzahlen belegt,
die sich aus den globalen Unternehmens- und Projektzielen ergeben. Wie bei einer Balanced
Scorecard genügen pro Perspektive wenige Kennzahlen um einen Informationsüberfluss zu
vermeiden. Diese Kennzahlen müssen sich kontinuierlich verfolgen lassen und stellen grafisch
aufbereitet eine Entscheidungsgrundlage für den weiteren Projektverlauf dar. Eine Übersicht
aller Perspektiven, Teilziele und zugehöriger Kennzahlen zeigt die Abbildung 63 am Ende dieses
Abschnitts.
SEITE 132 INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS
Perspektive Teilziel Kennzahl
Mitarbeiter leben die Wissensteilung Anzahl MA die in das IS einstellen
Mitarbeiter verwenden das IS aktiv MA die sich die letzten 8 Wochen
eingeloggt haben
MA empfinden die Implementierung
positiv positive Antworten in Befragung
Erhöhung der Problemlösungs-
kompetenz der MA positive Antworten in Befragung
Förderung durch das Management Führungskräften in Besprechungen
Systemnutzungsgrad Anzahl Login-Vorgänge insgesamt
Erreichbarkeit des Systems für die MA PC-Ausstattung
Benutzerfreundlichkeit positive Antworten in Befragung
Aufbau dokumentierter
Wissensressourcen Anzahl der neuen Eintragungen
Weiterentwicklung des IS Anzahl neuer Features
Fehlerreduktion in der Prozesskette Fehlerreduzierung
Verbesserung der Kennzahlenwerte
der Prozesse Anzahl verbesserter Kennzahlen
"Best of"-Prozesse im Benchmark Anzahl der "best of" Prozesse
aktive Beteiligung der MA eingereichte Verbesserungsvorschläge
Vertrauen der MA untereinander positive Befragungsantworten
Anlernen neuer MA nach
Wissenskriterien MA-/ Vorgesetztenbefragung
Etablierung des Feedback-Prozesses Anzahl durchgeführter Gespräche
offene Diskussionsatmosphäre Befragungsergebnisse
Mitarbeiter-
perspektive
Informations-
systemperspektive
Proze ss-
perspektive
Unternehmens-
kulturperspektive
MA: Mitarbeiter IS: Informationssystem
Quelle: Verfasser
Abbildung 63: Perspektiven, Teilziele und Kennzahlen der Implementierungs-Scorecard
Die Mitarbeiterperspektive zeigt auf, inwiefern die Menschen das Implementierungsprojekt und
das wissensbasierte Informationssystem annehmen. Mitarbeiter sind der wichtigste Faktor für
den Erfolg des Unternehmens und des Projekts (vergleiche TOM-Modell, Kapitel 5.1.1), so dass
mit dieser Perspektive begonnen wird. Die Verfolgung der Perspektive zeigt die Motivationslage
und die Annahme der neuen wissensorientierten Verhaltensweisen auf. Die Teilziele sind so
gewählt, dass der Fortschritt des organisationalen Lernprozesses sowie der Implementierung hin
zu einer wissensorientierten Arbeitsweise sichtbar wird.
Die Teilziele bilden mit ihren entsprechenden Kennzahlen den Umgang der Mitarbeiter mit dem
wissensbasierten Informationssystem und die Zufriedenheit mit der Implementierung ab. Zu-
sätzlich wird eine mögliche subjektive Erhöhung der Problemlösungskompetenz seitens der
Mitarbeiter sowie die Förderung durch das Management verfolgt.
Die Informationssystemperspektive spiegelt im Zusammenhang mit der Mitarbeiter- und Pro-
zessperspektive die Weiterentwicklung der Eigenschaften sowie die Nutzung des Softwaresys-
tems wider. Die Nutzungsgrade und das Verhalten der Nutzer geben Auskunft, inwiefern das
Informationssystem in die Prozesse eingebettet und von den Mitarbeitern akzeptiert wurde. Für
eine stichhaltige Beurteilung müssen die Ziele zu Beginn des Projekts sorgfältig gesetzt werden,
wobei sie insbesondere nicht zu hoch angesetzt sein dürfen. Die Inhalte können in ihrer Quantität
problemlos erfasst werden, wobei die qualitative Betrachtung schwieriger ist, da nur sehr schwer
zu bestimmen ist, wann ein Eintrag für einen anderen Mitarbeiter wertvoll ist. Insgesamt kann
INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS SEITE 133
aber davon ausgegangen werden, dass eine Erhöhung der Informationsbasis der Mitarbeiter zu
besseren Arbeitsergebnissen führt.
Die Perspektive stellt auch auf die Weiterentwicklung der Softwaresystemfeatures ab, da es sich
bei dem Implementierungsprojekt um eine kontinuierliche Aufgabe handelt und daher eine
Kennzahl zur Abbildung der Entwicklungsdynamik erforderlich ist. An dieser Stelle können mit
dem Softwarehersteller weitere individuelle Kenngrößen definiert werden.
In der Prozessperspektive wird im Zusammenhang mit der Informationssystemperspektive ver-
folgt, wie eng die Einbindung der wissensorientierten Arbeit in die Prozesse bzw. den Workflow
des Unternehmens ist (vergleiche geforderte prozessorientierte Einführung in Kapitel 5.1.2). Die
Aussagekraft dieser Perspektive ist besonders hoch, wenn ein Benchmark für vergleichbare
Prozesse durchgeführt wird und eine Aussage getroffen werden kann, wie sich die übrigen Pro-
zesse ohne die wissensorientierte Arbeitsweise weiter entwickelt haben. Hier kann ein Nachweis
geführt werden, dass der Einsatz des wissensbasierten Informationssystems die Prozessabläufe
optimiert.
Die Kennzahlen dieser Perspektive können in den meisten Fällen aus vorhandenen Controlling-
Instrumenten ausgewählt werden. Dabei muss eine Zahl enthalten sein, die die Ergebnisse der
Benchmark-Untersuchungen aufzeigt, wie beispielsweise Qualitäts- oder Auslastungskenn-
zahlen. So können die Ergebnisse in die langfristige Projektplanung einbezogen werden.
Die Unternehmenskulturperspektive hat die Aufgabe, die Nachhaltigkeit des Eingangs der wis-
sensorientierten Arbeit in die Unternehmung nachzuweisen und Korrekturen zu ermöglichen.
Mit Hilfe der Perspektive wird insbesondere die langfristige und zukunftsorientierte Sicht abge-
deckt, da wissensintensive Projekte die besten Ergebnisse aufweisen, wenn sie in die Kultur
übergegangen und in den Köpfen der Mitarbeiter fest verankert sind. Die Bedeutung des Ein-
gehens auf die Unternehmenskultur hat bereits das Change Management in Kapitel 5.4 darge-
stellt.
Daher werden die Ziele mittels Kennzahlen verfolgt, die im Rahmen einer Mitarbeiter- bzw.
Vorgesetztenbefragung erhoben werden. Die Interviews können bei der Unternehmenskultur-
perspektive in größeren zeitlichen Abständen erfolgen, da Veränderungen in der Kultur nur
langsam vonstatten gehen und nicht sofort messbar sind. Gleiches gilt auch für die Veränderung
von persönlichen Verhaltensweisen der Mitarbeiter und Vorgesetzten. Daher kann diese Per-
spektive auch Auskunft darüber geben, ob die im Implementierungsprojekt angewendeten Moti-
vationsinstrumente eine langfristige Wirkung entfalten, oder ob sie lediglich kurzfristig in einer
Steigerung der Kennzahlen der übrigen Perspektiven wirken.
6.4.3 Verfolgung der Kennzahlen
Zunächst wird für jede Kennzahl ein Startwert und ein Zielwert definiert. Der Startwert ist der
Wert zu Beginn des Implementierungsprojekts und wird dadurch einmalig festgelegt. Der Ziel-
wert wird ebenfalls am Anfang des Projekts ausgegeben und ist der Wert, der am Ende des
Implementierungsvorhabens erreicht werden soll. Ist der Umfang des Projekts sehr groß, kann es
auch sinnvoll sein, die Implementierungs-Scorecard auf einzelne Projektschritte auszurichten.
Dadurch werden die am Anfang unerreichbar scheinenden Ziele relativiert und realistischere
Teilziele für einen bestimmten Projektschritt angenommen.
SEITE 134 INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS
Quelle: Verfasser
Abbildung 64: Zielverfolgung mit der Implementierungs-Scorecard
Die Verfolgung der Kennzahlen muss regelmäßig durch ihre Erhebung durchgeführt werden, so
dass jeder Kennzahl ein Istwert zugeordnet wird. Als Zeitpunkt empfiehlt sich der Abschluss
Perspektive Teilziel Kennzahl Wert
Start
Wert
Ziel
Wert
Ist
Ziel in %
erreicht
Mitarbeiter leben die
Wissensteilung
Anzahl MA die in
das IS einstellen 02518
72%
Mitarbeiter verwen-
den das IS aktiv
MA die sich die
letzten 8 Wochen
eingeloggt haben
02522
88%
MA empfinden die
Implementierung
positiv
positive Antworten in
Befragung zur
Implementierung
02522
88%
Erhöhung der
Problemlösungskom
petenz der MA
positive Antworten in
Befragung zur
Kompetenz
02516
64%
Förderung durch
das Management
Führungskräfte in
Besprechungen 086
75%
Systemnutzungs-
grad
Anzahl Login-
Vorgänge insgesamt 0 250 197 79%
Erreichbarkeit des
Systems für die MA
PC-Ausstattung
086
75%
Benutzerfreundlich-
keit
positive Antworten in
Befragung 02517
68%
Aufbau dokumen-
tierter Wissens-
ressourcen
Anzahl der neuen
Eintragungen 150 225 212 83%
Weiterentwicklung
des IS
Anzahl neuer
Features 587
67%
Fehlerreduktion in
der Prozesskette
Fehlerreduzierung 856
67%
Verbesserung der
Kennzahlenwerte
der Prozesse
Anzahl verbesserter
Kennzahlen 0 8 4 50%
"Best of"-Prozesse
im Benchmark
Anzahl der "best of"
Prozesse 086
75%
aktive Beteiligung
der MA
eingereichte
Verbesserungs-
vorschläge
010 7
70%
Vertrauen der MA
untereinander
positive Befragungs-
antworten 02519
76%
Anlernen neuer MA
nach Wissens-
kriterien
MA-/ Vorgesetzten-
befragung 0 30 27 90%
Etablierung des
Feedback-
Prozesses
Anzahl
durchgeführter
Gespräche
086
75%
offene Diskussions-
atmosphäre
Befragungs-
ergebnisse 02517
68%
Mitarbeiter-
perspektive
Informations-
systemperspektive
Prozess-
perspektive
Unternehmens-
kulturperspektive
INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS SEITE 135
einzelner Phasen des Implementierungsprojekts, da so eine Überprüfung der Ergebnisse nach
einer abgeschlossene Projekteinheit entsteht. Bei jeder Erhebung wird die Scorecard aktualisiert,
so dass die Veränderungen der Kennzahlen im zeitlichen Verlauf sichtbar werden.
Im Ergebnis ergibt sich ein Zielerreichungsgrad, der angibt, welcher Prozentwert des Ziels be-
reits erreicht ist. Er errechnet sich aus der Differenz von Istwert zu Startwert und der Differenz
zwischen Ziel- und Startwert als Basis. Die Abbildung 64 zeigt ein Beispiel einer Implemen-
tierungs-Scorecard mit Startwerten, Zielwerten, Istwerten und Zielerreichungsgraden.
Für eine gute Übersichtsichtlichkeit werden die Zielerreichungsgrade in einer Grafik dargestellt.
Dazu bietet sich ein Netzdiagramm an, mit dem auf einen Blick die herausragend guten sowie
die verbesserungswürdigen Zielerreichungen identifizieren lassen. Die Abbildung 65 und
Abbildung 66 zeigen eine Darstellung der Zielerreichungsgrade gemäß Abbildung 64. Als Bei-
spiele werden hier die Zielerreichungsgrade der Mitarbeiter- und Informationssystemperspektive
aufgezeigt. Analog lassen sich diese Netzdiagramme auch für die Prozess- und Unternehmens-
kulturperspektive erstellen.
0%
25%
50%
75%
100%
Anzahl MA die in das IS
einstellen
MA die sich die letzten 8
Wochen eingeloggt haben
positive Antworten in
Befragung zur
Implementierung
positive Antworten in
Befragung zur Kompetenz
Führungskräften in
Besprechungen
Erreichungsgrad des
Ziels in %
Quelle: Verfasser
Abbildung 65: Zielerreichungsgrade der Implementierungs-Scorecard im Netzdiagramm am
Beispiel der Mitarbeiterperspektive
SEITE 136 INSTRUMENTARIUM ZUR MESSUNG DES IMPLEMENTIERUNGSERFOLGS
0%
25%
50%
75%
100%
Anzahl Login-Vorgänge
insgesamt
PC-Ausstattung
positive Antworten in
Befragung
Anzahl der neuen
Eintragungen
Anzahl neuer Features
Erreichungsgrad des
Ziels in %
Quelle: Verfasser
Abbildung 66: Zielerreichungsgrade der Implementierungs-Scorecard im Netzdiagramm am
Beispiel der Informationssystemperspektive
6.4.4 Zusammenhänge der Perspektiven
Die einzelnen Perspektiven der Implementierungs-Scorecard sind in einem engen Zusammen-
hang zu sehen. Zum einen ist eine zeitliche Wirkfolge zu sehen, d.h. eingeleitete Maßnahmen
werden in den Perspektiven nacheinander sichtbar, zum anderen ist ein inhaltlicher Zusammen-
hang gegeben.
Die Folge der Wirkungen ist in der Weise zu sehen, dass die Primärwirkung von Maßnahmen in
den Perspektiven „Mitarbeiter“ und „Informationssystem“ stattfindet. Daran anschließend wer-
den Auswirkungen in der Prozessperspektive und am Ende in der Unternehmenskulturperspek-
tive sichtbar. So müssen auch die Ergebnisse der Erhebungen interpretiert werden. Das bedeutet,
dass zu Beginn des Projekts nur geringe Auswirkungen in den beiden letztgenannten Perspekti-
ven nicht als Problem gedeutet werden dürfen. Erst dann, wenn in der Ausbauphase keine ein-
deutigen Veränderungen erkennbar sind, muss eine Neuplanung der Maßnahmen gedacht wer-
den.
Inhaltlich hängen alle Perspektiven miteinander zusammen, so dass eine isolierte Betrachtung
nicht sinnvoll ist, sondern nur das Gesamtbild entscheidend ist. Es darf nicht beunruhigen, wenn
eine einzelne Kennzahl aus dem Rahmen fällt. Es müssen jedoch die Ursachen hinterfragt wer-
den. Wenn eine gesamte Perspektive einen schlechten Zielerreichungsgrad aufweist, so ist dies
im Projektteam eingehend zu diskutieren und Lösungen sind zu erarbeiten.
PROTOTYPISCHE ANWENDUNG DES IMPLEMENTIERUNGSMODELLS SEITE 137
7 Prototypische Anwendung des Implementierungsmodells in der
Automobilindustrie
Alles was lebt, ist nur ein Versuch, ob es sich bewähren wird.
(Wilhelm Schwöbel)
Das Implementierungsmodell konnte im Rahmen seiner Entwicklung bei einem Automobil-
zulieferer prototypisch angewendet werden, so dass einige Erfahrungen aus der praktischen
Umsetzung bereits eingeflossen sind. Die Ergebnisse dieses realen Einsatzes gibt dieses Kapitel
wieder. Dazu werden zunächst die Rahmenbedingungen beleuchtet und im Anschluss daran die
Anwendung des Phasenkonzeptes sowie der begleitenden Prozesse aufgezeigt.
7.1 Rahmenbedingungen für die Durchführung des Implementierungsprojekts
Bei der Durchführung des Implementierungsprojekts gemäß Kapitel 5 spielen eine Vielzahl von
Umgebungsbedingungen im Unternehmen eine Rolle, die in der Analysephase offen gelegt
werden. Das sind Faktoren wie die Ausgangssituation im Unternehmen, die die Vorkenntnisse
der Mitarbeiter, zuvor durchgeführte wissensorientierte Projekte und das Unternehmen selbst
beschreibt. Zum anderen müssen die vom Management unter den genannten Voraussetzungen
gesetzten bzw. erwarteten Unternehmens- und Projektziele betrachtet werden.
7.1.1 Ausgangssituation im Unternehmen
Die Ausgangssituation im Unternehmen muss in drei unterschiedlichen Dimensionen angesehen
werden. Diese Dimensionen werden aus dem Standort, den Mitarbeitern und den Prozessen
gebildet. An dem Standort des Automobilzulieferers werden rund 1.000 Mitarbeiter in der Ent-
wicklung und Fertigung im Mehrschichtbetrieb beschäftigt. Parallel zu dem Standort, der den
Prototypen des wissensbasierten Informationssystems einführt, sind weitere Tochter- und
Schwesterunternehmen mit gleichen oder ähnlichen Produkten und Prozessen vorhanden. Die
gefertigten Produkte haben einen komplexen Aufbau und erfordern eine aufwändige Fertigungs-
struktur mit optimierten Abläufen hinsichtlich der Kommunikation und Zusammenarbeit über
Abteilungsgrenzen hinweg. Der Standort verfügt über keine Abteilung, die sich fachspezifisch
mit dem Thema Wissensmanagement befasst.
Die zweite Dimension der Mitarbeiter stellt sich so dar, dass vor dem Projekt der Implementie-
rung eines wissensbasierten Informationssystems kein durchgängiges und umfassendes Wis-
sensmanagementprojekt durchgeführt wurde. Es wurden vereinzelte wissensintensive Maßnah-
men wie eine Neugestaltung des Intranets oder abteilungsinterne Optimierungen in der Haltung
und Verteilung von digitalen Daten ausgeführt. Auf Seiten der Mitarbeiter ist nur von allgemei-
nen Kenntnissen in der Thematik Wissensmanagement auszugehen. Dem Management ist die
Bedeutung bewusst, was auch zu dem Start dieses Implementierungsprojekts geführt hat. Die
Mitarbeiter sind aufgrund des derzeitigen Wettbewerbsdrucks durch das Tagesgeschäft starken
Belastungen ausgesetzt, so dass zusätzliche Aufgaben nur in kleinem Umfang zumutbar sind
SEITE 138 PROTOTYPISCHE ANWENDUNG DES IMPLEMENTIERUNGSMODELLS
oder andere Aufgaben entfallen müssen. Oberste Priorität hat immer die Aufgabe der Erfüllung
der Produktionsvorgaben. Allgemein sind die Mitarbeiter als sehr offen und interessiert an neuen
Aufgaben und Innovationen einzustufen. Sie sind sehr zuverlässig und bringen in Projekten ihre
eigenen Ideen mit ein.
In der dritten Dimension der Prozesse kann davon ausgegangen werden, dass die vorhandene
Prozessstruktur für die Unterstützung durch ein wissensbasiertes Informationssystem geeignet
ist. Die Prozesse sind in ihrem Ablauf optimiert, so dass kein Business Process Reengineering
erforderlich ist. Dennoch bestehen im Rahmen der Weitergabe und Verteilung von Wissen er-
hebliche Potenziale. Dies ist vor allem dadurch begründet, dass die Mitarbeiter die vorhandene
Zeit mit einem wissensbasierten Informationssystem effizienter nutzen können.
7.1.2 Zielsetzungen des Projekts
Aus den gegebenen Rahmenbedingungen ergeben sich für das Implementierungsprojekt im
Zielfindungsprozess gemäß Kapitel 5.2.1 vielfältige Zielsetzungen, die in unterschiedlicher
Weise zu realisieren sind. Zunächst müssen erste Erfahrungen mit einem langfristig angelegten
wissensorientierten Projekt gesammelt werden, das die Mitarbeiter vollständig integriert. Ziel ist
es, in einem kleinen Rahmen eine innovative Technologie in Form des wissensbasierten Infor-
mationssystem mit einem Entwicklungspartner so weit zu entwickeln, dass es in großem Umfang
produktiv eingesetzt werden kann. Als Innovationsrahmen wurde dafür der wissensintensive
Bereich der Fertigung ausgewählt, bei dem langfristig markante Kennzahlen wie die Ausschuss-
quote, die Reaktionszeit und –qualität bei Störungssituationen, die Auslastung, die Produktivität
insgesamt und die Stillstandszeiten signifikant durch das wissensbasierte Informationssystem zu
verringern sind. Als erstes Einsatzgebiet des wissensbasierten Informationssystems kommt die
Unterstützung der Mitarbeiter bei der Analyse und Behebung von Störungen in Betracht, da dies
ein besonders wissensintensiver Prozess ist. Tritt eine Störung auf, so stellt dies immer ein gro-
ßes Problem für den Fertigungsprozess dar, das schnellstmöglich behoben werden muss. Hierzu
ist der kontinuierliche Austausch und die Dokumentation von Erfahrungswissen über alle Ferti-
gungsbereiche hinweg notwendig. Zur Wiederauffindbarkeit bietet sich die Sicherung des Wis-
sens anhand einer Produkt- und Prozessstruktur an. In einem weiteren Ziel soll die zu entwi-
ckelnde Systematik auch auf andere Standorte mit ähnlichen Prozessen und Produkten leicht
übertragbar sein.
Während der Entwicklung sind die Mitarbeiter durch eine weitreichende Beteiligung am Imple-
mentierungsprojekt an die Idee der übergreifenden Wissensteilung heranzuführen und davon zu
überzeugen. Gemeinsam mit den Mitarbeitern und dem Softwarehersteller ist das wissensbasierte
Informationssystem weiter zu entwickeln, auf die speziellen Bedürfnisse des Unternehmens
abzustimmen, wobei es aber flexibel anpassbar und damit universell einsetzbar bleiben muss.
7.2 Anwendung des Implementierungsmodells
Die aufgezeigten Rahmenbedingungen sind für den Einsatz des Implementierungsmodells gemäß
Kapitel 5 geeignet, da auf Basis von motivierten Mitarbeitern sowie einer sorgfältigen Prozess-
analyse die Anpassung und der anschließende Einsatz eines wissensbasierten Informations-
PROTOTYPISCHE ANWENDUNG DES IMPLEMENTIERUNGSMODELLS SEITE 139
systems erfolgt. Ebenso wird eine Skalierbarkeit des Projekts verlangt, da die Implementierung
stufenweise erfolgen soll. Das komplexe Vorhaben der Systemeinführung wird zunächst in
einem kleinen Unternehmensbereich erprobt und anschließend nach erfolgreichem Testlauf in
größerem Rahmen ausgeweitet.
Das hier vorgestellte Implementierungsprojekt hat die Analyse- und Pilotphase durchlaufen. Ein
weiterer Ausbau des wissensbasierten Informationssystems im Rahmen einer Ausbauphase ist
vorgesehen. Die Begleitprozesse sind ebenfalls, wie im Implementierungsmodell beschrieben,
getestet worden. Insbesondere können bereits vielfältige Erfahrungen in der Zusammenarbeit
aller intern und extern Beteiligten sowie zum Projektmanagement vermittelt werden.
7.2.1 Rolle des Projektmanagements und Phasenkonzepts
Das Projektmanagement ist wie in den Kapiteln 4.2 und 5.2.2 dargestellt für Implementierungs-
vorhaben eine wichtige Basis. Für das Implementierungsprojekt ist es essenziell, dass bei der
Projektleitung alle Informationen zusammenlaufen, damit die Aktivitäten koordiniert geplant
und ausgeführt werden können. Insbesondere die Abstimmung zwischen dem internen und ex-
ternen Projektmanager ist wichtig, damit die Aufgaben im gesamten Projektteam parallel und
zügig abgearbeitet werden. Der Projektmanager entscheidet, wie die zukünftigen Nutzer einbe-
zogen werden und informiert das Management über den Fortschritt des Projekts.
Daraus ergibt sich eine sehr vielschichtige Tätigkeit, die auch die Absprache der Aktionen mit
der Muttergesellschaft und die Klärung von rechtlichen Fragen mit dem Softwarehersteller bein-
haltet. Die Termine sind zu koordinieren und Mitarbeiter bzw. das Management regelmäßig zu
informieren. Je nach Umfang des Projekts sollte der Projektmanager mindestens die Hälfte der
Arbeitszeit ausschließlich für die Projektleitungsaufgaben zur Verfügung haben. Unter dieser
Bedingung ist eine Einhaltung der drei klassischen Ergebnisgrößen Qualität, Kosten und Zeit zu
erwarten.
Die Analysephase des Implementierungsprojekts konzentrierte sich auf zwei wesentliche Kern-
punkte. Zunächst dominierte die Klärung von internen Fragestellungen, wie die Abschätzung der
Wirtschaftlichkeit des Projekts und die Koordination der Aktivitäten mit der Muttergesellschaft.
Ein weiterer wichtiger Aspekt ist die Auswahl eines geeigneten Softwareherstellers. Hierbei
muss nicht nur der Markt sondiert werden, sondern es sind auch frühzeitig Fragen zur Geheim-
haltung und den weitergehenden Verwendungsrechten an den Projektergebnissen zu klären.
Durch die Vielzahl der beteiligten Personen und Stellen im Unternehmen darf der zeitliche und
organisatorische Aufwand nicht unterschätzt werden.
Der zweite Kernpunkt ist die Analyse der Prozesse, die auch die Ermittlung von Arbeitsabläufen,
die Beobachtung von Besprechungen und die Untersuchung von Dokumentenflüssen beinhaltete.
Durch diese Vorgehensweise konnte ein Initialeinsatzbereich in der Fertigung identifiziert wer-
den, dessen Mitarbeiter hochgradig innovativ und konzentriert mitgearbeitet haben. Der hohe
Zeit- und Überzeugungsaufwand kann als sinnvoll eingesetzt beschrieben werden.
Es hat sich während der Implementierung herausgestellt, dass es von großem Vorteil ist, den
Softwarehersteller bereits frühzeitig in das Projekt zu integrieren. Die Prozessanalyse konnte mit
ihm gemeinsam durchgeführt werden, da er sein Produkt genau kennt und weiß, auf welche
Details bei der Untersuchung zu achten ist. Dadurch können spätere Nacharbeiten oder gar Dop-
SEITE 140 PROTOTYPISCHE ANWENDUNG DES IMPLEMENTIERUNGSMODELLS
pelarbeiten wirksam vermieden werden. Gleichzeitig werden die Mitarbeiter des Software-
herstellers durch ihre Analysetätigkeit im Haus intern bekannt. Die Arbeiten müssen von der
internen und externen Projektleitung sorgfältig abgestimmt sein. Zur Sicherung und Abstimmung
der Ergebnisse wurden sie auf allen Ebenen mehrfach präsentiert und diskutiert. Bei diesen
Präsentationen muss konsequent auf die Intention des Projekts in Form der Wissensteilung hin-
gewiesen werden. Dadurch wird das Projekt verständlicher und von den Mitarbeitern akzeptiert.
Während der Pilotphase gilt es, die Erkenntnisse aus der Analysephase umzusetzen. Hierbei tritt
auch die technische Entwicklung in den Vordergrund. Es ist sicherzustellen, dass ein Server für
das wissensbasierte Informationssystem zur Verfügung steht und im Initialbereich alle Mitar-
beiter über einen PC einen Zugang zu dem System erhalten. Die Erfahrung aus dem Projekt hat
gezeigt, dass die Nutzer regelmäßig über den Entwicklungsstand der Software informiert werden
wollen, da sie so ihre Ideen sofort einbringen können, was zu einer breiten Akzeptanz geführt
hat. Es ist in der Pilotphase mit einer eher geringen Anzahl Softwarefeatures zu arbeiten, um die
Komplexität gering und die Übersichtlichkeit hoch zu halten. Es kommen in den Diskussions-
runden sehr viele Ideen auf, die auch prinzipiell umsetzbar erscheinen, dennoch sollte dies nach
der erfolgreichen Realisierung der ersten Schritte geschehen.
In Absprache mit den späteren Nutzern sind für Testzwecke einige Initialdaten und eine grobe
Struktur in das wissensbasierte Informationssystem einzupflegen. Eine große Menge an Daten ist
nicht hilfreich, da sie schnell zu einer unübersichtlich Struktur führen und den Nutzern den
Freiraum für die Entwicklung einer eigenen Strukturierung nimmt. Die Entwicklung der Wis-
sensteilung lässt sich anhand eines Systems mit wenigen Vorgaben und Datensätzen am besten
verfolgen.
Bewährt hat sich die Einrichtung eines intensiven Feedback-Prozesses mit regelmäßiger und
direkter Ansprache der Initialnutzer. Dadurch lassen sich wichtige und detaillierte Rückmel-
dungen zum Implementierungsvorgehen und zur Software erfragen. Weitere Maßnahmen zur
Motivation oder intensiveren Schulung sind nach Abschluss der ersten Testphase und nach
Auswertung der Implementierungs-Scorecard gezielt durchzuführen.
Die geplanten Zeiträume für die Projektschritte dürfen nicht zu kurzfristig ausgelegt sein, da sich
im durchgeführten Projekt gezeigt hat, dass die erste Version der Software nach der Vorstel-
lungsrunde mit den Nutzern erneut angepasst werden musste. Es können trotz aller Vorbereitun-
gen nicht alle wichtigen Punkte zu Beginn integriert sein, so dass eine Überarbeitungsschleife
grundsätzlich erforderlich ist. Eine Einführung in den Produktivbetrieb ist nur dann sinnvoll,
wenn die Funktionalität der Initialfeatures voll gegeben ist.
Für die Ausbauphase und Vollbetriebsphase ist geplant, die in der Pilotphase getesteten und
optimierten Komponenten in eine breite Anwendung zu bringen. Dies ist zum einen die Aus-
weitung auf alle Fertigungsbereiche zunächst innerhalb eines Standorts und im weiteren Verlauf
auch auf weitere Standorte. Die notwendigen technischen Strukturen wurden von Beginn an
entsprechend aufgebaut. Die Vorgehensweise wird weiterhin auf der Unterstützung der Prozesse
basieren, wozu in den weiteren Bereichen möglicherweise erneute Prozessbetrachtungen not-
wendig werden. Aufgrund der sehr positiven Motivation der Mitarbeiter kann davon ausgegan-
gen werden, dass dieses Vorhaben erfolgreich verläuft.
Für die Durchführung der weiteren Phasen müssen sich allerdings die wirtschaftlichen Rahmen-
bedingungen innerhalb des Unternehmens verbessern, da eine wissensorientierte Arbeit während
PROTOTYPISCHE ANWENDUNG DES IMPLEMENTIERUNGSMODELLS SEITE 141
einer Unsicherheitsphase nicht möglich ist. Die Motivation der Mitarbeiter konzentriert sich in
einem solchen Zeitraum auf die Aufrechterhaltung ihres Arbeitsplatzes, so dass weitergehende
Projekte kaum durchführbar sind.
7.2.2 Das Change Management
Das Change Management gemäß Kapitel 5.4 konnte sich in den ersten Projektphasen auf die
intensive Information und die Einbeziehung der Initialnutzer beschränken. Die Mitarbeiter waren
bereits von sich aus sehr motiviert und haben selbst die Notwendigkeit eines wissensbasierten
Informationssystems mit der damit verbundenen Arbeitsweise erkannt. Ein weiterer Motiva-
tionsanreiz erschien bei der prototypischen Einführung nicht erforderlich. Zusätzlich zeigten alle
Beteiligten ein hohes Interesse an der Technik, so dass der daraus resultierende „Spieltrieb“ zu
einem höheren Verständnis des Softwaresystems führt.
Das wissensbasierte Informationssystem wurde durch die integrative Informationspolitik von den
Mitarbeitern nicht als Belastung, sondern als Herausforderung empfunden. Die Projektbeteiligten
haben von sich aus weitere Personen aus ihrer Abteilung in die wissensorientierte Arbeit einge-
bunden und die Idee weiter kommuniziert. Daher waren in dieser Richtung keine weiteren Maß-
nahmen notwendig. Der aktive Feedback-Prozess und die Schulung der Mitarbeiter in der Nut-
zung des Systems haben die Ziele erreicht. Die Schulungsmaßnahme konnte parallel mit der
Systempräsentation durchgeführt werden, indem jeder Teilnehmer selbst testen konnte und
auftauchende Fragen sofort beantwortet wurden. Im weiteren Verlauf stand die Projektleitung
stets für den Systemsupport zur Verfügung. Durch die angespannte wirtschaftliche Lage ist der
Prozess der Einführung nach der Initialeinführung aufgrund anderweitiger Aufgaben der Mitar-
beiter ausgesetzt worden, so dass das Projekt nach der Stabilisierung der Lage fortgeführt wer-
den kann.
Im weiteren Verlauf des Implementierungsprojekts ist in der Ausbauphase fraglich, ob alle wei-
teren Mitarbeiter ebenso motiviert die Wissensteilung voran treiben. Hier gilt es, schon früh
Überzeugungsarbeit mit Hilfe der Mitarbeiter aus der Pilotphase zu leisten und auf die vorhan-
denen Erfolge zu verweisen. Im Rahmen dieser Vorgehensweise ist die Chance groß, dass so-
wohl das Softwaresystem als auch die wissensorientierte Arbeitsweise Eingang in die Kultur des
Unternehmens finden. Die rege Beteiligung auf Seiten der Mitarbeiter und das große Interesse
im Management und bei der Muttergesellschaft lassen darauf schließen, dass auch weitere „Wis-
sensprojekte“ folgen werden und den Prozess weiter stützen. Die Ausrichtung des Standorts als
Innovationsschwerpunkt ist ebenfalls hilfreich.
7.2.3 Die Zusammenarbeit mit dem Softwarehersteller
Die Zusammenarbeit mit dem Hersteller der Software trägt wesentlich zum Erfolg des Projekts
bei. Grundlage muss eine detaillierte und von beiden Seiten gezeichnete Geheimhaltungserklä-
rung sowie eine Regelung der Verwendungsrechte an den Projektergebnissen sein. Mit einer
soliden Vertrauensbasis wurde der Softwarehersteller schon frühzeitig in der Analysephase
eingebunden und bekam auch Zugang zu internen Besprechungen und Dokumenten. Dadurch
konnte er sich ein eigenständiges Bild der Prozesse machen und seine Software darauf optimal
abstimmen.
SEITE 142 PROTOTYPISCHE ANWENDUNG DES IMPLEMENTIERUNGSMODELLS
Im Verlauf des Implementierungsprojekts hat es sich als günstig erwiesen, wenn regelmäßig
Mitarbeiter des Softwareherstellers im Haus an Projektbesprechungen und weiteren Routine-
runden teilnehmen. Dadurch sind die Personen keine unbekannten Größen mehr und können als
direkte Ansprechpartner für Verbesserungswünsche fungieren. Die Integrität im Projektteam
erhöht sich und führt im Idealfall zu einer positiven Arbeitsatmosphäre. Daher bietet es an, mit
einem Anbieter zusammen zu arbeiten, der seinen Sitz in der gleichen Region hat und die Mitar-
beiter regelmäßig im Haus sein können. Darüber hinaus sind wöchentliche telefonische Abstim-
mungen der internen und externen Projektleitung notwendig.
Eine sinnvolle Maßnahme sind Zwischenpräsentationen während der Entwicklungszeit zusam-
men mit dem gesamten Projektteam und dem Softwarehersteller mit anschließender Diskussion
des aktuellen Stands. Durch die rege Diskussion mit den späteren Anwendern konnten wichtige
Erkenntnisse für die Weiterentwicklung gewonnen werden. Zudem ist es für die Mitarbeiter sehr
motivierend zu sehen, dass ihre Wünsche und Ideen ernst genommen, sofort aufgegriffen und
eingearbeitet werden.
7.2.4 Die Messung des Systemnutzens
Die Messung des Systemnutzens ist ein wesentlicher Baustein zur Steuerung des Implemen-
tierungsprojekts. Entscheidungen können so begründet werden und der Erfolg nach Durch-
führung der Maßnahmen ist nachvollziehbar. Die Ergebnisse der Messung sind nur als ein Bau-
stein der Entscheidungsfindung zu sehen und werden durch die übergeordneten Ziele und sub-
jektive Eindrücke ergänzt. Im hier dargestellten Implementierungsprojekt beginnt die Anwen-
dung der Implementierungs-Scorecard gegen Ende der Pilotphase.
Die vollständige Nutzung der Implementierungs-Scorecard gemäß der Vorgehensweise aus
Kapitel 6 mit den darin enthaltenen Kennzahlen konnte aufgrund des zwischenzeitlichen Pro-
jektstopps nicht mehr durchgeführt werden. Im weiteren Verlauf ist es notwendig, die Imple-
mentierungs-Scorecard nach jeder Projektphase zu erheben. Mittels eines Vergleichs der im
Zeitverlauf gesammelten Scorecards kann der Implementierungserfolg kontinuierlich nachge-
wiesen werden.
7.3 Zusammenfassende Betrachtung der industriellen Praxis
Die Durchführung des Implementierungsprojekts nach dem vorgestellten Modell erbrachte wert-
volle Erkenntnisse. Die Vorbereitungen für die Implementierung müssen sorgfältig erfolgen und
erfordern mit allen Abstimmungsrunden leicht einen großen zeitlichen Umfang. Nach dem Start
des Projekts ist es zu vermeiden, dass die Planung der Ressourcen in der Analysephase zu knapp
erfolgt. Ein solcher Fehler macht sich insbesondere dann bemerkbar, wenn sich ein kreatives und
entwicklungsfreudiges Projektteam gebildet hat, dass viele neue Ideen entwickelt, die zuvor
nicht eingeplant waren. Mit einem großen Ideenumfang ist in der Entwicklungsphase jedoch zu
rechnen, so dass Zeit- und Personalressourcen großzügig einzuplanen sind.
Die Einteilung des Projekts gemäß dem Phasenkonzept hat sich als eine gute Strukturierung
herauskristallisiert, nach der das Vorgehen sinnvoll unterteilt wird. Bereits in der Pilotphase
können die Systemkomponenten getestet und optimiert werden, so dass einer Ausweitung des
PROTOTYPISCHE ANWENDUNG DES IMPLEMENTIERUNGSMODELLS SEITE 143
Systemeinsatzes nichts mehr entgegensteht. Die Idee der Wissensteilung ist im Unternehmen
stark akzeptiert worden und wurde von den Mitarbeitern sogar aktiv gewünscht, so dass die im
Implementierungsmodell vorgeschlagenen intensiven Fördermaßnahmen nicht eingesetzt werden
mussten.
Die Erfahrungen aus dem Implementierungsprojekt haben gezeigt, dass es wichtig ist, das wis-
sensbasierte Informationssystem während der Pilotphase schnellstmöglich in den Produktiv-
betrieb zu bringen, um Erkenntnisse aus dem Praxiseinsatz für die Weiterentwicklung gewinnen
zu können. Während der Analyse- und Pilotphase konnten viele Anregungen gesammelt werden,
deren Umsetzung in einem Zeitraum vor dem Produktivbetrieb nicht vollständig möglich war. Es
ist notwendig, das Softwarepaket in einen Testlauf zu bringen und währenddessen die Weiter-
entwicklung voranzutreiben. Ohne die Erkenntnisse aus dem Praxiseinsatz kann die Entwicklung
nicht gezielt vorangetrieben werden.
Keinesfalls darf in frühen Phasen des Projekts die Arbeit auf Kosten der nachhaltigen Ergebnisse
zu schnell vorangetrieben werden. Fehler oder Unzulänglichkeiten in der Analysephase können
sich in späteren Stadien stark negativ auswirken bis hin zu einer in die falsche Richtung ent-
wickelten Software.
Der Erfolg des Projekts ist sehr stark von dem Vertrauensverhältnis zwischen Unternehmen und
Softwarehersteller abhängig. Hilfreich ist die frühzeitige Klärung rechtlicher Fragen sowie eine
klare Zuordnung von Arbeitspaketen zu einem der beiden Partner. Die Einhaltung der abge-
stimmten Terminschiene ist auf beiden Seiten Voraussetzung erfolgreicher Zusammenarbeit.
SEITE 144 PROTOTYPISCHE ANWENDUNG DES IMPLEMENTIERUNGSMODELLS
ZUSAMMENFASSUNG SEITE 145
8 Zusammenfassung und Ausblick
Der einst an seinen Freund schrieb:
„Ich habe nicht die Zeit gehabt, mich kürzer zu fassen“,
wusste, dass in der Kunst der Darstellung nicht das Viele,
sondern das Wenige schwer ist.
(Joachim Johann Winckelmann)
8.1 Ausgangspunkt der Arbeit
Den Ausgangspunkt der Arbeit bilden zwei Extreme. Auf der einen Seite werden in der Literatur
sehr viele Konzepte zur Einführung einer Standardsoftware beschrieben, die gleichzeitig erheb-
liche Einschnitte in den Aufbau und die Funktionsweise bedeuten. Auf der anderen Seite dage-
gen werden vielfältige Skizzen für das Wissensmanagement aufgezeigt, die zur Erreichung eines
optimierten Umgangs mit Wissen darauf abzielen, vor allem die weichen Faktoren, also die
Eigenschaften von und den Umgang mit Menschen und deren Wissen, zu stimulieren. Gleich-
zeitig drängen in der heutigen Zeit immer mehr Softwareprodukte auf den Markt, die als wis-
sensbasierte Informationssysteme eine Unterstützung in der wissensorientierten Arbeit ver-
sprechen.
In diesem Umfeld gibt diese Arbeit eine Hilfestellung, wie ein wissensbasiertes Informations-
system konsequent und nachhaltig in einem Unternehmen eingesetzt werden kann. Es werden
bekannte und bewährte Einführungskonzepte aus der Umgebung der Standardsoftware aufgegrif-
fen und in Verbindung mit den Erkenntnissen der Wissensmanagementforschung zu einem
durchgehenden Implementierungskonzept für wissensbasierte Informationssysteme weiterent-
wickelt. Diese Arbeit bildet im Vergleich zu den bekannten Konzepten einen neuen Ansatz, der
eine möglichst umfassende Integration der Systemnutzer schon während der Implementierungs-
phase erlaubt und in seiner Durchführung die wissensorientierte Softwareintegration deutlich
beschleunigt.
8.2 Methodisch konzeptionelle Vorgehensweise
Die vorliegende Arbeit verfolgt eine anwendungsorientierte Herangehensweise an die Aufgabe
der Implementierung eines wissensbasierten Informationssystems. In der Analyse der bestehen-
den Forschungsansätze werden zunächst drei Ziele verfolgt. In einem ersten Schritt werden die
bestehenden Ergebnisse der Wissensmanagementforschung auf die Tauglichkeit für die Anwen-
dung in einem Implementierungsmodell geprüft. In diesem Zusammenhang wird auch der zweite
Schritt, die Untersuchung der Ansätze zur Messung von Ergebnissen der Arbeit mit Wissen,
durchgeführt. Daran anschließend werden in einem dritten Schritt die Vorgehensmodelle für die
Implementierung von Standardsoftware-Systeme dahingehend untersucht, welche Teile der
Verfahrensweisen für wissensbasierte Informationssysteme geeignet sind.
SEITE 146 ZUSAMMENFASSUNG
Aus dem großen Bereich der Wissensmanagementforschung werden insbesondere die Ansätze
der lernenden Organisation und der Unternehmens- und Wissenskultur herangezogen, um eine
Grundlage für die Arbeit mit einem wissensbasierten System zu legen. Zusammen mit den bisher
eingesetzten Werkzeugen zeigen sie auf, dass sich die Gestaltung der Systemeinführung eng an
den Erfordernissen der Mitarbeiter orientieren muss. Die Intention des TOM-Modells von
BULLINGER wird aufgegriffen, indem die drei Dimensionen Technik, Organisation und Mensch
im Implementierungsmodell parallel betrachtet werden. Dabei legt das Modell im Gegensatz zu
den bisherigen Annahmen Wert auf eine Anwendung von Personalisierungs- und Kodifizie-
rungsstrategie mit dem wissensbasierten Informationssystemen. Es können nur einige Teile des
Wissens kodifiziert werden, für den weitaus größeren Teil soll durch das Informationssystem der
persönliche Austausch angeregt werden.
In dem Bereich der Systemimplementierung werden die Projektstrukturen für Standardsoft-
wareimplementierungen weiter entwickelt, dadurch dass die Ansätze wie beispielsweise der von
GRONAU dahingehend ergänzt und verändert werden, dass sie für diesen Anwendungszweck eine
deutlich stärkere Einbindung der betroffenen Mitarbeiter, d.h. der künftigen Systemnutzer, be-
nötigen. In den vier vorgeschlagenen Einführungsphasen Analysephase, Prototypenphase, Aus-
bauphase und Vollausbau werden die Mitarbeiter mit einem durchgängigen Change Management
durch regelmäßige Beteiligung an der Systementwicklung und stetige Informationen über den
Systemfortschritt für die Ziele des Wissensmanagements sensibilisiert. Dies drückt sich auch in
kontinuierlichen Anpassungen der vor Ort stattfindenden Prozesse aus, die die Systemnutzung
nach kurzer Zeit selbstverständlich machen.
Zur konsequenten Verfolgung der Projektziele wird ein Konzept zur Messung des Systemnut-
zens vorgeschlagen, das mehrere Instrumente zur Beobachtung und Verifizierung der Ergebnisse
nutzt. Es werden zum einen Kennzahlen vorgeschlagen, die sich direkt auf das System beziehen,
beispielsweise die Anzahl der Nutzer, die Einträge pro User oder die Zahl der Abrufe von Ein-
tragungen. Zum anderen werden indirekte Kennzahlen herangezogen, die sich auf den Bereich
des Unternehmens und die Beteiligung bzw. die innere Einstellung der Mitarbeiter beziehen.
Das Konzept wird abgeschlossen durch eine Überprüfung des Implementierungsmodells im
Praxiseinsatz in der Industrie. In diesem Teil werden die oben ermittelten Vorgehensweisen auf
Tauglichkeit und Erfolg getestet.
8.3 Inhaltliche Ergebnisse
Das Ergebnis der Arbeit ist eine strukturierte Vorgehensweise zur Implementierung eines wis-
sensbasierten Informationssystems in den industriellen Prozesskontext. Durch die Darstellung
und Anwendung eines mitarbeiterorientierten Change Managements im Rahmen eines langfristig
angelegten Implementierungsprojekts gelingt es, wissensbasierte Informationssysteme in eine
Organisation einzuführen. Diese Art der Vorgehensweise stellt sicher, dass dadurch nicht nur das
Informationssystem, sondern im Sinne eines durchgängigen Wissensmanagements, auch die Idee
einer gemeinsamen wissensorientierten Arbeit durch die Mitarbeiter aktiv gelebt werden kann.
Insofern kann das Informationssystem als eine Art Mittel zum Zweck angesehen werden, indem
es unterstützend wirkt durch die Schaffung eines Bewusstseins für das eigene Wissen und das
Wissen anderer Mitarbeiter.
ZUSAMMENFASSUNG SEITE 147
Der zentrale Gedanke bei allen Teilen der Arbeit liegt darin, Betroffene zu Beteiligten zu
machen. Durch diese Herangehensweise werden die Mitarbeiter schon während der Analyse-
und Prototypenphase in die Gestaltung des Systems eingebunden und können ihre eigenen Ideen
einbringen. Sie sind diejenigen, die ihre eigenen Bedürfnisse am besten kennen und bekommen
durch die Realisation ihrer Vorstellungen eine besondere Motivation zur Arbeit mit dem wis-
sensbasierten Informationssystem. Die bei Standardsoftwareimplementierungen häufig anzutref-
fenden Akzeptanzprobleme können somit vermieden werden.
Das Implementierungskonzept in vier Stufen fördert Mitarbeiterbeteiligung, da von vornherein in
den Stufen beispielsweise Workshops zur Systemgestaltung und regelmäßige Reviews mit den
Initialnutzern vorgesehen sind. Die Erkenntnisse aus diesen Konferenzen fließen direkt zurück
zu der Systementwicklung und können zeitnah geprüft und umgesetzt werden. Durch diese
hochflexible Gestaltung werden hohe Anforderungen an das Projektmanagement und an die
Softwareentwickler gestellt, wobei der große Vorteil aber in dem Wegfall von langwierigen und
aufwändigen Anpassungsmaßnahmen an einem fertigen System im Nachhinein wie bei Stan-
dardsoftware entfallen können.
Zur Erreichung einer hohen Flexibilität setzt die vorgestellte Projektorganisation darauf, in
einem interdisziplinären Team die Implementierung in einem kurzen Zeitrahmen zu realisieren.
Die Mitglieder aus verschiedensten Abteilungen und Organisationseinheiten des Unternehmens
können von vornherein ihre Wünsche und Anregungen in das Projekt einbringen, so dass spätere
Änderungen aufgrund von nicht beachteten Erfordernissen auf ein Minimum reduziert werden
können. Zusätzlich ist das Projekt langfristig ausgerichtet und sieht eine laufende Optimierung
vor. Stillstand ist bekanntlich Rückschritt, so dass auch das wissensorientierte Informations-
system einer ständigen kritischen Hinterfragung vor allem durch die Systemnutzer bedarf.
Gleichzeitig werden immer wieder die Prozesse auf den Prüfstand gestellt und bei Bedarf ange-
passt. In der langen Sichtweise lassen sich auch Erfolge in einer wissensorientierten Verände-
rung der Unternehmenskultur beobachten. Durch das Vorleben von Verhaltensweisen werden
beispielsweise ein Wissensaustausch selbstverständlich. Zusätzlich lässt sich mit zunehmenden
technischen Möglichkeiten auch die technische Integration weiter voran treiben. Dies berück-
sichtigt die Forderungen der Wissensmanagementforschung, dass wissensorientierte Projekte
eine laufende Betreuung erfordern.
Möglich ist die erfolgreiche Implementierung immer nur dann, wenn der klare Wille kommu-
niziert wird, das Unternehmen konsequent in eine Kultur der wissensorientierten Arbeitsweise zu
führen. Das bedeutet, es sind im Vorfeld nicht nur die Projektziele zu definieren, sondern auch
die Unternehmensziele entsprechend auszurichten. Die Messung der Zielerreichung wird durch
die Implementierungs-Scorecard gesichert, die ein rechtzeitiges Gegensteuern bei nicht zufrie-
denstellenden Ergebnissen in einer ihrer vier Dimensionen erlaubt.
Das Gesamtergebnis lässt auch die Feststellung zu, dass sich die Aussagen beispielsweise des
TOM-Modells von BULLINGER bestätigen. Eine softwaretechnische Installation und Bereit-
stellung eines wissensbasierten Informationssystems allein hinterlässt keine spürbare Wirkung
auf den Unternehmenserfolg und die Unternehmenskultur. Es bedarf immer auch einer sorgfäl-
tigen Berücksichtigung und Aufnahme der Mitarbeiterinteressen und einer Abstimmung der
Vorgehensweise auf die bereits gelebte Kultur sowie die bestehenden Prozesse und organisato-
rischen Gestaltungsmerkmale.
SEITE 148 ZUSAMMENFASSUNG
8.4 Weiterer Forschungsbedarf
Die hier vorliegende Arbeit zeigt ein Verfahren zur Implementierung eines wissensbasierten
Informationssystems auf. Dieser Leitfaden berücksichtigt die Rahmenbedingungen organisato-
rischer und konzeptioneller Art sowie vor allem die Bedürfnisse der Menschen, die mit dem
wissensbasierten Informationssystem arbeiten und es zum Leben erwecken. Es zeigt sich, dass
ein weiterer Forschungsbedarf im Bereich der technischen Systemintegration besteht. Unterneh-
men betreiben heute eine Vielzahl von informationsverarbeitenden Systemen, aus denen wich-
tige Informationen für Mitarbeiter in wissensintensiven Systemen bereitgestellt werden können.
Diese Arbeit berücksichtigt in ihrem Konzept zwar die generelle Ausrichtung des wissens-
basierten Informationssystems an den bestehenden DV-Systemen, für eine vollständige techni-
sche Integration bedarf es aber noch einer systematischen Aufarbeitung, wie vorhandene Sys-
temstrukturen in wissensbasierte Informationssysteme integriert werden können. Mittels einer
solchen Methodik besteht die Möglichkeit, das wissensbasierte Informationssystem noch ziel-
gerichteter einzusetzen und spezifischer auf die Bedürfnisse der Mitarbeiter im Unternehmen
abzustimmen. Vorstellbar ist dies in Form einer Ergänzung des erarbeiteten Implementierungs-
modells dahingehend, dass nach der Phase des Vollausbaus des zunächst geplanten Systems ein
weiterer Schritt in Form einer unternehmensweiten Anbindung an die bestehenden Informations-
plattformen des Unternehmens stattfindet. In diesem Zusammenhang ist auch ein Vorgehen zu
entwerfen, inwieweit die speziellen Bedürfnisse einzelner Mitarbeiter aufgenommen und in
Hilfestellungen des wissensbasierten Informationssystems in der Abarbeitung täglicher Prozesse
umgesetzt werden können.
LITERATURVERZEICHNIS SEITE 149
Literaturverzeichnis
[Amel02] Amelingmeyer, Jenny: „Wissensmanagement”; Wiesbaden: Deutscher Universitäts-
Verlag, 2002, 2. aktualisierte Auflage (ISBN 3-8244-7554-5).
[ApRi00] Appelrath, Hans-Jürgen / Ritter, Jörg: „R/3-Einführung, Methoden und Werkzeuge“;
Berlin: Springer-Verlag, 2000 (ISBN 3-540-65593-X).
[ArSc78] Argyris, Chris / Schön, Donald A.: „Organizational Learning: a theory of action
perspective“; Reading: Addison-Wesley, 1978 (ISBN 0-201-00174-8).
[Barb96] Barbitsch, Christian E.:
„Einführung integrierter Standardsoftware – Handbuch für
eine leistungsfähige Unternehmensorganisation“; München: Hanser Verlag, 1996
(ISBN 3-446-18680-8).
[BeKe00] Beierle, Christoph / Kern-Isberner, Gabriele: „Methoden wissensbasierter Systeme –
Grundlagen, Algorithmen, Anwendungen“; Braunschweig: Vieweg Verlag, 2000
(ISBN 3-528-05723-8).
[Berg05] Bergmann, Philipp:
„Die Technik steht – und dann? Wie Sie Ihre Mitarbeiter zum
Wissensaustausch motivieren“; in: Wissensmanagement, 2005, Nr. 3, S. 20-22.
[BeWe03] Best, Eva / Weth, Martin: „Geschäftsprozesse optimieren – Der Praxisleitfaden für
erfolgreiche Reorganisation“; Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th.
Gabler, 2003 (ISBN 3-409-12381-4).
[Blei99] Bleicher, Knut:
„Das Konzept integriertes Management – Visionen, Missionen,
Programme“; Frankfurt: Campus-Verlag, 1999, 5. erweiterte Auflage (ISBN 3-593-
36194-9).
[Bode03] Bodendorf, Freimut:
„Daten- und Wissensmanagement“; Berlin: Springer Verlag,
2003 (ISBN 3-540-00102-6).
[Boni90] Bonitz, Manfred:
„Wissen – Information – Informatik“; in „Effektivitätsfaktor
Information, Themenkreis 1: Von der Datenverarbeitung zur Wissensverarbeitung“;
Mater, E. / Killenberg, H. / Jankowski, L.: hrsg. vom Institut für
Informationswissenschaft, Erfindungswesen und Recht der Technischen Hochschule
Ilmenau, Ilmenau, 1990.
[Borm02] Bormann, Hans-Werner:
„Prozesse verändern: schwierig, aber nicht unmöglich“; in:
Wissensmanagement, 2002, Nr. 2, S. 41-43.
[BoTK03] Borgelt Christian / Timm Heiko / Kruse Rudolf: „Unsicheres und vages Wissen“; in:
Görz, Günther (Hrsg): „Handbuch der Künstlichen Intelligenz“; München: Oldenbourg
Verlag, 2003, 4. korrigierte Auflage (ISBN 3-486-27212-8).
[BrRP05] Brettel, Malte / Reißig-Thust, Solveig / Plag, Martin: „Konzept für ein systematisches
Change Management“; in: Kohnke, Oliver / Bungard, Walter: „SAP-Einführung mit
Change Management – Konzepte, Erfahrungen und Gestaltungsempfehlungen“;
Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2005 (ISBN 3-409-
SEITE 150 LITERATURVERZEICHNIS
12650-3).
[Bung05] Bungard / Walter: „Einführung unternehmensweiter Standard-Software-Pakete: Eine
gefährliche Gratwanderung zwischen wirtschaftlichem Höhenflug und
existenzbedrohendem Absturz“; in: Kohnke, Oliver / Bungard, Walter: „SAP-
Einführung mit Change Management – Konzepte, Erfahrungen und
Gestaltungsempfehlungen“; Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th.
Gabler, 2005 (ISBN 3-409-12650-3).
[BuSc97] Bullinger, Hans-Jörg / Schäfer, M.: „Kundenorientierung und lernende Unternehmen:
Wie Sie vom Kunden lernen“; in: Gabler’s Magazin, Heft 4/1997, S. 94-98.
[BuWP98] Bullinger, Hans-Jörg / Wörner, Kai / Prieto, Juan: „Wissensmanagement-Modelle
und Strategien für die Praxis“; in: Bürgel, H. (Hrsg.): „Wissensmanagement –
Schritte zum intelligenten Unternehmen“; Berlin: Springer Verlag, 1998 (ISBN 3-540-
63624-2).
[BWPW98] Bullinger, Hans-Jörg / Warschat, Joachim / Prieto, Juan / Wörner, Kai:
„Wissensmanagement – Anspruch und Wirklichkeit: Ergebnisse einer
Unternehmensstudie in Deutschland“; in: Information Management, Ausgabe 1/98,
S. 7-23.
[DaBo94] Davis, Stanley M. / Botkin, Jim: „The coming of Knowledge-Based Business”; in:
Harvard Business Review, 1994, September/October, S. 165ff.
[DaBo95] Davis, Stanley M. / Botkin, Jim: „Wissen gegen Geld: Die Zukunft der unternehmen
in der Wissensrevolution“; Frankfurt/Main: Campus Verlag, 1995 (ISBN 3-593-
35380-6).
[DaPr98] Davenport, Thomas H. / Prusak, Laurence: „Wenn ihr Unternehmen wüsste, was es
alles weiß… - Das Praxishandbuch zum Wissensmanagement“; Landsberg/Lech:
Verlag Moderne Industrie, 1998 (ISBN 3-478-26470-1).
[Deck05] Decker, Björn et al.: „Wissen und Information 2005“; Stuttgart: Fraunhofer IRB
Verlag, 2005 (ISBN 3-8167-6756-7).
[DFGr02] D’Oosterlinck, Marc / Freitag, Hartmut / Graff, Joachim: „SiemensIndustrialServices:
Turning know-how into results“; in Davenport, Thomas H. / Probst, Gilbert J.B.:
„Knowledge Management Case Book – Siemens Best Practices”; Erlangen: Publicis
KommunikationsAgentur GWA, 2002, 2. Auflage (ISBN 3-89578-181-9).
[DGJT02] Dora, Andrea, / Gibbert, Michael / Jonczyk, Claudia / Trillitzsch, Uwe: „Networked
Knowledge – implementing a system for sharing technical Tipps and expertise”; in
Davenport, Thomas H. / Probst, Gilbert J.B.: „Knowledge Management Case Book –
Siemens Best Practices”; Erlangen: Publicis KommunikationsAgentur GWA, 2002, 2.
Auflage (ISBN 3-89578-181-9).
[Dier03] Dierkes, Meinolf:
„Theorie und praktischer Nutzen von Unternehmenskultur“; in:
Bullinger, H.-J. / Warnecke, H.J. / Westkämper, E.: „Neue Organisationsformen im
Unternehmen – Ein Handbuch für das moderne Management“; Berlin: Springer
Verlag, 2003, 2. neu bearbeitete und erweiterte Auflage (ISBN 3-540-67610-4).
LITERATURVERZEICHNIS SEITE 151
[DIN87] Deutsches Institut für Normung e.V. (DIN; Hrsg.): „DIN 69901 – Projektmanagement
- Begriffe“; Berlin: Deutsches Institut für Normung e.V., 1987.
[DIN03] Deutsches Institut für Normung e.V. (DIN; Hrsg.): „DIN 31051:2003-06 – Grundlagen
der Instandhaltung“; Berlin: Deutsches Institut für Normung e.V., 2003.
[DoLa02] Doppler, Klaus / Lauterburg, Christoph: „Change Management – Den
Unternehmenswandel gestalten“; Frankfurt/Main: Campus Verlag, 2002, 10. Auflage
(ISBN 3-593-36819-6).
[DoZl04] Dorrhauer, Carsten / Zlender, Andrej: „Business-Software: ERP, CRM, EAI, E-
Business – eine Einführung“; Marburg: Tectum Verlag, 2004 (ISBN 3-8288-8628-0).
[Druc93] Drucker, Peter: F. „Post-capitalist society“; New York: Harper Business, 1993 (ISBN
0-88730-620-9).
[EKPW99] Eversheim, Walter / Klocke, Fritz / Pfeifer, Tilo / Weck, Manfred: „Wettbewerbsfaktor
Produktionstechnik: Aachener Perspektiven“; hrsg. vom AWK Aachener
Werkzeugmaschinen-Kolloquim, Aachen: Shaker Verlag, 1999 (ISBN 3-8265-4344-
0).
[Ever96] Eversheim, Walter:
„Organisation in der Produktionstechnik – Band 1: Grundlagen“;
Düsseldorf: VDI-Verlag, 1996, 3. neu bearbeitete und erweiterte Auflage (ISBN 3-18-
401542-4).
[Fech96] Fechtner, Harri u.a. (Hrsg.): „Erfolgsfaktor Mensch – Im Spannungsfeld zwischen
Führen und Dienen“; Neuwied: Luchterhand Verlag, 1996 (ISBN 3-472-02439-9).
[Felb98] Von Felbert, Dirk: „Wissensmanagement in der unternehmerischen Praxis“; in:
Pawlowsky, Peter (Hrsg.): „Wissensmanagement – Erfahrungen und Perspektiven“;
Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 1998 (ISBN 3-409-
18974-2).
[Föck01] Föcker, Egbert:
„Die Werkzeuge des Wissensmanagements“; in:
Wissensmanagement online, Ausgabe März/April 2001.
http://www.wissensmanagement.net/online/archiv/2001/03_0401/wissensmanageme
nt_softwar.shtml (21. Dezember 2005)
[Fors00] Forst, Annelyse:
„Was leistet die Balanced Scorecard?“; in: Wissensmanagement
online, Ausgabe November/Dezember 2000.
http://www.wissensmanagement.net/online/archiv/2000/11_1200/balanced_scorecar
d.shtml (02. Januar 2006)
[FrRe93] Frieling, Ekkehart / Reuther, Ursula (Hrsg.): „Das lernende Unternehmen –
Dokumentation einer Fachtagung am 6. Mai 1993 in München“; Hochheim: Neres-
Verlag, 1993 (ISBN 3-9802836-6-6).
[FrSc01] Frank, Ulrich / Schauer, Hanno: „Potentiale und Herausforderungen des
Wissensmanagements aus der Sicht der Wirtschaftsinformatik“; in Schreyögg, Georg
(Hrsg.): „Wissen in Unternehmen – Konzepte, Maßnahmen, Methoden“; Berlin: Erich
Schmidt Verlag, 2001 (ISBN 3-503-05952-0).
SEITE 152 LITERATURVERZEICHNIS
[Gaed04] Gaede, Bernd: „Bewertung von Wissensmanagement-Projekten und die Balanced
Scorecard“; in: Wissensmanagement, 2004, Nr. 1, S. 10-13.
[GeSt98] Gemmerich, Markus / Stratmann, Jan: „Wissensmanagement in der Praxis“; in:
technologie & management, Jg. 47, Nr. 1, 1998.
[Görk01] Görk, Manfred:
„Customizing“; in: Mertens, Peter: „Lexikon der
Wirtschaftsinformatik“; Berlin: Springer-Verlag, 2001, 4. vollständig neu bearbeitete
und erweiterte Auflage (ISBN 3-540-42339-7).
[GöSc04] Götz, Klaus / Schmid, Michael: „Praxis des Wissensmanagements“; München:
Verlag Franz Vahlen, 2004 (ISBN 3-8006-3062-1).
[Grew00] Grewe, Alexander: „Implementierung neuer Anreizsysteme – Grundlagen, Konzept
und Gestaltungsempfehlungen“; München: Hampp Verlag, 2000 (ISBN 3-87988-
509-5).
[GrMü05] Gronau, Norbert / Müller, Claudia: „Wissensarbeit prozessorientiert modellieren und
verbessern“; in: Wissensmanagement, 2005, Nr. 3, S. 50-52.
[Gron01] Gronau, Norbert:
„Industrielle Standardsoftware – Auswahl und Einführung“;
München: Oldenbourg Verlag, 2001 (ISBN 3-486-25693-9).
[Grub94] Gruber, Hans:
„Expertise – Modelle und empirische Untersuchungen“; Opladen:
Westdeutscher Verlag, 1994 (ISBN 3-531-12613-X).
[HaCh96] Hammer, Michael / Champy, James: „Business Reengineering – Die Radikalkur für
das Unternehmen“; Frankfurt/Main: Campus Verlag, 1996, 6. Auflage (ISBN 3-593-
35017-3).
[Haun02] Haun, Matthias:
„Handbuch Wissensmanagement: Grundlagen und Umsetzung,
Systeme und Praxisbeispiele“; Berlin: Springer Verlag, 2002 (ISBN 3-540-67583-3)
[HaNT99] Hansen, Morten T. / Nohria, Nitin / Tierney, Thomas: „Wie managen Sie das Wissen
in Ihrem Unternehmen?“; in: Harvard Business Manager, 23. Juli 1999, S. 85-96.
[Herb00] Herbst, Dieter:
„Erfolgsfaktor Wissensmanagement – Wissen als einzigartige
Kombination von Information und Erfahrung, systematische Erfassung, Archivierung
und Verbreitung von Wissen, Instrumente des Wissensmanagement“; Berlin:
Cornelsen Verlag, 2000 (ISBN 3-464-49072-6).
[Herr01] Herrmann, Thomas et al.: „Wissensmanagement mitgestalten – Konzepte, Methoden
und Bewertungskriterien“; Oberhausen: TBS, Technologieberatungsstelle beim
DGB, 2001 (ISBN 3-924793-50-6).
[HeVo01] Heisig, Peter / Vorbeck, Jens: „Benchmarking Survey Results“; in: Mertins, Kai /
Heisig, Peter / Vorbeck, Jens [Hrsg.]: „Knowledge Management – Best Practices in
Europe”; Berlin: Springer Verlag, 2001, S. 97-123 [ISBN 3-540-00490-4].
[HHMS04] Hindel, Bernd / Hörmann, Klaus / Müller, Markus / Schmied, Jürgen: „Basiswissen
Softwareprojektmanagement – Aus- und Weiterbildung zum Certified Project
Manager nach iSQI-Standard“; Heidelberg: dpunkt.verlag, 2004 (ISBN 3-89864-230-
5).
LITERATURVERZEICHNIS SEITE 153
[Hoff05] Hoffmann, Matthias: „Wissen geht nicht von Technologie, sondern von Menschen
aus“; in: Wissensmanagement, 2005, Nr. 3, S. 26-27.
[HoKK04] Howaldt, Jürgen / Klatt, Rüdiger / Kopp, Ralf: „Neuorientierung des
Wissensmanagements – Paradoxien und Dysfunktionalitäten im Umgang mit der
Ressource Wissen“; Wiesbaden: Deutscher Universitäts-Verlag, 2004 (ISBN 3-8244-
0768-X).
[Hopf00] Hopfenbeck, Waldemar:
„Allgemeine Betriebswirtschafts- und Managementlehre –
das Unternehmen im Spannungsfeld zwischen ökonomischen, sozialen und
ökologischen Interessen“; München: Verlag Moderne Industrie, 2000, 13. vollständig
überarbeitete und erweiterte Auflage (ISBN 3-478-39875-4).
[Hopf02] Hopfenbeck, Waldemar:
„Allgemeine Betriebswirtschafts- und Managementlehre –
das Unternehmen im Spannungsfeld zwischen ökonomischen, sozialen und
ökologischen Interessen“; München: Verlag Moderne Industrie, 2000, 14. Auflage
(ISBN 3-478-39875-4).
[Itam87] Itami, Hiroyuki:
„Mobilizing invisible assets“; Cambridge: Harvard University Press,
1987 (ISBN 0-674-57770-1).
[Joch97] Jochem, Michael:
„Einführung integrierter Standardsoftware – ein ganzheitlicher
Ansatz“; Essen: Universität - Gesamthochschule Essen, Dissertation im Fachbereich
Wirtschaftswissenschaften, 1997.
[KaNo92] Kaplan, Robert S. / Norton, David P.: „The Balanced Scorecard Measures That Drive
Performance“; in: Harvard Business Review, 1992.
[KaNo97] Kaplan, Robert S. / Norton, David P.: „Balanced Scorecard – Strategien erfolgreich
umsetzen“; Stuttgart: Schäffer-Poeschel Verlag, 1997 (ISBN 3-7910-1203-7).
[Karn05] Karner, Josef:
„Wissensmanagement in KMU“; in: Wissensmanagement online,
Ausgabe Februar 2005.
http://www.wissensmanagement.net/online/archiv/2005/02_2005/wissensmanageme
nt_in_kmu.shtml (17. November 2005)
[Kate03] Katenkamp, Olaf: „Wissensmanagement in der Praxis – Modelle und Instrumente im
Überblick“; in Katenkamp, Olaf / Peter, Gerd (Hrsg.): „Die Praxis des
Wissensmanagements – Aktuelle Konzepte und Befunde in Wirtschaft und
Wissenschaft“; Münster: LIT Verlag, 2003 (ISBN 3-8258-6922-9).
[Kirc96] Kirchmer, Mathias:
„Geschäftsprozessorientierte Einführung von Standardsoftware –
Vorgehen zur Realisierung strategischer Ziele“; Wiesbaden: Betriebswirtschaftlicher
Verlag Dr. Th. Gabler, 1996 (ISBN 3-409-12170-6).
[Kohn05] Kohnke, Oliver:
„Change Management als strategischer Erfolgsfaktor bei ERP-
Implementierungsprojekten“; in: Kohnke, Oliver / Bungard, Walter: „SAP-Einführung
mit Change Management – Konzepte, Erfahrungen und Gestaltungsempfehlungen“;
Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2005 (ISBN 3-409-
12650-3).
SEITE 154 LITERATURVERZEICHNIS
[KoMö02] Kostka, Claudia / Mönch, Anette: „Change Management – 7 Methoden für die
Gestaltung von Veränderungsprozessen“; München: Carl Hanser Verlag, 2002, 2.
Auflage (3-44621883-1).
[KoRo04] Koeder, Kurt W. / Rohleder, Norbert E.: „Wissensmanagement in deutschen
Unternehmen – eine Bestandsaufnahme“; in: Wissensmanagement online, Ausgabe
Mai 2004.
http://www.wissensmanagement.net/online/archiv/2004/05_2004/wissensmanageme
nt_unternehmen.shtml (17. November 2005)
[Kott95] Kotter, John P.: „Leading Change: Why transformation efforts fail“; in: Harvard
Business Review, 1995, March-April, S. 59-67.
[Krcm03] Krcmar, Helmut:
„Informationsmanagement“; Berlin: Springer Verlag, 2003, 3. neu
überarbeitete und erweiterte Auflage (ISBN 3-540-43886-6).
[Krem04] Krems, Burkhardt:
„Lernende Organisation“; in: Online-Verwaltungslexikon,
http://www.olev.de.
http://www.olev.de/lernorg.htm (02. Dezember 2005)
[Lehn01] Lehner, Franz:
„Computergestütztes Wissensmanagement – Fortschritt durch
Erkenntnisse über das organisatorische Gedächtnis?“; in Schreyögg, Georg (Hrsg.):
„Wissen in Unternehmen – Konzepte, Maßnahmen, Methoden“; Berlin: Erich
Schmidt Verlag, 2001 (ISBN 3-503-05952-0).
[Mert05] Mertens, Peter:
„Grundzüge der Wirtschaftsinformatik“; Berlin: Springer Verlag,
2005, 9. überarbeitete Auflage (ISBN 3-540-23411-X).
[MeZi05] Meyer, Matthias / Zinnbauer, Markus: „Aller Anfang ist schwer – die Implementierung
von Wissensmanagementsystemen“; in: Wissensmanagement, 2005, Nr. 6, S. 48-
51.
[MMGe02] Martin, Reiner / Mauterer, Heiko / Gmünden, Hans-Georg: „Systematisierung des
Nutzens von ERP-Systemen in der Fertigungsindustrie“; in: Wirtschaftsinformatik,
Jg. 44, 2002, Nr. 2, S. 109-116.
[Müld01] Mülder, Wilhelm:
„Implementierung“; in: Mertens, Peter: „Lexikon der
Wirtschaftsinformatik“; Berlin: Springer-Verlag, 2001, 4. vollständig neu bearbeitete
und erweiterte Auflage (ISBN 3-540-42339-7).
[MüLe05] Müller-Stewens, Günter / Lechner, Christoph: „Strategisches Management – Wie
strategische Initiativen zum Wandel führen“; Stuttgart: Schäffer Poeschel Verlag,
2005, 3. aktualisierte Auflage (ISBN 3-7910-2467-1).
[N.N.90] N.N.:
„Expertensysteme - Einführung in Technik und Anwendung, Band 1“; Berlin:
Siemens-Aktiengesellschaft, 1990, 2. Auflage (ISBN 3-8009-1553-7).
[N.N.97] N.N.:
„Brockhaus – Die Enzyklopädie, Band 10 HERR-ISS“; Leipzig: Brockhaus,
1997, 20. überarbeitete und aktualisierte Auflage (ISBN 3-7653-3110-4).
LITERATURVERZEICHNIS SEITE 155
[N.N.03] N.N.: „Der Brockhaus Computer- und Informationstechnologie: Hardware, Software,
Multimedia, Internet, Telekommunikation“; Leipzig: Brockhaus, 2003 (ISBN 3-7653-
0251-1).
[Nerd03] Nerdinger, Friedemann W.:
„Motivation von Mitarbeitern“; Göttingen: Hogrefe-Verlag,
2003 (ISBN 3-80171484-5).
[NiRe05] Niedereichholz, Joachim / Reske, Jens: „Probleme bei der Einführung von
Standardsoftware“; in: Kohnke, Oliver / Bungard, Walter: „SAP-Einführung mit
Change Management – Konzepte, Erfahrungen und Gestaltungsempfehlungen“;
Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2005 (ISBN 3-409-
12650-3).
[NjKo02] Njaa, Nicole / Kohnke, Oliver: „Zielvereinbarungen im Change Management“; in:
Bungard, Walter / Kohnke, Oliver (Hrsg.): „Zielvereinbarungen erfolgreich umsetzen
– Konzepte, Ideen und Praxisbeispiele auf Gruppen- und Organisationsebene“;
Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2002, 2. erweiterte Auf-
lage (ISBN 3-409-11477-7).
[Nobl99] Noble, C.H.:
„The eclectic roots of strategy implementation research“; in: Journal of
Business Research, Volume 45, 1999, S. 119-134.
[Nohr01] Nohr, Holger:
„Steuerung und Erfolgsmessung im Wissensmanagement mit
Balanced Scorecards“; in: Wissensmanagement, 2001, Nr. 4, S. 21-24.
[NoPR98] North, Klaus / Probst, Gilbert / Romhardt, Kai: „Wissen messen – Ansätze,
Erfahrungen und kritische Fragen“; in: zfo - Zeitschrift Führung und Organisation,
1998, Nr. 3, S. 158-166.
[Nort02] North, Klaus:
„Wissensorientierte Unternehmensführung – Wertschöpfung durch
Wissen“; Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2002, 3.
aktualisierte und erweiterte Auflage (ISBN 3-409-33029-1).
[NoTa97] Nonaka, Ikujiro / Takeuchi, Hirotaka: „Die Organisation des Wissens – wie
japanische Unternehmen eine brachliegende Ressource nutzbar machen“; Frankfurt:
Campus Verlag, 1997 (ISBN 3-593-35643-0).
[Öste00] Österle, Hubert: Vorwort in: Teufel, Thomas / Röhricht, Jürgen / Willems, Peter:
„SAP-Prozesse mit Knowledge Maps analysieren und verstehen“; München:
Addison-Wesley Verlag, 2000 (ISBN 3-8273-1602-2).
[Öste01] Österle, Hubert:
„Standardsoftware – Auswahl und Einführung“; in: Mertens, Peter:
„Lexikon der Wirtschaftsinformatik“; Berlin: Springer-Verlag, 2001, 4. vollständig neu
bearbeitete und erweiterte Auflage (ISBN 3-540-42339-7).
[ÖsWi03] Österle, Hubert / Winter, Robert: „Business Engineering – Auf dem Weg zum
Unternehmen des Informationszeitalters“; Berlin: Springer Verlag, 2003, 2.
vollständig neu bearbeitete und erweiterte Auflage (ISBN 3-540-00049-6).
[Pala97] Palass, Brigitta:
„Der Schatz in den Köpfen – Immer mehr Manager ahnen es: Nur
SEITE 156 LITERATURVERZEICHNIS
Wissen schafft in Zukunft Wachstum und Wohlstand.“; in: Manager Magazin, 1997,
Nr. 1, S. 112 ff.
[Panh04] Panhans, Tanja:
„Cultural Change: Auf dem Weg zu einer Kultur für kooperatives
Lernen und Arbeiten“; in: Wissensmanagement, 2004, Nr. 1, S. 45-47.
[Pawl94] Pawlowsky, Peter:
„Wissensmanagement in der lernenden Organisation“;
Paderborn: Habilitationsschrift, 1994
[Pete05] Peters, Peter:
„Wertgetriebenes Change Management für ERP-Einführungen“; in:
Kohnke, Oliver / Bungard, Walter: „SAP-Einführung mit Change Management –
Konzepte, Erfahrungen und Gestaltungsempfehlungen“; Wiesbaden:
Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2005 (ISBN 3-409-12650-3).
[Prim03] Primus, Arthur:
„Optimierung von Problemlösungsprozessen durch
Wissensmanagement – Ein Vorgehensmodell“; Wiesbaden: Deutscher Universitäts-
Verlag, 2003 (ISBN 3-8244-0689-6)
[PrBü98] Probst, Gilbert / Büchel, Bettina: „Organisationales Lernen: Wettbewerbsvorteil der
Zukunft“; Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gäbler, 1998, 2.
Auflage (ISBN 3-409-23024-6).
[PRRo03] Probst, Gilbert / Raub, Stefan / Romhardt, Kai: „Wissen managen – Wie
Unternehmen ihre wertvollste Ressource optimal nutzen“; Wiesbaden:
Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2003, 4. überarbeitete Auflage (ISBN
3-409-49317-4).
[Pupp91] Puppe, Frank:
„Einführung in Expertensysteme“; Berlin: Springer Verlag, 1991, 2.
Auflage (ISBN 3-540-54023-7).
[Rasc00] Rasch, Alejandro Alcalde: „Erfolgspotential Instandhaltung- Theoretische
Untersuchung und Entwurf eines ganzheitlichen Instandhaltungsmanagements“;
Berlin: Erich Schmidt Verlag, 2000 (ISBN 3-503-05811-7).
[Reiß97] Reiß, Michael:
„Instrumente der Implementierung“; in: Reiß, Michael / von
Rosenstiel, Lutz / Lanz, Anette (Hrsg.): „Change Management – Programme,
Projekte und Prozesse“; Stuttgart: Schäffer-Poeschel Verlag, 1997(ISBN 3-7910-
0947-8).
[ReKr96] Rehäuser, Jakob / Krcmar, Helmut: „Wissensmanagement im Unternehmen“; in
Schreyögg, Georg / Conrad, Peter (Hrsg.): „Wissensmanagement“; Berlin: de
Gruyter, 1996 (ISBN 3-11-014999-0).
[Remu02] Remus, Ulrich:
„Prozessorientiertes Wissensmanagement. Konzepte und
Modellierung“; Regensburg: Universität Regensburg, Dissertation, 2002,
elektronisches Dokument:
http://www.opus-bayern.de/uni-regensburg/volltexte/2002/80/pdf/remusdiss.pdf
[ReSc02] Remus, Ulrich / Schub, Stephan: „Prozessorientiertes Wissensmanagement in der
Praxis – Ein referenzmodellgestützter Ansatz“; Regensburg: Universität Regensburg,
LITERATURVERZEICHNIS SEITE 157
Lehrstuhl für Wirtschaftsinformatik III, Forschungsbericht Nr. 60, Juni 2002 (ISBN 3-
932345-84-3).
[Rinz98] Rinza, Peter:
„Projektmanagement – Planung, Überwachung und Steuerung von
technischen und nichttechnischen Vorhaben“; Berlin: Springer Verlag, 1998, 4.
neubearbeitete Auflage (ISBN 3-540-64021-5).
[Rohl05] Rohleder, Norbert E.: „Wissen gezielt einsetzen“; in: Wissensmanagement online,
Ausgabe Oktober 2005.
http://www.wissensmanagement.net/online/archiv/2005/10_2005/kmu_1005.shtml
(17. November 2005)
[Romh98] Romhardt, Kai:
„Die Organisation aus der Wissensperspektive – Möglichkeiten und
Grenzen der Intervention“; Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th.
Gabler, 1998 (ISBN 3-409-12855-7).
[Rose01] Rosenstiel, Lutz von:
„Motivation im Betrieb: mit Fallstudien aus der Praxis“;
Leonberg: Rosenberger Fachverlag, 2001, 10. überarbeitete und erweiterte Auflage
(ISBN 3-931085-30-9).
[Samm00] Sammer, Martin:
„Vernetzung von Wissen in Organisationen – Gestaltung von
Rahmenbedingungen“; Wiesbaden: Deutscher Universitäts-Verlag, 2000 (ISBN 3-
8244-0555-5).
[Sand01] Sanden, Heike:
„Entwicklung eines Modells zur Implementierung von
Wissensmanagement in Organisationen“; Paderborn: Universität Paderborn,
Dissertation 2001.
[Satt99] Sattelberger, Thomas:
„Wissenskapitalisten oder Söldner? – Personalarbeit in
Unternehmensnetzwerken des 21. Jahrhunderts“; Wiesbaden:
Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 1999 (ISBN 3-409-18994-7).
[Sche95] Schein, Edgar H.: „Unternehmenskultur – ein Handbuch für Führungskräfte“;
Frankfurt: Campus-Verlag, 1995 (ISBN 3-593-35268-0).
[Schi01] Schindler, Martin:
„Wissensmanagement in der Projektabwicklung – Grundlagen,
Determinanten und Gestaltungskonzepte eines ganzheitlichen
Projektwissensmanagements“; Lohmar: Eul Verlag, 2001, 2. durchgesehene Auflage
(ISBN 3-89012-849-1).
[Schm99] Schmid, Michael R.: „Wissensmanagement für den Innovationsprozess – Ein
empirisch fundierter Beitrag zur Gestaltung und Umsetzung des
Wissensmanagement-Ansatzes im produktorientierten Ideenmanagement bei
DaimlerChrysler“; Universität Bielefeld, Dissertation, 1999.
[Schn96] Schneider, Ursula:
„Wissensmanagement – Die Aktivierung des intellektuellen
Kapitals“; Frankfurt/Main: Frankfurter Allgemeine Zeitung, Verlags-Bereich
Wirtschaftsbücher, 1996 (ISBN 3-929368-53-6).
SEITE 158 LITERATURVERZEICHNIS
[Schü97] Schüppel, Jürgen: „Wissensmanagement – Organisatorisches Lernen im
Spannungsfeld von Wissens- und Lernbarrieren“; Wiesbaden: Deutscher
Universitäts-Verlag, 1997 (ISBN 3-8244-6304-0).
[Schü05] Schütt, Peter:
„Das optimale Wissensmanagementsystem?“; in:
Wissensmanagement, 2005, Nr. 5, S. 18-22.
[ScRe99] Schiava, Manfred della / Rees, William H.: „Was Wissensmanagement bringt“; Wien:
Signum Verlag, 1999 (ISBN 3-85436-298-6).
[Seib80] Seibt, Dietrich:
„Implementierung, organisatorische“; in: Grochla, Erwin (Hrsg.):
„Handwörterbuch der Organisation“; Poeschel Verlag: Stuttgart, 1980 (ISBN 3-7910-
8016-4).
[Seng98] Senge, Peter M.:
„Die fünfte Disziplin: Kunst und Praxis der lernenden Organisation“;
Stuttgart: Klett-Costa Verlag, 1998, 6. Auflage (ISBN 3-608-91379-3).
[Shie02] Shields, Murrell G.: „ERP-Systeme und E-Business schnell und erfolgreich einführen
– Ein Handbuch für IT-Projektleiter“; Weinheim: Wiley-VCH Verlag, 2002 (ISBN 3-
527-50017-0).
[Souk01] Soukup, Christoph:
„Wissensmanagement – Wissen zwischen Steuerung und
Selbstorganisation“; Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2001
(ISBN 3-409-11751-2).
[Steh01] Stehr, Nico:
„Wissen und Wirtschaften – die gesellschaftlichen Grundlagen der
modernen Ökonomie“; Frankfurt am Main: Suhrkamp Verlag, 2001 (ISBN 3-518-
29107-6).
[Stei00] Steinbuch, Pitter A.: „Projektorganisation und Projektmanagement“; Ludwigshafen
(Rhein): Friedrich Kiehl Verlag, 2000, 2. Auflage (ISBN 3-470-48592-5).
[Stew98] Stewart, Thomas A.: „Der vierte Produktionsfaktor – Wachstum und
Wettbewerbsvorteile durch Wissensmanagement“; München: Carl Hanser Verlag,
1998 (ISBN 3-446-19230-1).
[StHa05] Stahlknecht, Peter / Hasenkamp, Ulrich: „Einführung in die Wirtschaftsinformatik“;
Berlin: Springer Verlag, 2005, 11. vollständig überarbeitete Auflage (ISBN 3-540-
01183-8).
[StHe03] Strulik, Thorsten / Heßling, Alexandra: “Systemisches Wissensmanagement im
Multi-Channel-Banking”; in: Soziale Welt, 54. Jg., 2003, Nr.1, S. 31-48.
[Stre97] Streich, Richard K.:
„Veränderungsprozessmanagement“; in: Reiß, Michael / von
Rosenstiel, Lutz / Lanz, Anette (Hrsg.): „Change Management – Programme,
Projekte und Prozesse“; Stuttgart: Schäffer-Poeschel Verlag, 1997(ISBN 3-7910-
0947-8).
[StSc05] Steinmann, Horst / Schreyögg, Georg: „Management – Grundlagen der
Unternehmensführung, Konzepte – Funktionen - Fallstudien”; Wiesbaden:
Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2005, 6. überarbeitete Auflage (ISBN
3-409-63312-X).
LITERATURVERZEICHNIS SEITE 159
[Svei94] Sveiby, Karl-Erik: „Towards a knowledge perspective on organisation”; Stockholm:
University of Stockholm, 1994, Doctoral Dissertation (ISBN 91-7153-267-6).
http://www.sveiby.com/articles/Diss1-3.html, 01. Juli 2005
http://www.sveiby.com/articles/Diss4-6.html, 01. Juli 2005
[Szul03] Szulanski, Gabriel:
„Sticky knowledge – Barriers to Knowing in the firm“; London:
SAGE Publications Ltd., 2003, 1. Auflage (ISBN 0-7619-6142-9).
[Troj05] Trojan, Jörg:
„Wissensmanagement bei der Deutschen Post World Net“; in:
Wissensmanagement online, Ausgabe Februar 2005.
http://www.wissensmanagement.net/online/archiv/2005/03_2005/dpwn.shtml
(17. November 2005)
[Tupp03] Tuppinger, Josef:
„Wissensorientierter Organisationswandel – Ein Ansatz zur
Veränderung von Struktur und Kultur“; Wiesbaden: Deutscher Universitäts-Verlag,
2003 (ISBN 3-8244-0690-X).
[vArb97] Von Arb, Reto: „Vorgehensweisen und Erfahrungen bei der Einführung von
Enterprise-Management-Systemen dargestellt am Beispiel SAP R/3“; Bern:
Universität Bern, Dissertation an der Fakultät für Rechts- und
Wirtschaftswissenschaften, 1997.
[Wahl03] Wahl, Mark:
„Wissensmanagement im Lebenszyklus von ERP-Systemen –
Explorative Untersuchung und Entwicklung eines Gestaltungskonzeptes für SAP
R/3-Projekte“; Wiesbaden: Deutscher Universitäts-Verlag, 2003 (ISBN 3-8244-7749-
1).
[Wahr96] Wahren, Heinz-Kurt E.: „Das lernende Unternehmen – Theorie und Praxis des
organisationalen Lernens“; Berlin: Verlag de Gruyter, 1996 (ISBN 3-11-014790-4).
[Welt99] Welti, Norbert:
„Successful SAP R/3 Implementation – Practical Management of
ERP-Projects“; Harlow: Addison-Wesley, 1999 (ISBN 0-201-39824-9).
[Weso05] Wesoly, Michael:
„Methoden und Instrumente zur Wissenbewahrung im
Unternehmen – Wissen verlieren ist nicht schwer…“; in: Betonwerk + Fertigteil-
Technik, 3/2005, S.46-51.
[WeSt03] Wesoly, Michael / Stolk, Arco: „Instrumente des Wissensmanagements“; in:
Bullinger, H.-J. / Warnecke, H.J. / Westkämper, E.: „Neue Organisationsformen im
Unternehmen – Ein Handbuch für das moderne Management“; Berlin: Springer
Verlag, 2003, 2.neu bearbeitete und erweiterte Auflage (ISBN 3-540-67610-4).
[Wiig04] Wiig, Karl M.: „People-focused knowledge management: how effective decision
making leads to corporate success”; Amsterdam: Elsevier Butterworth-Heinemann,
2004, 10. Auflage (ISBN 0-7506-7777-5).
[Will98] Willke, Helmut:
„Systemisches Wissensmanagement“; Stuttgart: Lucius&Lucius
Verlag, 1998 (ISBN 3-8282-0082-6).
SEITE 160 LITERATURVERZEICHNIS
[WiRa03] Wilkesmann, Uwe / Rascher, Ingolf: „Wissensmanagement – Analyse und
Handlungsempfehlungen“; Düsseldorf: Hans-Böckler-Stiftung, 2003 (ISBN 3-
935145-71-3).
[WoFA05] Wohlfahrt, Sven / Fischer, Daniel / Alwert, Kay: „Bewertungsmethoden immaterieller
Ressourcen im Fokus“; in: Wissensmanagement, 2005, Nr. 5, S. 44-46.
[Zimm06] Zimmermann, Günther: „Wissensmanagement – und die Sprache?“; in:
Wissensmanagement, 2006, Nr. 6, S. 10-13.
ABBILDUNGSVERZEICHNIS SEITE 161
Abbildungsverzeichnis
Abbildung 1: Aufbau der Arbeit ................................................................................................................4
Abbildung 2: Auswahl der durch die Implementierung berücksichtigten Rahmenbedingungen..............9
Abbildung 3: Schematischer Aufbau eines Expertensystems................................................................11
Abbildung 4: Hierarchie von Daten über Informationen zu Wissen .......................................................15
Abbildung 5: Auswahl von Definitionen des Begriffs Wissen.................................................................15
Abbildung 6: Auswahl von Definitionen des Begriffs Wissensmanagement..........................................17
Abbildung 7: Personalisierungs- und Kodifizierungsstrategie................................................................19
Abbildung 8: Zentrale Konzepte im prozessorientierten Wissensmanagement ....................................21
Abbildung 9: Gestaltungsrahmen des prozessorientierten Wissensmanagements...............................22
Abbildung 10: Bausteine des Wissensmanagementkreislaufs nach PROBST/RAUB/ROMHARDT ............23
Abbildung 11: Technik-Organisation-Mensch Modell.............................................................................24
Abbildung 12: Anteile der drei Ebenen im TOM-Modell.........................................................................24
Abbildung 13: Technologien und Anwendungen des Wissensmanagements.......................................25
Abbildung 14: Technologien und Anwendungen im Wissensmanagementprozess nach PROBST........26
Abbildung 15: Transformation von individuellem zu organisationalem Wissen.....................................29
Abbildung 16: Anpassungslernen...........................................................................................................29
Abbildung 17: Veränderungslernen........................................................................................................30
Abbildung 18: Prozesslernen .................................................................................................................31
Abbildung 19: Ebenen einer Unternehmenskultur .................................................................................35
Abbildung 20: Offizielle und heimliche Spielregeln einer Unternehmenskultur .....................................39
Abbildung 21: Notwendigkeit der Messung und Bewertung von Wissen als Impulsgeber für die
Steuerung ......................................................................................................................40
Abbildung 22: Vier Basisperspektiven einer Balanced Scorecard.........................................................42
Abbildung 23: Vier Perspektiven einer wissensorientierten Balanced Scorecard nach NOHR ..............44
Abbildung 24: Ziele und Kennzahlen der Perspektiven einer Balanced Scorecard nach NOHR............45
Abbildung 25: Die Implementierung im Gesamtkontext einer Standardsoftwareeinführung .................47
Abbildung 26: Teilaufgaben der Projektorganisation .............................................................................50
Abbildung 27: Ablauf- und objektorientierte Projektstrukturierung.........................................................52
Abbildung 28: Übersicht Projektplanungsschritte...................................................................................53
Abbildung 29: Einführungsstrategien für Standardsoftware...................................................................56
Abbildung 30: Phasenmodell einer Standardsoftwareeinführung nach JOCHEM....................................58
Abbildung 31: Geschäftsprozessorientierte Einführung einer Standardsoftware nach KIRCHMER.........60
Abbildung 32: Das Change Management als Prozess nach KOHNKE....................................................65
SEITE 162 ABBILDUNGSVERZEICHNIS
Abbildung 33: Die drei Phasen des Veränderungsprozesses............................................................... 65
Abbildung 34: Bestimmungsgrößen des Handelns der Akteure............................................................ 67
Abbildung 35: Die kritischen Erfolgsfaktoren bei ERP-Projekten und deren Unterstützung durch
Change Management.................................................................................................... 69
Abbildung 36: Akzeptanzfaktoren bei Veränderungsprojekten ............................................................. 72
Abbildung 37: Aufbau des Implementierungsmodells ........................................................................... 75
Abbildung 38: Wissensmanagement als Basis der ImplementierungsstrategieFehler! Textmarke nicht definiert.
Abbildung 39: Integration von Technik, Organisation und Mensch....................................................... 77
Abbildung 40: Prozessorientierung des Implementierungsmodells....................................................... 79
Abbildung 41: Durchlaufen der Lernformen während der Implementierung ......................................... 81
Abbildung 42: Ängste der Mitarbeiter und die Reaktion darauf im Rahmen der Implementierung....... 83
Abbildung 43: Projektstruktur des Implementierungsmodells ............................................................... 86
Abbildung 44: Ableitung mehrstufiger Projektziele aus den Unternehmenszielen................................ 87
Abbildung 45: Aufgaben des Projektmanagements im Implementierungsprojekt................................. 89
Abbildung 46: Teilnehmer an der Kick-off-Veranstaltung...................................................................... 92
Abbildung 47: Das Phasenkonzept als Kernprozess des Implementierungsmodells ........................... 94
Abbildung 48: Vorbereitungsphase im Implementierungsmodell .......................................................... 96
Abbildung 49: Vorgehen bei der Analyse der Unternehmensprozesse................................................. 97
Abbildung 50: Pilotphase im Implementierungsmodell.......................................................................... 99
Abbildung 51: Feedback-Prozess im Detail......................................................................................... 100
Abbildung 52: Ausbausphase im Implementierungsmodell................................................................. 101
Abbildung 53: Vollbetriebsphase des Implementierungsmodells........................................................ 103
Abbildung 54: Integrationsaspekte in der Vollbetriebsphase .............................................................. 104
Abbildung 55: Vergleich des wissensbasierten Implementierungsmodells mit dem Verfahren für
Standardsoftware von JOCHEM.................................................................................... 106
Abbildung 56: Der Begleitprozess des mitarbeiterorientierten Change Management ........................ 107
Abbildung 57: Ableitung des Veränderungsbedarfs aus unternehmensinternen Faktoren................. 109
Abbildung 58: Die drei Phasen des Veränderungsprozesses im Vergleich........................................ 110
Abbildung 59: Der Gedanke der Softwareanpassung im Implementierungsmodell............................ 113
Abbildung 60: Einbindungsgrad des Softwareherstellers nach Teilprozessen ................................... 115
Abbildung 61: Die langfristige Erfolgssicherung.................................................................................. 117
Abbildung 62: Aufbau des Kapitels zur Messung des Implementierungserfolgs ................................ 123
Abbildung 63: Perspektiven einer Scorecard für die Implementierung ............................................... 131
Abbildung 64: Perspektiven, Teilziele und Kennzahlen der Implementierungs-Scorecard................. 132
Abbildung 65: Zielverfolgung mit der Implementierungs-Scorecard.................................................... 134
ABBILDUNGSVERZEICHNIS SEITE 163
Abbildung 66: Zielerreichungsgrade der Implementierungs-Scorecard im Netzdiagramm am
Beispiel der Mitarbeiterperspektive .............................................................................135
Abbildung 67: Zielerreichungsgrade der Implementierungs-Scorecard im Netzdiagramm am
Beispiel der Informationssystemperspektive ...............................................................136
