%20(2).png)
- Ein Pilot beweist, dass etwas möglich ist. Er beweist nicht, dass es im Alltag trägt – das sind zwei verschiedene Fragen.
- Die vier häufigsten Blocker: fehlende Integration, ungeklärte Zuständigkeit im Betrieb, keine Abnahmekriterien und kein Budget für die Laufzeit.
- Ein Pilot auf kopierten Testdaten sagt wenig über die Realität aus. Echte Daten zeigen die Ausnahmen – und die Ausnahmen sind die Arbeit.
- Wer vorher festlegt, ab welchem Messwert ausgerollt wird, muss am Ende nicht diskutieren, sondern nur nachsehen.
- Der Betrieb braucht einen Namen: Wer prüft die Ergebnisse, wer eskaliert, wer schaltet im Zweifel ab?
Warum der Sprung nicht gelingt
Der typische Pilot wird bewusst klein gehalten: wenige Beispiele, ein Teilprozess, ein Fachbereich, eine manuelle Dateneinspeisung. Genau diese Vereinfachungen sind der Grund, warum er funktioniert – und sie sind der Grund, warum der Betrieb daran nicht anschließt. Der Pilot löst das fachliche Problem; was fehlt, ist alles um das Problem herum.
Das ist kein Fehler im Pilot. Es ist ein Fehler in der Erwartung: Ein Proof of Concept ist eine Antwort auf „Geht das?“, nicht auf „Wie betreiben wir das?“. Wer beide Fragen im gleichen Schritt beantwortet haben will, braucht von Anfang an einen anderen Zuschnitt.
Die vier Blocker
| Blocker | Woran man ihn erkennt | Was vorher zu tun ist |
|---|---|---|
| Fehlende Integration | Daten werden für den Pilot manuell exportiert und eingefügt | Schnittstellen und Rechte vorab prüfen, nicht nur die Fachlogik |
| Unklare Zuständigkeit | Niemand kann sagen, wer das System nach dem Go-live betreut | Rolle benennen: Prüfung, Eskalation, Abschaltung |
| Keine Abnahmekriterien | Diskussion darüber, ob das Ergebnis „gut genug“ ist | Messgröße und Schwelle vor dem Pilot festlegen |
| Kein Betriebsbudget | Projektbudget deckt die Einführung, aber nicht den Betrieb | laufende Kosten von Anfang an mit einplanen |
Testdaten sind das falsche Material
Ein Pilot auf sauberen, ausgewählten Beispielen trifft fast immer. Der Alltag besteht aber aus dem, was nicht sauber ist: Dokumente mit fehlenden Feldern, Mails mit drei Themen in einer Nachricht, Scans in schlechter Qualität, Sonderfälle, die ein Mitarbeiter seit Jahren im Kopf hat. Diese Fälle sind kein Randthema, sondern der größere Teil der späteren Entwicklungsarbeit.
Deshalb lohnt es, den Pilot auf einem echten, unsortierten Ausschnitt laufen zu lassen – ruhig klein, aber zufällig gezogen statt ausgewählt. Das Ergebnis sieht schlechter aus und ist viel brauchbarer: Es zeigt, wie viel Nacharbeit zwischen Prototyp und Betrieb liegt, und das ist die Zahl, die man für die Entscheidung braucht.
Abnahmekriterien vor dem Pilot
Die entscheidende Frage lautet nicht „Funktioniert es?“, sondern „Ab welchem Wert rollen wir aus?“. Diese Schwelle muss vor dem Pilot stehen, sonst wird die Bewertung zur Geschmacksfrage – und Geschmacksfragen gewinnt im Zweifel der Status quo.
Brauchbar sind zwei Größen: eine Qualitätsgröße (Anteil korrekter Ergebnisse auf einem festen Testsatz) und eine Aufwandsgröße (verbleibende manuelle Nacharbeit pro Fall). Dazu gehört eine Vereinbarung, was bei Unsicherheit passiert: Nicht jedes Ergebnis muss automatisch durchlaufen – ein System, das Zweifelsfälle an einen Menschen gibt, ist oft wirtschaftlicher als eines, das alles selbst entscheiden will.
Der Betrieb braucht einen Namen
Ein KI-System ist kein Werkzeug, das man installiert und vergisst. Es braucht jemanden, der regelmäßig in die Ergebnisse schaut, der bei auffälligen Mustern nachfragt und der entscheidet, wenn etwas nicht stimmt. Diese Rolle muss nicht groß sein, aber sie muss existieren und einen Namen haben.
Dazu kommt ein Punkt, der gern vergessen wird: der Weg zurück. Was passiert, wenn das System ausfällt oder abgeschaltet wird – kann der Prozess manuell weiterlaufen? Wenn ja, ist der Einsatz unkritisch. Wenn nein, gehört diese Abhängigkeit vor dem Rollout auf den Tisch.
Zuschnitt für einen Pilot, der anschlussfähig ist
- Einen Teilprozess wählen, der auch allein einen Nutzen hat.
- Messgröße und Schwelle für den Rollout vorher festlegen.
- Echte, zufällig gezogene Daten verwenden – keine ausgewählten Beispiele.
- Schnittstellen und Zugriffsrechte früh prüfen, nicht erst beim Rollout.
- Datenschutzfragen parallel klären, nicht nach der Abnahme.
- Betriebsrolle benennen: Prüfung, Eskalation, Abschaltung.
- Laufende Kosten und Betreuungsaufwand in die Entscheidung einrechnen.
- Rückfallweg beschreiben, falls das System ausfällt.
Häufige Fragen (FAQ)
Wie lange sollte ein Pilot dauern?
Lang genug, um die unsauberen Fälle zu sehen, kurz genug, um nicht zum Dauerzustand zu werden. In der Praxis sind wenige Wochen auf echten Daten aussagekräftiger als Monate auf einem ausgewählten Testsatz. Ein fester Endtermin mit Entscheidungspunkt verhindert den Pilot ohne Ende.
Soll man klein anfangen oder gleich groß?
Klein im Umfang, aber realistisch in der Umgebung. Ein kleiner Anwendungsfall mit echter Integration bringt mehr Erkenntnis als ein großer mit manuellem Datentransfer – weil die Integration der Teil ist, der später Zeit kostet.
Was, wenn die Trefferquote unter der Schwelle bleibt?
Dann ist das ein brauchbares Ergebnis, kein gescheitertes Projekt. Häufig liegt die Ursache in der Datenqualität oder in einem zu breit gefassten Anwendungsfall. Beides lässt sich eingrenzen – oder man entscheidet begründet dagegen, was ebenfalls ein Ergebnis ist.
Braucht jeder Anwendungsfall einen Pilot?
Nein. Bei gut abgegrenzten Standardaufgaben mit klaren Ein- und Ausgaben kann man direkt aufsetzen und früh im Parallelbetrieb prüfen. Ein Pilot lohnt sich vor allem dort, wo unklar ist, wie viel Nacharbeit übrig bleibt.
Der Unterschied zwischen einem Pilot und einem Betrieb sind selten die Modelle – es sind Integration, Zuständigkeit, Kriterien und Budget. Wer die vier vor dem Prototyp klärt, hat danach eine Entscheidung statt einer Diskussion. Wie wir Anwendungsfälle entsprechend zuschneiden, zeigt die Seite Lösungen. Für eine Einordnung Ihres Vorhabens nutzen Sie den Kontakt.