KI Projekt Erfolg messen: Referenzwert vor dem Start

KI Projekt Erfolg messen: der Referenzwert vor dem Start

Den Erfolg eines KI Projekts messen Sie, indem Sie vor dem Start einen Referenzwert festhalten: eine geschäftliche Zielgröße wie Durchlaufzeit, Fehlerquote oder gebundenes Kapital, gemessen über einen repräsentativen Zeitraum unter dokumentierten Rahmenbedingungen. Nach dem Go live vergleichen Sie dieselbe Größe unter denselben Bedingungen. Vorab vereinbarte Schwellen entscheiden über Ausbau, Anpassung oder Abschaltung.

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:

Der Referenzwert wird nachträglich rekonstruiert. Nach dem Go live ist der alte Prozess oft nicht mehr messbar, weil Systeme umgestellt oder Teams umorganisiert wurden.
Die Zielgröße wechselt während des Projekts. Wird das ursprüngliche Ziel verfehlt, rückt plötzlich eine andere Kennzahl in den Vordergrund. Das beschädigt das Vertrauen in jede spätere Bewertung.
Nur die Technik wird gemessen. Modellgenauigkeit und Antwortqualität sind wichtig für den Betrieb, ersetzen aber nicht die geschäftliche Zielgröße.
Kosten fehlen in der Rechnung. Ein fairer Vergleich bezieht laufende Kosten für Betrieb, Überwachung und Nachtraining ein. Für die Frage, ob Eigenbetrieb oder Abrechnung pro Token günstiger ist, hilft unser Kostenvergleich.
Die Datengrundlage reicht nicht. Laut den genannten Auswertungen von Deloitte sowie Capgemini und Microsoft benötigen 80 % der Initiativen vorgelagerte Investitionen in die Datenarchitektur. Der Referenzwert macht diese Lücke früh sichtbar. Das ist ein Nutzen für sich.

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äufig gestellte Fragen

Wie lange sollte der Referenzwert gemessen werden?

So lange, dass typische Schwankungen des Prozesses enthalten sind. Für Prozesse mit Saison oder Monatsabschluss bedeutet das mindestens einen vollständigen Zyklus. Liegen historische Daten im System vor, lässt sich der Referenzwert vor dem Start oft direkt daraus ableiten.

Was tun, wenn es keine verwertbaren Daten gibt?

Dann beginnt das Vorhaben mit einer strukturierten Stichprobe, etwa einer Zeiterfassung für eine festgelegte Menge an Vorgängen. Fehlen Daten grundsätzlich, ist das selbst ein wichtiger Befund: Zuerst muss die Datengrundlage verbessert werden.

Welche Rolle spielt die Modellgenauigkeit?

Sie ist eine Betriebsgröße. Wir überwachen sie, um Qualitätsverluste früh zu erkennen. Über den Erfolg des Projekts entscheidet jedoch die geschäftliche Zielgröße, die vor dem Start festgelegt wurde. Wer den Startpunkt nicht kennt, kann den Weg nicht messen. In einem Erstgespräch klären wir mit Ihnen, welche Zielgröße für Ihren Anwendungsfall trägt und welche Daten für einen belastbaren Referenzwert heute schon vorliegen.

Quellen und Verweise

Deloitte (2025) sowie Capgemini und Microsoft (2025), zitiert in nexpatch.ai/de/wissen/vergleich/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/wissen/glossar/bedarfsprognose (Bestandssenkung typisch 10 bis 50 %, Schneider Electric minus 10 % Bestand).