Teilen von Rollen und Zuständigkeiten für das Änderungsmanagement im Team

Change Manager/Coordinator

Change Manager, die manchmal auch als Change Coordinator bezeichnet werden, sind in der Regel für die Verwaltung aller Aspekte von IT-Änderungen verantwortlich. Sie priorisieren Änderungsanfragen, bewerten ihre Auswirkungen, akzeptieren Änderungen oder lehnen diese ab. Außerdem dokumentieren sie Änderungsmanagementprozesse und Änderungspläne. Zu ihren Hauptaufgaben gehört die Vorbereitung, Organisation und Leitung von CAB-Meetings. Der Erfolg eines Change Managers wird in der Regel danach beurteilt, ob er Zeit- und Budgetvorgaben einhält.

Change Authority/Approver

Eine Change Authority ist eine Person, die entscheidet, ob eine Änderung genehmigt oder abgelehnt werden soll. Manchmal handelt es sich um eine einzelne Person, z. B. einen Manager oder eine Führungskraft. In anderen Fällen ist es eine Gruppe von Personen in einem Change Advisory Board. Und in wiederum anderen Fällen ist es ein Peer Reviewer. Laut ITIL 4 ist es "in besonders dynamischen Organisationen allgemein üblich, die Genehmigung von Changes zu dezentralisieren, wobei Peer-Review ein wichtiges Element für hohe Performance ist."

Change Manager arbeiten in der Regel eng mit der Change Authority zusammen, um Änderungen zu genehmigen und sie innerhalb des Unternehmens voranzubringen. In einigen Fällen, insbesondere in kleinen Unternehmen, ist der Change Manager zugleich die Change Authority und dazu berechtigt, derartige Entscheidungen zu treffen, ohne weitere Personen oder Teams einzubeziehen.

Geschäftliche Stakeholder

Geschäftliche Stakeholder sind häufig am Änderungsmanagement beteiligt und können in den Autorisierungsprozess eingebunden werden. Diese Praktik kommt angesichts der kritischen Bedeutung von Softwareservices für die meisten Unternehmen immer häufiger vor.

Wenn sich beispielsweise eine Änderung auf die Verbindung zwischen der Zahlungsabwicklungssoftware des Finanzteams und dem CRM des Vertriebsteams auswirkt, müssen Stakeholder aus den Finanz- und Vertriebsteams gegebenenfalls an CAB-Meetings und den endgültigen Entscheidungen über eine Änderung beteiligt werden.

Techniker/Entwickler

Entwicklungsteams reichen normalerweise Änderungen ein, um sie genehmigen zu lassen, und dokumentieren den Fall entsprechend seiner Notwendigkeit. Sobald eine Änderung genehmigt wurde, stellen diese Teams in Unternehmen, die einen You-built-it-you-run-it-Ansatz verfolgen, die Änderung bereit, überwachen sie und reagieren häufig auch auf Vorfälle oder Probleme im Zusammenhang mit der Änderung. In anderen Fällen kann das Vorfallmanagementteam, das für alle durch die Änderung verursachten Vorfälle verantwortlich ist, unabhängig von den Entwicklern agieren, die die Änderung implementieren.

Servicedesk-Mitarbeiter

Servicedesk-Mitarbeiter an vorderster Front können ihre einzigartige Erfahrung mit Vorfällen und allgemeinen Serviceproblemen einbringen, die eine Änderung verursachen kann.

Ops-Manager

Da Operations Manager dafür verantwortlich sind, die Systeme täglich am Laufen zu halten, ist ihre Meinung bezüglich Risiken und Abhängigkeiten gefragt.

Customer Relationship Manager

Als Sprachrohr des Kunden können Relationship Manager ihre Kenntnisse über die Denkweise von Kunden, ihre Frustrationen und ihre sich ständig ändernden Bedürfnisse einbringen.

Information Security Officer und Netzwerktechniker

Experten für Netzwerksicherheit und Cloud-Infrastruktur können wichtige Erkenntnisse zu Bedrohungen und Schwachstellen liefern.

Was ist ein CAB?

Change Advisory Boards (CABs) sind Gruppen, die die Risiken jeder Änderungsanfrage bewerten und diese genehmigen (oder auch nicht) und dazu Personen mit den oben beschriebenen Verantwortlichkeiten hinzuziehen. Normalerweise führt ein CAB regelmäßig geplante Meetings durch, um alle vorgeschlagenen anstehenden Änderungen zu überprüfen. Bei Bedarf zieht es Experten hinzu, um diese Änderungen zu erklären, zu rechtfertigen oder zu bewerten. Herkömmliche CABs sind als Gatekeeper bekannt, die die Freigabe von Änderungen kontrollieren.

Aus diesem Grund werden CABs und die damit zusammenhängenden lästigen Meetings, die langen Backlogs zu Änderungsanfragen und die Tatsache, dass sie wenig mit dem eigentlichen Tätigkeitsfeld zu tun haben, oft gering geschätzt. Glücklicherweise entwickeln sich viele CABs weiter, damit sie eine agilere Softwareauslieferung ermöglichen und eine stärker strategisch ausgerichtete Beraterrolle einnehmen können. CABs mausern sich zu Beratungsgremien, die für die Überwachung von Änderungstrends verantwortlich sind. Sie empfehlen Praktiken, um diese anzugehen, und suchen nach Möglichkeiten, um Teams dabei zu unterstützen, Kunden einen Mehrwert zu bieten und Risiken zu reduzieren.

