CMDB und Change Management: Impact-Analyse vor jeder Änderung

© ArLawKa

Was ist der Zusammenhang zwischen CMDB und Change Management?

Eine CMDB (Configuration Management Database) liefert dem Change Management die Faktenbasis, mit der sich das Risiko einer Änderung schon vor der Freigabe beziffern lässt. Fehlt diese Verknüpfung, entscheidet am Ende Bauchgefühl statt Datenlage, und das wird teuer. Der New Relic Observability Forecast 2025 beziffert die mittleren Jahreskosten schwerwiegender IT-Ausfälle deutscher Unternehmen auf 147 Millionen Euro. Fast die Hälfte der befragten Betriebe meldet mindestens wöchentlich einen solchen Vorfall. Änderungen an IT-Systemen zählen laut der Studie zu den drei häufigsten Ursachen, ein erheblicher Teil dieser Kosten ließe sich mit einer sauberen Impact-Analyse vermeiden. Change Management zählt damit zu den zentralen Disziplinen des IT Service Management.

Risiken durch ungeklärte Abhängigkeiten

Der CMDB-Themenschwerpunkt im IT Lifecycle Management beschreibt, wie Configuration Items erfasst und miteinander verknüpft werden. Eine Änderung betrifft dabei selten nur ein einzelnes System, sondern immer auch das Geflecht an Abhängigkeiten darum herum. Für die Führungsebene zählt vor allem eines: Jede ungeklärte Abhängigkeit ist ein unkalkuliertes Risiko im Budget. Im umfassenderen IT Lifecycle Management zeigt sich, dass diese Steuerung nicht bei einzelnen Werkzeugen endet, sondern die gesamte Nutzungsdauer von IT-Investitionen betrifft.

Bei KRITIS-Betreibern reicht das Risiko über den Kostenpunkt hinaus: Aufsichtsbehörden verlangen zunehmend den Nachweis, dass Änderungen an kritischen Systemen bewertet wurden, bevor sie umgesetzt werden. Das umfassendere Lebenszyklusmanagement in Behörden ordnet diese Nachweispflicht in den größeren Kontext der öffentlichen Verwaltung ein. Ein dokumentierter Change-Prozess schützt damit auch die persönlich haftende Geschäftsführung.

Change Advisory Board: Wer im Unternehmen über riskante Änderungen entscheidet

Ein Change Advisory Board bündelt die Freigabe für Änderungen, deren Risiko über das Tagesgeschäft hinausgeht. Es setzt sich aus Vertretern der betroffenen Fachbereiche, der IT-Sicherheit und des Betriebs zusammen und trägt damit einen Teil der Verantwortung, die sonst allein auf der Geschäftsführung lastet. Das Change Advisory Board wägt dabei vor allem eines ab: Risiko gegen Nutzen einer Änderung, das sind seine zentralen Aufgaben. Ohne aktuelle CMDB-Daten verkommt dieses Gremium zur reinen Formsache, die Risiken nicht wirklich bewertet, sondern nur dokumentiert.

Ein Großteil ungeplanter Änderungen entsteht im Rahmen laufender Wartung und Betreuung bestehender Anwendungen, genau dort setzt eine belastbare Impact-Analyse zuerst an, weil hier die meisten Berührungspunkte zu anderen Systemen liegen. Kostentreiber, die dabei regelmäßig unterschätzt werden:

• Ungeplante Ausfallzeiten und entgangener Umsatz während der Störung
• Vertragsstrafen und SLA-Nachzahlungen gegenüber Kunden
• Zusätzliche Personalkosten durch Nacht- und Wochenendeinsätze zur Fehlerbehebung
• Reputationsschäden bei kundenseitig sichtbaren Systemausfällen
• Nachweispflichten gegenüber Aufsichtsbehörden bei regulierten Branchen
• Folgekosten durch wiederholte, nicht dokumentierte Notfalländerungen

