Bildquelle: Bildquelle: Pexels / Foto-ID 280252 / https://www.pexels.com/photo/280252/ / C00 Lizenz
Ein Servicekatalog soll nicht nur zeigen, was bestellt werden kann. Er sollte auch verraten, wie wichtig ein Dienst im Ernstfall ist. Wenn dort keine Wiederanlaufzeit steht, entscheidet der Betrieb im Ausfall oft unter Druck, welcher Dienst zuerst zurückkommt.
Mit Wiederanlaufzeit ist hier die Zeit gemeint, in der ein ausgefallener Dienst wieder arbeitsfähig sein soll. In Notfall- und Kontinuitätsplänen wird dafür häufig der Begriff Recovery Time Objective verwendet. Für ITSM-Generalisten ist die Idee wichtiger als die Abkürzung: Der Servicekatalog verbindet Leistung, Nutzerkreis, Verantwortung und Priorität. Genau dort gehört deshalb sichtbar hin, wie schnell ein Dienst nach einer Störung wieder gebraucht wird.
Ohne Zeitangabe wird Priorität zur Bauchentscheidung
Im normalen Betrieb wirkt ein Servicekatalog oft wie ein Bestell- und Informationssystem. Er nennt den Dienst, erklärt den Nutzen, zeigt Kosten, Ansprechpartner, Freigabeweg und manchmal auch Servicezeiten. Im Ausfall reicht das nicht. Dann muss der Betrieb wissen, ob ein Dienst innerhalb von Minuten, Stunden oder erst am nächsten Arbeitstag wieder verfügbar sein muss.
Fehlt diese Einordnung, entsteht eine gefährliche Lücke zwischen Managementerwartung und technischer Realität. Der wichtigste Dienst ist dann nicht automatisch der teuerste, der lauteste oder der mit dem prominentesten Fachbereich. Entscheidend ist, welche Geschäftsprozesse davon abhängen, welche Kundenzusagen betroffen sind und welche Folgeschäden entstehen, wenn der Wiederanlauf länger dauert. Ohne diese Sichtbarkeit gewinnt im Zweifel die lauteste Forderung, nicht die beste Betriebspriorität.
Der Servicekatalog macht Erwartungen sichtbar
Eine Wiederanlaufzeit im Servicekatalog ist keine Garantie, dass jede Störung exakt in dieser Zeit gelöst wird. Sie ist eine Planungs- und Steuerungsgröße. Sie hilft, Backup-Strategien, Bereitschaft, Eskalationswege, Kommunikation und Wiederherstellungsreihenfolge an einer sichtbaren Erwartung auszurichten.
Praktisch kann ein Katalogeintrag eine kurze Zeile enthalten: „Wiederanlaufziel: vier Stunden nach bestätigtem Ausfall, abhängig von Infrastruktur und Datenstand.“ Diese Formulierung ist verständlicher als eine isolierte Kennzahl. Sie zeigt den Zeithorizont und gleichzeitig die Grenze der Aussage. Der Betrieb kann daraus ableiten, welche Vorarbeiten nötig sind, der Fachbereich erkennt die Erwartung, und das Management sieht, ob ein Dienst wirklich kritisch genug behandelt wird.
Eine Zeitangabe braucht einen Besitzer
Wiederanlaufzeiten veralten, wenn niemand sie pflegt. Neue Schnittstellen, zusätzliche Nutzergruppen, Cloud-Abhängigkeiten oder geänderte Geschäftsprozesse können die Bedeutung eines Dienstes stark verschieben. Deshalb sollte jede Zeitangabe mit einer Service-Owner-Rolle verbunden sein. Diese Rolle muss nicht jedes Backup selbst betreiben, aber sie muss die fachliche Priorität regelmäßig bestätigen.
Für den Service Desk ist diese Verbindung besonders wertvoll. Im Ausfall muss er nicht raten, welcher Fachbereich zuerst informiert wird oder welche Eskalation legitim ist. Der Katalogeintrag liefert einen ersten Rahmen: Dienst, Besitzer, erwartete Wiederanlaufzeit, Kommunikationskontakt und Abhängigkeiten. So wird aus einer technischen Störung schneller eine steuerbare Entscheidungslage.
So baust Du die Angabe in den Katalog ein
- Beginne mit den wichtigsten produktiven Diensten, nicht mit jedem kleinen Hilfstool.
- Formuliere die Wiederanlaufzeit in normaler Sprache, zum Beispiel „innerhalb eines Arbeitstags“ oder „innerhalb von vier Stunden nach bestätigtem Ausfall“.
- Nenne die Rolle, die diese Priorität fachlich bestätigt und regelmäßig überprüft.
- Verknüpfe die Angabe mit Backup, Bereitschaft, Eskalation und Kundeninformation.
- Prüfe nach größeren Änderungen, ob die Zeitangabe noch zur tatsächlichen Abhängigkeit passt.
NIST beschreibt Kontinuitätsplanung als Vorbereitung darauf, IT-Systeme nach Unterbrechungen in einer priorisierten Reihenfolge wiederherzustellen. Ready.gov betont für Geschäftsfortführung, dass Organisationen kritische Funktionen, Abhängigkeiten und Wiederherstellungsanforderungen kennen müssen. Atlassian ordnet Wiederherstellungskennzahlen wie Mean Time To Repair als Messgrößen ein, die erst dann nützlich sind, wenn sie in operative Entscheidungen übersetzt werden. Für itsm.news folgt daraus: Die Wiederanlaufzeit gehört nicht in ein separates Notfalldokument, das im Alltag niemand öffnet. Sie gehört auch an die Stelle, an der Dienste, Verantwortliche und Erwartungen ohnehin sichtbar werden.
Quellen und Einordnung: NIST SP 800-34 Rev. 1 zur Contingency Planning Guide for Federal Information Systems, Ready.gov zur Business Continuity Planning Suite, Atlassian zu Incident-Management-Kennzahlen. Stand der Quellenprüfung: 24.07.2026. Bildquelle: Pexels / Foto-ID 280252 / C00 Lizenz.
