SH

Sascha Hess

xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

Strategische Wissens-Roadmap 2026

Change Management bei ERP-Projekten

Menschen mitnehmen — der entscheidende Unterschied zwischen Erfolg und Scheitern

1

Veränderungspsychologie

Warum Menschen sich widersetzen — und was wirklich hilft

2

Stakeholder-Playbuch

Sponsor, Key User, Bremser — jeden richtig führen

3

Kommunikationsplan

Was, wann, an wen — lückenlos und wirkungsvoll

4

Schulungskonzept

Rollen-basiert, praxisnah, nachhaltig wirksam

5

30-Tage-CM-Kickoff

Change Management von Tag 1 an im Projekt verankern

WAS SIE IN DIESEM KIT ERWARTEN DÜRFEN

■  Veränderungspsychologie — Warum Menschen sich widersetzen und welche Interventionen wirklich wirken.

■  Stakeholder-Playbuch — Für jeden Typ den richtigen Ansatz: Sponsor, Key User, Skeptiker, Bremser.

■  Kommunikationsplan — Vollständige Vorlage mit Botschaften, Kanälen, Timing und Absendern.

■  Schulungskonzept — Rollen-basiertes Schulungssystem das Wissen dauerhaft verankert.

■  30-Tage-CM-Kickoff — Change Management ab Tag 1 strukturiert im Projekt verankern.

ZIEL DIESES KITS

Nach dem Lesen und Umsetzen dieses Kits haben Sie ein vollständiges Change-Management-Konzept für Ihr ERP-Projekt, konkrete Werkzeuge für jede Projektphase und messbare Kriterien für eine erfolgreiche Adoption — damit das System nicht nur läuft, sondern genutzt wird.

EMOTIONALE REISE DURCH DEN WANDEL:

PHASE 1 — SCHOCK / VERNEINUNG (Beginn Projekt)

  Reaktion: "Das kann nicht sein" / "Wir brauchen das nicht"

  Gefühl:   Überraschung, Unglaube, temporäre Paralyse

  Handlung: Informieren, Verständnis zeigen, nicht drängen

PHASE 2 — ÄRGER / WIDERSTAND (Anforderungsphase)

  Reaktion: "Das macht alles komplizierter" / "Wer hat das entschieden?"

  Gefühl:   Frustration, Angst, Kontrollverlust

  Handlung: Zuhören, einbinden, Gründe erklären — nicht verteidigen

PHASE 3 — VERHANDELN / AUSPROBIEREN (Testphase)

  Reaktion: "Vielleicht wenn wir X anders machen..." / Erste Neugier

  Gefühl:   Ambivalenz, vorsichtige Offenheit

  Handlung: Mitmachen ermöglichen, Erfolge zeigen, Feedback einfordern

PHASE 4 — DEPRESSION / TAL (kurz vor Go-Live)

  Reaktion: "Es ist so viel auf einmal" / Überforderung

  Gefühl:   Erschöpfung, Unsicherheit, Tief der Energie

  Handlung: Unterstützung intensivieren, Hypercare-Team präsent

PHASE 5 — AKZEPTANZ / INTEGRATION (Post Go-Live)

  Reaktion: "Ich komme damit zurecht" / "Das ist eigentlich okay"

  Gefühl:   Erleichterung, neue Routine, Sicherheit

  Handlung: Feiern, verstärken, Best Practices teilen

ACHTUNG: Nicht alle Menschen durchlaufen alle Phasen in gleicher

          Geschwindigkeit. Manche springen zurück. Manche überspringen Phasen.

          Change Management begleitet — es schubst nicht.

ADKAR = die 5 Bausteine individueller Veränderung:

A — AWARENESS (Bewusstsein)

  "Ich verstehe warum die Veränderung nötig ist."

  Maßnahme: Townhall, Management-Kommunikation, Business Case erklären

  Messung:  Survey "Wissen Sie warum wir das neue ERP einführen?"

D — DESIRE (Bereitschaft)

  "Ich will die Veränderung unterstützen."

  Maßnahme: Persönlichen Nutzen zeigen, Ängste adressieren, einbinden

  Messung:  Survey "Unterstützen Sie das ERP-Projekt aktiv?"

K — KNOWLEDGE (Wissen)

  "Ich weiß wie ich im neuen System arbeite."

  Maßnahme: Schulungen, Handbücher, Quick Reference Cards, E-Learning

  Messung:  Schulungstest-Ergebnisse, Zertifizierungsquote

A — ABILITY (Fähigkeit)

  "Ich kann das neue System effektiv nutzen."

  Maßnahme: Praxisübungen, Coaching, Testumgebung, Key User Support

  Messung:  Transaktionsrate, Fehlerquote, Support-Tickets

