KI verstärkt das Delivery-System: Warum schnelle KI eine schwache Umsetzung nicht reparieren kann

KI kann unter gewissen Umständen die Durchlaufzeit einer Aufgabe verkürzen. Sie kann zum Beispiel Code vorschlagen, Testfälle vorbereiten, Anforderungen strukturieren, Dokumentation erzeugen, Präsentationen erstellen und vieles mehr. Das ist durchaus nützlich, kann jedoch unter gewissen Umständen die Wartezeiten auf einer anderen Ebenen verschieben, dadurch dass Aufgaben schneller erledigt werden können. Dafür müssen wir ein wenig genauer und die Delivery ansehen.

Delivery entsteht nicht an einem einzelnen Arbeitsplatz, sondern in einem System aus Entscheidungen, Abhängigkeiten, Warteschlangen, Qualitätsprüfungen, Plattformen, Daten und Feedback. Wird nur ein Teil dieses Systems schneller, verschiebt sich dieser Engpass. Mehr Output kommt früher an der nächsten Station an, wo es dann wartet auf Review, Test, Security, Deployment oder eine fachliche Entscheidung.

Deshalb sollte beim Einsatz von KI Wert gelegt werden, herauszufinden wie KI den Arbeitsfluss von einer Idee bis zu einem überprüfbaren Kundennutzen verändert und wohin neue Bottlenecks entstehen, welche die Durchlaufzeit trotz schnellerer Umsetzung abbremsen könnten.

Die Systemthese: KI ist ein Verstärker

Der DORA-Bericht 2025 beschreibt KI als Verstärker bestehender Stärken und Schwächen. Die Kernaussage ist wichtig, weil sie den Blick vom Tool auf das Arbeitssystem lenkt. Eine Organisation mit klaren Zielen, kleinen Arbeitspaketen, Qualitätsmechanismen, guten internen Plattformen und kurzen Feedbackschleifen kann zusätzliche Geschwindigkeit in qualitativen und wertvollen Ergebnisse übersetzen. Wo jedoch Prioritäten unklar, Übergaben langsam oder Qualitätsprüfungen fragil sind, macht diese zusätzliche erhaltene Umsetzungsgeschwindigkeit andere Probleme deutlich sichtbarer und dringlicher.

Als Forschungsbasis nennt DORA mehr als 100 Stunden qualitative Daten und Befragungsantworten von fast 5.000 Technologie-Fachkräften. Die veröffentlichten Ergebnisse beschreiben statistische Zusammenhänge, Modelle und qualitative Muster. Sie beweisen jedoch nicht, dass jede Organisation dieselbe Wirkung erlebt oder dass eine einzelne Maßnahme allein ein bestimmtes Ergebnis verursacht.

Genau diese Grenze ist für die Praxis hilfreich, da diese verhindert, dass automatisch zwei falsche Schlüsse daraus gezogen werden und zwar: „KI steigert automatisch die Produktivität“ noch „KI macht Delivery automatisch instabil“.

Lokaler Aufgabengewinn ist noch kein End-to-End-Wert

Ein lokaler Gewinn ist leicht zu sehen. Ein Entwurf ist in einer Stunde statt in einem Tag fertig. Eine Codeänderung entsteht schneller. Eine Analyse umfasst mehr Varianten. Das sind reale Beobachtungen, sofern sie im eigenen Kontext gemessen werden. Daraus folgt jedoch noch nicht, dass Kund:innen früher einen Nutzen erhalten.

Zwischen lokalem Output und Wert liegen mindestens vier Prüfungen:

1. Ist die Arbeit richtig? Löst sie ein relevantes Kunden- oder Geschäftsproblem?

2. Ist sie integrierbar? Passt sie zu Architektur, Daten, Prozessen und anderen laufenden Änderungen?

3. Ist sie sicher betreibbar? Besteht sie Test, Security, Compliance und Deployment?

4. Lernen wir aus der Nutzung? Erkennen wir nach der Auslieferung, ob der erwartete Outcome eintritt?

Wenn eine dieser Prüfungen langsam oder unklar ist, beschleunigt KI zunächst die Ankunft an diesem Engpass. Das System liefert nicht automatisch schneller, sondern erzeugt früher mehr Arbeit an diesen Engpässen.

Mehr Output kann WIP und Warteschlangen vergrößern

Der einfachste Systemfehler ist, KI-Ausstoß wie zusätzliche Kapazität zu behandeln. Wenn Teams mehr beginnen, ohne ihre Abschlusskapazität zu erhöhen, steigt Work in Progress. Dann konkurrieren mehr Änderungen um dieselben Reviews, Testumgebungen, Fachentscheidungen und Releases.

Das zeigt sich nicht nur in einem längeren sichtbaren Backlog, sonder auch durch Typische Signale:

• Pull Requests oder fachliche Entwürfe "altern", bevor jemand sie prüft.

• Blockierte Arbeit wird parallel durch neue Arbeit ersetzt.

• Abhängigkeiten werden später entdeckt, weil mehr Pakete gleichzeitig unterwegs sind.

• Kontextwechsel nehmen zu, obwohl einzelne Aufgaben schneller starten.

