Den ITIL 4 Change Management-Prozess verstehen (und wie Automatisierung die IT verbessern kann)

Was ist Change-Management?

ITIL 4 Change Management bezieht sich auf eine Reihe von Richtlinien, die von der ITIL-Stiftung erstellt wurden. Diese Richtlinien helfen Unternehmen bei der Verwaltung digitaler Produktänderungen minimale Reibung oder Risiken.

ITIL 4 ist die vierte Überarbeitung dieser Richtlinien, wobei die erste Version bereits 1989 veröffentlicht wurde! Im Gegensatz zu ITIL 3, das eine Reihe speziell definierter Prozesse für Unternehmen festlegte, zielt ITIL 4 darauf ab, flexible Leitlinien bereitzustellen. Wichtig ist, dass Unternehmen die in ITIL 3 beschriebenen spezifischen Prozesse übernehmen und dennoch vollständig mit den ITIL 4-Richtlinien kompatibel bleiben können.

Die Change-Management-Empfehlungen von ITIL 4 enthalten in erster Linie spezifische Definitionen für Schlüsselkonzepte und Rollen, die im IT-Betrieb vorkommen. Die beschriebenen Konzepte sind verallgemeinert, sodass sie unabhängig von der tatsächlichen Unternehmensstruktur universell anwendbar sind. Ziel ist es, dass Organisationen ihre eigenen Prozesse und Praktiken unter Berücksichtigung des von ITIL 4 festgelegten Change-Management-Frameworks entwickeln.

Die Empfehlungen von ITIL 4 Hand in Hand nutzen Analyse der Risikovorhersage ändern kann die Release-Geschwindigkeit erheblich beschleunigen und Produktteams dabei unterstützen, insgesamt risikoärmere Änderungen vorzunehmen. Bleiben Sie den Risiken einen Schritt voraus mit Digital.ai Intelligence.

Warum ITIL 4 für das Änderungsmanagement verwenden?

Änderungen sind ein fester Bestandteil des täglichen IT-Betriebs, egal in welche Kategorie sie fallen. Vor Jahrzehnten wurden Änderungen auf seltene Patch-Ereignisse oder Konfigurationsaktualisierungen beschränkt, die nur ein paar Mal im Jahr oder seltener stattfanden. Mittlerweile erhalten einige der beliebtesten Anwendungen, Dienste und Plattformen der Welt jedes Jahr Tausende von Änderungsaktualisierungen. Google hat 2018 bekanntlich darüber berichtet hat allein in diesem Jahr über 3,000 Änderungen an seinen Suchmaschinenalgorithmen vorgenommen, durchschnittlich etwa 9 pro Tag.

Angesichts der vielen Veränderungen, die sich in so rasantem Tempo vollziehen, benötigen IT-Organisationen eine strukturierte Methode zur Integration und Bereitstellung von Änderungen, um das Risiko von Serviceunterbrechungen zu minimieren. Gleichzeitig müssen die Verantwortlichen im IT-Betrieb alle Hindernisse beseitigen, die der Geschwindigkeit der Änderungen im Wege stehen. Jede unnötige Verzögerung oder Sperre behindert die Wertschöpfungskette.

Das stellt ein Paradoxon dar: Wir müssen Veränderungen in einem umsetzen safe viel schneller als je zuvor.

Der kürzlich aktualisierte ITIL-Änderungsmanagementprozess soll dieses Problem lösen. Das Hauptziel des ITIL 4-Änderungsmanagements besteht darin, alle Hindernisse für die Implementierung von Änderungen zu beseitigen und gleichzeitig die effiziente Kontrolle über Betriebsmetriken und andere Ziele des Änderungsrisikomanagements beizubehalten. In diesem Sinne schlägt ITIL 4 ein Framework zur Änderungsaktivierung vor, anstatt einen starren Satz vorgeschriebener Änderungsmanagementprozesse zu definieren.

Durch die Übernahme der Ideale von ITIL 4 und deren individuelle Anpassung an die jeweilige Unternehmensumgebung können IT-Betriebsteams die Geschwindigkeit von Veränderungen beschleunigen und gleichzeitig Ineffizienzen – und störende Bedrohungen – minimieren.

ITIL 4 zielt darauf ab, das Änderungsmanagement weniger umständlich zu gestalten

