ITIL CMDB als Grundlage für besseres Incident- und Change-Management

Eine CMDB nach ITIL verbindet technische Informationen mit den Services, die Ihr Unternehmen täglich benötigt. Sie macht sichtbar, welche Systeme zusammenarbeiten, wer verantwortlich ist und welche Folgen Störungen oder Änderungen haben können. Hier erfahren Sie, welche Aufgaben eine CMDB nach ITIL hat und wir zeigen Ihnen anhand praktischer Beispiele, wie Sie das Incident- und Change-Management mit verlässlichen Konfigurationsdaten unterstützen. Außerdem erfahren Sie, wie Sie eine CMDB schrittweise einführen und Ihre Datenqualität dauerhaft erhöhen.

Inhaltsverzeichnis

1. Was ist eine ITIL CMDB
2. ITIL CMDB vs. IT Asset Management
3. Welche Rolle nimmt eine CMDB in ITIL ein
4. ITIL v3 vs. ITIL 4 – was sich beim Configuration Management ändert
5. Welche Informationen in eine ITIL CMDB gehören
6. Wie eine ITIL CMDB das Incident-Management unterstützt
7. Warum Change Management eine verlässliche CMDB benötigt
8. Eine ITIL CMDB schrittweise einführen
9. Datenqualität und Automatisierung dauerhaft sichern
10. Sinnvolle Kennzahlen für die laufende Verbesserung
11.  Häufige Fragen zur ITIL CMDB

Was ist eine ITIL CMDB

CMDB steht für Configuration Management Database. Darin werden ausgewählte Configuration Items, kurz CIs, mit ihren Eigenschaften und Beziehungen dokumentiert. Ein CI ist eine Komponente, die Sie steuern und verwalten müssen, um einen IT-Service bereitzustellen. Dazu können Server, Anwendungen, Netzwerkgeräte und Cloud-Ressourcen gehören, aber auch Services, Schnittstellen oder relevante Dokumentationen.

Die kompakte ITIL CMDB Definition lautet: Eine CMDB ist eine Datenbank, die Informationen über Configuration Items und deren Beziehungen über ihren Lebenszyklus bereitstellt. Die Bezeichnung „ITIL CMDB“ beschreibt dabei den Einsatz dieser Datenbasis im IT-Service-Management nach ITIL.

Der entscheidende Mehrwert liegt in den Zusammenhängen. Eine Inventarliste zeigt beispielsweise, dass eine virtuelle Maschine existiert. Eine sinnvoll modellierte ITIL CMDB zeigt zusätzlich, welche Anwendung darauf läuft, welcher Service davon abhängt und welches Team bei einem Ausfall zuständig ist. Auch Verträge können mit einem CI verknüpft werden, um Abhängigkeiten zu modellieren.

Einen Überblick über Funktionen, Integrationen und Einsatzmöglichkeiten finden Sie auf unserer Seite zur CMDB für IT-Dokumentation und Servicemanagement.

ITIL CMDB vs. IT Asset Management

IT Asset-Management und Configuration Management nutzen häufig Informationen über dieselben Geräte und Anwendungen, beantworten aber unterschiedliche Fragen.

IT Asset-Management betrachtet vor allem Beschaffung, Nutzung, Kosten, Verträge und Ausmusterung. Die ITIL CMDB dokumentiert, wie diese Komponenten miteinander verbunden sind und welche IT-Services von ihnen abhängen.

Bei einem Server erfasst das Asset Management beispielsweise Anschaffungskosten und Wartungsverträge. Die CMDB zeigt, welche Anwendungen darauf laufen, welche Services sie unterstützen und wer für den Betrieb verantwortlich ist. Gemeinsam liefern diese Informationen die Grundlage für wirtschaftliche und technische Entscheidungen.

Welche Rolle nimmt eine CMDB in ITIL ein

ITIL liefert Orientierung für die Organisation und Verbesserung des IT Service-Managements. Damit daraus im Alltag belastbare Entscheidungen entstehen, benötigen Teams verlässliche Informationen über ihre Services und deren Komponenten.

Hier setzt die ITIL CMDB an. Sie liefert beispielsweise Kontext für die Bewertung einer Störung oder die Planung einer Änderung. Die Datenbank selbst priorisiert jedoch kein Ticket und genehmigt keinen Change. Dazu benötigen Sie definierte Verantwortlichkeiten, geeignete Prozesse und gegebenenfalls eine Integration mit Ihrem ServiceDesk oder ITSM-System.

