Change-Management-Plan: Widerstand entschärfen, bevor er entsteht

Ein Change-Management-Plan für ein ERP-Programm legt fest, wie Menschen von ihrer heutigen Arbeitsweise zu der Arbeitsweise kommen, die das neue System verlangt, und wer dafür verantwortlich ist. Er beginnt mit der Mobilisierung, nicht mit dem Training. Er hat sieben Teile, jeweils mit einem benannten Verantwortlichen, und ist in Charter, Design-Workshops und Quality Gates eingebunden, statt als Nebenstrang nebenherzulaufen.

Die meisten Widerstände kommen nicht aus dem Nichts. Sie bauen sich langsam auf, lange vor dem Kickoff. Man hört sie in Nebenbemerkungen in frühen Meetings. Man merkt, wie wichtige Ansprechpartner aus den Fachbereichen still werden. Bis ein formaler Change-Plan entworfen ist, ist der Schaden meist schon angerichtet.

Es beginnt meist an ein paar vorhersehbaren Stellen:

1. Schlüsselanwender, die vom frühen Design ausgeschlossen werden.
2. Abteilungsleiter, die von Auswirkungen überrascht werden, über die niemand mit ihnen gesprochen hat.
3. Vage Kommunikation, die zu Zweifeln einlädt.
4. Gescheiterte frühere Projekte, die stilles Misstrauen hinterlassen haben.

Das sind strukturelle Probleme, nicht nur Kommunikationsprobleme. Ist der Lenkungsausschuss passiv, ist Reibung zu erwarten. Sagt der Projekt-Charter nichts zur Adoption, haben Sie bereits einen Hebel verloren.

1. 01MobilisierungEinfluss kartieren und die informelle Vorgeschichte sammeln
2. 02DesignAdoptions-KPIs vereinbaren, Power-User gestalten mit
3. 03TestFachanwender testen ihre eigenen Prozesse
4. 04TrainingRollenbasiert, mit echten Daten, zu Zeiten, an denen man teilnehmen kann
5. 05Go-live-GateAdoptionsschwellen, nicht nur funktionale Abnahme
6. 06Die ersten 90 TageLogins, Fehler, Tickets und Workarounds verfolgen

Workarounds werden erkannt, bevor sie zur Gewohnheit werden

Ein Change-Plan ist kein Kommunikationskalender. Das sind die sieben Bausteine und wer jeden verantworten sollte.

Baustein	Zweck	Verantwortlich
Rollen- und Einflusskartierung	Alle Betroffenen mit ihrem Einfluss, nicht nur mit ihrem Titel	Change-Lead
Change-Auswirkungsanalyse	Wie sich Rollen, Prozesse und Werkzeuge jeder Gruppe ändern	Prozessverantwortliche mit dem Change-Team
Kommunikationsplan	Zielgruppen, Botschaften, Kanäle und Zeitpunkte, mit Feedbackschleifen	Kommunikationsleiter
Training und Befähigung	Rollenbasiertes Curriculum, Praxis, Bereitschaftsprüfungen	Trainingsmanager
Einbindung der Führung	Führungskräfte sind abgestimmt, informiert und stehen sichtbar hinter der Veränderung	Executive Sponsor mit dem Change-Lead
Adoptions-KPIs	Verhaltenskennzahlen, im Design vereinbart und über den Go-live hinaus verfolgt	Change-Lead
Widerstandsmonitoring	Frühwarnzeichen, den Teams zugeordnet	Alle Workstream-Leads

Kommunikation heißt in den meisten Change-Plänen Newsletter, E-Mails und Town Halls. Das bewegt Menschen nicht.

Ich erinnere mich an einen Rollout, bei dem wir alles pünktlich kommuniziert haben, aber niemand erklären konnte, warum sich der Prozess ändert. Wir hatten Menge, aber keine Klarheit.

Nach Zielgruppe zuschneiden. Das obere Management will zuerst die Geschäftsauswirkung. Endanwender müssen es von ihrer eigenen Führungskraft hören, nicht von einem Programmleiter, den sie nie getroffen haben. Fachliche Leiter reagieren besser, wenn ihnen ein Teil der Botschaft gehört.

Feedback einbauen. Kommunikation nur in eine Richtung ist ein halber Plan. Ich habe mit einem Team gearbeitet, in dem wöchentliche Q&A-Calls mehr bewirkten als jede E-Mail. Verknüpfen Sie, was Sie hören, mit dem Risikoregister, damit Schwachstellen sichtbar werden, bevor sie öffentlich werden.

Den richtigen Zeitpunkt treffen. Zu früh erzeugt Verwirrung. Zu spät wirkt erzwungen. In einem Rollout glaubten Anwender, ihre Stellen würden ersetzt. Das hatte niemand gesagt. Aber das Schweigen füllte die Lücken. Sprechen Sie die Angst direkt und früh an, bevor es jemand anderes für Sie tut.

Verwenden Sie die Personenlandkarte des letzten Projekts nicht wieder. Einfluss verändert sich von Programm zu Programm. Bauen Sie die Karte von Grund auf neu und aktualisieren Sie sie jeden Monat.

Erfassen Sie für jede Person drei Dinge: wie stark die Veränderung sie betrifft, wo sie heute steht (unterstützend, neutral oder ablehnend) und wie viel Einfluss sie auf andere hat. Eine ablehnende Führungskraft der mittleren Ebene, der ein Team folgt, ist wichtiger als ein einzelner ablehnender Anwender.

Sammeln Sie auch die informelle Vorgeschichte. Gescheiterte frühere Projekte prägen das Verhalten auf eine Weise, die die Lessons-Learned-Dokumente nie festhalten. Ein paar Stunden Zuhören, woran sich Menschen erinnern, zeigen Ihnen, womit Sie es wirklich zu tun haben. Mein Leitfaden zum Stakeholder-Management behandelt die Kartierung ausführlicher.

Training ist ein Teil des Change Managements, nicht das Ganze. Der häufige Fehler ist Training, das zu spät kommt, im falschen Format und aufhört, bevor die Menschen sicher sind. Ein eintägiger Kurs zwei Wochen vor dem Go-live ist keine Bereitschaft.

Was funktioniert:

1. Rollenbasierte Inhalte. Bringen Sie jeder Gruppe bei, was sie für ihre eigene Arbeit braucht, keine Systemtour.
2. Üben mit echten Daten. Nutzen Sie die eigenen Daten und Transaktionen des Unternehmens, keine Demo-Szenarien.
3. Power-User als Trainer. Menschen lernen besser von Kollegen, denen sie vertrauen. Behandeln Sie Power-User als Mitautoren des Designs, nicht nur als Tester.
4. Training zur richtigen Zeit. Ein Finanzteam, mit dem ich gearbeitet habe, ließ Sitzungen ausfallen, weil sie zum falschen Zeitpunkt angesetzt waren. Die Verlegung löste das Problem.
5. Support nach dem Go-live. Die Zuversicht sinkt nach dem Go-live, nicht davor. Besetzen Sie das Hypercare mit Leuten, die echte Fragen schnell beantworten können.

Auch der Benutzerabnahmetest (UAT) gehört zur Adoption. Ich erinnere mich an eine UAT-Sitzung, in der ein kleiner Fehler in der Preislogik zu falschen Rechnungen geführt hätte. Ein Teamleiter entdeckte ihn. Sonst hatte ihn niemand bemerkt. Dieser eine Fund ersparte Wochen an Bereinigung, und er gelang, weil ein Fachanwender das System zum Teil als sein eigenes empfand.

Verankern Sie Adoptionsschwellen in Ihren Quality Gates. „Das System funktioniert“ ist eine funktionale Abnahme. „Die Anwender sind bereit, darin zu arbeiten“ ist eine andere, und die meisten Programme fragen nur nach der ersten. Mein Leitfaden zu SAP-Trainingsstrategien geht beim Trainingsplan tiefer.

Adoptions-KPIs, die vor dem Go-live vereinbart werden

Legen Sie diese im Design fest, damit es eine Basis zum Messen gibt:

1. Login-Raten je Anwendergruppe in den ersten 90 Tagen.
2. Fehlerraten in zentralen Transaktionen im Vergleich zur Basis des Altsystems.
3. Support-Tickets nach Menge und Kategorie.
4. Häufigkeit von Workarounds: Exporte in Tabellenkalkulationen, parallele Datensätze, manuelle Freigaben außerhalb des Systems.
5. Von Führungskräften gemeldete Zuversicht aus kurzen Pulse-Umfragen.

Das Zeitfenster ist schmal. Ich habe erlebt, wie Anwender innerhalb von Wochen stillschweigend zu Tabellenkalkulationen zurückkehrten, nicht weil das System kaputt war, sondern weil ihnen niemand durch die Veränderung half. Wenige Monate nach dem Go-live werden Workarounds zur Gewohnheit.

Digital-Adoption-Werkzeuge

SAP hat die Übernahme von WalkMe im September 2024 abgeschlossen, bei einem Eigenkapitalwert von rund 1,5 Milliarden US-Dollar. SAP erklärte damals, die KI-Fähigkeiten von WalkMe würden Joule über Workflows hinweg um kontextbezogene Hilfe ergänzen. Damit besitzt SAP jetzt zwei Adoptionswerkzeuge mit unterschiedlichen Stärken:

• SAP Enable Now eignet sich für strukturierte Trainingsinhalte: Einen Prozess einmal aufzeichnen und daraus Dokumentation, Simulationen und Testskripte erzeugen.
• WalkMe eignet sich für Hilfestellung innerhalb der Anwendung im Moment der Nutzung und kann SAP- und Nicht-SAP-Anwendungen übergreifen.

Bewerten Sie beide gemeinsam. Whatfix ist die wichtigste unabhängige Alternative, wenn Sie Adoptions-Tooling wollen, das nicht an SAP gebunden ist. Keines dieser Werkzeuge ersetzt eine Führungskraft, die erklärt, warum die Veränderung wichtig ist.

Auch bei guter Vorbereitung entsteht neue Reibung. Sie übermäßig zu kontrollieren, geht meist nach hinten los. Das Ziel ist, sie früh zu sehen.

Warnzeichen sind verpasste Workshops, Schweigen in Meetings, vages Feedback im Test und Key-User, die inoffizielle Workarounds bauen. Ordnen Sie jedes Signal dem Team zu, aus dem es kommt, damit Sie handeln können, bevor es den Lenkungsausschuss erreicht.

Eine Praxis, die funktioniert: Wechseln Sie die Change-Leads je Phase. Eine einzelne Person, die den Change über ein zweijähriges Programm verantwortet, brennt meist aus und verliert die Perspektive. Wenn sich die Art des Widerstands ändert, sollten sich auch die Menschen ändern, die damit umgehen.

Vor allem: Halten Sie das Change Management innerhalb der Programmstruktur. Verhaltensergebnisse gehören in den Projekt-Charter. Personenrisiken wie Überlastung der Teams und altes Misstrauen gehören neben die technischen Risiken ins Risikoregister. Wenn das Change Management in ein allgemeines PMO-Update berichtet, wird es zum Abhaken.

Was sollte ein Change-Management-Plan enthalten?

Sieben Teile: Einflusskartierung, eine Auswirkungsanalyse, einen Kommunikationsplan mit Feedbackschleifen, rollenbasiertes Training, Einbindung der Führung, Adoptions-KPIs und Widerstandsmonitoring. Jeder Teil braucht einen benannten Verantwortlichen, und der Plan sollte mit dem Charter, den Design-Workshops und den Quality Gates verknüpft sein.

Was sind die 5 C's des Change Managements?

Es gibt mehrere Versionen. Die, die ich nutze: Clarity (Menschen wissen, was sich für sie ändert), Consistency (Führungskräfte sagen dasselbe), Commitment (der Sponsor bleibt sichtbar), Communication (relevant, rechtzeitig und in beide Richtungen) und Capability (Training, Support und Zeit zur Anpassung). Fehlt eines davon, fallen die Menschen in alte Gewohnheiten zurück.

Was sind die 7 R's des Change Managements?

Sie stammen aus dem IT-Service-Management und dienen dazu, einen Änderungsantrag zu bewerten, bevor man handelt. Wer ihn gestellt hat, der Grund, der erwartete Ertrag, die Risiken, die benötigten Ressourcen, wer verantwortlich ist und die Beziehung zu anderen Änderungen. Sie gelten für die technische Änderungskontrolle, nicht für die menschliche Seite eines Programms.

Was ist der Unterschied zwischen organisatorischem und technischem Change Management?

Organisatorisches Change Management bereitet Menschen vor: Kommunikation, Training und Unterstützung durch eine Veränderung ihrer Arbeitsweise. Technisches Change Management steuert, welche Änderungen in das SAP-System gelangen, über Transporte, Freigaben, Tests und Rollback. ERP-Programme managen die technische Seite meist gut; Adoptionsprobleme entstehen auf der organisatorischen Seite. Mein Leitfaden zu Werkzeugen für das technische Change Management in SAP behandelt die technische Seite.

Sollte ich WalkMe oder SAP Enable Now verwenden?

Oft beides. SAP Enable Now ist stärker beim Erstellen strukturierter Trainingsinhalte vor dem Go-live. WalkMe ist stärker bei der Hilfe in der Anwendung nach dem Go-live, besonders wenn Anwender zwischen SAP und anderen Anwendungen wechseln. Da SAP beides besitzt, bewerten Sie sie gemeinsam. Whatfix ist die wichtigste unabhängige Alternative.

Wann sollte das Change Management in einem ERP-Projekt beginnen?

Bei der Mobilisierung, vor dem ersten Design-Workshop. Die wichtigsten frühen Maßnahmen sind die Einflusskartierung, das Sammeln der informellen Vorgeschichte früherer Projekte, die Aufnahme von Verhaltensergebnissen in den Charter und das Festlegen des Kommunikationsrhythmus des Sponsors.