3. Wenn das Change-Management keines ist
Ein drittes Fallbeispiel, das den Nutzen einer übergreifenden Prozesssicht belegen soll, drehte sich um das Change-Management. In einem internationalen Unternehmen wurde der über alle Länder Europas standardisierte SAP-Service innerhalb von nur drei Jahren wieder landesspezifisch verwässert. Die daraus resultierende Komplexität führte zu Budgetüberschreitungen für Changes und zu einer ansteigenden Fehlerquote. Die Termintreue bezüglich der zugesagten Verfügbarkeiten von Änderungen im Produktivsystem war zu schwach, die Kunden fühlten sich schlecht bis gar nicht informiert.
Diese Situation verweist auf eine schwache Governance, einen mangelhaft eingeführten Itil-Prozess sowie das Fehlen von verbindlich geregelten Rollen und Verantwortlichkeiten. Zudem wird hier die integrative Sicht auf den Change-Management- und den Release-Management-Prozess schmerzlich vermisst.
Die Change-Governance sollte eine saubere Kategorisierung von Change-Requests sowie deren konforme Erfassung im Prozess vorantreiben. Nur so lässt sich die Wurzel des strategischen Problems schnell ausfindig machen. In diesem Fall waren trotz zentralisierter IT und eines aus strategischen Gründen gewollten Standards rund 75 Prozent aller Change Requests (CRs) landesspezifisch. Durch eine Adaption der Verrechnungs- und Budgetrichtlinien ließ sich der Trend umkehren.
Es gab mehr Incident- als Problem-Tickets
Anhand des Inputs zum Change-Prozess wurde dann die Herkunft der CRs gemessen. Es gab mehr Incident-Tickets, die einen Change Request auslösten, als Problem-Tickets. Nach Itil kann aber berechtigterweise nur ein Problem-Ticket einen CR aus dem Service-Support in Gang setzen. Im Klartext heißt das: Man änderte mal schnell den Quellcode, um Störungen zu beseitigen, ohne zuvor das Problem systematisch untersucht und dokumentiert zu haben. Dieses Vorgehen aber sollte höchstens erlaubt sein, um wohlbekannte und fest definierte "Standard-Changes" effizienter zu machen.
Nach der Korrektur dieses Prozessfehlers und Behebung der damit einhergehenden Ineffizienzen konnte sich das Team auf weitere Schwächen im Change-Prozess konzentrieren. Zunächst wurde die Anzahl der Change Requests verringert. Dann ging es darum, die Termintreue zu verbessern.
Im Fokus des Prozessteam stand nun die Planungsqualität des Forward Schedule of Change (FSC). Anhand von Stichproben wurde klar: Der offiziell kommunizierte Plan, nach dem die Change Requests abgearbeitete wurden, war allenfalls ein "Best Guess". Der Versuch, Zuverlässigkeit und Ressourceneffizienz unter einen Hut zu bringen, wurde durch fehlende Prozessdisziplin, nicht implementierte Richtlinien, fehlende Governance und einen eingeschränkten Blick auf die Schnittstelle zum Release-Management zunichtegemacht.
Beispielsweise wurden "Emergency Changes", eigentlich für existentielle Geschäftsprobleme gedacht, missbraucht, um Änderungen zu beschleunigen. Das selbstverständlich in der Überzeugung, kundenorientiert zu agieren, wobei in Wahrheit die Zuverlässigkeit und Professionalität der IT beim Kunden in Misskredit gebracht wurde. Zudem gab es Transporte außerhalb des Release-Kalenders. Eine Änderung des FSC wurde den Antragstellern nicht zeitnah mitgeteilt - geschweige denn zuvor mit ihnen abgestimmt. Durch eine ganzheitliche Betrachtung der Change-Management-Prozesse veränderten sich die kritischen Werte positiv.