Change Advisory Board – Hindernis oder Mehrwert? 5 Verbesserungstipps

Das Change Advisory Board, kurz CAB etabliert sich bei der Einführung von IT Change Management schnell als das Aushängeschild gegenüber den Kunden sowie gegenüber der eigenen IT. Steht eine zu beantragende Änderung an, sind die Gemüter nicht selten unterschiedlich gegenüber dem CAB eingestellt. Für den einen steht es schlichtweg als zu nehmende Hürde im Weg zum Ziel der Umsetzung seiner gewünschten Änderung. Andere nehmen das CAB als das wahr, wozu es dienen soll: Informationsaustausch, Risikoeinschätzung und Auswirkungsanalyse – kurz, ein Mehrwert um die eigene geplante Änderung möglichst reibungslos über die Bühne zu bringen. Doch wie können die Verantwortlichen des IT Change Management das CAB so gestalten, um eine positive Wahrnehmung zu unterstützen? Lesen Sie hier, wie Sie Hürden abbauen und Mehrwerte vermitteln können.

1. Offene Fragen schon vorher klären

Um die Teilnahme und Einhaltung des Change Management Prozesses, sowie die positiv eingestellte Teilnahme am CAB auch zu fördern, ist es immens wichtig, dass der Requester im CAB nicht durch ggf. unangenehme Fragen „vorgeführt“ wird. Ist die beantragte Änderung bereits getestet worden? Sind die richtigen Personen zur Information berücksichtigt? Gibt es keine anderen Changes zum geplanten Zeitpunkt? Klärt das Change Management (oder ggfs. unterstützend die Change Evaluation) diese Fragen bereits gründlich vorab, sind die meisten dieser Fragen bereits mit Vorstellung des Change beantwortet. Eine unangenehme „Blöße“ für den Antragsteller durch das Verneinen müssen einer dieser Fragen wird damit verhindert und der Antragsteller informiert auch bei seiner nächsten Änderung wieder gerne die weiteren CAB Teilnehmer über seine Änderung.

[the_ad_placement id=“dyn“]

2. Notwendige Abklärungen nicht im CAB ausdiskutieren

Werden während der Vorstellung von geplanten Change im CAB noch notwendige Abklärungen (bspw. welche Services greifen auf das CI zu, an dem ein Change stattfinden soll) identifiziert, werden diese sachlich vermerkt und zur anschließenden Klärung ggfs. als „unter Vorbehalt“ Grund zur Genehmigung mitgenommen. Andernfalls kann beispielsweise eine Zuständigkeitsfrage schnell zu unprofessionellen Diskussionen führen, welche nicht in das CAB und somit meist auch vor den Kunden oder Provider gehören.

3. Klare Einteilung der Agenda

Je nach organisatorischem Aufbau des CAB ist die disziplinäre Aufteilung, der Turnus und weitere Aspekte der Organisation von Unternehmen zu Unternehmen sehr variierend. Einige Konstanten sollten jedoch zur Etablierung des CAB einen gewissen Wiedererkennungswert aufweisen. Eines davon sollte ein gewisser Rahmen der zeitlichen Reihenfolge sein. Eine Agenda in Form von TOP´s (Tagesordnungspunkte) wie bspw.

1. Approvals
2. In Progess
3. Review

kann dabei allen Teilnehmern ein klares Bild der Abfolge mitbringen. Darüber hinaus kann es bei zeitlichen Engpässen für die Teilnehmer eine punktuelle Teilnahme zu den für Sie relevanten Topics ermöglichen.

4. Kompakte Vorabinformationen betroffener Services/Anwendungen

Um zu vermeiden, dass Stakeholder, welche als CAB Teilnehmer fungieren sollen das Interesse am CAB verlieren, ist es immens wichtig, dass diese schnell identifizieren können, ob eine Teilnahme im folgenden CAB für Sie von Relevanz ist oder nicht. Als Empfehlung eignet sich hierfür ein prominente Spalte am Anfang der Auflistung anstehender Change, welche das betroffene System oder den betroffenen Service in (für Kunden) verständlicher Formulierung anführt. Sitzt beispielsweise der Leiter der Personalabteilung anfangs dauerhaft im CAB und es werden stets nur Netzwerk-Change besprochen, welche vielleicht sogar noch andere Standorte betreffen, ist der Personalleiter im schlimmsten Fall aufgrund mangelndem Interesse ist mehr anwesend, wenn ein Update für das SAP-HR System durch den Provider angemeldet wird.

[the_ad_placement id=“dyn“]

5. Leider nicht selbstverständlich: kein Fingerpointing!

Bei einem schief gelaufenen Change ist der Review Teil des CAB, also der nach ITIL Lektüre durchzuführende „Post Implementation Review“ besonders wichtig. Im Fokus steht dabei die zielgerichtete Analyse, was zu den Umständen geführt hat und wie diese künftig nach lessons learned Charakter vermeiden werden können. Der Vorsitzende des CAB muss dabei als Moderator strikt das Aufkommen von Schuldzuweisungen oder auch direktes Fingerpointing verhindern. Die Klärung, wo nach der Ursache von Problemen oder Fehlern zu suchen ist, sollte max. bis auf Teamebene herunter gehen. Fehler, welche durch einzelne Personen verursacht wurden, werden allenfalls im Nachgang sachlich und lösungsorientiert besprochen, sie gehören jedenfalls auf keinen Fall auf „die Bühne“.

Zusammenfassung

Das CAB sollte für alle Teilnehmer einen nachvollziehbaren Mehrwert erbringen. Ist dies für einzelne Teilnehmer nicht der Fall, wird das Interesse an der Teilnahme schnell sinken. Dies ist durch das Change Management ggfs. durch Stakeholder Management vorzubeugen und entgegen zu wirken. Aus Sicht von Antragstellern sollte der gesamte Prozess des Change Management und einer Beurteilung im CAB keine zu große bürokratische Hürde darstellen.

Das CAB sollte sich, wenn auch kritisch hinterfragend, stets unterstützend verhalten und so die Teilnehmer sowie Antragsteller dadurch positiv mitnehmen und dadurch den Mehrwert des gemeinsamen Austausches damit bekräftigen.

Jan Kahmann

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert