Mit KI erst Arbeit neu gestalten, dann über Kapazität entscheiden

Schnellere Aufgaben bedeuten noch keine höhere Systemproduktivität

KI kann eine einzelne Aktivität beschleunigen, ohne das Unternehmen produktiver zu machen.

Angenommen, ein KI-Werkzeug beschleunigt die Erstellung von Spezifikationen, Code oder kommerziellen Inhalten. Mehr Output erreicht nun die Prüfung. Prüfkapazität, Entscheidungsrechte und Freigabekontrollen bleiben unverändert. Am nächsten Prozessschritt wächst die Warteschlange. Menschen verbringen mehr Zeit damit, uneindeutige Ergebnisse zu klären. Die End-to-End-Durchlaufzeit verändert sich kaum—oder die Qualität sinkt.

Die lokale Aufgabe wurde schneller. Das System nicht.

Das ist nicht nur ein theoretisches Risiko. In einem NBER-Feldexperiment über 66 Unternehmen erhielten 7.137 Wissensarbeiter Zugang zu einem generativen KI-Werkzeug. Aktive Nutzer verbrachten weniger Zeit mit E-Mails; eine breitere Veränderung von Menge oder Zusammensetzung ihrer Aufgaben konnte die Studie jedoch nicht feststellen. Individuelle Zeitgewinne können also real sein, während breitere Arbeitsmuster weitgehend unverändert bleiben. Das beweist nicht, dass Workflow-Redesign immer Wert schafft. Es zeigt, warum der Zugang zu einem Tool allein noch kein Wertnachweis ist.

Andere Kontexte liefern andere Ergebnisse. Eine im Quarterly Journal of Economics veröffentlichte Studie mit 5.172 Beschäftigten im Customer Support fand nach Einführung eines generativen Assistenten mehr gelöste Anliegen pro Stunde; besonders stark war der Effekt bei weniger erfahrenen Beschäftigten. Dagegen zeigte eine randomisierte METR-Studie von 2025, dass erfahrene Open-Source-Entwickler in ihnen gut bekannten Repositories mit den damals verfügbaren KI-Werkzeugen länger brauchten—obwohl sie selbst eine Beschleunigung erwartet hatten.

Diese Ergebnisse widersprechen sich nicht. Sie zeigen, dass „KI-Produktivität“ kein einheitlicher Effekt ist. Sie hängt von Arbeit, Nutzer, System, Technologie und Messgröße ab. Ein Ergebnis auf Aufgabenebene lässt sich nicht automatisch auf einen anderen Workflow übertragen. Und gefühlte Geschwindigkeit ist kein belastbarer Nachweis für End-to-End-Wert.

Lokale Beschleunigung ist nicht dasselbe wie Systemproduktivität.

Der Workflow ist die richtige Entscheidungseinheit

Eine Stelle bündelt unterschiedliche Arbeit: wiederholbare Schritte, Urteil, Ausnahmen, Koordination, Wartezeit, Nacharbeit und Verantwortung. Die gesamte Stelle als automatisierbar oder nicht automatisierbar zu behandeln verdeckt die relevanten Entscheidungen.

Eine Aufgabe ist präziser, kann aber weiterhin zu klein sein. Das Unternehmen verdient selten an einer isolierten Aufgabe. Wert entsteht, wenn ein Kunde ein verlässliches Ergebnis erhält, ein Produkt die Produktion erreicht, eine Entscheidung besser wird, ein Risiko beherrscht wird oder eine Transaktion abgeschlossen werden kann.

Der Workflow verbindet diese Punkte. Er zeigt die Reihenfolge der Arbeit, den Informationsfluss, den Einsatz von menschlichem oder maschinellem Urteil, den Umgang mit Ausnahmen und den Engpass, der den Durchsatz bestimmt. MIT Sloan fasste 2026 Forschung zu verketteten Aufgaben zusammen: Die Wirkung von Automatisierung hängt davon ab, wie Aufgaben gruppiert, angeordnet und zwischen Menschen und Maschinen übergeben werden—nicht nur von der Leistung eines einzelnen Schritts.

Damit wird der Workflow zur Ebene, auf der Technology, Product, Operations und Finance gemeinsam entscheiden können. Er ist detailliert genug, um reale Arbeit sichtbar zu machen, und breit genug, um Veränderung mit Unternehmensökonomie zu verbinden.

