Digitale Exzellenz
Digitale Exzellenz

Mensch vs. Maschine: Change Management – ein Begriff, zwei Disziplinen

, 3. Januar 2022

Lesezeit: 10 Minuten

Mensch vs. Maschine: Change Management – ein Begriff, zwei Disziplinen

Egal, ob Unternehmen Veränderungen an der IT oder an der Organisation vornehmen: Meist fällt der gleiche Begriff: Change Management. In der Praxis unterscheiden sich beide Disziplinen eklatant. Zeit für eine Aufklärung, was beide Disziplinen unterscheidet und voneinander lernen können.

Viele Unternehmen betreiben in der Praxis häufig, ohne es zu wissen, zwei Ansätze für ihr Veränderungsmanagement. Einen exklusiv für die IT und einen anderen für Veränderungen den Menschen oder die Organisation betreffend. Oft wissen jedoch Involvierte der beiden Disziplinen nichts, über die Existenz oder die Legitimation der jeweils anderen, obwohl sie sich in bestimmten Fällen sogar selbst bedingen. Mit ITIL verändern Unternehmen Maschinen, mit Prosci Menschen.

Change Management nach ITIL

Wer seine IT weiterentwickelt, betreibt Veränderungsmanagement – „technisches“ Veränderungsmanagement. Als Instrument werden die meisten ITler das sogenannte ITIL-Framework kennen. Es liefert umfangreiche Best Practices zur Instandhaltung und Weiterentwicklung technischer Systeme auf verschiedenen Dimensionen. Eine davon ist das Change Management und es umfasst die Koordination und Realisierung von Veränderungen an einem IT-System in drei möglichen Ausprägungen:

  • hinzufügen,
  • entfernen und/oder
  • ersetzen von Bestandteilen.

Veränderungen an Servern in Serverschränken, virtuellen Servern, Applikationen auf Servern oder Netzwerkstrukturen zur physischen und virtuellen Verbindung jener Infrastruktur haben mitunter komplizierte Auswirkungen auf bereits bestehende Systeme. Change Manager begleiten jede Veränderung durch einen genau definierten Prozess: Unternehmen verhindern so, dass ihnen durch die Veränderung wirtschaftliche Schäden entstehen.

Schnittstellen nach ITIL sind typischerweise das Release Management, das Incident & Problem Management und das Configuration Management. Es gibt geplante Veränderungen an einem IT-System, also Releases zu einem festgelegten Zeitpunkt. Darüber hinaus gibt es ungeplante Veränderungen, dessen Ursprung Incidents & Problems sind. Das Configuration Management hält in der sogenannten Configuration Management Data Base (CMDB) fest, was installiert ist, wo und in welcher Version und Anzahl es installiert ist und wie hoch die Lebenserwartung dieser Komponenten ist.

Jede Veränderung im technischen Sinn wird mit einem einmaligen Identifizierer versehen und im besten Fall mit einem IT-Service-Management (ITSM) unterstützt. Damit weiß jeder zu jeder Zeit, wer für welche Veränderung an einem IT-System für was verantwortlich ist, wie groß der Umfang des Changes ist und wie der Arbeitsstand ist.

Change Management nach ITIL
Der Change-Prozess nach ITIL

Change Management nach Prosci

Demgegenüber steht das Change Management, das Menschen und die Organisation betrifft. Technische Anpassungen lösen häufig Veränderungen der menschlichen Arbeit aus. Dennoch kommen unterschiedliche Methoden zum Einsatz. Eine ist die Procsi-Methodik: Der Mensch, im Mittelpunkt aller Handlungen, wird durch den sogenannten ADKAR-Prozess begleitet.

Der erste Baustein Awareness (A) = Bewusstsein vermittelt, warum eine Veränderung nötig ist, warum sie genau jetzt wichtig ist, was aktuell nicht richtig läuft, welche Vorteile sich daraus ergeben (für Organisation und Mitarbeitende) und was passiert, wenn nichts verändert würde. Ohne dieses Bewusstsein gibt es kein Verlangen.

Das Element Verlangen = Desire (D) motiviert und fördert die bewusste Entscheidung für eine Veränderung beim Menschen, abhängig von der individuellen Ausgangslage der Mitarbeitenden, ihren eigenen Interessen für oder wider die geplante Veränderung und organisatorischen Bedingungen. Ohne jenes Verlangen, ist der Mensch nicht bereit, sich neues Wissen anzueignen.

Neues Wissen = Knowledge (K) wird den Betroffenen im dritten Baustein vermittelt. Dazu gehören neue Fähigkeiten, neues Verhalten, neue Prozesse, Systeme und Tools, neue Rollen und Verantwortlichkeiten. All das muss erlernt werden, abgestuft nach vorhandenem Wissen und bestehenden Kompetenzen und abgestuft nach dem persönlichen Lerntempo. Zugang zu neuem Wissen zu schaffen, ist ein kritischer Erfolgsfaktor: Es geht darum, zu wissen, welche Dinge gemacht werden müssen (Effektivität) und wie sie richtig gemacht werden (Effizienz).

