Bei Veränderungsvorhaben gilt allgemein: Je mehr Betroffene (eigene Mitarbeiter, Kunden oder weitere Stakeholder) Sie zu "Beteiligten" machen, umso stärker wird später der Zuspruch für die Neuerung ausfallen, egal ob es sich um neue Prozesse, einen Kulturwandel oder um die Einführung neuer IT-Anwendungen handelt. Die Standish Group, welche jährlich den bekannten "Chaos Report" heraus gibt, identifiziert "User involvement" sogar als eine der wichtigsten Variablen für Projekterfolg bei IT-Projekten.
Foto: Gustavo Frazao-Shutterstock.com
In diesem Artikel soll nun diskutiert werden, welchen wesentlichen Beitrag das IT-Service-Management für einen gelungenen Wandel leisten kann. Die Überlegung: Im Rahmen von Rollouts großer IT-Projekte sollten Sie Ihr Service-Management - und dabei insbesondere ein proaktives Problemmanagement - nicht aus den Augen lassen. Warten Sie hier nicht erst auf den Moment, bis der Vorhang fällt, sondern binden Sie es frühzeitig mit ein.
Change Management - was denn nun?
Vorab eine kurze Begriffsklärung. Recht unglücklich ist die doppelte Belegung des Begriffs Change Management in der Literatur und Praxis, führt sie doch gerade bei IT-Vorhaben zu Verständigungsproblemen zwischen den Teams. Denn eher technisch Versierte finden sich gedanklich sofort in den ITIL-Prozessen wieder und verbinden damit die kontrollierte Veränderung einer Software.
Viele Berater meinen mit Change Management jedoch das Planen und Steuern des Veränderungsprozesses einer Organisation. So wird der Begriff auch hier verwendet. Konkret beziehen wir uns auf Veränderungen, welche durch neue IT-Systeme ausgelöst werden.
Aber der Blick auf ITIL war gar nicht ganz verkehrt. Denn wir wollen ja herausstellen, wie sich IT-Service-Management und Change Management ergänzen. Dabei fokussieren wir uns konkret auf die Teildisziplinen Incident und Problem Management: Allgemein ist ein Incident erst einmal jede Störung des Betriebsablaufs, die der Anwender einer (neuen) Software erfährt. Das Incident Management ist dann der Prozess, der diese Störung aufnimmt, dokumentiert, analysiert und zügig versucht, den Betrieb wieder herzustellen.
Problem Management unterstützt das Incident Management insofern, als dass es die Ursache für die Störungen - nämlich die Probleme wie zum Beispiel Softwarefehler, fehlerhafte (SOA-)Schnittstellen, oder etwa eine "falsche" Handhabung durch die Anwender - ergründet und dokumentiert oder sogar Umgehungslösungen (Workarounds) bereitstellt.
Ein wichtiger Unterschied der beiden Disziplinen ist, dass Incident Management reaktiv ist, da es erst in Erscheinung tritt, wenn eine Störung eingetreten ist, während das Problem Management proaktiv ist, indem es die Umstände, welche zu Störungen führen können, sowie mögliches Anwenderverhalten antizipiert und eine dokumentierte Lösung für den Support bereitstellt. Üblicherweise werden diese Ergebnisse in einer Knowledge Database festgehalten, sodass der 1st oder 2nd Level Support zügig auf diese Lösungen zugreifen kann.
Wie hilft IT-Service Management dem Veränderungsprozess?
Im Bereich des Change Managements hat sich unter anderem der Ansatz von Prosci bewährt. Diese Organisation empfiehlt unter anderem ein Vorgehen nach dem ADKAR-Modell. Dieses beschreibt die Faktoren, die für einen gelungenen Veränderungsprozess vonnöten sind. Dabei sind folgende "Bausteine" gleichermaßen zu beachten:
A - Awareness: Wahrnehmung für die Notwendigkeit zum Wandel fördern,
D - Desire: Den Wunsch nach Veränderung wecken,
K - Knowledge: Das Wissen bereitstellen, wie ein erfolgreicher Wandel funktionieren kann,
A - Ability: Die Fähigkeit zu stärken, einen Wandel auch tatsächlich durchzuführen ,
R - Reinforcement: Den Wandel schließlich nachhaltig festigen.
Schafft man es, jeden dieser Hebel zu gebrauchen, kann ein Veränderungsprozess erfolgreich werden. Der Nutzen einer Neuerung wird jedoch in den seltensten Fällen unmittelbar realisiert, meist bekommt die Begeisterung der Mitarbeiter durch die Umstellung zunächst einen kräftigen Dämpfer - kurz: die Motivation und die Produktivität sinkt.
Vereinfacht kann das durch die "J-Kurve" dargestellt werden. Sie beschreibt, wie das Leistungsniveau durch den Impuls der Veränderung zunächst absinkt, um dann mittel- bis langfristig auf das neue und vor allem höhere Leistungsniveau anzusteigen.
Foto: Ernst & Young
Durch IT-Service Management die Fähigkeit zur Veränderung stärken
An dieser Stelle kommt schließlich das IT-Service Management ins Spiel: Es wirkt in der Kategorie Ability und hilft der Organisation, den Wandel operativ durchzuführen. Denn um das Tal der Tränen möglichst zügig zu durchqueren, sollte die neue Software so störungsfrei wie möglich sein und den Arbeitsalltag der Mitarbeiter erleichtern. Falls Störungen auftreten, müssen diese möglichst rasch beseitigt werden.
Das IT-Service Management wirkt somit als wesentliche Stütze des Veränderungsprozesses des Rollouts. Wichtige Erfolgsfaktoren sind dabei folgende:
Als ersten Schritt gilt es, sich der Rolle des IT-Service Managements frühzeitig bewusst zu werden. Und dem Entwicklerteam auch klar zu machen, dass ihr Fachwissen und ihre Lösungskompetenz gefragt sein werden. Denn die besten Schulungen und die motiviertesten Multiplikatoren nützen am Ende wenig, wenn die Anwendung "stockt" und die Nutzer sich nichts sehnlicher zurück wünschen, als ihre Altsysteme. Von dieser Perspektive aus betrachtet ist das IT-Service Management sozusagen das schwächste Glied der Kette im Veränderungsprozess - reißt dieses Glied, ist die Akzeptanz von Beginn an in Gefahr.
Eine große Bedeutung kommt daher dem proaktiven Problem Management zu. Lange vor dem Go-Live, also noch während der Entwicklungsphase, sollte damit begonnen werden, bekanntes Fehlverhalten (Known Bugs) sowie mögliche Anwenderfragen zu antizipieren und wenn möglich Workarounds zu dokumentieren. Die Datenbank der bekannten Problemfälle sollte dann zum Go-Live bereits ausreichend gefüllt sein und auch während der Einführungszeit fleißig weiter befüllt werden.
Da der Incident-Prozess reaktiv ist, das heißt, er wird erst bei aufgetretener Störung gestartet, kommt es hier in erster Linie auf die Qualität der Lösung sowie auf geringe Reaktions- und Liegezeiten an. Das bedeutet, dass für die Phase des Rollouts ein ausreichend großes Support-Team, im besten Fall bestehend aus 1st-, 2nd- und eventuell 3rd Level zur Verfügung stehen muss. Dieses sollte frühzeitig in der Anwendung geschult werden und insbesondere während der frühen Rollout-Phase kontinuierlich bereit stehen, um auf Störungen zeitnah reagieren zu können. Idealerweise werden dabei Sollwerte für Antwort-, Liege- und Bearbeitungszeiten festgelegt.
Diese Überlegungen können helfen, das bei IT-Projekten oft vorherrschende "Silodenken" zwischen der technischen und der organisatorischen (Fach-)Seite zu überwinden.
Teilen Sie Ihren Teams mit, wie wichtig die IT-Service-Mitarbeiter für das Gelingen des Gesamtvorhabens sind und dass Veränderungsmanagement somit echte Teamarbeit ist. Damit Ihr Go-Life ein toller Auftritt wird, muss ihr neues System als Produkt auf die "Bühne" … die Scheinwerfer dürfen dann aber auch nicht schlapp machen. (bw)