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.
- Projektmanagement
Gegen Change-Projekte regt sich in Unternehmen häufig Widerstand, weil neue Techniken und Verfahren für die Belegschaft oft eine Veränderung der Arbeitsabläufe bedeuten. Um die Projektziele zu erreichen, ist es deshalb um so wichtiger, folgende Fehler zu vermeiden und im Zuge eines guten Projektmanagements die genannten Tipps zu beherzigen. - Widerstand gegen Change-Projekte wird unterschätzt
Bei vielen Mitarbeitern regt sich Widerstand, wenn sie mit Veränderungen ihrer Arbeitsprozesse konfrontiert werden.<br><br> Tipp: Analysieren Sie im Vorfeld welche Auswirkungen das Change-Projekt auf die Arbeitsinhalte und Mitarbeiter hat und wer besonders betroffen ist. - Veränderungen und deren Ziele werden nicht ausreichend kommuniziert
Viele Unternehmen versäumen es, ihren Mitarbeitern die Wechselvorhaben präzisse zu erläitern.<br><br> Tipp: Begründen Sie die Notwendigkeit der Veränderung möglichst bildhaft und nennen sie konkrete Beispiele. - Mitarbeitern wird ein schlechtes Gefühl vermittelt
Der Veränderungsdruck in Change-Projekten erzeugt bei den Mitarbeitern oft den Eindruck, dass die bisherige Arbeitsweise schlecht war. Die Folge: Demotivation.<br><br> Tipp: Erzeugen Sie bei der Belegschaft ein "Wir-Gefühl" für das Erreichen der Projektziele. - Guter Projektplan und professionelles Projektmanagement fehlen
Unternehmen investieren häufig zu wenig Zeit und Energie in die Planung von Change-Projekten.<br><br> Tipp: Brechen Sie Change-Projekte nicht überhastet vom Zaun und wählen Sie erfahrene Projektmanager aus. - Zu wenig positive Veränderungsenergie
Zwei Drittel der Belegschaft - die sogenannten "Fence-Sitter" - stehen Projekten anfangs unentschlossen gegenüber und verzögern die Projektenergie.<br><br> Tipp: Konzentrieren Sie Führungsarbeit und Change-Kommunikation nicht auf die "Projektgegner", sondern auf die "Fence-Sitter", um sie für das Projekt zu begeistern. - Wenig Unterstützung für Führungskräfte und Projektmanager
Change-Projekte gelingen nur, wenn die Führungskräfte selbst hinter den Veränderungen stehen und eine angemessene Unterstützung erfahren.<br><br> Tipp: Achten Sie als Topmanager und/oder Projektverantwortlicher darauf, die Führungskräfte auf der operativen Ebene als Mitstreiter zu gewinnen. - Die Mitarbeiter erfahren zu wenig Unterstützung
Gewohnte Routinen werden durch Change-Projekte oft obsolet. Das heißt: Die Verunsicherung des Mitarbeiters steigt, und seine Leistung sinkt.<br><br> Tipp: Führen Sie Mitarbeitergespräche und nehmen Sie sich ausreichend Zeit dafür. Geben Sie den Mitarbeitern Zeit für den Umstellungsprozess. - Konflikte werden negiert und unter den Tisch gekehrt
Veränderungsprozesse beschwören häufig Verunsicherung und Kompetenzprobleme herauf, die ein großes Konfliktpotenzial bergen.<br><br> Tipp: Machen Sie den Mitarbeitern klar, dass in Change-Prozessen nie alles wie geschmiert läuft. Entschärfen Sie das Konfliktpotenzial durch Gespräche. - Zielabweichungen werden zu spät erkannt und korrigiert
Gescheiterte Projekte zeigen, dass Unternehmen nicht rechtzeitig reagiert haben, wenn während des Projekts etwas aus dem Ruder gelaufen ist.<br><br> Tipp: Machen Sie klar, dass sachlich begründete Bedenken und mögliche Fehlentwicklungen thematisiert werden können und bei solchen Projekten nie alles glattgeht. - Das Topmanagement sitzt im Elfenbeinturm
Es kommt nicht gut an, wenn das Topmanagement Change-Projekte zwar verkündet, sich anschließend aber nicht mehr darum kümmert.<br><br> Tipp: Zeigen Sie Präsenz im Projekt. Zum Beispiel, indem Sie regelmäßig den Kontakt mit Mitarbeitern auf der operativen Ebene suchen und sich bei ihnen erkundigen: Wie läuft das Projekt? Was braucht Ihr zur Unterstützung? - Teilerfolge werden nicht kommuniziert und gefeiert
Viele Unternehmen vergessen im Zuge des Projekts, Teilerfolge zu kommunizieren. Bei den Beteiligten kann deshalb bisweilen der Eindruck entstehen, dass nichts vorangeht. <br><br> Tipp: Betreiben Sie Projekt-Monitoring - um Zielabweichungen früh zu erkennen und Teileerfolge verkünden zu können.
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)