Wir haben Confluence. Warum weiß trotzdem niemand, was dort steht?

Es gibt eine Aussage, die in fast jedem Erstgespräch über Wissensmanagement auftaucht. Manchmal ist es Confluence. Manchmal SharePoint. Manchmal Notion. Der Satz lautet immer gleich:

„Wir haben das eigentlich. Aber keiner schaut dort rein.”

Das ist kein Tool-Problem. Das ist ein Systemproblem. Und es ist lösbar — aber nicht mit einem besseren Tool.

Warum gut gemeinte Systeme zu Dokumenten-Friedhöfen werden

Der Aufbau einer Wissensbasis folgt fast immer demselben Muster. Es gibt einen Auslöser: eine Einarbeitungsphase, die zu lange dauert. Eine Schlüsselperson, die kündigt. Ein Projekt, bei dem das Wissen aus dem letzten ähnlichen Projekt unauffindbar ist.

Also wird ein Tool eingeführt. Seiten werden angelegt. Prozesse werden dokumentiert. Für ein paar Wochen schaut es gut aus.

Dann kommt der Alltag zurück. Neue Informationen entstehen — aber sie landen in E-Mails, in Chat-Nachrichten, im Kopf. Das neue Tool wird bei dringenden Aufgaben nicht geöffnet. Die Seiten veralten still.

Sechs Monate später ist das Tool vorhanden. Aber es enthält das, was vor sechs Monaten stimmte — nicht das, was heute gilt.

Das Ergebnis ist in gewisser Hinsicht schlimmer als kein Tool: Es gibt eine Wissensbasis, die den Anschein von Ordnung erweckt. Und Antworten liefert — die falsch sind.

Das eigentliche Problem: Fehlende Ownership

Die meisten Wissensbasen scheitern nicht an der Technologie. Sie scheitern an einer einzigen fehlenden Antwort:

Wer ist dafür verantwortlich, dass diese Information aktuell bleibt?

Solange diese Frage für jeden Eintrag in der Wissensbasis unbeantwortet ist, wird die Basis mit der Zeit zur Fiktion. Nicht weil niemand will. Sondern weil niemand zuständig ist.

In der Praxis bedeutet das: Wenn sich ein Prozess ändert, ändert die zuständige Person den Prozess. Vielleicht schreibt sie eine kurze Nachricht im Team-Chat. Die Seite im Wiki bleibt unberührt, weil das Aktualisieren des Wikis keine definierte Aufgabe ist — es ist „eigentlich selbstverständlich”, also de facto niemandes Verantwortung.

Das Ownership-Prinzip

Das Ownership-Prinzip ist einfach: Jede Information in der Wissensbasis hat eine namentlich benannte Eigentümerin oder einen Eigentümer. Diese Person ist dafür verantwortlich, dass die Information aktuell ist — nicht dafür, sie täglich zu überprüfen, sondern dafür, sie zu aktualisieren, wenn sich etwas ändert.

Das ist ein organisatorischer Entscheid, kein technischer. Kein Tool löst dieses Problem. Notion nicht. Confluence nicht. SharePoint nicht. Das Ownership muss explizit definiert und kommuniziert werden.

In kleinen Teams kann das eine Person für alles sein. In größeren Teams ist eine klare Zuordnung nach Themenbereich oder Prozessverantwortung sinnvoller: Wer den Prozess verantwortet, verantwortet auch seine Dokumentation.

Die drei Regeln, die ein lebendes Wissenssystem von einem toten unterscheiden

Regel 1: Änderungen passieren zweimal.

Einmal im System, einmal in der Dokumentation. Gleichzeitig — nicht danach. Wer eine Prozessänderung umsetzt, aktualisiert in demselben Arbeitsschritt die zugehörige Seite in der Wissensbasis. Nicht als separate Aufgabe. Als fester Bestandteil der Änderung.

Regel 2: Veraltete Informationen sind schlechter als keine.

Eine leere Seite signalisiert: hier gibt es keine Information. Eine veraltete Seite signalisiert: hier gibt es eine Information — und sie ist falsch. Lieber weniger dokumentieren, dafür aktuell, als alles dokumentieren, wovon die Hälfte überholt ist.

Regel 3: Jede Seite hat ein Datum und eine Eigentümerin.

Nicht als technisches Metadatum, das niemand liest. Als sichtbare Information. Wer die Seite geöffnet hat, sieht sofort: Wann wurde das zuletzt überprüft? Wen frage ich, wenn etwas nicht stimmt?

Was das mit KI zu tun hat

Dieser Zusammenhang ist der Grund, warum das Aktualisierungsproblem heute dringlicher ist als vor drei Jahren.

Wenn ein Mensch eine veraltete Seite liest, merkt er oder sie oft, dass etwas nicht stimmt. Der Kontext fehlt, das Datum ist alt, die beschriebene Software existiert nicht mehr. Ein Mensch zweifelt.

Eine KI zweifelt nicht. Sie liest das, was in der Wissensbasis steht, und gibt es mit derselben Zuversicht wieder — egal ob es von gestern oder von vor zwei Jahren ist. Ein RAG-System, das auf veraltete Dokumente zugreift, ist nicht nur nutzlos. Es ist aktiv irreführend.

Wer RAG oder einen internen KI-Assistenten einsetzen will, muss die Frage der Datenpflege zuerst beantworten. Nicht danach. Die Qualität des KI-Outputs ist direkt proportional zur Qualität der Datenbasis. Kein Modell, keine Infrastruktur, kein Prompt kann das kompensieren.

Die Wissensbasis ist nicht die Infrastruktur für KI. Sie ist die Voraussetzung.

Der erste Schritt, wenn das System bereits existiert

Wenn bereits ein Tool vorhanden ist, das niemand nutzt, ist die Lösung nicht das nächste Tool. Die Lösung ist ein Audit des bestehenden Systems.

Nicht technisch. Inhaltlich: Welche Informationen sind aktuell? Diagram as Code kann helfen, technische Dokumentation automatisch synchron zu halten. Welche nicht? Welche Seiten hat in den letzten drei Monaten jemand aufgerufen? Was fehlt?

Dieser Audit dauert je nach Unternehmensgröße einen halben bis einen Tag. Ein strukturierter KI-Audit zeigt auch, wo KI das Wissensmanagement sinnvoll unterstützen kann. Was danach entsteht, ist kein Vollständigkeitsprojekt — sondern eine priorisierte Liste: Welche zehn Seiten müssen jetzt aktuell sein? Wer ist jeweils verantwortlich?

Der Rest kann wachsen.

Nächste Schritte

Wenn Sie Ihr bestehendes Wissenssystem auditieren und wieder funktionsfähig machen wollen — oder von Grund auf ein System aufbauen möchten, das tatsächlich genutzt wird — begleitet Strukturaflow diesen Prozess vom ersten Audit bis zur KI-Integration.