6. Service Configuration Management

6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen

Kurz erklärt

Service Configuration Management sorgt dafür, dass wichtige Informationen über Services, Systeme, Komponenten und deren Beziehungen nachvollziehbar gepflegt werden.

Ziel ist, zu wissen:

Dadurch können Incidents, Problems, Changes und Releases besser bewertet und gesteuert werden.

Warum Service Configuration Management wichtig ist

IT-Services bestehen selten aus nur einer einzelnen Komponente.

Ein scheinbar einfacher Service kann abhängig sein von:

Wenn diese Zusammenhänge unbekannt sind, entstehen Risiken:

Service Configuration Management schafft dafür eine nachvollziehbare Informationsbasis.

Was ist eine Configuration?

Eine Configuration beschreibt, wie ein Service oder System aufgebaut ist.

Dazu gehören beispielsweise:

Beispiel:

Der Service „VPN-Zugang“ besteht nicht nur aus dem VPN-Gateway.

Er kann abhängig sein von:

Configuration Item

Ein Configuration Item (CI) ist ein Bestandteil, der für die Bereitstellung oder Verwaltung eines Service relevant ist.

Beispiele:

Nicht jedes technische Objekt muss automatisch ein CI sein.

Die Organisation muss festlegen, welche Elemente wichtig genug sind, um verwaltet zu werden.

Beispiele für Configuration Items

CI-Typ Beispiel
Service Mitarbeiterportal
Anwendung Warenwirtschaft
Server APP-WEB-01
Datenbank SQL-Cluster Produktion
Netzwerk Standort-Firewall
Cloud Azure App Service
Sicherheit TLS-Zertifikat
Identität Entra-ID-Gruppe
Dokumentation Betriebsrunbook
Lieferant Supportvertrag Provider
Arbeitsplatz Notebook
Peripherie Etikettendrucker

Welche CI-Typen sinnvoll sind, hängt von Organisation, Services und Steuerungsbedarf ab.

Ziel von Service Configuration Management

Service Configuration Management soll sicherstellen, dass verlässliche Informationen verfügbar sind über:

Diese Informationen unterstützen andere ITIL Practices.

Beispiele:

Service Configuration Management ist mehr als Inventarisierung

Inventarisierung beantwortet oft nur:

Was ist vorhanden?

Service Configuration Management beantwortet zusätzlich:

Wie hängt es zusammen und warum ist es für den Service wichtig?

Beispiel:

Eine Inventarliste zeigt:

Service Configuration Management zeigt zusätzlich:

Diese Beziehungen machen die Informationen im Betrieb wertvoll.

CI-Beziehungen

Beziehungen zwischen CIs sind besonders wichtig.

Typische Beziehungen:

Beziehungen helfen zu verstehen, welche Auswirkungen ein Ausfall oder Change haben kann.

Beispiel: Serviceabhängigkeiten

Benutzer
    ↓
Mitarbeiterportal
    ↓
Webserver
    ↓
Anwendungsdienst
    ↓
Datenbank
    ↓
Storage

Zusätzlich abhängig von:

Wenn die Datenbank ausfällt, ist das Mitarbeiterportal betroffen.

Wenn das Zertifikat abläuft, kann die Anmeldung scheitern.

Wenn DNS fehlerhaft ist, erscheint der Service möglicherweise komplett unerreichbar.

CMDB

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

Eine CMDB kann enthalten:

Eine CMDB muss nicht zwingend ein einzelnes großes Werkzeug sein.

Wichtig ist, dass die benötigten Informationen zuverlässig verfügbar und gepflegt sind.

CMDB und CMS unterscheiden

Der Begriff Configuration Management System (CMS) kann breiter verstanden werden als eine einzelne CMDB.

Ein CMS kann mehrere Datenquellen verbinden.

Beispiele:

Die CMDB kann ein Teil dieses größeren Systems sein.

Configuration Management und Asset Management unterscheiden

Configuration Management Asset Management
Fokus auf Servicebeziehungen und Betriebsrelevanz Fokus auf Besitz, Kosten, Lebenszyklus und Vertragsdaten
betrachtet CIs und Abhängigkeiten betrachtet Assets als wirtschaftliche oder verwaltete Objekte
wichtig für Incident, Problem und Change wichtig für Einkauf, Lizenzierung und Lifecycle
Beispiel: Datenbank ist abhängig von Storage Beispiel: Server wurde am 12.03.2025 gekauft

Ein Objekt kann gleichzeitig Asset und CI sein.

Beispiel:

Ein produktiver Server ist wirtschaftlich ein Asset und betrieblich ein CI.

Welche Informationen sind sinnvoll?

Nicht jedes Detail muss erfasst werden.

Sinnvolle CI-Informationen können sein:

Zu viele ungenutzte Felder machen Pflege schwer.

Zu wenige Informationen machen die Daten im Betrieb wertlos.

CI-Status

Ein CI kann unterschiedliche Status besitzen.

Beispiele:

Der Status hilft zu erkennen, ob ein CI produktiv genutzt wird oder nicht.

Beispiel:

Ein alter Server darf nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen, wenn er bereits außer Betrieb genommen wurde.

Umgebungen kennzeichnen

CIs sollten ihrer Umgebung zugeordnet werden.

Beispiele:

Das ist wichtig, weil ein Change an einem Testsystem anders bewertet wird als ein Change an einem produktiven System.

Unklare Umgebungskennzeichnung kann zu gefährlichen Verwechslungen führen.

Kritikalität erfassen

Die Kritikalität beschreibt, wie wichtig ein CI oder Service für die Organisation ist.

Beispiele:

Die Kritikalität hilft bei:

Wichtig:

Die Kritikalität eines CIs sollte aus der Servicebedeutung abgeleitet werden.

Owner und Verantwortlichkeiten

Für wichtige CIs sollte klar sein:

Ohne Owner veralten Informationen schnell.

Ungeeignet:

Niemand fühlt sich für das System verantwortlich.

Besser:

Service Owner, technischer Owner und Supportgruppe sind dokumentiert.

Service Owner und CI Owner unterscheiden

Rolle Bedeutung
Service Owner Verantwortung für den gesamten Service und dessen Wertbeitrag
CI Owner Verantwortung für ein bestimmtes Configuration Item
Supportgruppe bearbeitet Incidents, Changes oder Betriebsaufgaben
Lieferant unterstützt oder betreibt bestimmte Komponenten

Ein Service kann viele CIs besitzen.

Ein CI kann mehrere Services unterstützen.

Deshalb sind Beziehungen und Verantwortlichkeiten wichtig.

Datenqualität

Service Configuration Management ist nur hilfreich, wenn die Datenqualität ausreichend ist.

Typische Probleme:

Schlechte Datenqualität kann gefährlicher sein als keine Daten, weil sie falsche Sicherheit erzeugt.

Datenqualität prüfen

Mögliche Prüffragen:

Regelmäßige Prüfung ist notwendig, besonders bei kritischen Services.

Discovery

Discovery bezeichnet das automatische Erkennen von Systemen, Komponenten oder technischen Eigenschaften.

Beispiele:

Discovery kann helfen, Daten aktuell zu halten.

Es ersetzt aber nicht jede fachliche Bewertung.

Ein Tool kann erkennen, dass ein Server existiert.

Es weiß nicht automatisch, welcher Geschäftsprozess davon abhängig ist.

Manuelle Pflege

Manche Informationen müssen manuell oder organisatorisch gepflegt werden.

Beispiele:

Automatische Erkennung und manuelle Pflege müssen zusammenarbeiten.

Namenskonventionen

Klare Namenskonventionen helfen, CIs eindeutig zu identifizieren.

Beispiele:

Ungeeignet:

Besser:

Die konkrete Namenskonvention muss zur Organisation passen.

Configuration Baseline

Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand.

Beispiele:

Baselines helfen bei:

Wenn ein System von der Baseline abweicht, sollte bekannt sein, warum.

Abweichungen erkennen

Abweichungen können entstehen durch:

Abweichungen sind nicht automatisch falsch.

Sie müssen aber nachvollziehbar und bewertet sein.

Service Configuration Management und Incident Management

Bei Incidents helfen Configuration-Daten zu verstehen:

Beispiel:

Eine Anwendung ist nicht erreichbar.

Durch CI-Beziehungen wird sichtbar, dass Anwendung, Datenbank und Identity Provider relevant sind.

Die Diagnose wird schneller und gezielter.

Service Configuration Management und Problem Management

Problem Management nutzt Configuration-Daten, um Ursachen zu erkennen.

Beispiele:

Ohne Beziehungen bleiben solche Muster oft verborgen.

Service Configuration Management und Change Enablement

Bei Changes helfen Configuration-Daten bei der Auswirkungsbewertung.

Zu prüfen ist:

Ein Change ohne Kenntnis der Abhängigkeiten kann unerwartete Incidents erzeugen.

Service Configuration Management und Release Management

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

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

Sonst stimmen spätere Analysen nicht mehr.

Service Configuration Management und Information Security Management

Configuration-Daten unterstützen Sicherheitsarbeit.

Beispiele:

Sicherheitsmaßnahmen hängen stark davon ab, zu wissen, welche Systeme und Abhängigkeiten existieren.

Praxisbeispiel: Abgelaufenes Zertifikat

Incident

Benutzer können sich nicht am Mitarbeiterportal anmelden.

Analyse

Das TLS-Zertifikat ist abgelaufen.

Configuration Management hilft durch:

Verbesserung

Zertifikate werden künftig als CIs mit Ablaufdatum, Owner und Monitoring erfasst.

Praxisbeispiel: Datenbankcluster

Situation

Mehrere Anwendungen melden Fehler.

Ohne CI-Beziehungen

Jedes Anwendungsteam sucht getrennt.

Mit CI-Beziehungen

Es wird sichtbar:

Nutzen

Die Ursache wird schneller eingegrenzt.

Praxisbeispiel: Change-Auswirkung

Change

Firewall-Regel soll angepasst werden.

Configuration Management zeigt:

Nutzen

Der Change wird besser bewertet und sicherer umgesetzt.

Typische Fehler

Fehler 1

CMDB wird als reine Inventarliste verstanden.

Fehler 2

CIs werden erfasst, aber Beziehungen fehlen.

Fehler 3

Daten werden einmal erstellt und danach nicht gepflegt.

Fehler 4

Owner sind unbekannt oder veraltet.

Fehler 5

Changes aktualisieren die CMDB nicht.

Fehler 6

Discovery-Daten werden ungeprüft übernommen.

Fehler 7

Zu viele unwichtige Details werden gepflegt, aber wichtige Servicebeziehungen fehlen.

Fehler 8

Cloud-Ressourcen und externe Services werden nicht berücksichtigt.

Fehler 9

CMDB-Daten werden in Incident, Problem und Change nicht genutzt.

Fehler 10

Dubletten und uneinheitliche Namen erschweren die Nutzung.

Fehler 11

Kritikalität wird technisch statt geschäftlich bewertet.

Fehler 12

Dokumentation und CMDB widersprechen sich.

Checkliste CI erfassen

Checkliste Beziehungen prüfen

Checkliste Datenqualität

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten täglich mit Configuration Items.

Beispiele:

Wichtig ist nicht nur, diese Komponenten technisch zu betreiben.

Wichtig ist auch zu dokumentieren:

Gute Configuration-Daten machen Fehleranalyse, Changes und Servicebetrieb deutlich sicherer.

Zusammenfassung

Service und Komponenten identifizieren
↓
wichtige Configuration Items festlegen
↓
Eigenschaften und Owner dokumentieren
↓
Beziehungen zwischen CIs erfassen
↓
Datenqualität prüfen
↓
Changes und Releases einbeziehen
↓
Informationen in Incident, Problem und Change nutzen
↓
CMDB oder CMS kontinuierlich pflegen und verbessern

Merksätze

Service Configuration Management ist mehr als Inventarisierung.

Beziehungen zwischen CIs sind oft wichtiger als einzelne technische Details.

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

Discovery hilft, ersetzt aber keine fachliche Verantwortung.

Ohne aktuelle Configuration-Daten werden Incidents, Problems und Changes riskanter.

Jede wichtige Änderung sollte auch die Configuration-Daten aktualisieren.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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

6.2 Configuration Items und Beziehungen

Kurz erklärt

Ein Configuration Item (CI) ist ein Bestandteil, der für einen IT-Service wichtig ist und deshalb verwaltet werden soll.

Beziehungen zwischen CIs zeigen, wie Services, Anwendungen, Systeme, Netzwerke, Datenbanken, Zertifikate, Lieferanten und andere Bestandteile zusammenhängen.

Der eigentliche Wert entsteht nicht nur durch die Liste einzelner CIs, sondern durch das Verständnis ihrer Abhängigkeiten.

Warum Configuration Items wichtig sind

IT-Services bestehen meistens aus mehreren technischen und organisatorischen Bestandteilen.

Beispiel:

Ein Mitarbeiterportal kann abhängig sein von:

Wenn diese Bestandteile nicht bekannt sind, werden Incidents, Problems und Changes schwieriger.

Configuration Items helfen dabei, diese Bestandteile strukturiert zu erfassen.

Was ist ein Configuration Item?

Ein Configuration Item ist ein Element, das für die Bereitstellung, den Betrieb, die Steuerung oder die Unterstützung eines Service relevant ist.

Ein CI kann technisch oder nicht-technisch sein.

Beispiele:

Nicht jedes vorhandene Objekt muss automatisch ein CI sein.

Entscheidend ist, ob das Objekt für Servicebetrieb, Risiko, Support, Change oder Steuerung relevant ist.

CI ist nicht gleich Asset

Ein Asset ist häufig ein wirtschaftlich oder vertraglich relevantes Objekt.

Ein CI ist ein für den Servicebetrieb relevantes Objekt.

Asset Configuration Item
Fokus auf Besitz, Kosten, Vertrag oder Lebenszyklus Fokus auf Servicebeziehung, Abhängigkeit und Betrieb
wichtig für Einkauf und Lizenzierung wichtig für Incident, Problem, Change und Release
Beispiel: Notebook mit Kaufdatum Beispiel: Notebook als Teil eines verwalteten Arbeitsplatzservices
Beispiel: Server als Anlagegut Beispiel: Server als Bestandteil einer produktiven Anwendung

Ein Objekt kann gleichzeitig Asset und CI sein.

Beispiel:

Ein produktiver Datenbankserver ist ein Asset und gleichzeitig ein CI.

Welche Objekte sollten als CI erfasst werden?

Ein Objekt sollte eher als CI erfasst werden, wenn:

Ein Objekt muss nicht erfasst werden, nur weil es technisch existiert.

Die Pflege muss einen praktischen Nutzen haben.

Beispiele für CI-Typen

CI-Typ Beispiel
Business Service Mitarbeiterportal
Technical Service Datenbankplattform
Anwendung Warenwirtschaft
Server PRD-APP-PORTAL-01
Datenbank SQL-Cluster Produktion
Netzwerkgerät Standort-Firewall
Cloud-Ressource App Service, Storage Account
Sicherheit TLS-Zertifikat, MFA-Richtlinie
Identität Entra-ID-Gruppe
Schnittstelle REST-API zum ERP-System
Monitoring Alarmregel für Zertifikatsablauf
Backup Backupjob für Datenbank
Dokumentation Betriebsrunbook
Lieferant Supportvertrag Provider

Die CI-Typen sollten zur Organisation passen.

Zu viele CI-Typen können die Pflege unnötig erschweren.

Zu wenige CI-Typen können wichtige Unterschiede verdecken.

Service-CI und technische CIs unterscheiden

Ein Service selbst kann als CI betrachtet werden.

Beispiel:

Der Service ist das, was Benutzer wahrnehmen.

