Man kommt im Service Management heutzutage an ITIL nicht mehr vorbei.
Aus eigener Erfahrung kann ich sagen, dass mit ITIL überschaubar Ordnung in komplexe Prozesse gebracht werden kann, dass es aber auch viel Overhead gibt. Während meiner ITIL-Schulung war ich mir nicht sicher, ob man diesem in jedem Unternehmen gerecht werden kann.

Aus erster Hand weiß ich mittlerweile, dass auch große IT-Dienstleister manchmal überfordert sein können. Denn nicht die Anzahl der Mitarbeiter lässt auf den Erfolg von ITIL in der Praxis schließen, sondern der Grad der Adaption an eigene Anforderungen und Ressourcen. In meinem Beispiel arbeitet das Unternehmen schon seit je her nach ITIL und die gesamte Unternehmensorganisation lebt ITIL.

Ich möchte mich auf das Change Management beschränken. Nach ITIL wird Change-Management als ein Prozess definiert, der „das Ziel hat, dass alle Anpassungen an der IT-Infrastruktur kontrolliert, effizient und unter Minimierung von Risiken für den Betrieb bestehender Business Services durchgeführt werden.“[1]

Ein Kunde von uns nimmt mit Hilfe einer Software Changes auf. Es kann unter anderem nach Infrastruktur, Release, Incident, Known-Error etc. kategorisiert werden. Neben der Nennung von Betroffenen, Verantwortlichen und Freigebenden ist die Klassifizierung der Changes existentiell. Ist der Change ein Notfall, Standard, Normal, Beschleunigt oder hat er vielleicht sogar gar keine Auswirkungen?

Verschiedene Klassifizierungen durchlaufen entsprechend verschiedene Genehmigungsstufen. Bei einem ‚Normal-Change‘ reicht je nach Risikostufe die Freigabe des Changemanagers (prüft formale und terminliche Richtigkeit) und des Change-Koordinators (Durchführende Instanz; prüft inhaltliche und technische Richtigkeit). Bei einer höheren Risikostufe muss der Change im CAB vorgestellt und dort zusätzlich freigegeben werden. Die Praxis zeigt, dass ein Change teilweise schon nach wenigen Stunden freigegeben sein kann oder auch schon mal erst nach 1-2 Wochen. Man sollte also Changes immer mit genug Vorlaufzeit einstellen.

Wie zuvor erwähnt ist die „Minimierung von Risiken für den Betrieb“ [2] das Ziel. Zeitweilig kann ein Change aber kurzfristig dringend notwendig sein, weil zum Beispiel schnellstmöglich ein Update ausgerollt werden muss, damit der Betrieb nicht gefährdet ist. In solchen Notfällen hat man noch nicht mal vorher Zeit eine Testphase zu durchlaufen, geschweige denn die Change-Vorlaufzeit einzuhalten. Hier muss ein ‚Notfall-Change‘ eingestellt werden. Diese Art von Changes durchlaufen einen anderen Genehmigungsprozess. Auf den ersten Blick, mag dieser schlanker wirken: Es ‚reicht‘ die Freigabe durch eine vorher bestimmte Instanz z.B. Manager on Duty. Er hat die Funktion, diese Changes freizugeben und trägt aber die Verantwortung, diesen zu dokumentieren und sicherzustellen, dass trotz des Notfalles alles in kontrollierten Abläufen stattfindet. Aufgrund der Kritikalität für den Betrieb wird der Prozess zeitlich also zwar verkürzt, nicht aber die Dokumentation oder Auseinandersetzung mit dem Change. Im Nachgang werden also Dokumente erstellt und Beweise geliefert. Man sollte also für verschiedene Situationen unterschiedliche Changemodelle haben[3].  

Für manche Unternehmen kann diese Art der Umsetzung des Change Management schon viel zu bürokratisch sein; es ist jedoch wichtig, ITIL als Empfehlung und Vorschlag zu verstehen. Jedes Unternehmen muss für sich selbst klären, welche Anforderungen es hat und wie die Empfehlungen, Prozesse und Rollen angepasst, umgesetzt und erfolgreich gelebt werden können. In der Praxis hat jede Prozessveränderung Kosten und Nutzen. Und die kann je nach Kontext sehr unterschiedlich sein. 

Autor: Ebru Doğru
April 2017