Bildquelle: extern
Ein Ablaufplan beruhigt, solange niemand ihn im Ernstfall benutzen muss. Nach Systemänderungen, neuen Schnittstellen oder einem Providerwechsel kann derselbe Plan aber plötzlich in die Irre führen. Dann verliert der Betrieb Zeit, obwohl die Dokumentation formal vorhanden ist.
Ablaufpläne sind im IT-Betrieb praktische Arbeitsanweisungen. Sie beschreiben, wer bei einer Störung prüft, wen der Service Desk informiert, welche Reihenfolge bei Wiederherstellung oder Eskalation gilt und welche Entscheidung nicht improvisiert werden soll. Für ITSM-Generalisten ist daran nicht das Dokument selbst entscheidend, sondern seine Verlässlichkeit im Moment der Nutzung.
Governance bedeutet hier nicht Papierpflege um der Prüfung willen. Governance sorgt dafür, dass Regeln, Verantwortlichkeiten und Nachweise im Alltag belastbar bleiben. Ein alter Ablaufplan kann gefährlicher sein als gar kein Plan, weil er Sicherheit vorgaukelt. Wer ihm folgt, sucht vielleicht im falschen System, ruft den falschen Dienstleister an oder wartet auf eine Rolle, die es nach einer Organisationsänderung nicht mehr gibt.
Änderungen treffen nicht nur Technik
Eine Änderung im Betrieb betrifft oft mehr als den eigentlichen Server, Dienst oder Cloud-Baustein. Sie verändert Zuständigkeiten, Monitoring, Berechtigungen, Eskalationswege, Wiederanlaufreihenfolgen und manchmal auch die Kommunikation zum Kunden. Wenn diese Folgen nicht in den Ablaufplan zurückfließen, entsteht eine stille Lücke zwischen Realität und Dokument.
Typisch ist der kleine Bruch. Ein Systemname ändert sich. Eine Schnittstelle wandert in eine andere Plattform. Ein Provider übernimmt den Nachtbetrieb. Ein altes Postfach wird durch einen Teams-Kanal ersetzt. Jede einzelne Änderung wirkt beherrschbar. Zusammen sorgen sie dafür, dass ein Plan beim nächsten Ausfall zwar professionell aussieht, aber an mehreren Stellen nicht mehr zur Wirklichkeit passt.
Regelwerke verlangen Pflege, nicht nur Erstellung
NIST beschreibt in seinem Leitfaden zur Notfallplanung für Informationssysteme, dass Pläne regelmäßig gepflegt, getestet und an veränderte Systeme oder Organisationsbedingungen angepasst werden müssen. Der genaue Kontext ist behördlich geprägt, aber die Logik passt in jede IT-Organisation. Ein Plan ist kein einmaliges Ergebnis. Er bleibt nur durch Wartung, Übungen und Rückmeldungen aus Vorfällen belastbar.
Auch der NIST-Leitfaden zur Behandlung von Sicherheitsvorfällen betont Lernen nach dem Vorfall. Nachbesprechungen sollen nicht nur technische Ursachen klären, sondern auch Abläufe, Kommunikation und Reaktionsfähigkeit verbessern. Für den normalen ITSM-Betrieb heißt das: Nach einer Störung darf der Plan nicht unverändert liegen bleiben, wenn die Nutzung gezeigt hat, dass Rückfragen, Zuständigkeiten oder Prüfschritte fehlen.
Ein Besitzer muss für jede kritische Anleitung sichtbar sein
Der wichtigste Schutz gegen veraltete Ablaufpläne ist ein klarer Besitzer. Nicht jede Anleitung braucht ein großes Governance-Gremium. Aber jede kritische Anleitung braucht jemanden, der nach einer Änderung gefragt wird: Betrifft das unseren Plan? Muss ein Schritt angepasst werden? Müssen Kontakte, Rollen, Systeme oder Prüfpunkte erneuert werden?
Ohne Besitzer wird Dokumentation zur Gemeinschaftsannahme. Alle gehen davon aus, dass irgendjemand sie schon pflegt. In der Praxis passiert dann oft nichts. Erst im Ausfall zeigt sich, dass der Link auf ein altes Dashboard führt, die Eskalationsnummer nicht mehr stimmt oder der Wiederherstellungsschritt eine Berechtigung voraussetzt, die der Bereitschaftsdienst nicht mehr hat.
Change-Abschluss ohne Dokumentationsfrage ist unvollständig
Ein Change gilt häufig als erledigt, wenn die technische Umsetzung erfolgreich war und keine Störung sichtbar ist. Für den Betrieb reicht das nicht. Der Abschluss sollte auch fragen, welche Betriebsunterlagen betroffen sind. Dazu gehören Ablaufpläne, Kontaktlisten, Monitoring-Regeln, Wiederanlaufhinweise, Servicekatalogeinträge, Supporttexte und Übergaben an den Service Desk.
Diese Prüfung muss nicht bürokratisch werden. Eine einfache Pflichtfrage im Change-Abschluss kann viel verhindern: Welche Anleitung wäre im Störfall jetzt falsch, wenn wir sie nicht anpassen? Wer diese Frage nicht beantworten kann, sollte den Change nicht als vollständig betriebsbereit markieren. Sonst entsteht ein technischer Erfolg mit operativer Restschuld.
Tests zeigen Lücken früher als echte Ausfälle
Ablaufpläne müssen nicht nur gelesen, sondern gelegentlich ausprobiert werden. Ein kurzer Tabletop-Test reicht oft aus. Eine Person beschreibt die Störung, eine andere folgt dem Plan Schritt für Schritt. Dabei wird sichtbar, ob Begriffe klar sind, ob Zugänge vorhanden sind, ob die Reihenfolge stimmt und ob Entscheidungen fehlen.
Besonders wertvoll sind Tests nach größeren Änderungen. Sie zeigen, ob ein neuer Dienstleister wirklich erreichbar ist, ob ein Cloud-Dashboard im Bereitschaftsmodell funktioniert, ob der Service Desk die richtige Sprache für Kundenmeldungen hat und ob Fachbereiche wissen, wann sie eingebunden werden. Solche Proben sind weniger teuer als eine improvisierte Nachtstörung.
Prüffragen für den nächsten Ablaufplan
- Wann wurde der Plan zuletzt nach einer echten Änderung geprüft?
- Wer ist als Besitzer sichtbar und erreichbar?
- Welche Systeme, Rollen, Kontakte oder Provider könnten seitdem gewechselt haben?
- Welche Schritte würden ohne Spezialwissen eines einzelnen Mitarbeiters funktionieren?
- Gibt es einen Test oder eine Nachbesprechung, die den Plan zuletzt bestätigt hat?
- Welche Änderung würde den Plan sofort ungültig machen?
Verlässliche Ablaufpläne entstehen nicht durch mehr Dokumente, sondern durch bessere Rückkopplung. Jede größere Änderung muss den Betrieb fragen, welche Anleitung dadurch altert. Erst dann wird Dokumentation vom Ablageort zur echten Hilfe im Ausfall.
Quellen und Einordnung: NIST SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems, NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide, Atlassian Incident Postmortem und Runbook-Praxis als öffentlich zugängliche Einordnung zu Planpflege, Lernen nach Vorfällen und betrieblicher Dokumentation. Bildquelle: Pexels, Foto-ID 1181345. Stand der Quellenprüfung: 03.07.2026.
