Warum lohnt sich eine Change-Request-Vorprüfung überhaupt?

Eine Change-Request-Vorprüfung lohnt sich, weil sie unvollständige Änderungsanträge herausfiltert, bevor sie eine CAB-Sitzung blockieren. Ohne diesen Schritt landen Anträge ohne Testnachweis oder Rollback-Plan direkt auf der Tagesordnung, das Gremium diskutiert Formfehler statt Risiken, und der Antragsteller bekommt die Rückfrage erst nach der Sitzung per Mail. Das kostet Zeit an drei Stellen gleichzeitig.

In der Praxis sieht das so aus: Der Change Manager sammelt Requests aus Jira Service Management oder ServiceNow, sichtet sie kurz vor der Sitzung und merkt erst dann, dass ein Zeitfenster fehlt oder ein Konfigurationselement in der CMDB nicht existiert. Die CAB-Mitglieder sitzen mit halbfertigen Unterlagen zusammen und müssen entscheiden, ob sie den Punkt vertagen oder unter Vorbehalt durchwinken. Beides ist unbefriedigend.

Am Ende leidet vor allem der Antragsteller aus dem Fachbereich. Er reicht einen Change ein, wartet auf Rückmeldung, bekommt nach Tagen eine Mail mit fehlenden Angaben, ergänzt sie, und der Antrag rutscht in die nächste Sitzung. Wiederholt sich das mehrfach im Monat, sinkt die Akzeptanz des gesamten Change-Prozesses im Unternehmen. Eine strukturierte Vorprüfung setzt genau an dieser Stelle an, ohne die eigentliche Bewertung durch das Gremium zu ersetzen.

Was gehört in einen vollständigen Change Request?

Ein vollständiger Change Request enthält mindestens sieben Angaben: eine klare Beschreibung der Änderung, die betroffenen Konfigurationselemente aus der CMDB, ein geplantes Zeitfenster, einen Testnachweis, einen Rollback-Plan, den zuständigen Genehmiger und einen Kommunikationsplan für Betroffene. Fehlt eines dieser Felder, kann das CAB die Änderung fachlich nicht seriös bewerten.

Diese Felder werden in der Praxis regelmäßig unvollständig oder widersprüchlich ausgefüllt, oft weil Formulare zu allgemein formuliert sind oder die CMDB nicht konsequent gepflegt wird. Die folgende Tabelle zeigt, wofür jedes Feld gedacht ist und welcher Fehler in der Vorprüfung am häufigsten auffällt.

Ein Blick in bestehende Change-Vorgänge im Kundenumfeld zeigt oft, dass gerade der Rollback-Plan und der Testnachweis am schwächsten ausgefüllt sind, weil sie zusätzlichen Aufwand vor der eigentlichen technischen Arbeit bedeuten. Wer sein Vorgehen bei der Prüfung von Softwareänderungen ohnehin dokumentiert, kann diese Angaben aus bestehenden Abläufen im Qualitätssicherung übernehmen, statt sie für jeden Change neu zu formulieren.

Wie prüft eine Change-Request-Vorprüfung Vollständigkeit und Konsistenz?

Eine Change-Request-Vorprüfung arbeitet zweistufig: Zuerst prüft sie, ob alle Pflichtfelder gefüllt sind, danach prüft sie, ob die Angaben inhaltlich zusammenpassen. Die Feldprüfung erkennt eine leere Zeile, die Konsistenzprüfung erkennt einen Widerspruch zwischen ausgefüllten Feldern, etwa wenn Zeitfenster und Wartungskalender sich nicht vertragen.

Die reine Feldprüfung ist mechanisch: Ist ein Zeitfenster eingetragen, ja oder nein. Ist ein Genehmiger benannt, ja oder nein. Diese Prüfung lässt sich in jedem ITSM-System als Pflichtfeld abbilden und ersetzt keine Fachkenntnis. Erst die Konsistenzprüfung bringt den eigentlichen Mehrwert, weil sie Angaben gegeneinander abgleicht, die ein Mensch unter Zeitdruck vor einer CAB-Sitzung leicht übersieht.

