Vom Pilot in den Betrieb, in sechs Stufen.
Warum Piloten stehenbleiben, Datenpflege, Anbindung, Zugriff und Protokoll, Kosten, ein Verantwortlicher. Der Leitfaden, der aus einem Versuch ein System macht.
Warum KI Projekte ihren Nutzen oft nicht belegen können
Fast jedes KI Projekt wird nach einem Jahr gefragt, was es gebracht hat. Fast keines kann die Frage mit einer Zahl beantworten, die alle Beteiligten akzeptieren. Das liegt selten am Modell. Es liegt daran, dass vor dem Start niemand festgehalten hat, wie gut der Prozess ohne KI war.
Die Marktlage verschärft das Problem. Auswertungen von Deloitte sowie Capgemini und Microsoft aus 2025 zeigen, dass sich nur 6 % aller KI Vorhaben in unter einem Jahr amortisieren. Einzelne Anwendungsfälle brauchen typischerweise 3 bis 12 Monate bis zum Return, große Plattformen 2 bis 4 Jahre. Eine Studie des MIT kommt 2025 zu dem Ergebnis, dass 95 % der Piloten mit generativer KI keine messbare Rendite zeigen. Die Methodik dieser Studie ist begrenzt, die Zahl ist daher als Richtung zu lesen und nicht als exakter Wert. Die Richtung ist trotzdem deutlich: Viele Projekte können ihren Nutzen nicht nachweisen, auch wenn er möglicherweise vorhanden ist.
Ohne Referenzwert wird jede Erfolgsmessung zur Meinungsfrage. Der Fachbereich spürt Entlastung, das Controlling sieht vor allem Kosten, die IT sieht zusätzlichen Betriebsaufwand. Entscheidungen über Ausbau oder Abschaltung fallen dann nach Bauchgefühl oder nach dem Budget des nächsten Jahres.
Was ein Referenzwert ist und was nicht
Ein Referenzwert, im Englischen Baseline, beschreibt den messbaren Zustand eines Prozesses vor der Einführung von KI. Er besteht aus drei Teilen: der Zielgröße selbst, dem Zeitraum, über den sie gemessen wurde, und den Rahmenbedingungen, unter denen der Wert entstanden ist.
Ein Referenzwert ist keine Modellkennzahl. Die Genauigkeit eines Modells oder die Trefferquote einer Suche sind technische Größen. Sie helfen dem Entwicklungsteam, sagen aber wenig darüber, ob sich ein Prozess verbessert hat. Ein Prognosemodell kann genauer werden, ohne dass im Lager weniger Kapital gebunden ist. Ein Sprachmodell kann bessere Antworten formulieren, ohne dass ein Vorgang schneller abgeschlossen wird.
Ein Referenzwert ist auch kein Schätzwert aus dem Gedächtnis. Aussagen wie „die Bearbeitung dauert ungefähr einen halben Tag" sind ein Anfang, aber keine Messung. Belastbar wird der Wert erst, wenn er aus Systemdaten, aus einer Zeiterfassung oder aus einer strukturierten Stichprobe stammt.
In vier Schritten zum belastbaren Referenzwert
Wir gehen bei jedem Vorhaben in vier Schritten vor, bevor die erste Zeile Code entsteht.
1. Eine Zielgröße wählen, die das Geschäft versteht. Geeignet sind gebundenes Kapital, Durchlaufzeit, Fehlerquote oder Bearbeitungsdauer. Die Größe sollte sich in Euro, Stunden oder Fällen ausdrücken lassen, damit Geschäftsführung und Fachbereich dieselbe Sprache sprechen. Wählen Sie eine Hauptgröße und höchstens zwei Nebengrößen. Mehr verwässert die Bewertung.
2. Den heutigen Zustand über einen sinnvollen Zeitraum messen. Ein einzelner Tag oder eine besonders ruhige Woche verzerren das Bild. Der Zeitraum sollte saisonale Schwankungen, Monatsabschlüsse oder typische Spitzen abdecken, soweit sie für den Prozess relevant sind.
3. Rahmenbedingungen festhalten. Damit der Vergleich später fair bleibt, dokumentieren Sie, was sich nicht ändern darf und was sich voraussichtlich ändert: Servicegrad, Auftragsvolumen, Personalstärke, Sortiment. Steigt das Volumen nach dem Go live deutlich, muss der Vergleich das berücksichtigen.
4. Gemeinsam festlegen, ab welcher Verbesserung das Projekt als Erfolg gilt. Diese Schwelle vereinbaren Fachbereich, IT und Geschäftsführung vor dem Start. Ebenso wichtig ist die Gegenschwelle: Unterhalb welchen Werts wird das System angepasst oder abgeschaltet?
Der Aufwand dafür ist überschaubar. Oft reichen ein Workshop und ein sauberer Datenauszug aus dem ERP, dem Ticketsystem oder der Dokumentenablage.
Zielgrößen je Anwendungsfall
| Anwendungsfall | Zielgröße | Rahmenbedingung für den Vergleich |
|---|---|---|
| Bedarfsprognose | Gebundenes Kapital im Bestand | Gleicher Servicegrad, vergleichbares Sortiment |
| Dokumentenverarbeitung, etwa Eingangsrechnungen | Bearbeitungsdauer je Beleg, Anteil manueller Nacharbeit | Belegvolumen, Anteil neuer Lieferanten |
| Interner Wissensassistent | Zeit bis zur belastbaren Antwort, Anteil korrekt beantworteter Testfragen | Fester Katalog von Testfragen, gleicher Dokumentenbestand |
| Kundenservice | Bearbeitungsdauer je Anfrage, Anteil ohne Rückfrage gelöster Fälle | Anfragevolumen, Kanal, Saison |
| Angebotserstellung | Durchlaufzeit von Anfrage bis Angebot | Anzahl und Komplexität der Anfragen |
| Qualitätsprüfung in der Produktion | Fehlerschlupf, Prüfdauer je Teil | Produktmix, Prüfvorschrift |
Welche Zielgröße passt, hängt vom Anwendungsfall ab. Die folgende Übersicht zeigt Größen, die sich für typische Anwendungsfälle eignen, und die Rahmenbedingung, die Sie für einen fairen Vergleich festhalten sollten.
Die Bedarfsprognose zeigt besonders deutlich, warum die Wahl der Zielgröße entscheidet. Das belastbare Maß ist nicht die Modellgenauigkeit, sondern die Differenz im gebundenen Kapital bei gleichem Servicegrad. Gut eingestellte Bedarfsprognosen senken Bestände typischerweise um 10 bis 50 %, Schneider Electric hat den Bestand um 10 % gesenkt. Solche Werte sind nur vergleichbar, wenn der Servicegrad konstant bleibt. Wer Bestand senkt und dafür Lieferfähigkeit verliert, hat kein Kapital gespart, sondern ein Problem verschoben.
Typische Fehler bei der Erfolgsmessung
In Projekten begegnen uns immer wieder dieselben Muster:
Vom Referenzwert zur Entscheidung über den Betrieb
Ein Referenzwert ist kein Selbstzweck. Er dient drei Entscheidungen im Lebenszyklus eines KI Systems.
Nach dem Pilot zeigt die erste Messung, ob der Anwendungsfall trägt. Ein erster interner Pilot in 72 Stunden liefert noch keinen belastbaren Langzeitwert, wohl aber eine erste Richtung gegen den Referenzwert. Auf dem Weg in den produktiven Einsatz, für den wir 4 bis 10 Wochen planen, wird die Messung auf das reale Volumen ausgeweitet. Im laufenden Betrieb zeigt der Vergleich, ob die Qualität stabil bleibt oder ob sich Daten und Prozesse so verändert haben, dass ein Nachtraining nötig wird.
Deshalb gehört der Referenzwert bei uns an den Anfang und nicht in den Nachgang. Wir legen ihn vor jedem Pilot gemeinsam mit Ihnen fest und übernehmen ihn in die Berichte des Betriebs. So sprechen Fachbereich, IT und Geschäftsführung nach einem Jahr über dieselbe Zahl. Wie wir Pilot, Umsetzung und Betrieb abrechnen, beschreiben wir auf der Seite Preise.
Häufige Fragen
Quellen
- Deloitte (2025) sowie Capgemini und Microsoft (2025), zitiert in nexpatch.ai/de/blog/orpheon-vs-plattformen (6 % der KI Vorhaben amortisieren sich in unter einem Jahr, einzelne Anwendungsfälle 3 bis 12 Monate, große Plattformen 2 bis 4 Jahre, 80 % der Initiativen benötigen vorgelagerte Investitionen in Datenarchitektur).
- MIT (2025): Studie zu generativer KI in Unternehmen (95 % der Piloten ohne messbare Rendite). Die Methodik ist begrenzt, der Wert ist als Tendenz zu lesen.
- NexPatch AI: Bedarfsprognose, nexpatch.ai/de/blog/bedarfsprognose (Bestandssenkung typisch 10 bis 50 %, Schneider Electric minus 10 % Bestand).