C3. Vom Piloten zur Produktion
Die meisten KI-Piloten erreichen nie die Produktion. Sie bleiben im Demonstrationsstadium stecken: technisch erfolgreich vorgeführt, aber nie in den Regelbetrieb überführt (das sogenannte Pilot-Fegefeuer).
Was dieses Kapitel liefert: das Vorgehen, einen Piloten von Anfang an auf den Übergang hin zu bauen, die Skalierungskriterien und die Go/No-Go-Checkliste für das Gate Pilot → Scale aus Kapitel C1 sowie die Rollout-Strategien für den Weg in die Fläche.
Den Piloten von Anfang an richtig aufsetzen
Ob ein Pilot die Produktion erreicht, entscheidet sich überwiegend vor seinem Start, mit der Frage, als was er gebaut wird. Zwei Denkweisen stehen sich gegenüber; beide beschreiben denselben Piloten, nur unterschiedlich aufgesetzt:
- Pilot im Demo-Modus: gebaut, um in einer Vorführung zu überzeugen. Alles ist auf diesen Termin hin optimiert: ausgewählte Daten, eigene Umgebung, keine Prüfungen. Nach der Vorführung ist nichts davon in der Produktion verwendbar, die eigentliche Arbeit beginnt von vorn. Genau so entsteht das Pilot-Fegefeuer aus der Kapiteleinleitung.
- Pilot als Produktionsvorstufe: gebaut als kleine Ausgabe des späteren Produktivsystems: dieselben Daten, dieselbe Plattform, dieselben Prüfungen, nur in kleinem Umfang. Fällt am Gate die Entscheidung Go, wächst dieser Pilot zur Produktion, statt neu gebaut zu werden.
Jede Zeile der Tabelle ist eine Designentscheidung, die beim Aufsetzen des Piloten getroffen wird. Die letzte Spalte zeigt, warum die Entscheidung den Unterschied macht: was beim Übergang in die Produktion passiert.
| Designentscheidung | Pilot im Demo-Modus | Pilot als Produktionsvorstufe | Folge beim Übergang in die Produktion |
|---|---|---|---|
| Erfolgskriterium | Der Pilot startet ohne festes Ziel, ganz im Sinne von „Wir schauen mal, was möglich ist". | Ein messbares Kriterium und eine Baseline werden vor dem Start festgelegt (siehe Kapitel D1). So beweist oder widerlegt der Pilot eine konkrete Hypothese. | Am Gate braucht es einen Nachweis: Der Demo-Pilot liefert nur Eindrücke, die Produktionsvorstufe liefert Messwerte gegen die Baseline. |
| Daten | Der Pilot arbeitet mit handverlesenen Beispielen und einem vorab bereinigten Datenauszug. | Der Pilot nutzt echte Produktivdaten mit all ihrer Unordnung, über den echten Zugriffsweg. | Beim Demo-Piloten bricht die Qualität ein, sobald echte Daten kommen; die Produktionsvorstufe hat diese Hürde bereits im Piloten genommen. |
| Architektur | Der Pilot läuft in einer abgeschotteten Testumgebung (Sandbox), die sich später nicht integrieren lässt. | Der Pilot ist eine schlanke Version des Zielbilds (siehe Kapitel B5): dieselben Plattformbausteine, dieselbe Authentifizierung, nur kleiner. | Der Demo-Pilot muss für die Produktion neu gebaut werden; die Produktionsvorstufe wird erweitert statt ersetzt. |
| Kosten | Die Kosten werden nicht gemessen, denn es ist „ja nur ein Pilot". | Die Kosten je Einheit (Anfrage, Vorgang) werden ab Tag 1 gemessen und auf den Zielumfang hochgerechnet (siehe Kapitel D2). | Ob sich der Dauerbetrieb rechnet, zeigt sich beim Demo-Piloten erst nach dem Rollout, bei der Produktionsvorstufe schon am Gate. |
| Governance | Sicherheit, Datenschutz und Ethik werden auf „später" vertagt. | Die Prüfungen laufen im Piloten mit (siehe Kapitel B8 bis B10). Die Freigabefähigkeit ist Teil des Pilotergebnisses. | Die nachgeholte Prüfung blockiert den Rollout des Demo-Piloten um Monate; die Produktionsvorstufe bringt die Freigaben schon mit. |
| Nutzer | Das Projektteam testet sich selbst. | Echte Anwender aus dem Fachbereich arbeiten produktionsnah mit und geben strukturiertes Feedback. | Akzeptanz und Alltagstauglichkeit zeigen sich beim Demo-Piloten erst in der Fläche; die Produktionsvorstufe kennt beides schon aus dem Piloten. |
| Zeitrahmen | Der Pilot läuft ohne festes Enddatum. | Der Pilot hat eine Zeitbox von 3 bis 6 Monaten mit festem Gate-Termin. | Ohne Endtermin wird der Demo-Pilot zum Dauerprovisorium; die Zeitbox erzwingt die Gate-Entscheidung. |
Der Mehraufwand dieser Disziplin ist gering im Vergleich zu ihrem Effekt: Ein so aufgesetzter Pilot beantwortet am Gate alle Fragen der Go/No-Go-Checkliste aus dem laufenden Betrieb heraus, statt sie nachträglich rekonstruieren zu müssen.
Warum Piloten scheitern
Die Tabelle zeigt die häufigsten Scheiterursachen mit ihrem typischen Symptom. Sie dient zwei Zwecken: als Frühwarnliste während der laufenden Pilotphase (tritt eines der Symptome bereits auf?) und als Ursachenanalyse für bereits gescheiterte Vorhaben, bevor der nächste Pilot startet.
| Ursache | Symptom |
|---|---|
| Kein Erfolgskriterium definiert | Der Pilot „funktioniert", aber niemand kann sagen, ob er den erwarteten Nutzen erreicht hat |
| Auf Demodaten statt Produktivdaten getestet | Die Qualität bricht ein, sobald echte, unsaubere Daten verarbeitet werden |
| Fehlende Architektur-Anbindung | Der Pilot läuft isoliert und lässt sich nicht in Kernsysteme integrieren, ohne neu gebaut zu werden |
| Inferenzkosten unterschätzt | Der Pilot war günstig, weil er wenige Anfragen verarbeitet hat; der Dauerbetrieb rechnet sich nicht |
| Kein Owner nach Pilotende | Das Projektteam löst sich auf, niemand verantwortet den Übergang in den Betrieb |
| Fehlende Governance-Freigabe | Sicherheits-, Compliance- oder Ethikprüfung war im Pilot nicht vorgesehen und blockiert jetzt den Rollout |
| Zu viele parallele Piloten | Kapazität verteilt sich auf zu viele Vorhaben, keines wird konsequent zu Ende geführt |
Skalierungskriterien
Ein Pilot ist skalierungsreif, wenn er alle drei Dimensionen erfüllt, nicht nur die technische. Die drei folgenden Listen prüfen Technik, Organisation und Wirtschaftlichkeit; jeder Punkt wird am Gate mit einem Nachweis belegt und mündet in die Go/No-Go-Checkliste im nächsten Abschnitt.
Technisch
- Lösung wurde mit echten Produktivdaten getestet, nicht nur mit kuratierten Beispielen
- Architektur ist anschlussfähig an Kernsysteme, ohne Neubau
- Beobachtbarkeit (Metriken, Protokolle, Drift-Erkennung) ist eingerichtet
- Sicherheits-Checkliste ist vollständig durchlaufen (siehe Kapitel B9)
Organisatorisch
- Ein Service Owner für den Dauerbetrieb ist benannt (siehe Kapitel B7)
- Governance-, Compliance- und Ethikfreigabe liegen vor (siehe Kapitel B8 und B10)
- Support-Struktur (Stufen 1 bis 3) ist definiert
- Betroffene Fachbereiche sind informiert und eingebunden (siehe Kapitel B11)
Wirtschaftlich
- Business Case wurde mit tatsächlichen Pilotdaten aktualisiert, nicht nur mit der ursprünglichen Schätzung
- Laufende Kosten (Inferenz, Betrieb, Lizenz) sind für den Zielumfang hochgerechnet
- Erfolgskriterium aus der Pilotphase wurde nachweislich erreicht oder mit Begründung angepasst
- Kostenzuordnung für den Dauerbetrieb ist geklärt
Vorlage: Go/No-Go-Checkliste
So wird die Checkliste eingesetzt: Vor der Gate-Entscheidung Pilot → Scale wird jede Zeile mit einem konkreten Nachweis gefüllt. Die letzte Spalte legt vorab fest, was bei Nichterfüllung passiert. Das ist der entscheidende Unterschied zu einer gewöhnlichen Liste: Die Konsequenz wird nicht erst in der Sitzung verhandelt, wenn der Druck groß ist, weiterzumachen.
| Kriterium | Erfüllt? | Nachweis | Entscheidung bei Nichterfüllung |
|---|---|---|---|
| Erfolgskriterium erreicht | Pilot mit angepasstem Ziel verlängern oder beenden | ||
| Produktivdaten getestet | Nicht skalieren, erst mit echten Daten erneut prüfen | ||
| Architektur anschlussfähig | Integrationsaufwand neu bewerten, ggf. Architektur anpassen | ||
| Governance-Freigaben vorliegend | Skalierung blockieren, bis die Freigabe erteilt ist | ||
| Service Owner benannt | Keine Übergabe in den Betrieb ohne benannte Verantwortung | ||
| Wirtschaftlichkeit im Zielumfang bestätigt | Kostenmodell überarbeiten oder Umfang reduzieren |
Entscheidungsregel: Ein „No-Go" bei technischen oder Governance-Kriterien ist verbindlich. Hier wird nachgebessert, nicht übergangen. Bei wirtschaftlichen Kriterien kann das Management bewusst und dokumentiert abweichen, wenn strategische Gründe überwiegen.
Rollout-Strategien: der Weg in die Fläche
Nach dem Go stellt sich die Frage, wie die Lösung in die Breite kommt. Vier Strategien haben sich etabliert; sie lassen sich kombinieren (z. B. Schattenbetrieb je neuer Nutzergruppe innerhalb eines stufenweisen Rollouts).
| Strategie | Vorgehen | Wann geeignet | Grenzen |
|---|---|---|---|
| Schattenbetrieb | Die KI läuft parallel zum bestehenden Prozess, ihre Ergebnisse werden verglichen, aber nicht verwendet | Folgenreiche Entscheidungen (Kredit, Preisbildung); immer, wenn die Qualität an realem Volumen erst belegt werden muss | Doppelaufwand für die Laufzeit; Endnutzer-Feedback fehlt, weil niemand mit den Ergebnissen arbeitet |
| Stufenweiser Rollout | Ausweitung nach Bereichen, Standorten oder Nutzergruppen mit Prüfpunkt je Stufe | Standardfall für die meisten Anwendungen; jede Stufe liefert Lernerfahrungen für die nächste | Braucht Geduld und diszipliniertes Nachhalten der Prüfpunkte |
| Parallelbetrieb mit Vergleichsgruppe | Ein Teil der Nutzer oder Vorgänge arbeitet mit, ein Teil ohne KI; Ergebnisse werden verglichen | Wenn der Wirkungsnachweis (gegen die Baseline) belastbar sein muss, z. B. für den Business Case | Organisatorisch anspruchsvoll; bei kleinen Fallzahlen wenig aussagekräftig |
| Big Bang | Alle Nutzer gleichzeitig | Nur bei geringem Risiko, erprobter Technik und einfacher Rücknahme (z. B. internes Assistenzwerkzeug) | Bei Problemen sind sofort alle betroffen; für folgenreiche oder kundennahe Systeme ungeeignet |
Für jede Strategie gilt: Ein Rückweg wird vor dem Rollout definiert (Abschaltpfad, Rückfall auf den alten Prozess). Ein Rollout ohne definierten Rückweg ist eine Wette, kein Plan.
Nach dem Go: Übergang und Stabilisierung
Industrialisieren statt hochskalieren. Die Pilotinfrastruktur wird durch die produktionsreife Plattform ersetzt, nicht einfach hochskaliert: Evaluations-Suite in die Deployment-Pipeline, Monitoring und Alarmierung nach Betriebsstandard, Ratenbegrenzung und Budget-Alarme aktiv, Zugriffe und Protokollierung nach Sicherheits-Checkliste. Die Kosten je Einheit werden im Zielvolumen erneut gemessen: Skaleneffekte und Lastspitzen verschieben die Pilotwerte.
Geordnete Übergabe. Das Projektteam übergibt an den Service Owner mit vollständiger Dokumentation: Modellkarte, Architekturentscheidungen, bekannte Grenzen und offene Risiken, Runbook für Betrieb und Vorfälle, Kontakte der Fachseite. Die Erfolgskriterien werden in das laufende Reporting überführt (siehe Kapitel D1 und D4).
Hypercare-Phase einplanen. Die ersten 4 bis 6 Wochen nach dem Rollout sind eine definierte Stabilisierungsphase mit erhöhter Betreuung: das Entwicklungsteam bleibt anteilig verfügbar, Support-Wege sind verkürzt, Qualitäts- und Kostenmetriken werden engmaschig beobachtet, Nutzerfeedback wird aktiv eingesammelt statt abgewartet. Die Hypercare-Phase endet mit einem definierten Kriterium (z. B. zwei Wochen stabil innerhalb der Serviceziele), nicht mit einem Datum allein; danach gilt der reguläre Betrieb (Phase Operate, siehe Kapitel C1).
Checkliste: Vom Piloten zur Produktion
Die Checkliste begleitet den gesamten Weg dieses Kapitels, vom Pilotdesign bis zur Hypercare-Phase:
- Pilot als Produktionsvorstufe aufgesetzt (Designtabelle oben), nicht als Demo
- Erfolgskriterium und Baseline vor Pilotstart festgelegt
- Ursachenanalyse für gescheiterte Vorgängerpiloten ausgewertet
- Skalierungskriterien in allen drei Dimensionen geprüft
- Go/No-Go-Checkliste ausgefüllt und Entscheidung dokumentiert
- Rollout-Strategie gewählt und begründet; Rückweg definiert
- Service Owner und Support-Struktur vor dem Rollout benannt
- Pilotinfrastruktur auf produktionsreife Plattform überführt; Kosten je Einheit im Zielvolumen erneut gemessen
- Übergabedokumentation vollständig (Modellkarte, Runbook, offene Risiken)
- Hypercare-Phase mit Endekriterium eingeplant
- Erfolgskriterien in das laufende Reporting überführt