6.3 Configuration Management Database

Kurz erklärt

Eine Configuration Management Database (CMDB) ist ein Datenbestand oder Werkzeug, in dem Configuration Items und ihre Beziehungen verwaltet werden.

Sie hilft dabei, Services, Systeme, Komponenten, Versionen, Verantwortlichkeiten und Abhängigkeiten nachvollziehbar zu dokumentieren.

Der Wert einer CMDB entsteht nicht durch möglichst viele Einträge, sondern durch aktuelle, verlässliche und nutzbare Informationen für Incident, Problem, Change, Release und Security Management.

Warum eine CMDB wichtig ist

IT-Services bestehen aus vielen abhängigen Bestandteilen.

Ohne zentrale oder verlässliche Configuration-Daten entstehen typische Probleme:

niemand weiß genau, welcher Service betroffen ist,
Changes werden mit unvollständiger Auswirkungsbewertung durchgeführt,
Incidents werden langsamer analysiert,
Problems werden nicht richtig eingegrenzt,
veraltete Systeme bleiben unentdeckt,
Zertifikate laufen ab,
Abhängigkeiten zu Lieferanten fehlen,
Dokumentation widerspricht der Realität,
und Verantwortlichkeiten bleiben unklar.

Eine CMDB soll diese Informationen strukturiert nutzbar machen.

Was eine CMDB leisten soll

Eine CMDB soll helfen zu beantworten:

Welche Services gibt es?
Welche Configuration Items gehören dazu?
Welche Systeme sind produktiv?
Welche Versionen sind im Einsatz?
Welche Komponenten hängen voneinander ab?
Welche Changes wurden zuletzt durchgeführt?
Welche Incidents betreffen ein CI?
Welche Problems oder Known Errors sind verknüpft?
Wer ist verantwortlich?
Welche Lieferanten sind beteiligt?
Welche Dokumentation gehört dazu?
Welche Risiken bestehen?

Damit unterstützt die CMDB nicht nur Dokumentation, sondern tägliche Betriebsentscheidungen.

CMDB ist kein Selbstzweck

Eine CMDB ist nur sinnvoll, wenn sie genutzt wird.

Ungeeignet:

Wir erfassen alles, weil eine CMDB vollständig sein muss.

Besser:

Wir erfassen die Informationen, die für Servicebetrieb, Support, Changes, Risiken und Entscheidungen wirklich benötigt werden.

Eine zu große, ungepflegte CMDB wird schnell unübersichtlich und unzuverlässig.

Eine kleine, gut gepflegte CMDB kann deutlich nützlicher sein.

CMDB und Configuration Management System

Eine CMDB ist ein Datenbestand für Configuration Items und Beziehungen.

Ein Configuration Management System (CMS) kann breiter sein.

Ein CMS kann mehrere Quellen verbinden, zum Beispiel:

CMDB,
Asset Management,
Monitoring,
Cloud-Inventar,
Endpoint Management,
Netzwerkdokumentation,
Softwareverteilung,
Virtualisierungsplattform,
Dokumentationssystem,
ITSM-Tool,
Security-Werkzeuge.

Die CMDB kann also Teil eines größeren Configuration Management Systems sein.

CMDB und Inventarliste unterscheiden

Inventarliste	CMDB
zeigt häufig nur vorhandene Geräte oder Assets	zeigt Configuration Items und Servicebeziehungen
Fokus auf Bestand	Fokus auf Betrieb, Abhängigkeiten und Wirkung
Beispiel: Server existiert	Beispiel: Server betreibt Service X und nutzt Datenbank Y
wichtig für Übersicht	wichtig für Incident, Problem, Change und Risiko
oft objektbezogen	service- und beziehungsbezogen

Eine Inventarliste beantwortet:

Was haben wir?

Eine CMDB beantwortet zusätzlich:

Wofür wird es genutzt und wovon hängt es ab?

Typische Inhalte einer CMDB

Eine CMDB kann enthalten:

Configuration Items,
CI-Typen,
CI-Status,
Servicezuordnung,
Versionen,
Umgebungen,
Standorte,
Owner,
Supportgruppen,
Lieferanten,
Kritikalität,
Sicherheitsklassifizierung,
Beziehungen,
Dokumentationslinks,
verknüpfte Incidents,
verknüpfte Problems,
verknüpfte Changes,
verknüpfte Releases,
letzte Prüfung,
letzte Änderung.

Nicht jede CMDB benötigt alle Felder.

Die Felder müssen zum Zweck und Pflegeaufwand passen.

Beispiel für einen CMDB-Eintrag

Feld	Beispiel
CI-Name	PRD-APP-PORTAL-01
CI-Typ	Server
Status	aktiv
Umgebung	Produktion
Service	Mitarbeiterportal
Owner	Plattform-Team
Supportgruppe	Application Support
Version	Linux Server Version X
Standort	Rechenzentrum Berlin
Kritikalität	hoch
Lieferant	interner Betrieb
Dokumentation	Betriebsrunbook Mitarbeiterportal
Beziehungen	läuft Portal-App, nutzt Datenbank PRD-DB-PORTAL-01
letzte Prüfung	02.08.2026

Dieses Beispiel ist bewusst einfach gehalten.

Die tatsächlichen Felder hängen von Organisation und Werkzeug ab.

Wichtige CI-Typen in einer CMDB

Mögliche CI-Typen:

Business Service,
Technical Service,
Anwendung,
Server,
Datenbank,
Netzwerkgerät,
Firewall,
Cloud-Ressource,
Zertifikat,
DNS-Eintrag,
Benutzergruppe,
Schnittstelle,
Monitoringregel,
Backupjob,
Dokumentation,
Lieferantenvertrag,
Arbeitsplatzgerät,
Drucker.

Wichtig ist eine klare interne Definition.

Wenn Teams CI-Typen unterschiedlich verwenden, werden Auswertungen ungenau.

Service als zentrales Element

Eine CMDB sollte nicht nur technische Komponenten sammeln.

Wichtig ist die Verbindung zum Service.

Beispiel:

Mitarbeiterportal
    ↓ nutzt
Portal-Anwendung
    ↓ läuft auf
PRD-APP-PORTAL-01
    ↓ nutzt
PRD-DB-PORTAL-01
    ↓ nutzt
PRD-STO-01

Zusätzlich:

Zertifikat,
DNS,
Identity Provider,
Monitoring,
Backup,
Supportgruppe,
Service Owner.

Erst diese Serviceperspektive macht die CMDB im Betrieb wertvoll.

Beziehungen in der CMDB

Beziehungen sind einer der wichtigsten Bestandteile einer CMDB.

Typische Beziehungen:

Service nutzt Anwendung,
Anwendung läuft auf Server,
Anwendung nutzt Datenbank,
Server nutzt Storage,
Service nutzt Zertifikat,
Anwendung kommuniziert mit Schnittstelle,
Standort nutzt Firewall,
Monitoring überwacht CI,
Backupjob sichert Datenbank,
Lieferant unterstützt Komponente.

Ohne Beziehungen ist eine CMDB oft nur eine Inventarliste.

Beispiel: Beziehungskette

Benutzer
    ↓
Mitarbeiterportal
    ↓
Webserver
    ↓
Anwendung
    ↓
Datenbank
    ↓
Storage

Weitere Abhängigkeiten:

DNS,
Zertifikat,
Identity Provider,
MFA,
Firewall,
Monitoring,
Backup,
Lieferant.

Wenn eine Komponente ausfällt, hilft die CMDB zu erkennen, welche Services betroffen sein können.

CMDB und Incident Management

Bei Incidents hilft eine CMDB durch:

schnelle Erkennung betroffener Services,
Zuordnung zu verantwortlichen Teams,
Sicht auf Abhängigkeiten,
Anzeige letzter Changes,
Verknüpfung zu Known Errors,
Priorisierung nach Kritikalität,
bessere Eskalation,
schnellere Kommunikation.

