Warum KI-Change-Management kein Zwei-Wochen-Projekt ist

KI fühlt sich beispiellos an. Neue Oberfläche, neue Fähigkeiten. Und in den Chefetagen liegt gerade dieser Ton in der Luft: Damit mussten wir uns noch nie beschäftigen. Zieht man der Technologie aber das Neue ab, bleibt eine Frage, die Unternehmen sich seit sehr langer Zeit stellen. Wie bringt man eine ganze Belegschaft dazu, ihre Arbeitsweise wirklich zu ändern?

Die Ökonomen Erik Brynjolfsson, Daniel Rock und Chad Syverson haben 2021 ein Paper dazu geschrieben [5]. Ihr Argument: Die versprochenen Produktivitätsgewinne einer neuen Universaltechnologie werden nicht sofort sichtbar. Nicht, weil die Technologie nicht funktioniert, sondern weil ihr Wert eine Reihe vonInvestitionen voraussetzt, die in keiner Bilanz stehen. Neue Geschäftsprozesse. Geschulte Mitarbeitende. Teams, die anders zusammenarbeiten. Eine Arbeitsstruktur, die man neu denkt. Nichts davon steht als Posten neben der Softwarelizenz, aber all das muss passieren, bevor sich der Einsatz auszahlt.

Lange bevor jemand ein Paper über Produktivitätskurven schrieb, sahen Arbeitspsychologen dasselbe Problem, nur beim einzelnen Mitarbeiter statt bei der ganzen Volkswirtschaft. 1988 veröffentlichten Timothy Baldwin und Kevin Ford die bis heute maßgebliche Übersichtsarbeit zum Transfer of Training [2]. Die Frage dahinter: Zeigt sich das, was jemand in einer Schulung lernt, später auch in seiner Arbeit? 1988, vor 38 Jahren, dasselbe Problem, weit und breit keine KI. Zwei Felder, zwei Jahrzehnte, zwei Forschergruppen, die zwei völlig verschiedene Dinge untersuchten, und am Ende dieselbe Diagnose: Der Moment, indem etwas Neues eingeführt wird, ob Maschine, Software oder Fähigkeit, ist nicht der Moment, in dem Wert entsteht. Der Wert kommt später. Das ist keine Geschichte über KI. Es ist eine Geschichte über jede Universaltechnologie, die ernst genug war, um zu verändern, wie Arbeit erledigt wird.

‍

Was es tatsächlich kostet, wenn IT-Projekte schieflaufen

Der vorherige Abschnitt erklärt, warum Unternehmen immer wieder überrascht werden. Die folgenden Zahlen verdeutlichen, wie teuer diese Überraschung meistens wird.

2012 analysierten McKinsey und das BT Centre for Major Programme Management der University of Oxford mehr als 5.400 große IT-Projekte, jedes mit einem Budget über 15 Millionen Dollar. Die Hälfte davonsprengte ihr Budget, lag im Schnitt 45 Prozent über den Kosten und 7 Prozent hinter dem Zeitplan, und lieferte dabei 56 Prozent weniger Geschäftswert als versprochen. Über die ganze Stichprobe gerechnet summierte sich die Überschreitung auf 66 Milliarden Dollar. Mehr als das Bruttoinlandsprodukt Luxemburgs [4].

Ein Jahr zuvor hatten der Oxford-Professor Bent Flyvbjerg und sein Kollege Alexander Budzier solchen Zahlen schon ein Gesicht gegeben. Sie verwiesen auf LeviStrauss, das 2003 auf ein einziges SAP-System migrieren wollte, Budget unter 5Millionen Dollar. Auf dem Papier fast Routine. Während der Umstellung konnte Levi's dann eine Woche lang keine Bestellungen ausliefern und musste 192,5 Millionen Dollar gegen den Gewinn abschreiben. Der CIO, David Bergen, verlor seinen Job [6].

Ein 5-Millionen-Projekt, 192 Millionen Verlust. Diese Lücke ist kein Rundungsfehler. Da hat ein Unternehmen die günstige Lösung gewählt und die Risiken ausgeblendet, die damit kamen.

Dieselbe Untersuchung ergab eine durchschnittliche Überschreitung von 27 Prozent. Aber der Durchschnitt versteckt die eigentliche Gefahr, so das Argument. Ungefähr eines von sechs Projekten wurde zu dem, was die Forscher einen Schwarzen Schwan nennen: Kosten im Schnitt 200 Prozent über Plan, Zeitpläne fast 70 Prozent darüber [6].

