Ihr KI-Rollout ist nicht langsam. Er ist unklar definiert.

Fragen Sie eine Führungskraft, warum ihr KI-Rollout sechs, neun oder zwölf Monate dauert, und Sie bekommen immer dieselben Antworten. “Unsere Daten sind chaotisch.” “Wir brauchen abteilungsübergreifende Zustimmung.” “So ist das nun mal bei Enterprise-IT.” Das mag alles stimmen. Fast alles davon ist auch eine Ausrede.

Denn hier ist die Wahrheit, die niemand im Projekt hören will. Die meisten langsamen KI-Rollouts sind nicht langsam. Sie sind unscoped: Niemand hat vor Projektstart festgelegt, welche Geschäftskennzahl das Projekt bewegen sollte.

Warum sich der Rollout lang anfühlt

Teams begeistern sich für eine Fähigkeit, eine Demo läuft gut, und das Projekt wird zu “genehmigt”, ohne je zu klären, ob es eine konkrete Kennzahl gibt, die sich ändern soll, wer diese Kennzahl verantwortet und was als abgeschlossen gilt. Drei Monate später steckt das Team im “lass uns auch mal schauen”-Territorium fest und erweitert den Umfang, weil es nie ein festes Ziel gab, gegen das man Nein sagen konnte.

Das ist kein langer Rollout. Es ist ein unscoped-Rollout, verkleidet als langer Rollout, und die Verkleidung funktioniert, weil alle Beteiligten die ganze Zeit über wirklich beschäftigt sind.

Keine Kennzahl zu bewegen, kein Projekt. Alles andere ist Beschäftigung.

Vier Fragen, die einen unscoped Rollout entlarven

Welche Kennzahl soll sich bewegen? Nicht “Effizienz verbessern.” Eine konkrete Kennzahl: Stunden pro Fall, Kosten pro Ticket, Conversion-Rate, Fehlerquote. Wenn im Raum niemand eine einzige Kennzahl in einem Satz benennen kann, wurde das Projekt nicht abgegrenzt, sondern nur genehmigt.

Wer verantwortet diese Kennzahl heute? Wenn aktuell niemand die Kennzahl verantwortet, die das Projekt angeblich bewegen soll, gibt es in sechs Monaten auch niemanden, der bemerkt, ob sie sich tatsächlich verändert hat. Das Projekt wird abgeschlossen, und die Verbesserung bleibt eine Behauptung statt einer Messung.

Was ist explizit ausgeschlossen? Ein Rollout ohne schriftliche “nicht das”-Liste absorbiert jede angrenzende Anfrage, die während der Umsetzung eintrifft, weil es kein Dokument gibt, auf das man verweisen kann, um Nein zu sagen. Scope Creep ist kein Disziplinversagen. Es ist das vorhersehbare Ergebnis davon, die Grenze nie schriftlich festgelegt zu haben.

Wie sieht “fertig” tatsächlich aus? “Live in Produktion” und “die Kennzahl hat sich bewegt” sind zwei unterschiedliche Definitionen von fertig, und die meisten Rollouts verwenden still die erste, während sie die zweite versprechen. Wenn das Abnahmekriterium eine funktionierende Demo statt eines gemessenen Ergebnisses ist, kann das Projekt nach jeder internen Kennzahl erfolgreich sein und trotzdem nicht das liefern, wofür es finanziert wurde.

Was sich ändert, sobald der Scope real ist

Ein sauber abgegrenzter Rollout ist nicht zwangsläufig kleiner. Er ist begrenzt. Jeder Beteiligte kann in einem Satz sagen, welche Kennzahl sich bewegt und woran man das erkennt. Anfragen außerhalb dieser Grenze werden für später festgehalten, statt den laufenden Build stillschweigend zu erweitern. Und das Projekt hat eine echte Ziellinie, statt eines sich verschiebenden Horizonts, der jedes Mal weiter wegrückt, wenn jemand in einem Meeting eine gute Idee hat.

Diese Disziplin fühlt sich am ersten Tag langsamer an, weil sie bedeutet, guten Ideen abzusagen, bevor die Arbeit überhaupt beginnt. Es ist die einzige Version von schnell, die zu einem Projekt führt, das tatsächlich endet.

The ODB Way

Bei ODB Growth beginnt jedes Engagement mit der Kennzahl, die sich bewegen muss, bevor überhaupt über Architektur oder Technologie gesprochen wird. Erst das Ziel, dann der Prozess, dann die Technologie. Kehrt man diese Reihenfolge um, entsteht ein Rollout, der in der Demo gut aussieht und nie wirklich fertig wird, weil es nie eine Ziellinie gab, die man erreichen konnte.

Korrigieren Sie den Scope, und der Zeitplan korrigiert sich meist von selbst. Nicht weil die Arbeit leichter wird, sondern weil endlich alle wissen, worauf sie hinarbeiten.