Bildquelle: extern
Inventarlisten wirken unscheinbar, bis eine IT-Störung eskaliert. Dann entscheidet sich, ob der Service Desk nur einen Gerätenamen sieht oder wirklich versteht, welcher Service, welcher Vertrag, welche Schnittstelle und welcher Verantwortliche betroffen sind. Leere Felder in der CMDB sind deshalb kein Dokumentationsproblem am Rand. Sie verteuern Störungen, weil sie Suche, Rückfragen und falsche Prioritäten auslösen.
Eine CMDB, also eine Configuration Management Database, ist eine Datenbasis für wichtige IT-Bausteine und ihre Beziehungen. Dazu gehören Server, Anwendungen, Cloud-Ressourcen, Netzwerke, Verträge, Standorte, Eigentümer und Services. Für Nicht-Spezialisten ist der Kern einfach: Die CMDB soll zeigen, wovon ein Service abhängt und wer bei Änderungen oder Störungen handeln muss. Fehlen diese Informationen, bleibt das Tool zwar vorhanden, aber der Betrieb arbeitet weiter mit Vermutungen.
Das Problem beginnt nicht beim Tool
Inventar- und Konfigurationsmanagement scheitert selten daran, dass ein Feld in der Software fehlt. Häufiger fehlt die Entscheidung, welche Informationen im Alltag wirklich gebraucht werden. Ein Service Desk braucht andere Daten als der Einkauf, Security oder die Architektur. Wenn jede Gruppe ihre eigene Sicht pflegt, entstehen parallele Listen, unterschiedliche Namen und widersprüchliche Zuständigkeiten. Im ruhigen Betrieb fällt das kaum auf. Im Störungsfall wird daraus ein Zeitverlust.
Ein Beispiel: Eine Anwendung fällt aus, aber im Datensatz steht nur der technische Hostname. Der fachliche Service fehlt. Der Owner ist nicht mehr aktuell. Die Supportgruppe verweist auf ein altes Team. Der Vertrag enthält keine erreichbare Eskalationsadresse. Jede einzelne Lücke wirkt klein. Zusammen führen sie dazu, dass Menschen telefonieren, Tickets weiterreichen und im Zweifel zu breit alarmieren. Genau dort werden Störungen teurer.
Vollständigkeit ist kein Selbstzweck
Der naheliegende Fehler ist, aus der CMDB ein Formularmonster zu machen. Mehr Pflichtfelder bedeuten nicht automatisch bessere Steuerung. Entscheidend ist, welche Felder eine konkrete Entscheidung verbessern. Für Störungen sind das vor allem Servicebezug, Kritikalität, technische Abhängigkeiten, verantwortliche Gruppe, Lieferant, Vertragsstatus, letzter bestätigter Prüfstand und ein Hinweis, wo operative Dokumentation liegt. Diese Daten müssen nicht perfekt sein. Sie müssen im Ernstfall belastbarer sein als Zuruf und Erinnerung.
ITIL beschreibt Service Management als eine Arbeitsweise, mit der IT-Services geplant, geliefert und verbessert werden. Diese Sicht ist wichtig, weil Inventardaten nicht als technische Ablage verstanden werden sollten. Sie sind Betriebsmittel für Entscheidungen: Wer muss reagieren? Welche Nutzer sind betroffen? Welche Änderung könnte die Störung ausgelöst haben? Welche Komponente darf nicht isoliert betrachtet werden?
Der Service Desk sieht die Datenqualität zuerst
Der Service Desk ist ein guter Prüfpunkt für CMDB-Qualität, weil dort die Lücken praktisch sichtbar werden. Wenn Tickets häufig mit Rückfragen beginnen, wenn Zuordnungen manuell korrigiert werden müssen oder wenn Standardtexte falsche Zuständigkeiten nennen, zeigt das nicht nur ein Prozessproblem. Es zeigt, dass Inventar- und Servicedaten nicht mehr zur Realität passen.
Diese Rückmeldungen sollten nicht als Einzelfehler verschwinden. Sinnvoll ist ein einfacher Korrekturpfad: Der Service Desk markiert den fehlenden oder falschen Datensatz, ein verantwortlicher Daten-Owner prüft ihn, und die Änderung wird nachvollziehbar bestätigt. So entsteht keine neue Schattenliste neben der CMDB. Die Betriebsorganisation nutzt echte Arbeitssignale, um die Datenbasis zu verbessern.
Security und Kosten hängen an derselben Wahrheit
Saubere Inventardaten helfen nicht nur bei Ausfällen. Sicherheitsvorgaben wie Asset-Inventare, Schwachstellenmanagement und Lieferkettenprüfung setzen voraus, dass Organisationen wissen, welche Systeme sie betreiben. Auch Kostensteuerung braucht diese Grundlage. Eine verwaiste Anwendung kann Lizenzen binden, Cloud-Kosten erzeugen oder Wartungsverträge verlängern, obwohl niemand sie bewusst steuert.
Darum sollte die CMDB nicht als reines ITSM-Tool betrachtet werden. Sie verbindet Betrieb, Security, Einkauf und Portfolio. Wenn diese Gruppen unterschiedliche Quellen nutzen, entstehen blinde Flecken. Wenn sie eine gemeinsame, geprüfte Mindestwahrheit pflegen, werden Störungen schneller eingeordnet und Risiken früher sichtbar.
Ein kleiner Prüfrahmen reicht für den Anfang
Organisationen müssen nicht sofort jede Komponente vollständig modellieren. Wirksamer ist ein enger Start mit kritischen Services. Für jeden dieser Services sollten fünf Fragen beantwortbar sein: Welche technischen Bausteine tragen ihn? Welche Nutzer oder Geschäftsprozesse hängen daran? Wer entscheidet im Störungsfall? Welche Lieferanten oder Verträge sind relevant? Wann wurde der Datensatz zuletzt gegen die Realität geprüft?
Aus diesen Fragen entsteht eine praktische Qualitätsmessung. Nicht die Zahl der gepflegten Objekte zählt, sondern die Nutzbarkeit bei Störung, Änderung und Risikoanalyse. Wenn ein Datensatz diese Fragen nicht beantwortet, ist er für den Betrieb nur begrenzt hilfreich, selbst wenn er formal existiert.
Die wichtigste Regel ist Verantwortlichkeit
CMDB-Pflege darf nicht nebenbei passieren. Jeder wichtige Service braucht einen Datenverantwortlichen, der Änderungen bestätigt und veraltete Informationen bereinigt. Automatische Discovery kann technische Fakten liefern, aber sie erkennt nicht zuverlässig, welcher Service fachlich betroffen ist, wer entscheiden darf oder welche Eskalation im Vertrag steht. Diese Informationen brauchen klare Ownership.
Für ITSM-Generalisten ist die Konsequenz deutlich: Leere Inventardaten sind kein kosmetischer Mangel. Sie verlängern Störungen, schwächen Security-Prüfungen und verschleiern Kosten. Ein gutes ITSM-Tool löst das nicht allein. Erst wenn die Organisation festlegt, welche Daten im Ernstfall entscheidungsfähig machen und wer sie aktuell hält, wird aus Inventar ein Betriebsnutzen.
Quellen und Einordnung: AXELOS zu ITIL und Service Management, NIST Cybersecurity Framework, CIS Controls zu Enterprise Asset Inventory sowie CISA Secure-by-Design-Ressourcen. Stand der Quellenprüfung: 29.06.2026.