Auch das ist keine Geschichte über schlechte Technologie. Es ist eine über die immer gleiche falsche Annahme: dass die Installation des Systems der schwierige Teil sei, während der schwierige Teil alles war, was drumherum passierte.

‍

Big Data, Cloud, ERP: dieselbe Geschichte, anderes Jahrzehnt

Schau dir die Technologien an, die in den letzten 15 Jahren die Vorstandsagenden bestimmten, und das Muster wiederholt sich mit fast mechanischer Regelmäßigkeit. Enormes Versprechen, echter Wert für die, die es richtig machten, und dieselbe gutdokumentierte Lücke zwischen dem, was budgetiert war, und dem, was tatsächlich nötig wurde.

Fangen wir mit Big Data an. 2011 veröffentlichte das McKinsey Global Institute einen der meistzitierten Berichte des Jahrzehnts und sagte eine Welle der Transformation voraus. Ein Einzelhändler, der Big Data konsequent nutze, könne seine operative Marge um mehr als 60 Prozent steigern, schätzten sie [8].

Mehr als ein Jahrzehnt später fand NewVantage Partners in einer Umfrage unter Datenverantwortlichen von 2022, veröffentlicht in der Harvard Business Review, dass gerade einmal 26,5 Prozent der Organisationen wirklich eine datengetriebene Organisation aufgebaut hatten. Warum? 91,9 Prozent der Führungskräfte nannten kulturelle Hürden als größtes Hindernis. Nicht die Technologie, nicht das Budget, sondern die Arbeit, Menschen dazu zu bringen, sich zu ändern. Der Autor des Berichts brachte es schlicht auf den Punkt: kein Technologieproblem, ein Menschenproblem [3].

Die Cloud-Migration erzählt fast dieselbeGeschichte, ein Jahrzehnt später. McKinseys Umfrage von 2020/21 unter 443 Organisationen ergab: drei von vier hatten ihr Cloud-Budget überschritten, und 38 Prozent lagen hinter dem Zeitplan. Der größte einzelne Treiber der Mehrausgaben war kein technischer Posten. 45 Prozent der Befragten mit Budgetüberschreitung nannten das Change-Management. Die Software funktionierte wie beworben. Was das Budget sprengte, war die organisatorische Arbeit welche nicht eingrechnet war [1].

Vor beiden kam ERP. McKinseys Untersuchung zu Enterprise-Resource-Planning-Transformationen fand, dass drei von vier dieser Projekte weder im Zeitplan noch im Budget blieben und zwei von drei eine negative Rendite lieferten. Aus demselben Grund: weil sie den Rollout als technische Lieferung behandelten und nicht als Geschäftstransformation, die man aktiv steuern und messen muss [7].

Drei Technologien, drei Jahrzehnte, jedes Mal dieselbe Annahme: Ist die Software erst installiert, ist der schwierige Teil vorbei.

‍

Wenn Big Data, Cloud und ERP Jahre brauchten, warum sollte Copilot Wochen brauchen?

Keines der beschriebenen Projekte war ein Fehlschlag in dem Sinn, wie das Wort normalerweise benutzt wird. Die Unternehmen, die ERP ganzheitlich einführten, die sauber in die Cloud migrierten, die tatsächlich datengetrieben wurden, es gibt sie. Das eine von vier ERP-Projekten, das im Budget blieb. Die 15 Prozent der Cloud-Migrationen, die ihre Ziele trafen. Das Viertel der Organisationen, das NewVantage, welches heute als echt datengetrieben zählt. Das sind die Gewinner.

Und selbst die Gewinner brauchten Jahre und gaben enorme Summen dafür aus.

Bleibt die Frage, welche man sich stellen sollte. Wenn selbst die erfolgreichen Technologien mehrjährige Zeitpläne brauchten, eigene Change-Management-Budgets, Rückendeckung aus der Führung und die Art anhaltender Aufmerksamkeit, die McKinsey Value Assurance nannte, warum sollte ausgerechnet ein KI-Rollout anders laufen? Warum sollte eine Copilot-Lizenz genau das Muster umgehen, das ERP, Cloud und Big Data unabhängig voneinander über drei Jahrzehnte bestätigt haben?