Die technischen CIs sind Bestandteile, die den Service ermöglichen.

Diese Unterscheidung hilft, technische Informationen mit Benutzer- und Geschäftsbezug zu verbinden.

Attribute eines Configuration Items

Ein CI sollte nur so viele Attribute besitzen, wie sinnvoll gepflegt und genutzt werden können.

Mögliche Attribute:

Wichtig ist nicht maximale Datenmenge.

Wichtig ist nutzbare Datenqualität.

CI-Name

Der CI-Name sollte eindeutig und verständlich sein.

Ungeeignet:

Besser:

Eine Namenskonvention kann enthalten:

Die konkrete Namenskonvention muss zur Organisation passen.

CI-Status

Der Status zeigt, in welchem Zustand sich ein CI befindet.

Mögliche Status:

Der Status ist wichtig für:

Ein CI, das außer Betrieb ist, sollte nicht mehr als aktive Abhängigkeit eines produktiven Services erscheinen.

Umgebung

Die Umgebung zeigt, wo ein CI genutzt wird.

Beispiele:

Ein Change an einem Testsystem ist anders zu bewerten als ein Change an einem produktiven System.

Fehlende Umgebungskennzeichnung kann gefährlich sein.

Beispiel:

Ein Administrator führt eine Änderung auf einem System aus, das für Test gehalten wird, tatsächlich aber produktiv ist.

Version und Konfiguration

Für viele CIs ist die Version wichtig.

Beispiele:

Versionen helfen bei:

Beispiel:

Wenn nur VPN-Client-Version 5.8 betroffen ist, muss diese Information auffindbar sein.

Owner und Supportgruppe

Für wichtige CIs sollte klar sein:

Unklare Verantwortlichkeiten führen zu Verzögerungen.

Ungeeignet:

Niemand weiß, wem dieser Server gehört.

Besser:

Service Owner, technischer Owner, Supportgruppe und Lieferant sind dokumentiert.

Kritikalität

Die Kritikalität beschreibt, wie wichtig ein CI oder der zugehörige Service ist.

Mögliche Stufen:

Die Kritikalität beeinflusst:

Wichtig:

Die Kritikalität sollte nicht nur technisch bewertet werden.

Ein unscheinbarer Server kann geschäftskritisch sein, wenn ein zentraler Prozess davon abhängt.

Sicherheitsklassifizierung

Manche CIs benötigen zusätzliche Sicherheitsinformationen.

Beispiele:

Solche Informationen helfen bei:

Was sind CI-Beziehungen?

CI-Beziehungen beschreiben, wie Configuration Items miteinander verbunden sind.

Beispiele:

Beziehungen machen sichtbar, welche Auswirkungen ein Ausfall oder Change haben kann.

Warum Beziehungen wichtiger sind als Einzelinformationen

Eine Liste einzelner CIs beantwortet nur:

Was gibt es?

Beziehungen beantworten:

Was hängt wovon ab?

Beispiel:

CI-Liste:

Beziehungen:

Erst durch Beziehungen wird klar, welche Komponenten gemeinsam einen Service ermöglichen.

Typische Beziehungstypen

Beziehung Bedeutung
nutzt Ein CI verwendet ein anderes CI
läuft auf Anwendung läuft auf Server oder Plattform
ist abhängig von Service funktioniert nur mit anderem CI
verbindet zu Netzwerk- oder Schnittstellenbeziehung
wird überwacht von Monitoringbeziehung
wird gesichert durch Backupbeziehung
wird unterstützt von Lieferanten- oder Supportbeziehung
ist Teil von Komponente gehört zu größerem Service
ersetzt neues CI ersetzt altes CI
kommuniziert mit technische Schnittstelle zwischen Systemen

Die Beziehungsarten sollten verständlich und einheitlich genutzt werden.

Beispiel: Mitarbeiterportal

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

Weitere Beziehungen:

Beispiel: VPN-Service

VPN-Service
    ↓ nutzt
VPN-Gateway
    ↓ nutzt
Firewall
    ↓ nutzt
Internetanbindung

Zusätzliche Abhängigkeiten:

Wenn MFA ausfällt, kann der VPN-Service betroffen sein, obwohl das VPN-Gateway technisch läuft.

Beispiel: Druckservice

Druckservice
    ↓ nutzt
Druckserver
    ↓ verwaltet
Netzwerkdrucker
    ↓ nutzt
Netzwerksegment

Weitere Abhängigkeiten:

Ein Druckproblem kann also viele Ursachen haben.

Ohne Beziehungen wird oft nur der Drucker selbst betrachtet.

Beispiel: Schnittstelle zwischen Anwendungen

Anwendung A
    ↓ sendet Daten an
API-Gateway
    ↓ leitet weiter an
Anwendung B
    ↓ schreibt in
Datenbank B

Zusätzliche Abhängigkeiten:

Eine kleine Änderung am API-Token kann den gesamten Datenaustausch stoppen.

Beziehungen und Incident Management

Bei Incidents helfen Beziehungen, die Auswirkung zu verstehen.

Beispiele:

Beispiel:

Mehrere Anwendungen melden Fehler.

CI-Beziehungen zeigen, dass alle denselben Datenbankcluster nutzen.

Die Diagnose wird schneller eingegrenzt.

Beziehungen und Problem Management

Problem Management nutzt CI-Beziehungen, um Muster zu erkennen.

Beispiele:

Ohne Beziehungen bleiben solche Muster oft unsichtbar.

Beziehungen und Change Enablement

Bei Changes sind Beziehungen besonders wichtig.

Zu prüfen ist:

Ein Change an einem kleinen CI kann große Auswirkungen haben, wenn viele Services davon abhängen.

Beispiel: Change-Auswirkung durch Beziehung

Change

Ein Zertifikat soll erneuert werden.

Ohne Beziehung

Es wird nur der Webserver betrachtet.

Mit Beziehung

Es wird sichtbar:

Dadurch wird der Change besser geplant.

Beziehungen und Release Management

Release Management benötigt Beziehungen, um zu verstehen:

Ein Release kann fehlschlagen, wenn eine abhängige Komponente vergessen wird.

Beziehungen und Information Security Management

Sicherheitsarbeit benötigt CI-Beziehungen.

Beispiele:

Ohne Beziehungen ist Sicherheitsbewertung unvollständig.

Beziehungen und Notfallplanung

Für Notfallplanung sind Abhängigkeiten entscheidend.

Zu klären ist:

Ein Wiederanlaufplan ohne Abhängigkeiten ist häufig unvollständig.

Tiefe der Beziehungspflege

Nicht jede Beziehung muss bis ins kleinste Detail gepflegt werden.

Zu klären ist:

Zu wenig Beziehungspflege macht die CMDB nutzlos.

Zu viel Detailtiefe macht sie schwer wartbar.

Beispiel für sinnvolle Detailtiefe

Für einen geschäftskritischen Service sinnvoll:

Für einen einfachen Testservice kann weniger Detail genügen.

Die Pflege muss zum Risiko passen.

Horizontale und vertikale Beziehungen

Vertikale Beziehungen

zeigen den Aufbau eines Service von oben nach unten.

Beispiel:

Service
    ↓
Anwendung
    ↓
Server
    ↓
Plattform
    ↓
Storage

Horizontale Beziehungen

zeigen Verbindungen zwischen gleichartigen oder verbundenen Komponenten.

Beispiel:

Anwendung A  ↔  API  ↔  Anwendung B

Beide Beziehungstypen sind wichtig.

Vertikale Beziehungen helfen bei Auswirkungsanalyse.

Horizontale Beziehungen helfen bei Schnittstellen- und Kommunikationsproblemen.

Upstream und Downstream

Bei Schnittstellen wird oft zwischen Upstream und Downstream unterschieden.

Begriff Bedeutung
Upstream vorgelagertes System, von dem Daten oder Dienste kommen
Downstream nachgelagertes System, das Daten oder Dienste erhält

Beispiel:

CRM-System
    ↓ sendet Kundendaten an
