Der Satz fällt meist am Ende eines Gesprächs, in dem etwas gerade funktioniert hat. Das System läuft. Die Schnittstelle antwortet. Der Dienstleister kennt den Weg. Dokumentation wäre jetzt möglich — und genau deshalb wird sie verschoben. Später, wenn Ruhe ist. Später, wenn das nächste Release draußen ist. Später, wenn jemand Zeit hat, der den Überblick hat.
Ruhe kommt nicht. Das nächste Release verschiebt das Fenster. Und die Person mit dem Überblick ist dieselbe, deren Ausfall den Überblick erst teuer macht. „Wir dokumentieren später“ ist deshalb keine Zeitplanung. Es ist eine Risikoentscheidung, die so klingt, als wäre sie keine.
Was später konkret heißt
Dokumentation, die fehlt, fällt im Alltag nicht auf. Der Betrieb läuft über Personen, nicht über Artefakte: über den Entwickler, der die nächtliche Strecke im Kopf hat, über die Administratorin, die weiß, welche Reihenfolge der Neustart hat, über den Dienstleister, dessen Ticketwarteschlange die eigentliche Wissensbasis ist. Solange diese Personen erreichbar sind, sieht das System gesund aus.
Der Schaden entsteht, wenn genau diese Erreichbarkeit wegfällt. Dann ist die fehlende Dokumentation kein Qualitätsmangel mehr, sondern die Zeit, die vergeht, bis jemand den Ist-Zustand rekonstruiert hat. In dieser Zeit steht nicht „die Doku“, sondern der Geschäftsprozess, der an dem System hängt.
Das Bundesamt für Sicherheit in der Informationstechnik benennt das im Baustein OPS.1.1.2 „Ordnungsgemäße IT-Administration“ als eigene Gefährdung: Unzureichende Dokumentation — unvollständig oder nicht mehr dem Ist-Zustand entsprechend — führt zu Fehlkonfigurationen und beeinträchtigt das Notfallmanagement, weil für zeitkritische Aufgaben erst Informationen gesammelt werden müssen. Die Verfügbarkeit dauert dann länger als geplant. Das ist keine Stilfrage. Es ist die Differenz zwischen einem geplanten Wiederanlauf und einem Suchauftrag unter Zeitdruck.
Der Bus-Faktor ist eine Betriebsgröße
In der Softwaretechnik heißt die zugehörige Größe Bus-Faktor oder Truck Factor: die kleinste Zahl von Personen, deren Ausfall ein Vorhaben handlungsunfähig macht. Avelino, Passos, Hora und Valente haben 2016 für 133 verbreitete GitHub-Projekte automatisiert geschätzt, wie viele Entwicklerinnen und Entwickler ein System tragen. In 65 Prozent der untersuchten Systeme lag der Truck Factor bei höchstens zwei. Die Mehrheit der populären Codebasen wäre also nach dem Weggang einer oder zweier Personen nicht mehr tragfähig.
Für ein internes System in einem mittelständischen Betrieb gilt das häufiger, nicht seltener. Dort gibt es oft keine zweite Person, die denselben Ausschnitt kennt. Der Bus-Faktor ist eins — und dieser eine Kopf sitzt nicht selten außerhalb der Firma, beim Dienstleister, der das System gebaut hat und seither betreibt.
Die Metrik misst keine Schreibqualität. Sie misst Konzentration. Ein Wiki mit hundert Seiten senkt den Bus-Faktor nicht, wenn der Wiederanlauf trotzdem nur einer Person gelingt. Umgekehrt senkt ein ausführbares Skript mit benanntem Ort und benannter Berechtigung den Faktor, auch wenn niemand eine Betriebsfibel geschrieben hat. Entscheidend ist, ob das Wissen das System verlassen kann, ohne dass das System stehen bleibt.
Drei Ausfälle, die denselben Befund haben
Die typischen Auslöser unterscheiden sich. Der Zustand, den sie offenlegen, ist derselbe.
Krankheit und Urlaub. Zwei Wochen Abwesenheit sind der häufigste Ernstfall und der am wenigsten geplante. Es braucht keinen Unfall und keine Kündigung. Es reicht, dass die Person, die den nächtlichen Abgleich kennt, nicht ans Telefon geht, während die Gegenstelle eine andere Datei liefert als gestern. Was intern als Personalfrage behandelt wird, ist in dem Moment ein Betriebszustand: Das System hat keine zweite Bedienung.
Dienstleisterwechsel. Hier wird aus dem stillen Risiko ein sichtbares. Der alte Auftragnehmer gibt Konten ab, der neue übernimmt „die Landschaft“, und beide Seiten stellen fest, dass die Landschaft in keinem der übergebenen Dokumente vollständig vorkommt. Schnittstellen, die in keiner Liste stehen. Cronjobs auf einem Rechner, der offiziell abgelöst ist. Ein produktives Geheimnis in der lokalen Passwortdatei einer einzelnen Arbeitsstation. Der Wechsel kostet dann nicht den vereinbarten Übergabeaufwand, sondern die Rekonstruktion. Wer den alten Dienstleister nicht mehr fragen kann oder nicht mehr fragen will, zahlt die fehlende Dokumentation als Einarbeitung — oft über Monate, oft unter laufendem Betrieb.
Nachfolge intern. Jemand geht, jemand kommt. Der Nachfolger erbt Zugänge und eine mündliche Einweisung. Was nicht aufgeschrieben ist, wird in den ersten Wochen als „wird sich zeigen“ akzeptiert und nach einem Jahr als Architektur behandelt: so macht man das hier. Die Entscheidung, die einmal bewusst offen gelassen wurde, ist dann unsichtbar geworden. Ein späterer Audit findet sie als Gewohnheit, nicht als Lücke.
In allen drei Fällen ist der Satz „wir dokumentieren später“ bereits vollzogen. Später war der Zeitpunkt, an dem die tragende Person noch da war. Dieser Zeitpunkt kehrt nicht wieder.
Was fehlt, wenn nur Köpfe wissen
Betriebswissen, das nur in einem Kopf liegt, hat eine Form, die sich im Alltag als Kompetenz tarnt. Die Person ist schnell. Sie braucht keine Anleitung. Sie kennt die Ausnahmen. Genau das macht sie unersetzlich — und das System abhängig.
Typisch sind nicht fehlende Hochglanzhandbücher, sondern fehlende Antworten auf wenige Fragen:
- Wer darf eine Änderung in Produktion bringen, und von welchem Ort aus?
- Welche Systeme müssen in welcher Reihenfolge wieder hochfahren?
- Welche Schnittstelle darf bei einem Fehler wiederholt werden, welche nicht?
- Wo liegen die Zugänge, und wer außer der tragenden Person kann sie nutzen?
- Welche Entscheidung wurde bewusst so getroffen, und welche Alternative wurde verworfen?
Ohne diese Antworten ist ein System nicht „undokumentiert“. Es ist nicht übergebbar. Der Unterschied ist praktisch: Eine unvollständige Beschreibung lässt sich ergänzen. Ein System, das nur eine Person bedienen kann, muss im Ernstfall erst verstanden werden. Das dauert länger als jeder geplante Wiederanlauf.
Deshalb behandelt das System-Audit unter der Dimension Betrieb ausdrücklich die Frage, wie viel Betriebswissen in genau einem Kopf liegt. Fehlende Dokumentation ist dort kein Hindernis für die Prüfung, sondern einer ihrer Befunde. Wer vorher aufräumt, bekommt einen Bericht über den aufgeräumten Zustand — nicht über den, in dem das System tatsächlich betrieben wird.
Abhängigkeit ist der eigentliche Preis
Der Fahrplan-Gedanke dahinter ist alt und selten ausgesprochen: Der Bus-Faktor ist die Frage, die jeder Käufer bei einer kleinen Beratung hat und fast niemand stellt. Dieselbe Frage gilt in der anderen Richtung. Wer ein System an einen einzelnen Dienstleister, eine einzelne Administratorin oder einen einzelnen Entwickler bindet, hat kein Personalproblem. Er hat ein Übergaberisiko.
Die Bindung entsteht nicht durch Verträge. Sie entsteht, weil das Wissen nicht im Kundenkonto liegt. Repositories, Cloud-Konten, Domains und Zertifikate auf dem Namen des Auftragnehmers. Ein Betriebswissen, das nur in dessen Ticketsystem existiert. Architekturentscheidungen, die nie als Entscheidung festgehalten wurden, sondern als Chatverlauf. Endet die Zusammenarbeit, gibt es nichts zu übergeben, das ein Dritter ohne Nachfrage weiterführen könnte.
Genau das ist der Maßstab, an dem Dokumentation sich messen lässt — nicht Lesbarkeit, nicht Vollständigkeit im schulischen Sinn, nicht die Zahl der Seiten. Die Frage lautet: Kann ein fremdes Team damit weiterarbeiten, ohne die Person zu fragen, die es gebaut hat? Wenn die Antwort nein ist, gehört das System der Person, nicht der Organisation.
Diese Abhängigkeit trifft kleine Beratungen und große Systemhäuser gleich. Sie trifft auch die eigene IT, wenn eine Person seit Jahren „das Portal“ macht. Der Ausfall verschiebt dann keinen Termin. Er hinterlässt eine laufende Produktion, die niemand ändern und im Störungsfall niemand wiederherstellen kann.
Was sich prüfen lässt, bevor jemand ausfällt
Der Nachweis, dass Wissen das System verlassen kann, ist keine Dokumentensammlung. Es ist ein Ablauf, den eine zweite Person einmal ausgeführt hat. Solange das nicht geschehen ist, bleibt jede Beschreibung eine Behauptung.
Prüfbar ist das, bevor der Ernstfall eintritt:
- Eine benannte zweite Person. Nicht „das Team“, sondern ein Name. Wer den Wiederanlauf beschreiben oder ausführen soll, wenn die tragende Person zwei Wochen nicht da ist.
- Zugänge, die der Organisation gehören. Was auf einem privaten Konto, einem persönlichen Arbeitsplatz oder im Namensraum des Dienstleisters liegt, ist im Wechsel- oder Krankheitsfall nicht da.
- Entscheidungen mit Begründung. Nicht das Diagramm des Wunschzustands, sondern die gewählte Variante, die geprüfte Alternative und der Grund. Ein Nachfolger kann eine begründete Entscheidung fortführen oder bewusst revidieren. Eine unbegründete Gewohnheit kann er nur nachahmen.
- Ein Ist-Bild, das dem Betrieb entspricht. Veraltete Dokumentation ist im Ernstfall gefährlicher als keine, weil sie Handlungen nahelegt, die am System vorbeigehen. Das BSI sagt dasselbe: Dokumentation, die im Zuge der Administration nicht mitgeführt wird, entspricht nicht mehr dem Ist-Zustand.
Das ist keine Anleitung, wie man gut schreibt. Es ist die Mindestbedingung dafür, dass ein System die Person überlebt, die es gerade trägt.
Später ist der teuerste Zeitpunkt
Dokumentation, die nach dem Ausfall entsteht, ist Rekonstruktion. Sie kostet Gesprächszeit mit Menschen, die das System nicht gebaut haben, Lesezeit in Systemen, die niemand erklärt hat, und Fehlversuche im laufenden Betrieb. Der Aufwand ist höher als der, den der Satz „später“ einmal vermeiden sollte — und er fällt an, wenn die Organisation am wenigsten Kapazität hat.
Deshalb gehört die Frage nach dem Bus-Faktor in die Bestandsaufnahme, nicht in die Nachsorge. Wo das Betriebswissen liegt, welche Systeme ohne eine bestimmte Person nicht mehr bedienbar sind, welche Zugänge und welche Entscheidungen nur mündlich existieren: Das sind Befunde. Sie lassen sich benennen, bevor jemand krank wird, kündigt oder den Auftrag verliert.
Ein System-Audit macht genau das sichtbar und übergibt die Ergebnisse so, dass ein beliebiges anderes Team danach arbeiten kann — in bearbeitbaren Formaten, ohne Nutzungseinschränkung, ohne dass die Umsetzung an den Prüfer gebunden ist. Wo danach laufend Entscheidungen anfallen und niemand im Haus sie gegenzeichnet, ist die technische Begleitung der Ort, an dem die Landschaft im Blick bleibt, bevor aus einer Randnotiz in achtzehn Monaten ein Ausfall wird.
Wissen, das nur in einem Kopf existiert, ist ein Systemzustand. Es wird nicht durch Einarbeitung behoben, sondern dadurch, dass der Ablauf ohne diesen Kopf ausführbar ist.
„Wir dokumentieren später“ verschiebt diesen Zustand nicht. Es verlängert ihn, bis er nicht mehr verhandelbar ist.
Quellen
- BSI, IT-Grundschutz-Kompendium, Baustein OPS.1.1.2 „Ordnungsgemäße IT-Administration“, Edition 2023 — Gefährdung „Unzureichende Dokumentation“ und Anforderung OPS.1.1.2.A11
- Guilherme Avelino, Leonardo Passos, Andre Hora, Marco Tulio Valente: „A Novel Approach for Estimating Truck Factors“, 24th IEEE International Conference on Program Comprehension (ICPC), 2016