Dokumentation mit Wiki-Systemen

Die Theorie der vorherigen Lektionen war konsequent „Doku XY brauchst du" – aber wo legt man sie ab? Die Antwort heute lautet fast immer: in einem Wiki-System oder einer Docs-as-Code-Plattform. Wikis sind kollaborativ (mehrere Personen schreiben gleichzeitig), versioniert (jede Änderung wird gespeichert), volltextsuch-fähig und verlinkbar – die ideale Plattform für lebendige IT-Doku. Die letzte Lektion in diesem Doku-Kurs zeigt dir die wichtigsten Wiki-Tools (Confluence, Wiki.js, BookStack, MediaWiki, Outline, Notion), den modernen Gegenpol Docs-as-Code mit Markdown in Git, ein Beispiel einer guten Wiki-Seite mit Struktur und Metadaten, das Konzept der Berechtigungen pro Bereich, die wichtigsten Pflege-Strategien (Templates, Verfalls-Marker, Reviews) und die häufigsten Stolperfallen. Wer das Wiki-Setup richtig macht, hat eine selbst-pflegende Wissensbasis. Wer es schlecht macht, hat ein digitales Friedhof, in dem niemand findet, was er sucht.

1) Tool-Landschaft im Vergleich

Klick die Tools an, um Stärken, Schwächen und Anwendungsfälle zu sehen:

2) Beispiel einer guten Wiki-Seite

So sieht eine sauber strukturierte Wiki-Seite aus – nicht zu lang, nicht zu kurz, mit Metadaten und Querverweisen:

3) Berechtigungs-Konzept

Nicht jeder darf alles. Klassisches Berechtigungs-Konzept in einem Wiki:

4) Strukturierung – wie organisiert man die Inhalte?

Ein leeres Wiki ist ein Albtraum. Bewährte Strukturen:

• Spaces (Bereiche) auf oberster Ebene: nach Team (IT-OPS, Dev, Security), nach Anwendung (ERP, CRM, Cloud) oder nach Funktion (Onboarding, Compliance).
• Page Trees innerhalb der Spaces: hierarchisch, max. 3-4 Ebenen tief.
• Templates pro Seitentyp: Server-Steckbrief, SOP, Runbook, Architektur-Doku, Meeting-Protokoll. Erleichtert Konsistenz.
• Tags / Labels für Quersuche: tags wie production, critical, review-overdue.
• Dashboards / Landing Pages: pro Service eine Übersichts-Seite mit Verlinkungen zu allen relevanten Detail-Seiten.
• Glossar: zentral, mit Abkürzungen und Begriffen.

5) Wiki vs. Docs-as-Code

Der moderne Gegenpol zu klassischen Wikis: Docs-as-Code – Doku als Markdown-Dateien in Git, ähnlich wie Software-Quellcode behandelt:

Pragmatische Mischformen: Confluence für Business-Doku + Docs-as-Code für API-/Entwickler-Doku. Beide verlinken aufeinander.

6) Pflege-Strategien

Ein gepflegtes Wiki braucht aktive Pflege. Bewährte Mechanismen:

• Owner pro Seite: jede Seite hat eine verantwortliche Person. Bei Personalwechsel re-zuweisen.
• Review-Datum: jede Seite zeigt „zuletzt geprüft: 2026-04-15". Älter als 6 Monate → Markierung „Review fällig".
• Templates verbindlich: neue Seiten mit Template starten, nicht von leerer Seite.
• Wiki-Champion pro Team: eine Person, die im Team Doku-Qualität voran treibt.
• Quartals-Review: alle Page-Owner gehen ihre Seiten durch und bestätigen Aktualität.
• Definition of Done: Tickets / Changes nicht abgeschlossen, bevor Wiki-Update erfolgt.
• Onboarding-Pflicht: neue Mitarbeiter machen in Woche 1 eine Wiki-Tour.
• Suchbarkeits-Tests: regelmäßig prüfen: findet man Wichtiges per Suche in 30 Sekunden?

