Das Meeting, das alle stillschweigend hinnehmen

Dreißig Personen in einer Telefonkonferenz. Eine Tabelle mit 85 Changes. Der CAB-Vorsitzende liest jeden einzelnen vor. Niemand stellt Fragen. Alle sagen “approved”.

Das passiert jede Woche in Unternehmen weltweit. Es ist die am weitesten verbreitete geduldete Dysfunktion im IT Service Management.

Das Change Advisory Board sollte eine Funktion zur Risikosteuerung sein. In der Praxis ist es ein Stempel mit Kalendereinladung.

Dieser Beitrag ist kein Argument gegen Change Governance. Change Governance ist wichtig. Es ist ein Argument dafür, dass das wöchentliche CAB-Meeting die schlechteste denkbare Umsetzung davon ist.

Und ServiceNow liefert Ihnen bereits die Werkzeuge, um es zu ersetzen. Die meisten Organisationen haben sie nur nicht konfiguriert, weil das Meeting politisch fest verankert ist.

Das CAB war nie für dieses Volumen gedacht

Wie es dazu kam

Das CAB-Konzept stammt aus ITIL v2. Es wurde für eine Zeit entworfen, in der Changes selten, hochriskant und manuell durchgeführt wurden.

Das war vor 20 Jahren.

Heute setzt ein mittelgroßes Unternehmen möglicherweise 200 bis 500 Changes pro Woche um. Cloud-Deployments, CI/CD-Pipelines, automatisiertes Patching, Infrastructure-as-Code. Das Volumen ist explodiert.

Das CAB-Meeting hat nicht mitgehalten. Es wurde einfach nur länger.

Was das Meeting tatsächlich liefert

Seien wir ehrlich darüber, was in einer typischen CAB-Sitzung passiert.

Die meisten Teilnehmenden haben die Changes vor dem Meeting nicht geprüft. Sie machen nebenbei andere Dinge. Sie genehmigen auf Basis dessen, wer den Change eingereicht hat, nicht auf Basis dessen, was drinsteht.

Hochriskante Changes bekommen die gleichen 90 Sekunden Aufmerksamkeit wie risikoarme. Manchmal weniger, weil das Meeting überzieht und die Leute gehen wollen.

Das Ergebnis ist keine Risikominimierung. Das Ergebnis ist ein Zeitstempel, der im Change Record „CAB approved” sagt. Das ist alles.

Niemand erkennt Kollisionen. Niemand liest Back-out-Pläne. Niemand prüft, ob die CMDB-Abhängigkeiten bewertet wurden.

Das Meeting produziert Compliance-Artefakte. Keine Sicherheit.

Das eigentliche Problem: politische Verankerung, nicht fehlende Prozesse

Warum niemand das Meeting abschafft

Alle wissen, dass das CAB nicht funktioniert. Die Change Manager wissen es. Die Platform Owner wissen es. Die Leute, die sich in die Konferenz einwählen, wissen es.

Warum hält es sich trotzdem?

Weil das Meeting eine Machtstruktur ist, keine Governance-Struktur.

Die Rolle des CAB-Vorsitzenden ist mit organisatorischer Autorität verbunden. Bestimmte Führungskräfte nutzen das Meeting, um Sichtbarkeit darüber zu behalten, was sich ändert. Das Meeting abzuschaffen fühlt sich an wie Aufsicht abzuschaffen.

Es ist auch eine Komfortdecke für Audits. Wenn ein Auditor fragt „Wie steuern Sie Changes?”, fühlt es sich sicherer an, auf ein wöchentliches Meeting mit 30 Teilnehmenden zu verweisen als auf ein automatisiertes Risikomodell. Auch wenn das Modell deutlich rigoroser ist.

Die Kosten, die niemand misst

Nehmen Sie 30 Personen. Multiplizieren Sie mit einer Stunde pro Woche. Das sind 30 Stunden hochqualifizierter Engineering- und Management-Zeit. Jede einzelne Woche.

