Pilotprojekte, die ankommen – vom Experiment in den Alltag

KI-Pilotprojekte sind in den meisten Unternehmen inzwischen Normalität. Deutlich seltener ist der zweite Schritt: die Übernahme eines Piloten in den Regelbetrieb. Diese Lesson behandelt die Ursachen dieser Lücke und zeigt, wie ein Pilot angelegt wird, der eine belastbare Entscheidung liefert.

Das Scheitern nimmt dabei unterschiedliche Formen an. Vier Verläufe treten besonders häufig auf:

• Der Pilot hat in der Demo überzeugt, wurde danach aber nicht weiterverfolgt, und der Grund dafür ist nicht dokumentiert.
• Der Pilot läuft seit über einem Jahr, ohne dass ein Termin oder ein Kriterium existiert, an dem über ihn entschieden wird.
• Der Pilot war breit angelegt, mehrere Abteilungen und Systeme gleichzeitig, und wurde nie fertiggestellt.
• Das Team findet keinen Use Case, der den Aufwand eines Piloten rechtfertigt.

Diese Verläufe haben eine gemeinsame Ursache. Piloten scheitern selten an der Technik, sondern meist am Design des Piloten: daran, wie er zugeschnitten, gemessen und beendet wird. Dieser Teil liegt vollständig in der Hand der Beteiligten und ist deshalb der wirksamste Ansatzpunkt.

Der Kerngedanke der Lesson

Ein Pilot ist ein Experiment mit Entscheidungsauftrag. Er hat eine Hypothese, eine Messgröße, einen Zeitrahmen und einen Termin, an dem entschieden wird. Fehlt eines dieser vier Elemente, handelt es sich der Sache nach um eine Demo oder ein Provisorium, unabhängig davon, wie das Vorhaben genannt wird.

Was dich erwartet

Demo, Proof of Concept, Pilot und Rollout werden im Alltag oft austauschbar benutzt. Tatsächlich beantwortet jede Stufe eine andere Frage und beweist genau eine Sache. Diese Unterscheidung ist die Grundlage für alles Weitere in dieser Lesson, denn viele spätere Probleme entstehen aus einer Verwechslung an dieser Stelle.

Die zwei typischen Verwechslungen

Die Demo wird als Pilot verkauft. Ein beeindruckender Prototyp aus handverlesenen Beispielen bekommt das Etikett Pilot, ohne dass echte Daten, echte Nutzer oder eine Messung dazukommen. Am Ende gibt es Begeisterung, aber keine Grundlage für eine Investitionsentscheidung. Die Diskussion, was der Pilot eigentlich gezeigt hat, beginnt erst nach seinem Ende.

Der Pilot wird wie ein Rollout geplant. Aus Sorge, später etwas zu übersehen, werden alle Abteilungen, Systeme und Sonderfälle von Anfang an einbezogen. Damit übernimmt der Pilot die Komplexität eines Rollouts, ohne dessen Grundlage zu haben: den Beweis, dass sich der Aufwand lohnt. Solche Piloten werden selten abgeschlossen, weil ihnen die Begrenzung fehlt, die ein Experiment auswertbar macht.

Wenn ein Pilot scheitert, richtet sich der erste Verdacht meist auf das Modell, das Tool oder die Datenqualität. Bei genauerer Betrachtung war das Scheitern jedoch oft schon im Zuschnitt angelegt, bevor etwas gebaut wurde. Vier Muster decken die große Mehrheit der Fälle ab.

Muster 1: Die Demo-Falle

Der Pilot hat keine Hypothese und keine Messgröße. Er soll zeigen, was möglich ist, und liefert deshalb am Ende Eindrücke statt einer Zahl, die eine Entscheidung trägt. Das Erkennungszeichen: Wenn niemand benennen kann, welches Ergebnis als Erfolg gegolten hätte, handelte es sich um eine verlängerte Demo, nicht um einen Piloten.

Muster 2: Die Größen-Falle

Der Pilot ist als kleine Transformation angelegt: mehrere Abteilungen, mehrere Systeme, ein Lenkungskreis. Damit steigt nicht nur der Aufwand, sondern vor allem die Zahl der Variablen. Wenn das Ergebnis enttäuscht, lässt sich nicht mehr feststellen, ob es am Use Case, an der Integration, an der Schulung oder an einem einzelnen Bereich lag. Der Erkenntniswert des Piloten geht verloren, unabhängig davon, wie viel Arbeit in ihm steckt.

