Der Pilot lief gut. Das ist meistens der Anfang des Problems.
Ein kleines Team, ein klarer Anwendungsfall, Leute, die Lust darauf hatten. Nach acht Wochen steht ein Ergebnis, das sich vorzeigen lässt. Dann folgt der Rollout in die Breite – und dort passiert plötzlich nichts mehr. Die Lizenzen sind gekauft, die Schulung ist gelaufen, die Nutzungszahlen fallen nach drei Wochen zurück auf das Niveau von vorher.
Der übliche Reflex ist, das Modell zu wechseln. Meiner Erfahrung nach liegt es fast nie am Modell.
Ein Pilot testet die Technologie. Er testet nie die Organisation.
Das ist der Konstruktionsfehler. Im Pilotteam arbeiten Freiwillige unter Bedingungen, die es sonst nirgends gibt: hohe Motivation, direkter Draht zum Projekt, Fehler ohne Folgen, Zeit zum Ausprobieren. Nichts davon überlebt den Rollout. Was im Regelbetrieb entscheidet, sind vier Fragen, die im Pilot niemand stellen musste.
Welche Arbeitsaufgabe genau? „Wir setzen KI im Kundenservice ein“ ist kein Anwendungsfall, sondern eine Absichtserklärung. Ein Anwendungsfall benennt einen Arbeitsschritt, den heute ein Mensch macht, und sagt, was danach anders ist.
Wer verantwortet das Ergebnis? Sobald ein System Entscheidungen vorbereitet, verschiebt sich Verantwortung, ohne dass jemand sie neu verteilt hätte. Genau das haben wir für die vernetzte Fabrik untersucht: Wir haben eine Matrix von Services mit den jeweils zuständigen Unternehmensfunktionen erarbeitet und dabei gesehen, dass die IT eine zentrale Rolle übernimmt, produktionsnahe Services aber weiter von der Operational Technology abhängen – und dass an der Schnittstelle neue digitale OT-Funktionen entstehen, die es vorher schlicht nicht gab. Der Rahmen war die Smart Factory. Das Muster ist überall dasselbe: Zuständigkeiten klären, bevor das System läuft, nicht danach.(Quelle)
Was macht die Führungskraft vor? Wer selbst nicht mit dem Werkzeug arbeitet, kann seinem Team nicht glaubhaft erklären, warum es das tun sollte.
Welche Regeln gelten? Was darf hinein, was nicht, wer prüft das Ergebnis, was passiert bei einem Fehler. Ohne Antwort entscheidet das jeder für sich – und die Vorsichtigen entscheiden sich gegen die Nutzung.
Adoption ist Führungsarbeit, keine Schulung
In einer systematischen Übersicht zu Eigenschaften von Führungskräften in digitalen Umgebungen haben wir gesehen: Die klassischen Eigenschaften zählen weiterhin. Aber Anpassungsfähigkeit, Kommunikationsfähigkeit, soziale und emotionale Fähigkeiten sowie Change-, Coaching- und Vertrauenskompetenzen gewinnen an Gewicht.(Quelle)
Das ist eine Aussage über Führung im Digitalen allgemein, kein Befund über KI. Aber der Schluss liegt nahe genug, um ihn auszusprechen: Wenn Technologie zwischen Menschen und ihre Arbeit tritt, verschiebt sich der Engpass von der Technik zur Begleitung. Ein Toolkalender löst das nicht.
Datenschutz und Mitbestimmung sind Gestaltungsparameter
In vielen Projekten kommen Datenschutz und Betriebsrat am Ende – als Prüfung, die man besteht oder an der man scheitert. Das ist teuer, weil man dann zweimal baut.
Meine Haltung: Diese Anforderungen sind Gestaltungsparameter, keine Hindernisse. Wer den Betriebsrat früh einbindet, bekommt nicht nur eine Zustimmung, sondern eine Information – nämlich, welche Nutzung die Belegschaft mitträgt. Diese Information hätte man ohnehin gebraucht, nur später und unter mehr Druck.
Ein Beispiel aus eigener Hand
Im Teilprojekt GameLOAP habe ich Online-Lernformate mit einer Anbindung an ein Sprachmodell entwickelt und in den Lehrbetrieb gebracht. Die Technik war die kleinere Hälfte. Die größere war: Wie kommt das Format in einen laufenden Lehrbetrieb? Wer betreut die Studierenden, wenn das Modell etwas Unerwartetes antwortet? Was passiert bei einem Ausfall? Erst als diese Fragen beantwortet waren, war aus einem funktionierenden Prototyp etwas geworden, das man tatsächlich einsetzen kann.(Quelle)
Fünf Fragen, die vor dem Rollout beantwortet sein sollten
- Welchen Arbeitsschritt genau ersetzt oder unterstützt das System – und was macht der Mensch stattdessen?
- Wer verantwortet das Ergebnis, wenn das System es vorbereitet hat?
- Woran erkennen wir in drei Monaten, ob es genutzt wird – und was tun wir, wenn nicht?
- Welche Regeln zu Daten, Prüfung und Fehlern gelten, und wer hat sie mitentschieden?
- Wer aus der Führungsebene arbeitet sichtbar selbst damit?
Keine dieser Fragen ist technisch. Wenn sie unbeantwortet bleiben, scheitert die Einführung nicht am Modell, sondern an der Organisation – und das merkt man erst, wenn der Pilot längst vorbei ist.