Drei Beispiele zeigen, was damit gemeint ist. Ein Antrag nennt ein Zeitfenster am Samstagvormittag, obwohl der Wartungskalender für dieses System einen Freeze wegen des Monatsabschlusses vorsieht. Ein Rollback-Plan beschreibt das Zurücksetzen einer Datenbank, während das betroffene Konfigurationselement laut CMDB ein reiner Anwendungsserver ist. Ein Testnachweis bezieht sich auf Version 4.2, während der Change Request Version 4.3 ausrollen soll. Solche Widersprüche fallen erst auf, wenn Felder gemeinsam gelesen werden.

Diese Art der Prüfung setzt voraus, dass die CMDB aktuell und die Wartungsfenster im System gepflegt sind. Ist das nicht der Fall, liefert auch die beste Change-Request-Vorprüfung nur so verlässliche Ergebnisse wie die Datenbasis, auf der sie arbeitet. Genau deshalb gehört eine Bestandsaufnahme der vorhandenen CMDB-Qualität zum ersten Schritt jeder Einführung.

Wie schlägt die Change-Request-Vorprüfung eine Risikoeinschätzung vor?

Die Change-Request-Vorprüfung leitet eine Risikoeinschätzung aus nachvollziehbaren Kriterien ab: Reichweite der Änderung, Abhängigkeiten laut CMDB, geplanter Zeitpunkt, Reversibilität durch den Rollback-Plan und Historie ähnlicher Changes. Aus diesen Kriterien entsteht ein begründeter Vorschlag mit Einstufung, keine automatische Entscheidung über Freigabe oder Ablehnung.

Reichweite bedeutet: Wie viele Systeme, Standorte oder Nutzer sind betroffen. Abhängigkeiten laut CMDB zeigen, ob ein vermeintlich kleiner Change an einem zentralen Konfigurationselement hängt, das mehrere andere Dienste versorgt. Der Zeitpunkt fließt ein, weil ein Change während des Monatsabschlusses anders zu bewerten ist als am ruhigen Freitagnachmittag. Die Reversibilität fragt, wie schnell und verlässlich ein Rollback funktioniert. Die Historie schließlich zeigt, ob ähnliche Changes in der Vergangenheit unauffällig verlaufen sind oder wiederholt zu Störungen geführt haben.

Aus diesen fünf Kriterien ergibt sich eine Einstufung, die dem Change Manager als Diskussionsgrundlage dient, etwa niedrig, mittel oder hoch, jeweils mit einer kurzen Begründung. Diese Begründung ist entscheidend, denn ohne sie bleibt die Einstufung eine Zahl ohne Nachvollziehbarkeit. Das CAB kann die Begründung prüfen, ergänzen oder verwerfen, die Verantwortung für die tatsächliche Risikobewertung bleibt beim Gremium.

Wichtig ist die Abgrenzung: Der Vorschlag ersetzt keine fachliche Einschätzung, er strukturiert sie. Wer im IT Service Management bereits mit Risikoklassen für Vorgänge arbeitet, kann diese Logik auf Changes übertragen, statt ein neues Bewertungsschema parallel aufzubauen.

Wer entscheidet, wenn die Change-Request-Vorprüfung nur vorschlägt?

Entschieden wird ausschließlich von Menschen: Der Change Owner verantwortet den Antrag fachlich, der Change Manager moderiert den Prozess und bereitet die Sitzung vor, das Change Advisory Board genehmigt oder lehnt ab, und bei Notfällen entscheidet ein Emergency-Gremium. Die Change-Request-Vorprüfung liefert dafür Arbeitsmaterial, keine Freigabe und kein Urteil.

Diese Rollenklarheit ist kein Nebensatz, sondern der Kern der Leistung. Der Change Owner bleibt dafür verantwortlich, dass sein Antrag fachlich korrekt und vollständig ist, auch wenn die Vorprüfung ihm dabei hilft, Lücken vor der Sitzung zu schließen. Der Change Manager entscheidet, welche Anträge überhaupt auf die Tagesordnung kommen. Das CAB trifft die eigentliche Genehmigungsentscheidung, gestützt auf den vorgeschlagenen Risikohinweis, aber nicht durch ihn ersetzt.