R — REINFORCEMENT (Verstärkung)

  "Ich nutze das neue System dauerhaft und richtig."

  Maßnahme: Anerkennung, Erfolge feiern, Rückfall erkennen und ansprechen

  Messung:  Adoption Rate nach 30/60/90 Tagen, Workaround-Monitoring

PULSE SURVEY — KURZBEFRAGUNG ALLE 4 WOCHEN (5 Fragen, anonym):

1. "Ich verstehe warum wir das neue ERP einführen."

   (1=Stimme gar nicht zu bis 5=Stimme voll zu)

2. "Ich bin über den aktuellen Projektstand gut informiert."

   (1-5)

3. "Ich fühle mich auf die Arbeit mit dem neuen System vorbereitet."

   (1-5)

4. "Meine Führungskraft unterstützt das ERP-Projekt aktiv."

   (1-5)

5. "Was besorgt Sie aktuell am meisten beim ERP-Projekt?"

   (Freitext)

AUSWERTUNG:

  Fragen 1-4 < 3,5 Ø → Sofortmaßnahmen einleiten

  Freitexte täglich lesen — sie sind das Frühwarnsystem

STAKEHOLDER-MATRIX:

                    EINFLUSS NIEDRIG     EINFLUSS HOCH

                  ┌─────────────────┬──────────────────┐

  INTERESSE       │  BEOBACHTEN      │  AKTIV MANAGEN   │

  HOCH            │  → Informieren   │  → Einbinden     │

                  │  → Zufrieden     │  → Partnerschaft │

                  │  halten          │  → Regelmäßiger  │

                  │                  │  Kontakt         │

                  ├─────────────────┼──────────────────┤

  INTERESSE       │  MINIMAL         │  ZUFRIEDEN       │

  NIEDRIG         │  ÜBERWACHEN      │  HALTEN          │

                  │  → Standard-Info │  → Konsultieren  │

                  │  → Keine extra   │  → Erwartungen   │

                  │  Energie         │  managen         │

                  └─────────────────┴──────────────────┘

TYPISCHE STAKEHOLDER ERP-PROJEKT:

  Aktiv managen:  GF (Sponsor), Bereichsleiter, Betriebsrat

  Einbinden:      Key User, IT-Abteilung, Buchhaltungsleiter

  Informieren:    Alle Mitarbeiter, Lieferanten (bei EDI), Kunden (bei Portal)

  Überwachen:     Externe Berater, Wirtschaftsprüfer

TYP 1 — DER SPONSOR (Geschäftsführung)

  Rolle:      Auftraggeber, Budget-Geber, Eskalations-Instanz

  Risiko:     Verlorenes Interesse, operative Eingriffe, wechselnde Prioritäten

  Was er braucht:

    ✓ Klaren Status in 5 Minuten (nicht 50 Folien)

    ✓ Rechtzeitige Eskalationen — keine Überraschungen

    ✓ Erfolge zum Kommunizieren nach außen

  Ihre Aufgabe:

    ✓ Monatliches 1:1 — Management Summary auf 1 Seite

    ✓ Frühzeitig eskalieren wenn politische Eingriffe nötig

    ✓ Kommunikationsaufgaben für den Sponsor vorbereiten

TYP 2 — DER BEGEISTERTE KEY USER

  Rolle:      Multiplikator, Tester, erster Ansprechpartner nach Go-Live

  Risiko:     Überlastung, Isolation im eigenen Team, Erwartungsenttäuschung

  Was er braucht:

    ✓ Echte Teilhabe — nicht nur Informationsempfänger

    ✓ Rückhalt von Führungskraft und Projektteam

    ✓ Anerkennung für Mehraufwand

  Ihre Aufgabe:

    ✓ Wöchentliches Key-User-Meeting

    ✓ Eskalationskanal wenn Vorgesetzter blockiert

    ✓ Nach Go-Live: Erfolge des Key Users sichtbar machen

TYP 3 — DER KONSTRUKTIVE SKEPTIKER

  Rolle:      Qualitätssicherung durch kritische Fragen — wertvoll!

  Risiko:     Wird als Bremser abgestempelt und verliert Engagement

  Was er braucht:

    ✓ Gehört werden — echte Antworten, kein Abspeisen

    ✓ Sachliche Diskussion auf Augenhöhe

    ✓ Gelegenheit recht zu haben wenn er Fehler aufdeckt

  Ihre Aufgabe:

    ✓ Zum Tester oder Review-Teilnehmer machen

    ✓ Kritik öffentlich ernst nehmen — nicht wegmoderieren

    ✓ Wenn er sich irrt: erklären, nicht gewinnen wollen