Die Herausforderung von CABs

Gängige Klischees rund um schlechte Meetings finden sich auch in CABs. Wir kritisieren sie zu Recht als Zeitverschwendung, weil sie nicht genug erreichen, weil zu viele Leute daran beteiligt sind und weil sie durchgeführt werden, "obwohl eine E-Mail völlig ausgereicht hätte". Dies liegt zum Teil daran, dass herkömmlichen CABs zu viel Verantwortung aufgebürdet wurde.

Veranschaulichen wir die Herausforderung anhand eines Beispiels aus der Luftfahrt, indem wie uns das CAB als Tower an einem Flughafen vorstellen. Dieser Tower hat eine Aufgabe, den Flugzeugen die Erlaubnis zur Landung zu erteilen. Dem Tower würde niemals die Aufgabe übertragen, zu beurteilen, ob die Bauweise der Flugzeuge sicher ist oder ob der Pilot über die richtigen Qualifikationen verfügt, da diese Faktoren bereits vom Bundesluftfahrtamt und anderen Organisationen bestätigt wurden.

Inzwischen bestehen zu viele CABs aus einer Vielzahl von Stakeholdern und haben die Aufgabe, umfassende Sicherheitsentscheidungen über alle möglichen Arten von Änderungen zu treffen. Und dies geschieht oft am Ende der Woche, wenn sich erschöpfte Mitarbeiter schon aufs Wochenende freuen. Damit sind die Misserfolge des CAB schon vorprogrammiert.

Darüber hinaus befassen sich CABs häufig vor allem mit dem Risiko von Änderungen, die zu Vorfällen führen. Dieser Aspekt ist natürlich wichtig, doch müssen sie auch das Risiko abwägen, das durch die Verzögerung wichtiger Änderungen entstehen kann. Ein zu langsames Handeln kann nicht nur Kunden schaden, sondern für Unternehmen im hart umkämpften SaaS-Markt auch das Aus bedeuten.

Es ist möglich, dem CAB eine stärker fokussierte Rolle zuzuweisen. Mithilfe der richtigen Praktiken können viele Änderungen automatisiert werden. Das CAB kann so zu einem wichtigen Berater werden, der Trends verfolgt und mit den Teams zusammenarbeitet, um Änderungen, von denen die Kunden profitieren, schneller umzusetzen.

So positionierst du dein CAB als strategischen Berater

Der erste Schritt zur Neupositionierung des CAB besteht darin, mit der Vorstellung aufzuräumen, dass ein schwerfälliges Änderungsmanagement positive Ergebnisse liefert. Aus dem State of DevOps Report 2019 geht hervor, dass Prozesse, die die Genehmigung eines CAB erfordern, sich negativ auf die Leistung der Softwareauslieferung auswirken, und die Befragten, die diese Prozesse befolgen, waren mit einer 2,6-mal höheren Wahrscheinlichkeit weniger leistungsfähig. Darüber hinaus gab es keine Beweise dafür, dass ein formelles Genehmigungsverfahren zu niedrigeren Fehlerraten bei Änderungen beiträgt.

Aus diesem Grund ergreifen moderne Teams diese Maßnahmen, um ihre CABs zu optimieren.

Behandle nicht alle Änderungsanfragen gleich

Jede Änderungsanfrage ist eine Gelegenheit, Informationen zu erfassen und zu sammeln. Diese können Aufschluss über Erfolgsquoten, verwandte Vorfälle und die damit verbundenen Faktoren geben. Im Laufe der Zeit können Daten dazu genutzt werden, um immer mehr Änderungen vorab zu genehmigen und zu automatisieren. Nur die folgenreichsten und riskantesten Änderungen sollten eine persönliche Genehmigung erfordern.

Bringe das Änderungs- und Release-Management näher zusammen

Der veraltete Ansatz für Releases bestand darin, sie zu bündeln und alle gleichzeitig zu veröffentlichen. Anschließend müssen CABs riesige Änderungspakete in mühevoller Kleinarbeit überprüfen und genehmigen. Dieser Ansatz kann anfällig für größere Vorfälle sein und erschwert dabei zusätzlich die Suche nach der Problemursache. Darüber hinaus verlangsamt es die Geschwindigkeit, mit der Teams ihren Kunden einen Mehrwert bereitstellen können. Und das bedeutet auch, dass Change Manager und Release Manager weniger Zeit für ihre eigentlichen Aufgaben im Projektmanagement haben.

Nutze progressive Releases für Tests und Iterationen

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. Dies begrenzt den Umfang eines möglichen Vorfalls und belegt den Erfolg eines Deployments, bevor es in allen Umgebungen eingeführt wird.

Optimiere das Änderungsmanagement mit Automatisierung und Tools

