Unternehmenswiki einführen: Vorgehen, Werkzeugwahl und Betrieb

Sie wollen ein Wiki einführen, wissen aber noch nicht, welches? Die Wiki-Auswahl von WZ-IT vergleicht BookStack, XWiki, Docmost und Wiki.js mit Ihren Inhalten. Während der Auswahl probieren Sie alle vier in Demo-Instanzen mit Beispielinhalten selbst aus, das Ergebnis ist eine Entscheidungsvorlage, ab 3.900 € netto. Kostenloses Erstgespräch vereinbaren

Ob ein Unternehmenswiki genutzt wird, entscheidet sich weniger bei der Software als bei Struktur, Zuständigkeiten und Pflege. Ein Wiki ohne feste Ordnung und ohne Verantwortliche wird nach kurzer Zeit zur zweiten Dateiablage, in der niemand mehr sucht. Die Einführung ist deshalb ein Projekt mit klaren Schritten, nicht die Installation eines Werkzeugs.

Dieser Leitfaden beschreibt die Einführung mit einem selbst betriebenen Open-Source-Wiki: vom Ziel über Struktur, Rollen und Werkzeugwahl bis zu Rechten aus dem Verzeichnisdienst, Pilot, Redaktionsprozess, Schulung und Betrieb. Welches der Systeme grundsätzlich zu welcher Organisation passt, vergleicht der Beitrag BookStack, Wiki.js, XWiki oder Docmost. Wer von Confluence Data Center kommt, findet Fristen und Migrationswege im Beitrag zum Confluence Data Center End of Life. Stand Oktober 2026.

Die sechs Schritte in Kürze:

1. Ziel, Zielgruppen und vorhandenen Bestand klären.
2. Struktur und Rollen festlegen, einschließlich Rechtematrix.
3. Das Werkzeug nach Lizenz- und Betriebsgrenzen wählen.
4. Anmeldung und Rechte an den Verzeichnisdienst anbinden.
5. Mit einem echten Bereich und echten Nutzern pilotieren.
6. Einen Redaktionsprozess mit Verantwortlichen und Prüfintervallen einführen.

Inhaltsverzeichnis

1. Warum Wikis nach drei Monaten nicht mehr genutzt werden
2. Schritt 1: Ziel, Zielgruppen und Bestand klären
3. Schritt 2: Struktur und Rollen festlegen
4. Schritt 3: Das Werkzeug nach Lizenz und Betrieb wählen
5. Schritt 4: Rechte aus dem Verzeichnisdienst übernehmen
6. Schritt 5: Pilot mit einem echten Bereich
7. Schritt 6: Redaktionsprozess, damit das Wiki aktuell bleibt
8. Schulung nach Rollen statt Einweisung für alle
9. Betrieb: Updates, Sicherung und Wiederherstellung
10. KI-Suche als Ausbau, nicht als Start
11. Verbreitete Irrtümer bei der Wiki-Einführung
12. Unser Vorgehen bei WZ-IT
13. Weiterführende Guides

Warum Wikis nach drei Monaten nicht mehr genutzt werden

Ein neues Wiki startet meist mit Schwung. Einige Wochen später werden Seiten nicht mehr aktualisiert, Dokumente landen wieder in der Dateiablage, Fragen werden wieder im Chat gestellt. Die Ursachen sind fast immer organisatorisch, und jede lässt sich einem Schritt der Einführung zuordnen:

Die Software spielt dabei eine Nebenrolle. Sie muss aber zu Struktur, Rechten und Anmeldung passen, sonst entstehen genau die Hürden aus der Tabelle.

Schritt 1: Ziel, Zielgruppen und Bestand klären

Am Anfang steht die Frage, wofür das Wiki da ist und für wen. Typische Dokumentationsarten sind:

• Handbücher und Richtlinien für alle Mitarbeitenden, etwa Arbeitsschutz, Datenschutz, Reisekosten.
• Prozessbeschreibungen einzelner Abteilungen, etwa Auftragsabwicklung oder Reklamation.
• IT-Betriebsdokumentation mit Systemen, Zugängen, Notfallabläufen.
• Wissensbasis für Support und Vertrieb mit häufigen Fragen und Lösungen.
• Einarbeitung neuer Mitarbeitender.

Nicht jede Art gehört in dasselbe Wiki, und nicht jede gehört überhaupt in ein Wiki. Die Abgrenzung zum Intranet, zum Dokumentenmanagement und zum Ticketsystem wird hier festgelegt.

