Ein internes Wiki aufbauen, das genutzt wird

Warum so viele Wikis im Betrieb verwaisen

Der Ablauf ist oft derselbe. Ein Inhaber oder eine engagierte Mitarbeiterin richtet ein Wiki ein, legt eine Struktur an und bittet alle, ihr Wissen einzutragen. In den ersten Wochen entstehen Seiten zu Abläufen, Kunden und Werkzeugen. Nach einigen Monaten sind die Seiten veraltet, neue kommen kaum hinzu, und Fragen werden wieder per Zuruf beantwortet. Das Wiki existiert noch, aber niemand verlässt sich mehr darauf.

Daraus folgt die Leitfrage dieses Beitrags: Wie baut ein kleiner Betrieb ein internes Wiki auf, das nach einem Jahr noch genutzt und gepflegt wird? Dafür klären wir zuerst, was ein Wiki ist und wofür es sich eignet, stellen dann das Wissensdilemma als Denkmodell vor, sehen uns die Befunde aus Fallstudien an, wägen zwei Arten des Aufbaus ab und beschreiben am Ende einen Aufbau in sechs Schritten.

Ein Wiki stirbt nicht an fehlender Technik, sondern daran, dass Schreiben für den Einzelnen mehr kostet, als es ihm bringt.

Was ist ein Wiki, und wofür eignet es sich?

Ein Wiki ist eine Sammlung von Seiten, die jeder Berechtigte direkt im Browser anlegen und ändern kann. Jede Änderung wird in einem Versionsverlauf festgehalten, und Seiten lassen sich untereinander verknüpfen. Der Name geht auf das hawaiische Wort für schnell zurück. Das bekannteste Wiki ist Wikipedia. In Unternehmen heißt es oft internes Wiki, Wissensdatenbank oder Teamhandbuch.

Ein Wiki eignet sich für Wissen, das sich ändert und von vielen gebraucht wird: Abläufe, Ansprechpartner, Antworten auf wiederkehrende Fragen, Einstellungen von Maschinen und Programmen, Regeln für die Zusammenarbeit. Es eignet sich weniger für Dateien, die sich nach dem Erstellen nicht mehr ändern, wie Verträge oder Rechnungen. Diese gehören in die Ablage, die der Beitrag Digitale Ablage beschreibt. Und es ersetzt nicht die Weitergabe von Erfahrungswissen durch Mitmachen und Zusehen, die der Beitrag Wissen sichern, bevor erfahrene Mitarbeiter gehen nach dem Modell von Nonaka und Takeuchi beschreibt.

Das Denkmodell: das Wissensdilemma

Ángel Cabrera und Elizabeth Cabrera (2002) haben eine Erklärung dafür vorgelegt, warum Wissenssysteme oft leer bleiben, obwohl alle sie nützlich finden. Sie beschreiben das Teilen von Wissen als soziales Dilemma, ähnlich einem öffentlichen Gut. Für den Einzelnen kostet das Aufschreiben Zeit, und manchmal gibt er damit einen Vorsprung ab. Der Nutzen fällt bei allen an, auch bei denen, die selbst nichts beitragen. Handeln alle nach ihrem kurzfristigen Vorteil, schreibt fast niemand, und alle stehen schlechter da, als wenn jeder etwas beigetragen hätte.

Eine Analogie aus dem Alltag ist die gemeinsame Teeküche. Jeder profitiert von einer sauberen Küche, aber das Abwaschen kostet den, der es tut. Ohne Regel, ohne Sichtbarkeit und ohne das Gefühl, dass der eigene Beitrag etwas bewirkt, stapelt sich das Geschirr. Ein Wiki ist eine Teeküche für Wissen.

Aus der Forschung zu solchen Dilemmata leiten die Autoren drei Arten von Gegenmaßnahmen ab. Sie sind der Kern des Aufbaus, der weiter unten beschrieben wird.

Was Fallstudien über Wikis in Unternehmen zeigen

Lin und Ehrlich (2012) untersuchten das interne Wiki eines deutschen IT-Dienstleisters, das 2008 eingeführt worden war und sich nach und nach zum weltweiten Intranet des Unternehmens entwickelt hatte. Es umfasste rund 56.000 Seiten. Die Autoren ordneten die Seiten vier Einsatzarten zu: Darstellung und Mitteilung, Nachschlagewerk, Projektorganisation und gemeinsames Gestalten. In Interviews nannten die Mitarbeiter als Hauptgrund für die Nutzung fast immer eigene Ziele, etwa die eigene Arbeit zu organisieren oder Anfragen zu sparen. Uneigennützige Motive wie anderen helfen wurden selten als Hauptgrund genannt. Die Autoren folgern, dass ein Wiki vor allem über die Einsatzarten wächst, die dem Schreibenden selbst nützen.

