CMDB-Datenqualität und Governance: Warum CMDB-Projekte scheitern

© BullRun

Warum CMDB-Datenqualität über den Projekterfolg entscheidet

Über Erfolg oder Scheitern eines Configuration-Management-Projekts entscheidet fast immer die CMDB-Datenqualität, nicht die gewählte Software. Ohne gepflegte Daten liefert selbst die teuerste CMDB nur ein Abbild der Vergangenheit.

Der CMDB-Themenschwerpunkt im IT Lifecycle Management streift diesen Zusammenhang bereits, hier geht es speziell um Datenqualität und Governance. Viele CMDB-Einführungen scheitern nämlich nicht an der Software, sondern daran, dass niemand die Verantwortung für die Datenpflege dauerhaft übernimmt. Davon hängt am Ende ab, ob sich die Investition auszahlt. Eingeordnet in das breitere IT Lifecycle Management ist die CMDB nur eines von mehreren Werkzeugen, die diese Art von Steuerung benötigen.

Digitalisierung als Belastungstest für die Steuerung

Wie groß diese Herausforderung ist, zeigen aktuelle Zahlen zur Digitalisierung in Deutschland. Laut der aktuellen Bitkom-Erhebung zur Digitalisierung 2024 hatte 2024 knapp jedes zweite der 606 befragten Unternehmen ab 20 Beschäftigten (48 Prozent) Probleme bei der Digitalisierung, deutlich mehr als 2023 mit 39 Prozent. Fehlende Zeit und Fachkräftemangel zählen zu den größten Hürden, also Ressourcen, die den eigentlichen CMDB Nutzen ausmachen. Fehlt die Pflege, passiert genau das Gegenteil vom Geplanten: Aus einem Entlastungswerkzeug wird eine zusätzliche Aufgabe, für die sich niemand zuständig fühlt. Häufiger fehlt eine klare Vorstellung davon, wer die CMDB dauerhaft pflegt und wie sie sich prüfen lässt.

Der stille Verfall nach dem Rollout

Eine frisch eingeführte CMDB wirkt zunächst vollständig und aktuell. Innerhalb weniger Monate weicht dieses Bild jedoch spürbar von der Realität ab, wenn niemand die laufende Pflege verantwortet. Vier Signale zeigen, dass an dieser Stelle nicht die Qualität der CMDB-Daten selbst, sondern die Steuerung dahinter fehlt:

• Kein benannter Verantwortlicher für einzelne CI-Klassen
• Keine Verbindung zwischen Änderungen im Betrieb und Aktualisierung der CMDB
• Keine wiederkehrende, unabhängige Prüfung der erfassten Systeme
• Keine Kennzahl, die den Zustand der Daten überhaupt sichtbar macht

Governance statt guter Vorsätze

An diesen vier Lücken lässt sich ablesen, dass CMDB Governance mehr braucht als eine gute Werkzeugauswahl. Die CMDB-Steuerung beginnt dort, wo Verantwortung, Prüfturnus und Messung fest im Betrieb verankert werden, statt sich auf gute Absichten zu verlassen. Warum scheitern CMDB-Projekte in der Praxis so häufig? Die Antwort liegt selten in der Software selbst.

Welche Dimensionen zeigen gute CMDB-Datenqualität?

Die Datenqualität der CMDB lässt sich an vier Dimensionen festmachen: Vollständigkeit, Aktualität, Konsistenz und Genauigkeit. Jede davon lässt sich einzeln prüfen und gezielt verbessern.

• Vollständigkeit: alle relevanten Systeme und ihre Abhängigkeiten sind erfasst
• Aktualität: der Stand entspricht der tatsächlichen IT-Landschaft
• Konsistenz: Angaben widersprechen sich nicht zwischen Systemen
• Genauigkeit: erfasste Attribute sind fehlerfrei und eindeutig

So sieht ein Konsistenzproblem in der Praxis aus: Meldet die CMDB einen Server als abgeschaltet, während die Firewall-Konfiguration ihn weiterhin als aktiv führt, liegt ein Widerspruch vor. Das gilt auch, wenn beide Einträge plausibel wirken. Solche Widersprüche bleiben oft monatelang unentdeckt, weil niemand beide Systeme regelmäßig abgleicht.

Qualität als Prozess, nicht als Zustand

Der Beitrag zum Data Lifecycle Management beschreibt dasselbe Prinzip für Daten im Allgemeinen: Qualität entsteht nicht einmalig, sondern über den gesamten Lebenszyklus hinweg. Die vier Dimensionen als festen Prüfrahmen zu etablieren, verschiebt die CMDB-Datenqualität von einer gefühlten Einschätzung zu einer messbaren Größe. Häufig liegt die eigentliche Ursache zudem im Datenmodell selbst, wenn es nicht zur gewachsenen Systemlandschaft passt. Eine gezielte Anpassung der Datenbankentwicklung schließt diese Lücke oft wirksamer als jede zusätzliche Richtlinie.

CMDB Governance: Rollen, Regeln und Freigaben

CMDB Governance bündelt genau jene Elemente, die zuvor fehlten: benannte Verantwortliche, feste Prüfzyklen und eine Verbindung zum laufenden Änderungsbetrieb im Tagesgeschäft. Ohne dieses Gerüst bleibt jede Kennzahl nur eine flüchtige Momentaufnahme.

CMDB-Steuerung in der Praxis