Beispiel:

Ein Benutzer meldet, dass das Mitarbeiterportal nicht erreichbar ist.

Die CMDB zeigt:

Portal läuft auf PRD-APP-PORTAL-01,
nutzt PRD-DB-PORTAL-01,
ist abhängig vom Identity Provider,
letzter Change betraf das Zertifikat.

Dadurch kann die Diagnose gezielter beginnen.

CMDB und Problem Management

Problem Management nutzt CMDB-Daten, um gemeinsame Ursachen zu erkennen.

Beispiele:

mehrere Incidents betreffen dieselbe Version,
mehrere Services hängen vom gleichen Datenbankcluster ab,
viele Probleme treten an einem Standort auf,
mehrere Anwendungen nutzen dasselbe Zertifikat,
wiederkehrende Störungen betreffen denselben Lieferanten.

Ohne CMDB-Beziehungen werden solche Muster oft erst spät sichtbar.

CMDB und Change Enablement

Change Enablement benötigt CMDB-Daten für die Auswirkungsbewertung.

Zu prüfen ist:

Welche CIs werden geändert?
Welche Services hängen davon ab?
Welche Benutzer oder Standorte sind betroffen?
Welche Owner müssen einbezogen werden?
Welche anderen Changes betreffen dieselben CIs?
Welche Dokumentation muss aktualisiert werden?
Welche Tests sind notwendig?
Welche Risiken entstehen?

Ein Change ohne CMDB-Prüfung kann unerwartete Auswirkungen verursachen.

CMDB und Release Management

Release und Deployment benötigen verlässliche Informationen über:

Zielumgebungen,
betroffene Komponenten,
Versionen,
Abhängigkeiten,
Schnittstellen,
Konfigurationen,
Rollback-Zustände,
Monitoring,
Dokumentation.

Nach einem Release müssen CMDB-Daten aktualisiert werden.

Sonst zeigt die CMDB einen veralteten Zustand.

CMDB und Information Security Management

Eine CMDB unterstützt Sicherheitsarbeit durch Informationen über:

kritische Systeme,
externe Erreichbarkeit,
veraltete Versionen,
Zertifikate,
Datenklassifizierung,
privilegierte Systeme,
Schnittstellen,
Lieferanten,
Cloud-Ressourcen,
betroffene Services bei Schwachstellen.

Beispiel:

Eine Sicherheitslücke betrifft eine bestimmte Softwareversion.

Mit CMDB-Daten kann schneller erkannt werden, welche Systeme und Services betroffen sind.

CMDB und Service Level Management

Service Level Management kann CMDB-Daten nutzen, um zu verstehen:

welche Komponenten kritische Services unterstützen,
welche Abhängigkeiten Service Levels gefährden,
welche Lieferanten beteiligt sind,
welche CIs besonders hohe Verfügbarkeit benötigen,
welche Changes Service Levels beeinflussen können.

Ein Service Level ist schwer zu steuern, wenn die technischen Abhängigkeiten unbekannt sind.

CMDB-Datenquellen

Mögliche Datenquellen für eine CMDB:

manuelle Pflege,
Discovery-Werkzeuge,
Monitoring,
Asset Management,
Endpoint Management,
Cloud-Plattformen,
Virtualisierungsplattformen,
Netzwerkmanagement,
Softwareverteilung,
ITSM-Tickets,
Change Records,
Lieferanteninformationen,
Dokumentationssysteme.

Keine einzelne Datenquelle ist automatisch vollständig.

Die CMDB muss aus passenden Quellen aufgebaut und geprüft werden.

Automatische Discovery

Discovery kann technische Informationen automatisch erfassen.

Beispiele:

Server,
IP-Adressen,
installierte Software,
Betriebssystemversionen,
Cloud-Ressourcen,
Zertifikate,
offene Dienste,
Netzwerkgeräte,
virtuelle Maschinen,
Container,
Datenbankinstanzen.

Discovery ist hilfreich für Aktualität.

