Im Ausfall zählt der Besitzer hinter dem Service

Kurz gesagt Eine IT-Störung wird nicht nur durch Technik langsam. Sie wird langsam, wenn niemand sicher weiß, wer den betroffenen Service fachlich besitzt, wer Entscheidungen treffen darf und welche Abhängigkeiten zuerst geprüft werden müssen. Ein gepflegter Servicekatalog ist deshalb kein schönes Verzeichnis für ruhige Tage, sondern eine Arbeitsgrundlage für den Moment, in dem Minuten zählen.

Im Alltag klingt Serviceverantwortung oft selbstverständlich. Der Datenbankbetrieb kennt seine Systeme, der Service Desk kennt die Hotline, das Fachteam kennt die Anwendung. Im Ausfall reicht dieses lose Wissen aber selten. Dann fragt niemand abstrakt nach einem Systemnamen. Dann geht es um Kundenwirkung, Priorität, Kommunikationswege, Wiederanlauf, Ausnahmen und die Frage, wer ein Risiko wirklich abzeichnen darf.

Ein Systemname ist noch kein Service

Der technische Name eines Servers, einer Datenbank oder einer Anwendung hilft im Maschinenraum. Für die Störungssteuerung ist er nur ein Teil der Wahrheit. Ein Service verbindet Technik mit Wirkung. Er beantwortet, wofür etwas gebraucht wird, wer betroffen ist, welche Zusagen gelten und welche Teams zusammenarbeiten müssen.

Genau an dieser Stelle entstehen in vielen Betriebsmodellen Reibungen, ohne dass sie sofort als Datenproblem erkannt werden. Ein Monitoring-Alarm nennt eine Komponente. Das Ticket landet beim Support. Der Support sucht den Business-Kontext. Ein Plattformteam kennt die Plattform, aber nicht die Priorität des Fachprozesses. Ein Fachbereich spürt den Ausfall, weiß aber nicht, welcher technische Pfad betroffen ist. Aus einer technischen Störung wird dadurch ein Koordinationsproblem.

Serviceverantwortung muss entscheidungsfähig sein

Ein Service Owner ist mehr als ein Name im Feld. Die Rolle muss im Ernstfall entscheiden oder die Entscheidung schnell herbeiführen können. Dazu gehören Prioritäten, Nutzerwirkung, Kommunikationsfreigaben und die Bereitschaft, zwischen schneller Reparatur und sicherem Betrieb abzuwägen.

Wenn diese Verantwortung nur formal eingetragen ist, zeigt sich der Fehler erst unter Druck. Der eingetragene Ansprechpartner ist im Urlaub, kennt die technische Veränderung nicht oder darf keine Risikoentscheidung treffen. Dann beginnt während der Störung die Suche nach der eigentlichen Zuständigkeit. Jede Eskalationsstufe erzeugt Wartezeit, obwohl der technische Befund vielleicht längst klar ist.

Praxisnah wird Serviceverantwortung erst, wenn der Katalog nicht nur Rollen nennt, sondern auch Stellvertretung, Kommunikationsweg, Fachbereich, technische Hauptabhängigkeiten und Betriebsfenster sichtbar macht. Der Service Desk braucht diese Informationen nicht als Governance-Dokument, sondern als sofort nutzbare Entscheidungshilfe.

Der Katalog braucht Störungslogik

Ein guter Servicekatalog ist nicht nur für Bestellungen und Beschreibungen geschrieben. Er muss auch im Ausfall funktionieren. Dafür braucht er Felder, die bei der Störungsklärung direkt helfen: betroffene Nutzergruppen, Kritikalität, Wiederanlaufreihenfolge, bekannte Abhängigkeiten, zuständige Teams, externe Provider, Kommunikationskanal und letzte wesentliche Änderung.

Besonders wichtig ist die Verbindung zwischen Service und Abhängigkeiten. Ein Ausfall wirkt selten isoliert. Identität, Netzwerk, DNS, Schnittstellen, Cloud-Plattform, Datenbank, Berechtigungen oder ein externer Dienstleister können denselben Nutzerprozess treffen. Wenn der Katalog nur den sichtbaren Hauptservice zeigt, bleibt die eigentliche Wirkungskette verborgen.

Wenige Pflichtfelder schlagen perfekte Modellierung

Der häufige Fehler liegt im Anspruch auf Vollständigkeit. Teams beginnen mit einem großen Datenmodell und verlieren Tempo, bevor der erste echte Nutzen entsteht. Für den Betrieb ist eine kleinere, gepflegte Pflichtstruktur oft wertvoller. Sie muss beantworten, wer entscheidet, wer repariert, wer informiert wird, welche Nutzerwirkung zu erwarten ist und welche Abhängigkeiten zuerst geprüft werden.

Diese Pflichtfelder sollten in Störungen, Änderungen und Service Reviews regelmäßig auftauchen. Ein Incident Review kann prüfen, ob die Zuständigkeit schnell genug klar war. Ein Change kann bestätigen, ob der Katalog nach einer Architekturänderung angepasst wurde. Ein Service Review kann veraltete Besitzer, falsche Kontakte und verschwundene Abhängigkeiten bereinigen. So bleibt der Katalog nicht Nebenakte, sondern Teil des Betriebsrhythmus.

Service Desk und Fachbereich müssen dieselbe Sprache sehen

Für Generalisten ist die Übersetzung entscheidend. Ein Fachbereich meldet keine fehlerhafte Queue, sondern einen unterbrochenen Prozess. Ein Nutzer beschreibt keine Datenbanklatenz, sondern eine Bestellung, die nicht abgeschlossen werden kann. Der Servicekatalog muss diese Sichten verbinden, sonst entstehen doppelte Wahrheiten.

Hilfreich sind deshalb verständliche Servicenamen, kurze Zweckbeschreibungen, eindeutige Nutzergruppen und klare Beispiele. Der technische Tiefgang bleibt wichtig, aber er gehört hinter eine lesbare Serviceperspektive. Erst diese Kombination erlaubt es dem Service Desk, Meldungen sauber zuzuordnen und betroffene Teams schneller zusammenzubringen.

Eine kurze Checkliste für den nächsten Review

• Hat jeder kritische Service einen entscheidungsfähigen Besitzer und eine echte Stellvertretung?
• Ist erkennbar, welche Nutzergruppe und welcher Geschäftsprozess betroffen sind?
• Sind die wichtigsten technischen und externen Abhängigkeiten sichtbar?
• Gibt es einen klaren Kommunikationsweg für Störungen und Änderungen?
• Wird der Katalog nach Reviews, größeren Änderungen und Providerwechseln aktualisiert?
• Kann der Service Desk mit den Angaben innerhalb weniger Minuten handeln?

Fazit

Servicekataloge wirken schnell administrativ, wenn sie nur als Inventar gepflegt werden. Ihr eigentlicher Wert zeigt sich im Ausfall. Dann entscheidet nicht die schönste Beschreibung, sondern die Frage, ob Zuständigkeit, Wirkung und nächste Handlung sofort erkennbar sind. Wer diesen Blick in den Katalog einbaut, verkürzt nicht jede technische Reparatur. Er verhindert aber, dass wertvolle Zeit in Zuständigkeitssuche verschwindet.

Quellen und Einordnung Axelos zu ITIL 4 Service Catalogue Management und IT Service Management, Atlassian zu Servicekatalogen und Service Ownership.