Die ehrliche Antwort: Niemand argumentiert diesen Fall wirklich. Er wird einfach angenommen. Und die Annahme beruht auf einer Art Kategorienfehler. Weil KI selbst schnell ist, mühelos, ohne Code, verwechselt man leicht die Geschwindigkeit der Technologie mit der Geschwindigkeit der Transformation. Keines der Projekte oben war langsam, weil die Software langsam war. Sie waren langsam, weil Menschen Zeit brauchten, um ihre Arbeitsweise zu ändern, und Organisationen Zeit, um die Prozesse darumherum aufzubauen. Und keines von beidem skaliert mit GPU-Takt oder Arbeitsspeicher.

Und trotzdem steht in vielen Chefetagen genau diese Erwartung im Raum: zwei Wochen, ein Workshop, halbes ERP-Budget, fertig adoptiert bis Freitag.

‍

Wie es aussieht, wenn die Schulung vorbei ist

Zu wissen, dass sich das Muster wiederholt, macht es nicht leichter, es zu durchbrechen. Wenn ERP, Cloud und Big Data alle dieselbe Lücke zwischen Installieren und tatsächlichem Ändern zeigen, dann ist die eigentliche Frage, wie diese Lücke in der Praxis aussieht. Dann, wenn die Copilot-Lizenzen laufen und die erste Schulung vorbei ist.

‍

Ein paar KI-Kickoffs und Schulungen reichen nicht

Viele Unternehmen starten ihre Copilot-Einführung mit einem naheliegenden Muster: ein KI-Strategie-Workshop für das Management und die Fachabteilungen, eine Microsoft Copilot Schulung für Mitarbeitende, einen KI-Governance Workshop mit der IT und vielleicht noch für ein paarmotivierte AI Champions eine Agent Enablement Schulung. Das ist ein guter Anfang. Aber es ist noch keine Einführung, die im Alltag wirklich trägt.

Denn nach dem ersten Impuls beginnt erst der schwierigste Teil: Jemand mussAnwendungsfälle priorisieren und mit einem KI-Team umsetzten, Fragen aus denTeams aufnehmen, Vorlagen pflegen, Office Hours organisieren, Governance-Regeln übersetzen, Nutzung auswerten und immer wieder nachhaken, ob Copilot tatsächlich in wiederkehrenden Aufgaben eingesetzt wird. Genau dieser Teil entscheidet darüber, ob aus einer Schulung neue Arbeitsweisen entstehen oder nur ein kurzer Motivationsschub.

In der Praxis sehen wir dabei vor allem zwei Ausgangslagen. Manche Unternehmen haben bereits eine Person oder ein kleines Team, das wirklich fürKI verantwortlich ist. Diese Menschen haben Zeit, Budget, Rückhalt aus derFührung und den klaren Auftrag, Copilot, Governance und weitere KI-Projekte systematisch voranzutreiben. Dort kann ein Trainingskonzept auf eine vorhandeneStruktur aufsetzen.

Häufiger ist jedoch die zweite Variante: Eine Person bekommt das Thema KI zusätzlich zu ihrer eigentlichen Rolle übertragen. Die IT-Leitung, der Digitalisierungsverantwortliche oder jemand aus einem Fachbereich soll „nebenbei“ Copilot-Einführung, Schulungen, Use Cases, interne Kommunikation und Governance mit betreuen. Dafür gibt es aber weder ausreichend Zeit noch eineigenes Budget oder klare Entscheidungsrechte. Dann wird KI schnell zu einem weiteren Punkt auf einer ohnehin vollen Aufgabenliste.

Genau hier liegt der blinde Fleck vieler Copilot-Initiativen. Auf dem Papier klingt es einfach, ein paar AI Champions zu benennen oder nach der Schulung eine Prompt-Bibliothek aufzubauen. In der Realität braucht auch das jemanden, der diese Strukturen aktiv pflegt. Ohne diese Verantwortung bleiben viele Maßnahmen Stückwerk: Der KI-Strategie-Workshop erzeugt Aufmerksamkeit, die Schulung zeigt Möglichkeiten, aber danach fehlt die Kraft, daraus Gewohnheiten zu machen.

Das Fazit ist deshalb unbequem, aber wichtig: Mit ein paar Workshops und einer Copilot-Schulung ist es nicht getan. Wenn Unternehmen wollen, dass Copilot wirklich genutzt wird, sowie Anwendungsfälle über Copilot Studio oder eigenentwickelt umgesetzt werden, müssen sie das Thema eine Ebene höher verankern. KI-Adoption ist keine Nebenaufgabe, die zufällig bei der IT oder einer engagierten Einzelperson landet. Sie braucht Priorität, Zeit, Budget und ein klares Mandat aus der Führung. Erst dann werden Trainings, Office Hours, Vorlagenbibliotheken und AI Champions mehr als gut gemeinte Einzelmaßnahmen. Dann werden sie Teil eines Veränderungsprozesses, der im Arbeitsalltag tatsächlich haften bleibt.