High-Velocity-Teams gehen inzwischen dazu über, frühere Genehmigungsmodelle zu überdenken. Anstatt in einem wöchentlichen persönlichen Meeting einen langen Backlog von Änderungsanfragen abzuarbeiten, nutzen sie die Möglichkeiten der virtuellen Zusammenarbeit. Dies kann in Form einer einfachen E-Mail mit Details zu Änderungsanfragen geschehen, damit diese vor einem CAB-Meeting überprüft werden können. In anderen Fällen können Jira-Tickets oder Confluence-Seiten Change Reviewern den nötigen Kontext liefern, um asynchron zusammenzuarbeiten und Änderungen zu genehmigen. Mit Jira Service Management können Teams diese Möglichkeiten zur Zusammenarbeit nutzen, etwa um sich kurz per Videokonferenz abzusprechen oder einen eigenen Slack-Channel zu erstellen. So bleiben die Informationen am selben Ort und alle sind auf dem Laufenden – je nachdem, wie dein Team am liebsten miteinander kommuniziert.

Veraltete ITSM-Tools erschweren es Infrastruktur-, Operations- und Entwicklerteams, Änderungsanfragen zu übermitteln. Mithilfe von Automatisierung und moderner Software lassen sich aufwendige manuelle Eingaben von Änderungsinformationen reduzieren. Entwickler würden nur allzu gern darauf verzichten, Tickets in einem umständlichen, separaten System auszufüllen, wenn diese Aufgaben automatisch nachverfolgt werden könnten. In Jira Service Management können Teams dank Automatisierung Änderungsprozesse optimieren, Risiken minimieren und Ausfälle reduzieren.

Bringe das Änderungsmanagement mit einem Shift-Left-Ansatz näher zu den Praktikern

Eine der gängigsten Strategien, die häufig CAB-Genehmigungen ersetzt oder reduziert, ist der Peer Review. Dabei wird die Verantwortung für die Identifizierung von Problemen im Code an diejenigen übertragen, die am meisten davon verstehen. ITIL 4 weist darauf hin, dass es "in besonders dynamischen Organisationen allgemein üblich ist, die Genehmigung von Changes zu dezentralisieren, wobei Peer-Review ein wichtiges Element für hohe Performance ist." In ähnlicher Weise wurde im State of DevOps Report 2019 empfohlen, dass "Unternehmen während des Entwicklungsprozesses einen Shift-Left-Ansatz verfolgen und auf Peer Review basierte Genehmigungen umsteigen".

Um Vorschriften einzuhalten, muss dieser Ansatz sorgfältig dokumentiert werden. Hier kommen Systeme wie Bitbucket ins Spiel, die Autoren und Peer Reviews automatisch nachverfolgen und verhindern, dass Änderungen ohne den erforderlichen Prozess veröffentlicht werden.

Bei Atlassian ist der Peer Review ein zentraler Bestandteil des Genehmigungsprozesses. Einer unserer IT-Risiko- und Compliance-Experten erklärt es so: "Der gesamte Atlassian-Code wird in Bitbucket gespeichert. Wenn Entwickler eine Änderung vornehmen möchten, checken sie den Code von Bitbucket aus und verschieben ihn auf ihren Laptop. Wenn sie ihn wieder in das Bitbucket-Repository einchecken, anstatt den Code zu aktualisieren, wird vom System ein Peer Review angefordert. Erst nachdem diese Überprüfung abgeschlossen und genehmigt wurde, wird der Code zurück in das Repository gepullt. Und wenn der Code nicht genehmigt wird? Dann wird er zusammen mit den Anmerkungen des Peer Reviewers an den ursprünglichen Entwickler zurückgeschickt. Dieser behebt den jeweiligen Fehler und reicht den Code erneut für einen Peer Review ein."

Ziehe Experten hinzu, um Best Practices umzusetzen

Unternehmen werden immer komplexer. Daher spielt die Vereinfachung des Informationsflusses und der Koordination zwischen den Teams eine immer größere Rolle. Anstatt einzelne Änderungsanfragen zu genehmigen, können CABs ihren Fokus auf die Verbesserung der Praktiken verlagern. In diesem Paradigma können sie Empfehlungen zur Verbesserung der Praktiken geben, bessere Funktionen implementieren sowie Ressourcen und Tools bereitstellen, die zu einer besseren Leistung führen. Dies erweitert die Kompetenzen des CAB und verringert das Risiko, dass nützliche Lösungen zu langsam auf den Markt kommen.

Selbst in stärker traditionell geprägten IT-Organisationen kann das CAB zu einem Ort für kreative Lösungen werden. Eine risikoscheue Universität, die sich an ältere ITSM-Tools und -Praktiken klammerte, musste beispielsweise herausfinden, wie sie Studenten über einen wichtigen Service informieren sollte, der nicht verfügbar sein würde. Das CAB wurde in diesem Fall zu einem Forum für das Brainstorming neuer Kommunikationsformen. Man einigte sich darauf, Süßigkeiten und Plakate in einer Kampagne zu verteilen, mit der eingehende Anfragen über ein geplantes Systemupgrade erfolgreich abgewehrt wurden.