Bei vielen Anbietern von KI-gestützten Change-Audits bleibt unklar, wo die automatische Einschätzung endet und die menschliche Entscheidung beginnt. Genau diese Grenze zieht ANCUD IT bewusst und dokumentiert sie im Prozess, unter anderem weil Verfahren zur Konformitätsbewertung von Hochrisiko-KI-Systemen ab 2026 verbindliche Nachweise über die Rolle automatisierter Bewertungen verlangen Konformitätsbewertung Hochrisiko-KI: Verfahren 2026. Wer heute schon zwischen Vorschlag und Entscheidung trennt, ist auf diese Anforderungen vorbereitet, statt sie nachträglich einbauen zu müssen.

Für das Notfallgremium gilt eine Besonderheit: Es entscheidet oft unter Zeitdruck, mit weniger vollständigen Angaben als ein reguläres CAB. Auch hier bleibt die Vorprüfung ein Hinweisgeber, nicht der Entscheider, wie der folgende Abschnitt zu Emergency Changes zeigt.

Was unterscheidet Standard, Normal und Emergency Change?

Ein Standard Change ist vorautorisiert und läuft nach einem etablierten Verfahren mit geringem Risiko ab, ein Normal Change durchläuft eine reguläre Bewertung durch das CAB, deren Aufwand vom Risikograd abhängt, und ein Emergency Change wird sofort umgesetzt, um einen laufenden Vorfall zu beheben, mit nachgelagerter statt vorheriger Prüfung. Die Change-Request-Vorprüfung greift in jeder Kategorie an einer anderen Stelle.

Bei Standard Changes prüft die Vorprüfung vor allem, ob der Antrag tatsächlich den vordefinierten Kriterien entspricht, denn eine falsch als Standard eingestufte Änderung entzieht sich sonst der eigentlich nötigen CAB-Bewertung. Bei Normal Changes läuft die volle Prüfung aus Vollständigkeit, Konsistenz und Risikoeinschätzung, wie in den vorherigen Abschnitten beschrieben, bevor der Antrag auf die Tagesordnung kommt. Bei Emergency Changes fehlt dafür die Zeit, hier dokumentiert die Vorprüfung nachträglich, ob die Angaben nachgereicht wurden und ob der Change im Nachhinein den Anforderungen entspricht, etwa im Rahmen eines Post-Implementation Reviews.

Diese Einordnung folgt der Praxis, wie sie auch im Change Management beschrieben wird, wo Standard-, Normal- und Notfalländerungen als getrennte Pfade mit eigenen Prüfpunkten geführt werden. Wer diese Kategorien im eigenen ITSM-System noch nicht klar trennt, sollte das vor Einführung einer Vorprüfung nachziehen, sonst greift die automatische Einordnung ins Leere.

Wie greift die Change-Request-Vorprüfung bei Notfall-Changes?

Bei einem Notfall-Change läuft die Change-Request-Vorprüfung nachgelagert: Der Change wird zuerst umgesetzt, weil ein Ausfall droht, danach prüft das System die Nachdokumentation gegen eine feste Frist, meist 24 bis 72 Stunden, und meldet fehlende Angaben an das Emergency-CAB (ECAB) statt an das reguläre Gremium.

Das ECAB tagt kurzfristig und mit reduzierter Besetzung. Die Vorprüfung liefert ihm eine Checkliste: Wurde ein Rollback-Plan dokumentiert, ist der betroffene Konfigurationseintrag in der CMDB aktuell, liegt eine Begründung für die Dringlichkeit vor. Fehlt etwas, markiert das System den Vorgang als unvollständig, ohne ihn zu blockieren, denn der Change ist bereits produktiv.

Anschließend fließt der Fall in das Post-Implementation Review. Hier prüft ein Mensch, ob die Dringlichkeit gerechtfertigt war und ob der Change im Nachhinein die üblichen Kriterien erfüllt hätte. Diese Rückschau ist keine reine Formalie, sie zeigt Muster: Häufen sich Notfall-Changes an bestimmten Systemen, deutet das auf strukturelle Probleme hin, nicht auf Einzelfälle.

