Komponenten, die die Wiki-Einführung beeinflussen

Technologische Faktoren: Wichtig, aber überschätzt

Auswahl der richtigen Wiki-Software

• Welche Systeme gibt es und welches ist das richtige, um die eigenen Unternehmensprozesse abzubilden?
• Setzt man als Unternehmen auf Open-Source-Technologien oder wählt man eine kommerzielle Lösung?
• Welche Schwächen und Stärken haben die Lösungen, inwieweit sind sie anpassbar?
• Welche Schnittstellen zu anderen Systemen gibt es?
• Ist eine LDAP-Anbindung und zusätzlich eine Single-Sign-on-Lösung möglich?

Betrieb des Systems

• Hosting bei einem Drittanbieter. Nachteil: Das Wiki läuft außerhalb des internen Systems. Allerdings zeichnet sich insbesondere im Zuge des Cloud-Computing-Trends ein Umdenken ab und immer mehr Unternehmen werden in den nächsten Jahren anstreben, Hosting-Leistungen auszulagern.
• Interner Betrieb: am aufwändigsten und kostspieligsten, denn das Unternehmen benötigt entsprechendes Know-how (Systemadministrator, Sicherheitskonzept) und eine geeignete Infrastruktur (Hardware oder ein virtuelles System, in dem das Wiki läuft)

Technische Infrastruktur

• Einige Unternehmen stehen schon bei der Frage nach dem Browser vor einem Problem, denn in vielen Firmen kommt heute noch der IE 6 zum Einsatz, der zahlreiche Funktionen, die eine Wiki-Software bietet, nicht abbilden kann.
• Derzeit hat diese Komponente noch eine hohe Relevanz und manche Unternehmen stehen vor der Tatsache, dass ihr ausgereiftes Wiki-System nicht vollumfänglich genutzt werden kann.

Integration und Single-Sign-on

• Integration in eine Single-Sign-on-Lösung ohne zusätzliches Login
• Mitarbeiter empfinden es als sehr störend, wenn ein System separate Zugangsdaten erfordert.
• Das Wiki sollte komplett in die System-Infrastruktur integriert werden, um die Akzeptanzchancen zu erhöhen.

Organisation: Der kritische Faktor bei der Wiki-Einführung

Es sind nicht etwa technologische Aspekte, die hauptsächlich Schwierigkeiten bereiten. Unternehmen, die Wikis nutzen, führen fast ausschließlich organisatorische Probleme an, die die Etablierung behindern:

• Zu wenige Mitarbeiter, die aktiv und häufig Informationen ins Wiki stellen
• Teilnehmern wird der Nutzen des Wikis nicht schnell genug klar.
• Es ist schwierig, Teilnehmer für das Wiki zu motivieren.

Aufgabendefinition

• Welche Aufgaben sollen mit dem Wiki erledigt werden?
• Warum wird ein Wiki eingeführt?
• Welche Aufgaben gibt es, die die Mitarbeiter mit dem Wiki erledigen sollen?

Hier müssen schon von vornherein bestimmte Anwendungsfälle und die konkrete Nutzung des Wikis in Form von Use Cases definiert werden.

Strong Backing from the Top

• Die mangelnde Beteiligung der Geschäftsführung ist mit einem hohen Risiko verbunden, denn ohne die Unterstützung „von oben“ wird sich ein Software-Werkzeug kaum auf breiter Ebene durchsetzen können
• Immer wieder setzen sich Wikis zwar in einzelnen Abteilungen durch, doch ohne Förderung seitens des Managements wird ein unternehmensweiter Roll-out kaum möglich sein
• Es ist wichtig, dass die Einführung eines Wikis von der Unternehmensleitung uneingeschränkt unterstützt wird, auch im Hinblick auf Ressourcen und finanzielle Mittel

Verantwortung für das Wiki

• Es ist wichtig, dass jemand die Verantwortung für das Wiki übernimmt und die Einführung aktiv vorantreibt (Content-Integration, neue Plugins installieren, spezielle Anwendungsfälle lösen, Ansprechpartner sein, etc.)
• Stichwörter: Wiki-Gardening, Wiki Evangelist, First-Level-Support
• Viele Unternehmen unterschätzen hier die anfallenden Ressourcen und den nötigen, erheblichen Zeitaufwand, der bei der Erledigung dieser Aufgaben anfällt

Richtige Zusammensetzung des Wiki-Pilot-Projekts

• Ziel: möglichst viele relevante Inhalte strukturiert in das Wiki einzubringen, damit es interessant und attraktiv für alle Mitarbeiter wird
• nicht ausschließlich Early Adopters einbinden, sondern auch weniger Technologie-affine und eher skeptische Nutzer (möglichst repräsentativer Querschnitt des Unternehmens)

Roll-out

• Das Wiki promoten und es nicht bei einer einmaligen Bekanntgabe lassen
• Zumeist ist es nötig, sie ständig zu wiederholen, den Mitarbeitern das neue Werkzeug immer wieder ins Bewusstsein zu rufen (Wiki-Kugelschreiber, Aufsteller und Displays mit Informationen über das Wiki, besondere Partizipation des Managements oder von Führungskräften im Wiki, usw,)
• Wiki-Marketing kontinuierlich und über einen längeren Zeitraum hinweg betreiben

Schulung

• Zu wenig Schulung und Informationen darüber, wie das Wiki zu nutzen ist
• Mitarbeiter müssen mit der Oberfläche und den einzelnen Funktionen des Wikis vertraut werden
• Jeder Mitarbeiter ist anderes: Mitarbeitern verschiedene Maßnahmen zur Verfügung stellen und diejenigen Angebote wahrnehmen lassen, die ihm dabei helfen, das Wiki kennen und anwenden zu lernen