Stocker, Richter, Hoefler und Tochtermann (2012) beschrieben drei Wiki-Einführungen in Unternehmen. Die Wikis wurden sehr unterschiedlich genutzt: als Wissensbasis, als Nachschlagewerk und als Unterstützung im Kundenservice. Die Nutzung passte sich jeweils der konkreten Arbeit an. Als Lehren nennen die Autoren, dass die Beteiligten den möglichen Nutzen kennen müssen, dass die Führung die Einführung zusätzlich unterstützen muss und dass es eine klare Kommunikation braucht, wofür das Wiki da ist.

Für kleine und mittlere Betriebe gibt es eine neuere Fallstudie. Schober, Stampfl und Geyer (2025) begleiteten einen mittelständischen Hersteller von Schwimmbecken in Österreich bei der Einführung einer Wissensdatenbank auf Wiki-Basis und befragten Mitarbeiter verschiedener Ebenen. Die Zufriedenheit stieg, vor allem weil Informationen leichter zu finden waren und Abläufe glatter liefen. Wie zufrieden jemand war, hing davon ab, ob das System seinen konkreten Wissensbedarf deckte. Mittleres Management und Fachkräfte profitierten mehr als Geschäftsleitung und Verwaltung. Die Studie ist qualitativ und betrifft einen einzigen Betrieb.

Eine bibliometrische Auswertung von Budić, Klopotan und Hegeduš (2025) über 352 Veröffentlichungen zeigt zudem, dass die Forschung zu Wikis nach dem Höhepunkt der Web-2.0-Zeit zurückging. Wikis werden heute eher als Hintergrund für andere Werkzeuge gesehen, etwa als Wissensgrundlage für generative KI. Für den Betrieb heißt das: Das Wiki ist heute oft ein Teil einer Arbeitsplattform und kein eigenes System mehr.

Nachschlagewerk oder Arbeitswerkzeug? Zwei Arten des Aufbaus

Es gibt zwei Lesarten, wie ein Wiki aufgebaut werden sollte. Die erste orientiert sich an Wikipedia: Ein Nachschlagewerk mit einer durchdachten Gliederung, in das alle ihr Wissen eintragen. Dafür spricht die Ordnung. Wer etwas sucht, findet es an einer erwartbaren Stelle. Dagegen spricht das Wissensdilemma. Die Pflege eines Nachschlagewerks ist Zusatzarbeit, und Zusatzarbeit wird im Tagesgeschäft als Erstes gestrichen.

Die zweite Lesart sieht das Wiki als Arbeitswerkzeug: Seiten entstehen, weil jemand sie für die eigene Arbeit braucht, etwa eine Checkliste für den eigenen Ablauf oder eine Antwort, die er sonst dreimal pro Woche geben müsste. Dafür sprechen die Befunde von Lin und Ehrlich: Genutzt wird, was dem Schreibenden selbst nützt.

Ich halte die zweite Lesart für die tragfähigere, mit einem Zugeständnis an die erste. Eine schlanke Grundgliederung mit vier bis sechs Bereichen braucht es, damit Seiten auffindbar bleiben. Alles darunter sollte aus der Arbeit wachsen. Ein Wiki, das als Nachschlagewerk geplant wird, wirkt am ersten Tag vollständig und ist nach einem Jahr veraltet. Ein Wiki, das als Werkzeug wächst, wirkt am ersten Tag dünn und ist nach einem Jahr das, was alle nutzen.

Ein Wiki in sechs Schritten aufbauen

Der folgende Aufbau setzt die drei Hebel des Wissensdilemmas um. Er ist für einen Betrieb mit fünf bis fünfzig Beschäftigten gedacht und braucht in den ersten vier Wochen etwa eine Stunde pro Woche für die verantwortliche Person.

1. Einen Ort wählen

   Nimm das Werkzeug, das das Team ohnehin täglich öffnet. Ein Wiki in einem zusätzlichen System, das niemand sonst nutzt, verliert gegen das Postfach.

