Piloten optimieren auf sichtbare Funktion: Das System soll in der Präsentation überzeugen. Produktive Systeme müssen dagegen wiederholt mit echten Fällen, Ausnahmen, wechselnden Daten und Nutzern arbeiten, die keine Enthusiasten sind. Zwischen beiden liegt eine Strecke, die viele Projekte nicht einplanen. Produktionsreife ist kein Termin im Kalender, sondern ein Zustand, der sich belegen lässt.
Warum Piloten steckenbleiben
- Es gibt keine Abnahmekriterien, also auch keinen Zeitpunkt, an dem der Pilot als bestanden gilt.
- Die Pilotnutzer sind die Personen, die das Projekt wollten; ihre Zufriedenheit sagt wenig über den Rest der Belegschaft.
- Niemand ist für den Betrieb benannt, weil das Projektteam nach dem Pilot andere Aufgaben hat.
- Die Datenqualität wurde nur für den Pilotausschnitt hergestellt.
- Sicherheits- und Datenschutzprüfung beginnen erst, wenn der Pilot fertig ist, und stellen dann Grundsatzfragen.
- Für den Betrieb ist kein Budget vorgesehen, weil der Pilot als Abschluss galt.
Abnahmekriterien in vier Feldern
| Feld | Beispielkriterium | Nachweis |
|---|---|---|
| Funktion | Das Testset erreicht die vereinbarte Qualität, kritische Fehler treten nicht auf | Evaluationsbericht mit Baseline und Datum |
| Betrieb | Owner, Support, Änderungsweg, Monitoring und Fallback sind vorhanden | Runbook, durchgeführter Alarm- und Abschalttest |
| Sicherheit und Daten | Rechte minimal, Datenschutzprüfung abgeschlossen, Angriffsfälle bestanden | Freigabe durch Datenschutz und IT-Sicherheit |
| Organisation | Nutzer qualifiziert, Prüfaufträge definiert, Kommunikation an Betroffene vorbereitet | Schulungsnachweis, Rollenliste, Ankündigung |
Die Kriterien werden vor dem Pilot festgelegt, nicht danach. Sonst passt sich das Kriterium dem Ergebnis an.
Der kontrollierte Pilot
Ein Pilot braucht einen begrenzten Nutzerkreis, der die spätere Zielgruppe abbildet, eine feste Laufzeit, messbare Ziele, eine wöchentliche Durchsicht der Kennzahlen und einen Entscheidungstermin, an dem die Evidenz auf dem Tisch liegt. „Wir schauen mal, wie es läuft“ ist kein Pilot, sondern ein unbefristeter Versuch.
Betrieb parallel zur Funktion entwickeln
Monitoring, Protokolle, Runbook und Rückweg auf die vorherige Version entstehen ab der ersten Woche, nicht nach der Freigabe. Was im Pilot nicht beobachtet wurde, kann in der Produktion nicht bewertet werden. Diese Reihenfolge verlängert den Pilot um wenige Tage und verkürzt die Produktivsetzung um Wochen.
Beispiel: Rechnungseingang
Ein Pilot soll Rechnungsdaten automatisch auslesen. In der Vorführung mit Musterrechnungen funktioniert es nahezu fehlerfrei. Im Pilot mit zweihundert echten Rechnungen zeigt sich, dass Lieferanten unterschiedliche Formate verwenden, Positionen auf mehreren Seiten stehen und Gutschriften wie Rechnungen aussehen. Der Pilot definiert deshalb: Testset aus echten Belegen, Abnahmekriterium je Feld, manueller Fallback in der Buchhaltung, Owner benannt. Die Produktivsetzung beginnt mit den drei Lieferanten, deren Formate stabil sind, und wird nach jeder bestandenen Erweiterung fortgesetzt.
Die Freigabeentscheidung
Die Entscheidung stützt sich auf drei Fragen: Sind die Kriterien erfüllt und belegt? Welche Restrisiken bleiben und wer trägt sie ausdrücklich? Wann wird der Betrieb erstmals überprüft? Ein Protokoll mit diesen Antworten ist die Grundlage, auf die sich später alle beziehen können, wenn etwas schiefgeht oder erweitert werden soll.
Produktionsreife ist erreicht, wenn das System an einem schlechten Tag beherrschbar ist, nicht wenn es an einem guten Tag beeindruckt.
Die Bausteine der fehlenden Mitte
Wie ein Testset entsteht, das als Abnahmegrundlage taugt, beschreibt der Beitrag zur Evaluation von KI-Ergebnissen. Welche Signale und Schweregrade in ein Runbook gehören, zeigt der Beitrag zum KI-Monitoring; wie der Datenvertrag mit bestehenden Systemen aussieht, der Beitrag zur KI-Integration.