Akteure im Change Management müssen oft erläutern, welche Art von Change Management sie betreiben: Ist es das Human Change Management (HCM) oder auch Organizational Change Management (OCM), also das was gern mit dem deutschen Begriff Veränderungsmanagement umschrieben ist? Gemeint ist: die systematische Begleitung einer strategisch ausgerichteten organisationalen Änderung, die Unterstützung beim Wandel der Unternehmenskultur oder die Begleitung von Veränderungsprojekten allgemein?
Oder ist das Change Management gemeint, das nach ITIL® als Teil des IT-Servicemanagements und in Verbindung mit weiteren IT-SM-Prozessen genutzt wird, um Änderungen der IT-Services zu beantragen, zu prüfen, zu entwickeln, zu testen und ins System zu spielen?
Letzteres ist oft ein erfolgskritischer IT-Service in Unternehmen, ersteres ist gelegentlich „nice to have“ und benötigt laufende Unterstützung der Leitungsebene, um erfolgreich agieren zu können. Bleibt diese aus, verkommen Veränderungsmanagement-Teams zu einer ornamentalen Crew von Schöngeistern, an deren Existenz man sich ab und zu erinnert, um singuläre Workshops zu moderieren oder Projekte mit etwas internem Marketing zu begleiten.
Gerade in hochkomplexen ERP-Systemen mit vielen tausend Nutzenden können kleinere Anpassungen des IT-Systems, die über das Change Management nach ITIL® dokumentiert und prozessiert werden, einen hohen Impact auf die Nutzung haben, wenn zum Beispiel ein neuer Prozess-Schritt oder eine neue Rolle eingebaut wird, wenn bisher analoge Aufgaben digitalisiert werden, Oberflächen modernisiert werden oder eine Erweiterung der Stammdatenpflege notwendig wird. Im schlimmsten Fall müssen Geschäftsprozesse des Unternehmens gestoppt werden, weil plötzlich Daten fehlen oder IT-gestützte Freigaben nicht mehr stattfinden. Schaut man dann näher hin, stellt sich heraus, dass Nutzende nicht informiert oder trainiert wurden, dass Betriebsprozesse einer Unit nicht angepasst wurden oder dass es für die neuen Systemrollen keine Menschen gab, die diese Rolle bekommen und die Aufgabe ausführen.
Bei unserem Kunden entstand daher der Wunsch, das Geschehen im IT-Servicemanagement und das klassische Veränderungsmanagement so miteinander zu verbinden, dass Nutzende in jedem Fall mitgenommen, informiert und trainiert werden können, unabhängig davon, ob es sich um einen kleineren Change oder ein ganzes IT-Projekt handelt.
Gemeinsam mit unseren internen Sparringspartnern haben wir daher die Methodik des klassischen Veränderungsmanagements in das IT-SM Modell komplett integriert. Diese Fusion von Veränderungsmanagement und Change Management sorgt nun dafür, dass die mit dem Change einhergehenden prozessualen, technischen und organisationalen Änderungen im Standard ermittelt und im Hinblick auf Nutzerrelevanz und Impact bewertet werden. Daraus können dann sowohl Maßnahmen des Veränderungsmanagements als auch Trainingsmaßnahmen abgleitet und auf den Nutzer-Impact zugeschnitten werden. Darüber hinaus sorgt die frühe Zuordnung der Änderungen zu Rollen und Aufgaben für Erwartungssicherheit in den einzelnen Geschäftsbereichen – und man kann z.B. bei Rollenänderungen rechtzeitig reagieren.
Kern der Methode ist die Dokumentation im IT-SM Tool, die von Prozessverantwortlichen, IT und Vertretern der Nutzenden gemeinsam erarbeitet und geprüft wird. Prüfkriterien des Veränderungsmanagements wurden in Quality Gates eingearbeitet. Dabei lag der Fokus auf einer pragmatischen Vorgehensweise, um die Dokumentationslast so gering wie möglich zu halten.
Lessons Learned für den Kunden und für uns: Veränderungsmanagement und Changemanagement müssen keine getrennten Welten sein. „Blended Changemanagement“ sorgt für Erwartungssicherheit und für ein rechtzeitiges gemeinsames Verständnis von dem, was im Veränderungsmanagement getan werden muss. So verstanden wird Veränderungsmanagement zum Enabler im IT-Servicemanagement und steigt von „nice to have“ auf zum essentiellen Standard und Erfolgsfaktor.