Aber Discovery erkennt nicht immer:

fachliche Kritikalität,
Service Owner,
Geschäftsprozessbezug,
Risikoakzeptanz,
Dokumentationsqualität,
geplante Ablösung,
oder organisatorische Verantwortung.

Manuelle Pflege

Manuelle Pflege bleibt wichtig für Informationen wie:

Service Owner,
fachliche Kritikalität,
Supportmodell,
Lieferantenverantwortung,
Sicherheitsklassifizierung,
Geschäftsprozessbezug,
Runbook-Link,
Notfallinformationen,
Risikoakzeptanz,
geplante Außerbetriebnahme.

Diese Informationen benötigen Verantwortliche.

Ohne klare Pflegeverantwortung veralten sie schnell.

Datenqualität in der CMDB

Eine CMDB ist nur so gut wie ihre Datenqualität.

Wichtige Qualitätskriterien:

Vollständigkeit,
Aktualität,
Eindeutigkeit,
Richtigkeit,
Konsistenz,
Nachvollziehbarkeit,
Nutzbarkeit,
Verantwortlichkeit.

Schlechte Daten können gefährlich sein.

Sie führen zu falschen Entscheidungen, weil Teams der CMDB vertrauen, obwohl sie veraltet ist.

Typische Datenqualitätsprobleme

Problem	Folge
doppelte CIs	Incidents und Changes werden falsch verknüpft
veraltete Owner	Eskalation dauert länger
fehlende Beziehungen	Auswirkung wird unterschätzt
falscher Status	außer Betrieb genommene Systeme erscheinen aktiv
fehlende Versionen	Sicherheitsbewertung wird ungenau
fehlende Servicezuordnung	Priorisierung wird schwieriger
falsche Umgebung	Test und Produktion werden verwechselt
fehlende Dokumentationslinks	Betrieb dauert länger

Dubletten vermeiden

Dubletten entstehen, wenn dasselbe CI mehrfach erfasst wird.

Beispiele:

APP-01,
app01,
Portal Server,
PRD-APP-PORTAL-01.

Folgen:

Beziehungen verteilen sich auf mehrere Einträge,
Reports werden falsch,
Changes erscheinen unvollständig,
Incidents werden nicht richtig gebündelt,
Owner widersprechen sich.

Gegenmaßnahmen:

Namenskonvention,
eindeutige IDs,
Dublettenprüfung,
klare Erfassungsregeln,
regelmäßige Datenbereinigung.

Namenskonventionen

Eine gute Namenskonvention unterstützt Eindeutigkeit.

Mögliche Bestandteile:

Umgebung,
Standort,
Funktion,
Servicebezug,
laufende Nummer.

Beispiele:

PRD-APP-PORTAL-01,
TST-DB-ERP-02,
BER-FW-STANDORT-01,
PRD-CERT-PORTAL-2026.

Die Namenskonvention sollte einfach genug sein, damit sie konsequent genutzt wird.

Pflichtfelder und optionale Felder

Nicht jedes Feld sollte verpflichtend sein.

Zu viele Pflichtfelder führen dazu, dass Benutzer falsche Werte eintragen, nur um den Datensatz speichern zu können.

Sinnvolle Pflichtfelder können sein:

CI-Name,
CI-Typ,
Status,
Umgebung,
Owner oder Supportgruppe,
Servicezuordnung bei produktiven CIs.

Optionale Felder können abhängig vom CI-Typ sein.

Beispiel:

Ein Zertifikat benötigt Ablaufdatum.

Ein Drucker benötigt Standort.

Eine Anwendung benötigt Version und Service Owner.

CMDB-Modell

Das CMDB-Modell beschreibt, welche CI-Typen, Attribute und Beziehungen verwendet werden.

Zu klären ist:

Welche CI-Typen gibt es?
Welche Attribute sind notwendig?
Welche Beziehungen sind erlaubt?
Welche Felder sind Pflicht?
Welche Datenquellen werden genutzt?
Wer darf CIs erstellen?
Wer darf CIs ändern?
Wie werden Dubletten verhindert?
Wie wird Qualität geprüft?

