Warum interne Dokumentation veraltet, obwohl sie einmal richtig war

Interne Dokumentation kann fachlich korrekt geschrieben, sauber freigegeben und trotzdem Monate später falsch sein. Nicht weil jemand schlecht dokumentiert hat. Sondern weil sich die Realität weiterbewegt, während das Dokument stehen bleibt.

Das Problem ist unangenehm, weil veraltete Dokumentation selten spektakulär scheitert. Ein System wirft keinen Fehler, nur weil eine Arbeitsanweisung noch einen alten Prozess beschreibt. Eine Wissensdatenbank meldet nicht automatisch, dass ein Ansprechpartner gewechselt hat. Ein How-to kann plausibel aussehen und gerade deshalb lange benutzt werden.

Die entscheidende Frage lautet deshalb nicht nur: Wie dokumentieren wir Wissen? Sondern: Wie merken wir zuverlässig, dass dokumentiertes Wissen überprüft werden muss?

Dokumentation veraltet oft ohne sichtbares Warnsignal

Für Softwaredokumentation ist dieser Effekt gut untersucht. Wen Siang Tan, Markus Wagner und Christoph Treude analysierten mehr als 3.000 GitHub-Projekte und suchten nach Referenzen auf Code-Elemente, die im Quellcode inzwischen verschwunden waren. Ihr Kernproblem: Quellcode verändert sich, die dazugehörige Dokumentation bekommt davon nicht automatisch etwas mit.

Die Autoren beschreiben diesen Verfall ausdrücklich als stillen Prozess. Ein Programm kann nach einer Änderung nicht mehr funktionieren. Ein veralteter Absatz in einer Wiki-Seite bleibt dagegen einfach stehen. In den untersuchten Projekten überlebten manche veralteten Referenzen über Jahre, bevor sie korrigiert wurden.

Das lässt sich nicht eins zu eins von Open-Source-Projekten auf jede interne Wissensdatenbank übertragen. Der Mechanismus ist trotzdem relevant: Wenn Dokumentation und die Realität, die sie beschreibt, getrennt verändert werden, entsteht eine Synchronisationsaufgabe. Ohne Auslöser oder Verantwortlichkeit ist nicht garantiert, dass beide wieder zusammenfinden.

Das eigentliche Problem ist die Kopplung an Veränderung

Deshalb greift die übliche Empfehlung „Dokumentation regelmäßig aktualisieren“ zu kurz. Regelmäßig ist noch kein Mechanismus.

Ein Prozess kann sich morgen ändern oder drei Jahre stabil bleiben. Ein Ansprechpartner kann heute wechseln. Eine technische Anleitung kann nach einem Release sofort falsch sein. Eine Grundsatzbeschreibung kann dagegen lange gültig bleiben.

Dokumente altern also nicht nach derselben Uhr. Entscheidend ist, welche Ereignisse ihre Aussage verändern können.

Das führt zu einer praktischeren Sicht: Für kritische Inhalte sollte nicht nur festgelegt sein, wer sie besitzt, sondern auch, welche Veränderungen einen Review auslösen. Bei einer Prozessbeschreibung kann das eine Prozessänderung sein. Bei einer Systemanleitung ein Release. Bei einer Zuständigkeit ein Rollenwechsel. Bei einer Richtlinie eine neue Freigabe oder Vorgabe.

Ein fester Prüftermin kann trotzdem sinnvoll sein. Er ist eher ein Sicherheitsnetz als die eigentliche Verbindung zwischen Veränderung und Dokumentation.

Ein Tool löst die Pflegefrage nicht allein

Auch die Forschung zu Wissensmanagement spricht gegen eine rein technische Erklärung. Kalle Koivisto und Toni Taipalus untersuchten in einer internationalen IT-Organisation mit 50 Beschäftigten, was wirksames Wissensmanagement behindert. Die Hürden lagen nicht nur in Werkzeugen. Sie verteilten sich auf persönliche, soziale, organisationale, technische und umgebungsbezogene Faktoren.

Das ist für interne Dokumentation wichtig. Eine perfekte Suchfunktion hilft wenig, wenn unklar ist, wer Inhalte pflegt. Ein Review-Workflow hilft wenig, wenn niemand Zeit oder Kontext für die Prüfung hat. Und eine Versionshistorie sagt, was geändert wurde, aber nicht automatisch, ob der aktuelle Stand fachlich richtig ist.

Die Wartbarkeit einer Wissensbasis ist deshalb eine Organisationsfrage mit technischem Anteil, nicht umgekehrt.

Wer nur die zweite Seite mit einem neuen Tool lösen will, übersieht die erste. Ein System kann einen Review organisieren. Es kann aber nicht automatisch jede fachliche Veränderung kennen, wenn die Organisation diese Verbindung nicht herstellt.

Veraltet heißt nicht automatisch wertlos

Es gibt eine wichtige Gegenposition. Ältere Dokumentation ist nicht zwangsläufig nutzlos.

Eine klassische Feldstudie von Timothy Lethbridge, Janice Singer und Andrew Forward untersuchte, wie Softwareentwickler Dokumentation tatsächlich verwenden und aktualisieren. Die Forscher fanden zwar, dass Dokumentation häufig nicht so zeitnah und vollständig gepflegt wird, wie Prozesse und Management es vorsehen. Gleichzeitig blieb veraltete Dokumentation in vielen Situationen nützlich.

Das ist plausibel. Ein altes Architekturdiagramm kann die Grundidee eines Systems noch korrekt erklären, obwohl einzelne Komponenten inzwischen anders heißen. Eine ältere Prozessbeschreibung kann den historischen Entscheidungsweg zeigen. Und ein Dokument kann in einem Teil veraltet, in einem anderen weiterhin belastbar sein.

