Die CMDB ist nicht das Problem. Ihr Betriebsmodell ist es.

Warum technische Plattformen funktionieren, aber trotzdem niemand ihren Daten vertraut

Die CMDB ist eingeführt. Die Daten sind migriert. Die Schnittstellen funktionieren. Das Projekt ist abgeschlossen.

Dann kommt der nächste kritische Incident. Jemand öffnet eine Excel-Liste. Ein anderer ruft den Kollegen an, der „die Umgebung kennt“. Ein Dritter prüft die Information noch einmal im Quellsystem. Die CMDB ist nicht ausgefallen. Das Vertrauen in sie ist ausgefallen.

Genau daran entscheidet sich der Erfolg einer CMDB. Nicht an der Zahl der importierten Configuration Items, nicht an der Größe des Datenmodells und auch nicht daran, ob zum Go-Live alle geplanten Schnittstellen funktionieren. Entscheidend ist, ob die Informationen so belastbar sind, dass eine Organisation ihre täglichen Entscheidungen darauf stützt.

Eine CMDB ist kein abgeschlossenes Softwareprojekt. Sie ist eine organisatorische Fähigkeit, die dauerhaft betrieben werden muss.

 

Das Projekt beginnt mit der falschen Frage

Viele CMDB-Initiativen starten mit einer Bestandsaufnahme: Welche Objekte müssen wir dokumentieren? Server, Switches, Anwendungen, Datenbanken, Verträge, Standorte, Cloud-Ressourcen, Schnittstellen, Verantwortliche und Lifecycle-Informationen. Die Liste wird länger, der Scope größer und das Datenmodell komplexer.

Die wichtigere Frage lautet jedoch: Welche Entscheidungen wollen wir mit diesen Informationen besser treffen?

• Sollen kritische Incidents schneller eingegrenzt werden?
• Sollen Changes verlässlicher auf ihre Auswirkungen bewertet werden?
• Muss bei einer Migration klar sein, welche Systeme gemeinsam verändert werden müssen?
• Soll nachvollziehbar werden, welche Infrastruktur einen geschäftskritischen Service unterstützt?

Erst aus diesen Anwendungsfällen ergibt sich, welche Objekte, Beziehungen und Detailtiefe tatsächlich benötigt werden. Wer zuerst möglichst viel dokumentieren will, baut schnell eine große Datenbasis auf, aber noch lange keine verlässliche Entscheidungsgrundlage.

 

Vollständigkeit ist die falsche Zielgröße

Der Anspruch einer vollständigen CMDB klingt vernünftig. In einer dynamischen IT-Landschaft ist Vollständigkeit jedoch kein dauerhafter Zustand. Virtuelle Maschinen entstehen und verschwinden, Anwendungen werden aktualisiert, Netzwerkverbindungen verändern sich, Geräte werden ausgetauscht und Verantwortlichkeiten wechseln.

Vollständigkeit wird dadurch schnell zu einer Kennzahl, die gut aussieht, aber wenig über den praktischen Wert aussagt. Wichtiger sind Relevanz, Aktualität, Beziehungsqualität und Verantwortlichkeit.

Eine kleinere Datenbasis, die für einen kritischen Service belastbar ist, ist mehr wert als ein nahezu vollständiges Modell, dem niemand vertraut.

Nicht jede Information muss in der CMDB liegen. Aber jede Information, auf deren Basis eine kritische Entscheidung getroffen wird, muss verlässlich sein. Das ist ein anderer Anspruch als möglichst viele Felder zu füllen.

 

Automatisierung liefert Fakten, nicht Bedeutung

Discovery, Schnittstellen und automatisierte Synchronisation sind unverzichtbare Bausteine. Eine hybride IT-Landschaft lässt sich nicht dauerhaft manuell aktuell halten. Automatisierung kann erkennen, dass ein Server existiert, welches Betriebssystem darauf läuft oder welche IP-Adresse vergeben ist.

Sie beantwortet deshalb aber noch nicht automatisch die entscheidenden Fragen: Wie kritisch ist dieser Server für das Unternehmen? Welcher Geschäftsservice hängt davon ab? Welche Kunden oder Standorte wären betroffen? Wer trägt die fachliche Verantwortung? Welche Wiederherstellungsreihenfolge gilt?

Automatisierung liefert die Fakten. Die Bedeutung liefert das Unternehmen. Ein belastbares Informationsmodell entsteht erst aus der Verbindung von beidem.

Auch Konflikte zwischen Datenquellen lösen sich nicht von selbst. Es muss klar definiert sein, welches System für welche Information führend ist und wie mit Abweichungen umgegangen wird. Sonst entsteht keine automatisierte Datenqualität, sondern automatisierte Unsicherheit.

 