Ein einfaches, verstandenes Modell ist besser als ein komplexes Modell, das niemand pflegt.

Granularität

Granularität beschreibt, wie detailliert CIs erfasst werden.

Beispiel:

Sehr grob:

Service: Mitarbeiterportal

Mittel:

Service,
Anwendung,
Webserver,
Datenbank,
Zertifikat.

Sehr fein:

einzelne Konfigurationsdateien,
einzelne Firewall-Regeln,
einzelne Bibliotheken,
einzelne Schnittstellenparameter.

Die richtige Granularität hängt vom Nutzen ab.

Zu grob hilft bei technischer Analyse wenig.

Zu fein ist schwer pflegbar.

Beispiel für passende Granularität

Für einen kritischen Webservice sinnvoll:

Service,
Anwendung,
Datenbank,
Server,
Load Balancer,
Zertifikat,
DNS,
Identity Provider,
Monitoring,
Backup,
wichtige Schnittstellen.

Nicht immer sinnvoll:

jede einzelne Konfigurationszeile,
jede temporäre Datei,
jedes unkritische Testobjekt.

Die CMDB soll Entscheidungen unterstützen, nicht jede technische Kleinigkeit abbilden.

CMDB-Lebenszyklus

Ein CI durchläuft einen Lebenszyklus.

geplant
    ↓
erstellt oder beschafft
    ↓
in Betrieb genommen
    ↓
geändert
    ↓
regelmäßig geprüft
    ↓
außer Betrieb genommen
    ↓
archiviert oder gelöscht

Die CMDB sollte diesen Lebenszyklus abbilden.

Besonders wichtig ist die saubere Außerbetriebnahme.

Außerbetriebnahme von CIs

Vor dem Entfernen eines CIs sollte geprüft werden:

Welche Services nutzen das CI?
Gibt es noch aktive Beziehungen?
Gibt es offene Incidents oder Problems?
Gibt es geplante Changes?
Wird das CI noch überwacht?
Gibt es Backups oder Archivdaten?
Gibt es Lizenz- oder Vertragsbezug?
Muss Dokumentation angepasst werden?
Muss ein Lieferant informiert werden?

Ein CI einfach zu löschen kann spätere Nachvollziehbarkeit zerstören.

Oft ist Archivierung sinnvoller.

CMDB und Change-Prozess

Changes sollten CMDB-Daten aktualisieren.

Beispiele:

neue Version nach Update,
neue Beziehung nach Schnittstellenänderung,
neues Zertifikat nach Erneuerung,
neuer Owner nach Übergabe,
neuer Status nach Außerbetriebnahme,
neue Cloud-Ressource nach Deployment,
neue Monitoringbeziehung nach Alarmregel.

Wenn Changes die CMDB nicht aktualisieren, veraltet sie automatisch.

CMDB und Dokumentation

Die CMDB ersetzt nicht jede Dokumentation.

Sie kann aber auf Dokumentation verweisen.

Beispiele:

Betriebsrunbook,
Architekturdiagramm,
Notfallhandbuch,
Installationsanleitung,
Schnittstellendokumentation,
Lieferantenvertrag,
Sicherheitskonzept,
Backup- und Restore-Anleitung.

Die CMDB zeigt, welche Dokumentation zu welchem CI oder Service gehört.

CMDB und Monitoring

Monitoring und CMDB sollten sich ergänzen.

Monitoring zeigt:

Zustand,
Alarme,
Verfügbarkeit,
Performance,
Kapazität,
Fehlerereignisse.

CMDB zeigt:

Servicezuordnung,
Kritikalität,
Owner,
Beziehungen,
Version,
Dokumentation.

Beispiel:

Monitoring meldet Ausfall eines Servers.

Die CMDB zeigt, welche Services davon abhängen und wer informiert werden muss.

CMDB und Cloud

Cloud-Umgebungen verändern sich oft schnell.