Abgrenzung des Wikis gegenüber anderen Systemen

• Obsolete, suboptimale Arbeitsmethoden nach und nach aus dem Tagesgeschäft zu verbannen
• Vorgaben formulieren, dass die Nutzung des Wikis in bewährten Anwendungsfällen zukünftig verbindlich ist, aber immer inkl. inhaltlicher Information, Begründung und Diskurs.
• Verbindliche Kommunikationsmuster definieren (Wann nutzt man das Wiki, wann andere Systeme? Wann versendet man eine E-Mail? Wann arbeitet man mit einem Dokumenten-Management-System?)

Bedeutung eines professionellen Layouts

• Wiki nicht "out of the box" implementieren, sondern im individuellen Design
• In Form einer qualitativ hochwertigen Lösung eine entsprechende Umgebung schaffen, in der die Mitarbeiter gerne und mit Freude agieren
• Mit einem System, das vertraut wirkt und integriert ist, identifizieren Mitarbeiter sich eher als mit einem Werkzeug, das als Fremdkörper im Intranet wahrgenommen wird.
• Außerdem: unternehmenspolitisches Zeichen setzen: Die Unternehmensführung unterstreicht durch die Investition in ein Layout im Corporate Design die Bedeutung des Wikis und signalisiert, dass sie an das System glaubt und es als zentrale und wichtige Plattform ansieht.

Neuer Kommunikationsansatz

Wandel des Kommunikationsansatzes im Unternehmen

• Üblich: Top-down-Ansatz
• Eine Veränderung fürchten viele Unternehmensführungsmitglieder: Der gewohnte Top-down-Ansatz nicht durch einen Bottom-up-Approach, aber durch einen kommunikativen Kreislauf abgelöst
• Aus Mitarbeitersicht wiederum kritisch: Mitarbeiter scheuen sich, ihr Wissen und damit ihr wertvollstes Gut zu teilen.

Bildung von Akzeptanz auf Entscheider-Ebene

• Gerade in größeren Unternehmen entscheiden Personen über eine Wiki-Einführung, die das Tool später gar nicht nutzen.
• Es gibt Entscheider, die dem Vorschlag einer Wiki-Einführung entgegnen: "Ich werde nicht damit arbeiten und deswegen brauche ich es auch nicht."
• Den entscheidungsbefugten Personen muss deutlich gemacht werden, dass es wichtig ist, dass sie eine Umgebung schaffen, in der die Mitarbeiter produktiv arbeiten können, und dass es nicht ihre Aufgabe ist, für die Einführung von Software zu sorgen, die ihnen persönlich hilft.

Innovationsskepsis

• Nimmt das Unternehmen Innovationen und neue Technologien schnell auf oder nicht?
• In konservativen Unternehmenskulturen wird neuen Technologien zunächst Skepsis und nicht selten Pauschalkritik entgegengebracht.
• Ist dies der Fall: umfassendere organisatorische Maßnahmen, mehr Wiki-Marketing, Wiki-Use-Cases stärker reglementieren

Lose Sammlung von Stolperfallen

• Fixierung auf eine Software: z.B. Microsoft Sharepoint
• Fixierung auf Open-Source als Pflichtprogramm
• Usability nicht berücksichtigen, dafür detaillierte Funktionslisten testen
• Zu wenig ansehen und erleben. Zu viel Planen und Vorausschauen, ohne zu wissen, was eigentlich geht.
• Der Glaube, besser zu wissen, als die Kollegen, was gut für die Kollegen ist. Den Mitarbeitern nicht die Freiheit zugestehen, eigene Entscheidungen zu treffen.
• Seine KollegInnen für dümmer halten, als man selbst ist.
• Zu glauben, dass es ein "zu viel" an Kommunikation gäbe, dass die Kollegen dann nicht mehr bewältigen könnten und deshalb alles reglementieren wollen.
• Den Mitarbeiter nicht in das Zentrum der Aktivitäten für die Implementierung eines Intranets stellen.
• Ignoranz für die Relevanz eines individuellen Designs
• Kollegen nicht abholen und fehlendes Schwitzen zum Beginn des Projekts.
• Leere Phrasendrescher statt fleissige Redaktionsbienen: Content is king
• Fehlendes Interesse und fehlende Integration der Führungsmannschaft: Es ist häufig so einfach die Chefs zu gewinnen. Versuchen Sie es wenigstens.
• Fehlende Integration der Mitarbeiter: kein Konzept, keine Schulungen, keine Feedback-Kanäle
• "Hier: Wiki! Friss!" hat noch nie funktioniert.
• Grabenkämpfe zwischen verschiedenen "Lagern", weil das Wiki nicht sauber abgegrenzt wurde. Häufige Schnittstellen: Dokumenten-Management-System, CRM-System, Microblog, Blog, E-Mail, Intranet, ERP-System, Meeting-Organisation, Prozess-Software, Wissensmanagement-Software, Content-Management-Software, ...
• Keine Konfrontation mit den Wiki-Skeptikern und deren Argumenten.
• Fehlende Offenheit im Unternehmen
• Fehlende Bereitschaft, ein Wiki im Unternehmen samt der dazugehörigen Philosophie tatsächlich auszuprobieren.
• Webinare als Möglichkeit bei verteilten Teams nicht anbieten
• Keiner ist für das Wiki verantwortlich
• Keiner hat Zeit für das Wiki