Für Wissensmanagement folgt daraus etwas anderes als „alte Inhalte löschen“: Gültigkeit sollte sichtbar und differenziert behandelt werden. Was ist aktuell freigegeben? Was ist nur noch historischer Kontext? Was wurde ersetzt? Wo ist die Aussage unsicher?

Versionierung hilft dabei, Änderungen nachvollziehbar zu machen. Sie ersetzt aber nicht die fachliche Entscheidung, welche Version noch gilt.

Reviews nach Kalender reichen nicht immer

Viele Organisationen reagieren auf das Problem mit einem pauschalen Rhythmus: jedes Dokument alle sechs oder zwölf Monate prüfen.

Das ist besser als gar kein Review. Trotzdem bleiben zwei Schwächen.

Erstens kann ein kritisches Dokument kurz nach dem letzten Review falsch werden. Dann wartet der Fehler bis zum nächsten Termin. Zweitens bindet ein starrer Rhythmus Zeit für Inhalte, die sich kaum verändern und vielleicht selten genutzt werden.

Ein alternatives Prinzip kommt aus Knowledge-Centered Service, kurz KCS. Dort wird Wissen möglichst im Nutzungskontext gepflegt. Das aktuelle KCS-Practices-Modell nennt den Gedanken „Reuse is Review“: Wenn Menschen einen Wissensartikel tatsächlich verwenden und dabei einen Fehler oder eine Lücke bemerken, soll die Korrektur direkt ermöglicht oder zumindest sauber zurückgespielt werden.

KCS ist ein konkretes Service-Management-Modell und kein universeller Beweis für alle Wissenssysteme. Der Gedanke ist trotzdem nützlich: Nutzung ist ein zusätzliches Qualitätssignal. Häufig verwendete Inhalte erzeugen reale Prüfsituationen, die ein Kalender allein nicht kennt.

Die drei Mechanismen ersetzen sich nicht. Sie decken unterschiedliche Blindstellen ab.

Ownership muss mehr bedeuten als ein Name im Feld

Ein Owner-Feld ist schnell angelegt. Damit ist noch nicht geklärt, was Ownership praktisch bedeutet.

Ein sinnvoller Verantwortlicher muss erkennen können, ob der Inhalt noch stimmt. Er braucht also entweder selbst den fachlichen Kontext oder einen klaren Weg zu den Personen, die ihn haben. Außerdem muss entschieden sein, welche Änderungen er aktiv mitbekommt.

Gerade hier liegt die Trennung zwischen System und Organisation. Das Wissenssystem kann Aufgaben, Fristen, Versionen und Freigaben verwalten. Es kann aber nicht von selbst wissen, dass eine Prozessänderung in Projekt A einen Wissensartikel aus Bereich B fachlich ungültig gemacht hat, wenn diese Beziehung nirgends abgebildet oder organisatorisch gelebt wird.

Deshalb sollte bei kritischer Dokumentation neben dem Inhalt mindestens klar sein:

• Wer entscheidet über fachliche Gültigkeit?
• Welche Ereignisse können den Inhalt verändern?
• Wie erreicht Nutzerfeedback den Verantwortlichen?
• Was passiert, wenn ein Review überfällig ist?
• Wie wird eine alte Version als ersetzt oder historisch kenntlich gemacht?

Das ist weniger spektakulär als eine neue KI-Suche. Für die Verlässlichkeit einer Wissensbasis ist es oft wichtiger.

KI macht Aktualität nicht überflüssig

Generative Suche verschärft die Frage sogar.

Wenn ein Mitarbeiter eine veraltete Datei manuell öffnet, sieht er zumindest das Dokument, das er benutzt. Ein KI-System kann Informationen aus mehreren Quellen zu einer flüssigen Antwort zusammenführen. Das verbessert den Zugriff, löst aber nicht automatisch die Gültigkeit der Quellen.

Deshalb sind Suche und Wissenspflege zwei verschiedene Aufgaben. Retrieval kann helfen, die passende Information zu finden. Aktualität braucht zusätzlich Ownership, Gültigkeit und einen Wartungsprozess.

Das ist auch die Grenze zu unserem Praxiswissen über KI und Wissensgovernance: Dort geht es darum, welches Wissensfundament eine Unternehmens-KI braucht. Hier geht es eine Ebene tiefer um den Lebenszyklus der Dokumente selbst.

Gute Dokumentation ist kein fertiges Artefakt

Dokumentation wird oft wie ein Projekt behandelt: Wissen erfassen, strukturieren, freigeben, fertig.

Für stabile historische Informationen kann das reichen. Für operative Dokumentation ist es die falsche Vorstellung.

Je enger ein Inhalt an veränderliche Prozesse, Systeme, Rollen oder Regeln gekoppelt ist, desto mehr braucht er einen Lebenszyklus. Schreiben und Freigeben sind nur der Anfang. Danach muss die Organisation erkennen können, wann die Realität den Text überholt hat.

Der robuste Ansatz kombiniert deshalb drei Dinge: Veränderungen lösen gezielte Reviews aus, Nutzung erzeugt Feedback, und zeitbasierte Prüfungen dienen als Sicherheitsnetz. Dazu kommt eine fachliche Ownership, die entscheiden kann, was noch gilt.

So wird aus einer Dokumentensammlung eine gepflegte Wissensbasis. Nicht weil nichts mehr veraltet, sondern weil Veralten nicht mehr unbemerkt bleiben muss.