Die ursprünglichen Versionen von ITIL – die erste wurde Ende der 1980er Jahre veröffentlicht – legten streng Prozesse fest, die den IT-bezogenen Aktivitäten einer Organisation Vorhersehbarkeit und Struktur verleihen konnten. Dieser Leitfaden war von entscheidender Bedeutung für Unternehmen, in denen die IT-Anforderungen entweder unbekannt waren oder zu Unvorhersehbarkeit führten. Es war das Produkt einer Welt, die mit aufkommenden Technologien nicht vertraut war, und sowohl Unternehmen als auch Regierungsorganisationen waren hungrig nach diesem Maß an spezifischer Beratung.

In den frühen 2000er Jahren kam es jedoch zu einem großen Wandel in den Methoden der Softwareentwicklung: Agile. Mit agilen, starren „Wasserfall„Entwicklungsprozesse wurden abgeschafft. Dies gab den einzelnen Entwicklungsteams mehr Autonomie und Kontrolle über ihre Endergebnisse, die in deutlich kürzerer Zeit erreicht werden konnten.

Agile machte die Idee populär, dass sich Anwendungen und Technologieplattformen kontinuierlich weiterentwickeln könnten – solange man daran arbeitet, sicherzustellen, dass jede neue Änderung einen Mehrwert für die Endbenutzer darstellt.

