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

CMDB-Datenqualität entscheidet darüber, ob eine Configuration Management Database im Ernstfall verlässliche Antworten liefert oder nur eine veraltete Momentaufnahme bleibt. Für CIOs in Unternehmen und Konzernen zeigt dieser Beitrag, warum viele CMDB-Projekte trotz solider Software an fehlender CMDB Governance scheitern und welche Rollen, Kennzahlen und Prüfroutinen eine CMDB dauerhaft verlässlich halten.
Mitarbeiterin prüft im Büro ein ausgedrucktes Prüfprotokoll, während Kollegen im Hintergrund an Laptops arbeiten, Symbolbild für die Kontrolle der CMDB-Datenqualität im Team.
© 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:

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.

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

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:

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.

FAQs

Wie lässt sich CMDB-Datenqualität im laufenden Betrieb messen? keyboard_arrow_down keyboard_arrow_up
Drei CMDB KPIs liefern eine verlässliche Einschätzung: der Anteil vollständig gepflegter Einträge pro CI-Klasse, die Übereinstimmungsrate zwischen CMDB und Discovery-Tool bei automatischen Abgleichen sowie der Anteil an Einträgen, die seit einer festgelegten Frist nicht mehr aktualisiert wurden. Kritische Systeme erhalten dabei strengere Schwellenwerte, wie es CMDB Best Practices empfehlen.
Was kostet mangelnde CMDB-Datenqualität ein Unternehmen wirklich? keyboard_arrow_down keyboard_arrow_up
Eine genaue CMDB-spezifische Zahl existiert kaum, branchenübergreifende Schätzungen gehen jedoch von durchschnittlich zweistelligen Millionenbeträgen pro Jahr aus, die allein durch fehlerhafte Daten entstehen. Ein erheblicher Teil der Arbeitszeit in betroffenen Teams fließt zudem in die nachträgliche Korrektur statt in produktive Aufgaben. Ein belastbarer CMDB Business Case sollte solche Folgekosten von Anfang an einkalkulieren.
Wie unterstützt TenMedia beim Aufbau einer nachhaltigen CMDB Governance? keyboard_arrow_down keyboard_arrow_up
TenMedia entwickelt individuelle Schnittstellen, die Discovery-Tools, Fachanwendungen und Verzeichnisdienste automatisiert mit einer CMDB abgleichen, damit die CMDB Reconciliation nicht mehr von Hand erfolgen muss. Wo Standard-Datenmodelle nicht zur gewachsenen Systemlandschaft passen, übernimmt TenMedia die individuelle Anpassung der zugrunde liegenden Datenbank und bildet Rollen sauber auf CI-Klassen ab. Über laufende Wartungs- und Supportverträge lässt sich die Pflege dauerhaft verankern, statt sie nach Projektende auslaufen zu lassen. Ergänzend entwickelt TenMedia individuelle Dashboards für Kennzahlen, wenn Standardwerkzeuge keine passende Auswertung liefern. So lässt sich die CMDB-Datenqualität über Jahre hinweg auf einem verlässlichen Niveau halten.