TYP 4 — DER PASSIVE BREMSER (gefährlichster Typ)

  Rolle:      Sagt öffentlich ja, handelt privat bremsend

  Risiko:     Unentdeckt bis es zu spät ist — Schatten-IT, Gerüchte, Boykott

  Warnsignale:

    → Meetings mit Ausreden fernbleiben

    → Technische Probleme die nur bei ihm auftreten

    → "Informelle" Gespräche in denen er Kollegen verunsichert

  Ihre Aufgabe:

    ✓ Direktes 1:1-Gespräch — Wahrnehmung ansprechen

    ✓ Führungskraft einbeziehen — nicht allein eskalieren

    ✓ Klare Erwartung formulieren: "Was brauchen Sie von uns?"

TYP 5 — DER OFFENE WIDERSTÄNDLER

  Rolle:      Sagt klar nein — öffentlich und laut

  Risiko:     Ansteckend auf unsichere Kollegen

  Warnsignale: Öffentliche Kritik, Meeting-Störungen, Verweigerung

  Ihre Aufgabe:

    ✓ Nie öffentlich konfrontieren — immer 1:1

    ✓ Ursache verstehen: Angst? Schlechte Erfahrung? Information?

    ✓ Wenn Ursache nicht behebbar: Führungskraft muss Position beziehen

    ✓ Letztes Mittel: Konsequenzen benennen — ruhig, klar, respektvoll

BEWERTUNGSSKALA:

  Einfluss / Interesse: 1 (niedrig) bis 5 (sehr hoch)

  Aktueller Stand: Grün (unterstützend) / Gelb (neutral) / Rot (bremsend)

  Wöchentlich aktualisieren — Farbveränderungen sofort adressieren

7 REGELN FÜR WIRKSAME PROJEKTKOMMUNI KATION:

1. FRÜHER ALS NÖTIG: Kommunizieren bevor Gerüchte entstehen.

   Lieber zu viel zu früh als zu wenig zu spät.

2. EHRLICH ALS PERFEKT: "Wir wissen es noch nicht" ist besser

   als falsche Sicherheit die später korrigiert werden muss.

3. PERSÖNLICH VOR DIGITAL: Wichtige Botschaften persönlich —

   erst danach schriftlich als Dokumentation.

4. FÜHRUNGSKRAFT ALS ABSENDER: Botschaften zur Veränderung

   kommen von der direkten Führungskraft — nicht von der IT.

5. WIEDERHOLUNG STATT EINMALIGKEIT: Dieselbe Botschaft braucht

   durchschnittlich 7 Kontakte bis sie verankert ist.

6. KANAL ZUM INHALT: Komplexe Botschaften im Meeting —

   nicht per E-Mail. Einfache Infos per Mail — nicht im Meeting.

7. FEEDBACK EINFORDERN: Jede Kommunikation schafft einen Kanal

   für Rückmeldungen. Ohne Feedback ist es Monolog.

Projekt-Start

Woche 1

Warum ERP, Was ändert sich, Was nicht

Alle MA

Townhall + Intranet

GF

Q&A-Box

Anforderungen

Woche 2-8

Wer ist Key User, wie kann ich mitmachen

Betroffene

Abteilungsmeeting

Bereichsleiter

Key User

Konzept fertig

Woche 12

Was das System konkret anders macht

Alle MA

Newsletter + Video

Projektleiter

Intranet-Forum

Test-Phase

Woche 16

Wann kann ich testen, wie melde ich Fehler

Key User + Tester

Mail + Workshop

IT-Projektleiter

Ticketsystem

Schulungsstart

T-8 Wochen

Wann ist meine Schulung, was lerne ich

Alle Anwender

Einladung + Intranet

HR + Projektleiter

Rückmeldebogen

T-2 Wochen

T-14 Tage

Konkrete Änderungen meiner täglichen Arbeit

Alle Anwender

Handout + Meeting

Direkte FK

Key User

Go-Live

T-0

System ist live, Helpdesk, Ansprechpartner

Alle

Mail + Aushang + Teams

GF + IT

Ticketsystem

Woche 1-4

Post Go-Live

Fortschritt, bekannte Probleme, Lösungen

Alle Anwender

Wöchentlicher Newsletter

Projektleiter

Feedback-Formular

BOTSCHAFTSARCHITEKTUR — WARUM / WAS / WIE:

WARUM (für alle, immer zuerst):

  "Unser aktuelles System kann nicht mehr mithalten. Wir verlieren

   täglich Zeit durch manuelle Prozesse und schlechte Daten.

   Mit dem neuen ERP arbeiten wir effizienter — und Sie haben

   mehr Zeit für die Arbeit die wirklich zählt."

WAS (spezifisch für jede Rolle):

  Buchhaltung: "Eingangsrechnungen werden automatisch gebucht —

                kein Abtippen mehr. DSO-Übersicht in Echtzeit."

  Einkauf:     "Bestellvorschläge kommen automatisch. Genehmigungen

                per Klick statt per E-Mail-Kette."

  Lager:       "Lagerbestand in Echtzeit. Keine Inventur-Überraschungen."

WIE (konkrete nächste Schritte):

  "Ihre Schulung ist am [Datum]. Ihr Key User ist [Name].

   Fragen beantwortet das Ticketsystem unter [Link].

   Helpdesk: [Nummer] — erreichbar Mo-Fr 7-18 Uhr."

WEN SUCHEN WIR? — IDEALPROFIL KEY USER:

FACHLICHE KRITERIEN:

  ✓ Tiefes Prozesswissen in der eigenen Abteilung

  ✓ Vertraut mit dem aktuellen System

  ✓ Fähigkeit, Anforderungen zu artikulieren

  ✓ Bereitschaft, sich intensiv mit dem neuen System zu befassen

PERSÖNLICHE KRITERIEN:

  ✓ Anerkannt von Kollegen — kein Außenseiter

  ✓ Kommunikativ — kann erklären und zuhören

  ✓ Offen für Veränderung — kein "Das war schon immer so"

  ✓ Belastbar — Doppelbelastung ist unvermeidbar

WEN VERMEIDEN:

  ✗ Der Mitarbeiter der am lautesten "Ich will" sagt

     (oft falsche Motivation — Projektstatus statt Prozessinteresse)

  ✗ Der einzige Experte für einen Kernprozess

     (Tagesgeschäft leidet wenn er im Projekt ist)

  ✗ Der offene Widerständler

     (Key User brauchen Grundbereitschaft — Skeptiker ja, Bremser nein)

ANZAHL:

  Kleine ERP-Einführung (< 50 User):   1 Key User pro Hauptmodul

  Mittlere Einführung (50-200 User):   1-2 Key User pro Abteilung

  Große Einführung (> 200 User):       2-3 Key User pro Abteilung

                                        + Super User als zweite Ebene

Anforderungsanalyse

Prozesse dokumentieren, Anforderungen einbringen, Workshops leiten

30-40 %

Konzept & Design

Lösungsvorschläge bewerten, Testfälle definieren

20-30 %

Realisierung

Systemkonfiguration prüfen, Testdaten vorbereiten

20-30 %

Test-Phase

UAT durchführen, Fehler dokumentieren, Abnahme

50-80 %

Schulung

Schulungen für Kollegen durchführen, Handbücher erstellen

60-80 %

Go-Live & Hypercare

Erster Ansprechpartner vor Ort, Tickets priorisieren

80-100 %

Post Go-Live

Support, Nachschulungen, Optimierungsvorschläge

20-30 %

PFLICHTEN DES PROJEKTTEAMS GEGENÜBER KEY USERN:

WÖCHENTLICH:

  ✓ Key-User-Meeting: Status, offene Fragen, Hindernisse

  ✓ Direkte Erreichbarkeit des Projektleiters

  ✓ Schnelle Antworten auf technische Fragen (< 24h)

PROJEKTLAUFZEIT:

  ✓ Vollständige System-Schulung vor allen anderen Anwendern

  ✓ Zugang zur Testumgebung von Beginn an

  ✓ Eskalationspfad wenn Vorgesetzter die Freistellung blockiert

  ✓ Anerkennung: Zertifikat, Erwähnung in Kommunikation, Dankeschön

NACH GO-LIVE:

  ✓ Key User sind nicht allein — Projektteam mindestens 4 Wochen erreichbar

  ✓ Eskalation zu Berater wenn Key User nicht weiterkommt: < 2h

  ✓ Transition in normalen Support dokumentiert und kommuniziert

HÄUFIGSTER FEHLER:

  Key User werden als kostengünstige Schulungsressource betrachtet —

  nicht als strategische Partner. Wer Key User nicht ernst nimmt,

  verliert sie in der kritischsten Phase.