Letztere steigt mit der Fähigkeit = Ability (A), Gelerntes korrekt umzusetzen. Die Theorie in die Praxis zu überführen ist der letzte Schritt bevor sich Erfolge einer Veränderung einstellen. Ein Mensch muss dafür physisch, psychisch und intellektuell in der Lage sein. Im besten Fall wird sie oder er dabei in der Anfangszeit professionell begleitet und hat die Zeit, sich in der neuen Arbeitsumwelt zurechtzufinden.

Ist eine Person oder eine Organisation so weit gekommen, gilt es den neu erreichten Zustand zu verstärken. Verstärkung = Reinforcement (R) der erzielten Erfolge durch aufrichtige und sinnvolle Anerkennung sorgt schlussendlich für eine nachhaltig erfolgreiche Veränderung in der Organisation und beim Menschen.

Das Projektmanagement und das Top Management sind die wichtigsten Schnittstellen im Change-Management nach Prosci. Das Top Management beschließt die Veränderung, beispielsweise eine Softwareneueinführung oder einen organisatorischen Umbau. Das Projektmanagement steuert die Umsetzung des Beschlusses. Das Change Management gewährleistet die Akzeptanz bei den betroffenen Mitarbeitenden und stellt damit den Nutzen der Entscheidung sicher.

Change Management nach Prosci
Der Change-Prozess nach Procsi

Gegenüberstellung: ein Begriff für zwei Disziplinen

Im Vergleich beider Change-Management-Welten, lassen sich folgende interessante Unterschiede feststellen:

Ort der Veränderung

Technisches Change Management findet zunächst fast immer in einer Testumgebung statt. Abseits der Live-Version wird implementiert, getestet, angepasst, justiert und erneut getestet. Erst danach wird die Veränderung in eine Produktivumgebung implementiert. Nur in Ausnahmefällen werden Änderungen direkt am „offenen IT-Herzen“ durchgeführt.

Anders beim Change Management für Mensch und Organisation: Ein Unternehmen kann eine Ausgliederung von Tochtergesellschaften oder einen Zukauf nicht im staubfreien Labor simulieren, um zu erfahren, wie die Belegschaft die Veränderung annimmt – auch wenn sich dank Digital Twin gerade einiges tut. Allerdings kann ein Unternehmen je nach Art der Veränderung Testgruppen bestimmen und zum Beispiel neue Abläufe erproben lassen, bevor sie für Alle im Unternehmen gelten.

Change-Prozess

Beide Disziplinen des Change Managements sehen ein sequenzielles Vorgehen vor. Es gibt eine klar definierte Abfolge von Aktivitäten, die alle Beteiligten einhalten sollen. Das Change Management, das den Menschen betrifft, erlaubt jedoch mehrere Schleifen, bezogen auf Entwurfsstadien einer Veränderung. Das gilt etwa bei den beiden Prozessbausteinen Knowledge und Ability. Ansonsten sollte jedes Level erfolgreich durchlaufen worden sein. Danach erst kann der nächste Change-Schritt gestartet werden.


IT ist kompliziert, der Mensch komplex

Der entscheidende Faktor, den technische Change Manager beachten müssen ist, dass nach dem Change alles kompatibel ist mit der übrigen Systemlandschaft, dass beispielsweise Schnittstellen vorhanden sind und funktionieren. Change Manager, die mit Menschen arbeiten, müssen vor allem mögliche Emotionen berücksichtigen, die eine Veränderung mit sich bringen.

Beide Faktoren erfordern eine Harmonisierung mit der Umwelt. IT-Changer haben es wahrscheinlich etwas leichter. In der Regel lässt sich im Vorfeld zu 100 Prozent sicherstellen, dass eine Komponente A (z.B. ein Server) mit einer Komponente B (z.B. einem Netzwerkkabel) kompatibel ist und beide somit harmonieren. Die Harmonie endet meist erst mit dem Ende der Lebensdauer einer der beiden Komponenten. Die Configuration Management Data Base (CMDB) hilft hierbei enorm. In der Datenbank sind u.a. Hardware, Software, Firmware und Lizenzen mit ihren verschiedenen Merkmalsausprägungen archiviert. Häufig reicht ein Blick in die CMDB, um mit Sicherheit sagen zu können, was verändert werden kann und was nicht.

Eine derartig exakte Prognose für Veränderungsvorhaben gibt es im Change Management mit Menschen nicht. Ob und in welcher Intensität der Umbau eines Teams Ärger oder Freude bei den Betroffenen auslöst, lässt sich nie vollkommen sagen. Im Vorfeld sollten deshalb die Personen, Gruppen und das Gesamtgefüge so individuell wie möglich analysiert und im Veränderungsprozesses betreut werden. Multiplikatoren (Change Agents) sind hier sehr hilfreich.