• Entscheidungen bündeln sich bei wenigen Rollen oder Gremien.

• Fertige Teilstücke warten auf ein gemeinsames Release oder eine Datenfreigabe.

Eine lokale Zeitersparnis kann deshalb im Gesamtsystem als zusätzliche Wartezeit erscheinen. Das soll nicht heißen, dass KI schlecht ist. Dies soll nur Ersichtlich machen, dass der Einsatz von KI auch eine Änderungen der Arbeitsprozesse, Organisationsaufgaben etc. berücksichtigen muss.

Bevor ein Team mehr KI-unterstützte Arbeit startet, sollte es sichtbar machen, wie viel Arbeit bereits im System liegt, wie alt sie ist und worauf sie wartet. WIP-Limits, explizite Pull-Regeln und kleinere Pakete begrenzen nicht die Ambition. Sie schützen die Fähigkeit, begonnene Arbeit tatsächlich abzuschließen und aus ihr zu lernen.

Test, Security und Deployment werden Teil des Engpasses

KI kann Implementierung beschleunigen. Sie kann auch mehr Varianten, Abhängigkeiten und zu prüfende Änderungen erzeugen. Wenn Testautomatisierung unzuverlässig ist, Sicherheitsprüfungen spät erfolgen oder Deployments selten und riskant sind, wächst hinter der schnelleren Erstellung ein Kontrollstau.

Zu diesen Sicherheitsnetzen gehören:

• kleine, nachvollziehbare Änderungen statt großer KI-generierter Pakete,

• Versionierung von Code, Konfiguration und relevanten Prompts,

• schnelle, verlässliche automatisierte Tests,

• klare Verantwortlichkeit für Review und Freigabe,

• reproduzierbare Security- und Compliance-Prüfungen,

• eine Deployment-Pipeline, die kleine Änderungen sicher ausliefern und zurücknehmen kann,

• sichtbare Rückarbeit statt einer bloßen Zählung erzeugter Artefakte.

Die richtige Kennzahl ist daher nicht „generierte Codezeilen“ oder „abgeschlossene KI-Tasks“. Aussagekräftiger ist die Verbindung aus Durchlaufzeit, Qualitäts- und Stabilitätssignalen, Rückarbeit und tatsächlichem Nutzungsergebnis.

Plattform und Operating Model bestimmen, ob Geschwindigkeit skaliert

Das Operating Model entscheidet zugleich, wer Prioritäten setzt, wer Risiken akzeptiert, wer über Ausnahmen entscheidet und wie Teams über Grenzen hinweg zusammenarbeiten. Ohne diese Klarheit erzeugt KI nicht weniger Koordination. Sie produziert mehr Fälle, in denen Koordination notwendig wird.

Drei Fragen machen diesen Zusammenhang konkret:

• Gibt es einen sicheren Standardpfad von einer kleinen Änderung bis zur Produktion?

• Können Teams die notwendigen Daten, Umgebungen und Entscheidungen ohne lange Ticketketten erhalten?

• Sind Verantwortung und Eskalation dort verankert, wo die Arbeit tatsächlich stattfindet?

Wenn die Antwort mehrfach Nein lautet, liegt der nächste Hebel wahrscheinlich nicht in einem weiteren KI-Tool, sondern in Plattform, Entscheidungsrechten oder Arbeitsfluss.

Ohne Feedback wird nur schneller angenommen

KI senkt die Kosten um Ideen und Varianten zu erzeugen. Dadurch steigt die Bedeutung von Feedback, damit wir verstehen ob wir auf dem richtigen Weg sind. Wenn ein Team schneller baut, aber seltener mit Nutzer:innen prüft, beschleunigt es vor allem seine Annahmen.

Gutes Feedback verbindet drei Ebenen:

1. Technisches Feedback: Ist die Änderung integrierbar, testbar, sicher und betreibbar?

2. Flow-Feedback: Wo wartet Arbeit, wo entsteht Rückarbeit und welche Abhängigkeit blockiert den Abschluss?

3. Outcome-Feedback: Ändert sich das relevante Verhalten, die Nutzung oder das Geschäftsproblem in die gewünschte Richtung?

Diese Ebenen dürfen nicht gegeneinander ausgespielt werden. Ein stabiles System ohne Kundennutzen ist nicht erfolgreich. Ein positiver Nutzungstest mit dauerhaft manuellen Risiken skaliert ebenfalls nicht. Und hoher Durchsatz bei wachsender Rückarbeit ist nur schnellerer Verbrauch von Kapazität.

Ausgewogen messen: Geschwindigkeit, Stabilität, Wert und Arbeitsfähigkeit

Eine einzelne Produktivitätskennzahl ist für KI-unterstützte Delivery zu vereinfacht und sollte unter anderem Business Impact, Delivery, Endnutzerzufriedenheit und Produktqualität berücksichtigen.

Ein kleines, entscheidungsfähiges Messbild kann enthalten:

• Wert: ein klarer Kunden- oder Geschäftsoutcome sowie das dazugehörige Nutzungssignal,

• Flow: Durchlaufzeit, Alter laufender Arbeit, WIP, Blockier- und Wartezeit,

