Warum die Einführung von Wikis scheitert (und es nicht an den Mitarbeitenden liegt)

Wenn du in den letzten fünf Jahren ein Wiki eingeführt hast, kennst du diesen Ablauf wahrscheinlich: Ankündigungsmail, begeisterte erste Beiträge von einer Handvoll engagierter Kolleg:innen, allmähliches Abflauen, immer weniger neue Inhalte und schliesslich das stille Eingeständnis, dass das Wiki «nicht richtig abgehoben hat». Die Diagnose danach ist fast immer dieselbe: Die Leute wollen halt nichts dokumentieren.

Diese Diagnose ist falsch oder zumindest unvollständig. Die meisten Wissensarbeitenden wollen genau das, was ein Wiki bieten soll: weniger Zeit für immer gleiche Fragen, ein schnelleres Onboarding für neue Kolleg:innen und einen verlässlichen Ort, an dem Entscheide und ihre Begründung zu finden sind. Der Wunsch nach guter Dokumentation ist echt. Was fehlt, ist nicht die Motivation, sondern das Umfeld, in dem Dokumentieren zur Gewohnheit wird statt zum Kraftakt.

Wenn die Einführung scheitert, sind die Ursachen fast immer struktureller Natur: zu viele Hürden, eine verwirrende Informationsarchitektur, eine Suche, die so schlecht ist, dass niemand darauf vertraut, dass das Geschriebene je gefunden wird, oder ein Wiki, das zu weit weg ist vom Ort, an dem die Arbeit tatsächlich passiert. Wer den Mitarbeitenden die Schuld gibt, verdeckt diese Ursachen und sorgt dafür, dass sie sich auf der nächsten Plattform wiederholen.

Muster 1: Das Problem der leeren Seite

Die meisten Wikis zeigen neuen Mitwirkenden einen leeren Editor und erwarten stillschweigend, dass daraus eine gut strukturierte Seite entsteht. Für erfahrene technische Redakteur:innen ist das Routine. Für Product Manager, Entwickler:innen oder HR-Fachleute, die etwas zu dokumentieren haben, sich aber nicht für das Handwerk der Dokumentation interessieren, ist es lähmend.

Der Aufwand für einen Beitrag steigt damit von «aufschreiben, was ich weiss» zu «entscheiden, wie ich das strukturiere, ein Format wählen und etwas produzieren, das professionell genug für eine Veröffentlichung aussieht». Diesen Aufwand nehmen die meisten nicht regelmässig auf sich, schon gar nicht, wenn sie viel zu tun haben.

Vorlagen setzen genau hier an. Eine gute Vorlage gibt die Struktur der Seite vor, sodass du nur noch den Inhalt einfügen musst und nicht über die Form nachdenken. Teams, die früh in Vorlagen investieren, etwa für Sitzungsnotizen, Projektstarts, Entscheidungsprotokolle, Prozessdokumentation oder Vorfallberichte, verzeichnen dauerhaft mehr Beiträge als Teams, die nur eine leere Leinwand bieten.

Muster 2: Das Navigationslabyrinth

Die meisten Unternehmenswikis sind als Baum organisiert: Bereiche ganz oben, darin Abschnitte, darin Seiten. In der Theorie ist das eine logische Hierarchie. In der Praxis verzweigt sich der Baum unvorhersehbar, sobald mehr als ein Team mitarbeitet. Die IT organisiert nach Systemen, HR nach Prozessen, das PMO nach Projekten. Keine dieser Hierarchien ist falsch, aber zusammen ergeben sie eine Struktur, in der du dich nur zurechtfindest, wenn du schon weisst, wo etwas liegt.

Wenn die Navigation mühsam ist, weichen die Leute auf die Suche aus. Ist auch die Suche schlecht, was oft der Fall ist, geben sie auf und fragen jemanden. Das ist keine Faulheit, sondern eine vernünftige Reaktion auf ein System, das mehr Aufwand verlangt als die Alternative.

Organisationen, die das gut lösen, investieren schon vor dem Start in die Informationsarchitektur und gestalten die oberste Ebene bewusst, statt sie organisch wachsen zu lassen. Sie wissen auch, dass Navigation allein nicht reicht: Die Suche muss gut genug funktionieren, um ein verlässlicher zweiter Weg zu jedem Inhalt zu sein. Navigation und Suche ergänzen sich, sie ersetzen sich nicht.

Muster 3: Das Problem «Wo gehört das hin?»