Ein Anbieter für KI-gestützte Auditierung von Change Requests beschreibt eine vergleichbare Kategorisierung von Prüfergebnissen nach Vollständigkeit und Risiko Auditing von Change Requests mit KI. Für ANCUD IT gilt dabei: Die Nachprüfung ersetzt keine Freigabe, sie dokumentiert nur, was bereits entschieden wurde, und legt die Grundlage für die Entscheidung, ob der Prozess für künftige Notfälle angepasst werden muss.

Wie fügt sich die Vorprüfung in ITIL 4 Change Enablement ein?

Die Change-Request-Vorprüfung ist ein Sub-Prozess innerhalb der ITIL 4 Practice Change Enablement, der vor der eigentlichen Bewertung liegt. Sie filtert unvollständige oder nicht durchführbare Anfragen heraus, bevor das Change Advisory Board Zeit in eine inhaltliche Prüfung investiert. ITIL nennt diesen Schritt nicht immer explizit, das YaSM-Referenzmodell tut es.

In der ITIL-V3-Terminologie hieß die vorgelagerte Practice noch Change Management, ITIL 4 spricht von Change Enablement und betont stärker die Zusammenarbeit zwischen Teams statt starrer Kontrolle. Die Vorprüfung passt zu dieser Verschiebung: Sie entlastet das Gremium, ohne ihm die Entscheidung abzunehmen, und sie lässt sich in bestehende Workflows einbetten, wie sie auch im IT Service Management beschrieben sind.

YaSM strukturiert den Ablauf in klar getrennte Teilschritte: Erfassen, Prüfen, Bewerten, Genehmigen, Umsetzen, Überprüfen. Die Vorprüfung deckt den zweiten Schritt ab und liefert dem dritten eine strukturierte Grundlage, etwa in Form eines Risikovorschlags mit Begründung. Das Gremium entscheidet weiterhin selbst, welches Gewicht dieser Vorschlag erhält.

Auch ISO/IEC 20000-1:2018 lässt sich mit diesem Ablauf verbinden. Abschnitt 8.1 verlangt eine dokumentierte Planung von Änderungen, Abschnitt 8.5 fordert ein kontrolliertes Change-Management-Verfahren mit nachvollziehbaren Entscheidungen. Eine vorgelagerte, protokollierte Vorprüfung erfüllt beide Anforderungen, ohne den bestehenden CAB-Prozess zu verändern.

Welche Anforderungen aus ISO 27001 und BSI-Grundschutz sind zu beachten?

ISO/IEC 27001:2022 verlangt in Annex A, Control 8.32, dass Änderungen an Informationsverarbeitungseinrichtungen einem geregelten Änderungsmanagementverfahren unterliegen. Diese Kontrolle fasst vier frühere Einzelkontrollen aus der Fassung von 2013 zusammen (Annex A 12.1.2, 14.2.2, 14.2.3, 14.2.4). Der BSI-Baustein OPS.1.1.3 fordert in Anforderung A5 zusätzlich, dass alle Änderungsanfragen erfasst und kontrolliert nachvollzogen werden.

Für die Change-Request-Vorprüfung bedeutet das: Sie muss nicht nur inhaltlich prüfen, sondern auch protokollieren, wann welche Anfrage mit welchem Ergebnis geprüft wurde. Ohne dieses Protokoll lässt sich gegenüber einem Auditor nicht belegen, dass die Kontrolle tatsächlich gelebt wird, unabhängig davon, ob die Prüfung durch Menschen oder mit KI-Unterstützung erfolgt.

Bei personenbezogenen oder vertraglich relevanten Angaben in Change-Dokumenten kommt die Frage nach Manipulation und Datenqualität hinzu. Verfahren zur automatisierten Dokumentenprüfung, wie sie etwa im Kontext von Vertragsdaten beschrieben werden, lassen sich grundsätzlich auf Change-Dokumentation übertragen, um Auffälligkeiten in Freigabevermerken oder Nachträgen zu erkennen Dokumentenprüfung mit KI.

Für Unternehmen, die unter NIS2 oder DORA fallen, ist Änderungsmanagement kein isoliertes IT-Thema mehr, sondern Teil der Nachweispflicht gegenüber Aufsichtsbehörden. Beide Rahmenwerke verlangen belastbare Prozesse für Betriebskontinuität und IT-Risikomanagement, zu denen ein dokumentierter Change-Prozess gehört. Eine Vorprüfung, die Vollständigkeit und Nachvollziehbarkeit sicherstellt, liefert dafür einen Baustein, ersetzt aber keine vollständige Compliance-Bewertung durch Rechts- oder Fachabteilung.

