Der Service Desk braucht bei Störungen die richtigen Betriebsdaten

Im Störfall zählt nicht die vollständigste Datenbank, sondern die schnellste belastbare Zuordnung. Wer ist verantwortlich, welcher Dienst hängt daran, welche Änderung kam zuletzt und welche Abhängigkeit darf jetzt nicht übersehen werden? Genau diese Betriebsdaten entscheiden, ob der Service Desk nur sucht oder den nächsten Schritt auslösen kann.

Eine CMDB ist eine Configuration Management Database. Sie sammelt Informationen über technische und organisatorische Bausteine eines IT-Services, etwa Anwendungen, Server, Schnittstellen, Verträge, Verantwortliche und Abhängigkeiten. Für ITSM-Generalisten ist daran weniger die Tooltiefe wichtig als die Betriebsfrage: Welche Daten helfen im Moment einer Störung wirklich, eine Entscheidung zu treffen?

Vollständigkeit klingt besser als sie im Ernstfall wirkt

CMDB-Projekte scheitern selten daran, dass niemand Daten haben möchte. Sie scheitern eher daran, dass zu viele Felder gepflegt werden sollen und niemand klar sagt, welche Informationen im Betrieb Priorität haben. Eine lange Liste kann beruhigend aussehen und trotzdem keine Hilfe sein, wenn im Alarmfall der Service Owner fehlt, die letzte Änderung unklar ist oder die Abhängigkeit zum Kundensystem nicht sichtbar wird.

Der bessere Startpunkt ist eine einfache Störfallfrage. Welche Information braucht ein Support- oder Betriebsteam in den ersten Minuten, damit es nicht blind eskaliert? Aus dieser Frage entsteht eine andere Datenlogik. Nicht jedes Attribut ist gleich wichtig. Verantwortlichkeit, betroffener Service, technische Abhängigkeit, Kritikalität, letzter Change, Supportweg und Kommunikationskontakt stehen deutlich weiter vorne als dekorative Detailfelder.

Der Servicebezug schlägt die Geräteliste

Eine reine Geräteliste hilft, wenn ein konkreter Server, ein Netzwerkgerät oder eine Anwendung gesucht wird. ITSM braucht aber meistens den Dienstbezug. Ein ausgefallenes System ist nicht nur ein technisches Objekt. Es trägt eine Funktion, eine Kundenzusage, eine interne Abhängigkeit oder einen Geschäftsprozess. Ohne diesen Bezug bleibt die Störung technisch, obwohl sie längst eine Servicefrage ist.

Deshalb sollte jedes zentrale Betriebsobjekt mindestens einen Service, einen fachlichen Ansprechpartner und einen technischen Owner haben. Die Zuordnung muss nicht perfekt akademisch sein. Sie muss im Ernstfall belastbar genug sein, damit niemand erst in alten Projektmails, Chatverläufen oder persönlichen Notizen suchen muss. Ein unvollständiger, aber geprüfter Servicebezug ist oft wertvoller als ein riesiger Datensatz ohne Besitzer.

Abhängigkeiten müssen praktisch lesbar bleiben

Abhängigkeiten sind der Kern jeder guten Betriebsdatenbasis. Sie zeigen, welche Anwendung eine Datenbank nutzt, welcher Dienst an einer Schnittstelle hängt oder welcher Provider im Hintergrund beteiligt ist. Für den Störfall reicht eine abstrakte Netzgrafik aber nicht. Das Betriebsteam muss erkennen, welche Verbindung kritisch ist, welche Folge realistisch droht und wo zuerst geprüft werden sollte.

Hilfreich ist eine klare Unterscheidung zwischen harten und weichen Abhängigkeiten. Hart ist eine Verbindung, ohne die der Service ausfällt oder falsche Ergebnisse liefert. Weich ist eine Verbindung, die Komfort, Auswertung oder einen Nebenprozess betrifft. Diese Einordnung verhindert Panik und schützt zugleich vor gefährlicher Verharmlosung. Der Service Desk kann dann erklären, warum ein scheinbar kleiner Fehler eine große Kundenwirkung haben kann.

Der letzte Change gehört neben den betroffenen Dienst

Bei Störungen fragt der Betrieb früh, was sich geändert hat. Wenn Change-Daten getrennt vom betroffenen Service liegen, geht wertvolle Zeit verloren. Eine CMDB oder ein anderes ITSM-Tool sollte deshalb sichtbar machen, welche Änderung zuletzt an einer Anwendung, Infrastrukturkomponente oder Schnittstelle vorgenommen wurde. Gemeint ist nicht nur die Ticketnummer. Wichtig sind Zeit, Ziel, betroffene Komponente, Verantwortlicher und Rückweg.

Diese Verbindung hilft auch gegen vorschnelle Schuldzuweisung. Nicht jede Störung entsteht durch den letzten Change. Aber ohne die Information wird die Suche unsauber. Teams prüfen dann parallel Symptome, Logs, Providerstatus und alte Annahmen, obwohl eine kleine Änderung den wahrscheinlichsten Einstiegspunkt liefert. Gute Betriebsdaten machen den Anfang der Diagnose strukturierter.

Pflege braucht eine kleine Prioritätenliste

Der größte Fehler ist der Anspruch, alles gleichzeitig aktuell zu halten. Für den Alltag funktioniert eine Prioritätenliste besser. Stufe eins umfasst produktive Services mit Kundenwirkung, zentrale Identitätsdienste, Netzwerk- und Cloud-Basisdienste, Backup, Monitoring und kritische Schnittstellen. Stufe zwei umfasst wichtige interne Dienste. Stufe drei enthält Rand- und Testsysteme, die trotzdem nicht vergessen werden dürfen.

Für jede Stufe sollte klar sein, wie oft die Daten geprüft werden, wer Änderungen einträgt und welches Feld niemals leer bleiben darf. Wenn der Service Owner fehlt, die Kritikalität unbekannt ist oder keine Eskalationsadresse existiert, ist der Datensatz nicht nur unvollständig. Er ist im Störfall riskant. Der Pflegeprozess sollte solche Lücken sichtbar machen und nicht in Tabellen verstecken.

Ein kleiner Störfalltest deckt schwache Daten auf

Ein pragmatischer Test reicht oft aus. Das Team wählt einen produktiven Service und stellt drei Fragen: Wer entscheidet bei einer Störung, welche technische Abhängigkeit ist zuerst zu prüfen und welche Änderung lag zuletzt am Dienst oder an einer direkten Komponente? Wenn diese Antworten im Tool nicht schnell auffindbar sind, ist die Datenbasis noch nicht betriebssicher.

So wird aus CMDB-Pflege kein Bürokratieprojekt. Sie wird zur Vorbereitung auf den nächsten Ausfall. Die wichtigste Datenfrage lautet dann nicht, ob jedes Feld gefüllt ist. Sie lautet, ob der Service Desk im ersten Störungsfenster genug Kontext bekommt, um richtig zu eskalieren, Kunden sauber zu informieren und die nächste technische Prüfung auszulösen.

Quellen und Einordnung AXELOS zu ITIL 4 Service Configuration Management, IBM zur Einordnung von Configuration Management, Atlassian zu IT Asset Management im ITSM-Kontext, NIST SP 800-61 Rev. 2 zu Computer Security Incident Handling. Stand der Quellenprüfung: 17.07.2026. Bildquelle: Pexels, Foto-ID 357514.