ERP-System
    ↓ sendet Rechnungsdaten an
Buchhaltungssystem

Wenn das CRM-System fehlerhafte Daten liefert, können downstream weitere Probleme entstehen.

Single Point of Failure erkennen

CI-Beziehungen können Single Points of Failure sichtbar machen.

Beispiel:

Mehrere Services nutzen denselben Datenbankserver.

Wenn dieser Server ausfällt, sind alle Services betroffen.

Mögliche Maßnahmen:

Beziehungen helfen also nicht nur bei Dokumentation, sondern auch bei Risikobewertung.

Dubletten und Namensprobleme

CI-Beziehungen werden unbrauchbar, wenn CIs mehrfach oder uneinheitlich erfasst sind.

Beispiele:

beschreiben möglicherweise dasselbe System.

Folgen:

Namenskonventionen und Dublettenprüfung sind deshalb wichtig.

Veraltete Beziehungen

Beziehungen können veralten durch:

Veraltete Beziehungen sind riskant.

Beispiel:

Ein Change wird als unkritisch bewertet, weil eine alte Beziehung fehlt.

Nach Umsetzung fällt ein abhängiger Service aus.

Beziehungen durch Changes aktualisieren

Jeder relevante Change sollte prüfen:

Configuration Management darf nicht getrennt von Change Enablement betrachtet werden.

Beziehungen durch Discovery erkennen

Technische Beziehungen können teilweise automatisch erkannt werden.

Beispiele:

Aber:

Discovery erkennt nicht immer fachliche Bedeutung.

Ein Tool kann eine Verbindung sehen.

Es weiß nicht automatisch, ob diese Verbindung geschäftskritisch ist.

Manuell gepflegte Beziehungen

Manuell gepflegt werden oft:

Diese Informationen brauchen Verantwortliche und regelmäßige Prüfung.

Beziehungen visualisieren

CI-Beziehungen können als Diagramm, Tabelle oder Abhängigkeitsansicht dargestellt werden.

Mögliche Formen:

Wichtig ist, dass die Darstellung für den Zweck geeignet ist.

Ein Management-Review benötigt andere Details als eine technische Fehleranalyse.

Service Map

Eine Service Map zeigt die wichtigsten Bestandteile eines Services.

Beispiel:

Service: Mitarbeiterportal

Benutzer
    ↓
DNS
    ↓
Load Balancer
    ↓
Webserver
    ↓
Anwendung
    ↓
Datenbank
    ↓
Storage

Zusätzlich:
Identity Provider, Zertifikat, Monitoring, Backup, Supportgruppe

Eine Service Map muss nicht jedes Detail enthalten.

Sie soll die wichtigsten Abhängigkeiten verständlich machen.

Tabellarische Beziehungspflege

Eine einfache Tabelle kann für kleinere Umgebungen ausreichend sein.

Service CI Beziehung Abhängig von Owner
Mitarbeiterportal Portal-App läuft auf PRD-APP-PORTAL-01 App-Team
Mitarbeiterportal Portal-App nutzt PRD-DB-PORTAL-01 DB-Team
Mitarbeiterportal Portal-App nutzt Identity Provider IAM-Team
Mitarbeiterportal Webservice nutzt TLS-Zertifikat Plattform-Team

Wichtig ist, dass die Tabelle gepflegt und genutzt wird.

CI-Beziehungen in Tickets nutzen

Tickets sollten relevante CIs enthalten.

Das hilft bei:

Beispiel:

Ein Incident wird nicht nur als „Anwendung gestört“ erfasst.

Er wird mit Service, Anwendungsversion, Datenbank und betroffener Schnittstelle verknüpft.

Dadurch können spätere Muster erkannt werden.

CI-Beziehungen in Changes nutzen

Ein Change Request sollte betroffene CIs enthalten.

Beispiele:

Zusätzlich sollten abhängige Services geprüft werden.

Ein Change an einer zentralen Komponente muss anders bewertet werden als ein Change an einem isolierten Testsystem.

CI-Beziehungen in Problems nutzen

Ein Problem Record sollte relevante CIs und Beziehungen enthalten.

Beispiel:

Mehrere Incidents betreffen verschiedene Anwendungen.

Problem Management erkennt:

Die CI-Beziehung hilft, eine gemeinsame Ursache zu finden.

Praxisbeispiel: Datenbank als gemeinsame Abhängigkeit

Situation

Drei Anwendungen melden Performance-Probleme.

Einzelbetrachtung

Jedes Team sucht zunächst in seiner Anwendung.

CI-Beziehungen zeigen

Nutzen

Die Analyse wird schneller auf die gemeinsame Abhängigkeit gelenkt.

Praxisbeispiel: Zertifikat als CI

Situation

Anmeldung am Service schlägt fehl.

CI-Beziehungen zeigen

Verbesserung

Zertifikate werden künftig als eigene CIs mit Ablaufdatum, Owner und Monitoringbeziehung gepflegt.

Praxisbeispiel: Standort-Firewall

Situation

Ein Standort meldet Zugriffsstörungen.

CI-Beziehungen zeigen

Nutzen

Die Fehlersuche wird auf Standortnetz, Firewall und VPN eingegrenzt.

Praxisbeispiel: Veraltete Beziehung

Situation

Eine alte Datenbank wird abgeschaltet.

Problem

In der CMDB ist nicht dokumentiert, dass ein Reporting-Service noch darauf zugreift.

Folge

Nach Abschaltung fällt das Reporting aus.

Lerneffekt

Vor Außerbetriebnahme müssen Abhängigkeiten geprüft und alte Beziehungen bereinigt werden.

Typische Fehler

Fehler 1

Nur technische Geräte werden als CIs betrachtet.

Fehler 2

Services selbst werden nicht als CIs erfasst.

Fehler 3

Beziehungen zwischen CIs fehlen.

Fehler 4

Beziehungen werden einmal erstellt und danach nicht gepflegt.

Fehler 5

Zu viele unwichtige Details werden gepflegt, aber wichtige Abhängigkeiten fehlen.

Fehler 6

CIs haben keinen Owner.

Fehler 7

CI-Namen sind uneinheitlich oder doppelt.

Fehler 8

Discovery-Daten werden ohne fachliche Prüfung übernommen.

Fehler 9

Changes aktualisieren CI-Beziehungen nicht.

Fehler 10

Tickets werden nicht mit betroffenen CIs verknüpft.

Fehler 11

Kritikalität wird ohne Servicebezug bewertet.

Fehler 12

Schnittstellen, Zertifikate und Cloud-Ressourcen werden vergessen.

Checkliste: Ist ein Objekt ein sinnvolles CI?

Checkliste CI-Attribute

Checkliste CI-Beziehungen

Checkliste Beziehungspflege nach Changes

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten praktisch mit vielen Configuration Items.

Beispiele:

Wichtig ist nicht nur, diese Komponenten technisch zu kennen.

Wichtig ist auch zu verstehen:

Gute CI-Beziehungen machen technische Arbeit schneller, sicherer und nachvollziehbarer.

Zusammenfassung

wichtige Services identifizieren
↓
relevante Configuration Items bestimmen
↓
sinnvolle Attribute erfassen
↓
Owner und Kritikalität festlegen
↓
Beziehungen zwischen CIs dokumentieren
↓
Serviceabhängigkeiten sichtbar machen
↓
CIs in Incidents, Problems und Changes nutzen
↓
Beziehungen nach Changes aktualisieren
↓
Datenqualität regelmäßig prüfen

Merksätze

Ein CI ist nur dann wertvoll, wenn es für den Servicebetrieb relevant ist.

Beziehungen zeigen, welche Auswirkungen ein Ausfall oder Change haben kann.

Eine CI-Liste ohne Beziehungen ist nur begrenzt hilfreich.

Technisch kleine Komponenten können geschäftlich sehr wichtig sein.

Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung.

CI-Beziehungen müssen nach Changes gepflegt werden.

Gute Configuration-Daten verbessern Incident, Problem, Change und Security Management.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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

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:

Eine CMDB soll diese Informationen strukturiert nutzbar machen.

Was eine CMDB leisten soll

Eine CMDB soll helfen zu beantworten:

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:

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:

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:

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:

Erst diese Serviceperspektive macht die CMDB im Betrieb wertvoll.

Beziehungen in der CMDB

Beziehungen sind einer der wichtigsten Bestandteile einer CMDB.

Typische Beziehungen:

Ohne Beziehungen ist eine CMDB oft nur eine Inventarliste.

Beispiel: Beziehungskette

Benutzer
    ↓
Mitarbeiterportal
    ↓
Webserver
    ↓
Anwendung
    ↓
Datenbank
    ↓
Storage

Weitere Abhängigkeiten:

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:

Beispiel:

Ein Benutzer meldet, dass das Mitarbeiterportal nicht erreichbar ist.

Die CMDB zeigt:

Dadurch kann die Diagnose gezielter beginnen.

CMDB und Problem Management

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

Beispiele:

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:

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

CMDB und Release Management

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

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:

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:

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

CMDB-Datenquellen

Mögliche Datenquellen für eine CMDB:

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:

Discovery ist hilfreich für Aktualität.

Aber Discovery erkennt nicht immer:

Manuelle Pflege

Manuelle Pflege bleibt wichtig für Informationen wie:

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:

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:

Folgen:

Gegenmaßnahmen:

Namenskonventionen

Eine gute Namenskonvention unterstützt Eindeutigkeit.

Mögliche Bestandteile:

Beispiele:

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:

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:

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:

Mittel:

Sehr fein:

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:

Nicht immer sinnvoll:

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:

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:

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:

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

CMDB und Monitoring

Monitoring und CMDB sollten sich ergänzen.

Monitoring zeigt:

CMDB zeigt:

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:

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:

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:

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:

Ein Schnittstellenfehler kann mehrere Services gleichzeitig betreffen.

CMDB und Zertifikate

Zertifikate sollten bei wichtigen Services als relevante CIs betrachtet werden.

Sinnvolle Informationen:

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:

Solche CIs sind besonders wichtig für:

CMDB-Reports

Nützliche Reports können sein:

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:

  1. kritische Services auswählen
  2. wichtigste CIs erfassen
  3. zentrale Beziehungen dokumentieren
  4. Owner festlegen
  5. Change-Prozess anbinden
  6. Datenqualität prüfen
  7. Nutzung in Incident und Change etablieren
  8. 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:

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:

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:

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:

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:

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:

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:

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

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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

6.4 Discovery, Pflege und Datenqualität

Kurz erklärt

Discovery, Pflege und Datenqualität sorgen dafür, dass Configuration-Daten nicht nur einmal erfasst, sondern dauerhaft aktuell, korrekt und nutzbar bleiben.

Discovery hilft, technische Informationen automatisch zu erkennen.

Pflege sorgt dafür, dass fachliche, organisatorische und servicebezogene Informationen ergänzt und aktuell gehalten werden.

Datenqualität entscheidet, ob Configuration-Daten im Betrieb wirklich verlässlich sind.

Warum dieses Thema wichtig ist

Eine CMDB oder ein Configuration Management System ist nur dann hilfreich, wenn die Daten stimmen.

Veraltete oder falsche Configuration-Daten führen zu Problemen:

Datenqualität ist deshalb kein Nebenthema.

Sie ist die Grundlage dafür, dass Service Configuration Management im Alltag funktioniert.

Discovery

Discovery bedeutet, technische Informationen automatisch oder halbautomatisch zu erkennen.

Mögliche Discovery-Ergebnisse:

Discovery kann Daten schneller und regelmäßiger erfassen als rein manuelle Pflege.

Was Discovery leisten kann

Discovery kann helfen bei:

Beispiel:

Ein Discovery-Werkzeug erkennt, dass ein Server noch eine alte Softwareversion verwendet.

Diese Information kann für Security, Change Enablement und Problem Management wichtig sein.

Was Discovery nicht automatisch leisten kann

Discovery erkennt Technik.

Discovery versteht aber nicht automatisch den fachlichen Zusammenhang.

Ein Discovery-Werkzeug erkennt vielleicht:

Es weiß aber nicht automatisch:

Deshalb muss Discovery durch fachliche Pflege ergänzt werden.

Discovery und manuelle Pflege ergänzen sich

Discovery Manuelle oder organisatorische Pflege
erkennt technische Objekte ergänzt fachliche Bedeutung
erkennt Versionen und Eigenschaften ergänzt Owner und Verantwortlichkeiten
erkennt Verbindungen bewertet Serviceabhängigkeiten
erkennt neue Ressourcen prüft, ob sie relevant sind
erkennt Abweichungen klärt, ob sie erlaubt sind
liefert Ist-Daten ergänzt Soll-Zustand und Kontext

Gute Configuration-Daten entstehen durch Kombination aus Automatisierung, Prozessen und Verantwortung.

Typische Discovery-Quellen

Mögliche Quellen für technische Erkennung:

Keine Quelle ist vollständig.

Mehrere Quellen müssen oft abgeglichen werden.

Discovery in Cloud-Umgebungen

Cloud-Umgebungen verändern sich häufig schneller als klassische Rechenzentrumsumgebungen.

Typische Herausforderungen:

Wichtige Maßnahmen:

Discovery in Container-Umgebungen

In Container-Umgebungen entstehen und verschwinden technische Instanzen oft sehr schnell.

Nicht jeder kurzlebige Container sollte dauerhaft als einzelnes CI gepflegt werden.

Sinnvoller können sein:

Wichtig ist, servicebezogene Informationen zu erfassen, nicht jede temporäre Laufzeitinstanz dauerhaft zu dokumentieren.

Discovery und Sicherheitsbewertung

Discovery ist für Sicherheit besonders wichtig.

Beispiele:

Aber auch hier gilt:

Discovery zeigt technische Tatsachen.

Die Risikobewertung benötigt zusätzlich Kritikalität, Datenklasse, Servicebezug und Owner.

Discovery-Ergebnisse prüfen

Discovery-Daten sollten nicht ungeprüft übernommen werden.

Zu prüfen ist:

Automatisierung ohne Prüfung kann die CMDB mit unbrauchbaren Daten füllen.

Datenpflege

Datenpflege bedeutet, Configuration-Daten aktuell und nutzbar zu halten.

Dazu gehören:

Pflege ist keine einmalige Projektarbeit.

Sie ist eine laufende Betriebsaufgabe.

Pflege durch Change Enablement

Changes sind eine der wichtigsten Quellen für CMDB-Aktualisierungen.

Nach einem Change kann sich ändern:

Deshalb sollte jeder relevante Change prüfen:

Müssen Configuration-Daten aktualisiert werden?

Wenn Changes die CMDB nicht pflegen, veraltet sie automatisch.

Pflege durch Release und Deployment

Nach Releases und Deployments ändern sich häufig:

Release- und Deployment-Prozesse sollten deshalb CMDB-Aktualisierung als Abschlussaufgabe enthalten.

Pflege durch Incident und Problem Management

Incident und Problem Management können Datenfehler sichtbar machen.

Beispiele:

Solche Erkenntnisse sollten nicht im Ticket verschwinden.

Sie sollten zur Verbesserung der Configuration-Daten genutzt werden.

Pflege durch Service Owner

Service Owner sind wichtig für fachliche Informationen.

Sie können prüfen:

Technische Teams kennen oft die Komponenten.

Service Owner kennen den fachlichen Wert und die Auswirkung.

Pflege durch technische Teams

Technische Teams pflegen vor allem technische Informationen.

Beispiele:

Wichtig ist, dass technische Änderungen nicht nur umgesetzt, sondern auch nachvollziehbar dokumentiert werden.

Pflegeintervalle

Nicht alle Configuration-Daten müssen gleich häufig geprüft werden.

Mögliche Prüfintervalle:

CI oder Information mögliches Prüfintervall
geschäftskritischer Service regelmäßig und nach jedem relevanten Change
Zertifikate automatisch überwachen und regelmäßig prüfen
produktive Server nach Changes und in festen Reviews
Cloud-Ressourcen häufig oder automatisiert
Dokumentationslinks regelmäßig oder nach Releases
Testsysteme nach Bedarf
archivierte CIs selten, aber nachvollziehbar

Die Häufigkeit sollte sich nach Risiko, Kritikalität und Änderungsdynamik richten.

Datenqualität

Datenqualität beschreibt, ob Configuration-Daten für den vorgesehenen Zweck geeignet sind.

Wichtige Qualitätsmerkmale:

Perfekte Vollständigkeit ist selten realistisch.

Entscheidend ist, dass die Daten für Incident, Problem, Change, Release und Security Management ausreichend zuverlässig sind.

Korrektheit

Korrektheit bedeutet:

Die Information stimmt mit der Realität überein.

Beispiele:

Falsche Daten sind gefährlich.

Beispiel:

Die CMDB zeigt einen Server als Testsystem, obwohl er produktiv genutzt wird.

Ein Change wird dadurch zu niedrig bewertet.

Aktualität

Aktualität bedeutet:

Die Information ist nicht veraltet.

Beispiele für veraltete Daten:

Aktualität entsteht durch Anbindung an Changes, Releases, Reviews und Discovery.

Vollständigkeit

Vollständigkeit bedeutet nicht, jedes Detail zu erfassen.

Sie bedeutet:

Die für den Zweck notwendigen Informationen sind vorhanden.

Beispiel:

Für einen kritischen Service sollten mindestens vorhanden sein:

Ein unwichtiger Testdienst benötigt weniger Detailtiefe.

Eindeutigkeit

Eindeutigkeit bedeutet:

Jedes CI ist klar identifizierbar.

Probleme entstehen durch:

Beispiel:

könnten dasselbe CI beschreiben.

Solche Dubletten erschweren Reports, Changes und Incidents.

Konsistenz

Konsistenz bedeutet:

Daten folgen einheitlichen Regeln.

Beispiele:

Ungeeignet:

werden ohne Regel gemischt.

Besser:

Eine definierte Schreibweise wird verbindlich genutzt.

Nachvollziehbarkeit

Nachvollziehbarkeit bedeutet:

Es ist erkennbar, woher eine Information kommt und warum sie geändert wurde.

Hilfreich sind:

Nachvollziehbarkeit ist besonders wichtig bei Sicherheitsfragen, Audits und Major Incidents.

Nutzbarkeit

Daten sind nur wertvoll, wenn sie genutzt werden können.

Nutzbarkeit bedeutet:

Eine CMDB mit vielen Feldern, die niemand versteht oder nutzt, erzeugt keinen Mehrwert.

Datenqualitätsregeln

Eine Organisation sollte Datenqualitätsregeln definieren.

Beispiele:

Solche Regeln müssen kontrollierbar sein.

Datenqualitätskennzahlen

Mögliche Kennzahlen:

Kennzahl Aussage
CIs ohne Owner Verantwortlichkeit fehlt
CIs ohne Servicezuordnung Servicebezug unklar
kritische Services ohne Abhängigkeiten Auswirkungsanalyse unvollständig
CIs ohne letzte Prüfung Aktualität unsicher
ablaufende Zertifikate ohne Owner hohes Betriebsrisiko
Dublettenquote Eindeutigkeit schlecht
Changes ohne CI-Verknüpfung CMDB wird im Change-Prozess nicht genutzt
Incidents ohne CI-Verknüpfung Trendanalyse erschwert

Kennzahlen sollten nicht nur gemessen werden.

Sie müssen zu Verbesserungen führen.

Datenqualitätsberichte

Datenqualitätsberichte können regelmäßig zeigen:

Solche Berichte sollten Verantwortliche und nächste Schritte enthalten.

Nur eine Fehlerliste reicht nicht aus.

Dubletten bereinigen

Dubletten entstehen leicht durch manuelle Pflege, Discovery oder unterschiedliche Datenquellen.

Vorgehen:

  1. mögliche Dubletten erkennen
  2. prüfen, ob es wirklich dasselbe CI ist
  3. führenden Datensatz festlegen
  4. Beziehungen zusammenführen
  5. verknüpfte Incidents, Problems und Changes prüfen
  6. Dublette archivieren oder löschen
  7. Ursache der Dublette beheben

Wichtig ist, nicht versehentlich unterschiedliche CIs zusammenzuführen.

Veraltete CIs archivieren

Nicht mehr aktive CIs sollten nicht einfach unkontrolliert gelöscht werden.

Besser ist oft:

So bleibt Nachvollziehbarkeit erhalten.

Das ist besonders wichtig bei Audits, Sicherheitsvorfällen oder späteren Analysen.

Abweichungen erkennen

Abweichungen zwischen CMDB und Realität können entstehen durch:

Abweichungen sollten nicht nur korrigiert werden.

Es sollte geprüft werden, warum sie entstanden sind.

Soll-Zustand und Ist-Zustand unterscheiden

Zustand Bedeutung
Soll-Zustand freigegebener oder erwarteter Zustand
Ist-Zustand tatsächlich erkannter Zustand
Abweichung Unterschied zwischen Soll und Ist

Beispiel:

Soll-Zustand:

Server nutzt Version 5.9.

Ist-Zustand:

Discovery erkennt Version 5.8.

Mögliche Ursachen:

Configuration Drift

Configuration Drift bedeutet, dass Systeme im Laufe der Zeit vom gewünschten Zustand abweichen.

Ursachen:

Folgen:

Baselines und regelmäßige Prüfungen helfen gegen Configuration Drift.

Baselines nutzen

Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand.

Beispiele:

Baselines helfen bei:

Wenn ein System von der Baseline abweicht, sollte dokumentiert sein, warum.

Pflegeverantwortung

Ohne Verantwortung veraltet Configuration Management.

Zu klären ist:

Verantwortung kann auf mehrere Rollen verteilt sein.

Sie muss aber eindeutig sein.

Rollen bei der Datenpflege

Rolle mögliche Aufgabe
Configuration Manager Regeln, Modell und Datenqualität steuern
Service Owner Servicebezug, Kritikalität und fachliche Daten prüfen
CI Owner einzelne CIs verantworten
Supportgruppe technische Informationen ergänzen
Change Manager CMDB-Aktualisierung nach Changes sicherstellen
Security Team sicherheitsrelevante Daten nutzen und prüfen
Asset Manager Asset-, Vertrags- und Lebenszyklusdaten liefern

Die Rollen müssen nicht immer eigene Stellen sein.

Wichtig sind klare Zuständigkeiten.

Pflege durch Prozesse erzwingen

Datenpflege funktioniert besser, wenn sie in Prozesse eingebaut ist.

Beispiele:

Datenpflege sollte nicht nur auf freiwilliger Erinnerung beruhen.

Pflegeaufwand realistisch halten

Zu viel Detailtiefe führt zu Pflegeproblemen.

Fragen zur Begrenzung:

Daten, die niemand nutzt und niemand pflegt, sollten kritisch hinterfragt werden.

Toolunterstützung

Tools können unterstützen durch:

Ein Tool löst aber kein organisatorisches Problem.

Ohne klare Regeln und Verantwortung wird auch ein gutes Tool schlechte Daten enthalten.

Integration mit ITSM-Prozessen

Configuration-Daten sollten nicht isoliert gepflegt werden.

Sie sollten aktiv genutzt werden in:

Je häufiger die Daten im Alltag genutzt werden, desto eher fallen Fehler auf.

Ungenutzte Daten veralten schneller.

Datenqualität durch Nutzung verbessern

Wenn Service Desk und Fachteams CMDB-Daten aktiv nutzen, werden Fehler sichtbar.

Beispiele:

Wichtig ist, dass solche Fehler einfach gemeldet und korrigiert werden können.

