Änderungsarten: Standard vs. Normal vs. Emergency Change

Die Geschäftswelt ist berüchtigt dafür, verwirrende Schlagworte und Branchenjargon zu verwenden. Dies ist auch der Fall, wenn es um die Unterscheidung zwischen Standard Change und Normal Change geht.

Es überrascht nicht, dass sich viele Menschen fragen: „Was ist der Unterschied zwischen Normal und Standard Change?“ Dies gilt insbesondere angesichts der Tatsache, dass Standard und Normal Synonyme sind, die unter den meisten Umständen relativ austauschbar sind.

Bevor wir weiter in den Kaninchenbau des Change eintauchen, sollten wir sicherstellen, dass wir uns darüber einig sind, was wir überhaupt meinen, wenn wir „Change“ sagen.

Was ist eine Änderung?

Im Kontext der IT-Geschäftswelt und insbesondere der Welt des ITIL-Managements bezieht sich eine Änderung auf Modifikationen der Softwareanwendungen der Organisation, unabhängig davon, ob es sich um interne Anwendungen oder kundenorientierte Produkte handelt. Änderungen in diesem Zusammenhang umfassen Aktualisierungen von bestehendem Code und Systemen, die getestet und in Live-Umgebungen implementiert werden.

Dieser Prozess des Änderungsmanagements wird vom Change Manager und Change Advisory Boards (CABs) durchgeführt. Das CAB befasst sich im Allgemeinen mit zwei Haupttypen von Änderungen, über die es Informationen sammelt, bevor es endgültig grünes Licht für die Implementierung gibt:

• Standardänderung
• Normale Änderung

Diese spezifischen Definitionen und Bezeichnungen können sich von einer Organisation zur nächsten je nach ihren Bedürfnissen ändern, aber es gibt einige allgemeine Regeln, nach denen sie in der Regel funktionieren. Beginnen wir mit der Erforschung dieser Prozesse, indem wir eine Standardänderung untersuchen.

(Notfalländerungen, auf die wir später eingehen, sind Änderungen, die dringlicher und sensibler sind und vom Emergency Change Advisory Board (ECAB) behandelt werden, bei dem es sich in der Regel um eine Untergruppe des CAB handelt.)

Was ist eine Standardänderung?

Standardänderungen, die manchmal auch als Routineänderungen bezeichnet werden, sind in der Regel vorab genehmigte Änderungen, die als wenig bis gar nicht risikobehaftet angesehen werden. Es handelt sich dabei um relativ häufig vorkommende Vorgänge, für die bestimmte Richtlinien und Verfahren gelten. Standardänderungen werden oft mit wiederholbaren Schritten durchgeführt, die nur selten Änderungen erfordern. Die KBS prüft in der Regel nicht jeden einzelnen Fall einer Standardänderung, sondern legt stattdessen ein Protokoll fest und gibt einen Überblick über die Richtlinien für die Durchführung von Standardänderungen.

Standardänderungen sind häufig Bereiche, in denen eine Automatisierung eingeführt werden kann, um den Prozess zu beschleunigen und die Effizienz zu steigern. Diese Änderungen haben sich zu einem sauberen, geordneten, systematischen Ansatz entwickelt, der zuverlässig zum Erfolg führt. Die Automatisierung von Aspekten dieser Standardänderungen kann die Zeit, die für den Prozess verschwendet wird, drastisch reduzieren und Arbeitsstunden für Arbeiten freisetzen, die ein wenig menschlichen Einfallsreichtum erfordern.

Das ITIL-Änderungsmanagement definiert Standardänderungen als:

„Eine im Voraus genehmigte Änderung, die ein geringes Risiko darstellt, relativ häufig vorkommt und einem Verfahren oder einer Arbeitsanweisung folgt“.

Betrachten Sie als Standard die Dienste, die die IT ihren Endbenutzern anbietet. Dienste wie:

• Lebenszyklus-Austausch von Hardware
• Software-Patching und -Updates
• Firewall-Änderungen
• Neue DNS-Einträge