In ITIL 4 ist die entsprechende Practice das Service Configuration Management. Ihr Zweck ist zuverlässige Informationen über die Konfiguration von Services und unterstützenden CIs verfügbar zu machen, wenn sie gebraucht werden.

ITIL v3 vs. ITIL 4 – was sich beim Configuration Management ändert

In ITIL v3 ist die Verwaltung von Assets und Konfigurationsinformationen im Prozess Service Asset and Configuration Management (SACM) zusammengefasst. ITIL 4 behandelt IT Asset Management und Service Configuration Management als separate Practices mit unterschiedlichen Schwerpunkten.

Eine Practice umfasst mehr als einen festgelegten Ablauf: Sie berücksichtigt auch die beteiligten Personen, Verantwortlichkeiten, Informationen und Werkzeuge. ITIL 4 stellt diese Aspekte ausdrücklich in den Mittelpunkt. Klare Zuständigkeiten und verlässliche Daten waren allerdings bereits in ITIL v3 wichtig.

Die CMDB liefert in beiden Versionen Informationen über Configuration Items und deren Beziehungen. Sie kann Teil eines umfassenderen Configuration Management Systems (CMS) sein, das mehrere Datenquellen und Werkzeuge zusammenführt.

Für Unternehmen bleibt die praktische Aufgabe dieselbe: festlegen, welche Informationen benötigt werden, wer sie aktuell hält und wie sie im Incident und Change Management genutzt werden.

Welche Informationen in eine ITIL CMDB gehören

Der sinnvolle Umfang ergibt sich aus Ihren Anwendungsfällen. Wenn der Service Desk die Auswirkungen einer Störung erkennen soll, braucht er andere Informationen als der Einkauf bei einer Vertragsverlängerung. Beginnen Sie deshalb mit den Fragen, die Ihre Teams tatsächlich beantworten müssen.

• Für einen ersten Service können folgende Angaben ausreichen:

• Eindeutige Kennung, Name und Typ des Configuration Items.

• Betriebsstatus und Umgebung, beispielsweise Produktion oder Test.

• Technisch verantwortliches Team und fachlich verantwortliche Person.

• Relevante technische Merkmale wie Version, Standort oder Netzwerkzuordnung.

• Beziehungen zu Anwendungen, Infrastruktur und unterstützten Services.

• Datenquelle, Zeitpunkt der letzten Aktualisierung und Prüfstatus.

Definieren Sie Pflichtfelder je CI-Typ. Ein Cloud-Service benötigt andere Merkmale als ein physischer Switch. Zu viele allgemeine Pflichtfelder führen schnell zu Platzhaltern und mindern damit den Nutzen Ihrer ITIL CMDB.

Beziehungen müssen eine klare Bedeutung haben

Die Aussage „Server gehört zu Anwendung“ kann unterschiedlich verstanden werden. Läuft die Anwendung auf dem Server? Verwendet sie dort eine Datenbank? Oder betreut dasselbe Team beide Objekte?

Legen Sie eindeutige Beziehungstypen und deren Richtung fest. Beispielsweise läuft eine Anwendung auf einer virtuellen Maschine, verwendet Sie eine Datenbank und unterstützt somit einen Geschäftsservice. So werden Abhängigkeiten nachvollziehbar und bei einer Auswirkungsanalyse nutzbar.

Berücksichtigen Sie außerdem Redundanzen. Der Ausfall einer einzelnen Komponente führt nicht automatisch zum Ausfall aller verbundenen Services. Cluster, Failover und alternative Verbindungen müssen bei der Interpretation einbezogen werden. Eine Beziehungsgrafik liefert dafür Anhaltspunkte; die tatsächliche Auswirkung hängt von Architektur und Betriebszustand ab.

Wie eine ITIL CMDB das Incident-Management unterstützt

Im Incident Management soll ein gestörter Service möglichst schnell wiederhergestellt werden. Häufig geht zunächst Zeit für grundlegende Fragen verloren: Welches System ist betroffen? Wer betreut es? Welche Nutzer oder Geschäftsabläufe sind eingeschränkt?

Eine gepflegte ITIL CMDB kann diese Suche verkürzen. Wenn ein Ticket mit dem passenden CI verknüpft ist, stehen dessen Servicebeziehungen, Zuständigkeiten und technische Angaben als Ausgangspunkt für die Bearbeitung zur Verfügung.

Praxisbeispiel bei einer nicht erreichbaren Anwendung

