Wiki-Einführung: Ein Pilotprojekt als Pflichtprogramm

You never get a second chance to make a first impression. Bei der Einführung einer neuen und von ihrer Art her andersartigen Software passt dieser Aphorismus, der mal Oscar Wilde, mal Marc Twain zugesprochen wird, sehr gut, denn: Eine Wiki-Einführung kann man nicht beliebig oft wiederholen. Deshalb empfehlen wir, ein Wiki-Projekt im Rahmen einer Pilotphase auf die spätere Nutzung vorzubereiten. Gegenargumente soll dieser Artikel entkräften.

Liebe auf den zweiten Blick zwischen Wiki und Mitarbeitern gibt es nicht

Wenn die Wiki-Einführung schiefgeht, hinterlässt man „verbrannte Erde“ – und verbrannte Erde ist bekanntlich nicht sonderlich fruchtbar. Deshalb empfiehlt es sich, vor dem Rollout auf einen größeren Personenkreis mit einem Pilotprojekt zu starten, bei dem eine überschaubare Anzahl an Personen prüft, ob das Wiki die vorhandenen Erwartungen erfüllen kann. Das Pilotteam erkennt Probleme, behebt Fehler und bereitet das System auf die Nutzung im Unternehmen vor. Nur wenn das Wiki den Praxistest besteht, sollte es ausgerollt werden.

Die Antwort auf die Frage, wie dramatisch eine gescheiterte Wiki-Einführung ist, gibt uns die dritte Stufe des in einem anderen Artikel besprochenen Innovationsprozesses nach Everett M. Rogers, Decision. Während dieser Entscheidungsphase manifestiert sich die Einstellung gegenüber einer Innovation. Wenn die Innovation schlecht vorbereitet ist, entwickeln die Nutzer eine negative Einstellung, die in der Regel eine gewisse Stabilität hat. Zudem besteht die Gefahr, dass sich eine negative „öffentliche Meinung“ entwickelt. Es kann sein, dass die Innovation in der gesamten Abteilung, im gesamten Bereich, im gesamten Unternehmen negativ wahrgenommen wird. Selbst Mitarbeiter, die noch nicht mit dem neuen Tool in Berührung gekommen sind, nehmen eine reservierte Haltung ein.

Medienwissenschaftler sprechen in diesem Zusammenhang von einem negativen Frame, die Neuheit erhält keine faire Chance. Deshalb ist ein Pilotprojekt so wichtig: Je größer der Personenkreis ist, der das Wiki im Falle einer schlecht vorbereiteten Einführung ablehnt, desto mehr verbrannte Erde produziert man.

Wiki-Pilotprojekt: "Gute Idee, aber ..."

Viele Wiki-Champions, die in ihren Unternehmen ein Wiki etablieren wollen, signalisieren hier Zustimmung und Verständnis für das Konzept des Wiki-Piloten. Erstaunlicherweise möchten eben jene Leute dennoch auf ein Pilotprojekt verzichten: Theoretisch finden sie die Idee eines Pilotprojekts gut, in der Praxis wollen sie dann aber doch lieber sofort loslegen. Drei Gründe werden dafür immer wieder angeführt: Pilotprojekte kosten Geld, benötigen Zeit und sind im spezifischen Fall überflüssig. Die Argumente klingen zunächst überzeugend, entpuppen sich bei näherer Betrachtung jedoch als Scheinargumente.

Gegenargument 1: Kosten
Die meisten Wiki-Einführungsprojekte haben ein überschaubares Gesamtbudget. Ein Pilotprojekt, so die Befürchtung, erhöht dieses Budget und ist ein Kostentreiber. Dieses Argument ist sowohl kurzsichtig als auch falsch. Die externen Kosten erhöhen sich durch das Vorschalten eines Pilotprojekts in der Regel nur geringfügig. Meist müssen lediglich zusätzliche Workshops durchgeführt werden, weil mehrere Personengruppen zu schulen sind, erst das Pilotteam, dann das Rolloutteam. Allerdings lässt sich selbst dieser überschaubare Mehraufwand durch ein Train-the-trainer-Seminar, bei dem interne Mitarbeiter in die Lage versetzt werden, selbständig Wiki-Einführungsschulungen zu halten, nochmals reduzieren.

Richtig ist hingegen, dass die internen Kosten steigen, weil man mehr Zeit mit evaluieren, testen, kommunizieren und iterieren verbringt. Allerdings erhält man dafür auch ein besseres Produkt und spart so Folgekosten. Vielleicht stellt sich heraus, dass ein zusätzliches Plugin benötigt wird, weil die Bordmittel nicht ausreichen. Möglicherweise zeigt sich, dass am Layout noch etwas verändert werden muss, weil eine bestimmte Umsetzung verwirrend ist.