Wie wird die Change-Request-Vorprüfung an Jira oder ServiceNow angebunden?

Die Change-Request-Vorprüfung läuft als zusätzlicher Schritt im bestehenden Workflow von Jira Service Management oder ServiceNow, nicht als separates System. Sie liest den Vorgang, setzt einen Kommentar mit dem Prüfergebnis, befüllt ein Feld für den Risikovorschlag und ändert den Status, etwa von „Eingereicht“ auf „Vorprüfung abgeschlossen“ oder „Rückfrage nötig“.

In Jira lässt sich dieser Schritt über einen eigenen Transition-Status im Change-Workflow abbilden. Das System kommentiert am Vorgang, welche Pflichtfelder fehlen oder welcher Wert im Feld für den Risikovorschlag hinterlegt wurde, inklusive Begründung. Der Change Manager sieht diese Information direkt im Vorgang, ohne ein zweites Werkzeug öffnen zu müssen.

In ServiceNow lässt sich die Vorprüfung an die Change-Workbench anbinden. Sie ergänzt den Change-Kalender um eine Markierung, wenn ein geplanter Termin mit einem bestehenden Wartungsfenster oder einem anderen Change kollidiert, und schreibt das Ergebnis als strukturiertes Feld statt als Freitext, damit spätere Auswertungen möglich bleiben.

Wichtig ist die Abgrenzung: Die Vorprüfung ergänzt das ITSM-System, sie ersetzt es nicht. Freigaben, Eskalationen und die CAB-Sitzung selbst bleiben vollständig in Jira oder ServiceNow verankert. ANCUD IT bindet die Prüfung über vorhandene Schnittstellen an, etwa im Rahmen bestehender Change Management-Prozesse, und vermeidet ein paralleles System, das zusätzliche Pflege erfordern würde. Wer bereits ein etabliertes IT-Service-Management betreibt, muss dafür keine neue Plattform einführen.

Welche Daten braucht die Change-Request-Vorprüfung?

Die Change-Request-Vorprüfung braucht Zugriff auf die CMDB, die Change-Historie, die Wartungsfenster, die geltenden Freigaberichtlinien und die Betriebshandbücher, meist in Confluence gepflegt. Diese Quellen liefern den Kontext, um zu erkennen, ob ein Change vollständig beschrieben ist, ob er mit anderen Terminen kollidiert und welche Systeme betroffen sind.

Die CMDB liefert die Zuordnung von Configuration Items zu Services und zeigt Abhängigkeiten, etwa welche Anwendung von einem bestimmten Server abhängt. Die Change-Historie zeigt, ob ähnliche Änderungen in der Vergangenheit Probleme verursacht haben. Freigaberichtlinien legen fest, welche Rollen welche Change-Typen genehmigen dürfen, und Betriebshandbücher dokumentieren Ausnahmen und Sonderfälle.

Diese Quellen sind nur nützlich, wenn ihre Datenqualität stimmt. Eine veraltete CMDB oder ein Confluence-Handbuch, das seit zwei Jahren nicht mehr aktualisiert wurde, führt zu falschen Einschätzungen, unabhängig davon, wie ausgereift die Prüflogik ist. Relevante Dimensionen sind dabei Vollständigkeit, Aktualität, Konsistenz und Korrektheit der hinterlegten Angaben.

Deshalb beginnt jede Einführung einer Change-Request-Vorprüfung bei ANCUD IT mit einer Bestandsaufnahme der vorhandenen Datenquellen, nicht mit der Konfiguration von Prüfregeln. Wo die CMDB Lücken hat, wird das offen benannt, statt die Lücke durch eine vermeintlich intelligente Schätzung zu verdecken.

Wo liegen die Grenzen einer Change-Request-Vorprüfung?