Die Executive-Sequenz lautet:

1. MAP — den End-to-End-Workflow und seine Konsequenzen verstehen.
2. ALLOCATE — jede relevante Arbeitseinheit bewusst zuordnen.
3. REDESIGN — den Workflow um diese Zuordnung herum neu gestalten.
4. PROVE — nachweisen, dass das Gesamtsystem besser funktioniert.
5. REBALANCE — Kapazität erst auf Basis dieser Evidenz verändern.

Das ist kein Reifegradmodell, sondern eine Entscheidungssequenz. Neue Evidenz kann die Organisation zurückführen: Ein gescheiterter Nachweis verlangt vielleicht eine andere Zuordnung; ein Muster bei Ausnahmen zeigt eine unvollständige Prozessaufnahme; zu hohe Lifecycle-Kosten können eine technisch erfolgreiche Lösung unwirtschaftlich machen.

Eine Engineering-Erfahrung aus erster Hand bei WiredMinds

Bei WiredMinds wurde KI Teil praktischer Engineering- und Business-Workflows innerhalb der breiteren Transformation eines etablierten B2B-SaaS-Unternehmens. Die entscheidende Engineering-Lektion war nicht, dass ein Modell Code erzeugen kann. Entscheidend war, dass generierter Output nur in einem Workflow zählt, der Veränderungen in verlässliche Produktfähigkeit übersetzt.

Das Operating Principle lautete: KI dort einsetzen, wo sie mechanische Arbeit reduzieren oder Verständnis beschleunigen kann—während Engineers Architektur, Review und Produktionsqualität verantworten. In einem solchen Software-Workflow kann KI beim Verständnis vorhandenen Codes helfen, Umsetzungsvarianten vorbereiten, repetitive Implementierung unterstützen, erste Tests vorschlagen, Dokumentation erleichtern und bei der Fehlersuche unterstützen. Das sind nützliche Muster, keine Behauptung, jeder Schritt sei in jedem WiredMinds-Team exakt so abgelaufen.

Die Beobachtung auf Unternehmensebene ist enger und belastbar: AI-unterstütztes Engineering trug zu schnellerer Entwicklungs- und Release-Arbeit sowie zu besserer Qualität bei. Für die wichtigere Schlussfolgerung braucht es keine öffentliche Prozentzahl. Der Effekt hing von Engineering Ownership, Release-Fähigkeit und operativer Disziplin rund um das Werkzeug ab. KI wurde weder zum verantwortlichen Architekten noch zum Reviewer oder Produktions-Owner.

Diese Erfahrung setzt zugleich eine wichtige Grenze. Schnellere Engineering-Arbeit zeigt allein noch nicht, wie viel Unternehmenswert realisiert wurde, und begründet keine Personalentscheidung. Freigesetzte Zeit kann Durchsatz, Qualität oder Produktfähigkeit verbessern. Sie kann aber auch in einem anderen Engpass verschwinden. Das Operating Model muss sichtbar machen, was tatsächlich geschieht.

Wenn Code-Erzeugung günstiger wird, verliert Engineering-Urteil nicht an Wert. Es verlagert sich zu Architektur, Evaluation, Integration und Konsequenz.

Hier treffen technische Tiefe und Unternehmensverantwortung aufeinander. Ein Technology Executive muss den Engineering-Workflow tief genug verstehen, um falsche Produktivitätsbehauptungen zu hinterfragen—und zugleich auf Unternehmensebene entscheiden, welches Ergebnis die freigesetzte Kapazität erzeugen soll.

MAP: verstehen, wie das Ergebnis wirklich entsteht

Workflow-Redesign beginnt mit Beobachtung, nicht mit einer Liste von KI-Use-Cases.

Erfasst werden Arbeitseinheiten, Entscheidungen, Übergaben, Wartezeit, Nacharbeit, Ausnahmen, Datenabhängigkeiten und Kontrollen zwischen einem Input und dem Geschäftsergebnis. Relevant ist der tatsächliche Weg einschließlich Tabellen, informeller Freigaben und Korrekturarbeit. Der dokumentierte Prozess lässt oft genau die Reibung aus, die darüber entscheidet, ob Automatisierung Wert schafft.