Praxisbeispiel: Discovery findet unbekannten Server

Situation

Discovery erkennt einen Server, der nicht in der CMDB steht.

Prüfung

Ergebnis

Der Server wird entweder als CI aufgenommen oder kontrolliert außer Betrieb genommen.

Praxisbeispiel: Falscher Owner

Situation

Ein Incident betrifft eine Anwendung.

Die CMDB nennt ein Team, das seit Monaten nicht mehr zuständig ist.

Folge

Eskalation verzögert sich.

Verbesserung

Praxisbeispiel: Veraltete Version

Situation

Die CMDB zeigt Version 5.9.

Discovery erkennt Version 5.8.

Mögliche Ursachen

Verbesserung

Abweichung wird geprüft, korrigiert und mit Change Record verknüpft.

Praxisbeispiel: Fehlende Zertifikatsdaten

Situation

Ein produktives Zertifikat läuft ab.

In der CMDB ist kein Ablaufdatum gepflegt.

Folge

Anmeldedienst fällt aus.

Verbesserung

Praxisbeispiel: Cloud-Ressource ohne Tags

Situation

Cloud-Report zeigt mehrere Ressourcen ohne Service-Tag.

Risiko

Verbesserung

Typische Fehler

Fehler 1

Discovery-Daten werden ungeprüft in die CMDB übernommen.

Fehler 2

Manuelle Pflege wird niemandem eindeutig zugeordnet.

Fehler 3

CMDB wird einmal aufgebaut und danach nicht gepflegt.

Fehler 4

Changes aktualisieren Configuration-Daten nicht.

Fehler 5

Dubletten werden ignoriert.

Fehler 6

Datenqualitätsberichte werden erstellt, aber nicht bearbeitet.

Fehler 7

Zu viele Felder werden gepflegt, obwohl sie niemand nutzt.

Fehler 8

Wichtige Beziehungen fehlen trotz vieler technischer Details.

Fehler 9

Cloud- und Container-Ressourcen werden nicht berücksichtigt.

Fehler 10

Zertifikate, Schnittstellen und Benutzergruppen werden vergessen.

Fehler 11

Owner und Kritikalität werden nicht regelmäßig geprüft.

Fehler 12

Teams vertrauen der CMDB nicht mehr, weil Fehler nicht korrigiert werden.

Checkliste Discovery

Checkliste Datenpflege

Checkliste Datenqualität

Checkliste nach Changes

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker tragen stark zur Datenqualität bei.

Im Alltag bedeutet das:

Eine gute CMDB entsteht nicht allein durch ein Tool.

Sie entsteht durch saubere technische Arbeit, klare Prozesse und konsequente Pflege.

Zusammenfassung

technische Daten durch Discovery erkennen
↓
Ergebnisse prüfen und Dubletten vermeiden
↓
fachliche Informationen ergänzen
↓
Owner, Servicebezug und Kritikalität pflegen
↓
Changes und Releases zur Aktualisierung nutzen
↓
Datenqualität regelmäßig messen
↓
Abweichungen korrigieren
↓
Pflegeaufwand realistisch halten
↓
Configuration-Daten aktiv in ITSM-Prozessen nutzen

Merksätze

Discovery erkennt Technik, aber nicht automatisch fachliche Bedeutung.

Datenpflege ist eine laufende Betriebsaufgabe, kein einmaliges Projekt.

Eine CMDB veraltet automatisch, wenn Changes sie nicht aktualisieren.

Datenqualität ist wichtiger als Datenmenge.

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

Je häufiger Daten im Alltag genutzt werden, desto schneller fallen Fehler auf.

Gute Datenqualität braucht Toolunterstützung, Prozesse und Verantwortung.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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

6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management

Kurz erklärt

Service Configuration Management liefert wichtige Informationen über Services, Configuration Items, Versionen, Verantwortlichkeiten und Abhängigkeiten.

Diese Informationen werden besonders in Incident Management, Problem Management und Change Enablement benötigt.

Ohne aktuelle Configuration-Daten werden Störungen langsamer analysiert, Ursachen schwerer erkannt und Changes riskanter bewertet.

Warum das Zusammenspiel wichtig ist

Configuration-Daten sind keine reine Dokumentation.

Sie unterstützen tägliche Entscheidungen im IT-Betrieb.

Beispiele:

Service Configuration Management liefert die Informationsbasis.

Incident, Problem und Change Management nutzen diese Informationen für Analyse, Bewertung und Steuerung.

Grundidee des Zusammenspiels

Service Configuration Management
        ↓
liefert Services, CIs, Beziehungen, Owner und Versionen
        ↓
Incident Management nutzt diese Daten für schnelle Diagnose
        ↓
Problem Management nutzt diese Daten für Ursachenanalyse
        ↓
Change Enablement nutzt diese Daten für Auswirkungs- und Risikobewertung
        ↓
Changes, Incidents und Problems liefern neue Erkenntnisse zurück
        ↓
Configuration-Daten werden aktualisiert und verbessert

Der Kreislauf funktioniert nur, wenn Configuration-Daten gepflegt und aktiv genutzt werden.

Zusammenspiel mit Incident Management

Incident Management benötigt Configuration-Daten, um Störungen schneller einzuordnen.

Wichtige Fragen:

Je besser diese Informationen verfügbar sind, desto schneller kann der Incident bearbeitet werden.

Incident Management liefert Informationen zurück

Incidents können zeigen, dass Configuration-Daten falsch oder unvollständig sind.

Beispiele:

Diese Erkenntnisse sollten nicht im Incident verschwinden.

Sie sollten genutzt werden, um die CMDB oder das Configuration Management System zu verbessern.

Beispiel: Incident mit fehlender Beziehung

Situation

Benutzer melden, dass das Mitarbeiterportal nicht erreichbar ist.

Analyse

Der Webserver ist erreichbar.

Die Anwendung kann sich aber nicht mit der Datenbank verbinden.

Problem

In der CMDB war die Datenbankbeziehung nicht gepflegt.

Folge

Die Diagnose dauert länger.

Verbesserung

Die Beziehung zwischen Mitarbeiterportal, Anwendung, Datenbank, Storage und Backup wird nachgetragen.

Zusammenspiel mit Problem Management

Problem Management nutzt Configuration-Daten, um Ursachen und Muster zu erkennen.

Wichtige Fragen:

Configuration-Daten helfen, einzelne Incidents in einen größeren Zusammenhang einzuordnen.

Problem Management liefert Informationen zurück

Problem Management kann Configuration-Daten verbessern.

Beispiele:

Eine Ursachenanalyse sollte deshalb auch prüfen, ob Configuration-Daten angepasst werden müssen.

Beispiel: Problem durch gemeinsame Abhängigkeit

Situation

Drei Anwendungen erzeugen ähnliche Fehlermeldungen.

Einzelbetrachtung

Jedes Team untersucht zunächst seine eigene Anwendung.

Configuration-Daten zeigen

Ergebnis

Problem Management erkennt eine gemeinsame Ursache schneller.

Verbesserung

Die Serviceabhängigkeiten werden in der CMDB klarer gepflegt.

Zusammenspiel mit Change Enablement

Change Enablement benötigt Configuration-Daten für die Auswirkungs- und Risikobewertung.

Wichtige Fragen:

Ohne Configuration-Daten wird ein Change schnell zu niedrig bewertet.

Change Enablement liefert Informationen zurück

Changes verändern Configuration-Daten.

Beispiele:

Nach einem Change muss geprüft werden:

Welche Configuration-Daten müssen aktualisiert werden?

Wenn Changes die CMDB nicht aktualisieren, veraltet sie automatisch.

Beispiel: Change mit unvollständiger Auswirkungsbewertung

Situation

Eine Firewall-Regel wird geändert.

Annahme

Nur eine kleine technische Anpassung.

Tatsächliche Auswirkung

Die Regel betrifft eine Schnittstelle zwischen Warenwirtschaft und Versand.

Nach dem Change können Aufträge nicht mehr übertragen werden.