SUPER USER = ERFAHRENE KEY USER ALS ZWEITE EBENE:

  Key User → Endanwender (erste Hilfe, Basisfragen)

  Super User → Key User (komplexe Fälle, Prozessfragen)

  IT/Berater → Super User (Systemfragen, Fehler, Konfiguration)

  Super User haben:

  ✓ Vollständige Systemschulung (alle Module)

  ✓ Zugang zu Systemdokumentation und Konfigurationsprotokollen

  ✓ Regelmäßigen Austausch mit IT und externem Berater

  ✓ Entscheidungskompetenz für kleinere Konfigurationsanpassungen

WAS WIRKLICH HILFT — 5 DESIGNPRINZIPIEN:

1. ROLLEN-BASIERT statt themenbasiert

   Falsch: "Schulung Modul Einkauf — 4 Stunden"

   Richtig: "Schulung Einkaufssachbearbeiter — nur meine Prozesse"

   → Keine Zeit mit Funktionen verschwenden die niemand braucht

2. PRAXISNAH statt Demo

   Falsch: Trainer zeigt, Teilnehmer schauen zu

   Richtig: Jeder Teilnehmer hat eigene Testumgebung mit echten Daten

   → Lernen durch Handeln — nicht durch Zuschauen

3. ZEITLICH VERTEILT statt einmalig

   Falsch: Alles in einem Tag 6 Wochen vor Go-Live

   Richtig: Konzept-Schulung (früh) + System-Schulung (2 Wochen vor Go-Live)

            + Refresher nach 4 Wochen

   → Wissen verblasst nach 1 Woche ohne Anwendung

4. KURZ UND FOKUSSIERT statt umfassend

   Falsch: 8 Stunden Vollschulng am Stück

   Richtig: 2-3 Stunden maximale Lerneinheit + Pause + Übung

   → Konzentrationskurve bei Erwachsenen: nach 90 Min. deutlich abfallend

5. MIT REFERENZ-MATERIAL statt nur Schulung

   Jeder Anwender braucht nach der Schulung:

   ✓ Quick Reference Card (1 Seite, laminiert am Arbeitsplatz)

   ✓ Prozess-Checkliste für die 3 häufigsten eigenen Aufgaben

   ✓ Link zum Video-Tutorial der wichtigsten Funktion

   ✓ Name und Foto des Key Users als Ansprechpartner

Alle Mitarbeiter

System-Überblick, Navigation

Webinar

60 Min.

T-8 Wochen

IT-Projektleiter

Einkaufssachbearbeiter

Bestellprozess, Wareneingang, Lieferantenanlage

Präsenz + Übung

3h

T-3 Wochen

Key User Einkauf

Buchhaltung

OP-Management, Zahlungsläufe, Monatsabschluss

Präsenz + Übung

4h

T-3 Wochen

Key User FiBu

Lager

Warenbuchungen, Inventur, Umlagerungen

Präsenz + Übung

2h

T-2 Wochen

Key User Lager

Vertriebsinnendiensst

Angebote, Aufträge, Lieferscheine

Präsenz + Übung

3h

T-2 Wochen

Key User Vertrieb

Führungskräfte

Reporting, Genehmigungen, Cockpit

Online

90 Min.

T-2 Wochen

Controller + IT

Key User

Gesamtsystem, Konfiguration, Support-Tools

Intensiv

2 Tage

T-8 Wochen

Externer Berater

-- Schulungsnachweis-Tracking (SQL-Beispiel)

CREATE TABLE dbo.Schulungs_Nachweis (

    NachweisID     INT IDENTITY PRIMARY KEY,

    Mitarbeiter    NVARCHAR(100),

    Abteilung      NVARCHAR(50),

    Schulungsmodul NVARCHAR(100),

    Schulungsdatum DATE,

    Dauer_Stunden  DECIMAL(4,1),

    TestErgebnis   INT,           -- Prozent (0-100), NULL wenn kein Test

    Bestanden      BIT,           -- 1 wenn >= 80 %

    Trainer        NVARCHAR(100),

    Zertifikat_Nr  NVARCHAR(50)

);

-- Schulungsquote je Abteilung

SELECT

    Abteilung,

    COUNT(DISTINCT Mitarbeiter) AS Geschulte,

    SUM(CASE WHEN Bestanden = 1 THEN 1 ELSE 0 END) AS Bestanden,

    ROUND(100.0 * SUM(CASE WHEN Bestanden=1 THEN 1 ELSE 0 END) /

          NULLIF(COUNT(DISTINCT Mitarbeiter),0),1) AS Quote_Pct

FROM dbo.Schulungs_Nachweis

WHERE Schulungsmodul LIKE '%ERP%'

GROUP BY Abteilung

ORDER BY Quote_Pct ASC;

MUSTER 1: "Das haben wir immer so gemacht."

