11. Service Configuration Management

11.1 Ziele und Grundlagen des Service Configuration Management

Kurz erklärt

Service Configuration Management sorgt dafür, dass Informationen über IT-Services und deren Bestandteile vollständig, aktuell und nachvollziehbar verwaltet werden.

Dazu gehören unter anderem Server, Clients, Netzwerkgeräte, Anwendungen, Cloud-Ressourcen, Dokumentationen und ihre gegenseitigen Beziehungen.

Ziel ist es, jederzeit zu wissen, welche Komponenten existieren, wie sie zusammenhängen und welche Auswirkungen Änderungen oder Störungen haben.

Was ist Service Configuration Management?

Service Configuration Management ist eine ITIL Practice zur Verwaltung von Informationen über Services und deren Bestandteile.

Dabei werden nicht die Geräte selbst verwaltet,

sondern die Informationen über diese Objekte.

Beispiele:

Alle diese Objekte können Bestandteil eines IT-Services sein.

Warum Service Configuration Management wichtig ist

In modernen IT-Umgebungen existieren oft tausende oder sogar zehntausende Komponenten.

Ohne eine strukturierte Verwaltung entstehen schnell Fragen wie:

Service Configuration Management beantwortet genau diese Fragen.

Ziele des Service Configuration Management

Die wichtigsten Ziele sind:

Was ist ein Configuration Item (CI)?

Ein Configuration Item (CI) ist jedes Objekt,

das für die Bereitstellung oder Verwaltung eines IT-Services relevant ist.

Ein CI kann beispielsweise sein:

Nicht jedes Inventarobjekt muss automatisch ein CI sein.

Entscheidend ist die Bedeutung für den Service.

Beispiele für Configuration Items

Kategorie Beispiele
Hardware Server, Notebook, Switch
Software Betriebssystem, ERP, Datenbank
Netzwerk Router, Firewall, VLAN
Cloud virtuelle Maschine, Storage, Load Balancer
Dokumentation Runbook, Architekturdiagramm
Service E-Mail, VPN, Fileserver
Verträge SLA, Wartungsvertrag

Nicht jedes Objekt ist ein CI

Ein einzelnes Netzwerkkabel oder eine Computermaus wird häufig inventarisiert,

aber nicht unbedingt als Configuration Item verwaltet.

Dagegen besitzen folgende Objekte meist einen direkten Einfluss auf Services:

Diese werden häufig als CIs geführt.

Was wird über ein CI gespeichert?

Je nach Organisation können unterschiedliche Informationen gespeichert werden.

Typische Angaben:

Je kritischer das CI,

desto umfangreicher sind häufig die gespeicherten Informationen.

Der Lebenszyklus eines Configuration Items

Ein CI durchläuft mehrere Phasen.

Beispiel:

Geplant
    │
    ▼
Beschafft
    │
    ▼
Installiert
    │
    ▼
In Betrieb
    │
    ▼
Geändert
    │
    ▼
Außer Betrieb
    │
    ▼
Entsorgt

Alle relevanten Änderungen sollten dokumentiert werden.

Status eines Configuration Items

Typische Status:

Der aktuelle Status erleichtert den Überblick.

Beziehungen zwischen Configuration Items

Ein großer Vorteil des Service Configuration Managements besteht darin,

dass Beziehungen dokumentiert werden.

Beispiel:

Online-Shop
      │
      ├── Webserver
      │      │
      │      └── Betriebssystem
      │
      ├── Datenbank
      │
      ├── Storage
      │
      └── Firewall

Dadurch wird sichtbar,

welche Komponenten voneinander abhängig sind.

Warum Beziehungen wichtig sind

Fällt eine Datenbank aus,

kann dies Auswirkungen haben auf:

Durch dokumentierte Beziehungen lassen sich Auswirkungen deutlich schneller erkennen.

Service statt Einzelgerät

ITIL betrachtet nicht einzelne Geräte,

sondern den gesamten Service.

Ein Benutzer interessiert sich beispielsweise nicht dafür,

welcher Server ausgefallen ist.

Wichtig ist für ihn,

ob der E-Mail-Service funktioniert.

Service Configuration Management verbindet technische Komponenten mit den bereitgestellten Services.

Service Maps

Service Maps zeigen grafisch,

welche Configuration Items zu einem Service gehören.

Beispiel:

VPN-Service
      │
      ├── Firewall
      ├── VPN-Gateway
      ├── Active Directory
      ├── DNS
      └── Zertifikate

