Umsetzen: vom Quick Win zum Projekt

Der Workshop ist vorbei. Auf dem Tisch liegen drei bewertete Fälle, jeder mit einem Namen, einem Termin und einem Zielwert.

Und ab jetzt gilt eine Regel, die in keiner Bewertung steht:

Deine Aufgabe konkurriert nicht mit anderen KI-Vorhaben. Sie konkurriert mit dem Tagesgeschäft der Person, der du sie gegeben hast.

Diese Lektion handelt davon, wie ein bewerteter Fall ein laufendes Vorhaben wird — und woran das in der Praxis scheitert.

Der Engpass ist Zeit, nicht Geld

Die Bundesnetzagentur hat 808 Unternehmen gefragt, was den KI-Einsatz einschränkt. Die Rangfolge ist der eigentliche Befund:

*Erhebung Oktober bis Dezember 2024.*

Zeit steht mit weitem Abstand vor Geld und Technik. Eine ähnliche Rangfolge zeigt eine Bitkom-Befragung von 604 Unternehmen ab 20 Beschäftigten aus dem Frühjahr 2026 — dort nennen 66 % zu wenig Zeit, 48 % begrenzte finanzielle Mittel und 40 % lange Entscheidungsprozesse. Diese Frage bezieht sich allerdings auf die Digitalisierung insgesamt, nicht auf KI im engeren Sinne; sie stützt den Befund, sie ersetzt ihn nicht.

Daraus folgt eine harte Regel für alles, was du nach dem Workshop schreibst:

Ein Fahrplan, der freie Kapazität unterstellt, ist schon falsch, wenn er gedruckt wird.

Konkret heißt das: Jeder Schritt braucht eine Person und ein Datum — nicht eine Abteilung und ein Quartal. Und wenn diese Person 20 % ihrer Zeit hat, steht das im Plan, nicht die Annahme, sie hätte 100.

Der praktische Test: Nimm deinen Fahrplan und rechne die Personentage je Woche zusammen. Wenn irgendwo mehr als ein Tag pro Woche und Person steht, ist es kein Plan, sondern eine Hoffnung.

Die Schätzung aus dem Workshop ist eine Hypothese

Der zweite Punkt ist unbequemer, weil er die eigene Arbeit betrifft. Alles, was ihr im Workshop geschätzt habt — Zeitersparnis, Fallzahl, Aufwand — ist eine Hypothese. Keine Messung.

Wie weit beides auseinandergehen kann, zeigt ein randomisiertes Experiment der Organisation METR. 16 erfahrene Entwickler bearbeiteten 246 reale Aufgaben, teils mit, teils ohne KI-Werkzeuge.

Die Autoren schränken die Übertragbarkeit auf andere Aufgaben ausdrücklich ein — das ist keine Aussage über KI im Allgemeinen, und diese Lektion macht auch keine daraus. Für die Umsetzung zählt allein die Folgerung, und die ist hart genug: Die gefühlte Ersparnis und die gemessene sind zwei verschiedene Dinge, und der Unterschied kann das Vorzeichen wechseln.

Daraus folgt der wichtigste Handgriff dieser Lektion:

Miss den Ausgangswert, bevor du anfängst

Wie lange dauert der Vorgang heute wirklich? Wie viele Fälle sind es pro Woche? Wie viele davon gehen zurück?

Zähl es eine Woche lang mit. Nicht schätzen, nicht aus dem System ableiten — mitzählen. Eine Strichliste reicht.

Der Grund ist banal und wird trotzdem ständig übersehen: Nach dem Start kannst du den Ausgangswert nie wieder erheben. Der alte Prozess ist dann weg. Und ohne Ausgangswert ist in Monat sechs nicht mehr zu klären, ob sich etwas verbessert hat — es bleibt bei Eindrücken, und Eindrücke sind, wie METR zeigt, unzuverlässig.

Die fünf Stufen

Ein bewerteter Fall wird nicht in einem Schritt produktiv. Er durchläuft fünf Stufen, und jede beantwortet genau eine Frage:

Der Wert dieser Stufen liegt nicht in der Bürokratie. Er liegt darin, dass jede Stufe eine Frage hat, die man beantworten kann — und damit einen Punkt, an dem man aufhören darf, ohne dass es als Scheitern gilt.

Ein Proof of Concept ist kein Pilot

Diese Verwechslung ist der teuerste Fehler der ganzen Umsetzung, und sie passiert fast immer aus guten Gründen.

Der Proof of Concept läuft. Die Ergebnisse sehen gut aus. Jemand zeigt sie in der Geschäftsführung, alle sind zufrieden, und der nächste Beschluss lautet: ausrollen.

Übersprungen wurde die einzige Stufe, die etwas über euer Unternehmen aussagt.

Ein Proof of Concept beantwortet, ob ein Verfahren mit ausgewählten Daten funktioniert. Er sagt nichts darüber,

• ob die Kollegin es im Tagesgeschäft tatsächlich benutzt,
• ob die Daten auch am Monatsende so aussehen wie im Test,
• ob der Ausnahmefall, der jeden Dienstag vorkommt, sauber durchläuft,
• ob die Bearbeitungszeit sinkt, wenn nebenher das Telefon klingelt.

Ein Pilot kostet vier bis acht Wochen. Ein gescheiterter Rollout kostet das Vielfache — und, schlimmer, er verbrennt die Bereitschaft für den nächsten Fall.

Kein Rollout ohne Pilot. Und der Pilot ist erst bestanden, wenn der Zielwert gemessen wurde — nicht, wenn alle zufrieden wirken.

Wie ein Pilot geschnitten wird

Der häufigste Fehler ist ein zu großer Pilot. Die brauchbare Größe:

• Ein Team, nicht die Abteilung.
• Ein Vorgang, nicht der ganze Prozess.
• Vier Wochen, nicht „bis es läuft".
• Ein gemessener Zielwert, kein Stimmungsbild.

Ein Pilot, der scheitert, ist ein billiger Erkenntnisgewinn. Ein Pilot, der so groß ist, dass er nicht scheitern darf, ist kein Pilot mehr.

Was dokumentiert wird — und warum

Zwei Dinge werden mitgeschrieben. Beide klingen nach Bürokratie und sind es nicht.

Der Steckbrief

Ziel, Kennzahl, Verantwortlicher, Sponsor, Umfang. Eine Seite, nicht zehn.

Sein Zweck ist nicht die Ablage. Er ist die Antwort auf die Frage, die zuverlässig in Monat vier gestellt wird: *Warum machen wir das eigentlich?* Wer sie dann nicht in zwei Sätzen beantworten kann, verliert das Vorhaben — nicht an einen Einwand, sondern an Erschöpfung.

Ein Steckbrief, den Sponsor und Prozesseigentümer gegengezeichnet haben, hat einen zweiten Nutzen: Wer sich nicht festlegen will, zeigt es an dieser Stelle. Früh statt spät.

Das Entscheidungs-Log

Das ist der unterschätzte Teil. In jedem Vorhaben werden Entscheidungen getroffen, die später niemand mehr erklären kann:

• Warum sind wir bei diesem Anbieter gelandet?
• Warum haben wir die Rechnungsprüfung ausgeklammert?
• Warum läuft das nicht über die Bestandsschnittstelle?

Notiere je Entscheidung drei Zeilen: was entschieden wurde, wann — und warum, mit dem, was ihr *damals* wusstet.

Der Grund dafür ist nicht Ordnungsliebe. Wenn sich in Monat sechs herausstellt, dass eine Entscheidung falsch war, ist die entscheidende Frage nicht, wer sich geirrt hat. Sie lautet:

Was wussten wir damals nicht?

Nur diese Frage macht ein Team beim nächsten Mal besser. Und sie lässt sich ohne aufgeschriebene Begründung nicht beantworten — rückblickend erscheint jede Entscheidung entweder offensichtlich richtig oder offensichtlich dumm.