‍

Die Ironie: Die Lösung ist bekannt, wird aber selten gekauft

Wenn wir mit Unternehmen über Copilot sprechen, sind sich erstaunlich viele Verantwortliche einig, dass nachhaltige KI-Einführung mehr braucht als ein paar Schulungen. Trotzdem fällt die Entscheidung am Ende oft anders aus. Statt eines langfristigen Einführungsprogramms werden ein KI-Impuls mit 200 oder 300 Teilnehmenden und eine einmalige Copilot-Schulung beauftragt.

Das ist verständlich. Eine einzelne Schulung lässt sich schnell organisieren, verursacht wenig Abstimmungsaufwand und erzeugt sofort Sichtbarkeit. Nach außen sieht das Thema KI damit zunächst adressiert aus. Der schwierigere Teil beginnt jedoch erst danach: Wer begleitet die Mitarbeitenden beim Transfer in den Alltag? Wer sammelt Fragen ein? Wer entwickelt neue Anwendungsfälle? Wer setzt Anwenungsfälle um? Wer misst, ob Copilot überhaupt genutzt wird? Und wer sorgt dafür, dass Governance-Regeln, Agenten und neue Funktionen nicht nach wenigen Wochen wieder in Vergessenheit geraten?

Genau deshalb verfolgen erfolgreiche Programme einen anderen Ansatz. Sie behandeln Copilot nicht als Schulungsprojekt, sondern als Veränderungsprozess. In unserer aithoria Roadmap wurden beispielsweise unterschiedliche Bausteine kombiniert: Governance-Workshops, EU-AI-Act-Schulungen, wiederholte Copilot-Trainings, Q&A-Sessions, Use-Case-Workshops mit Fachabteilungen, Agenten-Einführungen, Guidelines, Intranet-Kommunikation und regelmäßige Review-Termine.

Die unbequeme Wahrheit lautet deshalb: Die meisten Unternehmen scheitern nicht daran, dass sie die Lösung nicht kennen. Sie scheitern daran, dass sieden notwendigen Aufwand unterschätzen und das Thema Change Management außer Acht lassen. Wie wir am Anfang des Blogposts beschrieben haben gibt es dieses Problem auch schon lange vor KI bei IT Projekten, sollte also nichts neues sein. Mit ein paar KI-Impulsvorträgen und einer Copilot-Schulung ist es nichtgetan. Wer nachhaltige Nutzung erreichen möchte, muss bereit sein, Adoption über Monate hinweg aktiv zu begleiten. Genau dort entsteht der eigentliche Nutzen, und genau dort trennt sich die erfolgreiche Einführung von der nächsten Lizenz, die nach anfänglicher Begeisterung kaum noch genutzt wird.

‍

Fazit

Die unbequeme Wahrheit ist also die: Die meisten Unternehmen scheitern nicht, weil sie die Lösung nicht kennen. Sie scheitern, weil sie den Aufwand unterschätzen. Ein paar Kickoff-Vorträge und eine Copilot-Schulung reichen nicht. Wer nachhaltige Nutzung will, muss bereit sein, die Adoption über Monate aktiv zu begleiten. Genau dort entsteht der Wert, und genau dort trennt sich ein erfolgreicher Rollout von einer weiteren Lizenz, die kaum noch jemand anfasst, sobald die erste Begeisterung weg ist. Wie das im Mittelstand konkret aussieht, zeigen wir am Beispiel der KI-Kompetenzen im Mittelstand.

Nichts davon ist einzigartig für KI. Dieselbe Lücke zwischen dem Installieren einer Technologie und dem tatsächlichen Ändern der Arbeitsweise gab es bei ERP-Rollouts, Cloud-Migrationen und Big-Data-Initiativen. Und sie wurde schon Jahrzehnte vorher untersucht. Was die Unternehmen unterscheidet, die es schaffen, ist nicht, die Lösung zu kennen. Es ist die Bereitschaft, sie so lange zu finanzieren und zu besetzen, wie es tatsächlich dauert.

Wenn du gerade überlegst, wie ihr aus einer Copilot-Lizenz echteNutzung macht, lass uns 20 Minuten sprechen. Wir schauen gemeinsam, wo bei euch der größte Hebel liegt, ganz ohne Verkaufsgespräch.