Die 10 Best Practices für das Änderungsmanagement

Wenn es darum geht, ein gesundes Mittelmaß aus Risiko und Schnelligkeit zu finden, gibt es im Änderungsmanagement keine Universallösung. Jedes Unternehmen hat seine eigene Kultur, Risikotoleranz und regulatorischen Anforderungen und sollte diese Überlegungen in seine Praktiken für das Änderungsmanagement einbeziehen.

Um das Risiko beurteilen zu können, musst du auch die behördlichen Anforderungen und Compliance-Verpflichtungen deines Unternehmens kennen. Wenn behördliche Bestimmungen ins Spiel kommen, geht es nicht mehr darum, wie viele Ausfälle dein System riskieren kann, bevor dein Unternehmen geschäftliche Verluste macht, oder wie viel die Ressourcen für die Behebung des Problems kosten werden. In diesem Fall handelt es sich um ein nicht verhandelbares Regelwerk. Du wirst einige Genehmigungen einholen müssen. Du wirst Verpflichtungen aufteilen müssen. Bei Vorschriften wie SOX und DSGVO gibt es für bestimmte Aktivitäten keinen Handlungsspielraum, auch wenn das den Prozess ein wenig verlangsamt.

Die gute Nachricht ist, dass Pläne nicht unumstößlich sein müssen. Unternehmen, die sich für einen konservativen Ansatz mit mehr Genehmigungen und starren Workflows entscheiden, können im Laufe der Zeit eine Neubewertung durchführen und die Strenge ihrer Prozesse an das Risikoniveau anpassen.

Mit Jira Service Management können Genehmigungsprozesse und Workflows an die Vorgaben von Unternehmen angepasst werden. Prozesse lassen sich nach Belieben flexibel gestalten oder automatisieren. Zum Beispiel könntest du risikoarme Prozesse automatisieren und kompliziertere Vorgänge durch Genehmigungen absichern.

Die Nachverfolgung von Metriken, insbesondere der Verbindungen zwischen Änderungen und Vorfällen, ist eine wichtige Grundlage für die Verbesserung deiner Änderungspraktiken. Die Daten werden Trends hervorheben und die Arten von Änderungsmanagement, Teammitglieder und Services aufzeigen, die mit der geringsten Wahrscheinlichkeit von einem Vorfall betroffen sein werden. Diese Informationen können dir dabei helfen, die Strenge auf das Risiko verschiedener Änderungsanfragen abzustimmen.

Mit einer intelligenten Risikobewertung können oft mehr Änderungsanfragen auf weniger strenge Genehmigungs-Workflows herabgestuft werden. Wie der adaptive Änderungsmanagementprozess von Gartner nahelegt, können Unternehmen anstreben, dass immer mehr normale Änderungen als Standard klassifiziert und dann vorab genehmigt und automatisiert werden.

Im Folgenden haben wir einige praktische Schritte zusammengestellt, mit denen Standardänderungen zum ganz normalen Vorgang werden.

1. Überprüfe deine Änderungen in den letzten Monaten.
   • Welches waren die häufigsten Änderungen?
   • Welche Änderungen sind "Standardänderungen"?
   • Auf welche Services wirken sie sich aus?
   • Welche Änderungen waren erfolgreich?
   • Wie lange hat die Implementierung dieser Änderungen durchschnittlich gedauert?
   • Welche Änderungen wurden von Entwicklungsteams angefragt?
2. Wähle drei bis fünf Standardänderungen aus, die automatisiert werden sollen.
3. Erstelle in deiner Servicemanagementsoftware Self-Service-Anfragetypen für die Standardänderungen.
   • Füge Text hinzu, um den Zweck und Umfang der standardmäßigen Änderungsanfrage zu verdeutlichen.
   • Fülle wichtige Felder aus, wie das System, die Anwendung oder der Service, der geändert wird.
   • Erstelle Automatisierungsregeln, um Änderungen automatisch zu genehmigen, Status zu ändern und Mitarbeiter über Updates zu benachrichtigen.
4. Nimm dir Zeit, um dein IT-Personal und Entwicklungsteams über diese neue Funktion zu informieren und sie darin zu schulen.
5. Überwache die Leistung in den nächsten Monaten.
   • Gewinne Erkenntnisse, um deine bestehenden Angebote zu verbessern.
   • Identifiziere zusätzliche Standardänderungen, die automatisiert werden sollen.