Das Abbruchkriterium

Jetzt der Teil, den fast alle auslassen.

Ein Abbruchkriterium ist ein Satz, den ihr aufschreibt, bevor es losgeht: Woran erkennen wir, dass wir aufhören sollten — und wer darf das entscheiden?

Warum das vorher passieren muss, hat einen Namen. Hal Arkes und Catherine Blumer haben 1985 beschrieben, was seither als Sunk-Cost-Effekt bekannt ist: Menschen führen etwas weiter, weil sie bereits investiert haben — obwohl die bereits ausgegebenen Mittel für die Frage, ob sich die Fortsetzung lohnt, keine Rolle spielen.

Im Projekt klingt das so: *„Wir haben schon 80.000 Euro drin."*

Das ist kein Argument. Die 80.000 sind weg, egal wie ihr entscheidet. Die einzig relevante Frage lautet, ob die *nächsten* Ausgaben sich lohnen.

Genau deshalb kann ein Abbruchkriterium nicht nachträglich formuliert werden. Wer mitten im Projekt anfängt zu überlegen, wann man aufhören sollte, überlegt bereits unter dem Einfluss des Investierten.

Woran man ein brauchbares erkennt

Nicht brauchbar: „Wenn es nicht funktioniert."

Brauchbar: „Wenn die Trefferquote nach acht Wochen Pilot unter 85 % liegt, stellen wir ein. Das entscheidet die Prozesseigentümerin."

Drei Eigenschaften: eine prüfbare Größe, eine Frist, und eine Person, die entscheiden darf.

Abbrechen ist nicht verschieben

Ein Fall, dessen Datengrundlage noch fehlt, wird verschoben — mit einer Aufgabe, wer die Grundlage schafft. Ein Fall, dessen Nutzen sich im Pilot nicht gezeigt hat, wird abgebrochen.

Beides ist ein Ergebnis, kein Scheitern. Und beides sollte im Entscheidungs-Log stehen, weil die Frage sonst in acht Monaten wieder auf den Tisch kommt.

Die ersten vier Wochen, ganz konkret

Woche 1 — Den Ausgangswert messen. Eine Woche mitzählen: Fallzahl, Zeit je Fall, Fehler oder Rückläufer. Die wichtigste Woche des ganzen Vorhabens, und sie kostet fast nichts.

Woche 2 — Den Steckbrief schreiben und gegenzeichnen lassen. Vom Sponsor und vom Prozesseigentümer. Eine Seite.

Woche 3 — Den Umfang schneiden. Was gehört in den Pilot, was ausdrücklich nicht? Der Ausschluss ist wichtiger als der Einschluss: „Rechnungen über 10.000 € laufen weiter manuell" ist eine bessere Festlegung als jede Absichtserklärung.

Woche 4 — Den Weg festlegen und ins Log schreiben. Anbieter oder interne Umsetzung — mit Begründung.

Und dann: 15 Minuten pro Woche

Ein wöchentlicher Termin, nicht länger als eine Viertelstunde. Drei Fragen:

1. Was ist seit letzter Woche passiert?
2. Was blockiert?
3. Sind wir noch im Zielwert?

Fünfzehn Minuten pro Woche sind das, was ein Vorhaben gegen das Tagesgeschäft am Leben hält. Ein Monatstermin ist zu spät — er bemerkt Stillstand erst, wenn er vier Wochen alt ist, und dann ist der Rückstand nicht mehr aufzuholen.

Für Berater:innen

Hier endet in den meisten Mandaten die Zusammenarbeit — und genau hier entscheidet sich, ob das Vorhaben etwas wird. Die Branche kennt diese Lücke übrigens genau: Anbieter von KI-Potenzialworkshops benennen den Abbruch nach dem Termin auf ihren eigenen Leistungsseiten offen und bearbeiten ihn mit Nachfassterminen, Retainer-Modellen und Fahrplänen.

Zwei Dinge, die sich bewährt haben:

Übergib an eine Person, nicht an eine Organisation. Ein Fahrplan, der an „die IT" übergeben wird, ist nicht übergeben.

Vereinbare einen Nachfasstermin, bevor du gehst. Nicht als Verkauf, sondern als Teil der Übergabe: vier Wochen, 30 Minuten, Blick auf den Steckbrief und den Zielwert. Wer den Termin nicht will, hätte den Fahrplan auch nicht umgesetzt.

Für interne KI-Verantwortliche

Deine Schwierigkeit ist die Zeit — deine eigene und die der anderen. Drei Dinge helfen:

Nimm dir das erste Vorhaben klein. Ein Fall, ein Team, vier Wochen. Der Nachweis, dass etwas funktioniert hat, ist mehr wert als ein ambitionierter Plan.

Schreib die 20 % hin. Wenn dein Prozesseigentümer einen Tag pro Woche hat, plane einen Tag pro Woche. Ein Plan, der stillschweigend mehr unterstellt, macht dich in Woche drei zum Mahner — und das ist die Rolle, in der man Vorhaben verliert.

Miss den Ausgangswert selbst, wenn es sonst niemand tut. Eine Strichliste über eine Woche ist der billigste Hebel, den du in diesem ganzen Kurs bekommst.

Häufige Fragen

Können wir den Proof of Concept nicht überspringen, wenn der Anbieter das Verfahren schon woanders im Einsatz hat? Ja — dann startet ihr direkt mit dem Pilot. Der PoC beantwortet die technische Frage; wenn die anderswo beantwortet ist, ist er verzichtbar. Der Pilot ist es nicht, denn er beantwortet eine Frage über euer Haus.

Wie lange darf ein Pilot dauern? Vier bis acht Wochen. Länger heißt fast immer, dass der Umfang zu groß geschnitten wurde. Ein Pilot, der ein halbes Jahr läuft, ist ein Projekt ohne Entscheidungspunkt.

Was, wenn der Zielwert im Pilot knapp verfehlt wird? Dann greift das Abbruchkriterium — sofern ihr eines formuliert habt. Wenn nicht, führt ihr jetzt eine Diskussion unter dem Einfluss des bereits Investierten, und die geht erfahrungsgemäß zugunsten der Fortsetzung aus.

Wer schreibt das Entscheidungs-Log? Wer die Entscheidung trifft, in drei Zeilen, am selben Tag. Nicht der Projektleiter im Nachhinein — dann fehlt genau das, was den Wert ausmacht: der Wissensstand von damals.

Reicht nicht ein Ticketsystem? Für Aufgaben ja. Für Entscheidungen nein: Ein Ticket beschreibt, was zu tun ist, nicht, warum man sich so und nicht anders entschieden hat.

Quellen

• **Bundesnetzagentur**, „KI in Unternehmen: Einsatz, Ressourcen und Herausforderungen"; Befragung von 808 Unternehmen, Erhebung 14.10.–06.12.2024 — Rangfolge der einschränkenden Faktoren. — Erhebung 14
• **Bitkom e. V.**, telefonische Befragung von 604 Unternehmen ab 20 Beschäftigten, Anfang 2026 — die Frage nach internen Hürden bezieht sich auf die Digitalisierung insgesamt. — 2026 — die Frage nach internen Hürden bezieht sich auf die Digitalisierung insgesamt
• **METR**, „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"; randomisiertes kontrolliertes Experiment mit 16 erfahrenen Entwicklern über 246 reale Aufgaben. Die Autoren schränken die Übertragbarkeit ausdrücklich ein. — 2025 AI on Experienced Open-Source Developer Productivity"
• **Hal R. Arkes, Catherine Blumer**, „The Psychology of Sunk Cost", *Organizational Behavior and Human Decision Processes* 35 (1985). — 1985)
• **Selbstauskünfte von Anbietern von KI-Potenzialworkshops** zur Nachbetreuung — Leistungsseiten, keine Erhebung. — Erhebung