Dies sind alles Beispiele für vorautorisierte Aufgaben, denen die IT-Abteilung sofort nach Auftreten einer Änderungsanfrage oder eines Bedarfs nachgehen kann. Nach der Genehmigung solcher Änderungen ist nur eine minimale Planung erforderlich, um eine Änderungsanforderung zu erfüllen.

Standardänderungen können auch betriebliche Änderungen umfassen, die einem bestimmten Zeitplan folgen, wie z. B. Aktualisierungszyklen von Druckern, Workstations und Netzwerkgeräten.

Das Verfahren zur Implementierung von Änderungen ist unkompliziert und führt selten zu Problemen oder Risiken. Vor der Genehmigung von Standardänderungen wird ein gründliches Risikobewertungsverfahren durchgeführt. Lediglich eine geschäftliche Änderung oder ein IT-Vorfall würde eine Neubewertung der mit Standardänderungen verbundenen Risiken erfordern.

Es handelt sich um eine Standardänderung, da die Genehmigung und Vorabgenehmigung im Ermessen der Organisation oder des Dienstleisters liegt. Das Verfahren zur Durchführung der Änderung ist gut dokumentiert. Die damit verbundenen Risiken werden im Voraus berechnet und berücksichtigt. Die notwendigen Maßnahmen zur Risikominderung werden im Rahmen des Änderungsverfahrens ergriffen. Sobald die Änderungsanforderung eingegangen ist, ist keine zusätzliche Genehmigung durch die Entscheidungsträger oder das Change Advisory Board (CAB) erforderlich.

Eine IT-Service-Anforderung als Standardänderung hat aus Sicht des IT-Service-Managements (ITSM) einige Vorteile. Der Change-Prozess läuft mit minimalen Reibungsverlusten ab, insbesondere wenn Informations- und Abteilungssilos zu unnötigen Verzögerungen und Einschränkungen bei der Change-Implementierung führen können. Da bereits eine Vorabgenehmigung, ein dokumentiertes Implementierungsverfahren und eine umfassende Risikobewertung vorliegen, kann die IT-Abteilung den angeforderten Service effizient und effektiv bereitstellen, was genau dem Ziel des ITIL-Rahmens im Zusammenhang mit dem Änderungsmanagement entspricht.

Es kann vorkommen, dass das CAB eingreift und feststellt, dass Elemente zur Liste der Standardänderungen hinzugefügt oder von ihr entfernt werden müssen, die nur wenig Aufsicht erfordern. Im Allgemeinen läuft eine Standardänderung während eines geplanten Wartungsfensters problemlos ab und hat, wenn überhaupt, nur geringe Auswirkungen auf die laufenden Dienste. Dies steht in direktem Gegensatz zu Notfalländerungen, die eine direkte Überwachung und sorgfältige Abwägung erfordern.

Was ist eine Notfalländerung?

Notfalländerungen sind im Grunde das genaue Gegenteil von Standardänderungen. ITIL definiert Emergency Change als:

„Eine Änderung, die so schnell wie möglich eingeführt werden muss“.

Beispiele für Emergency Change sind:

• Implementierung eines Sicherheitspatches für einen Zero-Day-Exploit
• Isolierung des Netzwerks von einem groß angelegten DDoS-Angriff (Distributed Denial of Service)

Diese Änderungen stellen typischerweise eine Krise oder eine Gelegenheit dar, die ohne übermäßiges Risiko angegangen werden muss. Daher wird ein akzeptables Risikoniveau erwartet, und es werden spezifische Verfahren zur Risikominderung angewandt. Vor der Durchführung einer Notfalländerung sind außerdem spezifische Genehmigungen und Ermächtigungen erforderlich.

Dies bedeutet keine langwierigen Sitzungen zwischen CAB-Mitgliedern, sondern eine Aufsicht auf hoher Ebene über den Änderungsmanagementprozess. In jeder Phase des Änderungsmanagementprozesses müssen alle Beteiligten schnell handeln. Infolgedessen werden die Notfalländerungen nicht gründlich getestet, und die entsprechenden Entscheidungen werden in einem ausgewogenen Verhältnis zwischen Risiko und Nutzen getroffen.