Die Grenzen liegen dort, wo Daten fehlen oder der Change nicht in bekannte Muster passt: eine fehlerhafte CMDB liefert falsche Abhängigkeiten, ein neues System ohne Change-Historie bietet keine Vergleichswerte, und politisch heikle Changes lassen sich nicht allein anhand technischer Kriterien einschätzen. In all diesen Fällen bleibt die Bewertung durch das CAB unverzichtbar.

Sonderfälle sind besonders anfällig für Fehleinschätzungen. Ein Change, der auf dem Papier klein aussieht, aber ein zentrales System betrifft, das in der CMDB unvollständig erfasst ist, kann als risikoarm markiert werden, obwohl er es nicht ist. Die Vorprüfung liefert einen Vorschlag, keine Garantie, und dieser Vorschlag muss im Zweifel angezweifelt werden dürfen.

Ein weiteres Risiko ist der Automatisierungsbias im Gremium selbst: Wenn ein Risikovorschlag über Wochen zuverlässig wirkt, sinkt die Bereitschaft, ihn kritisch zu hinterfragen. Genau das widerspricht dem Zweck der Vorprüfung, die das CAB entlasten, aber nicht dessen Urteilsvermögen ersetzen soll. Wiederkehrende Stichproben durch Menschen bleiben deshalb Teil des Prozesses.

ANCUD IT benennt diese Grenzen bewusst vor der Einführung, nicht erst im Betrieb. Eine Vorprüfung, die zu jedem Change eine eindeutige Antwort liefert, wäre kein Fortschritt, sondern ein Warnsignal. Realistisch ist ein System, das unsichere Fälle klar als solche markiert und sie an Menschen zurückgibt, statt eine Scheinsicherheit zu erzeugen.

Wie messen Sie, ob die Change-Request-Vorprüfung wirkt?

Die Wirkung zeigt sich in vier beobachtbaren Größen: dem Anteil der vom CAB zurückgewiesenen Änderungsanträge, der Zahl der Rückfragen je Antrag, dem Umfang der Nacharbeit nach der Sitzung und der Trefferquote des Risikovorschlags gegenüber dem tatsächlichen Verlauf des Changes. Diese Werte lassen sich aus den vorhandenen Feldern in Jira Service Management oder ServiceNow ziehen, ohne neue Kennzahlensysteme aufzubauen.

Sinkt der Anteil zurückgewiesener Change Requests, arbeiten die Antragstellenden vollständiger vor, weil die Vorprüfung fehlende Pflichtfelder und unklare Rollback-Pläne schon vor der Sitzung markiert. Weniger Rückfragen je Antrag bedeuten, dass das CAB weniger Zeit mit Klärungen verbringt und mehr Zeit mit der eigentlichen Risikoabwägung. Beides lässt sich über einen Vergleichszeitraum vor und nach Einführung auswerten, ohne dass ANCUD IT dafür Zielwerte vorgibt.

Die Nacharbeit nach dem CAB, also nachträgliche Korrekturen an bereits freigegebenen Changes, zeigt, ob Fehler früher auffallen oder erst im Betrieb sichtbar werden. Die Trefferquote des Risikovorschlags wird durch einen Abgleich mit dem tatsächlichen Verlauf ermittelt: Wie oft lag die vom System vorgeschlagene Einstufung nahe am späteren Ergebnis, etwa bei Störungen oder Rollbacks. Diese Prüfung entspricht dem Grundgedanken, dass ein automatisiertes Urteil kontrollierbar bleiben muss und nicht unbesehen übernommen wird, wie es auch für automatisierte Bewertungen in der Wissenschaft beschrieben wird wo automatisierte Bewertungen an ihre Grenzen stoßen.

Wichtig bleibt: Diese Kennzahlen belegen Entlastung im Ablauf, nicht die Richtigkeit einzelner Entscheidungen. Ob ein Change freigegeben wird, bleibt Sache des Change Advisory Boards. Die Vorprüfung liefert Vorschläge und Hinweise, keine Beschlüsse.

Wie läuft die Einführung einer Change-Request-Vorprüfung ab?

Die Einführung beginnt mit einer Bestandsaufnahme des bestehenden Change-Prozesses und der genutzten ITSM-Werkzeuge, gefolgt vom Aufbau eines Regelwerks für Vollständigkeit und Risikoeinstufung. Ein Pilot läuft zunächst auf einer einzelnen Change-Kategorie, etwa Standard Changes im Server-Umfeld. Erst nach Auswertung dieses Piloten folgt die Ausweitung auf weitere Kategorien und der laufende Betrieb.