Selbst motivierte Mitwirkende halten inne, wenn sie nicht wissen, wohin ein neuer Inhalt gehört. Ist das eine neue Seite oder ein Abschnitt auf einer bestehenden? Gehört es in den Bereich Engineering oder Product? Diese kleinen Entscheidungen, bei jedem Beitrag aufs Neue, summieren sich zu einer Hürde, die die meisten lösen, indem sie gar nichts beitragen.

Die Lösung besteht aus zwei Dingen: klare Zuständigkeiten für Bereiche und Abschnitte, damit es immer jemanden gibt, den du fragen kannst, und eine einfache Möglichkeit, Inhalte als «noch einzuordnen» zu markieren, damit aus «Ich weiss nicht, wo das hingehört» nicht «Ich schreibe es gar nicht erst» wird. Manche Wikis unterstützen Entwürfe oder eine Art Eingangskorb für Seiten, die erstellt, aber noch nicht eingeordnet sind. So wird das Schreiben vom Organisieren getrennt.

Muster 4: Losgelöst vom Arbeitsalltag

Am schwersten setzen sich Wikis durch, die den meisten Kontextwechsel verlangen. Wenn du für ein Update einen neuen Tab öffnen, zum richtigen Bereich navigieren, die Seite finden, in den Bearbeitungsmodus wechseln, die Änderung machen, speichern und veröffentlichen musst, ist jeder Schritt eine Hürde. Zusammen ergeben sie eine Aufgabe, die die meisten auf unbestimmte Zeit verschieben.

Wiki-Tools, die sich in die Plattformen einfügen, auf denen die Leute ohnehin ihren Arbeitstag verbringen, senken diesen Aufwand deutlich. Wenn dir jemand im Chat eine Frage stellt und du sie beantworten und dabei gleich eine Wiki-Seite erstellen oder aktualisieren kannst, verteilt sich der Aufwand auf etwas, das du sowieso gerade tust. Das Wiki entsteht dann nebenbei bei der normalen Arbeit, statt eine eigene Tätigkeit zu sein, für die du dir extra Zeit nehmen musst. Integrationen mit Slack, Teams und ähnlichen Plattformen sind deshalb nicht nur bequem, sondern ein echter Hebel für die Akzeptanz.

Muster 5: Mobil funktioniert nichts

Unternehmenswikis sind überwiegend für den Desktop gebaut. Bearbeitungsoberflächen, die mit Tastatur und Maus gut funktionieren, werden auf dem Smartphone umständlich oder unbrauchbar. Das ist heute wichtiger als früher: Die Momente, in denen Dokumentieren am natürlichsten wäre, nach einem Meeting, auf dem Arbeitsweg oder nach einem Gespräch, sind oft mobile Momente.

Ein Wiki, zu dem du vom Smartphone aus nichts beitragen kannst, steht dir nur in etwa der Hälfte der Situationen zur Verfügung, in denen du es nutzen möchtest. Mobile Unterstützung ist kein Luxus. Sie ist eine Voraussetzung dafür, dass das Wiki zu allen Arbeitsweisen in einer modernen Organisation passt.

Was erfolgreiche Einführungen gemeinsam haben

Organisationen, in denen ein Wiki dauerhaft genutzt wird, haben meist ein paar Gemeinsamkeiten. Mit der Wahl eines besonders cleveren Tools oder einer überzeugenden Launch-Kampagne haben diese wenig zu tun.

Sie starten mit einem konkreten, wertvollen Anwendungsfall statt mit der Vorgabe «Alles kommt ins Wiki». Sie investieren zuerst in Vorlagen und erst dann in Inhalte, damit Mitwirkende eine klare Struktur haben. Sie bestimmen Verantwortliche für die wichtigsten Bereiche. Sie machen das Wiki in den Tools sichtbar, die ohnehin genutzt werden. Und sie behandeln die ersten drei Monate wie ein Produktmanagement-Thema: Sie beobachten, wo die Leute hängen bleiben, und räumen Hürden aus dem Weg, statt nur auf Schulung und Kommunikation zu setzen.

Das Tool spielt eine Rolle, aber eine kleinere als das Umfeld. Die wichtigste Frage bei der Evaluation eines Wikis ist nicht «Welche Plattform hat die meisten Funktionen?», sondern «Mit welcher Plattform fällt es den Leuten am leichtesten, ganz selbstverständlich das Richtige zu tun?» Akzeptanz ist eine Frage des Designs, nicht der Willenskraft.