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:

Incidents werden falsch priorisiert,
Changes werden mit falscher Auswirkungsbewertung geplant,
Problems werden nicht richtig eingegrenzt,
Owner sind nicht erreichbar,
Serviceabhängigkeiten fehlen,
Sicherheitslücken werden übersehen,
Zertifikate laufen ab,
Cloud-Ressourcen bleiben unbekannt,
und Dokumentation widerspricht der Realität.

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:

Server,
Clients,
Netzwerkgeräte,
virtuelle Maschinen,
Container-Plattformen,
Cloud-Ressourcen,
installierte Software,
Betriebssystemversionen,
IP-Adressen,
offene Dienste,
Zertifikate,
Datenbankinstanzen,
Schnittstellen,
Hardwareinformationen,
Speicher,
Netzwerkverbindungen,
und technische Abhängigkeiten.

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

Was Discovery leisten kann

Discovery kann helfen bei:

Erstbefüllung einer CMDB,
Erkennung unbekannter Systeme,
Aktualisierung technischer Daten,
Abgleich von Ist-Zustand und Soll-Zustand,
Erkennung veralteter Versionen,
Sicherheitsbewertung,
Audit-Vorbereitung,
Cloud-Transparenz,
Netzwerkübersicht,
und Datenqualitätsprüfung.

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:

ein Server existiert,
ein Dienst läuft,
eine IP-Adresse ist erreichbar,
ein Zertifikat ist installiert,
eine Anwendung kommuniziert mit einer Datenbank.

Es weiß aber nicht automatisch:

welcher Geschäftsprozess betroffen ist,
welcher Service Owner verantwortlich ist,
welche Kritikalität der Service besitzt,
ob eine Abweichung genehmigt ist,
ob ein System bald abgelöst wird,
welcher Lieferant verantwortlich ist,
oder welcher Workaround im Störungsfall gilt.

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:

Netzwerk-Scanner,
Monitoring-System,
Endpoint-Management,
Softwareverteilung,
Virtualisierungsplattform,
Cloud-Plattform,
Container-Plattform,
Verzeichnisdienst,
Zertifikatsverwaltung,
Backup-System,
Datenbankverwaltung,
Sicherheitswerkzeuge,
ITSM-System,
Asset-Management-System.

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:

Ressourcen werden automatisch erstellt,
Ressourcen werden schnell gelöscht,
Tags fehlen oder sind uneinheitlich,
Owner sind unklar,
Kostenstellen fehlen,
Testressourcen bleiben aktiv,
Dienste werden extern bereitgestellt,
Abhängigkeiten sind dynamisch.

Wichtige Maßnahmen:

verbindliche Tags definieren,
Owner erfassen,
Umgebung kennzeichnen,
automatische Exporte nutzen,
Cloud-Ressourcen regelmäßig prüfen,
nicht genutzte Ressourcen bereinigen,
Sicherheitsklassifizierung ergänzen.

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:

Service,
Anwendung,
Namespace,
Cluster,
Deployment,
Image-Version,
Datenbank,
Volume,
Ingress,
Zertifikat,
Secret,
Monitoring,
Backupjob.

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:

unbekannte Systeme erkennen,
veraltete Software finden,
offene Dienste prüfen,
externe Erreichbarkeit feststellen,
ablaufende Zertifikate identifizieren,
nicht genehmigte Cloud-Ressourcen erkennen,
nicht inventarisierte Geräte finden,
Systeme mit kritischen Schwachstellen priorisieren.

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:

Ist das erkannte Objekt wirklich relevant?
Ist es bereits als CI vorhanden?
Ist der Name eindeutig?
Ist die Umgebung korrekt?
Ist der Status korrekt?
Gibt es Dubletten?
Ist der Owner bekannt?
Gibt es einen Servicebezug?
Handelt es sich um ein temporäres Objekt?
Muss das Objekt dauerhaft gepflegt werden?

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:

neue CIs erfassen,
veränderte CIs aktualisieren,
entfernte CIs archivieren,
Beziehungen pflegen,
Owner aktualisieren,
Versionen korrigieren,
Dokumentationslinks prüfen,
Dubletten bereinigen,
Statuswerte anpassen,
und veraltete Einträge entfernen oder archivieren.

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:

Version,
Konfiguration,
Beziehung,
Status,
Umgebung,
Owner,
Lieferant,
Zertifikat,
Schnittstelle,
Monitoring,
Backup,
Dokumentation.

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:

Anwendungsversionen,
Zielumgebungen,
Infrastrukturkomponenten,
Schnittstellen,
Datenbankversionen,
Konfigurationsstände,
Container-Images,
Dokumentation,
Known Errors,
Monitoringregeln.

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:

falscher Owner im Incident,
fehlende Servicebeziehung,
veraltete Version,
nicht dokumentierte Schnittstelle,
fehlender Known Error,
nicht erfasstes Zertifikat,
falsche Kritikalität,
fehlender Dokumentationslink.

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:

stimmt die Servicebeschreibung,
stimmt die Kritikalität,
stimmt der Geschäftsprozessbezug,
stimmen Supportzeiten,
stimmen Benutzergruppen,
stimmen Lieferanten,
sind Abhängigkeiten vollständig,
sind Dokumentationslinks aktuell,
sind Risiken korrekt bewertet.

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:

Versionen,
Konfigurationsstände,
Plattformen,
Server,
Datenbanken,
Netzwerkkomponenten,
Zertifikate,
Backupjobs,
Monitoringregeln,
Schnittstellen,
Betriebshandbücher.

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:

korrekt,
aktuell,
vollständig genug,
eindeutig,
konsistent,
nachvollziehbar,
auffindbar,
verantwortet,
und nutzbar.

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:

Version ist richtig,
Owner ist richtig,
Status ist richtig,
Servicezuordnung ist richtig,
Beziehung ist richtig.

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:

alter Owner,
alte Version,
außer Betrieb genommener Server ist noch aktiv,
neues Zertifikat fehlt,
Cloud-Ressource wurde gelöscht,
Schnittstelle wurde geändert,
Dokumentationslink zeigt auf alte Anleitung.

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:

Service Owner,
technische Supportgruppe,
wichtigste CIs,
zentrale Abhängigkeiten,
Kritikalität,
Dokumentation,
Notfallinformationen,
und relevante Lieferanten.

Ein unwichtiger Testdienst benötigt weniger Detailtiefe.

Eindeutigkeit

Eindeutigkeit bedeutet:

Jedes CI ist klar identifizierbar.

Probleme entstehen durch:

doppelte Einträge,
unterschiedliche Schreibweisen,
unklare Namen,
fehlende IDs,
unklare Umgebungen,
ähnliche Systemnamen.

Beispiel:

APP01
app01
Portal-App-Server
PRD-APP-PORTAL-01

könnten dasselbe CI beschreiben.

Solche Dubletten erschweren Reports, Changes und Incidents.

Konsistenz

Konsistenz bedeutet:

Daten folgen einheitlichen Regeln.

Beispiele:

gleiche Statuswerte,
gleiche CI-Typen,
einheitliche Namenskonvention,
klare Beziehungstypen,
einheitliche Umgebungsbezeichnungen,
definierte Pflichtfelder.

Ungeeignet:

Produktion,
Prod,
PRD,
Live

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:

letzter Änderungszeitpunkt,
letzter Prüftermin,
verknüpfter Change,
verantwortliche Person oder Gruppe,
Datenquelle,
Kommentar zur Abweichung,
Archivierung statt unkontrollierter Löschung.

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

Nutzbarkeit

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

Nutzbarkeit bedeutet:

Informationen sind auffindbar,
Felder sind verständlich,
Beziehungen sind sichtbar,
Reports sind sinnvoll,
Daten passen zu Prozessen,
Teams vertrauen den Informationen,
Pflegeaufwand ist realistisch.

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

Datenqualitätsregeln

Eine Organisation sollte Datenqualitätsregeln definieren.

Beispiele:

produktive CIs benötigen Owner,
produktive CIs benötigen Servicezuordnung,
kritische Services benötigen dokumentierte Abhängigkeiten,
Zertifikate benötigen Ablaufdatum und Owner,
Changes müssen betroffene CIs verknüpfen,
außer Betrieb genommene CIs werden archiviert,
Dubletten werden regelmäßig bereinigt,
Cloud-Ressourcen benötigen Tags.

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:

welche CIs unvollständig sind,
welche Owner fehlen,
welche Beziehungen fehlen,
welche CIs lange nicht geprüft wurden,
welche Zertifikate bald ablaufen,
welche Versionen veraltet sind,
welche Changes keine CIs verknüpft haben,
welche Services keine Abhängigkeiten besitzen.

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:

mögliche Dubletten erkennen
prüfen, ob es wirklich dasselbe CI ist
führenden Datensatz festlegen
Beziehungen zusammenführen
verknüpfte Incidents, Problems und Changes prüfen
Dublette archivieren oder löschen
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:

Status auf außer Betrieb setzen,
Beziehungen prüfen,
offene Incidents oder Changes prüfen,
Dokumentation verknüpft lassen,
Archivierungsdatum erfassen,
Grund der Außerbetriebnahme dokumentieren.

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:

ungeplante Changes,
manuelle Änderungen,
Notfallmaßnahmen,
nicht dokumentierte Deployments,
fehlerhafte Discovery,
Cloud-Automatisierung,
Lieferantenänderungen,
Schatten-IT,
vergessene Außerbetriebnahmen.

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:

Update fehlgeschlagen,
CMDB nicht aktualisiert,
falscher Server gescannt,
Rollback wurde durchgeführt,
Change nicht dokumentiert.

Configuration Drift

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

Ursachen:

manuelle Änderungen,
Hotfixes,
ungeplante Anpassungen,
unterschiedliche Skriptversionen,
nicht dokumentierte Changes,
Lieferantenarbeiten,
fehlende Automatisierung,
fehlende Kontrolle.

Folgen:

Tests werden unzuverlässig,
Deployments schlagen fehl,
Sicherheitslücken entstehen,
Incidents werden schwerer analysiert,
Rollback wird schwieriger.

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

Baselines nutzen

Eine Configuration Baseline beschreibt einen bekannten, freigegebenen Zustand.

Beispiele:

Standardserverkonfiguration,
genehmigte Anwendungsversion,
geprüfte Firewall-Regelbasis,
Standardclient,
freigegebene Cloud-Tag-Struktur,
definierter Release-Stand.

Baselines helfen bei:

Vergleich mit aktuellem Zustand,
Fehleranalyse,
Rollback,
Audit,
Standardisierung,
Sicherheitsprüfung.

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

Pflegeverantwortung

Ohne Verantwortung veraltet Configuration Management.

Zu klären ist:

Wer ist für das CMDB-Modell verantwortlich?
Wer pflegt technische Daten?
Wer pflegt Serviceinformationen?
Wer prüft Datenqualität?
Wer bereinigt Dubletten?
Wer kontrolliert Reports?
Wer aktualisiert Daten nach Changes?
Wer genehmigt Modelländerungen?
Wer ist Ansprechpartner bei Datenfehlern?

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:

Change kann nicht abgeschlossen werden, ohne betroffene CIs zu prüfen.
Release-Abschluss enthält CMDB-Aktualisierung.
Incident-Kategorien verlangen Servicezuordnung.
Zertifikate benötigen Owner und Ablaufdatum.
Cloud-Ressourcen ohne Pflicht-Tags werden gemeldet.
Außerbetriebnahme verlangt Abhängigkeitsprüfung.

Datenpflege sollte nicht nur auf freiwilliger Erinnerung beruhen.

Pflegeaufwand realistisch halten

Zu viel Detailtiefe führt zu Pflegeproblemen.

Fragen zur Begrenzung:

Wird dieses Feld wirklich genutzt?
Wer pflegt es?
Wie oft ändert es sich?
Kann es automatisiert werden?
Hilft es bei Incident, Problem, Change oder Security?
Ist es für einen kritischen Service notwendig?
Entsteht durch fehlende Information ein echtes Risiko?

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

Toolunterstützung

Tools können unterstützen durch:

Pflichtfelder,
Workflows,
Discovery-Import,
Dublettenprüfung,
Beziehungsansichten,
Reports,
Erinnerungen,
Datenqualitätsregeln,
Rollenrechte,
Schnittstellen zu Monitoring und Cloud,
Verknüpfung mit Incidents und Changes.

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:

Incident Management,
Problem Management,
Change Enablement,
Release Management,
Service Level Management,
Information Security Management,
IT Asset Management,
Continual Improvement.

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:

falscher Owner wird bei Eskalation bemerkt,
fehlende Beziehung fällt bei Change-Bewertung auf,
veraltete Version fällt bei Security-Prüfung auf,
fehlender Dokumentationslink fällt im Incident auf.

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

Ist der Server produktiv?
Welcher Service nutzt ihn?
Wer ist Owner?
Warum wurde er nicht erfasst?
Gibt es Sicherheitsrisiken?
Gibt es offene Ports?
Muss ein Change oder Problem erstellt werden?

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

Owner wird korrigiert,
ähnliche Services werden geprüft,
regelmäßige Owner-Reviews werden eingeführt,
Change-Übergaben müssen künftig Owner aktualisieren.

Praxisbeispiel: Veraltete Version

Situation

Die CMDB zeigt Version 5.9.

Discovery erkennt Version 5.8.

Mögliche Ursachen

Update wurde nicht durchgeführt,
Rollback wurde nicht dokumentiert,
CMDB wurde zu früh aktualisiert,
Discovery scannt falsches System,
mehrere ähnliche CIs existieren.

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

Zertifikate als eigene CIs erfassen,
Ablaufdatum verpflichtend machen,
Owner festlegen,
Monitoring für Ablaufdaten einführen,
Erneuerungs-Runbook verknüpfen.

Praxisbeispiel: Cloud-Ressource ohne Tags

Situation

Cloud-Report zeigt mehrere Ressourcen ohne Service-Tag.

Risiko

Kostenstelle unklar,
Owner unbekannt,
Kritikalität unbekannt,
Sicherheitsbewertung schwierig,
Außerbetriebnahme riskant.

Verbesserung

Pflicht-Tags definieren,
Erstellung ohne Tags technisch verhindern oder melden,
Ressourcen nachträglich zuordnen,
Verantwortliche benennen.

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:

technische Änderungen nicht nur ausführen, sondern dokumentieren,
Versionen und Konfigurationen korrekt erfassen,
falsche CMDB-Daten melden,
Owner und Servicebezug prüfen,
Discovery-Ergebnisse fachlich einordnen,
nach Changes Beziehungen aktualisieren,
Zertifikate, Schnittstellen und Monitoring berücksichtigen,
und Datenqualität als Teil stabilen Betriebs verstehen.

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

6.1 Service Configuration Management – Ziele, Begriffe und Grundlagen
6.2 Configuration Items und Beziehungen
6.3 Configuration Management Database
6.5 Service Configuration Management im Zusammenspiel mit Incident-, Problem- und Change-Management
Change Enablement
Release Management
Incident Management
Problem Management
Information Security Management
IT Asset Management

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert – ITIL Practice Guide: Service Configuration Management
PeopleCert – ITIL Practice Guide: IT Asset Management
PeopleCert – ITIL Practice Guide: Change Enablement
PeopleCert – ITIL Practice Guide: Release Management
PeopleCert – ITIL Practice Guide: Information Security Management
ITIL Foundation – Version 5

Einordnung

Die dargestellten:

Discovery-Beispiele,
Datenqualitätsregeln,
Pflegeprozesse,
Prüffragen,
Checklisten,
Datenqualitätskennzahlen,
und Praxisbeispiele

sind herstellerneutrale Praxisempfehlungen.

ITIL schreibt keine universelle:

Discovery-Methode,
Datenqualitätskennzahl,
Pflegefrequenz,
Pflichtfeldstruktur,
Toolintegration,
oder CMDB-Governance-Struktur

für alle Organisationen vor.

Die konkrete Umsetzung muss an:

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

angepasst werden.

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

Revision #1
Created 2 August 2026 16:02:27 by Admin
Updated 2 August 2026 16:02:38 by Admin