Rechnen Sie jetzt die versteckten Kosten dazu: Changes, die in einer Warteschlange liegen und auf das nächste CAB-Fenster warten. Ein Change, der am Dienstagmorgen eingereicht wird, kann erst nach der CAB-Genehmigung am Donnerstag live gehen. Das sind zwei Tage Lieferverzögerung, die in jeden einzelnen Change eingebaut sind, unabhängig vom Risiko.

Multiplizieren Sie das über Hunderte von Changes, und Sie beginnen den tatsächlichen Bremseffekt auf die Delivery-Geschwindigkeit zu erkennen.

Das CAB ist nicht kostenlos. Es ist nur so, dass niemand die Rechnung verfolgt.

Was ServiceNow Ihnen bereits bietet (und was Sie ignorieren)

Das ist der Teil, der mich frustriert. ServiceNow hat die Alternative gebaut. Sie befindet sich genau jetzt in Ihrer Plattform. Die meisten Organisationen haben sie nur nicht aktiviert.

Das Change Risk Assessment Model

Das Change Management-Modul von ServiceNow beinhaltet eine konfigurierbare Risk-Assessment-Engine. Sie definieren die Risikoberechnung auf Basis von Faktoren wie Impact, Kategorie, betroffenen CIs, Change-Typ und historischen Erfolgsraten.

Die Plattform kann jeden Change automatisch bewerten. Kein Meeting erforderlich.

Sie können Risikoschwellenwerte konfigurieren, die das Approval-Routing bestimmen. Risikoarme Changes werden automatisch genehmigt oder an einen Peer-Reviewer weitergeleitet. Hochriskante Changes werden an die zuständige fachliche Autorität eskaliert.

Das ist kein Feature Request. Das existiert heute. Es existiert seit Jahren.

Standard Change Authority und Auto-Approval

Standard Changes sind vorab autorisierte, wiederholbare Changes mit bekanntem Risikoprofil. ServiceNow ermöglicht es Ihnen, Standard-Change-Templates mit vorausgefüllten Feldern und Auto-Approval-Workflows zu erstellen.

Wenn ein Change 50 Mal erfolgreich durchgeführt wurde, ohne einen einzigen Incident, braucht er beim 51. Mal kein menschliches Gremium zur Genehmigung.

Die meisten Organisationen haben weniger als 10 Standard-Change-Templates konfiguriert. Es sollten Hunderte sein.

Jeder Change, der zum Standard Change wird, ist ein Change, der nie wieder das CAB berührt. So leeren Sie die Warteschlange.

Peer Review statt Gremiumsentscheid

Die Approval-Engine von ServiceNow unterstützt gezieltes Peer Review. Statt jeden Change an ein 30-köpfiges Board zu leiten, routen Sie ihn an die ein oder zwei Personen, die den technischen Bereich tatsächlich verstehen.

Ein Netzwerk-Change wird von einem Netzwerk-Engineer geprüft. Ein Datenbank-Change wird von einem DBA geprüft. Ein Application Deployment wird vom App Owner geprüft.

Das ist schneller, technisch fundierter und liefert bessere Ergebnisse als ein generalistisches Gremium.

Flow Designer kann dieses Routing automatisch auf Basis von Change-Attributen orchestrieren. Assignment Rules, CI Ownership und Gruppenzugehörigkeit können den Workflow steuern.

Das neue Operating Model

Hier ist das Modell. Es ist nicht theoretisch. Ich habe Organisationen bei der Umsetzung begleitet.

Die Changes in Stufen einteilen

Teilen Sie Ihr Change-Volumen in drei Stufen ein, basierend auf dem Risiko-Score.

Stufe 1: Standard Changes. Vorab autorisiert. Automatisch genehmigt. Kein menschliches Review nötig. Diese sollten langfristig 50 % oder mehr Ihres Gesamtvolumens ausmachen.

Stufe 2: Normal Changes, geringes bis mittleres Risiko. Peer Review durch die zuständige fachliche Autorität. Asynchron in der Plattform genehmigt. Kein Meeting.