Die Bestandsaufnahme beantwortet vier Fragen: Wo liegt das Wissen heute (Dateiablage, SharePoint, Confluence, Altwiki, Ticketsystem, E-Mail-Postfächer)? Welche Inhalte sind noch gültig? Welche Bereiche sind vertraulich? Welcher Verzeichnisdienst ist vorhanden, etwa Active Directory, Entra ID oder Keycloak? Ergebnis ist ein Bestandsbild mit Quellen, Rechtebereichen und den Personen, die heute faktisch Inhalte pflegen.

Schritt 2: Struktur und Rollen festlegen

Die Struktur entscheidet, ob Inhalte gefunden werden. Bewährt haben sich wenige oberste Bereiche, die sich an Zielgruppen oder Organisationseinheiten orientieren, darunter eine begrenzte Tiefe. Dazu kommen Namenskonventionen für Seiten, Vorlagen für wiederkehrende Seitentypen (Prozessbeschreibung, Anleitung, Entscheidungsprotokoll, Betriebshandbuch) und eine Archivregel für Inhalte, die nicht mehr gelten.

Die Rollen legen fest, wer was darf und wer wofür zuständig ist:

Aus Rollen und Bereichen entsteht die Rechtematrix: welche Gruppe aus dem Verzeichnis in welchem Bereich lesen, schreiben oder verwalten darf. Rechte werden auf Bereichsebene vergeben, nicht für einzelne Seiten. Einzelrechte auf Seitenebene sind die Ausnahme für wirklich vertrauliche Inhalte, weil sie sich schlecht überblicken lassen.

Schritt 3: Das Werkzeug nach Lizenz und Betrieb wählen

Erst wenn Struktur und Rechte feststehen, lässt sich das Werkzeug sinnvoll wählen. Für ein Unternehmen, das Inhalte im eigenen Betrieb halten will, kommen vor allem vier Open-Source-Wikis in Frage. Der wichtigste Unterschied liegt nicht in den Funktionen, sondern darin, was die freie Edition bei Anmeldung und Rechten leistet:

Quellen: BookStack, BookStack, Roles and Permissions, XWiki Pricing, xwiki-contrib/ldap, xwiki-contrib/oidc, Docmost Pricing, Wiki.js Module, BookStack Releases, Docmost Releases, Wiki.js 3.0.0-beta.617. Stand Oktober 2026.

Daraus ergibt sich eine erste Einordnung:

• BookStack passt zu Handbüchern, Prozess- und IT-Dokumentation, bei denen die feste Ordnung aus Regal, Buch, Kapitel und Seite hilft und keine eigene Wiki-Administration vorgesehen ist.
• XWiki passt, wenn viele Bereiche mit fein abgestuften Rechten bestehen, strukturierte Daten oder Formulare gebraucht werden oder Confluence abgelöst wird.
• Docmost passt zu Teams, die gleichzeitig an Seiten schreiben. Mit Firmen-Login und Seitenrechten ist die Business-Stufe Pflicht, für 50 Nutzer sind das 3.600 US-Dollar Lizenz im Jahr.
• Wiki.js passt zu technischer Dokumentation in Markdown. Die stabile Linie ist 2.x, die Version 3.0 ist noch Beta.

Outline taucht in vielen Listen auf, steht aber unter der Business Source License 1.1. Ihr Zusatzrecht schließt den Betrieb als Dienst für Dritte aus, erst am 09.09.2030 wechselt der Code auf Apache 2.0 (GitHub, Outline LICENSE). Outline kommt deshalb nur in Frage, wenn die eigene IT es selbst betreibt.

Die Auswahl sollte nicht an Funktionslisten enden. Die späteren Bereichsverantwortlichen probieren die Kandidaten mit eigenen Beispielinhalten aus: Wie legen sie eine Prozessbeschreibung an, wie finden sie eine Anleitung, wie vergeben sie Rechte im eigenen Bereich? Wie Docmost Community und Business sich im Detail unterscheiden, zeigt der Beitrag Docmost Community vs. Enterprise Edition.

Schritt 4: Rechte aus dem Verzeichnisdienst übernehmen

Ein Wiki mit eigenen Konten und eigenem Passwort ist eine Hürde mehr. Die Anmeldung läuft deshalb über den vorhandenen Verzeichnisdienst, per Single Sign-on mit OIDC oder SAML oder per LDAP. Das hat drei Folgen:

• Kein zusätzliches Passwort. Mitarbeitende melden sich mit dem Firmen-Login an. Bei Single Sign-on gilt die Mehrfaktor-Anmeldung des Identitätsanbieters auch für das Wiki.
• Rechte folgen den Gruppen. Die Rechtematrix aus Schritt 2 wird auf Gruppen im Verzeichnis abgebildet. BookStack kann Rollen über LDAP- oder SAML2-Gruppen automatisch zuweisen (BookStack, Roles and Permissions).
• Austritte sind geregelt. Wird ein Konto im Verzeichnis deaktiviert, ist auch die Anmeldung am Wiki nicht mehr möglich.

Hier wirkt die Lizenzfrage aus Schritt 3: Bei Docmost gehören SSO, LDAP und MFA zur Business-Stufe (Docmost Pricing). Bei BookStack, XWiki und Wiki.js sind sie ohne Zusatzlizenz enthalten.

Schritt 5: Pilot mit einem echten Bereich

Der Pilot prüft Struktur, Werkzeug und Anmeldung mit echten Inhalten, bevor alle Bereiche umziehen. Gut geeignet ist ein Bereich mit spürbarem Bedarf, etwa IT-Anleitungen, Einarbeitung oder die Prozesse einer Abteilung.

Zum Pilot gehören:

• eine produktionsnahe Instanz mit Single Sign-on und den Gruppen aus dem Verzeichnis,
• der Pilotbereich nach Strukturplan mit Vorlagen,
• vorhandene, gültige Inhalte, übernommen aus Dateiablage oder Altsystem,
• eine Pilotgruppe aus Autoren und Lesern, die Rückmeldung gibt.

Ein neues Wiki füllt sich am schnellsten, wenn nicht neu geschrieben, sondern vorhandenes Material übernommen und mit Vorlagen in Form gebracht wird. Zuerst kommen die Inhalte, nach denen am häufigsten gefragt wird. Veraltete Dokumente werden archiviert, nicht migriert.

Am Ende steht ein Abnahmeprotokoll: Finden die Pilotnutzer, was sie suchen? Wo passt die Struktur nicht? Welche Vorlagen fehlen? Erst danach folgen die weiteren Bereiche, Bereich für Bereich.

Schritt 6: Redaktionsprozess, damit das Wiki aktuell bleibt

Der Redaktionsprozess ist der Schritt, der über die Nutzung nach drei Monaten entscheidet. Er besteht aus wenigen, verbindlichen Regeln:

Einige Systeme bringen dafür Funktionen mit, bei Docmost etwa einen Prüfworkflow für Seiten in der Enterprise-Stufe (Docmost Pricing). Ein Feld in der Vorlage und ein regelmäßiger Blick auf überfällige Seiten erfüllen denselben Zweck. Der Redaktionsleitfaden selbst steht als Seite im Wiki.

Schulung nach Rollen statt Einweisung für alle

Eine allgemeine Einweisung für alle reicht nicht, weil die Rollen Unterschiedliches brauchen:

• Autoren: Vorlagen nutzen, sauber gliedern, verlinken statt kopieren, Anhänge ablegen, Suche gezielt einsetzen.
• Bereichsverantwortliche: Rechte im eigenen Bereich, Prüfintervalle, Archivieren.
• Administratoren: Gruppen und Anmeldung, Erweiterungen, Updates, Sicherung, Export.

Für Leser genügt meist eine kurze Anleitung im Wiki selbst. Kurzanleitungen zu jeder Rolle stehen ebenfalls als Seiten im Wiki, damit sie gefunden werden, wenn sie gebraucht werden.

Betrieb: Updates, Sicherung und Wiederherstellung

Ein Wiki wird nach der Einführung zum System, auf das sich Abteilungen verlassen. Der Betrieb umfasst:

Betrieben wird das Wiki auf der eigenen Infrastruktur oder bei einem Betreiber in Deutschland, etwa über Managed Open Source. Entscheidend ist, dass die Zuständigkeit vor dem Start geregelt ist und nicht beim Pilotteam hängen bleibt.

KI-Suche als Ausbau, nicht als Start

Eine KI-Suche beantwortet Fragen an den Wissensbestand in Sätzen und nennt die Quellseiten. Sie gibt aber wieder, was im Wiki steht, einschließlich veralteter Inhalte, und muss die Rechte des Wikis beachten: Wer eine Seite nicht lesen darf, darf auch keine Antwort daraus erhalten.

Deshalb kommt die KI-Suche nach der Einführung, wenn der Bestand gepflegt ist und die Rechte über Gruppen gesetzt sind. Wege dahin sind die LLM Application von XWiki (XWiki mit KI einrichten), die KI-Funktionen von Docmost ab Business oder eine eigene Suchschicht über mehrere Quellen, wie sie der Beitrag Atlassian Rovo Alternative self-hosted beschreibt. Ob die Antworten mit den eigenen Inhalten tragen, prüft ein abgegrenzter Test wie der RAG Proof of Value.