Die vorherrschende Kultur und die Veränderungshistorie im Unternehmen sind gute Seismografen, um zu bestimmen, welche Veränderungen „kompatibel“ für die Mitarbeitenden sind und welche nicht. Eine hundertprozentige Sicherheit gibt es jedoch nicht.

Das sogenannte Cynefin-Framework bringt es auf den Punkt: Demnach sind technische Veränderungen „kompliziert“, den Menschen betreffende Veränderungen sind dagegen als komplex einzustufen.

Rollenunterschiede

Beim Change Management für Menschen gibt es ein breites Rollenspektrum. Procsi spricht von (Haupt-) Sponsoren, Führungskräften, Change Practitioner (Change Manager) und Change Agents. Das technische Change Management nach ITIL kennt im Kern nur zwei Rollen: den Change Manager und die Change Authority, also eine Person oder eine Gruppe von Personen.

Eine weitere Besonderheit ist, dass der Change Manager nach Procsi durchaus in der Praxis gleichzeitig Projektmanager sein kann und parallel zu seinen internen Change-Aufgaben die Akzeptanz der Veränderung bei den Endnutzern verantwortet. ITIL zieht für das technische Change Management eine klare Grenze. Es bestünde ein Interessenkonflikt. Der Change Manager könnte unter anderem bei der Planung verfügbarer Testumgebungen das eigene Projekt bevorzugen.

Beim Change Management, das für den Menschen gedacht ist, lassen sich durchaus Synergien nutzen, wenn Change Management und Projektmanagement in einer Hand liegen. Organisatorische Veränderungen oder strategische Produktanpassungen wirken sich oft auf interne Abläufe und auf Kundenprozesse aus. Hier ist es nützlich, wenn eine Person beide Seiten im Blick hat.

Die Unterschiede im Überblick: Merkmale einer VeränderungChange Management (Maschine)Change Management (Mensch)
ObjektIT-Komponente/IT-SystemMensch/Gruppe von Menschen
Wichtigstes Veränderungskriterium des VeränderungsobjektesKompatibilitätEmotion
PlanbarkeitHochModerat
ErfolgsgarantieHochModerat
ProzessSequenziellSequenziell, bedingt agil
Freigebende RolleChange-AuthorityHauptsponsor
Koordinierende RolleChange-ManagerChange Practitioner (Projektmanager)
Cynefin-FrameworkKompliziertKomplex
Anwendbares FrameworkITILProsci
Gegenüberstellung der beiden Ansätze im Change Management

Was der Mensch von der Maschine lernen kann und was nicht

In der Praxis, vor allem durch die Digitalisierung der Arbeit, findet technisches Change Management und Veränderungsbegleitung für die Mitarbeitenden sehr nah beieinander statt und bedingen sich gegenseitig. Beide Disziplinen können somit voneinander lernen.

Nach Prosci kann es sich zum Beispiel anbieten, ähnlich wie bei ITIL, eine Klassifizierung jeder einzelnen Veränderung vorzunehmen. Jede Veränderung wird nach Art und Umfang kategorisiert und mit einmaligen Identifizierern versehen, was verändert soll und wer betroffen ist – am besten IT-gestützt. Dort wo es möglich ist, wird eine Veränderung für einen Test vorbereitet, genehmigt, getestet und wieder durch ein Gremium für den Rollout freigegeben.

Eine 1:1-Übertragung von Change Management nach ITIL auf Menschen ist allerdings nicht möglich. Ein nicht übertragbares Element ist der sogenannte Sättigungspunkt einer Veränderung. Es ist nach Prosci nicht eindeutig beschrieben, wann Menschen keine neuen gleichzeitig ablaufenden Veränderungen mehr zulassen.

Die Definition dieser Sättigung funktioniert nur bei technischen Veränderungen. Wenn es zehn Testumgebungen gibt und ein Veränderungsvorhaben exklusiv eine Testumgebung benötigt, dann können gleichzeitig zehn Veränderungsvorhaben getestet werden. Gibt es keine exklusive Nutzung einer Testumgebung, bieten die vorhandene Rechenkapazität einer Testumgebung und durch SLA-gesteuerte Performance-Standards eine Kapazitätsgrenze.

Eine solche mathematische Planung ist mit Menschen nicht zu machen: Es ist nicht zu beantworten, wie viele unterschiedliche Veränderungen welcher Art ein Mensch zur gleichen Zeit bewältigen kann. Die Rechenleistung eines Servers lässt sich objektiv bestimmen, die unserer Gehirne nicht.

Zudem ist sie nicht die einzige wichtige Veränderungskomponente. Das schnellste Gehirn wird eine Veränderung nicht umsetzen, wenn es diese Veränderung nicht umsetzen will. Der Wille der Maschine, sich zu verändern, existiert nicht. Er spielt damit für das technische Change Management keine Rolle. Zumindest noch nicht. Vielleicht müssen Change Manager eine KI-Lösung irgendwann fragen, ob sie einer Anpassung am Algorithmus zustimmen.