Datenqualität in der CMDB: Warum sie ein kontinuierlicher Prozess ist

Warum eine saubere IT-Dokumentation heute noch nichts darüber aussagt, ob Sie ihr morgen vertrauen können

Eine hohe Datenqualität in der CMDB klingt zunächst nach einem klaren Ziel: Daten bereinigen, Dubletten entfernen, Pflichtfelder prüfen, Schnittstellen testen und fehlende Informationen ergänzen. Ist dieser Punkt erreicht, scheint das Thema erledigt.

Genau hier liegt jedoch das Problem. IT-Infrastrukturen verändern sich permanent. Komponenten werden ausgetauscht, Anwendungen migriert, Schnittstellen angepasst, Systeme außer Betrieb genommen und Verantwortlichkeiten neu verteilt. Jede dieser Veränderungen kann dazu führen, dass technische Realität und dokumentierter Zustand auseinanderlaufen.

 

Datenqualität hat deshalb eine Halbwertszeit.

Ein Datensatz kann heute korrekt sein und morgen bereits veraltet. Entscheidend ist also nicht nur, wie gut die Daten zu einem bestimmten Zeitpunkt sind. Mindestens genauso wichtig ist die Frage: Wie schnell erkennen und korrigieren wir relevante Abweichungen?

In den bisherigen Beiträgen dieser Serie ging es darum, warum digitale Souveränität mit Transparenz beginnt, weshalb ein Inventar noch keinen digitalen Zwilling ergibt, warum eine CMDB ein tragfähiges Betriebsmodell benötigt und weshalb Discovery Veränderungen erkennt, aber nicht über deren Bedeutung entscheiden kann.

Der nächste logische Schritt ist daher die Frage: Wie lässt sich Datenqualität in einer CMDB dauerhaft sicherstellen?

 

Was bedeutet Datenqualität in einer CMDB?

Datenqualität bedeutet nicht nur, dass möglichst viele Felder ausgefüllt sind. Entscheidend ist vielmehr, ob die vorhandenen Informationen für den jeweiligen Anwendungsfall vollständig, aktuell, konsistent und verlässlich genug sind.

Ein Datensatz kann vollständig sein und trotzdem falsche Informationen enthalten. Eine Komponente kann korrekt erfasst sein, aber mit der falschen Anwendung verknüpft werden. Ein Service kann vollständig modelliert sein und dennoch auf veralteten Beziehungen basieren.

Datenqualität umfasst deshalb mehrere Dimensionen. Dazu gehören unter anderem Vollständigkeit, Aktualität, Konsistenz, Eindeutigkeit, Plausibilität sowie korrekte Beziehungen und Abhängigkeiten.

Die entscheidende Frage lautet deshalb nicht: Sind unsere Daten vollständig?

Sondern: Sind unsere Daten zuverlässig genug für die Entscheidungen und Prozesse, für die wir sie benötigen?

 

Gute Daten zum Go-Live sind erst der Anfang

Gerade rund um Einführung, Migration oder Go-Live wird Datenqualität intensiv betrachtet. Bestehende Daten werden bereinigt, Informationen vervollständigt, Schnittstellen geprüft und Verantwortlichkeiten abgestimmt. Am Ende steht im besten Fall eine konsistente und belastbare Datenbasis.

Doch schon mit der nächsten Veränderung kann dieser Zustand wieder verloren gehen. Eine Komponente wird ersetzt, eine Anwendung migriert oder eine Schnittstelle angepasst. Vielleicht wird die technische Änderung korrekt durchgeführt, aber nicht vollständig dokumentiert.

Solche Abweichungen entstehen meist schrittweise. Mit jeder Differenz zwischen realer und dokumentierter Infrastruktur sinkt das Vertrauen in die zentrale IT-Dokumentation. Teams beginnen, Informationen zusätzlich in anderen Systemen zu prüfen, eigene Listen zu führen oder sich auf das Wissen einzelner Personen zu verlassen.

