(KI) Automatisierung ohne Beschleunigung

Ein Software-Team setzt einen KI-Programmierassistenten ein, und seine Leistung verdoppelt sich. Die Pull-Requests häufen sich. Die Anzahl der Commits pro Entwickler steigt. Das Entwickler-Dashboard leuchtet in einem erfreulichen Grünton. Sechs Monate später haben genauso viele Funktionen die Kunden erreicht wie im Jahr zuvor. Die Arbeit ging schneller von der Hand. Das Produkt jedoch nicht.

Hier geht es nicht um überbewertete KI. Der Assistent hat genau das gehalten, was er versprochen hat. Es geht darum, wo Geschwindigkeit in ein System einfließt und wo sie es wieder verlässt – und warum dies selten derselbe Ort ist. KI wird sehr viele träge Organisationen in genau der einen Sache schneller machen, die nie ihr Problem war.

Die Geschichte, die jeder erzählt

Alle reden davon, dass Ingenieure den Engpass darstellen. Natürlich tun sie das. Sie sind sichtbar, teuer und ständig im Rückstand. Wenn also eine Technologie auf den Markt kommt, mit der jeder Ingenieur zwei- oder dreimal so viel Code produzieren kann, lautet die naheliegende (aber falsche) Schlussfolgerung, dass auch die dreifache Leistung bei den Kunden ankommt.

Die Schlussfolgerung ist falsch, und zwar in einer Weise, die sich seit Jahrzehnten messen lässt. Die technische Leistung ist so gut wie nie der limitierende Faktor dafür, wie schnell validierte Funktionen den Kunden erreichen. Sie ist nur eine Stufe in einer viel längeren Kette, und die Beschleunigung einer einzelnen Stufe in dieser Kette bringt der Kette insgesamt nichts, es sei denn, diese Stufe war die langsamste. In den meisten Organisationen war dies nicht der Fall.

Das ist kein Problem der Werkzeuge, sondern ein Problem des Arbeitsablaufs. Und Probleme im Arbeitsablauf lassen sich nicht durch schnellere Werkzeuge lösen. Sie lassen sich nur durch eine andere Sichtweise auf das System lösen.

Was fließt eigentlich durch das System?

Beginnen wir mit einer präzisen Frage: Was ist das Ergebnis einer Produktentwicklungsorganisation? Die intuitive Antwort lautet: Artefakte. Code, Zeichnungen, Anforderungen, Testberichte. Doch nicht in den Artefakten selbst wird Wert geschaffen. Wert entsteht, wenn die Unsicherheit darüber, was funktionieren wird, verringert wird und dieses Wissen in eine umsetzbare Entscheidung umgewandelt wird. Die Produktentwicklung ist eine Maschine, die validierte Entscheidungen hervorbringt. Die Artefakte sind lediglich das Medium, das diese speichert und weiterleitet.

Die Produktentwicklung ist eine Maschine, die fundierte Entscheidungen hervorbringt.

Diese neue Sichtweise verändert die Definition dessen, was als Fortschritt gilt. Eine Codezeile, die noch nicht integriert wurde und deren Funktionsfähigkeit noch nicht nachgewiesen ist, hat keine Unsicherheit beseitigt. Sie ist keine getroffene Entscheidung. Sie ist lediglich Bestandsmaterial.

In einer Fabrik ist der Lagerbestand sichtbar. Man kann durch die Halle gehen und sieht halbfertige Autos, die zwischen den Arbeitsstationen gestapelt sind. In der Branche nennt man das in Arbeit, WIP und ein Jahrhundert Operations Research haben den Herstellern beigebracht, sich davor zu fürchten. Bei der Produktentwicklung ist es genauso, nur dass man es nicht sehen kann. Ungeklärte Entscheidungen, nur halbwegs verstandene Entwürfe, geschriebener Code, dessen Funktionsfähigkeit im integrierten System noch nicht nachgewiesen ist: Das ist „Design in Progress“, kurz DIP. Es handelt sich um echte Arbeit, die im System schlummert, und da sie keine physische Form hat, lässt sich ihre Anhäufung leicht übersehen, bis sie sich als verspäteter Integrationsfehler, als Welle von Nacharbeiten oder als nicht eingehaltene Verpflichtung bemerkbar macht.

