Lesedauer 5 Minuten Von Silvia Hildebrandt
Lewin, Kotter und ADKAR gehören zu den bekanntesten Modellen im Change Management. Sie helfen, Veränderung zu ordnen. Sie geben Sprache, Struktur und Orientierung. Genau deshalb werden sie auch bei IT-Projekten gern verwendet. Trotzdem reichen sie für IT-Change allein nicht aus. Der Grund ist einfach: IT-Change ist nicht nur eine Verhaltensänderung. IT-Change verändert Arbeitssysteme. Er verändert Daten, Rollen, Rechte, Routinen, Transparenz, Entscheidungsgeschwindigkeit und Macht. Wenn ein Unternehmen nur Kommunikation, Schulung und Sponsorship plant, aber diese Systemfolgen nicht steuert, bleibt der Change unvollständig.
Bekannte Grundlagen für Change Management, greifen bei IT-Change allein zu kurz. Der Beitrag zeigt, warum digitale Veränderungen zusätzlich Arbeitsprozesse, Daten, Rollen, Governance, Psychologie und kontinuierliches Lernen berücksichtigen müssen.
Klassischer Change geht oft von einem Zielbild aus. Die Organisation steht an Punkt A, sie soll zu Punkt B, und die Menschen sollen diesen Weg mitgehen. Bei IT ist Punkt B aber selten stabil. Systeme werden nach dem Go-live angepasst. Daten werden bereinigt. Rollenrechte werden korrigiert. Reports werden neu gebaut. KI-Funktionen kommen hinzu. Schnittstellen verändern Folgeprozesse. Nutzerinnen und Nutzer entwickeln neue Erwartungen. IT-Change ist deshalb nicht nur ein Weg von alt nach neu. Er ist eine dauerhafte Wechselwirkung zwischen Technik, Arbeit und Organisation.
Lewins Denkmodell mit Auftauen, Verändern und Stabilisieren hat bis heute einen Wert. Es erinnert daran, dass Gewohnheiten nicht einfach verschwinden. Menschen und Gruppen haben Kräfte, die den alten Zustand halten. Wer ein neues System einführt, muss also erst verstehen, welche Routinen, Vorteile und Schutzmechanismen im alten System stecken. Gerade bei gewachsenen Excel-Prozessen, informellen Freigaben und persönlichen Absprachen ist das wichtig. Menschen halten nicht immer am Alten fest, weil sie altmodisch sind. Sie halten daran fest, weil es ihnen Orientierung, Tempo oder Sicherheit gibt.
Die Grenze von Lewin liegt bei moderner IT aber in der Idee der Stabilisierung. Natürlich brauchen Menschen nach Veränderung eine neue Routine. Aber digitale Systeme frieren selten wieder ein. Es gibt Updates, neue Datenanforderungen, neue Security-Regeln, Automatisierungen und KI-Erweiterungen. Ein Unternehmen kann also nicht so tun, als sei nach dem Go-live wieder Ruhe. Besser ist die Frage: Wie schaffen wir Stabilität in einem System, das sich weiter verändert? Das ist eine andere Aufgabe. Sie braucht kontinuierliches Lernen, Feedbackschleifen, Produktverantwortung und klare Regeln für Anpassungen.
Kotters Acht-Schritte-Modell bringt andere Stärken ein. Es betont Dringlichkeit, eine starke Führungskoalition, eine klare Vision, Kommunikation, breite Beteiligung, kurzfristige Erfolge und kulturelle Verankerung. Das ist auch für IT-Change wertvoll. Viele digitale Projekte scheitern, weil sie wie reine Technikprogramme behandelt werden. Dann fehlt eine gemeinsame Geschichte. Es ist unklar, warum die Veränderung wichtig ist. Führungskräfte sprechen unterschiedlich darüber. Die Organisation sieht nur Aufwand, aber keinen Sinn. Kotter hilft, diese Lücken zu schließen.
Trotzdem bleibt Kotter für IT-Change zu grob, wenn er allein eingesetzt wird. Eine Vision löst keine schlechte Datenqualität. Dringlichkeit behebt keine unlogische Benutzeroberfläche. Eine Führungskoalition ersetzt keine klaren Rechte im System. Kurzfristige Erfolge helfen wenig, wenn der Alltag nach dem Go-live langsamer wird. IT-Change braucht neben Mobilisierung auch konkrete Arbeitsgestaltung. Er braucht Prozessklarheit, Datenverantwortung, User Experience, Support, Hypercare, Governance und Messung der realen Nutzung. Diese Dinge liegen nicht automatisch im Kotter-Modell.
ADKAR ist besonders praktisch, weil es den einzelnen Menschen betrachtet. Awareness, Desire, Knowledge, Ability und Reinforcement beschreiben, was eine Person braucht, damit Veränderung gelingt. Sie muss verstehen, warum etwas passiert. Sie braucht einen Grund, mitzugehen. Sie braucht Wissen. Sie muss die neue Arbeitsweise tatsächlich können. Und sie braucht Verstärkung, damit sie nicht in alte Muster zurückfällt. Für Trainingsplanung, Führungsgespräche und Adoption ist dieses Modell sehr hilfreich.
Die Grenze von ADKAR liegt darin, dass es stark auf individuelle Veränderung schaut. Ein Mensch kann alle fünf Schritte durchlaufen und trotzdem an schlechter IT scheitern. Er kann den Nutzen verstehen und trotzdem mit einer Maske arbeiten, die zu viele Klicks verlangt. Er kann die Veränderung wollen und trotzdem Daten nicht finden. Er kann geschult sein und trotzdem an fehlenden Rechten scheitern. Er kann motiviert sein und trotzdem vom Team zur alten Lösung zurückgezogen werden. Bei IT-Change sitzt das Problem oft nicht nur im Menschen, sondern im Zusammenspiel von Mensch, Prozess, System und Organisation.
Das Bridges Transition Model ergänzt eine wichtige Perspektive. Es unterscheidet zwischen äußerer Veränderung und innerem Übergang. Ein neues Tool kann an einem Montag live gehen. Der innere Übergang dauert länger. Menschen müssen etwas loslassen, sie gehen durch eine unsichere Zwischenphase, und sie finden erst später eine neue Identität im neuen Arbeitsmodus. Diese Sicht ist besonders wichtig, wenn IT Rollen verändert. Wer früher als Expertin für einen manuellen Prozess galt, kann sich durch Automatisierung plötzlich entwertet fühlen.
Doch auch Bridges reicht allein nicht aus. Das Modell erklärt gut, warum Menschen Verlust, Unsicherheit und Neuorientierung erleben. Es sagt aber wenig darüber, wie ein Datenmodell verantwortet wird, wie Systemrechte gestaltet werden, wie KI-Empfehlungen geprüft werden oder wie ein Supportmodell nach dem Go-live funktioniert. IT-Change braucht emotionale Begleitung, aber er braucht auch Betriebsarchitektur. Ohne diese Architektur wird die neutrale Zone nicht zur Lernphase, sondern zur Dauerbaustelle.
Warum ist IT-Change so schwierig und teuer? Erstens skalieren Fehler. Ein unklarer Prozess bleibt in einem Workshop klein. Ein unklarer Prozess in einem ERP-System wird auf viele Menschen, Standorte, Datenfelder und Reports verteilt. Zweitens sind Abhängigkeiten unsichtbar. Eine kleine Änderung in einem Formular kann Reporting, Compliance, Einkauf oder Kundenservice betreffen. Drittens werden Erwartungen oft zu früh verkauft. Ein System soll schneller, einfacher und transparenter machen. Wenn der Alltag nach dem Go-live mehr Aufwand bringt, entsteht Enttäuschung. Viertens bleibt der Nutzen oft nur dann erhalten, wenn Menschen Daten konsequent pflegen. Genau das passiert nicht automatisch.
Dazu kommt, dass IT-Change Macht verändert. Daten machen Arbeit sichtbarer. Dashboards zeigen Abweichungen. Workflows legen fest, wer wann etwas tun darf. KI kann Empfehlungen geben, die fachliche Erfahrung herausfordern. Dadurch entstehen emotionale Reaktionen, die klassische Change-Kommunikation häufig zu allgemein behandelt. Es geht nicht nur um Angst vor Veränderung. Es geht um Kompetenzscham, Kontrollgefühl, Statusverlust, Datenangst und moralischen Stress. Menschen fragen sich, ob sie noch gebraucht werden, ob Zahlen fair sind und ob sie für Systemfehler verantwortlich gemacht werden.
Klassische Modelle fangen einen Teil dieser Emotionen auf. Lewin hilft beim Verstehen alter Gewohnheiten. Kotter hilft bei Richtung und Energie. ADKAR hilft bei individueller Befähigung. Bridges hilft bei Verlust und innerem Übergang. Was oft fehlt, ist die digitale Spezifik. Ein Mitarbeitender kann nicht nur traurig sein, weil etwas Altes endet. Er kann auch unsicher sein, weil das System jeden Fehler speichert. Eine Führungskraft kann nicht nur Widerstand erleben. Sie kann auch ihre alte Rolle verlieren, weil Daten nun direkt verfügbar sind. Ein Team kann nicht nur Schulung brauchen. Es kann auch eine neue Regel brauchen, wann KI genutzt und wann sie hinterfragt wird.
Deshalb braucht IT-Change eine eigene Change-Architektur. Diese Architektur sollte vier Ebenen verbinden. Die erste Ebene ist die Sinn- und Nutzenarchitektur. Hier klärt das Unternehmen, welches Problem wirklich gelöst wird, wer profitiert und wo neue Belastung entsteht. Ein Nutzenversprechen darf nicht nur für den Vorstand stimmen. Es muss für jede betroffene Rolle konkret werden. Eine Buchhaltung braucht andere Antworten als ein Vertriebsteam. Ein Standortleiter braucht andere Antworten als eine Sachbearbeiterin.
Die zweite Ebene ist die Arbeits- und Prozessarchitektur. Hier wird sichtbar, wie sich Aufgaben verändern. Welche Schritte fallen weg? Welche kommen hinzu? Welche Entscheidungen werden automatisiert? Welche Ausnahmen bleiben menschlich? Welche alten Workarounds verschwinden, und welche neuen könnten entstehen? Diese Ebene zwingt das Projekt, den Alltag ernst zu nehmen. Ein Prozess ist nicht fertig, wenn er in einem Diagramm steht. Er ist erst belastbar, wenn Menschen ihn unter Zeitdruck, bei Fehlern und in Sonderfällen nutzen können.
Die dritte Ebene ist die psychologische Adoptionsarchitektur. Hier geht es um Verstehen, Wollen, Können, Vertrauen und Belastung. ADKAR kann hier ein guter Kern sein, aber es sollte erweitert werden. Zusätzlich braucht es einen Check für kognitive Last, Technostress, Rollenangst, Datenmisstrauen und KI-Verantwortung. Die Frage lautet nicht nur: Haben wir geschult? Die bessere Frage lautet: Können Menschen das neue Verhalten im echten Arbeitskontext ausführen, ohne ihre Arbeitsfähigkeit oder ihr Vertrauen zu verlieren?
Die vierte Ebene ist die Daten-, Governance- und Vertrauensarchitektur. Gerade bei digitalem Change entscheidet sie über Akzeptanz. Wer sieht welche Daten? Wer korrigiert Fehler? Wer darf eine KI-Empfehlung überstimmen? Welche Kennzahlen dürfen für Führung genutzt werden, und welche nur für Prozessverbesserung? Wie wird verhindert, dass Transparenz zur Überwachung wird? Ohne diese Fragen wird Digitalisierung politisch. Teams verteidigen sich gegen Daten, statt mit Daten zu lernen.
Diese vier Ebenen machen klassische Modelle nicht wertlos. Sie setzen sie an die richtige Stelle. Lewin, Kotter, ADKAR und Bridges bleiben nützlich, weil sie wichtige Ausschnitte beleuchten. Sie sind aber keine vollständige Landkarte für IT-Change. Eine IT-Landkarte muss zeigen, wie Technik auf Arbeit wirkt, wie Arbeit auf Verhalten wirkt und wie Verhalten wiederum Daten, Sicherheit und Nutzen beeinflusst. Genau diese Rückkopplung macht digitalen Wandel anspruchsvoll.
Deshalb sollte der Start eines IT-Changes nicht mit der Frage beginnen, welches Modell angewendet wird. Er sollte mit der Frage beginnen, welche Art von Veränderung vorliegt. Geht es um ein neues Werkzeug, um einen neuen Prozess, um neue Datenmacht, um KI-Unterstützung oder um eine neue Form von Führung? Je nach Antwort braucht die Organisation andere Schwerpunkte. Ein reines Tool braucht starke Nutzungsunterstützung. Ein datengetriebener Prozess braucht Vertrauensregeln. Eine KI-Einführung braucht Prüfkompetenz und Verantwortungsgrenzen.
Ein Beispiel zeigt den Unterschied. Wenn ein Unternehmen ein neues CRM einführt, kann ADKAR sauber abgearbeitet sein. Die Mitarbeitenden wissen, warum das CRM kommt. Sie haben Schulungen erhalten. Sie können die wichtigsten Funktionen bedienen. Trotzdem kann der IT-Change scheitern, wenn Besuchsberichte zu lang sind, wenn Kundendaten nicht eindeutig sind, wenn Führung nur Aktivitätszahlen kontrolliert oder wenn der Vertrieb den Nutzen nicht im Verkaufsgespräch sieht. Das Problem liegt dann nicht in fehlender Motivation allein. Es liegt in der Verbindung aus Prozessdesign, Datenmodell, Führungslogik und Arbeitspsychologie.
Genauso kann Kotter erfolgreich mobilisieren und trotzdem digitale Wirkung verfehlen. Eine starke Vision kann Menschen bewegen, aber sie ersetzt keine Entscheidung über Zielkonflikte. Soll ein neues System möglichst sicher sein oder möglichst schnell nutzbar? Soll ein Dashboard Transparenz schaffen oder Leistung kontrollieren? Soll KI Vorschläge machen oder Entscheidungen vorbereiten? Solche Fragen müssen konkret beantwortet werden. Allgemeine Change-Energie reicht nicht, weil digitale Systeme Zielkonflikte technisch festschreiben. Was im Workshop offen bleibt, wird später im System zur harten Regel.
Darum gehört zur IT-Change-Architektur auch eine Konfliktarchitektur. Sie legt fest, wie Zielkonflikte entschieden werden. Wenn Fachbereich und IT unterschiedliche Prioritäten haben, braucht es klare Entscheidungswege. Wenn Datenschutz, Nutzerfreundlichkeit und Controlling unterschiedliche Anforderungen stellen, braucht es eine sichtbare Abwägung. Wenn eine KI-Anwendung Produktivität verspricht, aber Vertrauen gefährdet, muss die Organisation die Grenze benennen. Ohne solche Entscheidungen entsteht Scheinkonsens. Alle stimmen zu, aber jede Gruppe erwartet etwas anderes. Nach dem Go-live brechen diese Erwartungen auf.
Ein weiterer Baustein ist die Lernarchitektur nach dem Go-live. Viele Projekte planen Schulung vor dem Start und Support nach dem Start. Das ist zu wenig. Menschen lernen digitale Arbeit erst im echten Kontext. Sie lernen, wenn ein Kunde anruft, wenn eine Ausnahme entsteht, wenn eine Zahl falsch ist oder wenn ein Workflow blockiert. Deshalb braucht IT-Change Lernschleifen in den ersten Wochen und Monaten. Dazu gehören offene Sprechstunden, kurze Praxisformate, Feedbackkanal, Super-User-Netzwerk und schnelle Anpassungsentscheidungen. Wichtig ist, dass diese Lernschleifen nicht als Reparatur von Unwissen gelten, sondern als normaler Teil digitaler Einführung.
Auch die Erfolgsmessung muss sich verändern. Ein IT-Change ist nicht erfolgreich, weil das System live ist. Er ist erfolgreich, wenn Arbeit besser funktioniert. Deshalb sollte die Organisation messen, ob die betroffenen Rollen Kernaufgaben schneller, sicherer oder besser erledigen können. Sie sollte messen, ob Schattenprozesse sinken, ob Datenqualität steigt, ob Supportanfragen abnehmen und ob Führung die neuen Informationen verantwortungsvoll nutzt. Diese Messung sollte nicht als Kontrolle gegen Menschen wirken. Sie sollte zeigen, ob das System und die Einführung gut genug gestaltet wurden.
Für die Praxis bedeutet das: Ein IT-Projekt braucht neben Projektplan und Kommunikationsplan auch einen psychologischen Wirkplan. Darin steht, welche Rollen sich verändern, welche Belastungen entstehen, welche Emotionen wahrscheinlich sind, welche Datenfragen Vertrauen gefährden und welche Lernschleifen nach dem Go-live geplant sind. Dieser Plan ist kein weiches Extra. Er ist Risikomanagement. Er verhindert, dass ein technisch gutes System im Alltag schlecht wird.
IT-Change kostet viel Geld, weil er selten nur Software betrifft. Er betrifft Entscheidungen, Identität, Verantwortung und Zusammenarbeit. Genau deshalb reichen allgemeine Change-Modelle nicht aus. Sie können den Rahmen liefern, aber sie müssen durch IT-Psychologie, soziotechnisches Denken und konkrete Change-Architektur ergänzt werden. Gute digitale Veränderung entsteht, wenn Menschen nicht nur informiert, sondern beteiligt, befähigt und geschützt werden. Dann wird IT nicht nur eingeführt. Sie wird wirksam.
Geschrieben von Silvia Hildebrandt @Hilstayn