Muster 3: Die Problem-Falle

Der Pilot beginnt beim Werkzeug statt beim Problem. Der Auftrag lautet sinngemäß, etwas mit KI zu machen, und so entsteht ein Anwendungsfall ohne echten Schmerzpunkt. Solche Piloten können technisch sauber laufen und trotzdem nichts beweisen, weil ihr Ergebnis für den Arbeitsalltag keine Rolle spielt. Wie du Use Cases mit echtem Hebel findest, behandelt die Lesson KI Use Cases neu denken.

Muster 4: Die Endlos-Falle

Der Pilot funktioniert, aber es gibt keinen Entscheidungstermin, keinen Verantwortlichen für den späteren Betrieb und kein Budget für die Zeit danach. Er läuft deshalb als dauerhafter Sonderfall weiter, betreut vom ursprünglichen Projektteam, bis das Interesse nachlässt oder eine Budgetrunde ihn beendet. Die Ursache liegt nicht im Piloten selbst, sondern darin, dass der Weg in den Regelbetrieb nie geplant wurde.

Gegen die Demo-Falle und die Größen-Falle hilft ein einfaches Werkzeug: der Pilot-Steckbrief, eine Seite, ausgefüllt vor dem Start. Er erzwingt die Klärungen, die sich später nicht mehr nachholen lassen, allen voran die Frage, woran sich der Pilot messen lässt.

Die sieben Angaben

1. Problem: Welcher Schmerzpunkt soll kleiner werden, und wer hat ihn heute? Ein Satz, der auch ohne das Wort KI funktioniert.
2. Hypothese: Ein falsifizierbarer Wenn-dann-Satz. Er muss so formuliert sein, dass er am Ende auch widerlegt sein kann.
3. Messgröße mit Vergleichswert: Eine Kennzahl, die die Hypothese prüft, und ihr heutiger Wert. Der Vergleichswert wird vor dem Start erhoben, nicht danach rekonstruiert.
4. Zuschnitt: Ein Workflow, ein Team. Alles Weitere ist Rollout-Arbeit und kommt nach der Entscheidung.
5. Nutzer und Daten: Echte Nutzer aus dem betroffenen Team und echte Daten aus dem echten Bestand, nicht die Vorzeige-Auswahl.
6. Zeitrahmen: Ein festes Enddatum. Üblich sind vier bis zwölf Wochen. Zeigt sich in dieser Zeit kein messbarer Effekt, ist ein späterer Effekt unwahrscheinlich.
7. Entscheidung: Wer entscheidet am Ende, an welchem Termin, und bei welchem Ergebnis wird vorzeitig abgebrochen?

Der Unterschied in der Praxis

Wie groß der Unterschied ist, zeigt sich am schnellsten im Vergleich. So klingen viele Piloten, bevor jemand den Steckbrief verlangt:

Die Werte im Beispiel sind fiktiv, der Unterschied ist es nicht: Jede Zeile der Nachher-Version ist am Ende überprüfbar. Die Vorher-Version lässt sich weder bestätigen noch widerlegen und liefert deshalb keine Grundlage für eine Entscheidung.

Die Endlos-Falle entsteht nicht am Ende des Piloten, sondern an seinem Anfang: Der Pilot wird als isoliertes Vorhaben gebaut, und die Überführung in den Regelbetrieb soll später geklärt werden. Zu diesem späteren Zeitpunkt konkurriert die Überführung dann mit allen anderen Vorhaben um Budget und Zuständigkeit, und in vielen Fällen unterbleibt sie deshalb ganz.

Das Gegenmittel sind fünf Fragen, die vor dem Start gestellt werden. Sie müssen nicht alle abschließend beantwortet sein, aber sie müssen auf dem Tisch liegen, mit einem Namen dahinter.

Die fünf Alltagsfragen