FALSCHE ANTWORT: "Das war aber nicht gut."

                 → Angriff auf Identität → Verhärtung

RICHTIGE ANTWORT:

  "Genau deshalb fragen wir Sie — Sie kennen den Prozess am besten.

   Wie würden Sie ihn gerne verbessern? Was nervt Sie daran täglich?"

  → Expertise anerkennen → Mitgestaltung öffnen

MUSTER 2: "Das funktioniert bei uns nicht."

FALSCHE ANTWORT: "Andere machen das auch so."

                 → Abwertung → Trotz

RICHTIGE ANTWORT:

  "Was genau meinen Sie — welcher Teil passt nicht?

   Lassen Sie uns das gemeinsam durchspielen."

  → Konkretisieren → sachliche Diskussion → ggf. echte Anpassung

MUSTER 3: "Ich habe keine Zeit für das Projekt."

FALSCHE ANTWORT: "Das muss aber sein."

                 → Machtdemonstration → Widerstand verlagert sich

RICHTIGE ANTWORT:

  An Mitarbeiter: "Was bräuchten Sie damit es geht?"

  An Führungskraft: "Dieser Mitarbeiter ist kritisch für das Projekt.

                    Was brauchen Sie damit er 20 % freigestellt werden kann?"

  → Problem lösen statt Druck erhöhen

MUSTER 4: "Das letzte IT-Projekt war auch ein Desaster."

FALSCHE ANTWORT: "Das war damals anders."

                 → Defensive → Glaubwürdigkeitsverlust

RICHTIGE ANTWORT:

  "Was war damals das größte Problem? Was müssen wir dieses Mal

   unbedingt anders machen damit Sie Vertrauen haben?"

  → Vergangenheit anerkenn → Unterschiede konkret benennen → Vertrauen aufbauen

STRUKTUR EINES WIDERSTANDSGESPRÄCHS (immer 1:1, nie öffentlich):

SCHRITT 1 — ÖFFNEN (5 Min.)

  "Ich möchte verstehen wie Sie das ERP-Projekt erleben.

   Ich bin hier um zuzuhören — nicht um zu überzeugen."

SCHRITT 2 — ZUHÖREN (10-15 Min.)

  Erzählen lassen. Nicht unterbrechen. Notizen machen.

  Nachfragen: "Was meinen Sie damit genau?"

              "Welche Erfahrung hat Sie das gelehrt?"

SCHRITT 3 — ZUSAMMENFASSEN (3 Min.)

  "Wenn ich Sie richtig verstehe, ist Ihre Hauptsorge...

   Habe ich das korrekt?"

  → Bestätigung einholen bevor Sie reagieren

SCHRITT 4 — ANTWORTEN (10 Min.)

  Auf jede konkrete Sorge eingehen.

  Was kann geändert werden → zusagen.

  Was nicht geändert werden kann → erklären warum — ehrlich.

  Was unklar ist → nachfragen statt antworten.

SCHRITT 5 — VEREINBAREN (5 Min.)

  "Was brauchen Sie damit Sie das Projekt aktiv unterstützen?"

  Konkrete nächste Schritte vereinbaren und dokumentieren.

  Folgetermin festlegen.

ESKALATIONSREGEL IM CHANGE MANAGEMENT:

STUFE 1 — PROJEKTLEITER-GESPRÄCH:

  Trigger: Stakeholder zeigt anhaltend rotes Signal

  Vorgehen: 1:1-Widerstandsgespräch (Kapitel 7.2)

  Zeitrahmen: Innerhalb 48 Stunden nach Identifikation

STUFE 2 — FÜHRUNGSKRAFT EINBEZIEHEN:

  Trigger: Stufe-1-Gespräch ohne Wirkung nach 2 Wochen

  Vorgehen: Gemeinsames Gespräch Projektleiter + direkte FK

  Zeitrahmen: 2 Wochen nach Stufe 1

STUFE 3 — SPONSOR ESKALIEREN:

  Trigger: Führungskraft kann oder will nicht handeln

  Vorgehen: Sponsor informieren, Handlungsbedarf benennen

  Zeitrahmen: 1 Woche nach Stufe 2

STUFE 4 — KONSEQUENZEN BENENNEN:

  Trigger: Aktive Sabotage oder Verweigerung kritischer Aufgaben

  Vorgehen: Sponsor + HR + direkte FK + Betroffener

  Inhalt: Klare Erwartung + Konsequenz bei Nichterfüllung

  WICHTIG: Arbeitsrechtliche Beratung vor diesem Schritt!