Natürlich kann man die Vogel-Strauß-Taktik anwenden, den Kopf in den Sand stecken und diese Probleme ignorieren. Dann entstehen zwar kurzfristig keine Kosten, aber die Probleme werden auch nicht gelöst. Statt der Pilotgruppe beschweren sich dann die Nutzer, die nach dem Rollout mit dem System arbeiten müssen. Und vielleicht führen genau diese Probleme dazu, dass das Wiki nicht angenommen, sondern abgelehnt wird.

Es ist eine Erkenntnis, die so alt ist wie die Software-Entwicklung selbst: Wer Fehler macht, weil er im Planungsstadium spart, muss ein Vielfaches ausgeben, um die Fehler nach der Implementierung wieder zu beheben.

Gegenargument 2: Zeit
Oft gibt es Termine, die Dritte vorgegeben haben. Manchmal soll das Wiki in einem konkreten Projekt zum Einsatz kommen, das bald startet. Manchmal gibt es Vorgaben vom Vorstand, die das Projektteam einzuhalten hat. Die Erwartungen an die sog. Lead Time (das ist die Zeit von der Anfrage des Kunden bis zur Auslieferung des Produkts durch den Dienstleister) sind manchmal geradezu utopisch.

Wir empfehlen in solchen Fällen, den Grund für den straffen Zeitplan zu hinterfragen. Vielfach ist die Hektik hausgemacht und lässt sich durch eine Abstimmung mit den entsprechenden Personen entschärfen. Es ist übrigens ein allgemeines Phänomen von Software-Projekten, dass diese unter teilweise enormen Zeitdruck umgesetzt werden. Viel zu selten wird dabei gefragt, woher dieser Druck eigentlich kommt und ob er dem Projektergebnis und auch den Unternehmenszielen wirklich zuträglich ist. Eine objektive und nüchterne Betrachtung führt oft zu einer Entspannung im Hinblick auf die zeitliche Komponente.

Gegenargument 3: Überschätzung
Viele Personen unterschätzen die Komplexität einer Wiki-Einführung – und sie überschätzen sich selbst und die Adoptionsfähigkeit ihrer Mitarbeiter. Das Argumentationsmuster ist dabei immer gleich: Bei einem Wiki handelt es sich um eine Software mit einer guten Usability. Und die Kollegen, die mit dem System arbeiten sollen, sind allesamt clevere Leute. Weshalb also mit einer Vorstudie Zeit und Geld verschwenden?

Unterstellen wir, dass ein Unternehmen sich für eine wirklich ausgereifte Wiki-Software wie Confluence entscheidet und die Mitarbeiter wirklich fit sind im Umgang mit Computern und dem Web. Dennoch handelt es sich bei einer Wiki-Einführung um eine Innovation, die zu einer Veränderung der bisherigen Arbeitsabläufe führt. Es bedarf eines Umlernens und einer Umgewöhnung, und zwar nicht nur was die Bedienung der neuen Software angeht, sondern auch was die emotionale Bindung betrifft. Die Mitarbeiter benötigen Unterstützung und Zeit, um sich an das neue System zu gewöhnen.

Erst vorbereiten, dann ausrollen

Aus diesen Gründen raten wir Unternehmen, die ein Wiki einführen wollen: Rollen Sie das Wiki erst aus, wenn Sie sicher sind, dass es die Anforderungen Ihrer Mitarbeiter erfüllt, und nehmen Sie sich die Zeit für ein Pilotprojekt. In der Regel verschiebt sich der Rollout um nicht mehr als einen Monat und die Kosten steigen um maximal 5.000 Euro. So viel sollte eine erfolgreiche Wiki-Einführung wert sein.

Möchten Sie in Ihrem Unternehmen ein Wiki einführen? Brauchen Sie Unterstützung bei einem laufenden Wiki-Projekt? Benötigen Sie Informationen über Inhalte und die Durchführung eines Pilotprojekts? Haben Sie Fragen zur Mitarbeiteraktivierung? Wir sind Experten für Unternehmenskommunikation und beraten Sie gerne: Bitte sprechen Sie uns unverbindlich an. Ausführliche Informationen haben wir auch auf unserer speziellen Seite zum Thema Firmenwikis für Sie zusammengestellt.

Weiterführende Informationen

Erfolgsfaktoren für Wikis: Organisation ist der Schlüssel
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Erfolgsfaktor Strong Backing from the Top
Return on Investment von Firmenwikis


Mehr über die Creative-Commons-Lizenz erfahren

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.