Dadurch lassen sich Störungen und Änderungen schneller bewerten.

Warum aktuelle Daten wichtig sind

Veraltete Informationen führen häufig zu:

Deshalb müssen Configuration-Daten regelmäßig gepflegt werden.

Praxisbeispiel

Ein Webserver fällt aus.

Durch Service Configuration Management erkennt die IT sofort,

dass betroffen sind:

Dadurch kann die Priorität schneller bestimmt und der Incident gezielt bearbeitet werden.

Typische Fehler

Fehler 1

Configuration Items sind nicht aktuell.

Fehler 2

Beziehungen fehlen.

Fehler 3

Services sind nicht dokumentiert.

Fehler 4

Änderungen werden nicht nachgetragen.

Fehler 5

Verantwortlichkeiten sind unklar.

Fehler 6

Zu viele unwichtige Objekte werden als CIs verwaltet.

Fehler 7

Service Maps fehlen.

Fehler 8

Configuration Management wird nur als Inventarliste genutzt.

Checkliste Configuration Items

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten regelmäßig mit Configuration Items.

Typische Aufgaben:

Eine gepflegte Configuration-Datenbasis erleichtert nahezu alle Bereiche des IT-Service-Managements.

Zusammenfassung

Service identifizieren

↓

Configuration Items erfassen

↓

Beziehungen dokumentieren

↓

Status aktuell halten

↓

Änderungen nachführen

↓

Informationen für Incident, Problem und Change Management bereitstellen

Merksätze

Service Configuration Management verwaltet Informationen – nicht die Hardware selbst.

Ein Configuration Item ist jedes für einen Service relevante Objekt.

Beziehungen zwischen Configuration Items sind oft wichtiger als die einzelnen Komponenten.

Aktuelle Configuration-Daten beschleunigen Incident- und Change-Prozesse.

Gute Service Maps erhöhen die Transparenz komplexer IT-Umgebungen.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Beispiele und Vorgehensweisen orientieren sich an der ITIL Practice „Service Configuration Management“. Welche Objekte als Configuration Items geführt werden und welche Informationen gespeichert werden, richtet sich nach Größe, Komplexität und Anforderungen der jeweiligen Organisation.

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

11.2 Configuration Items, Attribute und Beziehungen

Kurz erklärt

Ein Configuration Item (CI) besteht nicht nur aus einem Namen.

Erst durch seine Eigenschaften (Attribute) und seine Beziehungen zu anderen Configuration Items entsteht ein vollständiges Bild eines IT-Services.

Ziel ist es, jederzeit nachvollziehen zu können, welche Komponenten existieren, welche Informationen darüber bekannt sind und wie sie miteinander verbunden sind.

Aufbau eines Configuration Items

Jedes Configuration Item besitzt eine Reihe von Informationen, die seinen aktuellen Zustand beschreiben.

Typische Bestandteile:

Je kritischer ein CI ist, desto umfangreicher sind häufig die gespeicherten Informationen.

Was sind Attribute?

Attribute sind Eigenschaften eines Configuration Items.

Sie beschreiben das CI genauer.

Beispiele:

Nicht jedes CI benötigt dieselben Attribute.

Beispiel: Server als Configuration Item

Attribut Beispiel
CI-ID SRV-00125
Name APP-SRV-01
Typ Virtueller Server
Betriebssystem Windows Server 2025
IP-Adresse 10.20.5.15
Standort Rechenzentrum Berlin
Status Produktiv
Verantwortlich Windows-Team
Service ERP-System

Diese Informationen erleichtern die Verwaltung erheblich.

Beispiel: Netzwerk-Switch

Ein Switch kann unter anderem folgende Attribute besitzen:

Dadurch lassen sich Wartung und Fehleranalyse vereinfachen.

Pflicht- und optionale Attribute

Nicht alle Informationen sind immer erforderlich.

Beispiel:

Pflichtattribute:

Optionale Attribute:

Die Organisation legt selbst fest, welche Angaben verpflichtend sind.

Eindeutige Identifikation

Jedes Configuration Item sollte eindeutig identifizierbar sein.

Geeignet sind beispielsweise:

Mehrdeutige Bezeichnungen erschweren den Betrieb.

Beziehungen zwischen Configuration Items

Einzelne Configuration Items bilden selten einen vollständigen Service.

Erst ihre Beziehungen machen Zusammenhänge sichtbar.

Beispiele:

Diese Beziehungen ermöglichen eine deutlich bessere Auswirkungsanalyse.

Beispiel einer Beziehung

Online-Shop
      │
      ▼
Webserver
      │
      ▼
Datenbank
      │
      ▼
Storage

Fällt das Storage-System aus,

kann die gesamte Anwendung betroffen sein.

Arten von Beziehungen

Typische Beziehungstypen:

Beziehung Beispiel
läuft auf Anwendung → Server
verwendet Anwendung → Datenbank
verbindet Switch → Server
schützt Firewall → Netzwerk
repliziert Datenbank → Datenbank
enthält Service → Anwendung
sichert Backup → Server

Je genauer Beziehungen dokumentiert sind,

desto einfacher lassen sich Auswirkungen erkennen.

Service und Configuration Items

Ein Service besteht meist aus mehreren Configuration Items.

Beispiel:

E-Mail-Service
      │
      ├── Mailserver
      ├── Datenbank
      ├── Storage
      ├── DNS
      ├── Firewall
      ├── Active Directory
      └── Zertifikate

Der Service ist mehr als die Summe seiner technischen Komponenten.

Auswirkungsanalyse (Impact Analysis)

Beziehungen ermöglichen eine schnelle Bewertung von Auswirkungen.

Beispiel:

Vor einem geplanten Change soll ein Server neu gestartet werden.

Durch die dokumentierten Beziehungen erkennt die IT sofort:

Betroffen sind:

Dadurch kann das Wartungsfenster besser geplant werden.

Root Cause Analysis unterstützen

Auch bei Störungen helfen Beziehungen.

Beispiel:

Monitoring meldet:

Die Beziehungen zeigen,

dass alle Systeme dieselbe Datenbank verwenden.

Die eigentliche Ursache liegt vermutlich dort.

Versionen dokumentieren

Viele Configuration Items besitzen unterschiedliche Versionen.

Beispiele:

Versionen erleichtern:

Eigentümer und Verantwortliche

Ein Configuration Item sollte einen fachlichen oder technischen Verantwortlichen besitzen.

Beispiele:

Dadurch ist klar,

wer Änderungen oder Entscheidungen verantwortet.

Status eines Configuration Items

Typische Statuswerte:

Der Status sollte jederzeit aktuell sein.

Dokumentationen verknüpfen

Zu einem CI können verschiedene Dokumente gehören.

Beispiele:

Diese Informationen sollten möglichst direkt mit dem CI verknüpft sein.

Automatische Aktualisierung

Viele Attribute können automatisch gepflegt werden.

Beispiele:

Dadurch steigt die Datenqualität.

Praxisbeispiel

Ein Administrator plant,

die Firmware einer Firewall zu aktualisieren.

Durch die Beziehungen erkennt er,

dass betroffen sind:

Das Wartungsfenster wird entsprechend geplant.

Typische Fehler

Fehler 1

Configuration Items besitzen keine eindeutige ID.

Fehler 2

Attribute sind unvollständig.

Fehler 3

Beziehungen fehlen.

Fehler 4

Verantwortliche sind nicht dokumentiert.

Fehler 5

Versionen werden nicht aktualisiert.

Fehler 6

Dokumentationen sind nicht verknüpft.

Fehler 7

Status stimmt nicht mit der Realität überein.

Fehler 8

Zu viele irrelevante Attribute werden gepflegt.

Checkliste Configuration Items

Checkliste Beziehungen

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker pflegen Configuration Items häufig direkt im Arbeitsalltag.

Typische Aufgaben:

Je vollständiger die Configuration-Daten sind, desto einfacher werden Incident-, Problem- und Change-Prozesse.

Zusammenfassung

Configuration Item erfassen

↓

Attribute ergänzen

↓

Beziehungen dokumentieren

↓

Verantwortlichkeiten festlegen

↓

Status aktuell halten

↓

Informationen für andere ITIL Practices bereitstellen

Merksätze

Ein Configuration Item besteht aus mehr als seinem Namen.

Attribute beschreiben ein CI – Beziehungen verbinden mehrere CIs.

Beziehungen sind entscheidend für Impact- und Ursachenanalysen.

Aktuelle Attribute erhöhen die Qualität der CMDB.

Gute Configuration-Daten erleichtern nahezu alle ITIL Practices.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Attribute, Beziehungstypen und Beispiele orientieren sich an der ITIL Practice „Service Configuration Management“. Welche Attribute gespeichert und welche Beziehungstypen verwendet werden, hängt von den Anforderungen und dem Datenmodell der jeweiligen Organisation ab.

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