• Qualität und Stabilität: fehlgeschlagene Änderungen, Wiederherstellungszeit, Defekte nach Auslieferung und Rückarbeit,

• Plattform und Governance: Erfolgsquote zentraler Arbeitswege, Zeit bis zu verwertbarem Feedback, dokumentierte Ausnahmen,

• Arbeitsfähigkeit: wahrgenommene Friktion, Überlastung, Klarheit und Lernfähigkeit im Team.

Nicht jede Organisation braucht alle Kennzahlen dauerhaft. Entscheidend ist, dass jede Messung an eine Entscheidung gebunden ist. Wenn sich ein Signal verschlechtert, muss klar sein, wer den Einsatz anpasst, WIP reduziert, einen Plattformengpass priorisiert oder einen KI-Anwendungsfall stoppt.

Der AI Delivery System Check

Der folgende Check ist eine Synthese von TheRevolutionaryMind. Er ist kein von DORA validiertes Diagnoseinstrument. Er verbindet die externe DORA-Evidenz mit internen Arbeitsweisen aus Flow-, Operating-Model- und Strategiepraxis.

Der Check soll keine Reifegradbewertung produzieren. Sein Ergebnis ist eine priorisierte Entscheidung: Welcher eine Systemengpass muss als Nächstes verändert werden, damit lokale KI-Geschwindigkeit in verlässlichen Wert übersetzt werden kann?

Konkrete Konsequenz: Erst das System sichtbar machen, dann beschleunigen

Ein pragmatischer Einstieg in KI braucht kein großes Transformationsprogramm, aber eine Schrittweise Herantastung und ein agiles Vorgehen:

1. Wählen Sie einen konkreten KI-unterstützten Arbeitsweg von der Idee bis zur Nutzung.

2. Definieren Sie den erwarteten Outcome und eine Qualitätsgrenze.

3. Visualisieren Sie alle Stationen, Warteschlangen und Entscheidungsrechte.

4. Messen Sie wenige Wochen lang End-to-End-Flow, Rückarbeit und Feedback – nicht nur lokale Bearbeitungszeit.

5. Entscheiden Sie danach, ob das KI-Tool, der Arbeitsfluss, die Plattform oder das Operating Model der nächste Hebel ist.

Damit bleibt KI ein Mittel zur Verbesserung. Sie wird nicht zum Ersatz für Priorisierung, Systemdesign oder Führung.

Abgrenzung zu bestehenden Artikeln

Dieser Artikel ergänzt drei bereits veröffentlichte Perspektiven:

• KI-Piloten steuern klärt Kriterien, Human Checkpoints und Entscheidungen vor Anpassung oder Skalierung eines konkreten Piloten.

• Kanban-Metriken verstehen vertieft Messgrößen für den Arbeitsfluss.

• Was ist Outcome Based Management? fokussiert die Steuerung über gewünschte Wirkung statt Aktivität.

Die neue Perspektive verbindet diese Ebenen für einen speziellen Moment: KI erhöht die lokale Produktionsgeschwindigkeit, während das Delivery-System als Ganzes unverändert bleibt.

Fazit

KI repariert keine unklare Priorisierung, keine überlastete Review-Stufe und keine Deployment-Pipeline. Sie kann diese Schwächen verstärken, weil sie mehr Arbeit schneller in das bestehende System einspeist.

Der sinnvolle nächste Schritt ist deshalb nicht automatisch mehr Automatisierung. Er ist ein belastbarer Blick auf Outcome, Flow, Qualität, Plattform und Feedback. Erst wenn diese Ebenen gemeinsam funktionieren, wird lokale Geschwindigkeit zu besserer Delivery.

Wenn Sie prüfen möchten, wo KI in Ihrem Delivery-System Wert erzeugt und wo sie nur den nächsten Engpass füllt, bietet unser Consulting für Strategie und Organisation einen passenden Rahmen für Diagnose, Priorisierung und konkrete Umsetzung.

Quellen

1. DORA: State of AI-assisted Software Development 2025, abgerufen am 25. August 2026.

2. DORA: DORA AI Capabilities Model, zuletzt aktualisiert am 25. November 2025.

3. DORA: Fragen zum AI Capabilities Model, abgerufen am 25. August 2026.

4. DORA: Forschungsfragen 2025, zuletzt aktualisiert am 22. September 2025.

5. DORA: Platform Engineering Capability, zuletzt aktualisiert am 12. Januar 2026.

6. Google Cloud DORA: Announcing the 2025 DORA Report, 23. September 2025.

7. DORA: Balancing AI tensions: Moving from AI adoption to effective SDLC use, 10. März 2026.

8. Eurostat: Digitalisation in Europe – 2026 edition, abgerufen am 25. August 2026.

Evidenzgrenze: DORA untersucht überwiegend technologiebezogene Arbeit und veröffentlicht Beziehungen, Modelle und Empfehlungen. Die Ergebnisse sind kein universeller Kausalnachweis. Die Eurostat-Zahlen belegen Verbreitung von KI in Unternehmen, nicht Delivery-Leistung, Produktivität oder Wertwirkung.