Hier liegt der Haken. Ein KI-Assistent ist in erster Linie eine Maschine, die DIP mit hoher Geschwindigkeit erzeugt.

Der Mechanismus: Warteschlangen schneller abarbeiten

A Wertstrom besteht aus drei Komponenten: Phasen, in denen spezialisierte Arbeiten stattfinden, Warteschlangen, in denen Aufgaben warten, und Übergaben, bei denen Aufgaben und Verantwortung zwischen den Phasen übertragen werden. Der Großteil der Zeit zwischen einer guten Idee und einer ausgelieferten Funktion wird nicht in den Phasen verbracht, sondern in den Warteschlangen. Die Aufgaben liegen dort und warten darauf, dass in der nächsten Phase Kapazität frei wird.

Donald Reinertsen, dessen Grundsätze des Produktentwicklungsablaufs ist so etwas wie der grundlegende Text in diesem Bereich – um es ganz offen zu sagen: Nur wenige Entwickler sind sich bewusst, dass Warteschlangen der wichtigste Einzelfaktor für eine schlechte Leistung in der Produktentwicklung sind. Arbeit, die zwischen den einzelnen Phasen wartet, unsichtbar, weil sie keine physische Form hat, und still und leise das Tempo für alles vorgibt.

Warteschlangen werden aus drei strukturellen Gründen immer länger, und es lohnt sich, diese zu nennen, da KI alle drei betrifft. Variabilität, da Aufträge ungleichmäßig eingehen und abgearbeitet werden, sodass es selbst in einem System, das nicht ausgelastet ist, zu Wartezeiten kommt. Hohe Auslastung, denn sobald eine Phase ihre volle Kapazität erreicht, führen schon kleine Störungen zu unverhältnismäßig großen Verzögerungen. Und große Chargen, denn wenn die Arbeitslast in Spitzen auftritt, schwankt die nächste Stufe zwischen Leerlauf und Überlastung.

KI-Automatisierung geht nach hinten los

Fügen Sie nun einen KI-Assistenten in die erste Stufe dieses Arbeitsablaufs ein. Die Leistung der Entwicklung steigt sprunghaft an. Was passiert mit der Warteschlange zwischen der Entwicklung und dem, was als Nächstes im Velocity Loop, Integration, Verifizierung, Überprüfung, Zertifizierung, Bereitstellung? Es wächst. Immer schneller. Der Assistent hat keine Einschränkung beseitigt. Er hat eine neue geschaffen. Jetzt gelangt mehr Arbeit in die langsame Phase, in größeren Stapeln, und wartet länger darauf, abgeholt zu werden.

Der Buch veranschaulicht dies anhand eines kleinen Beispiels, das das gesamte KI-Problem vorwegnimmt. Ein ML-Team kann Modelle schneller trainieren, als das Integrationsteam sie bewerten kann. Ohne Begrenzung stauen sich die Modelle in einer Warteschlange zwischen den beiden Teams. Das schnellere Team fühlt sich produktiv. Das langsamere Team geht unter. Die End-to-End-Bereitstellung kommt nicht voran, da die Integrationsphase – die eigentliche Engstelle – genau dieselbe Kapazität hat wie zuvor. Das Einzige, was sich geändert hat, ist die Größe des vor ihr wartenden Stapels. KI ist dieses schnellere ML-Team, das auf Ihre gesamte Entwicklungsabteilung auf einmal angewendet wird.

Little’s Law lässt sich nicht verhandeln