11.3 CMDB und Configuration Management System (CMS)

Kurz erklärt

Damit Configuration Items und ihre Beziehungen verwaltet werden können, benötigen Organisationen geeignete Werkzeuge.

Die bekannteste Datenbank hierfür ist die Configuration Management Database (CMDB).

ITIL betrachtet jedoch nicht nur eine einzelne Datenbank, sondern ein Configuration Management System (CMS), das Informationen aus verschiedenen Quellen zusammenführt.

Ziel ist es, jederzeit aktuelle und verlässliche Informationen über Services und deren Bestandteile bereitzustellen.

Was ist eine CMDB?

Die Configuration Management Database (CMDB) ist eine Datenbank zur Speicherung von Informationen über Configuration Items und deren Beziehungen.

Eine CMDB enthält beispielsweise Informationen über:

Die CMDB bildet die Grundlage vieler ITSM-Prozesse.

Aufgaben einer CMDB

Eine CMDB soll:

Sie dient als zentrale Informationsquelle für viele ITIL Practices.

Was ist ein Configuration Management System (CMS)?

Ein CMS ist mehr als eine einzelne Datenbank.

Es verbindet verschiedene Informationsquellen miteinander.

Ein CMS kann beispielsweise Informationen aus folgenden Systemen zusammenführen:

Dadurch entsteht ein umfassender Überblick über die IT-Landschaft.

CMDB und CMS unterscheiden

Diese Begriffe werden häufig verwechselt.

CMDB CMS
einzelne Datenbank Gesamtsystem
speichert CI-Daten verbindet mehrere Datenquellen
Bestandteil des CMS umfasst zahlreiche Systeme
enthält Configuration Items stellt Informationen bereit

Die CMDB ist also ein Bestandteil des CMS.

Aufbau eines CMS

Ein mögliches Beispiel:

Monitoring
      │
Inventarisierung
      │
Cloud
      │
Active Directory
      │
Ticket-System
      │
Dokumentation
      │
      ▼
Configuration Management System
      │
      ▼
CMDB

Das CMS stellt Informationen aus verschiedenen Quellen zusammen.

Welche Informationen stammen aus welchen Quellen?

Beispiele:

Informationsquelle Beispiele
Monitoring Status, Alarme
Active Directory Benutzer, Computer
Virtualisierung virtuelle Maschinen
Cloud Instanzen, Storage
Inventarisierung Hardware
Ticket-System Incidents, Changes
Dokumentation Runbooks, Architektur

Das CMS verbindet diese Informationen logisch miteinander.

Warum nicht alles in der CMDB speichern?

Nicht jede Information gehört dauerhaft in die CMDB.

Beispiel:

CPU-Auslastung verändert sich ständig.

Diese Information stammt besser direkt aus dem Monitoring.

Die CMDB speichert stattdessen beispielsweise:

Aktuelle Zustandsinformationen liefert das Monitoring.

Zentrale Datenhaltung

Eine zentrale Datenbasis bietet zahlreiche Vorteile.

Beispiele:

Dadurch arbeiten alle ITIL Practices mit denselben Informationen.

Beziehungen visualisieren

Viele CMDB-Systeme können Beziehungen grafisch darstellen.

Beispiel:

CRM-Service
      │
      ├── Webserver
      ├── Datenbank
      ├── Storage
      ├── Firewall
      └── DNS

Solche Darstellungen erleichtern die Fehlersuche erheblich.

Serviceorientierte Sicht

ITIL betrachtet bevorzugt Services statt Einzelgeräte.

Ein Benutzer interessiert sich beispielsweise dafür,

ob der VPN-Service verfügbar ist,

nicht dafür,

welcher einzelne Server betroffen ist.

Das CMS verbindet beide Sichtweisen.

Abfragen im CMS

Ein CMS beantwortet beispielsweise Fragen wie:

Dadurch lassen sich Entscheidungen schneller treffen.

Integration mit Monitoring

Viele CMS-Systeme übernehmen Statusinformationen aus dem Monitoring.

Beispiele:

Dadurch stehen aktuelle Informationen direkt zur Verfügung.

Integration mit Change Enablement

Nach einem erfolgreichen Change sollte die CMDB aktualisiert werden.

Beispiele:

Nur so bleibt die Datenqualität erhalten.

Integration mit Incident Management