Jeder dieser Posten lässt sich schwer beziffern, solange niemand systematisch nachvollzieht, welche Änderung welchen Ausfall ausgelöst hat. Genau diese Nachvollziehbarkeit liefert eine gepflegte CMDB in Verbindung mit einem strukturierten Change-Prozess.

Wie funktioniert eine Impact-Analyse vor einer IT-Änderung?

Jede Impact-Analyse beginnt mit einem Change Request, der das geplante Vorhaben kurz beschreibt. Von dort aus verfolgt sie die Abhängigkeiten eines Configuration Items in der CMDB und schätzt anhand dieser Kette ab, welche Services, Kundengruppen und internen Abläufe von einer geplanten Änderung betroffen wären. Für die Geschäftsführung heißt das konkret: Welches Risiko ist mit dieser Änderung finanziell und operativ verbunden, und lohnt sich die Freigabe im aktuellen Zeitfenster? Je vollständiger die hinterlegten Beziehungen, desto verlässlicher lässt sich diese Frage beantworten.

Wie belastbar diese Antwort ausfällt, hängt an der Datenqualität der CMDB selbst, ein Thema, das der Schwesterbeitrag zur CMDB-Datenqualität und Governance vertieft. In der Praxis lässt sich eine belastbare Impact-Analyse an wenigen, klar prüfbaren Fragen festmachen, die vor jeder Freigabe beantwortet sein sollten:

• Welches Configuration Item soll geändert werden?
• Welche weiteren Systeme hängen direkt oder indirekt daran?
• Welche Kundengruppen oder internen Abläufe sind betroffen?
• Wie kritisch sind die betroffenen Systeme für den laufenden Betrieb?
• Existiert ein Rollback-Plan für den Fall eines Fehlschlags?
• Welcher Freigabeweg passt zum ermittelten Risiko?

Beispiel: Ein Datenbank-Update mit Signalwirkung

Ein geplantes Update einer zentralen Datenbank wirkt zunächst wie reine Routine. Ein Blick in die CMDB zeigt jedoch, dass drei Fachanwendungen und ein externes Berichtssystem auf dieselbe Datenbank zugreifen. Ohne diesen Blick hätte das Wartungsfenster mitten in die Kernarbeitszeit des Berichtssystems gefallen, mit spürbarem Ausfallrisiko für die betroffene Fachabteilung. Solche Zusammenhänge lassen sich selten mit Standard-Software abbilden, sobald die eigene Systemlandschaft historisch gewachsen ist. Angepasste Datenbankentwicklung modelliert CMDB-Beziehungen so, dass sie die tatsächliche Infrastruktur widerspiegeln. Genau in dieser Modellierungstiefe entscheidet sich, ob eine Impact-Analyse verlässlich ist oder nur gut aussieht. Betrifft eine Änderung zusätzlich Aufbewahrungs- oder Löschfristen, greift ergänzend das Data Lifecycle Management.

Was unterscheidet Standard, Normal und Emergency Changes?

Standard Changes sind vorab genehmigte, risikoarme Routineänderungen mit bekanntem Ablauf und lassen sich ohne Einzelprüfung freigeben. Normal Changes durchlaufen dagegen eine individuelle Risikobewertung, bevor sie umgesetzt werden dürfen. Emergency Changes verlassen den regulären Rhythmus vollständig, weil ein akutes Problem sofortiges Handeln verlangt und eine Prüfung erst im Nachgang stattfinden kann. Diese Einteilung entscheidet direkt darüber, wie viel Zeit und Aufwand ein einzelner Change tatsächlich bindet.

• Standard Change: bekanntes Vorgehen, geringes Risiko, Freigabe ohne Einzelprüfung
• Normal Change: individuelle Bewertung vor der Freigabe, planbarer Vorlauf
• Emergency Change: sofortige Umsetzung, Prüfung und Dokumentation im Nachgang
• Wiederkehrender Change: standardisierte Vorlage, weiterhin regelmäßig überwacht