Stufe 3: Normal und Emergency Changes, hohes Risiko. Diese erhalten ein fokussiertes Review. Keine 30-Personen-Konferenz. Eine kleine Gruppe relevanter Stakeholder, die den Change Record tatsächlich gelesen und das Risiko bewertet haben.

Unten automatisieren, oben steuern

Das Ziel ist, Menschen aus Entscheidungen herauszunehmen, die kein menschliches Urteil erfordern.

Genehmigen Sie automatisch, was sicher ist. Lassen Sie Peer Reviews durchführen, was moderat ist. Kommen Sie nur zusammen, wenn es wirklich hochriskant ist.

Das ist nicht weniger Governance. Es ist bessere Governance. Sie konzentrieren Expertenwissen auf die Changes, die es tatsächlich brauchen, statt dünne Aufmerksamkeit über alles zu verteilen.

Das Meeting durch asynchrones Review und Eskalation bei Ausnahmen ersetzen

Stufe-2-Changes brauchen kein Meeting. Sie brauchen einen Reviewer, der den Change Record öffnet, den Plan prüft und auf „Genehmigen” oder “Ablehnen” klickt.

ServiceNow protokolliert all das. SLA-Timer auf Approvals. Kommentare und Work Notes für die Audit-Nachverfolgung. Ablehnungs-Workflows, die an den Antragsteller zurückgeleitet werden.

Das einzige wiederkehrende Meeting, das überlebt, ist eine kurze, fokussierte Sitzung für Stufe-3-Changes. Und wenn es in einer Woche keine Stufe-3-Changes gibt, fällt das Meeting aus. Genau das ist der Punkt.

Wie Sie den Übergang schaffen, ohne einen Krieg auszulösen

Sie werden auf Widerstand stoßen. Der CAB-Vorsitzende wird sich bedroht fühlen. Das Audit-Team wird Fragen haben. Das mittlere Management wird sich Sorgen machen, die Sichtbarkeit zu verlieren.

So gehen Sie damit um.

Beide Modelle parallel betreiben

Schaffen Sie das CAB nicht am ersten Tag ab. Betreiben Sie das neue Modell 8 bis 12 Wochen lang parallel.

Erfassen Sie während der Parallelphase, welche Changes das Risikomodell automatisch genehmigt oder per Peer Review behandelt hätte, im Vergleich zu denen, die tatsächlich die volle CAB-Diskussion benötigten. Sammeln Sie die Daten.

Lassen Sie die Daten das Meeting abschaffen

Präsentieren Sie nach der Parallelphase die Zahlen.

Zeigen Sie, wie viele Changes ohne jede Diskussion durch das CAB gelaufen sind. Zeigen Sie die durchschnittliche Zeit pro Change im Meeting im Vergleich zum Peer-Review-Workflow. Zeigen Sie die Lieferverzögerung, die durch das wöchentliche CAB-Fenster verursacht wird.

Wenn die Daten zeigen, dass 80 % der Changes das Meeting nie gebraucht haben, bricht das politische Argument in sich zusammen.

Sie eliminieren keine Aufsicht. Sie beweisen, dass die Plattform es besser kann.

Das ist ein Governance-Upgrade, keine Governance-Abschaffung

Das CAB war das beste verfügbare Werkzeug im Jahr 2005. Wir haben nicht mehr 2005.

ServiceNow bietet Ihnen Risk Scoring, automatisiertes Routing, Standard Change Authority, Peer-Review-Workflows und lückenlose Audit Trails. Jede einzelne dieser Funktionen ist rigoroser als eine 30-Personen-Telefonkonferenz, in der niemand aufpasst.

Die Frage ist nicht, ob Sie Change Governance brauchen. Sie brauchen sie.

Die Frage ist, ob ein wöchentliches Rubber-Stamp-Meeting die beste Umsetzung davon ist.

Ist es nicht. Und Ihre Plattform weiß das längst.