2. Eine schlanke Grundgliederung anlegen

   Vier bis sechs Bereiche, etwa Abläufe, Kunden und Aufträge, Werkzeuge, Ansprechpartner, Regeln. Keine tiefere Struktur auf Vorrat.

3. Mit den häufigsten Fragen beginnen

   Sammle zwei Wochen lang jede Frage, die im Team mehr als einmal gestellt wird. Die zehn häufigsten werden die ersten Seiten.

4. Vorlagen für Seiten bereitstellen

   Eine Vorlage für Prozessseiten, eine für Antworten, eine für Ansprechpartner. Das senkt den Aufwand für jede neue Seite.

5. Mit Links antworten

   Wer eine Frage beantwortet, deren Antwort im Wiki steht, schickt den Link statt der Antwort. Fehlt die Seite, schreibt er sie und schickt dann den Link.

6. Besitzer und Prüfdatum festlegen

   Jede Seite hat einen Besitzer und zeigt das Datum der letzten Prüfung. Seiten älter als zwölf Monate werden geprüft oder archiviert.

Der fünfte Schritt ist der wichtigste. Er macht das Wiki zum Ort der Antworten, nicht zum Ort, an dem Antworten zusätzlich abgelegt werden. Die Regeln aus dem sechsten Schritt entsprechen denen, die der Beitrag Wissensmanagement im Vertrieb für Vertriebswissen beschreibt. Wie eine einzelne Prozessseite aufgebaut ist, zeigt die Ein-Seiten-Methode.

Ein Beispiel für eine Arbeitsplattform, die Aufgaben und Wissensseiten an einem Ort verbindet, ist quik OS, ein Werkzeug eines Geschäftspartners von Owners Council. Ob dieses oder ein anderes Werkzeug passt, prüfst du mit denselben Fragen: Öffnet das Team es täglich? Findet ein neuer Kollege eine Antwort in unter einer Minute? Lassen sich Besitzer und Prüfdatum je Seite festhalten?

Wo ein Wiki an seine Grenzen stößt

Ein Wiki speichert, was sich aufschreiben lässt. Erfahrungswissen, das sich erst beim Tun zeigt, etwa das Gespür für einen schwierigen Kunden oder das Einstellen einer Maschine nach Gehör, lässt sich nur unvollständig in Seiten fassen. Dafür braucht es Begleitung und Mitmachen. Für die Einarbeitung neuer Kollegen ist das Wiki deshalb eine Hilfe, aber kein Ersatz für einen Paten, wie ihn der Beitrag Neue Mitarbeiter einarbeiten vorsieht.

Auch die Befundlage hat Grenzen. Die zitierten Studien sind Fallstudien einzelner Unternehmen, zum Teil aus der IT-Branche und aus der Zeit, als Wikis neu waren. Sie zeigen Muster, keine gesicherten Wirkungen.

Fazit: Wie wird ein internes Wiki genutzt?

Gefragt war, wie ein kleiner Betrieb ein Wiki aufbaut, das nach einem Jahr noch genutzt wird. Die Antwort liegt weniger in der Software als im Wissensdilemma. Schreiben kostet den Einzelnen, der Nutzen fällt bei allen an. Ein Wiki lebt deshalb, wenn Beitragen weniger kostet und mehr bringt: Seiten entstehen aus der eigenen Arbeit, Vorlagen senken den Aufwand, Antworten werden mit Links gegeben, und jede Seite hat einen Besitzer und ein Prüfdatum.

Wie gezeigt, deuten die Fallstudien in dieselbe Richtung. Genutzt wird, was dem Schreibenden selbst nützt, und die Führung muss die Einführung sichtbar unterstützen. Ein Wiki ist am Ende kein Archiv des Wissens, sondern eine Gewohnheit des Teams.

So fängst du an

1. Lege fest, in welchem Werkzeug das Wiki liegen soll, das das Team schon täglich nutzt.
2. Lege vier bis sechs Bereiche an und nicht mehr.
3. Bitte das Team, zwei Wochen lang jede wiederholte Frage auf einer Liste zu notieren.
4. Schreibe selbst die erste Seite zu einer Frage, die du oft beantwortest, und antworte ab jetzt mit dem Link.
5. Vereinbare in der nächsten Wochenrunde die Regel: Wer eine Antwort zum zweiten Mal gibt, schreibt eine Seite.