Seibert / Preuss / Rauer Enterprise Wikis

Die erfolgreiche Einführung und Nutzung von Wikis in Unternehmen
1. Auflage 2011
ISBN: 978-3-8349-6786-2
Verlag: Betriebswirtschaftlicher Verlag Gabler
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 200 Seiten, Web PDF

Reihe: Business and Economics (German Language)

Zunehmend mehr Unternehmen nutzen Wikis für die interne und externe Kommunikation. Häufig jedoch läuft dieser Kommunikationskanal ins Leere. Das Buch beschreibt häufig auftretende Probleme der internen Unternehmenskommunikation, die zulasten von Produktivität und Effizienz gehen, anhand konkreter Beispiele und zeigt Lösungsmöglichkeiten mithilfe von Enterprise Wikis. Was wird sich in unserem Unternehmen durch eine Wiki-Einführung verändern? Welche Potenziale und Gefahren birgt sie? Wie läuft ein idealtypisches Wiki-Projekt ab? Welche Stolperfallen gibt es auf dem Weg zu einer erfolgreichen Etablierung und wie kann man Herauforderungen meistern und Missverständnisse ausräumen? Was kann und soll ein Wiki leisten und welche konkreten Anwendungsfälle gibt es? Die Fragen beantwortet das Buch und gibt praktische Tipps, Tricks und Best Practices für die produktive und effiziente Arbeit mit einem Firmenwiki.

Zielgruppe

Professional/practitioner

Autoren/Hrsg.

Seibert, Martin

Preuss, Sebastian

Rauer, Mathias

Inhaltsverzeichnis