Nachdem du die bisherigen Praktiken deines Teams für das Änderungsmanagement evaluiert und das Änderungsrisiko bewertet hast, ist es hilfreich, die Dokumentation zur Risikobewertung zentral zusammenzutragen. Durch die Confluence-Integration von Jira Service Management erhalten Teams eine zentrale Informationsquelle in einem Änderungsplandokument. Auf dieser Seite können Mitarbeiter eine Änderungsplanvorlage sowie Informationen zur Risikobewertung hinzufügen.

Niemand braucht zusätzliche Arbeit. Deshalb wird das Änderungsmanagement häufig als lästige Pflicht betrachtet. Beim Änderungsmanagement werden Mitarbeiter oft aufgefordert, etwas zu dokumentieren – und das häufig in einem Tool, mit dem sie ungern arbeiten – und auf einen Prozess mit ein oder zwei zusätzlichen Schritten zu warten. Und Entwickler, die Code veröffentlichen müssen, können diese zusätzlichen Aufgaben für ihre eigentliche Arbeit als hinderlich empfinden. Hier kann eine zentrale Informationsquelle, z. B. ein Änderungsplan auf einer Confluence-Seite, die Dokumentation durch Einbeziehung des gesamten Teams vereinfachen.

Die Lösung für diese Herausforderung besteht darin, Änderungsmanagementprozesse so einfach wie möglich zu gestalten. Achte darauf, dass möglichst wenig Genehmigungen erforderlich sind. Wähle technische Tools aus, die sich nahtlos integrieren lassen, damit Entwickler nicht dieselben Informationen in mehrere Systeme eingeben müssen. Und automatisiere Abläufe, wo immer möglich. Diese Funktionen von Jira Service Management bieten Teams die Flexibilität, im eigenen Tempo und mit eigenen Methoden zu arbeiten.

Je einfacher du den Prozess gestalten kannst, desto leichter kannst du Teams langfristig davon überzeugen.

In den meisten traditionellen IT-Organisationen wird ein Change Advisory Board (CAB) damit beauftragt, die technischen und geschäftlichen Auswirkungen von Änderungsanfragen zu bewerten. Der übliche Prozess bringt einige Herausforderungen mit sich, wie langsame Releases, behäbige Prozesse und manchmal auch eine mangelnde Kommunikation und Zusammenarbeit. Aus diesem Grund überdenken besonders leistungsstarke Teams das CAB-Modell.

Dabei soll der Wert erhalten bleiben, den diese Boards für unsere IT-Prozesse schaffen. Sie ermöglichen Kommunikation, wägen die Notwendigkeit von Änderungen mit deren Risiken gegeneinander ab und sorgen gleichzeitig dafür, dass typische CAB-Prozesse beweglicher und strategischer werden. Dies bedeutet in der Regel:

• dass nur bei besonders riskanten Änderungen die Genehmigung des CAB eingeholt werden muss (und bewährte Tools wie Peer Review, virtuelle Checklisten und Automatisierung verwendet werden, um weniger riskante Änderungen zu handhaben),
  
• dass CABs mit der Strategieerstellung beauftragt werden und Teams bei der Entwicklung von Praktiken unterstützen, die Risiken und Workloads des Änderungsmanagements durch Prozesseffizienz und -automatisierung reduzieren,
  
• dass CABs virtuell und in Echtzeit stattfinden, damit nicht mehr auf persönliche Meetings gewartet werden muss, um wichtige Änderungen anzusprechen oder Fragen zu bearbeiten.

Das Entscheidende hierbei ist die Verlagerung hin zur Strategie. Das neue CAB ist nicht mehr dazu da, um als sogenannter Gatekeeper zu fungieren, sondern um Veränderungen zu begünstigen. Es ist eine strategische Ressource, keine Behinderung mehr. Code-Reviews und technische Kleinstdetails sind Peer Reviews und Personen vorbehalten, die Fehler in Code am besten erkennen können. Und das CAB hat wieder mehr Zeit, um sich auf Prozesse und Strategien zu konzentrieren und die Continuous Delivery zu unterstützen.

Der veraltete Ansatz für Releases bestand darin, sie zu bündeln und alle gleichzeitig zu veröffentlichen. Die meisten von uns wissen jetzt, dass dieser Ansatz anfällig für größere Vorfälle ist und es schwieriger macht, die Ursache eines auftretenden Problems zu finden. Kleinere häufigere Releases können das Ausmaß eines potenziellen Vorfalls begrenzen. Ein progressives Team stellt Canary-Releases oder Feature Flags für eine kleine Gruppe von Benutzern bereit, um die Stabilität vor dem vollständigen Deployment zu testen und nachzuweisen.