Herausforderungen:

Ressourcen entstehen automatisch,
Ressourcen werden schnell gelöscht,
Namen sind uneinheitlich,
Tags fehlen,
Owner sind unklar,
Kostenstellen fehlen,
Beziehungen sind dynamisch,
externe Dienste sind beteiligt.

Für Cloud-Ressourcen sind klare Tags, automatisierte Erkennung und regelmäßige Prüfung besonders wichtig.

CMDB und Tags

Tags oder Labels können helfen, Cloud- und Plattformressourcen zuzuordnen.

Mögliche Tags:

Service,
Umgebung,
Owner,
Kostenstelle,
Kritikalität,
Datenklasse,
Ablaufdatum,
Projekt,
Supportgruppe.

Beispiel:

Tag	Wert
Service	Mitarbeiterportal
Umgebung	Produktion
Owner	Plattform-Team
Kritikalität	hoch
Datenklasse	intern

Tags ersetzen keine vollständige CMDB, können aber wichtige Daten liefern.

CMDB und Container

Auch Container-Umgebungen können CMDB-relevant sein.

Mögliche CIs:

Container-Plattform,
Cluster,
Namespace,
Anwendung,
Image-Version,
Datenbank,
Volume,
Ingress,
Secret,
Zertifikat,
Monitoring,
Backupjob.

Wichtig ist, nicht jeden kurzlebigen Container einzeln dauerhaft zu pflegen.

Oft sind Service, Anwendung, Plattform, Version und Abhängigkeiten wichtiger als einzelne temporäre Instanzen.

CMDB und Schnittstellen

Schnittstellen werden oft vergessen.

Dabei sind sie für Services kritisch.

Zu erfassen sind:

Quellsystem,
Zielsystem,
Protokoll,
Authentifizierung,
Zertifikat,
Datenformat,
Owner,
Lieferant,
Kritikalität,
Monitoring,
bekannte Fehler,
Abhängigkeiten.

Ein Schnittstellenfehler kann mehrere Services gleichzeitig betreffen.

CMDB und Zertifikate

Zertifikate sollten bei wichtigen Services als relevante CIs betrachtet werden.

Sinnvolle Informationen:

Name,
betroffener Service,
Hostname,
Ablaufdatum,
Aussteller,
Owner,
Erneuerungsprozess,
Monitoring,
abhängige Systeme,
Dokumentationslink.

Viele vermeidbare Incidents entstehen durch abgelaufene oder falsch erneuerte Zertifikate.

Berechtigungen und Gruppen als CIs

Auch Benutzergruppen oder Berechtigungskonzepte können CI-relevant sein.

Beispiele:

Administratorgruppe,
Rollen für Fachanwendung,
VPN-Zugriffsgruppe,
MFA-Ausnahmegruppe,
Servicekonto,
API-Berechtigung.

Solche CIs sind besonders wichtig für:

Sicherheit,
Change Enablement,
Audits,
Incident-Diagnose,
Berechtigungsprobleme,
und Compliance.

CMDB-Reports

Nützliche Reports können sein:

aktive produktive Services,
Services ohne Owner,
CIs ohne Servicezuordnung,
CIs ohne aktuelle Prüfung,
ablaufende Zertifikate,
veraltete Versionen,
kritische CIs ohne Monitoring,
Changes pro CI,
Incidents pro CI,
Known Errors pro Service,
CIs mit fehlenden Beziehungen.

Reports sollen nicht nur Zahlen liefern.

Sie sollen konkrete Verbesserungen ermöglichen.

CMDB-Einführung schrittweise beginnen

Eine CMDB sollte nicht zwingend sofort alles abbilden.

Sinnvoller Start:

kritische Services auswählen
wichtigste CIs erfassen
zentrale Beziehungen dokumentieren
Owner festlegen
Change-Prozess anbinden
Datenqualität prüfen
Nutzung in Incident und Change etablieren
schrittweise erweitern

Eine CMDB scheitert häufig, wenn zu Beginn zu viel auf einmal erfasst werden soll.