AUFGABE 1 — COALITION BUILDING (Verbündete gewinnen)

  Die Führungskraft kommuniziert aktiv und positiv über das Projekt —

  auch wenn sie selbst noch Bedenken hat.

  Satz den sie sagen muss: "Ich stehe dahinter und erwarte,

  dass mein Team mitzieht."

AUFGABE 2 — RESSOURCEN FREISTELLEN

  Key User bekommen tatsächlich die zugesicherte Zeit.

  Tagesgeschäft wird umorganisiert — nicht einfach addiert.

  Konkret: Stellvertreterregelung dokumentieren und kommunizieren.

AUFGABE 3 — SICHTBARE NUTZUNG

  Die Führungskraft nutzt das neue System selbst — öffentlich.

  Sie ruft Berichte aus dem ERP ab — in Meetings.

  Sie genehmigt digital — statt auf Papier.

  Signal: "Wenn der Chef es nutzt, ist es ernst gemeint."

AUFGABE 4 — KONSEQUENZEN SETZEN

  Workarounds (Excel statt ERP) werden nicht toleriert — ruhig, klar, konsequent.

  Satz: "Ich erwarte, dass wir alle mit dem neuen System arbeiten.

         Was braucht ihr dafür?"

AUFGABE 5 — FEEDBACK EINHOLEN UND WEITERGEBEN

  Führungskraft ist Frühwarnsystem — nicht Informationsfilter.

  Sie gibt Probleme ihrer Mitarbeiter ungefiltert weiter.

  Sie gibt Antworten des Projektteams ungefiltert zurück.

AUFGABE 6 — ERFOLGE FEIERN

  Erster Auftrag erfolgreich im neuen System: öffentlich loben.

  Key User hat Kollegen geholfen: erwähnen im Teammeeting.

  Abgeschlossener Meilenstein: Team-Frühstück.

  Klein. Ehrlich. Konsistent.

FÜHRUNGSKRÄFTE-BRIEFING — AGENDA (90 Minuten):

BLOCK 1 — WARUM DAS PROJEKT (20 Min.)

  Business Case, strategische Notwendigkeit

  Was passiert wenn wir es nicht tun?

  Ihre Rolle als Führungskraft — explizit

BLOCK 2 — WAS ÄNDERT SICH FÜR IHR TEAM (30 Min.)

  Konkrete Prozessveränderungen je Abteilung

  Zeitplan, Meilensteine, Go-Live-Datum

  Was bleibt gleich — was ändert sich fundamental

BLOCK 3 — WAS SIE TUN MÜSSEN (20 Min.)

  Ressourcen freistellen: Namen, Zeiten, Ersatz

  Kommunikation: Wann, wie, welche Botschaft

  Umgang mit Widerstand: Wann eskalieren, wie ansprechen

BLOCK 4 — FRAGEN UND BEDENKEN (20 Min.)

  Alle Bedenken auf den Tisch — kein Abspeisen

  Ehrliche Antworten — kein Schönreden

  Offene Punkte: schriftlich nachliefern

ERGEBNIS:

  Jede Führungskraft verlässt das Briefing mit:

  ✓ Klarem Verständnis ihrer Rolle

  ✓ Konkreten Erwartungen schriftlich

  ✓ Namen der Key User und deren Freistellung bestätigt

  ✓ Terminen für Mitarbeiter-Kommunikation in ihrem Kalender

🟢 / 🟡 / 🔴

🟢 / 🟡 / 🔴

PHASE: BEWUSSTSEIN (Projekt-Start bis T-6 Monate)

  KPI 1: Awareness-Score (Pulse Survey Frage 1)  Ziel: > 3,5 von 5

  KPI 2: Townhall-Teilnahmequote               Ziel: > 80 %

  KPI 3: Intranet-Seitenaufrufe Projekt-Seite   Ziel: > 50 % MA

PHASE: VORBEREITUNG (T-6 bis T-2 Monate)

  KPI 1: Key-User-Freistellungsquote           Ziel: 100 % wie vereinbart

  KPI 2: UAT-Teilnahmequote                    Ziel: > 90 % der Key User

  KPI 3: Stakeholder-Zufriedenheit (gelb/rot)  Ziel: < 20 % gelb, 0 % rot

PHASE: SCHULUNG (T-8 bis T-2 Wochen)

  KPI 1: Schulungsabdeckung                    Ziel: > 95 % aller Anwender

  KPI 2: Test-Bestehensquote                   Ziel: > 85 % ≥ 80 %

  KPI 3: Schulungszufriedenheit (1-5)          Ziel: ≥ 3,8 Ø