Ursache

Die Beziehung zwischen Firewall-Regel, Schnittstelle und Geschäftsprozess war nicht dokumentiert.

Verbesserung

Schnittstellen und Firewall-Abhängigkeiten werden als relevante CIs und Beziehungen gepflegt.

Configuration-Daten im Change Request

Ein Change Request sollte relevante Configuration-Daten enthalten.

Dazu gehören:

So wird aus einer technischen Änderung eine bewertbare Serviceänderung.

Zusammenspiel mit Release und Deployment Management

Release und Deployment Management benötigen Configuration-Daten für kontrollierte Bereitstellung.

Wichtige Fragen:

Nach einem Release müssen Versionen, Beziehungen und Dokumentation aktualisiert werden.

Beispiel: Release mit Versionsänderung

Situation

Eine neue Anwendungsversion wird ausgerollt.

Configuration Management muss aktualisieren

Nutzen

Bei späteren Incidents ist sofort sichtbar, welche Version produktiv läuft.

Zusammenspiel mit Knowledge Management

Configuration-Daten und Knowledge Management ergänzen sich.

Die CMDB zeigt:

Knowledge Management liefert:

Beide müssen verknüpft sein.

Eine CMDB ohne Dokumentationslinks ist weniger nützlich.

Eine Knowledge Base ohne Service- und CI-Bezug ist schwerer auffindbar.

Beispiel: Knowledge und CMDB

Situation

Ein VPN-Problem tritt wiederholt auf.

CMDB zeigt

Knowledge Base zeigt

Nutzen

Der Service Desk kann neue Incidents schneller erkennen und bearbeiten.

Zusammenspiel mit Information Security Management

Information Security Management benötigt Configuration-Daten für Risikobewertung und Schutzmaßnahmen.

Wichtige Fragen:

Ohne Configuration-Daten ist Sicherheitsarbeit unvollständig.

Beispiel: Sicherheitslücke

Situation

Eine kritische Schwachstelle betrifft eine bestimmte Softwareversion.

Mit guter CMDB

Es ist erkennbar:

Nutzen

Patchpriorisierung wird schneller und nachvollziehbarer.

Zusammenspiel mit IT Asset Management

IT Asset Management und Service Configuration Management überschneiden sich.

IT Asset Management liefert Informationen über:

Service Configuration Management ergänzt:

Ein Server kann gleichzeitig Asset und CI sein.

Beide Sichten sollten zusammenpassen.

Zusammenspiel mit Service Level Management

Service Level Management benötigt Configuration-Daten, um Service Levels realistisch zu bewerten.

Wichtige Fragen:

Service Levels sind schwer steuerbar, wenn die Serviceabhängigkeiten unbekannt sind.

Zusammenspiel mit Monitoring

Monitoring und Configuration Management ergänzen sich.

Monitoring zeigt:

Configuration Management zeigt:

Beispiel:

Monitoring meldet einen Serverausfall.

Die CMDB zeigt, dass daran ein geschäftskritischer Service hängt.

Dadurch kann der Incident korrekt priorisiert und kommuniziert werden.

Zusammenspiel mit Continual Improvement

Configuration Management liefert viele Verbesserungsansätze.

Beispiele:

Diese Erkenntnisse sollten in Continual Improvement einfließen.

Typischer Informationsfluss

Incident erkennt Datenfehler
        ↓
Datenfehler wird dokumentiert
        ↓
Configuration Management prüft und korrigiert
        ↓
Change aktualisiert CI oder Beziehung
        ↓
Problem Management erkennt Muster
        ↓
Knowledge Management ergänzt Workaround
        ↓
Reporting zeigt Datenqualität
        ↓
Continual Improvement verbessert Prozess und Pflege

Configuration Management ist dadurch Teil eines Lernkreislaufs.

Wichtige Schnittstelleninformationen

Für das Zusammenspiel mit anderen Practices sind besonders wichtig:

Diese Informationen sollten nicht nur vorhanden sein, sondern auch aktiv genutzt werden.

Praxisbeispiel: Major Incident

Situation

Ein zentraler Service fällt aus.

Incident Management benötigt

Configuration Management liefert

Nachbereitung

Praxisbeispiel: Wiederkehrende Druckerprobleme

Situation

Ein Standort meldet regelmäßig Druckprobleme.

Incident-Daten zeigen

Configuration-Daten zeigen

Problem Management erkennt

Der Fehler hängt mit einem alten Treiber und einer bestimmten Anwendung zusammen.

Verbesserung

Treiber wird über Change Enablement aktualisiert.

Knowledge-Artikel und CMDB werden angepasst.

Praxisbeispiel: Zertifikatsmanagement

Situation

Ein Zertifikat läuft ab und verursacht einen Incident.

Problem Management erkennt

Change Enablement setzt um

Configuration Management aktualisiert

Praxisbeispiel: Cloud-Ressource ohne Owner

Situation

Eine Cloud-Ressource erzeugt Kosten und ist sicherheitsrelevant.

Problem

Kein Owner, kein Service-Tag, keine Dokumentation.

Risiko

Verbesserung

Typische Fehler im Zusammenspiel

Fehler 1

CMDB wird gepflegt, aber im Incident Management nicht genutzt.

Fehler 2

Incidents zeigen Datenfehler, aber niemand korrigiert sie.

Fehler 3

Problem Management erkennt neue Abhängigkeiten, aber sie werden nicht dokumentiert.

Fehler 4

Changes ändern CIs, ohne die CMDB zu aktualisieren.

Fehler 5

Release und Deployment aktualisieren Versionen nicht.

Fehler 6

Knowledge-Artikel sind nicht mit Services oder CIs verknüpft.

Fehler 7

Security bewertet Risiken ohne aktuelle Configuration-Daten.

Fehler 8

Monitoring-Alarme enthalten keine Serviceinformationen.

Fehler 9

Asset-Daten und CI-Daten widersprechen sich.

Fehler 10

Owner und Supportgruppen sind veraltet.

Fehler 11

Configuration-Daten werden nur für Audits gepflegt, nicht für den Betrieb.

Fehler 12

Datenqualitätsprobleme werden gemessen, aber nicht verbessert.

Checkliste Zusammenspiel mit Incident Management

Checkliste Zusammenspiel mit Problem Management

Checkliste Zusammenspiel mit Change Enablement

Checkliste Zusammenspiel mit Release und Deployment

Checkliste Zusammenspiel mit Security

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten täglich an der Schnittstelle zwischen Technik, Support und Betrieb.

Für sie bedeutet das:

Gute Configuration-Daten entstehen nicht nur durch ein Tool.

Sie entstehen durch konsequente Nutzung im Alltag.

Zusammenfassung

Configuration-Daten bereitstellen
↓
Incident Management nutzt sie für Diagnose und Priorisierung
↓
Problem Management nutzt sie für Muster und Ursachen
↓
Change Enablement nutzt sie für Risiko- und Auswirkungsbewertung
↓
Release und Deployment aktualisieren Versionen und Beziehungen
↓
Knowledge Management verknüpft Workarounds und Runbooks
↓
Security nutzt Daten für Risiko- und Schwachstellenbewertung
↓
Datenfehler und neue Erkenntnisse fließen zurück
↓
CMDB, Service Maps und Dokumentation werden verbessert

Merksätze

Configuration-Daten sind nur wertvoll, wenn sie im Betrieb genutzt werden.

Incident Management braucht Service- und CI-Bezug für schnelle Diagnose.

Problem Management braucht Beziehungen, um gemeinsame Ursachen zu erkennen.

Change Enablement braucht Abhängigkeiten für realistische Risikobewertung.

Jeder relevante Change sollte Configuration-Daten aktualisieren.

Knowledge ohne CI-Bezug ist schwerer auffindbar.

Monitoring ohne Servicebezug erschwert Priorisierung.

Gute Configuration-Daten verbessern Support, Stabilität, Sicherheit und Veränderungsfähigkeit.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten:

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

angepasst werden.

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