Verbreitete Irrtümer bei der Wiki-Einführung

Unser Vorgehen bei WZ-IT

WZ-IT begleitet die Einführung von der Entscheidung bis zum Betrieb. Jeder Schritt hat ein festes Ergebnis.

1. Orientierung, wenn das Thema noch offen ist. Steht noch nicht fest, ob ein Wiki der richtige nächste Schritt ist, ordnet der Orientierungsworkshop die Themen. Er findet remote und halbtägig statt und kostet ab 1.490 € netto.
2. Wiki-Auswahl mit festem Umfang. Die Wiki-Auswahl kostet ab 3.900 € netto. Sie umfasst die Bestandsaufnahme Ihrer Inhalte, Rechte und Identitäten, gewichtete Kriterien mit Fachbereichen und IT und die Prüfung der Lizenz- und Betriebsgrenzen. Für die Dauer der Auswahl stellen wir Demo-Instanzen von BookStack, XWiki, Docmost und Wiki.js mit Beispielinhalten bereit, die Sie selbst ausprobieren, ohne sich vorher festzulegen. Outline bewerten wir in der Matrix, hosten es aber nicht als Demo, weil die Lizenz den Betrieb als Dienst ausschließt. Ergebnis ist eine Entscheidungsvorlage mit Empfehlung, Lizenzkosten aus Herstellerangaben und Betriebsmodell. Wenn ein anderes Werkzeug besser passt, steht das in der Vorlage. Der Betrag wird auf die Einführung angerechnet, wenn Sie diese innerhalb von 6 Monaten zum selben Thema beauftragen.
3. Einführung. Das Angebot dafür erhalten Sie mit der Entscheidungsvorlage. Es umfasst Struktur- und Rollenkonzept mit Rechtematrix, Anmeldung über Ihren Verzeichnisdienst, den Pilot, die Übernahme vorhandener Inhalte, den Redaktionsleitfaden und die Schulung nach Rollen. Lizenzen wie Docmost Business erwerben Sie direkt beim Hersteller.
4. Betrieb in Deutschland. Das Wiki betreiben wir über Managed Open Source in deutschen Rechenzentren, ab 129,90 € netto je Workload und Monat, mit Updates, Sicherung und Überwachung. Alternativ läuft es auf Ihrer eigenen Infrastruktur.
5. Ausbau um KI-Suche. Ist der Bestand gepflegt, prüft der RAG Proof of Value ab 9.900 € netto, wie gut Antworten aus Ihren Inhalten tragen. Den dauerhaften Aufbau beschreibt die Seite zum internen KI-Assistenten.

Weiterführende Guides

• BookStack, Wiki.js, XWiki oder Docmost, welches Wiki zu welcher Organisation passt.
• Confluence Data Center End of Life 2029, Fristen und Migrationswege zu Open-Source-Wikis.
• Docmost Community vs. Enterprise Edition, welche Funktionen hinter der Lizenzgrenze liegen.
• Atlassian Rovo Alternative self-hosted, KI-Suche über das eigene Wiki.
• XWiki mit KI einrichten, die LLM Application mit lokalem Modell.
• Wissensmanagement: Wiki-Auswahl und Einführung, das Paket von WZ-IT.
• Beratung bei WZ-IT, alle Einstiege vom Erstgespräch bis zur Auswahl.

Ein Wiki, das nach drei Monaten noch genutzt wird. Wir klären mit Ihnen Ziel, Struktur und Rechte, lassen Sie die passenden Wikis mit Beispielinhalten selbst ausprobieren und begleiten Pilot, Redaktionsprozess und Betrieb. Kostenloses Erstgespräch vereinbaren

Quellen

• BookStack, Startseite mit Funktionen und Lizenz
• BookStack, Roles and Permissions
• GitHub, BookStack
• GitHub, BookStack Releases
• XWiki Pricing
• GitHub, xwiki-platform
• GitHub, xwiki-contrib/ldap
• GitHub, xwiki-contrib/oidc
• Docmost Pricing
• GitHub, docmost
• GitHub, Docmost Releases
• GitHub, requarks/wiki
• GitHub, Wiki.js Anmeldemodule v2.5.315
• GitHub, Wiki.js 3.0.0-beta.617
• GitHub, Outline LICENSE
• Atlassian, Data Center End of Life