Minimal sinnvolle CMDB für kleine Umgebungen

Für kleine Umgebungen kann auch eine einfache Struktur ausreichen.

Mögliche Mindestinformationen:

Service,
wichtige Komponenten,
Owner,
Umgebung,
Status,
Version,
wichtigste Abhängigkeiten,
Dokumentationslink,
letzter Change,
letzte Prüfung.

Das kann auch in einem einfachen ITSM-Tool, Wiki oder einer strukturierten Tabelle beginnen.

Wichtig ist Pflege und Nutzung.

Governance der CMDB

CMDB-Governance legt Regeln fest.

Zu klären ist:

Wer ist für das CMDB-Modell verantwortlich?
Wer darf CIs erstellen?
Wer darf CIs ändern?
Wer prüft Datenqualität?
Welche Felder sind Pflicht?
Wie werden Dubletten behandelt?
Wie werden Changes eingebunden?
Wie oft werden kritische CIs geprüft?
Welche Reports werden genutzt?
Wie werden Fehler korrigiert?

Ohne Governance wird eine CMDB schnell unzuverlässig.

Rollen im CMDB-Betrieb

Mögliche Rollen:

Rolle	Aufgabe
Configuration Manager	steuert Modell, Qualität und Regeln
Service Owner	verantwortet Serviceinformationen
CI Owner	verantwortet einzelne CIs
Supportgruppe	nutzt und ergänzt Betriebsinformationen
Change Manager	sorgt für Aktualisierung nach Changes
Security Team	nutzt Daten für Sicherheitsbewertung
Asset Manager	liefert Asset- und Vertragsdaten

Die Rollen müssen nicht überall als eigene Stellen existieren.

Die Verantwortlichkeiten müssen aber klar sein.

Praxisbeispiel: Incident mit CMDB-Nutzen

Situation

Mehrere Benutzer melden, dass das Mitarbeiterportal nicht erreichbar ist.

CMDB hilft durch:

Servicezuordnung,
betroffene Anwendung,
Datenbankbeziehung,
Zertifikatsbeziehung,
letzter Change,
zuständige Supportgruppe,
Kritikalität des Services.

Ergebnis

Die Analyse konzentriert sich schneller auf Datenbank, Zertifikat und letzten Change.

Praxisbeispiel: Change mit CMDB-Nutzen

Situation

Ein Datenbankserver soll aktualisiert werden.

CMDB zeigt:

drei Anwendungen nutzen diesen Server,
eine Anwendung ist geschäftskritisch,
ein Lieferant muss für Test erreichbar sein,
Backupjob muss vor dem Change geprüft werden,
Service Desk muss informiert werden.

Ergebnis

Der Change wird nicht als isoliertes Serverupdate behandelt, sondern als Serviceänderung mit Abhängigkeiten.

Praxisbeispiel: Sicherheitslücke

Situation

Eine kritische Schwachstelle betrifft eine bestimmte Softwareversion.

CMDB hilft durch:

Liste betroffener Systeme,
Servicezuordnung,
Kritikalität,
Owner,
Umgebung,
externe Erreichbarkeit,
Patchstatus,
Changes zur Behebung.

Ergebnis

Patchpriorisierung wird schneller und nachvollziehbarer.

Praxisbeispiel: Abgelaufenes Zertifikat verhindern

Situation

Mehrere Zertifikate wurden bisher nur in einzelnen Runbooks erwähnt.

Problem

Ablaufdaten wurden nicht zentral überwacht.

Verbesserung

Zertifikate werden als CIs erfasst mit:

Ablaufdatum,
Servicebezug,
Owner,
Monitoring,
Erneuerungsprozess,
Dokumentationslink.

Nutzen

Ausfälle durch abgelaufene Zertifikate werden besser vermeidbar.

Typische Fehler

Fehler 1

CMDB wird als reine Inventarliste aufgebaut.

Fehler 2

Zu viele CIs werden erfasst, aber nicht gepflegt.

