Warum KI-Projekte im Pilot stecken bleiben
Fast jedes Unternehmen, mit dem wir sprechen, hat schon einmal etwas mit KI ausprobiert. Fast keines hat es in den Betrieb gebracht. Der Grund liegt selten in der Technik.
Ein Pilot ist schnell gebaut. Ein Modell anbinden, ein paar Dokumente hineinkippen, eine Oberfläche darum herum: nach zwei Wochen steht etwas, das in der Präsentation überzeugt. Genau das ist das Problem. Ein Pilot beweist, dass etwas möglich ist. Er beweist nicht, dass es tragfähig ist.
Der Sprung, den niemand einplant
Zwischen Demo und Betrieb liegt Arbeit, die in keiner Präsentation vorkommt: Zugriffsrechte, die zur bestehenden Rollenstruktur passen. Fehlerfälle, die jemand sieht und behebt. Eine Antwort auf die Frage, was passiert, wenn das Modell falsch liegt. Und ein Mensch, der zuständig ist, wenn am Dienstagmorgen niemand mehr weiterkommt.
Diese Arbeit ist unspektakulär und macht rund zwei Drittel des Gesamtaufwands aus. Wer sie erst nach dem erfolgreichen Pilot entdeckt, steht vor einem Budgetantrag, den er nicht vorbereitet hat. Das Projekt wird dann nicht abgelehnt, es wird vertagt. Und vertagt bedeutet in der Praxis beendet.
Vier Entscheidungen, die vor dem Start gehören
- 01Wer betreibt das System nach dem Go-live? Ein Name, keine Abteilung.
- 02Woran messen wir, ob es funktioniert? Eine Zahl, die es heute schon gibt.
- 03Was passiert bei einer falschen Antwort? Wer merkt es, wer korrigiert?
- 04Wie kommt das System wieder weg, wenn es nicht trägt? Ein Ausstieg ohne Datenverlust.
Diese vier Fragen kosten in der Vorbereitung eine halbe Stunde. Später kosten sie das Projekt. Wir stellen sie im ersten Gespräch, weil die Antworten oft schon zeigen, ob der gewählte Anwendungsfall der richtige ist.
Klein anfangen heisst nicht unwichtig anfangen
Der häufigste Fehler bei der Auswahl: Man sucht einen Prozess, bei dem wenig kaputtgehen kann. Das Ergebnis ist ein Anwendungsfall, den niemand vermisst, wenn er wegfällt, und für den entsprechend niemand kämpft, wenn es hakt.
Besser ist ein Prozess, der schmal, aber echt ist: eine Aufgabe, die täglich anfällt, klar begrenzt ist und deren Ergebnis jemand sofort beurteilen kann. Angebotsentwürfe aus wiederkehrenden Bausteinen. Eingehende Rechnungen vorsortieren. Protokolle in Aufgaben übersetzen. Alles Dinge, bei denen der Nutzen in der ersten Woche sichtbar ist.
Ein Anwendungsfall, den niemand vermisst, wird auch nicht verteidigt, wenn das Budget knapp wird.
Woran wir es festmachen
Bevor wir bauen, halten wir fest, welche Zahl sich verändern soll und wo sie heute steht. Bearbeitungszeit pro Vorgang, Anteil manueller Nacharbeit, Durchlaufzeit bis zur ersten Antwort. Ohne diesen Ausgangswert bleibt jede spätere Bewertung Geschmackssache, und Geschmackssache verliert gegen jede Sparrunde.