Ein Governance-Modell für die CMDB legt fest, wer welche CI-Klasse verantwortet, welche Freigaben vor einer Änderung nötig sind und wie oft eine unabhängige Prüfung stattfindet. Diese Struktur verzahnt sich zunehmend mit den Anforderungen der IT-Compliance, sobald ein CMDB Compliance Audit gegenüber Aufsichtsstellen nötig wird. Wichtig ist nur, dass sie gelebt wird, statt nur auf Papier zu existieren. Manche Anbieter nennen ein solches Regelwerk auch CMDB Governance Framework oder CMDB Governance Model. Ohne festen Turnus verliert selbst die beste Regel ihre Wirkung. Ganz ähnliche Ownership-Fragen kennt im Übrigen auch das Software Asset Management, bezogen auf Lizenzen statt Konfigurationselemente. Ein Rahmenwerk ohne gelebte Praxis verändert an der Datenqualität nichts.

Wer übernimmt CMDB Ownership?

Ohne ein klares Ownership-Modell veraltet eine CMDB nach unabhängigen Beobachtungen aus der ITSM-Praxis binnen etwa sechs Monaten spürbar. Die Verantwortung für die CMDB darf daher nicht diffus im Team liegen, sondern muss konkreten Rollen zugeordnet sein.

CMDB Ownership bedeutet in der Praxis: Für jede CI-Klasse (etwa Server, Netzwerkkomponenten oder Fachanwendungen) gibt es eine benannte Person oder ein Team, das Vollständigkeit und Aktualität der jeweiligen Einträge verantwortet. Diese Verantwortung lässt sich nicht outsourcen oder allein an eine Software delegieren, so leistungsfähig sie auch sein mag. Verantwortung für Daten bleibt immer eine organisatorische Aufgabe, technische Werkzeuge unterstützen sie nur.

CMDB Ownership statt Zufallspflege

Ohne feste CMDB-Verantwortlichkeit pflegt am Ende oft niemand konsequent, weil jeder Bereich davon ausgeht, dass sich ein anderer Bereich bereits darum kümmert. Genau in dieser Lücke zwischen mehreren Zuständigkeiten verlieren viele CMDB-Projekte langsam an Substanz. Ein einfaches, klar zugeschnittenes Rollenmodell schließt diese Lücke zuverlässig.

Vier Rollen, die jede CMDB braucht

• Verantwortliche pro CI-Klasse für Vollständigkeit und Aktualität der Einträge
• Prozessverantwortliche für die Verbindung zum Change-Management
• Freigabeinstanz für neue oder geänderte Konfigurationseinträge
• Prüfinstanz für die regelmäßige, unabhängige Kontrolle der Datenqualität

Eine CMDB RACI Matrix bildet diese vier Rollen häufig ab. Sie lassen sich in kleineren Teams bündeln, sollten aber nicht ganz entfallen. Gerade in gewachsenen Konzernstrukturen sorgt diese Klarheit dafür, dass eine CMDB nicht zwischen Abteilungen zerfällt.

Warum reicht ein Discovery-Tool allein nicht aus?

Discovery-Tools finden Systeme automatisch, weisen ihnen aber keine Verantwortlichen zu und definieren keine Beziehungen zwischen ihnen. Diese Lücke sorgt dafür, dass viele Unternehmen einem bloßen Tool-Kauf zu viel Vertrauen schenken.

Automatisierte Inventarisierung liefert eine solide Grundlage an Rohdaten, ersetzt aber weder die Einordnung in Geschäftsprozesse noch die laufende Pflege der Beziehungen zwischen Systemen. Ein Discovery-Tool erkennt, was existiert, nicht, wer dafür zuständig ist. Das Ergebnis ist oft ein großes, aber unübersichtliches Inventar mit vielen Objekten und wenig nutzbarer Struktur. Wird an dieser Stelle allein auf Technik gesetzt, verschiebt sich das Problem nur um einige Monate.

CMDB Audits: Rhythmus und Inhalt

Ein CMDB Audit sollte für geschäftskritische Systeme mindestens vierteljährlich erfolgen, für weniger kritische Bereiche reicht ein halbjährlicher Turnus. Entscheidend ist weniger die Häufigkeit selbst als ein feststehendes Protokoll.

Ein belastbares Audit-Protokoll enthält typischerweise:

• Zeitpunkt der Prüfung und verantwortliche Person
• geprüfte CI-Typen und eingesetzte Prüfmethode
• festgestellte Abweichungen zwischen CMDB und tatsächlichem Zustand
• Ursachenanalyse zu den gefundenen Abweichungen
• vereinbarte Korrekturmaßnahmen mit festen Terminen

Diese Struktur verhindert, dass eine Prüfung zur reinen Formsache wird.

Reifegrad vor Werkzeug

Governance lässt sich nicht in einem einzigen Schritt einführen. Ein CMDB Maturity Model unterscheidet dabei typischerweise eine unstrukturierte Ausgangslage, erste feste Abläufe, gemessene Qualität und eine vollständig gesteuerte, auditierte Praxis. Stufen lassen sich dabei nicht überspringen, ohne zusätzliche Unordnung zu erzeugen. Ein Unternehmen, das direkt von chaotischer Pflege zu vollautomatisierter Steuerung springen will, schafft meist neue Baustellen, statt alte zu schließen. Branchenweite Schätzungen gehen von Kosten in zweistelliger Millionenhöhe pro Jahr aus, die allein durch mangelhafte Datenqualität entstehen. Diese Größenordnung zeigt, warum sich der schrittweise Aufbau von CMDB Governance auszahlt, lange bevor ein Prüfbericht das erste Mal negativ auffällt.