7) Suche – das wichtigste Wiki-Feature

Wenn die Suche schlecht ist, ist das Wiki tot. Was eine gute Wiki-Suche ausmacht:

• Volltextsuche – auch in Anhängen (PDFs, Excels).
• Filter nach Space, Tag, Owner, Datum.
• Auto-Complete – Vorschläge beim Tippen.
• Synonyme – „Firewall" findet auch „FW".
• Häufig-gesucht-Listen – Top-Suchen sichtbar (hilft Doku-Lücken zu erkennen).
• Suche im Mailclient / Browser-Erweiterung – direkter Zugriff ohne Tab-Wechsel.

Performante Suche bei Confluence durch Lucene/Elasticsearch im Hintergrund, bei selbst-gehosteten Wikis ggf. zusätzliches Search-Backend (Solr, Algolia).

8) Antipatterns

• Tool-Salat. Confluence, Notion, OneNote, SharePoint und MediaWiki parallel im Einsatz, niemand weiß wo was steht. Lösung: ein Hauptsystem festlegen, Migration der Inhalte.
• Wiki ohne Templates. Jede Seite anders aufgebaut, Suchen schwer, Konsistenz weg. Lösung: pro Seitentyp ein Template.
• Schreiberecht für alle. Chaos pur. Lösung: Editorrechte gezielt vergeben, gleichzeitig „Beitragen leicht machen" über Pull-Requests oder Vorschläge.
• Schreiberecht für niemanden außer Admin. Anderes Extrem – Doku wächst nicht, weil Hürde zu hoch. Lösung: Editor-Rechte für relevante Personen.
• Passwörter im Wiki. Sicherheitsproblem. Lösung: Vault-System (Bitwarden, HashiCorp Vault), im Wiki nur Verweis.
• Veraltete Seiten ohne Markierung. User folgt 3 Jahre alter Anleitung, baut Mist. Lösung: Review-Marker, Last-Modified prominent.
• Inhalte in Anhängen statt im Wiki. 30 Word-Files als Attachment, nicht durchsuchbar. Lösung: Inhalte als Wiki-Seiten, nur Original-Source-Dokumente als Anhang.
• Keine Verlinkung. Jede Seite Insel, keine Quer-Bezüge. Lösung: Verlinkungs-Kultur etablieren.
• Suche kaputt / nicht indexiert. Wichtige Seiten finden sich nicht über Suche. Lösung: regelmäßig Suchtests, Index-Status prüfen.
• Onboarding ohne Wiki-Tour. Neue Mitarbeiter wissen nicht, dass das Wiki existiert. Lösung: Wiki-Tour als Onboarding-Pflicht.
• Wiki-Backup fehlt. Bei Datenverlust ist alles weg. Lösung: regelmäßiges Backup mit Restore-Tests.

Zusammenfassung

Wiki-Systeme sind die heutige Standard-Plattform für IT-Doku: kollaborativ, versioniert, suchbar. Tool-Auswahl je nach Setup: Confluence (Enterprise), Wiki.js / BookStack / MediaWiki (Open Source), Notion (flexibel), Docs-as-Code mit Markdown in Git für Tech-/API-Doku. Gute Wiki-Seiten haben klare Struktur, Metadaten (Owner, Review-Datum), Templates und Querverweise – Berechtigungen werden pro Space vergeben (Viewer / Editor / Space-Admin / System-Admin). Pflege-Strategien: Owner pro Seite, Review-Marker, verbindliche Templates, Quartals-Review. Suche ist das wichtigste Feature – ohne sie ist auch das schönste Wiki tot.

Verwandte Lektionen: Warum Doku · Betriebshandbuch · Prozess-Doku · und mehrWeitere relevante LektionenServer-DokuNetzwerk-DokuLeistungen dokumentierenÜbergabeprotokollVeränderungsprozesseRBACBackup 3-2-1