CMDB aufbauen aus IT-Inventar braucht klare Servicefragen

CMDB aufbauen klingt nach Toolprojekt. Im Alltag entscheidet aber eine einfachere Frage: Welche Servicefrage soll ein Inventardatensatz beantworten, wenn ein Ticket, eine Änderung oder ein Ausfall auf dem Tisch liegt?

Eine Configuration Management Database, kurz CMDB, soll Informationen über IT-Komponenten und ihre Beziehungen sammeln. Dazu gehören Server, Anwendungen, Datenbanken, Schnittstellen, Services, Verträge, Owner und Abhängigkeiten. Für ITSM-Generalisten ist die CMDB nicht die schönere Inventarliste. Sie ist nur dann wertvoll, wenn sie im Betrieb erklärt, welcher Service betroffen ist, wer entscheiden darf und welche Folge eine Änderung oder Störung hat.

Warum eine CMDB nicht mit dem Tool beginnt

Der häufigste Fehler beim CMDB-Aufbau ist der Start mit einer vollständigen Datenfantasie. Dann werden Servernamen, Anwendungen, Geräte, Verträge und Schnittstellen gesammelt, bevor geklärt ist, welche Entscheidung mit diesen Daten besser werden soll. Das Ergebnis wirkt fleißig, bleibt aber schwer nutzbar. Die Liste wächst, die Pflege wird mühsam und im Störungsfall fragt trotzdem jemand im Chat, wem der betroffene Dienst gehört.

Ein tragfähiger Einstieg beginnt anders. Zuerst wird eine Servicefrage ausgewählt. Zum Beispiel: Welche Anwendungen hängen an diesem geschäftskritischen Service? Wer ist Owner? Welche Systeme müssen vor einer Änderung geprüft werden? Welche Provider sind beteiligt? Erst danach werden die Datenfelder festgelegt. So bleibt die CMDB klein genug für Pflege und konkret genug für den Betrieb.

Inventardaten brauchen einen Servicebezug

IT-Inventar beantwortet meist, was vorhanden ist. Eine CMDB muss zusätzlich erklären, wofür es gebraucht wird. Ein Server, eine Datenbank oder eine Anwendung ist im Betrieb nur begrenzt hilfreich, solange der Bezug zum Service fehlt. Wird daraus sichtbar, welche Nutzergruppe, welcher Standort, welcher Fachprozess oder welches SLA betroffen ist, wird aus Bestandswissen Betriebswissen.

Genau an dieser Stelle berührt der CMDB-Aufbau den Servicekatalog. Der Beitrag alte Services mit Owner-Freigabe aus dem Servicekatalog streichen zeigt, warum fehlende Verantwortung Lücken erzeugt. Eine CMDB kann diese Lücken sichtbar machen, wenn sie Service, Komponente und Owner verbindet. Ohne diese Verbindung entsteht nur eine zweite Ablage neben dem Inventarsystem.

Die erste Datenlinie muss klein und prüfbar sein

Für den Start reichen wenige Pflichtfelder. Sinnvoll sind Service, Komponente, Owner, technischer Ansprechpartner, Kritikalität, Abhängigkeit, Datenquelle, letzter Prüfzeitpunkt und Pflegeauslöser. Pflegeauslöser heißt: Wann wird der Datensatz aktualisiert? Bei einer Änderung, bei einer Provider-Rückmeldung, beim Service-Review oder bei einem Major Incident?

Diese Begrenzung schützt vor Scheingenauigkeit. Eine CMDB mit zehn verlässlichen Feldern ist wertvoller als ein großes Modell, dessen Hälfte niemand pflegt. Wichtig ist auch, dass jede Information eine Quelle hat. Discovery-Tools können technische Fakten liefern. Owner, Servicebezug und Kritikalität brauchen meistens eine fachliche Bestätigung. Beides muss getrennt sichtbar sein.

Abhängigkeiten sind nur nützlich, wenn sie Entscheidungen auslösen

Abhängigkeiten gelten oft als Kernversprechen einer CMDB. In der Praxis helfen sie nur, wenn sie eine konkrete Entscheidung auslösen. Ein Pfeil zwischen Anwendung und Datenbank ist wenig wert, wenn niemand weiß, ob eine Änderung riskant ist, ob ein Wartungsfenster nötig wird oder wer vorab informiert werden muss.

Deshalb sollte jede Abhängigkeit mindestens eine Aussage tragen. Ist sie kritisch für die Verfügbarkeit? Betrifft sie sensible Daten? Hängt ein externer Provider daran? Muss der Service Desk bei Ausfall eine besondere Antwort geben? Der Artikel Problem Management und Incident Management im Alltag trennen macht diese Trennung ebenfalls sichtbar. Ursachenanalyse und Störungsführung brauchen andere Informationen, aber beide profitieren von klaren Abhängigkeiten.

Änderungen liefern die beste Pflegechance

Eine CMDB veraltet nicht plötzlich. Sie veraltet durch viele kleine Änderungen, die nicht zurück in die Datenbasis geschrieben werden. Neue Schnittstellen, geänderte Owner, verschobene Provideraufgaben, abgelöste Server, neue Monitoring-Regeln oder geänderte Kritikalität tauchen zuerst in Tickets, Projekten und Changes auf. Dort sollte die Pflegepflicht sitzen.

