Close

Ready for ITSM at high velocity?

10 Best Practices für das Änderungsmanagement

Das Änderungsmanagement hat den Ruf, prozesslastig, behäbig und schwierig zu sein. Muss es aber nicht. Bei richtiger Ausführung reduziert das IT-Änderungsmanagement die Zahl der Vorfälle und sorgt neben agilen Prozessen auch für weniger Arbeitsunterbrechungen.

Wie sollten wir das Änderungsmanagement also angehen? Diese zehn Best Practices sind ein guter Ausgangspunkt:

1. Entwickle ein Verständnis für die Risikotoleranz deines Unternehmens und plane entsprechend

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.

2. Nutze eine datengesteuerte Risikobewertung, um deine Änderungsmanagementpraktiken kontinuierlich anzupassen

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 Änderungen, 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.

3. Mache das Änderungsmanagement so einfach wie möglich

Kein Mensch braucht zusätzliche Arbeit. Deshalb wird das Änderungsmanagement häufig als lästige Pflicht betrachtet. Änderungsmanagementpraktiken verlangen oft, dass Mitarbeiter etwas dokumentieren – und das häufig in einem Tool, mit dem sie ungern arbeiten – und auf einen Prozess mit ein oder zwei zusätzlichen Schritten warten. Und Entwickler, die Codes veröffentlichen müssen, können diese zusätzlichen Aufgaben für ihre eigentliche Arbeit als hinderlich empfinden.

Die Lösung für diese große Herausforderung besteht darin, Änderungsmanagementprozesse so einfach wie möglich zu gestalten. Sorge dafür, dass möglichst wenig Genehmigungen erforderlich sind. Wähle nahtlos integrierbare, technische Tools aus, damit Entwickler nicht dieselben Informationen in mehrere Systeme eingeben müssen. Und automatisiere Abläufe, wo immer das möglich ist.

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

4. Überdenke das herkömmliche CAB-Modell

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.

5. Nutze Tools, um deine Prozesse zu automatisieren und optimieren

Die Automatisierung deiner Tools ist eine der besten Möglichkeiten, um den Aufwand von Änderungsmanagementprozessen für deine Teams zu verringern. Einfache gegenseitige Kontrollen in unseren Tools sorgen dafür, dass wir Vorschriften einhalten und Risiken reduzieren können, ohne dass einzelne Personen unnötig Zeit für neue Prozesse aufwenden müssen.

Guy Herbert, Risk Futurist bei Atlassian, erklärte kürzlich in einem Artikel über Compliance und Risiko: "Die Wahrheit ist, dass die meisten von uns nicht unbedingt einen sechsphasigen Genehmigungsprozess und ein mehrere Monate dauerndes Hin und Her mit Compliance-Genehmigungs-Boards brauchen … Wirklich wichtig wären einfachere gegenseitige Kontrollen, um sicherzustellen, dass nicht konforme Änderungen erst gar nicht abgenickt werden. Vieles davon können unsere Tools selbst erledigen. Mit Bitbucket können unsere Entwickler beispielsweise den Code, an dem sie gearbeitet haben, nicht wieder zurück in die Datenbank pushen, bevor er von einem anderen Entwicklerkollegen überprüft wurde. Bamboo führt keinen neuen Code ein, der die Compliance-Prozesse in Bitbucket nicht durchlaufen hat."

6. Stelle kleinere Releases schrittweise bereit, um sicherzustellen, dass deine Änderungen funktionieren

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.

7. Behandle ITIL als Leitlinien, nicht als verbindliche Regeln

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.

8. Priorisiere die Zusammenarbeit

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.

9. Nutze Chaos Engineering und Resilience Engineering zu deinem Vorteil

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.

10. Wähle Tools aus, mit denen deine Entwicklungsteams vertraut sind und mit denen sie gerne arbeiten

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.