In der Bestandsaufnahme sichtet ANCUD IT gemeinsam mit dem Change Manager und der IT-Leitung abgeschlossene Change Requests der vergangenen Monate: Welche Felder fehlten häufig, welche Anträge gingen mehrfach zwischen Antragstellenden und CAB hin und her, welche Rollback-Pläne waren unvollständig. Aus diesen Mustern entsteht das Regelwerk, das später die Vorprüfung steuert. Es wird mit dem Change Advisory Board abgestimmt, nicht an ihm vorbei entwickelt.

Der Pilot beschränkt sich bewusst auf eine Change-Kategorie mit überschaubarem Risiko. So lässt sich beobachten, wie die Change-Request-Vorprüfung mit echten Anträgen umgeht, bevor sie auf komplexere Kategorien wie Emergency Changes oder Änderungen an produktionskritischen Systemen ausgeweitet wird. Der Change Coordinator begleitet den Piloten und meldet Fehleinschätzungen zurück, die ins Regelwerk einfließen.

Im Rollout übernehmen bestehende Rollen die Verantwortung weiter: Der Change Manager verantwortet den Prozess, das CAB trifft die Freigabeentscheidung, die IT-Sicherheit prüft Fragen mit Bezug zu ISO 27001 Annex A 8.32 und zum BSI-Baustein OPS.1.1.3. ANCUD IT übergibt am Ende ein System, das im bestehenden Werkzeug läuft und von der Kundschaft selbst weiterentwickelt werden kann, etwa im Rahmen des bestehenden Change Managements.

Wie lange dauert die Einführung einer Change-Request-Vorprüfung?

Eine realistische Zeitspanne umfasst mehrere Wochen für die Bestandsaufnahme, mehrere weitere für den Pilotbetrieb auf einer Change-Kategorie und einen offenen Zeitraum für die Ausweitung, der von der Zahl der Kategorien und der Qualität der vorhandenen Daten abhängt. Feste Wochenangaben ohne Kenntnis der Ausgangslage wären unseriös.

Die Bestandsaufnahme verlängert sich, wenn abgeschlossene Change Requests nicht durchgängig dokumentiert sind oder in mehreren Systemen parallel liegen, etwa wenn ein Teil der Changes noch in Tabellen statt im ITSM-Werkzeug geführt wird. Auch eine unvollständige oder veraltete Configuration Management Database kostet Zeit, weil sie Grundlage vieler Risikoeinschätzungen ist.

Der Pilot selbst läuft über mehrere Change-Zyklen, damit genügend Anträge durch die Vorprüfung laufen, um Muster und Fehleinschätzungen zu erkennen. Organisationen mit hohem Change-Aufkommen sammeln diese Erfahrung schneller als solche mit wenigen Changes pro Monat. Die Ausweitung auf weitere Kategorien hängt zusätzlich davon ab, wie stark sich Regeln zwischen Standard-, Normal- und Emergency Changes unterscheiden.

Wer eine belastbare Zeitschätzung möchte, sollte zuerst die eigene Ausgangslage prüfen lassen. ANCUD IT nennt nach der Bestandsaufnahme einen Zeitrahmen für den konkreten Fall, nicht vorab pauschal für jede Change-Request-Vorprüfung.

Was kostet eine Change-Request-Vorprüfung?

Die Kosten hängen von der Zahl der Change-Kategorien, dem Zustand der Configuration Management Database, den anzubindenden Schnittstellen und dem gewählten Betriebsmodell ab. Ein Angebot ohne diese Angaben wäre eine Schätzung ins Blaue. ANCUD IT nennt deshalb keine Pauschalbeträge, sondern führt zunächst eine technische Bestandsaufnahme durch.

Je mehr Change-Kategorien mit eigenen Regeln abgebildet werden sollen, desto mehr Abstimmungsaufwand entsteht mit dem Change Advisory Board und der Fachabteilung. Eine gepflegte CMDB senkt den Aufwand, weil Abhängigkeiten zwischen Systemen bereits dokumentiert sind. Fehlt diese Pflege, muss die Vorprüfung zunächst mit weniger automatisierten Hinweisen arbeiten oder die CMDB wird in einem separaten Schritt bereinigt.

Schnittstellen zu Jira Service Management, ServiceNow oder anderen ITSM-Systemen bestimmen, wie viel Integrationsarbeit anfällt. Auch das Betriebsmodell wirkt sich aus: Ein lokal betriebenes Modell verursacht andere Kosten als ein Cloud-Modell, etwa durch Betriebsverantwortung, Wartung und Anforderungen aus der IT-Sicherheit. Bei besonders sensiblen Change-Kategorien, etwa mit Bezug zu personenbezogenen Daten, kann ein lokales Modell trotz höherem Betriebsaufwand die passendere Wahl sein.

Der erste Schritt bleibt in jedem Fall die Bestandsaufnahme des Change-Prozesses, der Werkzeuge und der Datenlage. Erst danach lässt sich seriös sagen, welcher Aufwand für die Change-Request-Vorprüfung realistisch ist.

Für wen eignet sich eine Change-Request-Vorprüfung?

Eine Change-Request-Vorprüfung eignet sich für IT-Betriebe mit hohem Change-Aufkommen, für regulierte Branchen mit Pflichten aus ISO 27001 oder BSI-Grundschutz und für Organisationen mit verteilten Teams, in denen Antragstellende und CAB nicht im selben Büro sitzen. In diesen Fällen entlastet die Vorprüfung ein wiederkehrendes, gut abgrenzbares Prüfmuster.

Bei hohem Change-Aufkommen sinkt sonst die Sorgfalt einzelner Prüfungen, weil das CAB unter Zeitdruck arbeitet. Regulierte Branchen wie Finanzdienstleister oder Betreiber kritischer Infrastrukturen profitieren, weil die Vorprüfung Nachweise für Annex A Control 8.32 und den BSI-Baustein OPS.1.1.3 strukturiert vorhält. Verteilte Teams gewinnen durch einheitliche Vorprüfregeln, die unabhängig vom Standort gleich angewendet werden.

Der Aufwand lohnt sich dagegen selten bei sehr geringem Change-Volumen oder wenn die meisten Änderungen ohnehin unter einen einzigen, klar abgegrenzten Standard Change fallen. Auch Organisationen ohne belastbare Historie abgeschlossener Change Requests sollten zunächst Daten sammeln, bevor sie eine automatisierte Vorprüfung aufbauen, sonst fehlt die Grundlage für ein sinnvolles Regelwerk.

ANCUD IT rät in solchen Fällen offen von einer verfrühten Einführung ab und schlägt stattdessen vor, den bestehenden Prozess erst zu stabilisieren, etwa im Rahmen des laufenden IT Service Managements.

Wie beginnen Sie mit ANCUD IT?

Der Einstieg beginnt mit einer Bestandsaufnahme des bestehenden Change-Prozesses und einer Auswertung abgeschlossener Change Requests. Daraus entsteht eine Entscheidungsvorlage, die zeigt, wo eine Change-Request-Vorprüfung ansetzen kann und mit welchem Aufwand realistisch zu rechnen ist. Diese Vorlage bildet die Grundlage für die Entscheidung, ob und wie ein Pilot startet.

In der Bestandsaufnahme sichten ANCUD-Beraterinnen und -Berater gemeinsam mit dem Change Manager die genutzten Werkzeuge, den Zustand der Configuration Management Database und eine Stichprobe abgeschlossener Anträge. Die Auswertung zeigt typische Lücken, wiederkehrende Rückfragen und Muster bei Risikoeinschätzungen. Diese Ergebnisse werden nicht intern gehalten, sondern offen mit CAB und IT-Leitung besprochen.

Weiterführende Hintergründe zu einzelnen Bausteinen, etwa zur Anbindung bestehender ITSM-Systeme, finden sich im Blog von ANCUD IT. Wer den Ablauf lieber im persönlichen Gespräch klären möchte, kann über die Seite zum Unternehmen direkt Kontakt aufnehmen und einen Termin für die Bestandsaufnahme vereinbaren.