Darum gehört in jede relevante Änderung eine kurze CMDB-Frage: Welche Konfigurationselemente ändern sich? Welcher Servicebezug ist betroffen? Muss ein Owner, eine Abhängigkeit oder ein Pflegezeitpunkt angepasst werden? Der Beitrag SLA Vorlage mit Messpunkten zeigt denselben Grundsatz bei Zusagen. Was später steuerbar sein soll, braucht einen klaren Mess- oder Pflegepunkt.

Discovery ersetzt keine Verantwortung

Automatische Erkennung kann den CMDB-Aufbau stark beschleunigen. Sie findet Systeme, Softwarestände, Netzwerkbeziehungen und technische Merkmale. Sie löst aber nicht die Verantwortungsfrage. Ein Tool kann erkennen, dass eine Anwendung mit einer Datenbank spricht. Es entscheidet nicht, ob diese Verbindung geschäftskritisch ist, wer eine Ausnahme genehmigt oder welche Antwort der Service Desk im Ausfall geben soll.

Deshalb braucht der CMDB-Prozess eine Rollenregel. Technische Daten kommen aus Discovery, Monitoring, Cloud-Plattformen oder Inventarsystemen. Servicebezug, Kritikalität und Owner werden fachlich bestätigt. Streitfälle werden nicht in der Datenpflege versteckt, sondern als offene Klärung geführt. So wird die CMDB nicht zur Datenkippe, sondern zum gemeinsamen Betriebsmodell.

Mini-Vorlage für den ersten CMDB-Schnitt

• Servicefrage: Welche Entscheidung soll die CMDB zuerst verbessern?
• Startumfang: Welche fünf bis zehn Services oder Anwendungen werden zuerst modelliert?
• Pflichtfelder: Welche Felder sind für Tickets, Changes und Reviews wirklich nötig?
• Datenquelle: Kommt die Information aus Discovery, Inventar, Vertrag, Servicekatalog oder Owner-Bestätigung?
• Pflegeauslöser: Welches Ticket, welcher Change oder welcher Review aktualisiert den Datensatz?
• Qualitätsprobe: Welche drei Störungen oder Änderungen werden gegen die neuen Daten getestet?

Diese Vorlage verhindert, dass der CMDB-Aufbau sofort zu groß wird. Sie zwingt zur Entscheidung, wo der erste Nutzen entsteht. Wenn eine Störung, eine Änderung oder ein Review mit den Daten schneller verstanden wird, ist der erste Schnitt brauchbar. Wenn nicht, fehlen entweder Servicebezug, Owner, Abhängigkeit oder Pflegeauslöser.

Qualitätsprüfung gehört in den Monatsrhythmus

Eine CMDB braucht außerdem eine einfache Qualitätsprüfung. Dafür muss nicht jeder Datensatz jeden Monat vollständig kontrolliert werden. Besser ist eine Stichprobe aus echten Fällen. Welche Störung war schwer zuzuordnen? Welche Änderung hatte unerwartete Nebenwirkungen? Welcher Provider konnte nicht rechtzeitig antworten, weil der Servicebezug fehlte? Solche Fälle zeigen, ob die CMDB im Betrieb hilft oder nur formal gepflegt wird.

Die Qualitätsprobe sollte drei Ergebnisse liefern. Erstens: Welche Felder waren im Fall zuverlässig? Zweitens: Welche Information fehlte für eine Entscheidung? Drittens: Welcher Pflegeauslöser muss angepasst werden, damit der Fehler nicht wiederkommt? So wird Datenqualität nicht als abstrakter Prozentwert diskutiert. Sie wird an einem Servicefall geprüft, den jeder nachvollziehen kann.

So bleibt die CMDB im Alltag brauchbar

Eine CMDB bleibt nur dann aktuell, wenn ihre Pflege im normalen Arbeitsfluss sitzt. Jede Änderung am Service, jede kritische Störung und jeder Service-Review sollte einen kurzen Datenblick enthalten. Nicht als Zusatzbürokratie, sondern als Schutz vor späterem Rätselraten. Die bessere Frage lautet nicht, ob alle Felder perfekt sind. Die bessere Frage lautet, ob der nächste Betriebsfall mit den vorhandenen Daten schneller entschieden werden kann.

Für Service Manager entsteht daraus ein pragmatischer Weg. Ein kleiner, sauber gepflegter Ausschnitt wird produktiv genutzt, geprüft und erweitert. Jede Erweiterung braucht wieder eine Servicefrage. So wächst die CMDB nicht aus Sammeldrang, sondern aus überprüfbarem Nutzen für Service Desk, Change Enablement, Problem Management und Providersteuerung.

Der wichtige Prüfpunkt liegt am Ende jeder Erweiterung. Kann ein Service-Desk-Mitarbeiter mit den Daten schneller erkennen, welcher Service betroffen ist? Kann ein Change-Verantwortlicher sehen, welche Abhängigkeit geprüft werden muss? Kann ein Problem-Manager erkennen, ob mehrere Störungen denselben technischen oder organisatorischen Zusammenhang haben? Wenn diese Fragen nicht beantwortet werden, ist das Modell zu grob, zu technisch oder zu schlecht gepflegt.

Quellen und Stand: Quellenprüfung am 10.08.2026. Einordnung anhand von Atlassian zu CMDB und Configuration Management, AXELOS zu ITIL 4 Service Configuration Management, AXELOS zur Service Configuration Management Practice und PeopleCert zu ITIL 4. Bildquelle: Pexels / Foto-ID 3861958 / https://www.pexels.com/photo/3861958/ / CC0-Lizenz