Angenommen, mehrere Beschäftigte können keine Aufträge mehr in einer Geschäftsanwendung öffnen. Der Service Desk ordnet die Meldungen dem betroffenen Service zu. Aus dessen dokumentierten Beziehungen geht hervor, welche Anwendungskomponenten und Datenbanken beteiligt sind.

Das zuständige Team prüft anschließend Monitoring, Protokolle und kürzlich durchgeführte Änderungen. Die CMDB liefert den Zusammenhang; die aktuellen Messwerte und Fehlermeldungen liefern die technische Evidenz. Auf dieser Basis lässt sich die Untersuchung gezielter eingrenzen und deutlich schneller beheben.

Auch die Kommunikation wird konkreter: Das Supportteam erkennt, welche Fachabteilung den Service verwendet und wer über den Bearbeitungsstand informiert werden muss. Die Priorität des Incidents ergibt sich aus den vereinbarten Regeln zu Auswirkung und Dringlichkeit. Hier können auch OLAs/SLAs sinnvoll abgebildet werden.

Ticket und Configuration Item miteinander verbinden

Der Nutzen wächst, wenn Mitarbeitende die Daten direkt im Supportprozess erreichen. Dafür muss die Integration passende CIs auffindbar machen und deren Identität eindeutig übergeben. Ein frei eingetippter Servername ist bei Umbenennungen und ähnlichen Bezeichnungen fehleranfällig.

Wie sich dieser Zusammenhang mit i-doit abbilden lässt, zeigt unser Anwendungsfall Incident Management und Ticketing. Welche Informationen im Ticket erscheinen und zurückgeschrieben werden, hängt von der eingesetzten Anbindung und deren Konfiguration ab.

Warum Change Management eine verlässliche CMDB benötigt

Vor einer Änderung müssen Teams beurteilen, welche Auswirkungen möglich sind und wie sich das Risiko angemessen begrenzen lässt. In ITIL 4 wird diese Aufgabe unter dem Begriff Change Enablement behandelt. Im Unternehmensalltag ist die Bezeichnung Change Management weiterhin verbreitet.

Eine ITIL CMDB unterstützt die Vorbereitung, indem sie betroffene Komponenten und dokumentierte Abhängigkeiten sichtbar macht. Dadurch können Verantwortliche genauer festlegen, wer beteiligt werden muss und welche Services nach der Änderung zu prüfen sind.

Praxisbeispiel: Update einer Datenbank

Ein Administrator plant das Update einer produktiven Datenbank. Die Konfigurationsdaten zeigen, dass mehrere Anwendungen darauf zugreifen. Diese Anwendungen unterstützen unterschiedliche Geschäftsabläufe und haben jeweils eigene verantwortliche Teams.

Aus diesen Informationen lässt sich eine konkrete Vorbereitung ableiten: Die Teams prüfen Kompatibilität, stimmen einen geeigneten Termin ab und legen Tests fest. Außerdem braucht es Kriterien für Erfolg und Abbruch sowie einen praktisch durchführbaren Wiederherstellungsplan.

Die ITIL CMDB liefert dafür einen dokumentierten Ausgangspunkt. Sie ersetzt weder die technische Prüfung noch die risikogerechte Freigabe. Fehlen relevante Beziehungen, muss diese Unsicherheit in die Bewertung des Changes eingehen.

Nach dem Change müssen die Daten stimmen

Ein erfolgreicher Change verändert häufig Versionen, Zuständigkeiten oder Abhängigkeiten. Wird nur das Ticket geschlossen, während die Dokumentation unverändert bleibt, arbeitet der nächste Bearbeiter mit einem veralteten Zustand.

Nehmen Sie die Aktualisierung der betroffenen CIs deshalb in die Abschlusskriterien auf. Hierzu bieten sich Checklisten oder andere Prüfungsdokumente an. Technische Merkmale können über einen anschließenden Import oder eine Discovery aktualisiert werden. Fachliche Zuordnungen und Servicebeziehungen benötigen je nach Quelle eine gesonderte Prüfung.

Wie das Problem Management von Konfigurationsdaten profitiert

Wiederkehrende Incidents lassen sich besser untersuchen, wenn die betroffenen Tickets einheitlich mit CIs verknüpft sind. Das Team kann dann prüfen, ob sich bestimmte Komponenten, Versionen oder Standorte häufen.

Ein Beispiel: Mehrere Störungen betreffen unterschiedliche Anwendungen, die denselben Infrastrukturservice nutzen. Diese Gemeinsamkeit liefert einen Ansatzpunkt für die Ursachenanalyse. Sie beweist die Ursache noch nicht, hilft aber, auftretende Probleme gezielt einzugrenzen.