Als Reaktion auf den Aufstieg der agilen Methodik (und DevOps Danach war ITIL gezwungen, sich anzupassen. ITIL v3 baute auf bestehenden ITIL-Änderungsprozessen auf und entwickelte ein Modell für die kontinuierliche Umsetzung von Änderungen, das viele Organisationen mit den folgenden Schritten befolgten:

1. Erstellen Sie einen Änderungsantrag (RFC)
2. Überprüfen Sie RFC
3. Lassen Sie den RFC von einem Change Advisory Board (CAB) bewerten und bewerten
4. Autorisieren Sie Änderungen basierend auf dem RFC
5. Planen Sie Aktualisierungen
6. Koordinieren Sie die Umsetzung
7. Deploy/integrate neue Änderungen
8. Überprüfen Sie die Änderungen und schließen Sie den Änderungsdatensatz

Diese Version des ITIL-Änderungsmanagementprozesses war zuverlässig, wiederholbar und übte ein hohes Maß an Kontrolle über das Ergebnis von Änderungsvorschlägen aus. Außerdem war es für einige Organisationen immer noch ziemlich umständlich.

Die Notwendigkeit einer ständigen CAB-Überprüfung verzögert Änderungen und könnte zu erheblichen Ineffizienzen führen. Dadurch wird der durch jede einzelne Veränderung geschaffene Wert belastet.

Als Reaktion auf diese Mängel schlug das neue ITIL 4-Framework vor, das starre Änderungsmodell „Vorschlag > Genehmigung > Implementierung > Abschluss“ bestimmten Änderungen vorbehalten zu lassen, die als nicht standardisiert galten. Während das ITIL 4-Framework also Raum für einen „normalen“ Änderungsmanagementprozess lässt, der aus früheren Versionen bekannt ist, ermutigt es IT-Betriebsleiter, so viele Änderungen wie möglich in eine andere Kategorie zu migrieren: Standardänderungen.

Beschleunigen Sie die Änderungsgeschwindigkeit mithilfe der Standard-Änderungsmodelle von ITIL

In ITIL v3 gab es eine Kategorie vorgeschlagener Änderungen, die als „Standardänderungen“ bezeichnet wurden. Diese wurden als risikoarm eingestuft und würden in der gegebenen IT-Umgebung häufig auftreten. Beispiele angeboten Dazu gehörten Passwortänderungen, neue Einstellungsverfahren und die Verlagerung von physischer Ausrüstung.

Mit ITIL 4 erkennen ITSM-Führungskräfte, dass Unternehmen danach streben können, Standardänderungen als Norm und nicht als besondere Ausnahme von „normalen Änderungen“ zu etablieren. Es wird vorgeschlagen, dass durch die Modellierung von Änderungskategorien oder spezifischen Änderungstypen in vielen Kontexten kein formalisiertes Gatekeeping und keine CAB-Genehmigung mehr erforderlich sind.

Wenn man herausfindet, welche Änderungen tatsächlich „normal“ (also „geringes Risiko“) sind, kann man die meisten Engpässe beseitigen, die der Agilität im Wege stehen. Wenn Änderungen mit höherem Risiko in den formalen RFC-Prozess eingeführt werden, können die Leiter des IT-Betriebs auch damit beginnen, das Risiko zu akzeptieren, zu mindern oder abzulehnen.

Der Prozess der Implementierung einer normalen Änderung kann heute weitgehend automatisiert werden. Das bedeutet, dass die Änderung, sobald sie von der Entwicklung vorgeschlagen wird (häufig als Reaktion auf das Datenfeedback des IT-Betriebs), getestet, integriert und in der Produktionsumgebung bereitgestellt und anschließend mit wenig bis gar keinem menschlichen Eingriff abgeschlossen werden kann.

Während also Standardänderungen den normalen Änderungsprozess widerspiegeln, wird der RFC durch einen Prozess mit geringer Latenz statt durch eine formalisierte CAB-Überprüfung überprüft und autorisiert.

Anpassung des ITIL-Änderungsmanagementprozesses, um Änderungen zu beschleunigen und gleichzeitig Risiken zu verwalten

Jeder Schritt des ursprünglichen ITIL 3-Änderungsmanagementprozesses kann im Wesentlichen beibehalten werden, ohne dass Geschwindigkeit oder Flexibilität darunter leiden.

Vorschläge des aktualisierten ITIL 4-Frameworks Zur Anpassung des Change-Management-Prozesses einer Organisation gehören:

• Erstellung von Änderungsmodellen für wiederkehrende Änderungen
• Dezentralisierung der Änderungsgenehmigung für Standardänderungen
• Größere Änderungen in kleinere Teile aufteilen, die weniger Risiko bergen
• Durch automatisierte Prüfungen, Tests und Bereitstellungen

So könnten sich Anpassungen in Bezug auf jeden Schritt eines formelleren ITIL-Änderungsmanagementprozesses widerspiegeln:

Anfrage auf Veränderung

Einzelne vorgeschlagene „normale“ Änderungen sollten zunächst im Vergleich zu einem Standardänderungsmodell betrachtet werden, um zu sehen, ob die Änderung tatsächlich den Genehmigungsprozess umgehen kann. Änderungen, die ein „geringes Risiko“ aufweisen und einige Merkmale vormodellierter Änderungen aufweisen, können aufgeteilt werden, sodass nur der neuartige Vorschlag formell berücksichtigt wird, während Standardkomponenten vorab autorisiert werden.

Wenn möglich, können RFCs automatisch als direkte Reaktion auf einen angezeigten Änderungsbedarf auf der Grundlage von aus dem IT-Betrieb abgeleiteten Datenrückmeldungen generiert werden. Automatisch generierte RFCs können dann in das vorgeschlagene Änderungs-/Feature-Portfolio integriert werden. Automatisierte RCFc reduzieren die Notwendigkeit von Notfalländerungen, da sie Risiken proaktiv identifizieren und dann darauf abzielen, dieses Risiko anzugehen, vorzugsweise indem sie sich so nah wie möglich an vormodellierten Standardänderungen orientieren.

Bewertung ändern
Gemäß ITIL 4 sollten CAB-Sitzungen einberufen werden, um besondere Umstände zu behandeln, und nicht nach einem voreingestellten Rhythmus oder als Teil eines Standardänderungsverfahrens geplant werden. Eine einzige Change-Manager-Rolle kann oft ausreichen, um das gegebene Risiko oder die Auswirkung einer Änderung zu bewerten, wenn ihr Urteilsvermögen durch ergänzt wird KI-gestützte Analytik. Standardänderungen können größtenteils oder vollständig durch einen automatisierten Prozess ausgewertet werden, wodurch ein Rückstand an Überlegungen verhindert und gleichzeitig die Latenz erheblich reduziert wird. Normale Änderungen, die einer formellen Genehmigung bedürfen, können zur Grundlage eines neuen Standard-Änderungsmodells werden oder dazu beitragen, bestehende Standard-Änderungsmodelle zu aktualisieren, um sie einem breiteren Anwendungsbereich anzupassen.

Berechtigung ändern
Ein Hauptziel des auf Agilität ausgerichteten Change Enablement Frameworks von ITIL 4 ist es, die Anzahl der Änderungsautorisierungen so weit wie möglich zu reduzieren. Durch die Modellierung von Änderungen kann die Autorisierung in den meisten Fällen sofort erfolgen und mithilfe von Analysen Änderungsrisiken bewerten kann die vom Menschen gesteuerte normale Änderungsautorisierung weniger umständlich und weniger forschungsintensiv machen.

Planen Sie Änderungen
Die Änderungsplanung und Build-Autorisierung kann durch den Einsatz von Änderungsanalysen erheblich optimiert werden, bis hin zur nahezu vollständigen Automatisierung. Die manuelle Planung und Änderungs-Build-Planung sollte so weit wie möglich reduziert werden. Auch hier kann die Modellierung von Änderungen die Rolle der Unsicherheit eliminieren, indem Änderungen, die besondere Aufmerksamkeit erfordern, von solchen isoliert werden, die schnell geplant und in eine zukünftige Release-Bereitstellung integriert werden können.

Deploy/Neue Änderungen integrieren
Mit unserer Release Management-Tools, die Bereitstellung und Integration von Änderungen wurde in vielen Unternehmen weitgehend automatisiert. „Normale“ Änderungen mit geringem Risiko sollten priorisiert werden, d. h. die meisten Änderungen sollten keine manuelle Bereitstellung oder Integration erfordern. Änderungen, die Aufmerksamkeit erfordern, können nach der Bereitstellung überwacht werden, wodurch die Notwendigkeit einer direkten menschlichen Überwachung für eine kleine Teilmenge riskanter Änderungen reduziert wird.

Überprüfen Sie die Änderungen und schließen Sie den Änderungsdatensatz
Die Bedeutung umfassender Änderungsabschlüsse sollte nicht übersehen werden. Es hat sich gezeigt, dass sie unvorhergesehene Probleme und Störungen wirksam reduzieren. Diese Maxime bedeutet jedoch nicht, dass IT-Organisationen umständliche manuelle Überprüfungsprozesse einführen müssen, um sicherzustellen, dass jede Änderung stabil ist und in der erforderlichen Dokumentation korrekt widergespiegelt wird.

Änderungsabschlüsse gehören selbst in kleineren Organisationen zu den Prozessschritten des Änderungsmanagements, die sich am ehesten für die Automatisierung eignen. Automatisiertes Testen und Überprüfen übernehmen eine „Qualitätssicherungs“-Rolle, während automatisierte CMDB-Updates und andere Aufgaben zum Abschluss von Änderungen die Notwendigkeit eines manuellen Abschlusses von Änderungen verringern. Diese Praktiken gewährleisten vollständigere Aufzeichnungen und verringern das Risiko, dass organisatorische Fehler die Integrität von CMDB-Daten und anderen wichtigen Aufzeichnungssystemen beeinträchtigen können.

Beschleunigen Sie die Bereitstellung von Änderungen mit IT Analytics in jedem Prozessschritt

Menschen sind kreativ und können hervorragende Problemlöser sein, aber wir sind nicht so gut wie Computer, wenn es darum geht, Tausende von Codezeilen oder Millionen von Dateneinträgen schnell zu überprüfen. Analytics bietet diese Funktionalität und kann die IT-Produktivität erheblich steigern und gleichzeitig Ihren Änderungsüberprüfungs- und Bereitstellungsprozess flexibler gestalten.
Durch das Hinzufügen von KI- und ML-Modellen werden die IT-Fähigkeiten weiter verbessert, indem automatisch Muster in Daten aufgedeckt werden, die das menschliche Auge möglicherweise nicht erkennen kann, z. B. Risikofaktoren für Änderungen oder die Wahrscheinlichkeit, dass eine bestimmte Änderung störende Auswirkungen auf die Leistung hat.

Diese Funktionalitäten veranschaulichen die entscheidende Rolle der Technologie bei der Verwaltung der Technologie, die wir täglich erstellen und ändern. Während die Automatisierung von Änderungen für moderne Change-Management-Praktiken nicht unbedingt notwendig ist, wird sie in den ITIL-Richtlinien als bewährte Methode betrachtet, die in einer Welt, in der Geschwindigkeit in Millisekunden und nicht in Monaten gemessen werden kann, von entscheidender Bedeutung ist.