Fehler 3

Services und Beziehungen fehlen.

Fehler 4

Owner sind nicht definiert.

Fehler 5

Daten werden nicht durch Changes aktualisiert.

Fehler 6

Discovery-Daten werden ungeprüft übernommen.

Fehler 7

Dubletten und uneinheitliche Namen werden nicht bereinigt.

Fehler 8

CMDB wird im Incident- und Change-Prozess nicht genutzt.

Fehler 9

Kritikalität wird technisch statt servicebezogen bewertet.

Fehler 10

Cloud-Ressourcen, Zertifikate und Schnittstellen fehlen.

Fehler 11

Reports zeigen Probleme, aber niemand verfolgt Verbesserungen.

Fehler 12

CMDB-Ziel und Pflegeaufwand passen nicht zusammen.

Checkliste CMDB-Modell

Checkliste CMDB-Eintrag

Checkliste Datenqualität

Checkliste CMDB im Change nutzen

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker nutzen und pflegen CMDB-Daten im praktischen Betrieb.

Wichtig ist:

Systeme eindeutig benennen,
produktive und nicht produktive Umgebungen unterscheiden,
Versionen und Konfigurationen sauber dokumentieren,
Abhängigkeiten erkennen,
Owner und Supportgruppen eintragen,
Changes mit CIs verknüpfen,
veraltete Daten melden,
und CMDB-Daten bei Incidents, Problems und Changes aktiv nutzen.

Eine gute CMDB macht technische Arbeit nicht bürokratischer.

Sie macht sie nachvollziehbarer, sicherer und schneller.

Zusammenfassung

Ziel der CMDB festlegen
↓
relevante Services und CI-Typen bestimmen
↓
Attribute und Beziehungen definieren
↓
Datenquellen anbinden
↓
Owner und Pflegeverantwortung klären
↓
CIs und Beziehungen erfassen
↓
CMDB in Incident, Problem und Change nutzen
↓
Datenqualität regelmäßig prüfen
↓
CMDB schrittweise verbessern

Merksätze

Eine CMDB ist nur wertvoll, wenn ihre Daten genutzt und gepflegt werden.

Beziehungen sind wichtiger als eine lange Liste einzelner Systeme.

Eine CMDB ersetzt keine Betriebsdokumentation, sie verknüpft relevante Informationen.

Discovery hilft bei Technik, ersetzt aber keine fachliche Verantwortung.

Jede relevante Änderung sollte auch die CMDB aktualisieren.

Schlechte CMDB-Daten können zu falschen Entscheidungen führen.

Klein anfangen und konsequent pflegen ist besser als groß planen und nicht aktuell halten.

Verwandte Seiten

6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen
6.2 Configuration Items und Beziehungen
6.4 Discovery, Pflege und Datenqualität
6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management
Incident Management
Problem Management
Change Enablement
Release Management
Information Security Management
IT Asset Management

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert – ITIL Practice Guide: Service Configuration Management
PeopleCert – ITIL Practice Guide: IT Asset Management
PeopleCert – ITIL Practice Guide: Change Enablement
PeopleCert – ITIL Practice Guide: Incident Management
PeopleCert – ITIL Practice Guide: Problem Management
ITIL Foundation – Version 5

Einordnung

Die dargestellten:

CMDB-Inhalte,
Feldbeispiele,
Datenqualitätsregeln,
Rollen,
Checklisten,
Reports,
und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

CMDB-Struktur,
Pflichtfeldliste,
CI-Typenliste,
Beziehungsmatrix,
Namenskonvention,
Discovery-Pflicht,
oder konkrete Toolarchitektur

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

Services,
Risiken,
Organisationsgröße,
Toollandschaft,
Datenqualität,
Supportmodell,
Sicherheitsanforderungen,
Change-Modell,
Cloud-Nutzung,
und verfügbare Fähigkeiten

angepasst werden.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026

Revision #1
Created 2 August 2026 15:54:11 by Admin
Updated 2 August 2026 15:54:23 by Admin