Die Bereinigung, die nie hält
Jedes CMDB-Sanierungsprojekt, das ich begleitet habe, beginnt gleich.
Jemand zieht einen Report. Die Daten sehen katastrophal aus. Das Leadership gibt einen Cleanup-Sprint frei. Ein Team verbringt sechs Wochen damit, CIs zu bereinigen, Duplikate zu entfernen und Discovery neu laufen zu lassen.
Neunzig Tage später sehen die Daten wieder katastrophal aus.
Dieser Zyklus wiederholt sich, bis die Organisation das Vertrauen in die CMDB vollständig verliert. Dann wird sie zum Regalprodukt, ein Häkchen, das bei der Plattform-Implementierung gesetzt wurde und in der Praxis ignoriert wird.
Und hier ist die Sache, die niemand laut aussprechen will:
Die Daten sind nicht falsch, weil Discovery versagt hat. Die Daten sind falsch, weil niemand das Betriebsmodell drumherum verantwortet.
Sie haben kein CMDB-Problem. Sie haben ein Ownership-Problem.
Warum Discovery nicht das Problem ist
Das Tool funktioniert. Das Betriebsmodell nicht.
ServiceNow Discovery, Service Mapping und Drittanbieter-Integrationen können Ihre CMDB mit akkuraten Daten befüllen. Das tun sie jeden Tag in reifen Organisationen.
Aber Discovery erfasst nur, was es zu einem bestimmten Zeitpunkt sehen kann.
Es weiß nicht, wer den neuen Server genehmigt hat. Es weiß nicht, dass ein Business Service im letzten Quartal umstrukturiert wurde. Es weiß nicht, dass ein Team 40 CIs stillgelegt hat, ohne jemanden zu informieren.
Das technische Tooling ist eine Datenquelle. Es ist kein Governance-Framework.
Wenn das Tooling für schlechte Daten verantwortlich gemacht wird, betrachten Sie das Symptom und nennen es die Ursache.
Was „gemeinsame Verantwortung” wirklich bedeutet.
Öffnen Sie jetzt Ihr CMDB-RACI.
Wenn das Wort „gemeinsam” in mehr als zwei Spalten auftaucht, haben Sie kein RACI. Sie haben ein Dokument, das es allen ermöglicht, davon auszugehen, dass sich jemand anders darum kümmert.
“Gemeinsam” ist der Ort, an dem Verantwortlichkeit stirbt.
Wenn alle verantwortlich sind, ist niemand verantwortlich. Wenn niemand verantwortlich ist, verfallen die Daten. Schnell.
Die 5 strukturellen Lücken, die jede CMDB zerstören
Ich habe dieses Muster in genügend Unternehmen gesehen, um es beim Namen zu nennen. Es gibt fünf Lücken, und sie treten fast immer gemeinsam auf.
1. Keine namentlich benannten CI-Data-Stewards.
Nicht ein “CMDB-Team.” Nicht “das Plattform-Team.” Namentlich benannte Personen, die für bestimmte CI-Klassen verantwortlich sind.
Jemand verantwortet die Server-CIs. Jemand anderes verantwortet die Application-CIs. Jemand verantwortet die Business-Service-Maps.
Wenn Sie diese Personen nicht namentlich benennen können, haben Sie sie nicht.
2. Keine Attestierungszyklen.
Data Stewards werden nicht nur benannt. Sie attestieren — in einem regelmäßigen Turnus — dass die Daten in ihren CI-Klassen korrekt sind.
Nicht jährlich. Nicht “wenn wir mal dazu kommen.”
Monatlich oder quartalsweise, je nach Volatilität der CI-Klasse. Dokumentiert. Nachverfolgt.
Die meisten Organisationen haben keinerlei Attestierungszyklen. Die Daten wurden bei der Implementierung „validiert” und danach nie wieder angeschaut.
3. Keine Konsequenzen bei schlechten Daten.
Was passiert, wenn ein CI-Datensatz falsch ist?
In den meisten Organisationen: nichts. Der Datensatz bleibt liegen. Vielleicht fällt es jemandem bei einem Major Incident auf. Vielleicht bemerkt es nie jemand.
Wenn schlechte Daten keine Konsequenzen haben, gibt es keinen Anreiz, gute Daten zu pflegen. Menschliche Natur. Kein Technologieproblem.
4. Keine Integrations-Governance.
Ihre CMDB wird wahrscheinlich von mehreren Quellen gespeist. Discovery. Eine Cloud-Management-Plattform. Manuelle Importe. HR-Feeds. ITAM-Synchronisationen.
Wer steuert, was passiert, wenn diese Quellen sich widersprechen?
Wer entscheidet über die autoritative Quelle für jedes CI-Attribut? Wer überwacht Reconciliation-Fehler in der IRE?
Wenn die Antwort „niemand konkret” lautet, ist Ihre CMDB eine Datenkollisionszone.
5. Kein Bezug zur nachgelagerten Nutzung.
Das ist die Lücke, die alle anderen unsichtbar macht.
Wenn Change Management die CMDB nicht für die Auswirkungsanalyse nutzt, fällt es niemandem auf, wenn die Daten falsch sind.
Wenn Incident Management keine Service Maps für die Zuweisung nutzt, interessiert es niemanden, ob die Maps veraltet sind.
Wenn SPM und ITAM keine CI-Beziehungen konsumieren, gibt es keine Feedbackschleife.
Die CMDB wird nur dann gesteuert, wenn sie für die Prozesse relevant ist, die von ihr abhängen. Wenn nichts von ihr abhängt, verfällt sie in aller Stille.
Das Governance-Modell, das tatsächlich funktioniert
Das ist nicht kompliziert. Es ist nur unbequem. Weil es erfordert, Namen zu nennen, Fristen zu setzen und Menschen in die Pflicht zu nehmen.
Ownership auf CI-Klassen-Ebene zuweisen.
Jede CI-Klasse in Ihrer CMDB braucht einen namentlich benannten Data Steward.
Kein Team. Eine Person.
Server. Applications. Business Services. Netzwerkkomponenten. Cloud-Ressourcen. Datenbankinstanzen.
Jede Klasse bekommt einen Owner. Dieser Owner ist verantwortlich für Vollständigkeit, Genauigkeit und Aktualität der Datensätze in seiner Klasse.
Dokumentieren Sie es. Veröffentlichen Sie es. Machen Sie es sichtbar.
Einen Attestierungsrhythmus aufbauen — kein Projekt.
Attestierung ist keine einmalige Bereinigung. Es ist ein wiederkehrender operativer Rhythmus.
Legen Sie einen Turnus fest. Quartalsweise ist ein vernünftiger Startpunkt für die meisten CI-Klassen. Monatlich für hochvolatile Klassen wie Cloud Compute.
In jedem Zyklus prüft der Data Steward eine definierte Menge an Datensätzen, bestätigt die Richtigkeit, markiert Ausnahmen und schließt die Attestierung ab.
Sie können diesen Workflow in ServiceNow abbilden. Ein einfaches Catalog Item, ein geplanter Report und eine Aufgabenzuweisung. Keine Custom App erforderlich.
Datenqualität mit ServiceNow-Reporting sichtbar machen.
CMDB-Health-Dashboards existieren in ServiceNow aus gutem Grund. Nutzen Sie sie.
Aber gehen Sie über den Standard-Health-Score hinaus. Erstellen Sie Reports, die zeigen:
- Veraltete CIs (kein Discovery-Update seit X Tagen)
- Verwaiste CIs (keine Beziehung zu einem Business Service)
- CIs mit fehlenden Pflichtattributen
- Attestierungs-Abschlussquoten pro Steward
Bringen Sie das auf ein Dashboard. Zeigen Sie es in Ihrem monatlichen CMDB-Governance-Board-Meeting. Ja, Sie brauchen eines.
CMDB-Gesundheit mit Change- und Incident-Ergebnissen verknüpfen.
Hier wird es konkret.
Erfassen Sie, wie viele Change-Kollisionen aufgrund ungenauer CI-Beziehungen aufgetreten sind. Erfassen Sie, wie viele Incidents falsch zugewiesen wurden, weil eine Service Map veraltet war.
Wenn Sie CMDB-Datenqualität mit operativen Ergebnissen verknüpfen, wird das Leadership aufmerksam. Wenn das Leadership aufmerksam wird, folgen Budget und Verantwortlichkeit.
Was Sie am Montagmorgen tun sollten
Hören Sie auf, den nächsten Cleanup-Sprint zu planen. Tun Sie stattdessen Folgendes.
- Prüfen Sie Ihr aktuelles RACI. Wenn das Wort „gemeinsam” mehr als zweimal vorkommt, schreiben Sie es mit namentlich benannten Ownern neu.
- Identifizieren Sie Ihre Top-5-CI-Klassen nach Volumen und nachgelagerter Auswirkung. Weisen Sie noch diese Woche jeder Klasse einen namentlich benannten Steward zu.
- Definieren Sie einen Attestierungsturnus. Starten Sie quartalsweise. Tragen Sie es im Kalender ein. Erstellen Sie eine wiederkehrende Aufgabe in ServiceNow.
- Setzen Sie ein CMDB-Governance-Board auf. Monatlich. 30 Minuten. Data Stewards, Platform Owner und ein Process Owner aus Change oder Incident. Prüfen Sie das Health-Dashboard. Prüfen Sie den Attestierungsstatus. Treffen Sie Entscheidungen.
- Verbinden Sie einen nachgelagerten Prozess. Nehmen Sie Change Management. Machen Sie die CI-Zuordnung bei jedem Change Request zur Pflicht. Beobachten Sie, wie schnell Datenqualität zum Problem aller wird.
Hören Sie auf, die Fassade zu reinigen. Reparieren Sie das Dach.
Sie können Discovery stündlich laufen lassen. Sie können ein Team beauftragen, jeden Quartal Datensätze zu bereinigen. Sie können ein weiteres Tool kaufen.
Nichts davon wird etwas bewirken, wenn niemand das Betriebsmodell verantwortet.
Die CMDB verrottet nicht wegen schlechter Technologie. Sie verrottet wegen fehlender Governance.
Benennen Sie die Owner. Legen Sie den Turnus fest. Bauen Sie die Feedbackschleife auf. Sorgen Sie dafür, dass die Daten für die Prozesse relevant sind, die sie konsumieren.
Das ist die Lösung. Nicht glamourös. Aber die einzige, die länger als 90 Tage hält.