1. Owner: Wem gehört das Ergebnis im Regelbetrieb? Die Antwort ist ein Name aus dem Fachbereich, der den Nutzen hat. Ein Pilot, der dauerhaft dem Innovationsteam gehört, hat keinen Abnehmer.
2. Integration: An welcher Stelle im bestehenden Ablauf setzt das Ergebnis an? Was ersetzt es, was kommt hinzu, welches System ist betroffen? Ein Werkzeug neben dem Workflow wird nach der Anfangsneugier nicht mehr geöffnet.
3. Betriebskosten: Was kostet der Regelbetrieb pro Monat, von Lizenzen über Nutzung bis Pflege, und aus wessen Budget? Die Kostenseite von KI-Lösungen behandelt die Lesson Was KI wirklich kostet.
4. Daten und Berechtigungen: Läuft der Pilot unter denselben Daten-, Rechte- und Compliance-Bedingungen wie später der Betrieb? Jede Ausnahmegenehmigung, die nur für den Piloten gilt, muss vor einem Rollout regulär geklärt werden und gehört deshalb früh auf die Liste.
5. Betreuung: Wer beantwortet nach dem Piloten Fragen, pflegt Prompts und Wissensbestände und kümmert sich um Fehler? Ohne diese Rolle zerfällt auch ein erfolgreicher Pilot innerhalb weniger Monate.

Der Anspruch ist dabei nicht, vor dem Start alles zu lösen, sondern nichts zu übersehen. Eine offen markierte Frage, etwa eine ungeklärte Budgetzuordnung, ist ein dokumentierter Arbeitsstand. Eine nie gestellte Frage taucht dagegen am Entscheidungstermin als ungeklärte Voraussetzung wieder auf und verzögert oder verhindert dort die Übernahme.

Am Entscheidungstermin liegen zwei Dinge auf dem Tisch: der Steckbrief und die Messwerte. Daraus ergibt sich einer von drei Ausgängen, und alle drei sind legitime Ergebnisse eines gut angelegten Piloten.

Verwerfen ist ein Ergebnis

Ein verworfener Pilot mit dokumentierter Begründung ist ein günstiges Ergebnis: Er hat für den Preis weniger Wochen eine Fehlinvestition in den Rollout verhindert, und die Lernnotiz erspart dem nächsten Team denselben Umweg. Teuer ist der Gegenfall: der Pilot, der ohne Entscheidung weiterläuft, weil sein Ende als Eingeständnis eines Fehlers gewertet würde. Er bindet dauerhaft Betreuung und Budget und schwächt zusätzlich die Glaubwürdigkeit nachfolgender Piloten.

Die Qualität dieser Entscheidung hängt vollständig an der Qualität der Messung. Wie du Messgrößen baust, die eine Entscheidung tragen, von der Fehleranalyse bis zur Kennzahl, vertieft die Lesson Messen statt raten.

Der Kern der Lesson in einem Satz: Ein Pilot ist ein Experiment mit Entscheidungsauftrag. Die fünf Regeln der Lesson sind Konsequenzen aus diesem Satz.

Das Prüfschema vor dem Start

Acht Fragen, bevor ein Pilot startet. Jedes Nein markiert eine Aufgabe, die sich vor dem Start mit deutlich weniger Aufwand lösen lässt als danach.

1. Ist benannt, auf welcher Stufe das Vorhaben steht und was genau es beweisen soll?
2. Begann die Auswahl beim Problem, und würde jemand den Piloten vermissen, wenn er morgen endet?
3. Gibt es eine Hypothese, die am Ende auch widerlegt sein kann?
4. Ist der Vergleichswert der Messgröße vor dem Start erhoben?
5. Ist der Zuschnitt ein Workflow und ein Team?
6. Sind die fünf Alltagsfragen gestellt: Owner, Integration, Betriebskosten, Datenbedingungen, Betreuung?
7. Stehen Entscheidungstermin und Entscheider fest?
8. Ist festgelegt, welches Ergebnis zu Skalieren, Iterieren oder Verwerfen führt, inklusive Abbruchkriterium?

Wie es weitergeht

Diese Lesson hat den Prozess behandelt. Drei Lessons vertiefen die Bausteine: KI Use Cases neu denken hilft, das richtige Problem zu finden, bevor der Steckbrief entsteht. Messen statt raten liefert das Handwerk für Messgrößen, die eine Entscheidung tragen. Und Was KI wirklich kostet schlüsselt die Betriebskosten auf, die in der vierten Alltagsfrage stecken. Wer noch grundsätzlicher einsteigen will, findet in KI im Business einsetzen die Einsatzformen, aus denen Pilot-Kandidaten entstehen.