Das Mapping sollte fünf Dinge sichtbar machen:

• das Ergebnis, für das der Workflow existiert;
• den Engpass, der aktuell Durchsatz oder Qualität bestimmt;
• die Arbeit, die Kunden-, Regulierungs- oder Entscheidungswert erzeugt;
• die Konsequenzen eines Fehlers einschließlich Erkennbarkeit und Reversibilität;
• den Owner des End-to-End-Ergebnisses.

Hier wird auch unnötige Arbeit erkennbar. Ein Review kann existieren, weil ein altes System unzuverlässig war. Eine Abstimmung kompensiert vielleicht inkonsistente Daten. Ein Report wird weiter erstellt, weil ihn niemand beendet hat. Diese Arbeit zu automatisieren, konserviert ihre Kosten in technisch aufwendigerer Form.

Die erste Automatisierungsentscheidung ist oft die Eliminierung.

MAP verhindert, dass eine attraktive KI-Demo zur Lösung auf der Suche nach einem Prozess wird. Gleichzeitig entsteht die Basis für den späteren Nachweis. Wer Durchlaufzeit, Qualitätsverluste und relevantes Ergebnis des bisherigen Workflows nicht kennt, besitzt keinen Nenner für eine Produktivitätsbehauptung.

ALLOCATE: entscheiden, was Menschen, Software und KI tun sollen

Sobald der Workflow sichtbar ist, braucht jede wesentliche Arbeitseinheit eine klare Zuordnung. „Automatisieren“ ist nicht präzise genug.

REDESIGN: den Workflow um die neue Allokation herum bauen

Einen Copilot oder Agenten in den alten Prozess zu setzen, ist kein Redesign. Übergaben, Freigaben, Anreize, Datenlücken und Ownership bleiben bestehen. Der Prozess kann nun mehr Output in dieselben Engpässe schicken.

Redesign fragt, was sich durch die neue Zuordnung verändern muss:

• Welche Übergaben entfallen?
• An welche Stelle gehört der Review?
• Können Kontrollen deterministisch oder ausnahmebasiert werden?
• Auf welche Daten und Berechtigungen braucht das System Zugriff?
• Wer verantwortet eine von KI ausgeführte Entscheidung und ihre Ausnahmen?
• Welche alte Arbeit endet mit dem Start des neuen Workflows?
• Welches Quality Gate bleibt vor einer irreversiblen Handlung nötig?

Im Beispiel schnellerer Produktion mit unveränderter Review-Warteschlange kann die Lösung in besseren Review-Werkzeugen, früheren Qualitätskontrollen, klaren Akzeptanzkriterien, engerem KI-Scope, deterministischen Checks oder neu geordneter Ownership liegen. Die Antwort ist nicht automatisch, mehr Reviewer einzustellen. Das würde den lokalen Produktivitätsgewinn in neue Betriebskosten übersetzen.

Dieselbe Logik gilt außerhalb des Engineering. Schnellere Lead-Generierung kann die Qualifizierung überlasten. Automatisiertes Reporting kann widersprüchliche Managementinformation vervielfachen. Vertragsanalyse kann Dokumentenprüfung beschleunigen, während Entscheidungsbefugnisse unverändert bleiben. Jede lokale Beschleunigung verlangt eine End-to-End-Antwort.

Deshalb wird KI-Nutzung erst dann zur Transformation, wenn sich Prozesse, Daten, Ownership und Wirtschaftlichkeit verändern. Zugang zu einem Tool kann schnell entstehen. Das Operating Model zu verändern ist die eigentliche Arbeit.

PROVE: das vollständige System messen

Der Nachweis beginnt beim Geschäftsergebnis und arbeitet rückwärts.

In einem Engineering-Workflow können Lead Time von der Entscheidung bis zur Produktion, Release-Frequenz, Produktionsfehler, Nacharbeit, Zuverlässigkeit, Kundeneffekt sowie Kapazität für Review und Betrieb relevant sein. In einem kommerziellen oder administrativen Workflow sind andere Messgrößen richtig. Das Prinzip bleibt gleich.