Wenn man dennoch das Gefühl hat, dass das Ergebnis positiv ausfallen sollte, gibt es eine Gleichung, die Klarheit schafft. Littles Gesetz besagt, dass die durchschnittliche Zykluszeit dem durchschnittlichen DIP geteilt durch den durchschnittlichen Durchsatz entspricht. Lesen Sie das langsam durch, denn es ist eines der wenigen unumstößlichen Gesetze in diesem Bereich.

Der Durchsatz ist die Rate, mit der fertige, geprüfte Artikel den Produktionsstrom verlassen. Diese Rate wird durch den Engpass bestimmt, nicht davon, wie schnell die erste Stufe produzieren kann. Wenn KI die Entwicklung beschleunigt, der nachgelagerte Engpass jedoch unverändert bleibt, steigt der Durchsatz nicht. Was steigt, ist der DIP, also der Lagerbestand im System. Und wenn der DIP steigt, während der Durchsatz konstant bleibt, verlängert sich die Zykluszeit. Die Mathematik dahinter ist nicht kompliziert. Wenn man einem System Arbeit hinzufügt, ohne dessen Durchsatz zu erhöhen, dauert es länger, bis jedes Teil den Prozess durchläuft – nicht kürzer.

Ein Unternehmen, das seine Code-Produktion verdoppelt, seine Kapazitäten für Integration, Review und Bereitstellung jedoch unverändert lässt, liefert also nicht schneller aus. Es liefert im gleichen Tempo aus, wobei weitaus mehr halbfertige Arbeit die Abläufe verstopft, und jede einzelne Funktion benötigt nun länger bis zur Fertigstellung als vor der Einführung des Tools. Schnellere Eingabe, längere Durchlaufzeiten. Das ist kein Paradoxon. Das ist einfache Arithmetik.

Das Anti-Muster: Lokale Effizienz statt Durchsatz

Dieses Versagen hat einen Namen, denn Unternehmen tappen schon seit Jahren ohne die Hilfe von KI darin. Nennen wir es „Lokale Effizienz statt Durchsatz“.

Das Modell ist verlockend, weil jedes lokale Signal positiv aussieht. Die Ingenieure werden besser ausgelastet. Die Leistung pro Person steigt. Die teaminterne Zykluszeit – gemessen vom ersten Commit bis zur Übergabe – kann sich sogar verbessern. Jede Kennzahl innerhalb des Entwicklungsbereichs wird grün. Und nichts davon hat Einfluss auf die Geschwindigkeit, mit der Kunden ein funktionsfähiges Produkt erhalten, denn der Entwicklungsbereich war nie die Phase, die diese Geschwindigkeit bestimmt hat.

Der Theorie der Engpässe, das dieser gesamten Disziplin zugrunde liegt, formuliert das Prinzip schonungslos: Die langsamste Stufe bestimmt das Tempo des gesamten Ablaufs, und die Optimierung einer anderen Stufe als des Engpasses führt nicht zu einer Verbesserung der Systemleistung. Ein Team kann seine eigene Zykluszeit halbieren, ohne dass dies auch nur den geringsten Einfluss auf die End-to-End-Lieferung hat, solange der eigentliche Engpass weiter unten in der Kette unberührt bleibt. Dieselbe Logik erklärt, warum Die Wohnungsknappheit in Deutschland ist eigentlich ein Strömungsproblem: Man investiert Kapital, und wenn der Engpass bei der Genehmigungswarteschlange liegt, geht nichts voran. KI ist ein Werkzeug, mit dem sich die Durchlaufzeit jeder beliebigen Phase, auf die man sie anwendet, halbieren lässt. Wendet man sie auf einen Bereich an, der kein Engpass ist – wo sich offenbar die meisten „einfachen Erfolge“ finden –, dann hat man echtes Geld ausgegeben, um eine Zahl in die Höhe zu treiben, die keine Rolle spielt.

Richten Sie AI auf eine Nicht-Einschränkung aus, und Sie haben echtes Geld ausgegeben, um eine Zahl in die Höhe zu treiben, die keine Rolle spielt.

