Change Management zwischen Control und Enablement

Früher war alles klar: Mit Verweis auf ITIL braucht jede IT-Organisation ein Change Management, um alle Änderungen an der IT zu kontrollieren und übermotivierte Administratoren zu bremsen. Alle Änderungen werden in großer Runde besprochen, das Change Advisory Board, kurz CAB, tritt jede Woche einmal zusammen. So wunderte es nicht, als AXELOS 2019 mit ITIL 4 die Praxis in „Change Control“, die Kontrolle oder Steuerung von Änderungen umbenannte.
Der neue Name hat indes nur kurzen Bestand und wird durch „Change Enablement“ ersetzt, statt Kontrolle sollen jetzt Änderungen auch sprachlich gefördert werden. Wer das bei vielen IT-Organisationen beliebte CAB in dem ITIL4-Foundation-Buch sucht, wird auch bei intensiver Recherche nicht fündig. Erst die ausführlichen Practice Guides erwähnen das CAB im Zusammenhang mit Change Authority, allerdings versehen mit einer deutlichen Warnung: „Diese so genannten Change Advisory Boards (CABs) werden oft zu Engpässen in den Wertströmen der Organisation; sie [CABs] führen zu Verzögerungen und begrenzen den Durchsatz der Change-Enablement-Praxis“. Die Practice Guides führen als ersten Erfolgsfaktor an, dass Changes zeitnah und effektiv umgesetzt werden, die Minimierung der negativen Auswirkungen ist immer der zweite Punkt. Leider geht AXELOS in ITIL 4 nicht darauf ein, warum diese ehemals Best Practice heute verächtlich als Bürokratiemonster gilt und warum man ohne Probleme auf die CAB-Sitzungen verzichten könne.
Die augenscheinlichste Neuerung an ITIL 4 ist die Umwidmung der ITIL-Prozesse in IITL-Praktiken, auch wenn die meisten nie Prozesse im engeren Sinn waren. Doch AXELOS hat mit der vierten Auflage von ITIL Bewegungen in der IT der letzten Jahre aufgegriffen, hier insbesondere die DevOps-Bewegung, die viele moderne Ansätze wie Lean IT in der Organisation der IT vereint. So greift ITIL 4 das auf, was die DevOps-Vordenker Forsgreen, Humble und Kim in ihrem Buch „Accelerate“ als eine Lean-Management-Praxis „Lightweight Change Approval“ bezeichnen. Sie kommen empirisch zu dem Schluss, dass „zusammenfassend Freigaben durch einen Dritten (wie einem Manager oder CAB) helfen schlicht nicht, die Stabilität der Produktivsysteme zu erhöhen“.
In dem Vortrag betrachten und vergleichen wir beide Ansätze – Change Management als Kontrollmittel und als Förderer einer DevOps-Kultur mit schnellen Changes. Wir zeigen abstrakt, wie beide unterschiedlich mit den Risiken umgehen, die aus Changes resultieren, und geben somit Unterbau für das DevOps-Vorgehen des „Lightweight Change Approvals“. Wir zeigen auf, welche Rahmenbedingungen Peer-Reviews als Freigabemethode unterstützen, um das Ziel des Change Managements zu gewährleisten – Änderungen erleichtern, ohne Risiken für die Stabilität.

Lernziele

Zuhörenden sollen nach dem Vortrag die Grundbegriffe des „Lightweight Change-Approvals“ aus der DevOps-Welt und die Beziehungen zu ITIL kennen, den unterschiedlichen Umgang von DevOps (bzw. ITIL 4) und klassischem Ansatz (ITILv3) mit Risiken aus IT-Veränderungen erklären und interpretieren können.