Das eigentliche Problem ist dann nicht mehr nur schlechte Datenqualität. Es ist verlorenes Vertrauen in die Daten.

 

Warum Datenqualität immer einen konkreten Zweck braucht

Nicht jedes Attribut muss überall mit derselben Intensität gepflegt werden. Wer versucht, sämtliche Informationen mit maximaler Detailtiefe aktuell zu halten, erzeugt schnell einen erheblichen Pflegeaufwand.

Deshalb sollte Datenqualität immer vom konkreten Anwendungsfall ausgehen.

Bei einem geschäftskritischen Service kann beispielsweise entscheidend sein, welche Anwendungen und Infrastrukturkomponenten miteinander verbunden sind. Für einen geplanten Change müssen möglicherweise andere Beziehungen aktuell und verlässlich sein. Bei einer Migration wiederum können technische Attribute und Systemstände im Vordergrund stehen.

Damit wird aus dem abstrakten Ziel „hohe Datenqualität“ eine konkrete fachliche Anforderung. Und erst eine solche Anforderung lässt sich sinnvoll messen und überprüfen.

Gute Datenqualität bedeutet nicht, möglichst viele Informationen zu pflegen. Sie bedeutet, die richtigen Informationen zuverlässig verfügbar zu haben.

 

Welche Rolle spielt Discovery bei der Datenqualität?

Automatisierte Discovery kann einen wichtigen Beitrag zur Datenqualität leisten. Sie kann neue Komponenten erkennen, technische Attribute aktualisieren und Abweichungen zwischen dokumentiertem und beobachtetem Zustand sichtbar machen.

Doch damit ist die Qualitätsfrage noch nicht beantwortet.

Wenn Discovery beispielsweise eine andere Komponente erkennt als die, die in der CMDB hinterlegt ist, muss geklärt werden, warum diese Abweichung existiert. Wurde ein Gerät regulär ausgetauscht? Befindet sich die Infrastruktur in einer Übergangsphase? Ist die Dokumentation veraltet oder wurde das Discovery-Ergebnis falsch zugeordnet?

Ein Sensor erkennt die Abweichung. Datenqualität entsteht durch den Prozess danach.

Damit schließt Datenqualitätsmanagement direkt an die Frage an, die im vorherigen Beitrag zu Discovery im Mittelpunkt stand: Nicht allein die technische Erkennung entscheidet über die Qualität der Dokumentation, sondern der Umgang mit den erkannten Abweichungen.

 

Datenqualität ist auch eine Frage der Reaktionszeit

Eine Datenqualitätsquote von beispielsweise 98 Prozent klingt zunächst gut. Sie sagt jedoch wenig darüber aus, ob ein Unternehmen seine Datenqualität tatsächlich beherrscht.

Denn zwei Organisationen können dieselbe Quote haben – und trotzdem völlig unterschiedlich auf Abweichungen reagieren.

Im einen Unternehmen bleibt eine kritische falsche Beziehung wochenlang unbemerkt. Im anderen wird sie automatisiert erkannt, fachlich bewertet und innerhalb kurzer Zeit korrigiert.

Deshalb sollte neben klassischen Qualitätskennzahlen eine weitere Frage gestellt werden:

Wie lange dauert es vom Entstehen einer relevanten Abweichung bis zu ihrer Erkennung und Korrektur?

Damit wird Datenqualität zu einer operativen Steuerungsgröße. Und genau hier treffen Technik, Prozesse und Verantwortung aufeinander.

 

Datenqualität braucht klare Verantwortung

Ein belastbarer Datenqualitätsprozess braucht mehr als technische Prüfungen. Er benötigt klare Verantwortlichkeiten.

Wer bewertet eine Abweichung zwischen Discovery und Dokumentation? Welches System gilt bei widersprüchlichen Informationen als führend? Wer darf Daten korrigieren? Wer prüft, ob diese Korrektur fachlich richtig war? Und innerhalb welchen Zeitraums müssen kritische Abweichungen bearbeitet werden?