Bei einem Incident können Administratoren sofort erkennen:

Dadurch verkürzt sich die Analyse erheblich.

Integration mit Problem Management

Problem Management nutzt historische Informationen aus dem CMS.

Beispiele:

Diese Informationen unterstützen die Ursachenanalyse.

Discovery-Werkzeuge

Viele Informationen müssen nicht manuell gepflegt werden.

Discovery-Werkzeuge erkennen automatisch:

Dadurch sinkt der Pflegeaufwand.

Manuelle Pflege bleibt notwendig

Nicht alle Informationen können automatisch erkannt werden.

Beispiele:

Diese Angaben müssen häufig manuell gepflegt werden.

Datenqualität

Eine CMDB ist nur dann hilfreich,

wenn die gespeicherten Informationen korrekt sind.

Wichtige Kriterien:

Schlechte Daten führen zu falschen Entscheidungen.

Praxisbeispiel

Ein Administrator plant einen Neustart eines Datenbankservers.

Über die CMDB erkennt er sofort:

Der Server gehört zu:

Dadurch wird der Change besser geplant und betroffene Fachbereiche können rechtzeitig informiert werden.

Typische Fehler

Fehler 1

CMDB und CMS werden gleichgesetzt.

Fehler 2

Configuration Items werden nicht aktualisiert.

Fehler 3

Discovery wird nicht genutzt.

Fehler 4

Monitoring ist nicht integriert.

Fehler 5

Beziehungen fehlen.

Fehler 6

Mehrere Datenquellen liefern widersprüchliche Informationen.

Fehler 7

Zu viele Informationen werden manuell gepflegt.

Fehler 8

Niemand ist für die Datenqualität verantwortlich.

Checkliste CMDB

Checkliste CMS

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker arbeiten regelmäßig mit CMDBs und CMS-Systemen.

Typische Aufgaben:

Ein gepflegtes CMS erleichtert nahezu alle administrativen Tätigkeiten im IT-Betrieb.

Zusammenfassung

Configuration Items erfassen

↓

In der CMDB speichern

↓

Weitere Datenquellen anbinden

↓

Informationen im CMS zusammenführen

↓

Beziehungen darstellen

↓

Informationen für alle ITIL Practices bereitstellen

Merksätze

Die CMDB ist ein Bestandteil des CMS.

Ein CMS verbindet Informationen aus mehreren Quellen.

Monitoring liefert Zustandsdaten – die CMDB liefert Strukturinformationen.

Discovery verbessert die Datenqualität.

Eine CMDB ist nur so gut wie die Qualität ihrer Daten.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

ITIL unterscheidet klar zwischen einer Configuration Management Database (CMDB) als Datenbank und einem Configuration Management System (CMS) als übergeordnetem Informationssystem. Welche Datenquellen integriert werden und wie die technische Umsetzung erfolgt, hängt von den eingesetzten ITSM-, Discovery- und Monitoring-Lösungen der jeweiligen Organisation ab.

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

11.4 Pflege, Discovery und Datenqualität

Kurz erklärt

Eine Configuration Management Database (CMDB) ist nur dann hilfreich, wenn ihre Informationen aktuell und korrekt sind.

Deshalb gehören die kontinuierliche Pflege, automatische Discovery-Verfahren und die regelmäßige Überprüfung der Datenqualität zu den wichtigsten Aufgaben des Service Configuration Management.

Ziel ist es, jederzeit eine zuverlässige Informationsbasis für Incident Management, Problem Management, Change Enablement und andere ITIL Practices bereitzustellen.

Warum Datenqualität entscheidend ist

Eine unvollständige oder veraltete CMDB kann mehr Schaden anrichten als gar keine CMDB.

Falsche Informationen führen beispielsweise zu:

Eine hohe Datenqualität ist daher wichtiger als eine möglichst große Anzahl gespeicherter Configuration Items.

Was bedeutet Datenqualität?

Datenqualität beschreibt,

wie zuverlässig und nutzbar Informationen sind.

Wichtige Qualitätsmerkmale:

Nur wenn diese Eigenschaften erfüllt sind,

können andere ITIL Practices auf die Daten vertrauen.

Vollständigkeit

Alle erforderlichen Informationen sollten vorhanden sein.

Beispiele:

Fehlende Informationen erschweren spätere Entscheidungen.

Aktualität

Configuration-Daten müssen Änderungen zeitnah widerspiegeln.

Beispiele:

Veraltete Informationen führen schnell zu Fehlentscheidungen.

