Change in Silos

Das Prinzip von ITIL® Change Management kann so einfach sein: Sollen Bodenfliesen gelegt werden, muss der Estrich glatt und trocken sein. Also müssen sich zwei Handwerker unterhalten und mit dem Architekten einen Zeitplan abstimmen, den alle Arbeiter und der Bauherr kennen sollten. Die Einführung von Change Management in gut funktionierenden IT Organisationen wird oftmals in einem Silo-Ansatz durchgeführt, das ist schon eine gute Idee, wenn man die Tücken beachtet.

Die Grundidee des Silo Ansatzes ist meist an einer Aufbauorganisation orientiert. Die diversen organisatorischen Einheiten bilden ein Silo. Es gibt eine koordinierende Stelle, die Change Requests (RfC) an ein Silo weiterleitet, die zuständige organisatorische Einheit arbeitet diesen RfC weitestgehend Eigenständig ab und meldet die Erledigung an die zentrale Stelle zurück.

Ein solcher Ansatz hört sich erst mal nicht so schlau an. Was ist gewonnen? Zum Beispiel ein einheitlicher Nachweis der Änderungshistorie. Meist wird nämlich ein zentrales Tool für Change Management eingeführt, das alle Änderungsanträge und deren Lebenszyklus festhält. Auch können in einem solchen Ansatz die verschiedenen Change Modelle entwickelt werden. Wartungsfenster werden vereinheitlicht und ein Change Schedule zentral gepflegt. Der Change Schedule kann dann wichtige Änderungen an die betroffenen Benutzer kommunizieren. Auch kommt es durchaus vor, dass über diesen Weg vorbildlich geführte Abteilungen die schlampigen Nachbarn erziehen sollen. Wenn die „Guten“ in der Überzahl sind und das politische Umfeld mitmacht, funktioniert das sogar.

Nachteile des Silo-Ansatzes sind jedoch wie zu erwarten. Angenommene Change Requests werden gerne in dem Silo gehalten, das heißt die Bewertung führt meist zu einer zu geringen Risikokategorie. Änderungen die verschiedene Silos betreffen, sind eher selten und funktionieren meist mangels Abstimmung nicht gut. Das Change Advisory Board (CAB) ist eher hierarchisch aufgestellt, trifft sich selten und alle Beteiligten haben das Gefühl sich nicht so gerne in die Angelegenheiten des anderen Silos einmischen zu wollen. Das heißt, nur Änderungen der Risikokategorie Eins werden sinnvoll durch das CAB geplant. So führt der Silo Ansatz in eine Sackgasse und in ein falsches Verständnis von Change Management.

Wie wäre es denn mit dem Ansatz „Change Management in Silos“ sehr deutlich als Zwischenschritt zu kennzeichnen? In diesem Zwischenschritt würde ich kein CAB vorsehen, sondern genauso wie die Struktur der Aufbauorganisation beibehalten wird, auch die bestehenden Gremien so lassen wie sie sind. Nachdem sich dieses Silo Change Management eingeschwungen hat, sollte eine Hierarche von Change-Autoritäten entwickelt werden und ein zentrales Change Management Team geschaffen werden, das unabhängig von den Silos RfCs prüft, bewertet und koordiniert. In dieses Team kann dann auch das Post Implementation Review angesiedelt werden.

Change Mangement ohne Change Advisory Board hört sich komisch an. Ich sprach jedoch von einer gut funktionierenden IT Organisationen und die hat in der Regel Steuerungsgremien schon in der Vergangenheit die Teilfunktionen des CAB ersetzen. Wenn kein CAB existiert, ist sehr klar das noch ein Entwicklungsschritt im Change Mangement existiert. Ein hierarchisch besetztes CAB in ein fachlich besetztes CAB zu wandeln kann ein langer Weg sein.

Schreibe einen Kommentar

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

Dein Kommentar wird manuell freigeschaltet. Ich bitte um Geduld, das kann manchmal etwas dauern.