Wenn diese Fragen nicht geklärt sind, helfen auch gute Dashboards und automatisierte Prüfungen nur begrenzt. Dann entstehen Findings, aber keine nachhaltige Verbesserung.

Datenqualität entsteht dort, wo technische Prüfmechanismen, fachliche Regeln und eindeutige Verantwortlichkeiten zusammenkommen.

 

Messen heißt nicht nur Fehler zählen

Kennzahlen helfen dabei, Datenqualität sichtbar zu machen. Beispielsweise lässt sich messen, wie viele relevante Datensätze vollständig gepflegt sind, bei wie vielen Komponenten Verantwortlichkeiten fehlen oder wo verschiedene Quellen voneinander abweichen.

Doch hundert Datenfehler sind nicht automatisch kritischer als fünf. Einige falsche Beziehungen innerhalb eines geschäftskritischen Services können größere Auswirkungen haben als zahlreiche fehlende Attribute in einem kaum genutzten Bereich.

Entscheidend sind deshalb drei Fragen:

Welche Abweichungen sind relevant? Welche Auswirkungen haben sie? Und wie schnell werden sie behoben?

So wird aus einer reinen Qualitätsquote eine Grundlage für operative Entscheidungen.

 

Bevor Sie Daten bereinigen, müssen Sie wissen, welche Probleme relevant sind

Wenn das Vertrauen in eine CMDB sinkt, liegt der erste Impuls nahe: Die Daten müssen bereinigt werden.

Doch eine Bereinigung behandelt zunächst nur sichtbare Symptome. Vorher sollte klar sein, wo relevante Qualitätsprobleme liegen, welche Auswirkungen sie haben und welche Maßnahmen zuerst umgesetzt werden sollten.

Dafür braucht es Transparenz über den tatsächlichen Datenzustand. Bestehende Datenstrukturen und -inhalte werden analysiert, Inkonsistenzen, Dubletten und fehlende Informationen identifiziert und anhand definierter Qualitätskriterien bewertet.

Genau hier setzt beispielsweise unser Datenqualitäts-Audit an. Es schafft nicht nur Transparenz über Auffälligkeiten, sondern liefert eine Grundlage, um Optimierungsmaßnahmen gezielt zu priorisieren.

Die sinnvolle Reihenfolge lautet deshalb:

Verstehen. Bewerten. Priorisieren. Verbessern.

Und anschließend muss sich zeigen, ob neue Abweichungen zuverlässig erkannt und bearbeitet werden.

 

Ein einfacher Praxistest für Ihre Datenqualität

Nehmen Sie einige Veränderungen der vergangenen Monate, zum Beispiel einen Hardwaretausch, eine Migration oder die Außerbetriebnahme eines Systems.

Prüfen Sie anschließend:

Sind diese Veränderungen heute vollständig und korrekt in Ihrer CMDB dokumentiert? Wurden relevante Abhängigkeiten ebenfalls aktualisiert? Ist nachvollziehbar, wer für die Daten verantwortlich ist? Wäre eine Abweichung automatisch oder durch einen definierten Prozess erkannt worden? Und wie lange hätte es gedauert, sie zu korrigieren?

Wenn Sie diese Fragen zuverlässig beantworten können, haben Sie mehr als eine gute Datenbasis. Dann haben Sie einen funktionierenden Datenqualitätsprozess.

Wenn nicht, sollte die erste Frage nicht lauten, wann die nächste große Datenbereinigung startet.

Sondern: Warum konnte sich die Abweichung überhaupt so lange in der Dokumentation halten?

Denn entscheidend ist nicht, ob Ihre CMDB heute fehlerfrei aussieht. Entscheidend ist, wie gut Ihr Unternehmen mit der nächsten Abweichung umgeht.