1;Vorwort;5
2;Exkurs;8
3;Inhalt;15
4;Teil 1 Unternehmenskommunikation: Wie ein Wiki Unternehmen verändert;23
4.1;1 Hofläden, Supermärkte und Firmenwikis: Bitte klingeln und Herzlich willkommen;24
4.1.1;1.1 Bitte klingeln heißt es auch in vielen Intranets;24
4.1.2;1.2 Was offene Türen und eine Kasse des Vertrauens bewirken;25
4.1.3;1.3 Die Vorteile überwiegen die Risiken;26
4.1.4;1.4 Worauf basiert das Miteinander?;26
4.1.5;1.5 Im Firmenwiki stiehlt niemand Kartoffeln;28
4.1.6;1.6 Vertrauen und Offenheit zahlen sich aus;28
4.2;2 Warum der Siegeszug der E-Mail zu weit gegangen ist;30
4.2.1;2.1 E-Mail: Segen für Unternehmen;30
4.2.2;2.2 Falsche Anwendung von E-Mails: Fluch für Unternehmen;31
4.2.3;2.3 E-Mail-Flut und Produktivität;31
4.3;3 E-Mail-Missbrauch: Der E-MailAnhang ist oft die falsche Anwendung von Technologie;34
4.3.1;3.1 Effizienzgewinn durch die Nutzung eines zentralen Systems;34
4.3.2;3.2 Organische Inhalte statt „toter“ Anhänge;35
4.3.3;3.3 Intern keine Anhänge, in der Kundenkommunikation geht es selten anders;36
4.4;4 Ein Arbeitstag ohne (und mit) Wiki;38
4.4.1;4.1 Unorganisierte Projektübergaben;38
4.4.2;4.2 Unproduktive neue Mitarbeiter;40
4.4.3;4.3 Ineffiziente Meetings;41
4.4.4;4.4 Träge Intranets;43
4.4.5;4.5 Ineffiziente Kundenkommunikation;45
4.5;5 Ein Meeting zur Wiki-Philosophie;51
4.6;6 Unternehmen und die Akzeptanz neuer Technologien: Eine Kategorisierung;54
4.6.1;6.1 Innovationsfreundlichkeit nach dem Crossing-the-Chasm-Modell;54
4.6.2;6.2 Social Media ist in der Early Majority angekommen;55
4.6.3;6.3 Es ist Zeit, auf Social Media zu setzen;56
4.7;7 Wer nutzt Wikis und warum und was bringen Wikis konkret?;58
4.7.1;7.1 Wie verbreitet sind Wikis in großen Unternehmen?;58
4.7.2;7.2 Gründe für die Wiki-Einführung und Motivation für die weitere Nutzung;59
4.7.3;7.3 Konkreter Nutzen von Firmenwikis;60
4.8;8 Was ein Wiki alles bewirken kann;61
4.8.1;8.1 Transparenz schaffen;61
4.8.2;8.2 Aktuelle Informationen zentral verfügbar;61
4.8.3;8.3 Bessere Zusammenarbeit;62
4.8.4;8.4 Mehr Effizienz;62
4.8.5;8.5 Glaubwürdige Informationen;62
4.8.6;8.6 Mehrwert durch Nutzungsfreude;62
4.9;9 111 Gründe für ein Firmenwiki;64
5;Teil 2: Technologische Aspekte der Wiki-Einführung und eine skeptische IT-Abteilung;71
5.1;1 Wie ein Wiki eigentlich funktioniert: Prinzip und HardwareAnforderungen;72
5.2;2 Grundsätzliche technologische Aspekte;75
5.2.1;2.1 Auswahl der richtigen Wiki-Software;75
5.2.2;2.2 Betrieb des Systems;76
5.2.3;2.3 Technische Infrastruktur im Unternehmen;76
5.2.4;2.4 Integration und Single-Sign-on;77
5.2.5;2.5 Stellung der Wiki-Software gegenüber anderen Systemen;78
5.3;3 Eine Brandrede von IT-Chef Marc Microsoft;79
5.4;4 Marc Microsoft muss das Intranet nicht über Bord werfen;82
5.4.1;4.1 Die Rolle eines Wikis;82
5.4.2;4.2 Die Tücken eines erfolgreichen Wikis: Redundanz und Gnadenlosigkeit;84
5.4.3;4.3 Wie sollte man reagieren?;84
5.4.4;4.4 Ist das Wiki also wichtiger als die anderen Systeme?;84
5.4.5;4.5 Wikis ergänzen bestehende Anwendungen;85
5.4.6;4.6 Sicherheitsprobleme im Firmenwiki?;85
5.5;5 Politische Unterstützung in Grundsatzfragen;87
5.6;6 Entscheidende Fragen bei der Evaluation von Wiki-Software;89
5.6.1;6.1 Open-Source-Software oder kommerzielles Firmenwiki?;90
5.6.2;6.2 Preis?;90
5.6.3;6.3 Existiert eine aktive Community?;90
5.6.4;6.4 Handelt es sich bei dem Wiki um eine anerkannte Lösung?;90
5.6.5;6.5 Verwendete Technologie?;91
5.6.6;6.6 Funktionalitäten des Systems?;91
5.6.7;6.7 Usability und Design?;91
5.6.8;6.8 Anspruch an das Projekt?;91
5.6.9;6.9 Migrierbarkeit der Daten?;92
5.6.10;6.10 Bietet das Wiki eine einfache Systemadministration?;92
5.6.11;6.11 Sind hochwertige Plugins verfügbar?;92
5.7;7 Wiki-Plugins: Welche Erweiterungen sind wichtig?;93
5.7.1;7.1 Office-Plugin;93
5.7.2;7.2 WebDAV-Plugin;94
5.7.3;7.3 Widget-Plugin;94
5.7.4;7.4 Datenbank-Plugin;94
5.7.5;7.5 Tag-Management-Plugin;94
5.7.6;7.6 Metadaten-Plugin;95
5.7.7;7.7 Dynamische Aufgabenlisten;95
5.7.8;7.8 Workflow-Plugin;95
5.7.9;7.9 Gallery-Plugin;96
5.7.10;7.10 Chart-Plugin;96
5.7.11;7.11 Dateien per Drag & Drop ins Wiki hochladen;96
5.8;8 Das Wiki im Käfig;97
5.9;9 Administrationskonzept;100
5.10;10 Die Nutzerperspektive im Auge behalten;102
5.11;11 Tipp: Wann sind Software-Updates sinnvoll?;104
5.11.1;11.1 Funktionalitäten: Was bringt das Update?;104
5.11.2;11.2 Große Releases: Auf den ersten Patch warten?;104
5.11.3;11.3 Aufwand: Wie hoch sind die technischen Anforderungen?;105
5.11.4;11.4 Kosten: Rechtfertigt der Nutzen sie?;105
5.11.5;11.5 Updates: Option oder Pflicht?;106
5.11.6;11.6 Faustregel: Spätestens nach drei Auslassungen nachziehen;106
6;Teil 3: Organisatorische und kulturelle Aspekte;108
6.1;1 Die fünf Stufen des Adoptionsprozesses;111
6.2;2 Ein Pilotprojekt als Pflichtprogramm;113
6.2.1;2.1 (Schein-)Gegenargument 1: Geld;114
6.2.2;2.2 (Schein-)Gegenargument 2: Zeit;115
6.2.3;2.3 (Schein-)Gegenargument 3: Überschätzung;116
6.3;3 Der Wiki-Prophet;117
6.3.1;3.1 Ohne Wiki-Prophet oder Unterstützung von oben kein Wiki-Erfolg;117
6.3.2;3.2 Wichtige Eigenschaften;118
6.3.3;3.3 Aktivitäten des Wiki-Propheten;118
6.4;4 Wiki-Steuerungskreis und WikiCharta-Gruppe;120
6.5;5 Die Pilotgruppe;121
6.5.1;5.1 Größe der Pilotgruppe;121
6.5.2;5.2 Funktion der Pilotgruppe;122
6.5.3;5.3 Struktur der Pilotgruppe;124
6.5.4;5.4 Ablauf der Pilotphase;125
6.6;6 Das Management (Strong Backing from the Top);126
6.6.1;6.1 Einführungsstrategie: Von unten, von oben oder zweigleisig?;127
6.6.2;6.2 Unternehmen machen Social-Media-Projekte zur Chefsache;127
6.6.3;6.3 Unternehmensführung ist treibende Kraft für Enterprise 2.0;128
6.6.4;6.4 Art der Zustimmung;129
6.6.5;6.5 Angst vor Ablehnung;129
6.6.6;6.6 Grundlagen für eine Zustimmung;130
6.7;7 Der Betriebsrat (Wie man Ängste zerstreut);132
6.7.1;7.1 Das Wiki nicht als Instrument zur Leistungsmessung missverstehen;132
6.7.2;7.2 Unbegründet: Angst vor Mitarbeiterüberwachung per Wiki;133
6.7.3;7.3 Eigene Inhalte kommunizieren und Unternehmenskultur positiv beeinflussen;133
6.7.4;7.4 Datenschutz sicherstellen;133
6.7.5;7.5 Verantwortung wahrnehmen: Wiki-Einführung als taktisches Mittel;134
6.8;8 Use-Cases: Was mit dem Wiki anfangen?;136
6.9;9 Das Erste Gebot: Teilen macht Spaß;138
6.9.1;9.1 Grundregeln, die das Teilen angenehm machen;139
6.9.2;9.2 Hemmschwellen entgegenwirken;141
6.9.3;9.3 Strong Backing from the Top fördert den Spaß am Teilen;141
6.10;10 Die Informationsarchitektur;143
6.10.1;10.1 Strukturelle Planung;143
6.10.2;10.2 Voll entwickelte versus organisch entstehende Struktur;143
6.10.3;10.3 Grobe Planung genügt;144
6.11;11 Nutzungsrichtlinien: Eine prototypische Wiki-Charta;146
6.11.1;11.1 Zusammenfassung der Wiki-Charta;146
6.11.2;11.2 Was macht man mit einem Wiki eigentlich?;147
6.11.3;11.3 Konkrete Anwendungsfälle;148
6.11.4;11.4 Was machen wir mit einem Wiki nicht?;148
6.11.5;11.5 Aktive Kommunikation mit Push und Pull;148
6.11.6;11.6 Abgrenzungskriterien in der Systemlandschaft;149
6.11.7;11.7 Regeln für die Eingrenzung oder Ausgrenzung von Anwendungsfällen;149
6.12;12 Rückblick: Warum wir der Capitol AG ein professionelles Design angeboten haben;151
6.12.1;12.1 Schlechte Integration behindert die Mitarbeiteraktivierung;152
6.12.2;12.2 Design-Anpassung heißt auch UsabilityOptimierung;153
6.12.3;12.3 Professionelle Druckund Exportfunktion spart Zeit;154
6.12.4;12.4 Joy of Use und damit Wiki-Akzeptanz steigern;154
6.12.5;12.5 Relevanz des Wikis untermauern;155
6.12.6;12.6 Argumente für ein professionelles Wiki-Design;156
6.13;13 Wissensaustausch (Arbeitskreise und Erfahrungsaustausch);157
6.13.1;13.1 Vorbehalte gegen den Arbeitskreis;158
6.13.2;13.2 Inhalte des Arbeitskreises;159
6.14;14 Wissenseinkauf;160
6.15;15 Feedbackschleifen (Wiki-Einführung als iterativer Prozess);162
6.15.1;15.1 Wiki-Gardening (Ordnung halten und darüber sprechen);165
6.15.2;15.2 Der Garten Firmenwiki wuchert zu: Ein Gärtner schafft Ordnung;165
6.15.3;15.3 Tolle Idee: Selten umgesetzt;167
6.15.4;15.4 Wer kann Gärtner werden?;168
6.16;16 Budget (Warum weniger nötig ist);170
6.17;17 Rollout: Lobbyarbeit;173
6.18;18 Rollout: Identifikation weiterer UseCases;176
6.18.1;18.1 Informationsangebote machen;176
6.18.2;18.2 E-Mail-Anhänge analysieren;177
6.18.3;18.3 Aufgaben in E-Mails analysieren;178
6.18.4;18.4 Hindernisse bei der E-Mail-Analyse;179
7;Teil 4: Wiki-Nutzung ankurbeln;181
7.1;1 Unternehmenspraxis: Welche Probleme treten bei der WikiNutzung auf?;182
7.1.1;1.1 Lessons Learned;183
7.1.2;1.2 Wiki-Nutzen entfaltet sich langfristig, Wikis haben einen hohen ROI;184
7.2;2 Best Practice: Per Scheunenbau inhaltliche Grundgerüste erstellen;185
7.2.1;2.1 Umzusetzende Inhalte priorisieren;185
7.2.2;2.2 Viele Dokumente mithilfe von Vorlagen erstellen;186
7.2.3;2.3 Je mehr angefangene Seiten, desto besser!;186
7.3;3 Kleine Maßnahmen mit großem Effekt;188
7.3.1;3.1 Wiki-Merchandising;189
7.3.2;3.2 Aufsteller und Aufkleber;189
7.3.3;3.3 Hall of Fame und Incentivierung durch Aufmerksamkeit;190
7.3.4;3.4 Messestand;191
7.3.5;3.5 Individuelle Werbeund Plakatkampagnen;191
7.3.6;3.6 Namensgebung;193
7.3.7;3.7 Anstrengen und am Ball bleiben!;193
7.4;4 Warum die Angst, Wissen zu teilen, unbegründet ist;195
7.4.1;4.1 Warum haben Mitarbeiter Bedenken, ihr Wissen zu teilen?;195
7.4.2;4.2 Missverständnis: Informationen versus Wissensanwendung;196
7.4.3;4.3 Das Wiki-Dashboard gibt Mitarbeitern etwas zurück;196
7.4.4;4.4 Weniger interne Fachfragen führen zu mehr Produktivität;197
7.5;5 Der Umgang mit Wiki-Gegnern;198
7.5.1;5.1 Konfrontation mit dem Wiki;198
7.5.2;5.2 Konfrontation mit Personas;198
7.5.3;5.3 Rezepte gegen Wiki-Zweifler;200
7.6;6 Überzeugungsstrategien, um WikiZweifel zu zerstreuen;201
7.6.1;6.1 Strategien, die zu allen Wiki-Zweiflern passen;201
7.6.2;6.2 Was Sie nicht tun dürfen;202
7.6.3;6.3 So überzeugen Sie Marc Microsoft und Gerd Gebichnichther;202
7.6.4;6.4 So bearbeiten Sie Bernd Blockierer;203
7.7;7 Texterstellung: Warum Mitarbeiter immer noch die E-Mail nutzen;205
7.7.1;7.1 Gründe von Mitarbeitern für das Erstellen und Versenden von Texten per E-Mail;206
7.7.2;7.2 Nachteile der Texterstellung per E-Mail;206
7.7.3;7.3 Vorteile der Wiki-Nutzung;207
7.8;8 Gewerbliche Mitarbeiter einbinden;209
7.9;9 Wiki-Chaos;212
7.9.1;9.1 Neue Wiki-Dokumente richtig anlegen: Wo und wie einsortieren?;212
7.9.2;9.2 Probleme mit der Einordnung und Auffindbarkeit von Dokumenten;212
7.9.3;9.3 Die optimale Organisation des Wissens;213
7.9.4;9.4 Wie kann man das Wiki-Chaos vermeiden?;213
7.9.5;9.5 Qualität statt Quantität?;214
7.9.6;9.6 Einheitliche Aufbereitung aller Dokumente ist unmöglich;215
7.9.7;9.7 Die Existenz von Inhalten ist wichtig, nicht die Form;215
7.10;10 Scheinriesen bekämpfen?;216
7.10.1;10.1 Vandalismus;216
7.10.2;10.2 Edit Wars;217
7.10.3;10.3 Fehler macht niemand absichtlich;218
7.10.4;10.4 Restriktionen torpedieren die Mitarbeiteraktivierung;218
7.11;11 Schulungen: Kultur, nicht Funktionen vermitteln;220
7.11.1;11.1 Szenario 1;220
7.11.2;11.2 Szenario 2;221
7.11.3;11.3 Tutorials und Anleitungen sind hilfreich;222
7.12;12 Kommunikation kanalisieren;224
7.12.1;12.1 Welche Informationen gehören in welchen Kanal?;225
7.12.2;12.2 Und welche Informationen gehören nun ins Firmenwiki?;228
7.12.3;12.3 Informationen für Mitarbeiter;228
7.12.4;12.4 Informationen zu Prozessen;229
7.12.5;12.5 Informationen über das und vom Unternehmen;229
7.12.6;12.6 Produktund Leistungsinformationen;230
7.12.7;12.7 Verbotsschilder aufstellen!;231
7.13;13 Bad Stories;232
7.13.1;13.1 Mangelnde Mitarbeiteraktivierung;232
7.13.2;13.2 Keine Identifikation;232
7.13.3;13.3 Software-Lösungen, die nicht die Unternehmensbedürfnisse abdecken;232
7.13.4;13.4 Festhalten an der falschen Software;233
7.13.5;13.5 Bürokratische Hürden und Vorbehalte;233
7.13.6;13.6 Sicherheitsaktionismus;234
7.13.7;13.7 Standard-Rollout;234
7.13.8;13.8 Keine Schulungsressourcen und falsche Prioritäten bei der Schulung;234
7.13.9;13.9 Nicht auffindbares Wissen;235
7.13.10;13.10 Fehlende Geduld;235
7.14;14 66 Anwendungsfälle für ein Firmenwiki;236
7.15;15 Schluss: Eine gute Nachricht;248
8;Sachregister;250
9;Die Autoren;254

Über Autor(innen)

Martin Seibert ist Gründer und Geschäftsführer von Seibert Media Consulting, Wiesbaden, einem Unternehmen, das in den Geschäftsfeldern Consulting, Design, Technologies und Systems tätig ist und unter anderem Intranets, Extranets, Web.Portale und Wikis entwickelt.
Sebastian Preuss und Matthias Rauer sind im Team von Seibert Media als Entwickler und Designer tätig.