Die Agilität der Organisation bestimmt, wie gut sie mit Notfalländerungen umgehen kann. Sie folgen einem ähnlichen Change-Management-Prozessablauf wie Normal Changes, allerdings in einem beschleunigten Zeitrahmen gemäß den ITIL-Richtlinien. Der erfolgreiche Umgang mit einem Emergency Change entscheidet über die Stabilität der für die Endbenutzer bereitgestellten IT-Dienste. Daher sollten die Auswirkungen eines Emergency Change dokumentiert und im Hinblick auf künftige Verbesserungen des Change-Management-Prozesses bewertet werden.

In den Protokollen für das Management von Emergency Changes sollte auch ein Remediation- oder Back-Out-Prozess enthalten sein. So kann der ursprüngliche Zustand wiederhergestellt werden, wenn die Umsetzung von Änderungen zusätzliche Risiken und Probleme mit sich bringt.

Sie kommen nicht zu den erwarteten Zeiten und sind alles andere als alltäglich. Notfalländerungen werden als Reaktion auf unvorhergesehene Hindernisse wie Sicherheitslücken und Exploits durchgeführt. Notfalländerungen werden sofort einem Change Manager gemeldet und dann zur weiteren Analyse an das ECAB weitergeleitet. Es ist die Aufgabe des ECAB, das Risiko der vorgeschlagenen Notfalländerungen zu bewerten und die Gefahr abzuwägen, die das zugrundeliegende Problem für die Organisation und ihre Dienste darstellt.

Das ECAB ist bestrebt, eine schnelle, aber wirksame Lösung für das neu entdeckte Problem zu finden, und arbeitet unter Zeitdruck, der keinen Raum für die typische Bürokratie der meisten Änderungsvorgänge lässt. Die Informationen müssen schnell gesammelt und analysiert werden, um die beste Vorgehensweise zur Behebung des Problems zu finden. Notfalländerungen werden schnell getestet und bei Bedarf sofort umgesetzt. Das Ziel von Notfalländerungen ist es, die laufenden Dienste so wenig wie möglich zu beeinträchtigen und das Ausbluten so schnell wie möglich zu stoppen. Dies lässt nur wenig Raum für Standardverfahren, da in den meisten Fällen Standardlösungen erforderlich sind.

Was irgendwo in der Mitte zwischen Notfalländerungen und Standardänderungen liegt, ist die normale Änderung.

Was ist eine normale Änderung?

Die meisten Unternehmen definieren normale Änderungen als jede Änderung, die keine Notfalländerung oder Standardänderung ist. Normale Änderungen werden nicht im Voraus genehmigt, wie es bei Standardänderungen der Fall ist, aber sie unterliegen auch nicht dem strikteren Zeitplan und dem Wildwest-Charakter von Notfalländerungen, die eine Befreiung von Bürokratie und einschränkenden Richtlinien erfordern. Normale Änderungen durchlaufen das CAB-Verfahren für jede Änderung, die vorgenommen wird.

Dies ermöglicht die Überwachung der Änderungen und gibt dem CAB die Möglichkeit zu beurteilen, ob diese normale Änderung so häufig vorkommt, dass ihr wiederholbare Richtlinien gegeben werden können, die sie in eine Standardänderung umwandeln könnten. Jede normale Änderung wird in Form eines Änderungsantrags (Request for Change, RFC) bearbeitet, der an das CAB weitergeleitet und schließlich vom Change Manager genehmigt oder abgelehnt wird.

Normale Änderungen sind relativ häufig, erfordern aber in der Regel etwas einzigartige oder neuartige Ansätze, im Gegensatz zu Standardänderungen, die in der Regel mit Hilfe von Schritt-für-Schritt-Anleitungen oder einigen grundlegenden Skizzen durchgeführt werden können. Normale Änderungen werden einer Selbstüberprüfung unterzogen, bei der das Team die Änderung im Rahmen des Auftrags analysiert und ihre Durchführbarkeit bewertet, bevor es sie an das CAB weiterleitet. Das CAB prüft dann die vorgeschlagene Änderung und stellt sicher, dass sie der Compliance und allen Sicherheitsprotokollen entspricht, bevor sie schließlich dem Change Manager zur endgültigen Genehmigung übergeben wird.

ITIL definiert eine normale Änderung als:

„Eine Änderung, die keine Notfalländerung oder Standardänderung ist. Normale Änderungen folgen den definierten Schritten des Änderungsmanagementprozesses.“

Das sind die Änderungen, die nach einem standardisierten Prozess bewertet, autorisiert und dann geplant werden müssen. Diese Änderungen werden im Voraus antizipiert und geplant, und es können entsprechende standardisierte Change-Management-Kontrollen entwickelt werden. Normale Änderungen werden jedoch erst nach Erhalt einer formellen Genehmigung und Freigabe umgesetzt. Änderungen mit geringem Risiko können die Genehmigung der lokalen IT-Teams erfordern, während Änderungen mit hohem Risiko die Genehmigung des CAB oder der leitenden Geschäfts- und IT-Führungskräfte erfordern können. Alle Aktivitäten im Rahmen der Change-Management-Prozesskontrollen werden für normale Changes durchgeführt.

Beispiele können die Migration kritischer Informationsressourcen, Anwendungen und Arbeitslasten von lokalen Servern zu Cloud-Rechenzentren sein.

Die Definition von Changes als normale Changes verringert das Risiko für das Unternehmen und die IT-Dienstleister, da die Planung für jede Änderung sicherstellt, dass die Risiken sorgfältig gemindert werden und die Change-Anforderungen zu den gewünschten Resultaten führen. Allerdings ist die Implementierung normaler Änderungen auch ein langwieriger und zeitraubender Prozess. Neben dem Genehmigungs- und Autorisierungsprozess benötigt der Service Provider eine starke Transparenz und Kontrolle des Change-Prozesses, der unterstellten Systeme und der damit verbundenen Abhängigkeiten.

Die Verwaltung und Implementierung von Normal Changes erfordert daher fortschrittliche ITSM-Technologien, um den Change-Prozess und die Systeme sorgfältig zu analysieren, zu testen, zu verwalten und auszuführen. Sobald der Normal Change implementiert ist, evaluiert die IT den Erfolg der Implementierung und die zukünftigen Anforderungen ähnlicher Changes. Im Idealfall entwickelt die IT ihre Change-Management-Prozesse, -Tools und -Funktionen weiter, um einen Normal Change in einen Standard Change umzuwandeln. Dadurch wird die Belastung der IT und der Dienstanbieter bei der Verwaltung von Änderungen verringert, während gleichzeitig die Kontrolle über den Änderungsmanagementprozess wie bei Standardänderungen gewonnen wird.

Zusammenfassung

Dieser Prozess des Änderungsmanagements trägt dazu bei, den Erfolg von Implementierungen zu steigern und gleichzeitig das Risiko und die Ausfallzeiten zu verringern. Die verschiedenen Arten von Änderungen und ihre Einteilung in Kategorien tragen zum reibungslosen Ablauf des gesamten Änderungsprozesses bei. Standardänderungen werden mit wenig bis gar keiner Aufsicht durchgeführt, während Notfalländerungen eine sorgfältige Verwaltung und detaillierte Analyse erfordern. Normale Änderungen liegen zwischen diesen beiden Extremen.

Die Unterscheidung zwischen Standard-, Normal- und Notfalländerungen sollte aus einer konzeptionellen Perspektive betrachtet werden, die über Unterschiede in der Namensgebung hinausgeht. Die Begriffe „Standard“ und „Normal“ mögen synonym erscheinen, aber die zugrundeliegenden Unterschiede spiegeln die Wirksamkeit der Verfahren und Kontrollen des Änderungsmanagements wider. Es ist daher wichtig, eine starke Change Enablement-Praxis zu haben, um zwischen den drei Änderungstypen durch eine sorgfältige Bewertung der Änderungsanfragen und Vorfälle, die zu einer Änderungsanforderung führen, zu unterscheiden.

Diese drei Änderungstypen helfen Organisationen, Probleme zu lösen, wenn sie auftreten, während sie das konstante Tempo beibehalten, das von modernen DevOps-Organisationen erwartet wird.

Zugehörige Lektüre

• BMC Service Management Blog
• Typen & Stufen des Change Management
• Change Management in der Cloud
• Organizational Change Management (OCM): A Template for Reorganizing IT
• Facilitating Change through Effective Communication