Datenqualität ist eine Eigentums- und Führungsfrage

Vor der Einführung wird häufig viel Aufwand in die Datenqualität investiert. Dubletten werden entfernt, Pflichtfelder ergänzt, Benennungen vereinheitlicht und Fehlerlisten abgearbeitet. Nach dem Go-Live sinkt diese Aufmerksamkeit oft deutlich. Genau hier beginnt der schleichende Vertrauensverlust.

Einzelne Informationen stimmen nicht mehr. Anwender beginnen gegenzuprüfen. Lokale Listen entstehen. Änderungen werden nicht konsequent dokumentiert. Mit jeder Abweichung sinkt das Vertrauen ein Stück weiter.

Die technische Frage lautet dann: Wie verbessern wir die Datenqualität? Die wichtigere organisatorische Frage lautet: Wer ist dafür verantwortlich, dass sie erhalten bleibt?

• Wer verantwortet die Informationen zu einem Server oder einer Netzwerkverbindung?
• Wer pflegt die Beziehungen zwischen Anwendungen und Geschäftsservices?
• Wer entscheidet, wenn zwei Quellsysteme unterschiedliche Werte liefern?
• Wer trägt die Konsequenz, wenn eine fehlende Beziehung zu einer falschen Change-Entscheidung führt?

Solange diese Fragen ungeklärt bleiben, wird Datenqualität zur Gemeinschaftsaufgabe. Und damit häufig zu einer Aufgabe, für die sich am Ende niemand vollständig verantwortlich fühlt.

Datenqualität ist keine technische Eigenschaft. Sie ist das Ergebnis von Eigentum, Anreizen und Konsequenz.

Governance muss dabei kein umfangreiches Regelwerk sein. Es braucht vor allem klare Vereinbarungen: Wer liefert welche Information? Wer verantwortet sie? Welches System führt im Konfliktfall? Welche Qualität ist für welchen Anwendungsfall ausreichend?

 

Der Go-Live ist nicht das Ziel

CMDB-Projekte werden häufig wie klassische Softwareprojekte organisiert: Anforderungen, Konzeption, Implementierung, Migration, Test, Go-Live. Danach gilt das Projekt als abgeschlossen. Für eine CMDB beginnt mit dem Go-Live jedoch erst die entscheidende Phase.

Jetzt verändern sich Daten, Schnittstellen müssen dauerhaft funktionieren, neue Anforderungen entstehen und Qualitätsprobleme werden sichtbar. Jetzt zeigt sich, ob die vorgesehenen Prozesse im Alltag funktionieren und ob Informationen tatsächlich aktuell gehalten werden können.

Eine CMDB braucht deshalb nicht nur ein Einführungsprojekt. Sie braucht ein Betriebsmodell. Dazu gehören klare Verantwortlichkeiten, definierte Qualitätsmechanismen, ausreichende Kapazitäten für Pflege und Weiterentwicklung sowie ein regelmäßiger Abgleich zwischen Informationsmodell und realer Umgebung.

Wer diesen Betrieb nicht von Anfang an mitdenkt, riskiert, dass die CMDB technisch weiterläuft, für die Organisation aber schrittweise an Bedeutung verliert.

 

Eine CMDB muss Arbeit reduzieren

Akzeptanz entsteht vor allem dann, wenn eine CMDB konkrete Arbeit erleichtert. Wenn Mitarbeitende Informationen lediglich zusätzlich pflegen müssen, ohne einen erkennbaren Vorteil zu haben, wird die Datenqualität langfristig leiden.

Anders sieht es aus, wenn ein Service Desk schneller erkennt, welche Systeme von einem Incident betroffen sind, wenn ein Change Manager Abhängigkeiten direkt nachvollziehen kann oder wenn Infrastrukturteams Informationen nicht mehrfach in unterschiedlichen Werkzeugen pflegen müssen.

Daten werden dann nicht gepflegt, weil sie „in der CMDB stehen müssen“, sondern weil andere Prozesse auf diese Informationen angewiesen sind. Der Nutzen liegt nicht in der Dokumentation selbst, sondern in einer schnelleren und besseren Entscheidung.

Das Problem schlechter CMDB-Daten ist nicht, dass ein Feld leer bleibt. Das Problem ist, dass unter Zeitdruck eine falsche Entscheidung getroffen wird.

 

Vom Ablageort zum Entscheidungssystem

Eine CMDB ist dann wertvoll, wenn sie mehr leistet als die Ablage technischer Informationen. Sie muss Zusammenhänge so abbilden, dass die Organisation Auswirkungen bewerten, Risiken priorisieren und Veränderungen kontrolliert umsetzen kann.

Damit ergänzt die CMDB die Perspektive des digitalen Zwillings. Der digitale Zwilling macht Beziehungen und Auswirkungen sichtbar. Das Betriebsmodell sorgt dafür, dass diese Sicht nicht zur Momentaufnahme wird.

Die Entwicklung lässt sich deshalb in drei Schritten beschreiben:

1. Transparenz schaffen: Welche Systeme, Services, Daten und Abhängigkeiten existieren?
2. Zusammenhänge verstehen: Was passiert, wenn sich eine Komponente verändert oder ausfällt?
3. Entscheidungsfähigkeit organisieren: Wie bleibt diese Information verlässlich und wird im Alltag genutzt?

 

Erst der dritte Schritt macht aus technischer Transparenz eine dauerhafte Fähigkeit.

 

Der Praxistest für Ihre CMDB

Nehmen Sie einen konkreten Prozess aus Ihrem Alltag: einen kritischen Incident, einen größeren Change, eine bevorstehende Migration oder die Ablösung eines Systems. Versuchen Sie anschließend, die notwendigen Entscheidungen ausschließlich mit den Informationen aus Ihrer bestehenden CMDB oder IT-Dokumentation zu treffen.

Wo müssen Mitarbeitende zusätzlich nachfragen? Wo wird eine Excel-Liste geöffnet? Welches Quellsystem wird vorsichtshalber noch einmal geprüft? Und an welcher Stelle lautet die Antwort noch immer: „Das weiß wahrscheinlich Kollege XY“?

Sobald jemand unter Zeitdruck auf Excel, ein zweites System oder das Erfahrungswissen einer Einzelperson ausweichen muss, kennen Sie die wichtigste Lücke Ihrer CMDB.

Der Test misst nicht, ob Ihre CMDB technisch funktioniert. Er misst, ob Ihre Organisation ihr vertraut.

 

Wie FNT Services unterstützt

Eine CMDB oder IT-Dokumentationslösung sollte nicht isoliert als Softwareprojekt betrachtet werden. Entscheidend ist das Zusammenspiel aus Daten, Prozessen, Verantwortlichkeiten und technischen Integrationen.

FNT Services unterstützt Unternehmen dabei, aus vorhandenen Daten eine belastbare Entscheidungsgrundlage zu entwickeln:

• Analyse der bestehenden Quellen und ihrer tatsächlichen Qualität
• Modellierung technischer und fachlicher Abhängigkeiten entlang konkreter Anwendungsfälle
• Integration geeigneter Quellsysteme und automatisierte Aktualisierung relevanter Informationen
• Aufbau klarer Rollen, Datenverantwortlichkeiten und Qualitätsmechanismen
• Weiterentwicklung und Absicherung des laufenden Betriebs

FNT Command bildet dabei die technologische Grundlage, um Infrastrukturinformationen, Services und Abhängigkeiten in einen nutzbaren Zusammenhang zu bringen. Der Ausgangspunkt ist jedoch nicht die Produktdemo, sondern die Entscheidung, die ein Unternehmen künftig schneller und sicherer treffen möchte.

Am Ende geht es nicht darum, möglichst viel zu dokumentieren. Es geht darum, im Zweifelsfall in Minuten, statt in Stunden entscheiden zu können.

 

Die CMDB ist kein Selbstzweck

Eine CMDB wird nicht dadurch wertvoll, dass viele Configuration Items in ihr liegen. Sie wird wertvoll, wenn die richtigen Informationen aktuell, miteinander verbunden und für konkrete Prozesse nutzbar sind.

Dafür braucht es Technologie. Es braucht aber ebenso klare Entscheidungen über Scope, Verantwortung, Qualität und Betrieb. Wer diese Entscheidungen nicht trifft, kauft ein Werkzeug und bekommt eine Momentaufnahme.

Der wahre Test einer CMDB ist nicht der Go-Live. Der wahre Test ist der Moment, in dem jemand unter Zeitdruck entscheiden muss, ob er ihren Daten vertraut.

Digitale Souveränität beginnt mit Transparenz. Transparenz entsteht durch Zusammenhänge. Und ihre Wirkung bleibt nur erhalten, wenn eine Organisation diese Zusammenhänge dauerhaft verantwortet.

Wenn Sie herausfinden möchten, wie belastbar Ihre CMDB oder IT-Dokumentation im Alltag tatsächlich ist, nennen Sie drei Entscheidungen, die Sie in den nächsten zwölf Monaten sicher treffen müssen. Prüfen Sie, ob Ihre heutige Informationsbasis dafür ausreicht. Genau dort beginnt der eigentliche Handlungsbedarf.