Die Organisation sollte den neu gestalteten Workflow mit einer glaubwürdigen Baseline vergleichen, lange genug beobachten, um Ausnahmen zu erkennen, und Neuheitseffekte von dauerhafter Veränderung trennen. Gemessen werden müssen sowohl der geplante Gewinn als auch Belastungen, die an anderer Stelle entstehen.

Hilfreiche Fragen sind:

• Ist der Durchsatz gestiegen oder nur die Warteschlange gewandert?
• Hat sich Qualität auch nach Review und Nacharbeit verbessert?
• Haben sich Kunden- oder Geschäftsergebnisse verändert?
• Welche Arbeit ist entfallen und welche nur schneller geworden?
• Welche neuen Lifecycle-Kosten, Abhängigkeiten oder Fehlerrisiken sind entstanden?
• Wird der neue Workflow wirklich genutzt oder läuft der alte parallel weiter?

Gerade bei KI ist selbst eingeschätzte Produktivität unzuverlässig. Erzeugung fühlt sich schnell an, während Prüfung und Integration länger dauern können. Die METR-Studie ist deshalb ein nützlicher Warnhinweis: Die Teilnehmer erwarteten deutliche Beschleunigung, während die Messung im eng begrenzten Untersuchungsfeld in die andere Richtung zeigte.

Produktivität muss an der Grenze gemessen werden, an der das Unternehmen Wert erhält—nicht dort, wo KI Output erzeugt.

Gesparte Zeit ist noch kein realisierter Wert

Wenn KI eine Stunde freisetzt, verändert sich die P&L nicht automatisch. Das Unternehmen hat zunächst theoretische Kapazität geschaffen. Wert entsteht erst, wenn das Operating Model diese Kapazität in ein Ergebnis übersetzt.

Dieses Ergebnis kann mehr Durchsatz, kürzere Time-to-Revenue, höhere Qualität, geringere Verluste, mehr Kundenwert, vermiedene Neueinstellungen, niedrigere externe Ausgaben, Produktdifferenzierung oder eine strukturelle Kapazitätsveränderung sein. Tritt nichts davon ein, kann die Zeitersparnis für den Einzelnen angenehm sein—wirtschaftlich bleibt sie ungenutzt.

Ich verwende Value-Capture Rate als operatives Executive-Konzept: den Anteil der theoretisch freigesetzten Produktivität, der tatsächlich in ein wertvolles Unternehmensresultat übersetzt wird. Es handelt sich nicht um eine akademisch standardisierte Kennzahl und sie sollte nicht mit künstlicher Genauigkeit ausgewiesen werden. Ihr Zweck ist, die fehlende Managemententscheidung zwischen „Das Tool machte Arbeit schneller“ und „Das Unternehmen wurde wertvoller“ sichtbar zu machen.

Drei Unternehmen können dieselbe Aufgabenbeschleunigung erreichen und völlig unterschiedlichen Wert realisieren. Eines liefert schneller an Kunden. Eines vermeidet geplante Neueinstellungen. Eines lässt Arbeitsvolumen, Ziele und Organisation unverändert; die gewonnene Zeit verteilt sich im System. Das technologische Ergebnis ähnelt sich, das wirtschaftliche nicht.

Gesparte Zeit ist noch kein realisierter Wert. Kapazität wird erst dann zu Wert, wenn Management entscheidet, was aus ihr wird.

Die Wirtschaftlichkeit von KI-Produktivität

Ein nützliches Denkmodell lautet:

Realisierter KI-Wert = Brutto-Potenzial des Geschäftsergebnisses × Workflow-Abdeckung × Adoption × Zuverlässigkeit × Value-Capture Rate − vollständige Lifecycle-Kosten − erwartete Fehlerkosten

Das ist keine Buchhaltungsformel, sondern ein Entscheidungsmodell für einen klar abgegrenzten Workflow und Zeithorizont. Brutto-Potenzial, Lifecycle-Kosten und erwartete Fehlerkosten müssen in derselben Einheit ausgedrückt werden; Workflow-Abdeckung, Adoption, Zuverlässigkeit und Value-Capture Rate sind begrenzte Anteile. Weil die Faktoren einander beeinflussen, sind Szenariobandbreiten ehrlicher als ein einzelner präziser Wert. Das Modell dient dazu, die vollständige Wertlogik sichtbar zu machen.