Für die Geschäftsführung liegt der eigentliche Hebel selten im Einzelfall: Ziel ist es, möglichst viele Standard Changes automatisiert freigeben zu können, ohne bei Normal und Emergency Changes an Kontrolle zu verlieren.

Change Advisory Board: Wann sich automatisierte Freigabe finanziell lohnt

Wo die CMDB durchgängig aktuell gepflegt ist, lässt sich ein Standard Change ohne Umweg über das komplette Change Advisory Board freigeben. Das System prüft automatisiert, ob die hinterlegten Bedingungen erfüllt sind, und gibt die Änderung frei, sobald keine kritische Abhängigkeit betroffen ist. Diese Automatisierung entlastet das Gremium spürbar und schafft Raum für die tatsächlich risikobehafteten Fälle. Für mittelständische Unternehmen mit vielen wiederkehrenden Änderungen macht dieser Effekt den Unterschied zwischen einer IT-Abteilung, die reagiert, und einer, die vorausplant.

Unabhängig von der genauen Zahl an Phasen (manche Rahmenwerke unterscheiden vier, andere sieben Schritte) folgt Change Management nach ITIL demselben Grundmuster aus Anfrage, Bewertung, Freigabe, Umsetzung und Überprüfung, an dem jemand verantwortlich hinschauen muss.

Nach dem Rollout: CMDB und Change Management im Regelkreis

Sobald ein Change erfolgreich umgesetzt wurde, aktualisiert das Release-Management die betroffenen Einträge in der CMDB. Bleibt dieser Schritt aus, veraltet die Datenbasis genau an der Stelle, an der sie am dringendsten gebraucht wird: bei der nächsten Impact-Analyse. Scheitert ein Change dagegen, zählt die Rückverfolgbarkeit doppelt, denn die Verknüpfung zwischen Störung und auslösendem Change zeigt, welche Annahme in der vorherigen Bewertung gefehlt hat. Ohne diese Rückkopplung wiederholt sich derselbe Fehler beim nächsten ähnlichen Change.

Ein belastbarer Abschluss jedes Change-Vorgangs lässt sich anhand weniger Kriterien überprüfen, die auch ohne technisches Detailwissen nachvollziehbar sind:

• Aktualisierung des betroffenen CMDB-Eintrags
• Bestätigung des neuen Systemzustands
• Abgleich zwischen geplanter und tatsächlicher Auswirkung
• Dokumentation aufgetretener Abweichungen und ihrer Ursachen
• Formaler Abschluss des Change-Datensatzes
• Rückmeldung an betroffene Fachbereiche und Kunden

Beispiel: Wenn der Notfall-Change zur Gewohnheit wird

Ein Unternehmen, das Emergency Changes regelmäßig nutzt, um Zeit zu sparen, verschiebt Risiko lediglich in die Zukunft. Jede Änderung ohne vorherige Impact-Analyse hinterlässt eine Lücke in der CMDB, die beim nächsten Vorfall zur eigentlichen Fehlerursache wird. Was kurzfristig wie Effizienz wirkt, summiert sich mittelfristig zu genau jenen Ausfallkosten, die eine strukturierte Impact-Analyse eigentlich verhindern sollte. Ein steigender Anteil an Notfalländerungen ist deshalb ein Warnsignal für die Steuerung, nicht für die Technik.

CMDB und Change Management funktionieren am besten als Regelkreis: Jede Impact-Analyse verbessert die nächste, sobald ihre Ergebnisse zuverlässig in die Datenbasis zurückfließen. Für die Führungsebene bedeutet das, Change-Prozesse als wiederkehrende Investition zu betrachten, die mit jeder Änderung präziser wird, statt langsam an Aussagekraft zu verlieren. So wird eine verlässliche Impact-Analyse vor IT-Änderungen Teil der Unternehmenssteuerung, und das Zusammenspiel von CMDB und Change Management zu einem echten Wettbewerbsvorteil.