Es gibt ein damit zusammenhängendes Muster, auf das man achten sollte, nämlich Wassermelonen-Berichterstattung und von Marc Löffler geprägt. Außen grün, innen rot. Projekte melden einen guten Status, weil die Aktivität hoch ist und Meilensteine abgehakt werden, während der End-to-End-Ablauf blockiert ist. KI ist ein hervorragender „Wassermelonen-Motor“. Sie erzeugt eine Flut von Aktivitäten, die alle auf einem Dashboard ablesbar sind, von denen aber keine notwendigerweise dazu beiträgt, validierte Fähigkeiten schneller zum Kunden zu bringen. Das Unternehmen hat das Gefühl, schneller voranzukommen. Der Kunde spürt keinen Unterschied.

Warum sich diese Fehlinterpretation noch verschlimmern wird

Zwei Dinge machen die KI-Version dieser Falle präziser als die manuelle.

Erstens ist das Ungleichgewicht größer. Eine manuelle Produktivitätssteigerung könnte die Leistung der Entwicklungsabteilung um zehn oder zwanzig Prozent erhöhen. Ein effektiver KI-Assistent kann die Rohproduktion von Code oder Design-Artefakten um ein Vielfaches steigern. Je größer die Kluft zwischen der Ausführungsgeschwindigkeit der ersten Stufe und der Geschwindigkeit ist, mit der die nachfolgende Stufe deren Ausgabe verarbeiten kann, desto stärker wächst die Warteschlange.

Zweitens handelt es sich bei den neuen Arbeiten überproportional oft um kostspielige Projekte. Das „Flow Framework“, entwickelt von Mik Kersten in Projekt zu Produkt, unterteilt alles, was ein Team hervorbringt, in vier Kategorien: Funktionen, Fehler, Risiken und technische Schulden:

• Funktionen sind neue Werte, die der Kunde abgerufen hat.
• Mängel sind Wertverluste und der Aufwand, der dafür aufgewendet wird, etwas zu beheben, das eigentlich hätte funktionieren sollen.
• Risiko ist die Arbeit im Bereich Sicherheit und Compliance.
• Schulden ist der unsichtbare Widerstand, der sich aufstaut und schließlich die Bereitstellung von Funktionen gänzlich zum Erliegen bringt.

Kersten warnt davor, dass ein Team achtzig Prozent seiner Kapazität für Fehler und technische Schulden aufwenden kann und dennoch in seinen Tools als produktiv erscheint, da die Tools Artefakte zählen und nicht den Wert.

Die wirtschaftlichen Zusammenhänge verstehen

Code, der schnell generiert wird, ohne das Verständnis, das früher durch langsames Schreiben entstand, ist eine zuverlässige Quelle für Fehler und technische Schulden. Er muss dennoch überprüft, integriert, gesichert und gewartet werden, und ein Großteil davon birgt latente Probleme, die erst später zutage treten. KI vergrößert also nicht nur die Warteschlange an der Engstelle. Sie bereichert diese Warteschlange genau um jene Arbeit, um die zu behebenden Fehler und um die zu bedienende technische Schuld, die Kapazitäten beansprucht, ohne neuen Kundennutzen zu schaffen. Die Verteilung des Arbeitsflusses verschiebt sich genau in dem Moment, in dem das Volumen sprunghaft ansteigt, hin zu den kostspieligen Kategorien.

Der eigentliche Kernpunkt ist wirtschaftlicher Natur. Die Produktentwicklung ist die Steuerung wirtschaftlicher Risiken unter Unsicherheit. Das Kapital bleibt so lange einem Risiko ausgesetzt, bis feststeht, ob das Vorhaben funktioniert, und das Ziel besteht darin, diese Unsicherheit schnell und nachhaltig zu verringern, damit das Risiko gering bleibt. Geschwindigkeit bedeutet im eigentlichen Sinne die Geschwindigkeit, mit der relevante Unsicherheit abnimmt. Die Erstellung doppelt so viel unvalidierten Codes verringert keine Unsicherheit. Der Code könnte fehlerhaft sein. Er hat die Integration oder den Kontakt mit einem echten Nutzer noch nicht überstanden. Solange dies nicht der Fall ist, handelt es sich um ein Risiko, nicht um Fortschritt. Eine schnellere Erstellung des Codes führt zu einer schnelleren Risikoentstehung. Das ist das Gegenteil von „Velocity“, das sich nur als „Velocity“ tarnt.