Das Brutto-Potenzial des Geschäftsergebnisses umfasst den erreichbaren Wert: Umsatz- oder Gross-Margin-Effekt, vermiedene Kosten oder Neueinstellungen, geringere externe Ausgaben, Durchsatz, Durchlaufzeit, Qualität, Kundenergebnis, Risikoreduktion oder strategische Optionalität.

Workflow-Abdeckung fragt, welchen Anteil der End-to-End-Arbeit das neu gestaltete System abdecken kann. Eine kleine Aktivität in einem langen, begrenzten Prozess zu beschleunigen schafft wenig Systemwert.

Adoption fragt, welcher Anteil der geeigneten Arbeit tatsächlich durch das neu gestaltete System läuft, statt den alten Weg parallel weiterzuführen.

Zuverlässigkeit reduziert den potenziellen Wert um den Anteil vorgesehener Ausführungen, die kein akzeptables Ergebnis liefern.

Value-Capture Rate fragt, wie viel freigesetzte Kapazität zu einem wirtschaftlichen oder strategischen Ergebnis wird—nicht zu ungenutzter oder nur verschobener Zeit.

Vollständige Lifecycle-Kosten umfassen Modelle und Inference, Lizenzen, Implementierung, Integration, Daten, Evaluation, Monitoring, AgentOps, Human Review, Ausnahmebehandlung, Nacharbeit, Security, Compliance, Training, Vendor-Abhängigkeit und Exit-Kosten.

Erwartete Fehlerkosten erfassen die verbleibenden Folgen fehlgeschlagener Ausführungen—etwa Behebung, Kundenschaden oder Betriebsunterbrechung—nur soweit diese Folgen nicht bereits in Lifecycle-Kosten oder Zuverlässigkeitsabschlag enthalten sind. Diese Abgrenzung verhindert Doppelzählung.

Das Technology Value Economics Model wendet dieselbe Disziplin auf Technologie insgesamt an: Direkte Ausgaben sind nur ein Teil der Kosten, und technische Aktivität ist noch kein Geschäftswert.

Human Review ist eine wirtschaftliche und risikobezogene Entscheidung

„Human in the loop“ gilt häufig als Beleg für verantwortungsvolles Design. Das ist es nicht. Es beschreibt eine Kontrolle—und diese Kontrolle braucht eine wirtschaftliche sowie risikobezogene Begründung.

Für jeden menschlichen Review-Schritt sollte geklärt werden:

• Welches Urteil fügt der Reviewer hinzu?
• Welchen Fehler verhindert der Review?
• Wie häufig erkennt er etwas Wesentliches?
• Könnte eine deterministische Kontrolle dasselbe Problem erkennen?
• Könnte Monitoring ausnahmebasiert erfolgen?
• Ist die Handlung reversibel?
• Stehen Review-Kosten im Verhältnis zu den erwarteten Fehlerkosten?

Wenn ein Mensch jeden Output freigibt, ihn aber kaum verändert, bezahlt der Workflow möglicherweise hohe Kontrollkosten für geringe Risikoreduktion. Noch problematischer ist Automation Complacency: Das Systemdesign verlässt sich darauf, dass der Mensch Fehler findet, während der Mensch davon ausgeht, dass das System meistens richtig liegt.

Ein Mensch in jeder Schleife kann zu einem teuren Ersatz für gutes Systemdesign werden.

Das rechtfertigt keine unsichere Autonomie. Bei folgenreichen, schwer erkennbaren, irreversiblen oder stark kontextabhängigen Entscheidungen kann menschliches Urteil die wirtschaftlichste Kontrolle sein. Das Industrial AI Production Readiness Model verbindet Autonomie mit Konsequenz, Evidenz, Integration, Oversight und Accountability. Dasselbe Denken gilt für Enterprise-Workflows.

Ein menschlich leichter oder vollständig autonomer Betrieb wird rational, wenn Arbeit hochvolumig, standardisiert, beobachtbar, begrenzt und reversibel ist; Automation verlässlich funktioniert; Ausnahmen selten und erkennbar sind; und menschliches Urteil das Ergebnis nicht wesentlich verbessert. Menschliche Beteiligung bleibt wertvoll, wenn sie Kontext, Architektur, Produkturteil, Kundeninterpretation, Ausnahmebehandlung, Accountability oder materielle Risikokontrolle beiträgt.