PHASE: GO-LIVE & HYPERCARE (T+0 bis T+30)

  KPI 1: Helpdesk-Ticket-Rate                  Norm: sinkt nach Woche 1

  KPI 2: Workaround-Meldungen                  Ziel: 0 bekannte Workarounds

  KPI 3: System-Transaktionsrate               Ziel: ≥ 90 % geplante Nutzung

PHASE: ADOPTION (T+30 bis T+90)

  KPI 1: Aktive User Quote                     Ziel: > 95 %

  KPI 2: Datenqualität ERP (DQ-Score)          Ziel: > 90 %

  KPI 3: Prozess-Compliance-Rate               Ziel: > 95 % Prozesse im ERP

-- Adoption-Tracking: Wer nutzt das System tatsächlich?

SELECT

    u.Abteilung,

    COUNT(DISTINCT u.UserName) AS Gesamt_User,

    COUNT(DISTINCT al.UserName) AS Aktive_User_30Tage,

    ROUND(100.0 * COUNT(DISTINCT al.UserName) /

          NULLIF(COUNT(DISTINCT u.UserName), 0), 1) AS Adoption_Rate_Pct,

    COUNT(al.TransaktionsID) AS Transaktionen_30Tage,

    ROUND(COUNT(al.TransaktionsID) * 1.0 /

          NULLIF(COUNT(DISTINCT al.UserName), 0), 0) AS Avg_Transakt_Pro_User

FROM dbo.ERP_User u

LEFT JOIN dbo.ERP_Aktivitaetslog al

    ON u.UserName = al.UserName

    AND al.Datum >= DATEADD(DAY, -30, CAST(GETDATE() AS DATE))

WHERE u.Aktiv = 1

GROUP BY u.Abteilung

ORDER BY Adoption_Rate_Pct ASC;

CHANGE-MANAGEMENT AMPEL — WÖCHENTLICHER BERICHT:

  KOMMUNIKATION:    🟢 Alle geplanten Kommunikationen durchgeführt

  STAKEHOLDER:      🟡 2 Stakeholder mit Gelb — Gespräche laufen

  SCHULUNG:         🟢 87 % Schulungsquote — Ziel 95 % in 2 Wochen

  KEY USER:         🔴 Key User Buchhaltung: Freistellung nicht gewährt

                       → Eskalation an Sponsor geplant

  PULSE SURVEY:     🟡 Awareness 3,6 / Vorbereitung 2,9 → Nachschulung nötig

  RISIKEN DIESE WOCHE:

  → Buchhaltungs-Key-User blockiert: Eskalation bis Fr 15:00

  → Vorbereitung-Score unter 3,0: Zusatz-Workshop T-3 Wochen

  NÄCHSTE WOCHE:

  → Sponsor-Gespräch Buchhaltung-Freistellung

  → Zusatz-Workshop Buchhaltung: Montag 9:00-12:00

  → Pulse Survey Welle 3 starten

VOR DEM START

Change Management braucht einen eigenen Line-Item im Projektbudget — typisch 10-15 % des Gesamtprojektbudgets. Einen dedizierten CM-Verantwortlichen benennen (kann der Projektleiter sein bei kleinen Projekten, sollte eine eigene Rolle sein ab 100 Usern). GF-Commitment schriftlich einholen bevor der Sprint beginnt.

ERGEBNIS NACH 30 TAGEN

Nach 30 Tagen ist Change Management strukturell im Projekt verankert: Stakeholder-Register gepflegt, Key-User-Netzwerk aufgebaut, Kommunikationsplan aktiv, erste Pulse-Survey-Ergebnisse vorliegend, Schulungsplanung finalisiert. Der Unterschied zum Projektstart: Sie wissen jetzt wo die Menschen stehen — und haben Strukturen um sie durch den Wandel zu führen.

ERP-Einführungsberatung inkl. Change Management

Vollständige Projektbegleitung von der Anforderungsanalyse bis zum Go-Live — mit integriertem Change-Management-Konzept, Key-User-Aufbau und Adoptionsmessung.

Change-Management-Konzept ERP

Eigenständige Entwicklung eines CM-Konzepts für laufende ERP-Projekte — Stakeholder-Analyse, Kommunikationsplan, Schulungskonzept, Adoption-Tracking.

Digitalisierungs-Strategieberatung

Reifegradanalyse und Digitalstrategie für den Mittelstand — mit integriertem Change-Ansatz für die Umsetzung.

SQL Server DB Health Check

Professioneller Audit Ihres SQL Servers — Managementreport, Risikobewertung und Maßnahmenplan. Scope: 3-5 Tage.

Interim IT-Management

Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, Projektführung, Change Leadership.