Kleinere kontrollierte Releases lassen sich einfacher organisieren, wenn Teams sie anhand eines Änderungszeitplans koordinieren können. Dadurch können Entwickler Konflikte leichter vermeiden und Tage erkennen, an denen es zu Ausfällen kommen kann. Die Änderungsmanagerfunktionen von Jira Service Management gewähren Teams Zugriff auf einen zentralen Zeitplan mit den nötigen Informationen zur Umsetzung dieser verteilten Releases.

ITIL hat nicht immer den besten Ruf. Die Praktik wird als restriktiv und überholt betrachtet. Tatsächlich hat ITIL IT-Teams aber viel zu bieten, auch solchen, die eine DevOps-Kultur eingeführt haben. Nicht dass ITIL zu starr ist, ist das eigentliche Problem, sondern vielmehr die Art und Weise, wie wir diese Leitlinien umsetzen.

Wenn du ITIL-Prozesse als eine Reihe von unumstößlichen Regeln auffasst, kann sich das natürlich restriktiv anfühlen. Wenn du sie jedoch als grundlegende Leitlinien verstehst, auf denen dein Unternehmen aufbauen kann, wirst du sie als willkommene Hilfestellung bei der Entwicklung deiner Praktiken für das Änderungsmanagement betrachten.

Dies gilt für jedes Framework und jeden kulturellen Ansatz. Ob ITIL, Lean, DevOps, Agile oder CD – kein Framework, so beliebt es auch ist, wird all deine Probleme auf einen Schlag lösen. Viel zu oft erhoffen wir uns, dass ein Framework oder Tool unsere internen Probleme löst, wenn wir eigentlich die Lösung in unserer Teamkultur suchen sollten.

Von CABs bis hin zu DevOps-Gruppen setzen erfolgreiche Teams auf Zusammenarbeit, Offenheit und Updates in Echtzeit. Das Änderungsmanagement ist dazu da, um Teams zu koordinieren. Änderungen, Vorfälle und Probleme haben Wellenauswirkungen, von denen mehr als ein Team betroffen ist. Diese Tatsache wird umso augenfälliger, je komplexer dein Unternehmen wird.

Ein gutes Änderungsmanagement ist in isolierten Umgebungen einfach nicht möglich. Unternehmen, die eine offene Zusammenarbeit fördern, werden sehr wahrscheinlich ihre Änderungspraktiken verbessern.

Jira Service Management ist darauf ausgelegt, Teams zusammenzubringen, damit sie ihre Ziele schneller erreichen – in diesem Fall durch schnellere und reibungslose Änderungen. Zusammenarbeit ist der Dreh- und Angelpunkt starker High-Velocity-Teams. Eine transparente Plattform mit Tools wie Confluence, integrierten Chats und Videokonferenzen sowie anpassbaren Workflows ermöglicht es allen Mitarbeitern, schnell individuelle und informierte Beiträge zu leisten.

Chaos Engineering ist eine neuere Praktik, die sich auf Tests der Ausfallsicherheit konzentriert und bei der Komponenten eines Produkts oder eines Service unterbrochen oder abgeschaltet werden. In ähnlicher Weise geht das Resilience Engineering bewusst auf alle möglichen Stressfaktoren eines Systems ein, zum Beispiel die Auslastung des Systems durch hohe Benutzerzahlen oder ein hohes Datenverkehrsaufkommen.

Beide Praktiken dienen dazu, Probleme und Änderungen zu identifizieren, die vorgenommen werden müssen, um zukünftige Vorfälle zu vermeiden. Dieser präventive Ansatz ist extrem nützlich für Änderungsmanagementteams und verringert deutlich den Zeitaufwand, die Kosten und die Alarm-Fatigue bei Vorfallmanagementteams.

Funktionierende Prozesse für das Änderungsmanagement sollten in alle Tools integriert werden, die deine Entwickler verwenden. Wenn du von Teams verlangst, ein neues Tool zu erlernen, Informationen in mehrere Tools einzugeben oder ein Tool zu verwenden, das sie nicht gewohnt sind oder das unpraktisch ist, verlangsamt das die Einführung. Und dies beeinträchtigt wiederum deine Fähigkeit, Kunden wertvolle Updates zu liefern.

Wir bei Atlassian verfolgen Änderungen mithilfe von Jira Service Management. Die Jira-Plattform bringt Entwicklungs- und Operations-Teams auf einfache Weise zusammen und bietet Transparenz und nachvollziehbaren Kontext – und zwar noch bevor Entwickler überhaupt mit dem Programmieren beginnen –, bis zu dem Moment, an dem Änderungen für die Produktion bereitgestellt werden.