Eine ITIL CMDB unterstützt damit auch langfristige Verbesserungen. Voraussetzung ist, dass Tickets korrekt zugeordnet werden und die relevanten Zusammenhänge für den untersuchten Zeitraum nachvollziehbar bleiben.

Eine ITIL CMDB schrittweise einführen

Ein klar begrenzter Start erleichtert die Einführung. Wählen Sie einen wichtigen Service, für den es wiederkehrende Fragen im Support oder bei Änderungen gibt. An diesem Beispiel lässt sich überprüfen, ob das Datenmodell im Alltag funktioniert.

1. Den konkreten Anwendungsfall festlegen

Formulieren Sie ein prüfbares Ziel. Beispielsweise soll der Service Desk für einen ausgewählten Service die zuständigen Teams und unterstützenden Systeme ohne Rückfrage finden können. Daraus ergibt sich, welche Informationen die erste Ausbaustufe Ihrer ITIL CMDB bereitstellen muss.
Beziehen Sie die späteren Nutzer und Anwender früh ein. Ein Datenfeld, das niemand für eine Entscheidung benötigt, verursacht dennoch Pflegeaufwand. Ein fehlender Ansprechpartner dagegen kann die Bearbeitung unmittelbar verzögern.

2. Datenmodell und Quellen festlegen

Legen Sie CI-Typen, Pflichtfelder und Beziehungstypen fest. Definieren Sie außerdem, welche Quelle für welche Information maßgeblich ist. Ein Inventarisierungssystem kann technische Merkmale liefern; Serviceverantwortliche bestätigen die fachliche Zuordnung.

Nutzen Sie eindeutige Identifikatoren für den Abgleich. Hostnamen oder IP-Adressen allein sind je nach Umgebung nicht stabil genug. Regeln für Umbenennungen, Dubletten und ausgemusterte Systeme gehören deshalb von Anfang an in jedes Konzept.

3. Verantwortlichkeiten festlegen

Bestimmen Sie für jede relevante Datenklasse eine zuständige Rolle. Die Administration der Software und die inhaltliche Verantwortung für Konfigurationsdaten sind unterschiedliche Aufgaben. Ein Plattformadministrator kann nicht automatisch die fachliche Richtigkeit jeder Servicebeziehung beurteilen.

Halten Sie Umfang, Zuständigkeiten, Datenquellen und Kontrollregeln in einem Configuration-Management-Plan fest. So wird aus der technischen Installation ein nachvollziehbarer Betriebsprozess.

4. Daten importieren und anhand realer Fälle prüfen

Übernehmen Sie vorhandene Daten in Ihre CMDB. Prüfen Sie danach stichprobenartig Ansprechpartner, Pflichtfelder und Beziehungen. Ein fehlerfrei abgeschlossener Import bestätigt lediglich den technischen Ablauf, nicht die Qualität des Ergebnisses.

Testen Sie anschließend einen realistischen Incident-Fall und spielen Sie Changes mit den vorhandenen Daten durch. Können die Beteiligten die benötigten Fragen beantworten? Welche Informationen fehlen derzeit noch? Diese Rückmeldungen sind aussagekräftiger als die bloße Anzahl importierter Objekte.

5. Nutzung und Umfang gezielt ausbauen

Erweitern Sie die ITIL CMDB erst, wenn Pflege und Nutzung für den ersten Service funktionieren. Übertragen Sie bewährte Regeln auf weitere Services und passen Sie das Modell dort an, wo sich Anforderungen unterscheiden oder neue hinzukommen.

Wie sich die organisatorischen Abläufe dazu entwickeln lassen, erläutert unser Praxis-Guide zur Umsetzung von ITIL-Prozessen.

Datenqualität und Automatisierung dauerhaft sichern

Automatische Netzwerkinventarisierung reduzieren den manuellen Pflegeaufwand drastisch. Sie erfassen jedoch nur Informationen, die in den jeweiligen Quellen verfügbar und mit den vorhandenen Zugriffsrechten erreichbar sind. Ein Discovery-Lauf kennt nicht zwangsläufig den fachlichen Zweck einer Anwendung oder die vereinbarte Kritikalität eines Services.

