Es gibt ein Muster, das sich in Unternehmen jeder Größe wiederholt. Ein Pilotprojekt startet. Innerhalb weniger Wochen gibt es eine Demonstration, die alle im Raum ehrlich beeindruckt. Dann vergehen Monate, die Begeisterung verfliegt, und irgendwann wird die Sache nicht mehr erwähnt.
Das kommt oft genug vor, dass es eine Untersuchung verdient. Die Ursachen sind nicht geheimnisvoll.
Die Demo optimiert auf das Falsche
Eine Demonstration wird gebaut, um zu zeigen, was möglich ist. Produktionssoftware wird gebaut, um zu bewältigen, was wahrscheinlich ist. Das sind unterschiedliche Ingenieursaufgaben, und in dieser Lücke sterben die meisten Piloten.
In einer Demo wählt jemand die Eingabe aus. Ein sauberes Dokument, eine gut gestellte Frage, ein repräsentativer Fall. Im Betrieb ist die Eingabe das, was ankommt – eine schiefe Scanseite, eine E-Mail mit drei Fragen versteckt in einer Beschwerde, ein falsch ausgefülltes Formular. Die Demo musste damit nie umgehen, also hat niemand geschätzt, wie viel Arbeit das wäre.
Eine brauchbare Faustregel: Die Demo entspricht vielleicht einem Fünftel des Gesamtaufwands. Wenn Ihre Planung sie als „fast fertig“ behandelt, liegt Ihr Zeitplan um ein Vielfaches daneben.
Niemand verantwortet das Ergebnis
Wenn ein Pilot ein Ergebnis liefert, sehen es alle an, weil es neu und interessant ist. Wenn ein Produktivsystem täglich vierzig Ergebnisse liefert, muss jemand die Prüfung verantworten – als Teil seiner tatsächlichen Aufgaben, mit dafür eingeplanter Zeit.
Wurde diese Verantwortung nie zugewiesen, produziert das System entweder ungeprüfte Ergebnisse, bis etwas schiefgeht, oder die Leute hören still auf, es zu nutzen, weil die Prüflast bei dem gelandet ist, der am wenigsten Nein sagen konnte. Beides beendet das Projekt.
Integration wurde als Nachgedanke behandelt
Der Pilot lief mit Daten, die jemand in eine Tabelle exportiert hat. Der Betrieb verlangt, aus dem System zu lesen, in dem die Daten tatsächlich liegen, Ergebnisse zurückzuschreiben, Fehler zu behandeln – und das ohne Administrator, der es manuell startet.
Diese Arbeit ist unglamourös und macht meist den größten Teil des Projekts aus. Sie verlangt außerdem Zugänge und Berechtigungen, deren Beschaffung im Unternehmen Wochen dauern kann. Ein Pilot, der die echten Systeme nie berührt hat, hat das Risiko des Projekts nicht verringert – er hat es verschoben.
Erfolg wurde nie definiert
Fragt man, was der Pilot beweisen sollte, bekommt man oft eine vage Antwort: dass KI hier helfen könnte. Das ist kein Kriterium, das jemand bestehen oder verfehlen kann.
Vergleichen Sie das mit: „Mindestens siebzig Prozent der eingehenden Anfragen sollen ohne Korrektur bearbeitet werden, und eine Prüferin soll eine davon in unter einer Minute kontrollieren können.“ Jetzt hat der Pilot ein Ergebnis. Jetzt ist die Entscheidung über Fortsetzung oder Abbruch eine Entscheidung und keine Stimmung.
Der Prozess selbst war kaputt
Manchmal funktioniert der Pilot genau wie gedacht und zeigt, dass der automatisierte Prozess gar nicht existieren sollte. Ein Formular, das niemand liest. Ein Freigabeschritt, der noch nie zu einer Ablehnung geführt hat. Ein Monatsbericht für jemanden, der das Unternehmen verlassen hat.
Das ist kein Misserfolg – es ist eines der wertvolleren möglichen Ergebnisse. Aber es zählt nur als Wert, wenn jemand danach handelt, statt den Piloten als gescheitert abzulegen.
Wie der nächste anders wird
Legen Sie die Erfolgskriterien vor dem Start fest. Arbeiten Sie ab der ersten Woche mit echten, unsauberen Eingaben statt mit ausgewählten Beispielen. Benennen Sie die Person, die das Ergebnis im Betrieb verantwortet, und bestätigen Sie, dass sie die Zeit hat. Verbinden Sie sich früh mit einem echten System, auch grob, damit das Integrationsrisiko auftaucht, solange das Projekt klein ist. Und vereinbaren Sie vorab, was zum Abbruch führen würde – ein Projekt, das nicht scheitern kann, kann auch nicht wirklich gelingen.
