Das Muster ist erstaunlich konstant. Ein Team baut etwas mit AI, zeigt es in einer Sitzung, alle sind beeindruckt. Drei Monate später fragt jemand nach – und die Antwort lautet, man sei noch dran, aber gerade sei viel los.

Der Pilot war nicht schlecht. Er ist nur nie zu Arbeit geworden. Nach unserer Erfahrung passiert das an drei konkreten Stellen, und an keiner davon ist die Technologie schuld.

Problem 1: Die Idee hängt am Werkzeug, nicht am Engpass

Der Ursprung ist oft eine Demo. Jemand sieht, was ein Werkzeug kann, findet es beeindruckend und überlegt danach, wo man das im eigenen Betrieb einsetzen könnte. Die Reihenfolge ist verkehrt herum – und sie führt zu Piloten, die etwas Beeindruckendes lösen, das niemanden gestört hat.

Woran ihr das erkennt: Der Pilot wird mit «schau mal, was das kann» vorgestellt, nicht mit «das hat uns letzten Monat elf Stunden gekostet». Fragt bei jeder AI-Idee nach der Zahl davor. Wenn niemand sagen kann, wie oft die Aufgabe anfällt und wie lange sie heute dauert, ist es keine Lösung, sondern eine Demo.

Das gilt auch umgekehrt: Manchmal zeigt die Antwort, dass das eigentliche Problem eine fehlende Schnittstelle ist oder ein Formular, das niemand ausfüllt. Dann ist die richtige Lösung eine Automatisierung ohne AI – günstiger, stabiler, wartungsärmer. Diesen Befund als Erfolg zu werten, fällt vielen schwer, spart aber am meisten Geld.

Problem 2: Es gibt niemanden, der freigeben darf

Der Pilot funktioniert, und dann steht die Frage im Raum, ob man damit jetzt echte Kundenkommunikation machen darf. Niemand weiss es. Also fragt man die Geschäftsleitung, die fragt den Datenschutzverantwortlichen, der findet die Frage berechtigt und will sie sorgfältig prüfen. Drei Wochen später ist die Aufmerksamkeit weg.

Das ist kein Unwille, sondern eine Lücke. Solange nicht definiert ist, welche Datenklassen erlaubt sind, wer freigibt und wer die Verantwortung für ein Ergebnis trägt, ist jede einzelne Entscheidung ein Einzelfall – und Einzelfälle dauern.

Die Konsequenz daraus ist unbequem für Projektpläne: Die Governance-Fragen gehören vor den Pilot, nicht danach. Nicht als vollständiges Regelwerk, aber als Minimalsatz von drei Antworten – welche Daten, wer gibt frei, wer haftet für das Ergebnis. Das ist ein Workshop, keine Konzeptphase.

Problem 3: Nach dem Pilot kommt keine Verankerung

Die dritte Stelle ist die häufigste. Der Pilot lief gut, die Freigabe ist da, drei Leute nutzen es – und dabei bleibt es. Nicht weil die anderen ablehnen, sondern weil es sie nie erreicht hat.

Dahinter stecken meist drei Versäumnisse. Es gab eine Schulung, aber eine generische: eine Stunde für alle, in der gezeigt wurde, was das Werkzeug alles kann, statt zwanzig Minuten pro Rolle mit der einen Aufgabe, die diese Rolle wirklich betrifft. Es gibt niemanden, den man fragen kann, wenn es nach zwei Wochen hakt. Und niemand misst, ob überhaupt jemand es benutzt.

Der letzte Punkt ist entscheidend, weil er alles andere sichtbar macht. «Wir haben zwanzig Lizenzen» ist keine Zahl. «Von zwanzig Personen nutzen es sieben wöchentlich, davon fünf im Verkauf» ist eine. Erst mit dieser Zahl könnt ihr fragen, warum die Finanzabteilung nicht dabei ist – und die Antwort ist fast immer konkret behebbar.

Was den Unterschied macht

Wer die drei Stellen kennt, kann sie einplanen. Praktisch heisst das:

Vor dem Pilot steht eine Analyse, die bei Prozessen beginnt und nicht bei Werkzeugen – mit einer Zahl zu Häufigkeit und heutigem Zeitbedarf für jeden Kandidaten. Gleichzeitig, nicht danach, werden die Minimalregeln geklärt: erlaubte Datenklassen, Freigabe, Verantwortung. Und nach dem Pilot folgt eine Phase, die den Namen verdient: rollenspezifische Schulung, benannte Ansprechpersonen, gemessene Nutzung.

Genau deshalb hat unser Vorgehen vier Phasen und nicht drei. Die vierte – wir nennen sie Drive – ist die, die in den meisten Projekten fehlt, und sie ist die, die über den Unterschied zwischen einem beeindruckenden Pilot und einer veränderten Arbeitsweise entscheidet.

Ein Pilot, der stirbt, ist nicht immer ein Fehler

Zum Schluss die Gegenprobe: Nicht jeder eingestellte Pilot ist ein Versagen. Wenn sich in Phase drei zeigt, dass ein Use Case in der Praxis nur die Hälfte des erhofften Nutzens bringt, ist das eine brauchbare Erkenntnis – vorausgesetzt, sie wird ausgesprochen und nicht als «läuft noch» weitergeschleppt.

Schlecht ist nicht der gestoppte Pilot. Schlecht ist der, der nie offiziell gestoppt wurde und deshalb weiter Aufmerksamkeit bindet.

Unser Vorgehen in vier Phasen – inklusive der Phase, die meistens fehlt →