Ein klassischer Change-Prozess kann langwierig und unflexibel sein. Lässt sich dieser Prozess agiler gestalten? In diesem Blogartikel aus unserer Serie zur Philosophie des „agil seins” werden wir das Changemanagement und eine diesbezüglich agilere Vorgehensweise besprechen. Funktioniert es? Wann funktioniert es nicht? Was funktioniert und was nicht?
„Agil sein” für Standard- oder Nicht-Standard-Changes?
In diesem Interview zum agilen Servicemanagement war ich skeptisch hinsichtlich der Vorteile des „agil seins“ im Changemanagement. Ich komme allerdings immer mehr zu der Überzeugung, dass es durchaus eine Daseinsberechtigung hat.
„Agil sein“ funktioniert in der Regel für Nicht-Standard-Changes besser. Die Idee dahinter besteht darin, dass es Ihnen bei nicht planbaren Arbeiten weiterhilft. Währenddessen sind Standard-Changes im Normalfall so planbar wie möglich konzipiert. Ein von Ihnen unterstützter Laptop ist ein gutes Beispiel: Sie nehmen einen Laptop aus dem Lager, installieren das benötigte Betriebssystem sowie Standardsoftware und liefern den Laptop aus. Alles planbar, keine Überraschungen.
Bei Nicht-Standard-Changes kann „agil sein“ jedoch den entscheidenden Unterschied ausmachen.
Ist Ihr Changemanagement-Prozess zu kompliziert geworden? So können Sie ihn vereinfachen
Worin liegt das Problem beim traditionellen ITIL-Ablauf?
Das ITIL-Changemanagement wurde konzipiert, um die Bearbeitung von Changes innerhalb Ihrer IT-Infrastruktur zu regulieren. Es bewirkt, dass nicht das ganze Netzwerk ausfällt, wenn Sie einen Server ersetzen. Es gibt im Netzwerk also eine Vielzahl von Kontrollen und Schutzmechanismen.
All diese Kontrollen sind nützlich. Doch sie sorgen auch dafür, dass der Prozess für Nicht-Standard-Changes sehr komplex geworden ist. Und ein komplexer Prozess bringt viele Nachteile mit sich:
- Eine Anfrage für einen Change (RfC – Request for Change) einzureichen bedeutet viel Arbeit. Sie müssen technische Lösungen konzipieren, eine Auswirkungsanalyse durchführen, Risiken einschätzen und Kosten vorhersehen. Und Sie können sich dabei nicht einmal sicher sein, dass der Change durchgeführt wird. Oder ob Ihre Informationen noch aktuell sind, wenn die Umsetzung live geht.
- Das Change Advisory Board (CAB) benötigt viel Zeit für die Freigabe von RfCs. In manchen Unternehmen berät das CAB über jeden Change, ob groß oder klein, dringend oder nicht. Das bedeutet, dass sechs bis acht CAB-Mitglieder Zeit damit verbringen, über eine relativ simple Anfrage zu beraten.
- Der Change-Prozess bewegt sich nur in eine Richtung. Bevor Sie eine Anfrage für einen Change einreichen, müssen Sie alles genau durchplanen. Nach der Freigabe bleibt nur noch die Ausführung des festgelegten Plans übrig. Sie haben neue Erkenntnisse erlangt? Es ist nicht leicht, diese im laufenden Prozess einzubringen, da dieser dann länger als er sollte andauern würde.
- Diese Kontrollmechanismen verlangsamen den Change-Prozess. Vielleicht sind Sie bereit, einen Change zu implementieren, aber stellen plötzlich fest „wir sollten doch das CAB noch die letzten Änderungen prüfen lassen, aber die haben keine Sitzung bis nächsten Mittwoch“.
Change-Anfragen ohne unnötige Aufgaben
Ich möchte nicht behaupten, dass Prozesse und Kontrollen von Natur aus unnötig sind. Ganz im Gegenteil: Ich empfehle Unternehmen meistens, mit RfC-Formularen zu arbeiten. Durch eine Auswirkungsanalyse – in welcher Form auch immer – vermeiden Sie größere Probleme bei der Implementierung.
Aber brauchen Sie für jeden einzelnen Change ein RfC-Formular? Ich denke nicht. Finden Sie das richtige Verhältnis zwischen dem Minimieren von Risiken und dem Vertrauen in die Fähigkeit Ihrer IT-Abteilung, die richtigen Entscheidungen zu treffen. Eine agile Handlungsweise hinsichtlich des Changemanagements kann Ihnen dabei helfen, dieses Gleichgewicht zu finden.
Der Changemanager: Inhaber des Change-Backlogs
Die Rollen des Changemanagers und des CAB werden sich am meisten verändern. Traditionell ist der Changemanager zunächst einmal der Prozessmanager. Wenn Sie eine agilere Handlungsweise einführen möchten, wird die Rolle des Changemanagers sozialer und mehr auf den Kern eines Projekts fokussiert ausfallen.
Das sind die Aufgaben eines agilen Changemanagers:
- Sie tragen die Wünsche Ihrer Interessensvertreter zusammen und priorisieren sie. Sie setzen RfCs in Form von Change-Anfragen in das Change-Backlog. Ein Backlog ist quasi eine priorisierte Liste anstehender Aufgaben. Wenn Sie gut priorisieren möchten, müssen Sie ein umfassendes Verständnis über Vorgänge innerhalb Ihrer Organisation haben. Sie prüfen die verschiedenen RfCs und vergleichen Interessen und Konflikte. Mithilfe dieses Vergleichs priorisieren Sie die Changes und prüfen darüber hinaus ungefähr alle zwei Wochen, ob sich die Prioritäten ändern müssen.
- Sorgen Sie dafür, dass die RfC-Beschreibungen eindeutig sind. Sie brauchen nicht für jeden einzelnen RfC ein vollständiges Formular. Sammeln Sie nur die Informationen, die Sie zur Priorisierung benötigen. Beispielsweise: Welche Probleme sollen durch den RfC gelöst werden? Was sind mögliche Lösungen? Wie groß ist der zu erwartende Umfang der Anfrage? Sie müssen nicht sämtliche Details wie eine vollständige Lösung, einen Implementierungsplan und das Budget direkt angeben.
- Stellen Sie lediglich sicher, dass die fünf wichtigsten RfCs detailliertere Beschreibungen enthalten. Denken Sie an folgende Faustregel: je niedriger etwas im Backlog rangiert, desto weniger Details müssen in der Anfrage angegeben werden. Machen Sie nur für die Anfragen detaillierte Angaben, die Sie bald bearbeiten. Nur für diese Anfragen bitten Sie um eine Freigabe vom CAB.
Das CAB: Von technischen Details bis zur strategischen Ebene
Wenn der Changemanager mehr Zeit damit verbringt, RfCs zu sammeln und zu priorisieren, stellt sich die Frage: Welche Rolle nimmt das CAB ein? Das CAB ist für den Prozess nach wie vor sehr wichtig, aber auf einer eher strategischen Ebene. Das sind die neuen Aufgaben des CAB:
- Die wichtigsten RfCs freigeben. Diese Aufgabe bleibt nahezu unverändert: Das CAB entscheidet, welche Anfragen vollständig sind. Einige RfCs werden möglicherweise abgelehnt. Der Hauptunterschied besteht darin, dass das CAB nur die Changes im oberen Bereich der Liste prüft und somit viel Zeit spart.
- Die Priorisierung des Backlogs freigeben. Der Changemanager hat bereits alle RfCs priorisiert, somit liegt es am CAB, diese Priorisierung zu prüfen. Wenn der Changemanager das gut macht, wird das CAB in der Regel nur um wenige Anpassungen bitten.
- In entscheidenden Momenten grünes Licht geben – oder das Stoppschild hochhalten. Während traditioneller Implementierungen erteilt das CAB die Freigabe, bevor etwas live gehen kann, beispielsweise während der Testphase. Im agilen Changemanagement erfolgt der Rollout der neuen Services in der Regel Schritt für Schritt. Damit gibt es nicht mehr diesen einen „Moment der Wahrheit“, bei dem alles schief gehen könnte. Wann erteilt das CAB also seine Freigabe? Die Antwort auf diese Frage variiert von Implementierung zu Implementierung. Das IT-Team und das CAB entscheiden bereits im Vorfeld, in welcher Implementierungsphase das CAB einbezogen werden wird.
Möchten Sie mehr über das Thema Agile Servicemanagement erfahren?
In unserem E-Book finden Sie alles Wissenswerte zum Thema agiles Servicemanagement. Sie erfahren, wie „agil sein“ mit ITIL zusammenspielt, wie agile Servicemanagement in der Praxis umsetzbar ist und welche Hürden bei der Umstellung auf eine agile Arbeitsweise überwunden werden müssen.
