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?
Häufige Fehler bei der Auswahl von Wiki-Software
Im Mittelpunkt der Evaluation müssen die Anforderungen des Unternehmens und die Frage stehen, welche Aufgaben die Mitarbeiter mithilfe des Wikis erfüllen sollen. Manche Unternehmen begehen den Fehler, das Pferd von hinten aufzuzäumen: Sie wählen eine Software aus, ohne dass ein konkreter Bedarf für die Nutzung besteht oder ohne dass das sie die Bedürfnisse des Unternehmens erfüllen kann. Anschließend wird viel Mühe darin investiert, Standardlösungen im Nachhinein an die tatsächlichen Anforderungen des Unternehmens anzupassen, was häufig nicht gelingt.
Am allerhäufigsten wird dieser Fehler in Unternehmen mit einer "Microsoft-Strategie" gemacht, bei der SharePoint 'eh da' ist und dann auch zum Einsatz kommt. Fast unzählbar sind die Anrufe von frustrierten und enttäuschten Kunden bei //SEIBERT/MEDIA, die eigentlich ein reines Firmenwiki und kein Sharepoint wünschen.
Auch häufig passiert: Die IT setzt ganz schnell ein MediaWiki auf und wir starten damit. Und wenn dann später festgestellt wird, dass MediaWiki eben nicht stark als Firmenwiki ist (siehe auch Video zum Thema), sind schon viele Inhalte erstellt, die einen aufwändigen Umzug der Daten erforderlich machen.
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