Die Grenze sollte sich mit der Evidenz bewegen. In der Lernphase kann Review breit beginnen und später stichproben- oder ausnahmebasiert werden, wenn Zuverlässigkeit und Erkennbarkeit dies tragen. Umgekehrt kann Review verstärkt werden, wenn Fehler zeigen, dass die ursprüngliche Grenze zu großzügig war.

REBALANCE: entscheiden, was freigesetzte Kapazität werden soll

Erst nach Redesign und Nachweis sollte Leadership strukturelle Kapazität verändern.

Die Entscheidung lautet nicht nur, Rollen zu behalten oder abzubauen. Freigesetzte Kapazität kann mehr Output erzeugen, Qualität oder Kundenergebnisse verbessern, zu knapper höherwertiger Arbeit wechseln, externe Ausgaben ersetzen, Neueinstellungen vermeiden, Managementebenen vereinfachen oder interne Kapazität reduzieren.

Struktureller Personalabbau ist wirtschaftlich rational, wenn der neu gestaltete Workflow dauerhaft Arbeit entfernt hat; zusätzliche Nachfrage die Kapazität nicht sinnvoll aufnehmen kann; Zuverlässigkeit und Kontrollen bewiesen sind; Ausnahmeaufwand verstanden ist; Übergangskosten einbezogen wurden; und die Organisation das neue System betreiben kann, ohne versteckte manuelle Arbeit neu zu erzeugen.

Er ist irrational, wenn theoretisch gesparte Minuten über Aufgaben hinweg addiert wurden, der Engpass nur gewandert ist, zusätzliche Nachfrage mehr Output aufnehmen kann, Qualität und Kontrolle weiterhin von nicht gezählter menschlicher Arbeit abhängen oder knappe Fähigkeit entfernt wird, bevor das Operating Model stabil ist.

Der Arbeitsmarkt kann sich verändern, bevor Unternehmen vollständige Kausalevidenz besitzen. Stanfords deskriptive Analyse von 2026 auf Basis von Millionen US-Lohnabrechnungen fand keine breite gesamtwirtschaftliche Verdrängung, berichtete jedoch eine wachsende Beschäftigungslücke bei 22- bis 25-Jährigen in KI-exponierten Berufen—vor allem durch geringere Neueinstellungen. Die Autoren bezeichnen das ausdrücklich als frühen deskriptiven Indikator, nicht als kausale Schätzung. Das warnt zugleich vor Leugnung und Übertreibung: KI kann Arbeitsnachfrage verändern, aber ungleichmäßig und ohne daraus ein universelles Headcount-Rezept abzuleiten.

Ein Headcount-Ziel kann Ergebnis einer KI-Transformation sein. Als Architektur dafür ist es ungeeignet.

Welche Fragen müssen Executives vor Kapazitätsentscheidungen beantworten?

Bevor ein Unternehmen KI-Produktivität in Workforce-Entscheidungen übersetzt, sollte Leadership kompakt beantworten können:

• Welche Arbeit ist entfallen und welche nur schneller geworden?
• Ist der End-to-End-Engpass gewandert?
• Haben sich Durchsatz, Qualität oder Kundenergebnis nach Review und Nacharbeit verbessert?
• Welche Arbeit ist deterministisch, welche wird von KI ausgeführt und welche braucht weiterhin Urteil?
• Welches Geschäftsergebnis hat die freigesetzte Kapazität aufgenommen?
• Vermeiden wir Neueinstellungen, setzen knappe Fähigkeit neu ein oder erzeugen wir ungenutzte Zeit?
• Welche Oversight verändert Ergebnisse und welche existiert nur aus Gewohnheit?
• Wie hoch sind vollständige Lifecycle- und erwartete Fehlerkosten?
• Wer verantwortet das Ergebnis, wenn KI die Arbeit ausführt?
• Welche Evidenz würde uns veranlassen, Allokation oder Kapazitätsentscheidung rückgängig zu machen?

Das sind keine HR-Fragen, die nach der Technologieentscheidung delegiert werden. Es sind Fragen des Operating Model und der Kapitalallokation. Sie gehören zu CEO, CFO, CTO oder CIO, Product, Operations und den für das Ergebnis verantwortlichen Führungskräften.