Zum Hauptinhalt springen
    SystemSelect · Beratung für Software-Auswahl

    30 Min · kostenlos

    Beratung anfragen

    Anfragen →

    Change Management bei Software-Projekten: So gelingt Akzeptanz

    70 % der IT-Projekte verfehlen ihre Ziele – meistens nicht wegen der Technik. Change Management entscheidet, ob ein neues System genutzt oder umgangen wird.

    Von Tim Sternatz · SystemSelect

    Warum Change Management kein Soft-Skill-Thema ist

    Neue Software verändert Arbeitsabläufe, Verantwortlichkeiten und manchmal ganze Rollen. Das betrifft Menschen – und Menschen brauchen Orientierung, Beteiligung und Zeit. Change Management ist kein Workshop am Projektende, sondern ein durchgehender Prozess.

    Dieser Ratgeber zeigt Ihnen die vier Phasen, die in der Praxis funktionieren – und die typischen Fehler, die Sie vermeiden können.

    Die vier Phasen in der Praxis

    1. Awareness: Warum überhaupt verändern?

    Die meisten Widerstände entstehen nicht gegen das neue System, sondern gegen das Gefühl, nicht gehört zu werden. Ohne klares Warum bleibt das Projekt ein IT-Thema – und die Akzeptanz bleibt aus.

    ✓ Das funktioniert
    • Problem-Statement gemeinsam erarbeiten (nicht nur Management-Folien)
    • Betroffene Teams früh einbinden – idealerweise als Mitgestalter, nicht als Empfänger
    • Konkreten Nutzen je Rolle zeigen: Was ändert sich für die Beteiligten?
    ! Das geht schief
    • Das Tool ist modern als einziges Argument
    • Informationsveranstaltung = Change Management
    • Fachbereiche erst nach Go-Live einbeziehen

    2. Beteiligung: Key User als echte Partner

    Key User sind das Rückgrat: Sie kennen die Prozesse, tragen das Wissen ins Team und validieren, ob die Lösung wirklich funktioniert. Aber: Key User brauchen Zeit, Mandat und Rückhalt.

    ✓ Das funktioniert
    • Key User mit explizitem Zeitbudget freistellen (20–40 % der Arbeitszeit)
    • Klare Rolle: Prozesswissen einbringen, Testfälle definieren, Schulungen mittragen
    • Regelmäßiges Feedback-Format (z. B. alle 2 Wochen) mit dem Projektteam
    ! Das geht schief
    • Key User nebenbei mitlaufen lassen
    • Nur eine Person pro Abteilung (Single Point of Failure)
    • Verantwortung ohne Entscheidungskompetenz

    3. Kommunikation: Transparenz baut Vertrauen auf

    Stille ist der größte Feind von Veränderung. Wenn niemand weiß, was passiert, füllen Gerüchte die Lücke. Regelmäßige, ehrliche Kommunikation ist kein Nice-to-have.

    ✓ Das funktioniert
    • Fester Kommunikationsrhythmus (z. B. monatliches Update, kurze Standup-Formate)
    • Erfolge sichtbar machen (Quick Wins, erreichte Meilensteine)
    • Probleme offen ansprechen – und zeigen, wie sie gelöst werden
    ! Das geht schief
    • Nur bei Problemen kommunizieren
    • Hochglanz-Newsletter ohne ehrliche Einblicke
    • Management redet, Fachbereich hört zu (Einbahnstraße)

    4. Qualifizierung: Schulung ist kein Event, sondern ein Prozess

    Ein 2-Tage-Training reicht nicht. Nachhaltige Befähigung bedeutet: praxisnahe Formate, wiederholbare Inhalte und Ansprechpartner im Alltag.

    ✓ Das funktioniert
    • Role-based Training: Lager lernt anders als Vertrieb
    • Praxis-Workshops mit echten Daten und echten Szenarien (nicht Testumgebung mit Dummy-Daten)
    • Train-the-Trainer: Key User als interne Multiplikatoren aufbauen
    • Nachbereitungsformate: FAQ-Kanal, kurze Video-Tutorials, Sprechstunde
    ! Das geht schief
    • Generische Schulung für alle (Module A–Z durchklicken)
    • Schulung 2 Wochen vor Go-Live und danach nichts mehr
    • Keine Dokumentation für Vertretungen und neue Mitarbeitende

    Drei Fehler, die fast jedes Projekt macht

    Fehler 1: Change ist nur ein Folien-Thema

    Change Management besteht aus einem Kapitel in der Projektpräsentation, aber niemand hat Budget, Zeit oder Ownership dafür.

    Lösung: Change braucht einen Owner, ein Budget und messbare Ziele (z. B. Adoption-Rate, Support-Tickets, Prozesszeiten nach Go-Live).

    Fehler 2: Widerstand wird als Problem behandelt

    Kritische Stimmen werden ignoriert oder marginalisiert statt gehört. Das führt zu verdecktem Widerstand: Leute nutzen das System, aber arbeiten drumherum.

    Lösung: Widerstand ist ein Signal, keine Störung. Hören Sie zu, nehmen Sie es ernst, adaptieren Sie wo sinnvoll. Oft steckt valides Prozesswissen dahinter.

    Fehler 3: Go-Live = Projektende

    Das Projektteam löst sich auf, Key User gehen zurück in ihre Rollen, Support wird an den Dienstleister abgegeben. Die Adoption-Kurve bricht ein.

    Lösung: Planen Sie 3–6 Monate Hypercare nach Go-Live ein: dedizierter Support, Feedback-Loops, Nachjustierung von Prozessen und Schulungen.

    Change-Readiness Checkliste

    • Stakeholder-Map mit Change-Rollen (Sponsor, Change Agent, Key User)
    • Kommunikationsplan mit Rhythmus und Kanälen
    • Key-User-Freistellung formal vereinbart
    • Schulungskonzept je Rolle (nicht generisch)
    • Feedback-Mechanismus eingerichtet (nicht nur Beschwerdekanal)
    • Hypercare-Phase nach Go-Live geplant (3–6 Monate)
    • Erfolgsmessung definiert (Adoption, Prozesszeiten, Support-Tickets)

    Modellvergleich: Kotter 8-Step vs. ADKAR

    Die zwei meistverwendeten Change-Modelle decken unterschiedliche Ebenen ab: Kotter ist organisations-orientiert, ADKAR personen-orientiert. In der Software-Einführung profitieren Sie meist von der Kombination.

    Kotter · 8 Schritte

    Organisations-Level

    1. Dringlichkeit erzeugen
    2. Führungskoalition aufbauen
    3. Vision & Strategie entwickeln
    4. Vision kommunizieren
    5. Hindernisse beseitigen
    6. Kurzfristige Erfolge planen
    7. Veränderungen verstärken
    8. Neues in der Kultur verankern

    Stärke: top-down, klare Phasenlogik. Schwäche: berücksichtigt Individuen wenig.

    ADKAR · 5 Bausteine

    Individuum-Level

    • Awareness · Bewusstsein für die Notwendigkeit
    • Desire · persönlicher Wille zur Änderung
    • Knowledge · Wissen über das "Wie"
    • Ability · Fähigkeit zur Umsetzung
    • Reinforcement · Verstärkung des neuen Verhaltens

    Stärke: passt zu individuellen Coaching-Gesprächen. Schwäche: skaliert nicht von alleine.

    Praxis-Tipp: Kotter als Gesamt-Programm-Struktur. ADKAR als Diagnose-Werkzeug für einzelne Stakeholder-Gruppen (z.B. „Vertrieb hat Desire, aber kein Knowledge" → Schulungsplan).

    Beispiel-Kommunikationsplan: Woche -8 bis +12 vor Go-Live

    Vorlage für CRM- oder ERP-Einführung im Mittelstand. Anpassen an Eskalations- und Schulungs-Touchpoints.

    WocheFormatZielgruppeKernbotschaft
    -8All-Hands (live)GesamtbelegschaftWarum wir wechseln (Awareness)
    -6Team-WorkshopAbteilungs-LeiterWer macht was, Verantwortlichkeiten
    -4Sprechstunde / Office HourPower-User-KandidatenQ&A, Ängste adressieren
    -3Schulungs-TagPower-UserHands-on: die wichtigsten Workflows
    -1FAQ + Cheat-SheetAlle End-UserWas ist neu, was bleibt gleich
    0Go-Live-AnmailAlle End-UserHeute starten, Support-Hotline ist da
    +1Tägliches Stand-upWar-RoomIssues, Workarounds, Eskalationen
    +4Adoption-ReviewSteeringKPIs nach 30 Tagen
    +12Lessons-LearnedProject BoardWas lief gut, was machen wir nächstes Mal anders

    Häufige Fragen

    Weiterlesen — 3 Artikel