Korrektheit

Die gespeicherten Informationen müssen der Realität entsprechen.

Beispiel:

Die CMDB enthält:

Windows Server 2022

Tatsächlich läuft:

Windows Server 2025

Solche Abweichungen können Fehleranalysen und Sicherheitsmaßnahmen erheblich erschweren.

Konsistenz

Informationen dürfen sich nicht widersprechen.

Beispiel:

Die CMDB nennt als Verantwortlichen das Linux-Team,

während die Dokumentation das Windows-Team aufführt.

Solche Widersprüche sollten vermieden werden.

Was ist Discovery?

Discovery bezeichnet die automatische Erkennung von Configuration Items und ihren Eigenschaften.

Discovery-Werkzeuge können beispielsweise erkennen:

Dadurch sinkt der manuelle Pflegeaufwand erheblich.

Wie funktioniert Discovery?

Je nach Werkzeug kommen unterschiedliche Verfahren zum Einsatz.

Beispiele:

Welche Methode verwendet wird,

hängt von der jeweiligen Infrastruktur ab.

Agentenbasierte Discovery

Ein Agent wird direkt auf dem System installiert.

Vorteile:

Nachteile:

Agentenlose Discovery

Hier erfolgt die Erkennung über Netzwerkprotokolle oder Programmierschnittstellen.

Vorteile:

Nachteile:

Automatisch erkannte Informationen

Discovery kann beispielsweise erfassen:

Nicht alle Informationen lassen sich automatisch erkennen.

Was Discovery nicht erkennt

Geschäftsbezogene Informationen müssen häufig manuell ergänzt werden.

Beispiele:

Diese Informationen entstehen meist außerhalb der technischen Infrastruktur.

Regelmäßige Discovery

Discovery sollte regelmäßig ausgeführt werden.

Beispiele:

Dadurch bleiben Änderungen möglichst aktuell.

Abgleich mit der CMDB

Nach einer Discovery werden erkannte Änderungen mit der CMDB verglichen.

Mögliche Ergebnisse:

Nicht jede Änderung wird automatisch übernommen.

Je nach Organisation erfolgt zunächst eine Prüfung.

Manuelle Pflege

Auch bei umfangreicher Discovery bleibt manuelle Pflege notwendig.

Typische Aufgaben:

Automatische Verfahren ersetzen diese Arbeiten nicht vollständig.

Qualitätssicherung

Configuration-Daten sollten regelmäßig überprüft werden.

Mögliche Maßnahmen:

Dadurch lassen sich Fehler früh erkennen.

Configuration Audits

Ein Configuration Audit überprüft,

ob die dokumentierten Informationen der tatsächlichen Umgebung entsprechen.

Beispielsweise wird geprüft:

Audits erhöhen die Zuverlässigkeit der CMDB.

Data Owner

Für wichtige Configuration Items sollte klar geregelt sein,

wer für die Daten verantwortlich ist.

Typische Verantwortliche:

Dadurch bleibt die Pflege dauerhaft sichergestellt.

Kennzahlen zur Datenqualität

Auch Datenqualität kann gemessen werden.

Beispiele:

Diese Kennzahlen unterstützen Continual Improvement.

Praxisbeispiel

Ein Discovery-Werkzeug erkennt,

dass auf einem Server eine neue Version des Betriebssystems installiert wurde.

Die Änderung wird erkannt,

aber zunächst nicht automatisch übernommen.

Nach erfolgreicher Prüfung aktualisiert der Administrator die CMDB.

Dadurch bleiben Dokumentation und tatsächlicher Zustand identisch.

Typische Fehler

Fehler 1

Configuration Items werden nie überprüft.

Fehler 2

Discovery wird nicht genutzt.

Fehler 3

Discovery überschreibt ungeprüft manuelle Angaben.

Fehler 4

Verantwortlichkeiten fehlen.

Fehler 5

Veraltete Beziehungen bleiben bestehen.

Fehler 6

Audits finden nicht statt.

Fehler 7

Zu viele irrelevante Informationen werden gespeichert.

Fehler 8

Monitoring und CMDB liefern widersprüchliche Daten.

Fehler 9

Changes werden nicht in die CMDB übernommen.

Fehler 10

Niemand misst die Datenqualität.

Checkliste Datenqualität

Checkliste Discovery

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sorgen häufig dafür,

dass Configuration-Daten korrekt und aktuell bleiben.

Typische Aufgaben:

Eine zuverlässige CMDB entsteht nicht einmalig, sondern durch kontinuierliche Pflege.

Zusammenfassung

Configuration Items erfassen

↓

Discovery durchführen

↓

Änderungen erkennen

↓

Daten prüfen

↓

CMDB aktualisieren

↓

Datenqualität überwachen

↓

Regelmäßig auditieren

Merksätze

Eine CMDB ist nur so gut wie ihre Daten.

Discovery reduziert manuellen Pflegeaufwand, ersetzt ihn aber nicht vollständig.

Geschäftsbezogene Informationen müssen häufig manuell ergänzt werden.

Regelmäßige Audits verbessern die Datenqualität.

Aktuelle Configuration-Daten unterstützen nahezu alle ITIL Practices.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die beschriebenen Discovery-Verfahren, Qualitätskriterien und Auditmaßnahmen orientieren sich an den Empfehlungen der ITIL Practice „Service Configuration Management“. Welche Discovery-Werkzeuge, Schnittstellen und Prüfmechanismen eingesetzt werden, hängt von der jeweiligen IT-Landschaft und den organisatorischen Anforderungen ab.

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

11.5 Zusammenspiel mit Incident, Problem, Change und Monitoring

Kurz erklärt

Service Configuration Management arbeitet eng mit vielen anderen ITIL Practices zusammen.

Die gespeicherten Informationen über Configuration Items (CIs), Services und deren Beziehungen bilden die Grundlage für fundierte Entscheidungen im IT-Betrieb.

Erst durch das Zusammenspiel mit Incident Management, Problem Management, Change Enablement und Monitoring and Event Management entfaltet Service Configuration Management seinen vollen Nutzen.

Warum das Zusammenspiel wichtig ist

Eine CMDB allein behebt keine Störungen und führt keine Änderungen durch.

Sie beantwortet jedoch entscheidende Fragen wie:

Diese Informationen werden anschließend von anderen ITIL Practices genutzt.

Zusammenspiel der Practices

Configuration Items
          │
          ▼
CMDB / CMS
          │
          ▼
Incident
Problem
Change
Monitoring
          │
          ▼
Bessere Entscheidungen

Die CMDB dient als gemeinsame Informationsbasis.

Service Configuration Management und Incident Management

Bei einem Incident muss häufig schnell geklärt werden:

Diese Informationen stammen aus der CMDB.

Beispiel

Das Monitoring meldet:

Webserver nicht erreichbar.

Die CMDB zeigt:

Dadurch kann der Incident schneller bewertet werden.

Impact Analysis

Die Auswirkungen einer Störung lassen sich mithilfe der Beziehungen zwischen Configuration Items bestimmen.

Beispiel:

Storage
    │
    ▼
Datenbank
    │
    ▼
ERP-System
    │
    ▼
Produktion

Fällt das Storage-System aus,

sind mehrere Services betroffen.

Dadurch steigt die Priorität des Incidents.

Root Cause Analysis

Auch Problem Management nutzt die Beziehungen der CMDB.

Beispiel:

Mehrere Incidents betreffen:

Die CMDB zeigt,

dass alle dieselbe Datenbank verwenden.

Dadurch lässt sich die eigentliche Ursache schneller identifizieren.

Service Configuration Management und Problem Management

Problem Management untersucht wiederkehrende Ursachen.

Configuration-Daten helfen beispielsweise dabei,

Je vollständiger die CMDB,

desto effizienter wird die Ursachenanalyse.

Known Errors

Wird eine Ursache dauerhaft dokumentiert,

kann sie mit betroffenen Configuration Items verknüpft werden.

Beispiel:

Known Error
      │
      ▼
Firmware-Version 4.2.1
      │
      ▼
Switch-Serie XY

Dadurch lassen sich ähnliche Vorfälle schneller erkennen.

Service Configuration Management und Change Enablement

Changes verändern häufig Configuration Items.

Beispiele:

Nach jedem erfolgreichen Change sollte die CMDB aktualisiert werden.

Vor einem Change

Vor einer Änderung beantwortet die CMDB beispielsweise:

Dadurch sinkt das Risiko von Fehlentscheidungen.

Nach einem Change

Nach erfolgreicher Umsetzung werden beispielsweise aktualisiert:

Dadurch bleibt die CMDB aktuell.

Service Configuration Management und Monitoring

Monitoring überwacht Configuration Items.

Die CMDB beschreibt sie.

Beispiel:

Monitoring erkennt:

Server ausgefallen.

Die CMDB ergänzt:

Erst beide Informationen zusammen ermöglichen eine vollständige Bewertung.

Service Maps

Monitoring und CMDB können gemeinsam Service Maps erzeugen.

Beispiel:

CRM-Service
      │
      ├── Webserver
      ├── API
      ├── Datenbank
      ├── Storage
      └── Firewall

Fällt eine Komponente aus,

werden betroffene Services sofort sichtbar.

Monitoring nach Changes

Nach einem Change überprüft Monitoring beispielsweise:

Configuration Management dokumentiert,

welche Version jetzt produktiv eingesetzt wird.

Monitoring unterstützt Discovery

Discovery-Werkzeuge erkennen:

Die Ergebnisse können anschließend in die CMDB übernommen werden.

Service Configuration Management und Service Level Management

SLA-Ziele beziehen sich häufig auf Services.

Die CMDB beschreibt,

welche Configuration Items zu einem Service gehören.

Dadurch können Verfügbarkeiten und Ausfälle korrekt bewertet werden.

Service Configuration Management und Availability Management

Availability Management benötigt Informationen darüber,

welche Komponenten für einen Service notwendig sind.

Beispiele:

Die CMDB liefert diese Informationen.

Service Configuration Management und Capacity Management

Kapazitätsplanung nutzt unter anderem:

Die CMDB zeigt,

welche Ressourcen vorhanden sind und welchen Services sie zugeordnet sind.

Service Configuration Management und Information Security Management

Viele sicherheitsrelevante Informationen werden mit Configuration Items verknüpft.

Beispiele:

Dadurch lassen sich Risiken gezielter bewerten.

Service Configuration Management und Continual Improvement

Eine gepflegte CMDB unterstützt Verbesserungen.

Beispiele:

Dadurch steigt der Nutzen der gesamten Configuration-Datenbasis.

Praxisbeispiel

Ein Switch wird ersetzt.

Vor dem Change zeigt die CMDB:

Betroffen sind:

Nach erfolgreicher Umsetzung werden:

aktualisiert.

Monitoring bestätigt anschließend,

dass alle Services wieder ordnungsgemäß funktionieren.

Typische Fehler

Fehler 1

Changes werden nicht in der CMDB dokumentiert.

Fehler 2

Incident Management nutzt die CMDB nicht.

Fehler 3

Monitoring kennt keine Servicebeziehungen.

Fehler 4

Discovery-Ergebnisse werden ignoriert.

Fehler 5

Service Maps fehlen.

Fehler 6

Configuration Items besitzen keine Verantwortlichen.

Fehler 7

Problem Management nutzt historische Configuration-Daten nicht.

Fehler 8

Mehrere Systeme besitzen widersprüchliche Informationen.

Fehler 9

SLA-Bewertungen berücksichtigen keine Serviceabhängigkeiten.

Fehler 10

Configuration-Daten werden nur nach größeren Projekten aktualisiert.

Checkliste Zusammenspiel

Checkliste Service Configuration Management

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker pflegen und nutzen Configuration-Daten nahezu täglich.

Typische Aufgaben:

Eine gepflegte CMDB reduziert Suchaufwand, verbessert Entscheidungen und unterstützt nahezu alle ITIL Practices.

Zusammenfassung

Configuration Items verwalten

↓

Beziehungen dokumentieren

↓

Informationen in der CMDB bereitstellen

↓

Incident, Problem und Change unterstützen

↓

Monitoring integrieren

↓

Datenqualität verbessern

↓

Services sicher betreiben

Merksätze

Service Configuration Management liefert Informationen – andere Practices nutzen sie.

Eine aktuelle CMDB beschleunigt Incident-, Problem- und Change-Prozesse.

Monitoring beschreibt den Zustand – die CMDB beschreibt die Struktur.

Service Maps erleichtern Impact- und Ursachenanalysen.

Gute Configuration-Daten sind eine wichtige Grundlage für professionelles IT-Service-Management.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die dargestellten Zusammenhänge entsprechen den Empfehlungen der ITIL-Practices. Service Configuration Management stellt strukturierte Informationen über Services und Configuration Items bereit, die von Incident Management, Problem Management, Change Enablement, Monitoring und weiteren Practices genutzt werden. Die konkrete technische Umsetzung erfolgt organisationsabhängig mithilfe von CMDB-, CMS-, Monitoring- und ITSM-Systemen.

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