Eine Diagnose, die Sie am Montag durchführen können

Es gibt eine Frage, die sich durch jedes „grüne“ Dashboard zieht, das bei der Einführung einer KI entsteht. Übernehmen Sie diese Frage und stellen Sie sie Ihrem eigenen Unternehmen, bevor der nächste Vertrag über ein neues Tool unterzeichnet wird:

Wenn Ihre Entwicklungsabteilung morgen ihre Leistung verdoppeln würde, würden die fertigen, validierten Funktionen dann schneller bei den Kunden ankommen?

Wenn die ehrliche Antwort „Nein“ lautet, dann ist die Leistung der Entwicklung nicht Ihr Engpass, und eine Beschleunigung dieser Leistung wird Ihr Produkt nicht schneller voranbringen. Sie wird Ihr laufendes Design aufblähen, Ihre Zykluszeiten verlängern und Ihren Arbeitsablauf in Richtung Fehler und technischer Schulden lenken, während Ihnen jede lokale Kennzahl versichert, dass sich die Dinge verbessern.

Die Lösung besteht nicht darin, das Tool abzulehnen. Die Lösung besteht darin, zunächst die eigentliche Einschränkung zu ermitteln. Bilden Sie den Wertstrom vom Kunden aus rückwärts ab, nicht von der Entwicklung aus vorwärts. Quantifizieren Sie, wo Arbeit wartet, nicht nur, wo Arbeit stattfindet. Die Phase mit der längsten Warteschlange bestimmt Ihr Tempo, und das ist fast nie die Phase, die am geschäftigsten aussieht. Setzen Sie dann dort KI ein oder nutzen Sie sie, um die Kapazität dieser Phase zu erweitern, bevor Sie sie auf den Teil des Systems richten, der bereits schnell genug war.

Warum dies jede Führungskraft im Ingenieurwesen beunruhigen sollte

Das Verführerische an KI ist, dass sie eine falsche Investition wie die richtige erscheinen lässt. Die schnellere Produktion ist real. Die Beschleunigung ist echt. Sie findet jedoch einfach in einer Phase statt, die keinen Einfluss darauf hat, wann Ihr Kunde einen Mehrwert erhält, und die daraus resultierende Flut an laufenden Projekten verschlechtert aktiv die Kennzahl, die Ihnen tatsächlich wichtig ist, während alle Ersatzkennzahlen einen Anstieg verzeichnen.

Ein träges Unternehmen, das KI einführt, ohne seine Einschränkungen anzugehen, wird kein agiles Unternehmen. Es wird zu einem trägen Unternehmen, das unfertige Arbeit in hohem Tempo produziert: mehr Bestände zwischen den Arbeitsschritten, längere Wartezeiten am Engpass, mehr Fehler und Schulden, die es zu bewältigen gilt, und ein Dashboard, das grün leuchtet – über einem Wertstrom, der genau so schnell liefert wie zuvor. Die Arbeit wurde beschleunigt. Das Produkt jedoch nicht. Und die Kluft zwischen diesen beiden Tatsachen verbirgt sich nun hinter einer Wand aus Aktivitäten, die für alle Welt wie Fortschritt aussieht.

Die Frage war nie, wie schnell Ihre Ingenieure produzieren können. Es ging immer darum, wie schnell Ihr System Unsicherheit in eine für den Kunden nutzbare Fähigkeit umwandeln kann. KI gibt auf die erste Frage eine klare Antwort. Zur zweiten Frage schweigt sie. Vergewissern Sie sich, welche Lösung Sie kaufen.