Für zuverlässiges CMDB Configuration Management müssen technische Aktualisierung und fachliche Prüfung zusammenarbeiten. Eine Netzwerkinventarisierung erfasst z.B. das auf einer VM eine Anwendung installiert ist, kann aber nicht automatisch einordnen wie wichtig diese für Ihre Organisation und die Geschäftskritischen Prozesse ist. Legen Sie fest, welche Felder automatisch überschrieben werden dürfen und wie widersprüchliche Angaben behandelt werden. Dokumentieren Sie fehlgeschlagene Synchronisationen, damit ein ausgefallener Import nicht unbemerkt zu veralteten Daten führt.

Auch die ITIL CMDB selbst benötigt ein Berechtigungskonzept. Infrastrukturinformationen können sensibel sein. Beschränken Sie Schreibrechte auf zuständige Rollen und gewähren Sie Leserechte entsprechend dem tatsächlichen Bedarf. Zugangspasswörter gehören grundsätzlich in einen Passwort-Safe.

Sinnvolle Kennzahlen für die laufende Verbesserung

Bewerten Sie die Datenqualität innerhalb eines klar definierten Umfangs. Aussagekräftige Kennzahlen sind beispielsweise:

• Der Anteil produktiver CIs mit bestätigtem verantwortlichem Team.

• Der Anteil ausgewählter Services mit geprüften Abhängigkeiten.

• Der Anteil fristgerecht geprüfter Datensätze je CI-Typ.

• Die Zahl ungeklärter Dubletten und fehlgeschlagener Importe.

• Der Anteil relevanter Changes mit abgeschlossener Aktualisierung der Konfigurationsdaten.

Ergänzend können Sie messen, wie lange Teams zum Auffinden bestimmter Informationen brauchen. Eine Veränderung der Incident-Bearbeitungszeit lässt sich dagegen selten allein auf die CMDB zurückführen. Personalbesetzung, Störungsart und andere Prozessverbesserungen beeinflussen sie ebenfalls.

Häufige Fragen zur ITIL CMDB

Muss eine CMDB die gesamte IT vollständig erfassen?

Der benötigte Umfang hängt von Ihren Services und Anwendungsfällen ab. Eine abgegrenzte, verlässlich gepflegte Dokumentation ist ein sinnvoller Start. Entscheidend ist, dass Nutzer erkennen können, welche Bereiche erfasst sind und wo Informationen fehlen oder noch nicht geprüft wurden.

Ist eine ITIL CMDB automatisch ITIL-konform?

Der Begriff allein ist kein Nachweis für eine Zertifizierung oder die Qualität Ihrer Prozesse. Prüfen Sie die tatsächlich unterstützten Funktionen, Integrationen und Verantwortlichkeiten. Die Software muss zu Ihren Arbeitsabläufen passen, und die Daten müssen für den vorgesehenen Zweck zuverlässig sein.

Kann eine CMDB das Monitoring ersetzen?

Monitoring erfasst aktuelle Zustände und Ereignisse. Die CMDB dokumentiert Komponenten und ihre Zusammenhänge. Beide Informationsarten ergänzen sich: Ein Alarm meldet eine Störung, während Konfigurationsdaten dabei helfen, den betroffenen Service und die zuständigen Personen zu bestimmen. Eine CMDB ersetzt somit kein Monitoring sondern liefert tiefgreifende, häufig nicht technische Informationen.

Kann man mit einer ITIL CMDB bessere Entscheidungen treffen?

Der Wert einer ITIL CMDB zeigt sich in konkreten Situationen: Der Service Desk findet das zuständige Team, eine Änderung berücksichtigt abhängige Anwendungen und wiederkehrende Störungen lassen sich im Zusammenhang untersuchen. Dafür braucht es ein passendes Datenmodell, überprüfte Beziehungen und eine Pflege, die zum Tagesgeschäft gehört.

Starten Sie mit einem wichtigen Service und klaren Fragen, die Ihre Teams beantworten müssen. Prüfen Sie den Nutzen im Incident- und Change-Management und erweitern Sie den Umfang anhand dieser Erfahrungen.

Mit i-doit können Sie Configuration Items und ihre Beziehungen dokumentieren und diese Daten über passende Anbindungen in Ihre Serviceprozesse einbeziehen. Entdecken Sie die CMDB-Lösung von i-doit und prüfen Sie, wie sich Ihre Infrastruktur und Services damit abbilden lassen.

Testen Sie jetzt Software der i-doit group produktiv.

Die i-doit group ist der führende Softwarehersteller für IT-Dokumentation, CMDB, ITSM & Verkabelungsmanagement, sowie für ISMS, Notfallmanagement & Datenschutz. Über 2.000 aktive Kunden vertrauen uns für ihre digitale Resilienz.

30 Tage kostenlos testen!