Die Unmöglichkeit, KI-Produktivität zu messen

Das hier wird lang, sorry. Ich hab schon mal geschrieben, dass ich meistens schreibe, wenn ich etwas herausfinden will. Diese Frage beschäftigt mich seit einer Weile, und jedes Mal, wenn ich dachte, ich hätte sie beantwortet, fand ich einen neuen Fehler in der Antwort.

Bei Flowstate werden wir regelmäßig gefragt, wie man den Return on Investment von KI misst. Manchmal wollen Leute wissen, ob ihre Teams produktiver sind. Manchmal brauchen sie einfach etwas Glaubwürdiges für den Vorstand, wenn der nach der Rechnung fragt. Verständlich.

Mich interessiert das aber nicht nur, weil unsere Firma die Frage beantworten muss. Ich glaube, dass KI Menschen deutlich leistungsfähiger machen kann, und darauf würde ich gern hinarbeiten. Agenten sollen den repetitiven Scheiß erledigen. Menschen sollen mehr Zeit für die Arbeit bekommen, die sie wirklich machen wollen, auch für Dinge, die sie sich vorher nicht leisten konnten.

Das ist ein großer Teil der Idee hinter Flowstate. Aber ich darf nicht davon ausgehen, dass es passiert, nur weil mir der Gedanke gefällt.

Ich lese gerade The Humanist Review, und verdammt, da steht richtig gutes Zeug. Ernsthaft, schau es dir an. Daron Acemoglus Essay über KI und Arbeit lohnt sich komplett, aber dieser Satz über den Unternehmenssektor ist mir hängengeblieben:¹

It will demand more pro-worker tools when it focuses on increasing productivity and innovation, rather than only labor cost-saving.

Ich glaube, er hat recht. Wenn ich den Nutzen von KI ausschließlich über Gehälter begründe, die sie ersetzen könnte, darf ich mich nicht wundern, wenn das Gespräch bei Stellenabbau landet. Ich würde lieber erklären können, was das Team jetzt kann, das vorher nicht ging. Oder ob der Wegfall eines zähen Prozesses irgendjemandes Arbeitstag tatsächlich besser gemacht hat.

Das Problem ist, es zu zeigen. Wenn jemand sagt, er spare eine Stunde am Tag, ist das interessant, aber ich will trotzdem wissen, was sich geändert hat. Hat er mehr geschafft? Hatte er endlich Zeit, über etwas ordentlich nachzudenken? Vielleicht hat das Tool ihm eine Stunde gespart und jemand anderem eine Stunde Prüfarbeit eingebrockt.

Also habe ich nach einer Möglichkeit gesucht, die Arbeit eines Unternehmens mit dem zu vergleichen, was es dafür ausgibt. Am besten etwas, das über verschiedene Teams hinweg taugt, egal ob Angestellte, Freelancer, ein Dienstleister oder Agenten die Arbeit erledigt haben. Ich habe nicht erwartet, dass jede Abteilung dieselbe Vorstellung von Erfolg hat. Ich hatte gehofft, dass wir uns wenigstens bei einem Teil der Buchhaltung einigen können.

Gelandet bin ich bei einem Ansatz, den ich für testenswert halte, nicht bei einer Antwort, die ich allen empfehlen würde. Einige meiner früheren Ideen waren falsch. Ich habe die nützlichen Fehler drin gelassen, weil die Erklärung, warum sie scheitern, wahrscheinlich mehr hilft als so zu tun, als wäre ich mit außergewöhnlicher Weitsicht bei der heutigen Version angekommen.

Das erste Problem lässt sich leicht zeigen: Gib einem Agenten die einfachen Supportfragen, und die Menschen, die sich um die schwierigen kümmern, wirken plötzlich schlechter in ihrem Job.

Offenbar hat das Helfen alles verschlechtert

Nimm ein Support-Team, das im Monat 800 einfache und 200 schwierige Fälle bearbeitet. Ein einfacher Fall kostet sechs Minuten menschliche Bearbeitung. Ein schwieriger dreißig. Alle werden auf demselben Niveau gelöst.

Das sind erfundene Zahlen.

Vor der KI braucht dieses hypothetische Team 180 Bearbeitungsstunden für seine 1.000 Fälle. Das sind 5,56 Fälle pro Stunde.

Jetzt bearbeitet ein Agent 600 der einfachen Fälle. Die Menschen haben noch 200 einfache und 200 schwierige Fälle: 120 Stunden für 400 Fälle, also 3,33 pro Stunde.

Das Dashboard meldet einen Rückgang der Rate des menschlichen Teams um 40 %. Die durchschnittliche Bearbeitungszeit steigt von 10,8 Minuten auf 18.

Niemand ist langsamer geworden. Die Menschen haben die härteren Fälle. Die einfachen haben den Durchschnitt früher verdünnt, und jetzt sind sie weg.

Das Unternehmen bekommt weiterhin alle 1.000 Fälle gelöst und braucht sechzig Stunden weniger menschliche Bearbeitung. Was diese Stunden wert sind, kommt später. Vorerst gilt: Vom Team zu verlangen, seinen alten Durchschnitt zurückzuholen, wäre eine ziemlich dumme Reaktion auf eine Änderung, die wir absichtlich vorgenommen haben.

Gib die einfachen Fälle an einen Agenten

i

Einfach, MenschenSchwierig, MenschenEinfach, Agent

Einfache Fälle, die der Agent pro Monat löst600 von 800

Fälle pro Personenstunde

5,56 → 3,33

Menschliche Bearbeitungsstunden

180 → 120

Anerkannte Lieferung

7.200 $ → 7.200 $

Zugeordnete Bearbeitungskosten

7.200 $ → 5.280 $

Tatsächliche Ausgaben, Lohnsumme unverändert

7.200 $ → 7.680 $

Die Fälle pro Personenstunde sinken um 40 %. Dieselben 1.000 Fälle werden trotzdem gelöst, und 60 Bearbeitungsstunden sind für etwas anderes frei.

Das gab es schon vor Chatbots. Das Remote Encoding Center des US Postal Service kümmert sich um Adressbilder, die seine Maschinen nicht entziffern können. Ein Bericht von 2022 beschreibt, dass die Maschinen die leichteren Bilder übernahmen und den Menschen die ließen, deren Deutung länger dauerte.² Tom Scotts Video aus dem Zentrum ist für mich immer noch eines der besten Beispiele dafür, wie ein automatisiertes System einen Geschäftsprozess verändert, Jahre bevor jemand es KI nannte. Intercom macht dieselbe Beobachtung zur menschlichen Restlast nach der Support-Automatisierung.³

Es gibt auch gute Forschung, die genau die Rate nutzt, die ich eben kritisiert habe. In Generative AI at Work berichten Erik Brynjolfsson, Danielle Li und Lindsey Raymond von durchschnittlich 15 % mehr gelösten Fällen pro Stunde. Ihr KI-Assistent half den Leuten, die Kunden antworteten. Er hat keine separate Warteschlange einfacher Fälle übernommen. Sie haben außerdem die Qualität und das Erleben der Arbeit untersucht.⁴

In diesem Setting habe ich nichts gegen das Zählen von Fällen. Ich habe etwas dagegen, anzunehmen, dass sie noch vergleichbar sind, nachdem sich geändert hat, welche Fälle die Menschen bekommen. „Fälle pro Stunde“ kann nützlich sein. Es braucht eine Beschreibung der Fälle.

Und selbst in meinem sauberen Beispiel kann ein Tag mit weniger einfachen Fragen ein anspruchsvollerer Tag sein. Nichts in der Tabelle sagt uns, ob der Job besser geworden ist.

Was fragen wir eigentlich?

Haben wir mehr geliefert? Hat es weniger Ressourcen gekostet? Hat die Arbeit etwas Nützliches bewirkt? Hatten die Menschen, die sie gemacht haben, einen besseren Tag?

Das sind verschiedene Fragen. Ich habe „Produktivität“ selbst so behandelt, als beantworte der Begriff alle vier.

Zahlen verraten uns das Volumen. Kosten verraten uns, was wir hineingesteckt haben. Durchlaufzeit verrät uns, wie lange jemand gewartet hat. Umsatz und Marge sind wichtig, aber sie sagen uns nicht, was in jedem einzelnen Team passiert ist. Eine Umfrage, in der Leute angeben, ob sie sich schneller fühlen, tut das auch nicht.

METRs Entwicklerexperiment von Anfang 2025 macht diesen letzten Punkt ziemlich schmerzhaft deutlich. Erfahrene Entwickler, die in vertrauten Open-Source-Repositories arbeiteten, brauchten mit den verfügbaren KI-Tools 19 % länger. Hinterher schätzten sie trotzdem, die Tools hätten sie 20 % schneller gemacht.⁵ Das ist ein Ergebnis für diese Entwickler und diese Tools, kein Urteil über Coding-Agenten im Jahr 2026. METRs Update vom Februar 2026 sagt, neuere Tools helfen wahrscheinlich mehr, und erklärt zugleich, warum Selektionseffekte diese Verbesserung schwer zu schätzen machen.⁶

Natürlich gibt es auch eine McKinsey-Umfrage. In den Ergebnissen vom August 2026 sagten 80 % der Befragten, KI habe ihre eigene Produktivität verbessert. Nur 37 % führten einen Einfluss auf den Unternehmensgewinn darauf zurück.⁷ Eine nützliche Lücke, die eine Beratung da gefunden hat. Es sind außerdem zwei verschiedene selbstberichtete Fragen, also können wir nicht einen Prozentwert vom anderen abziehen und den fehlenden Nutzen für gestohlen erklären.

Das SPACE-Framework hat mir geholfen, der Frage eine Grenze zu setzen. Nicole Forsgren, Margaret-Anne Storey und ihre Mitautoren argumentieren, dass sich Entwicklerproduktivität nicht in einer einzigen Kennzahl oder Dimension erfassen lässt.⁸ Da stimme ich zu. Ein Maß für Liefereffizienz kann trotzdem nützlich sein. Es muss nur aufhören zu behaupten, es beschreibe alles andere.

Ich nenne den Vorschlag einen standardisierten Lieferindex. Er behandelt die gelieferte Arbeit und die Ressourcen dahinter. Das Geschäftsergebnis und das Erleben der Arbeit brauchen ihre eigenen Belege.

Ich habe es mit den Zahlen versucht, die wir schon haben

Jede sah vernünftig aus, bis ich ihr ein unbequemes Beispiel gab.

Die Tabellen sind kein Grund, jedes bestehende Maß wegzuwerfen. Ich brauchte Teile von mehreren. Was immer wieder scheiterte, war die Annahme, dass eines davon die ganze Aufgabe übernehmen kann.

Ich habe die Kandidaten an elf erfundenen Fällen getestet, darunter ein Agent, der die einfache Arbeit übernimmt, und ein Team, das sich in zwei teilt. Meine Arbeitsnotizen enthalten die Fälle, die Dummy-Daten und die Rechnungen. Nimm sie als Protokoll, wie sich die Idee verändert hat, nicht als elf Tests, die belegen, dass die endgültige Version in einem Unternehmen funktioniert.

Arbeit ist kein Ticket

Meine erste Definition war hübsch sauber: Zähle Arbeit, die jemand angefordert und abgenommen hat.

Leider gab es das Unternehmen, das ich beschrieben hatte, nicht.

Bei Flowstate hinkt unser eigenes Linear-Setup fast immer der Arbeit hinterher, die tatsächlich gemacht wird. Ich brauche keine historische Studie über Issue-Tracker, um dieses Problem zu erkennen.

Ein Entwickler bemerkt etwas, bespricht es, behebt es und legt irgendwo unterwegs ein Ticket an. Ein Kunde eröffnet eine Konversation in Intercom. Eine Rechnung trifft ein. Ein Anwalt gibt in einem Telefonat Rat. Der Entwickler in Bereitschaft untersucht den Fall, weil der laufende Betrieb des Dienstes ohnehin seine Verantwortung ist.

Wir machen Arbeit nicht legitim, indem wir sie hinter einen Genehmigungsknopf stellen. Wer den Eintrag anlegt, ist außerdem nicht unbedingt die Person, die die Arbeit gebraucht hat.

Was ich zählen will, ist ein geschäftliches Lieferergebnis oder ein Service mit einem Zweck, einem Umfang und einer Abschlussbedingung, die wir erklären können. Eine Anfrage kann das festlegen. Ein vereinbartes Ziel, ein Kundenproblem oder eine dauerhafte Zuständigkeit auch. Ein Entwickler sollte nicht darauf warten müssen, dass eine andere Abteilung das Schließen einer Sicherheitslücke beauftragt, bevor es zählt.

Die Definitionen werden sich je nach Funktion unterscheiden. Ich sehe da keinen Weg drumherum.

Das sind keine alternativen Namen für Zeilen in einer Datenbank. Eine gemergte Änderung kann unvollständig sein. Eine als bezahlt markierte Rechnung kann falsch sein. Ein stummer Kunde kann zufrieden sein oder restlos bedient.

Die Belege sind verstreut. Ein Vorfall kann eine Support-Konversation, ein Engineering-Issue, drei Pull Requests und eine Follow-up-Mail hinterlassen. Sechs Einträge zu zählen belegt keine sechs Ergebnisse. Objektzentriertes Process Mining hilft hier, weil es Ereignisse darstellt, die mit mehreren Geschäftsobjekten verbunden sind.⁹ Es hilft, die Einträge zusammenzuführen. Es entscheidet nicht, wofür der Vorfall zählen soll.

Ob Unternehmen den relevanten Kontext teilen und ob KI ihn zuverlässig deuten kann, sind getrennte Probleme. Ich lasse sie in diesem Beitrag draußen. Für die Buchhaltung nehmen wir an, dass wir eine hinreichend gute Darstellung der Arbeit und ihrer Kosten herstellen können, durch menschliche Prüfung, Automatisierung oder beides.

Dann bleibt eine schwierige Frage: Was zählen wir angesichts der Belege? Fehlende Belege sollten Arbeit offen lassen, nicht für wertlos erklären. Sonst baue ich ein Maß dafür, wer die begeistertsten Abschlussnotizen schreibt.

Die Buchhalter waren schon mal hier

Das Support-Beispiel braucht einen Weg, sechs Minuten Arbeit von dreißig zu unterscheiden. Dieser Teil ist zumindest nicht neu.

ACCA beschreibt Standardstunden als Weg, verschiedene Produkte zu einem Produktionsmaß zusammenzufassen. Sie trennen, wie viel produziert wurde, wie viel der verfügbaren Kapazität genutzt wurde und wie effizient.¹⁰ Das ONS verwendet kostengewichtete Aktivitätsindizes für einen Großteil der öffentlichen Dienstleistungen.¹¹

Ich übernehme diese Struktur: Outputs nach Typ zählen, dann mit stabilen Referenzgewichten aufaddieren. Das gibt uns eine Skala, ohne dass jeder interne Service einen Verkaufspreis haben muss.

Das ONS ist auch ein nützlicher Dämpfer für meinen Ehrgeiz. Etwa ein Drittel des öffentlichen Dienstleistungs-Outputs, den seine Methodik abdeckt, nutzt weiterhin eine Konvention, nach der Inputs gleich Outputs sind, was die Produktivität für diesen Teil konstant macht.¹¹ Dass es kostengewichtete Messung gibt, heißt nicht, dass schon jemand herausgefunden hat, wie man jeden Service misst.

Zurück zum Support. Bei einem Referenz-Stundensatz von 40 $ trägt eine einfache Lösung ein Gewicht von 4 $ und eine schwierige 20 $. Multipliziere jede Anzahl mit ihrem Gewicht und addiere:

D = 800 × 4 + 200 × 20 = 7.200

(1)

Wir bekommen 7.200 $ vor dem Agenten und 7.200 $ danach. Das Unternehmen hat dieselben 800 einfachen und 200 schwierigen Lösungen erhalten. 600 davon billiger zu machen lässt sie nicht aus dem Output verschwinden.

Allgemein geschrieben:

D_t = Σ_k n_k,t s_k,b

(2)

D ist der gelieferte Output in Dollar zu Referenzkosten. n ist die Anzahl je Typ und s sind die durchgängigen Referenzkosten des Typs. t bezeichnet den Zeitraum, den wir messen, und b den Referenzzeitraum. Die Summe läuft über die Arbeitstypen.

Diese Dollar sind weder Umsatz noch Einsparungen. Sie erlauben uns, Mengen ungleicher Arbeit mit einem einzigen, offen gelegten Gewichtssatz zu vergleichen.

Anfangs wollte ich das Gewicht rechtfertigen, indem ich argumentierte, die historischen Kosten seien eine Untergrenze für den Wert. Eine Firma zahlt doch nicht vier Stunden für Arbeit, die weniger als vier Stunden wert ist?

Eine extrem großzügige Einschätzung unternehmerischer Entscheidungen. Firmen kaufen Dinge, die sie nicht kaufen sollten, und vernünftige Investitionen können scheitern. Die alten Kosten sagen etwas über die Produktion aus. Sie beweisen nicht, was das Ergebnis wert war.

Für ein echtes Unternehmen würde der Standard die relevante Mischung aus Menschen, Tools, Agenten und zugekauften Services abdecken. Wo wir glaubwürdige rollenbasierte Aufwandsschätzungen haben, verhindern feste Referenzsätze, dass derselbe Job ein größeres Gewicht bekommt, weil ihn jemand Teureres gemacht hat. Ein zugekaufter Service braucht stattdessen vielleicht einen vergleichbaren Referenzpreis.

Tatsächliche Gehälter und Rechnungen gehören auf die Kostenseite. Dieselbe klar umrissene Lieferung sollte in London und Lissabon dasselbe Outputgewicht haben. Ein Wechsel des Lieferanten sollte daran auch nichts ändern.

Standardstunden können funktionieren, wo sie Sinn ergeben. Aber ein Index, der automatisierte Arbeit abdeckt, braucht mehr als die verbleibenden menschlichen Stunden, sonst können seine Gewichte gegen null gehen, je erfolgreicher die Automatisierung ist. Referenz-Ressourcenkosten geben uns eine breitere Basis.

Und der Referenzzeitraum muss nicht vor der KI liegen. Er braucht brauchbare Belege. „Bevor irgendjemand ChatGPT benutzt hat“ bleibt nicht ewig ein nützliches Datum.

Sind das nicht einfach Story Points in Dollar?

Möglich. Zuerst eine Korrektur, über die sich Entwickler zu Recht ärgern: Story Points sind keine Stunden. Sie sollten Arbeit relativ zu anderer Arbeit einschätzen, nach Komplexität und Unsicherheit, weshalb so viele Teams eine Fibonacci-artige Skala nutzen. Die Abstände wachsen, wenn die Sicherheit sinkt. Points in Stunden umzurechnen war nie der Sinn.

Das Risiko hier ist ein anderes. Die Schätzungen des Teams in Dollar umzurechnen und das Ergebnis objektiv zu nennen, wäre dieselbe Vermutung mit besserem Finanz-Branding.

Ron Jeffries’ Entschuldigung dafür, dass er möglicherweise Story Points erfunden hat, ist lustig, beantwortet diesen Einwand aber nicht.¹² Gergely Orosz beschreibt einen Entwickler, der Schätzungen aufblähte, sobald das Team seine Sprint-Points als Erfolgstest behandelte.¹³ Ein Referenzkostensystem bietet dieselbe Versuchung. Gib der Arbeit ein größeres Gewicht, und der Score wird besser.

Ich will einen Standard für eine Klasse gelieferter Arbeit, keine laufende Schätzung, wie schwierig sich dieser konkrete Versuch anfühlt. Eine Planungsschätzung kann steigen, wenn wir ein Problem finden. Das Outputgewicht sollte nicht steigen, nur weil wir länger gebraucht haben. Hat sich der Umfang geändert, müssen wir sagen, was sich geändert hat.

Ich würde den Standard aus geprüften Beispielen vergleichbarer Arbeit bauen und an anderen Beispielen testen. Die Gewichte für den Vergleich festschreiben. Änderungen protokollieren, damit weder das Team noch sein Manager ein berichtetes Ergebnis verbessern kann, indem er sie nachträglich vergrößert.

Ein Rest Urteilsvermögen bleibt dabei. Welche Jobs gehören zusammen? Ist der teure Fall eine andere Art von Arbeit oder ein teurer Versuch derselben? Ein Prüfer muss sowohl die Kategorie als auch das Gewicht anfechten können.

Sogar die Wahl des Durchschnitts zählt. Ein Median beschreibt einen typischen Fall. Multipliziert mit dem Volumen reproduziert er bei einer Arbeitslast mit langem Schwanz in der Regel nicht den Gesamtverbrauch an Ressourcen. Für ein erwartetes Ressourcenkostengewicht würde ich normalerweise mit einem Mittelwert für eine klar definierte Klasse anfangen und die Streuung zeigen. Ich würde nicht die Statistik wählen, die den Index am schönsten aussehen lässt.

KI könnte helfen, Gewichte vorzuschlagen. Anthropics Arbeit zur Schätzung von Aufgabendauern fand nützliche Ranginformationen, aber Claude überschätzte kurze Softwareaufgaben und unterschätzte lange.¹⁴ Jobs ungefähr in die richtige Reihenfolge zu bringen reicht nicht, wenn ihre relativen Gewichte das Ergebnis bestimmen.

Ein Points-System könnte ähnliche Kontrollen übernehmen. Ich darf den Sieg nicht dadurch erklären, dass ich den Namen ändere. Der Test ist, ob ein anderes Team die Definitionen anwenden kann und ob eine vernünftige Meinungsverschiedenheit das Ergebnis ändert.

Hält das nicht, dann ja, dann habe ich Story Points in Dollar neu erfunden.

Haben wir es erledigt, oder nur aufgehört, darüber zu reden?

Fin liefert ein nützliches konkretes Beispiel. Intercom zählt bestätigte und angenommene Lösungen, bei denen der Kunde nach einer Antwort geht, ohne weitere Hilfe zu verlangen. Die Dokumentation sagt außerdem, dass die Gebühr zurückgenommen wird, wenn der Kunde in dieselbe Konversation zurückkehrt und weitere Hilfe sucht.¹⁵

Das ist eine klare Abrechnungsregel. Sie lässt eine Frage zu stummen Kunden offen, aber es wäre unfair, sie ohne die Rücknahmeregel zu diskutieren. Und von Menschen geschlossene Konversationen verdienen dieselbe Prüfung.

Für diesen Index würde ich für jede Art von Arbeit festlegen, was als Abschluss zählt. Manchmal gibt es eine ausdrückliche Abnahme. Manchmal gibt es einen Test, einen Zahlungsbeleg oder einen Nachweis der Lieferung. Manchmal haben wir nur indirekte Signale und müssen diese Unsicherheit zeigen. „Geschlossen“ kann nicht jeden Fall entscheiden.

Nacharbeit ist auch nicht einfach. Eine wiedereröffnete Konversation kann eine gescheiterte Antwort sein oder eine neue Frage. Ein Code-Revert kann einen Fehler beheben oder eine geänderte Produktentscheidung widerspiegeln. Ein späterer Streit entwertet nicht automatisch die Rechtsberatung, die ihm vorausging.

Wir brauchen eine Regel dafür, welche Korrekturen früheren Output rückgängig machen, wie viel davon und welche zu neuem Umfang gehören. Wende sie auf Menschen und Agenten gleichermaßen an. Vergleiche Arbeit, die dieselbe Gelegenheit hatte, Mängel zu zeigen, und überarbeite den ursprünglichen Zeitraum, wenn frühere Anrechnung nicht mehr trägt. Eine frisch geleerte Queue sollte nicht besser aussehen, nur weil sich noch niemand beschweren konnte.

Das Prüfen kostet auch Ressourcen. Die Review-and-Redo-Szenarien von GDPval zeigen, wie stark sich der scheinbare Kostenvorteil verschieben kann, sobald Expertenprüfung eingerechnet wird. Es sind modellierte Szenarien, keine beobachteten Einsparungen in Unternehmen, und das Paper vermerkt, dass für seine menschliche Vergleichsbasis keine gleichwertigen Prüf- und Fehlerkosten enthalten sind.¹⁶ Ich will den ganzen Workflow auf beiden Seiten durchgerechnet sehen.

Die Planung hat einen anderen Fehler meiner früheren Version offengelegt. Ich hatte vorgeschlagen, einem Forecast-Zyklus keine Anrechnung zu geben, wenn die Anpassungen des Planers ihn verschlechtert haben. Das hat das Erledigen der Arbeit mit einem günstigen Ergebnis verwechselt.

Forecast Value Added ist nützlich, um Anpassungen über vergleichbare Beobachtungen hinweg zu bewerten.¹⁷ Es ist kein universeller Schalter dafür, ob Planung stattgefunden hat. Ein solider Forecast kann seinen Auftrag erfüllen und trotzdem danebenliegen. Gute Rechtsberatung kann einen Deal verhindern. Ein Experiment kann gerade deshalb nützlich sein, weil es uns sagt, das Projekt aufzugeben.

Erkennt das Maß nur gute Nachrichten an, übersieht es manche gute Arbeit.

Vierzig Entwürfe wovon?

Jetzt gib dem Index etwas Marketingarbeit.

Ein Team hat früher vier Anzeigenvarianten pro Woche produziert. Jede brauchte zwei Stunden, was bei unserem Beispielsatz jeweils ein Referenzgewicht von 80 $ ergibt. Der Wochen-Output war 320 $.

Mit KI produziert es vierzig. Wende das Gewicht auf jede erzeugte Datei an, und der Output wird zu 3.200 $, während sich die Ergebnisse der Kampagne kaum bewegen.

Anfangs habe ich das als Beweis gesehen, dass das Maß kaputt ist. Vielleicht ist es das, aber nicht aus dem Grund, den ich dachte. Vierzig eigenständige, vergleichbare Lieferergebnisse können die zehnfache Produktion sein, ohne zehnmal nützlicher zu sein. Ich hatte schon gesagt, dass ich keinen Wert messe, und erwartete dann trotzdem, dass die Zahl das tut.

Die andere Frage ist, ob diese vierzig Dateien vierzig Lieferergebnisse waren. Es können Entwürfe gewesen sein, mit denen man auswählt, was in ein einziges Experiment kommt.

Nehmen wir für dieses Beispiel an, der Service ist ein Kampagnenexperiment für eine bestimmte Zielgruppe, mit einer definierten Testfrage und Berichtsanforderungen. Ich würde dieses Experiment zählen. Ob vier Entwürfe entstehen oder vierzig, ändert die Einheit nicht. Ihre Erstellung und Auswahl gehören zu den Kosten.

Führt das Team ein weiteres, wirklich eigenständiges Experiment von vergleichbarem Umfang durch, ist das mehr Output. Zehn Variationen desselben Tests zehn Experimente zu nennen ist es nicht. Wir bräuchten die Definition, bevor wir das Ergebnis sehen, nicht eine erfinderische Erklärung hinterher.

In einem anderen Workflow kann das Erzeugen einsatzbereiter Varianten selbst der Service sein. Dann können einzelne Varianten die richtige Einheit sein. Das ist eine andere Berichtsgrenze, und ich würde nicht zwischen beiden wechseln, je nachdem, welche die größere Zahl liefert.

Tom Cunningham und Parker Whitfill von METR haben geholfen zu klären, warum die Wertfrage getrennt bleibt. Sie unterscheiden zwischen dem Effekt von KI auf die alte Aufgabenmischung, die neue Aufgabenmischung und den erzeugten Wert. Etwas billig zu machen verändert, was Leute zu versuchen wählen, und nicht nur, wie schnell sie die Arbeitslast von gestern abschließen.¹⁸

Ich bin dafür, diese Fragen zu trennen. Eine Produktionszahl wird nicht zum Wertmaß, nur weil die Arbeit früher teuer war. Auch macht die Zustimmung eines Managers vierzig Varianten nicht vierzigmal nützlicher als eine.

Was passiert, wenn ein Schritt wegfällt?

Bei Software bricht die Zählung in die andere Richtung.

Angenommen, ein Feature brauchte früher eine dreistündige Spezifikation, zehn Stunden Umsetzung und zwei Stunden Review. Bei 40 $ pro Stunde sind die Referenzkosten 600 $.

Jetzt kann ein Agent dasselbe Feature aus dem Kontext bauen, der schon da ist. Die Nutzung kostet 25 $. Das menschliche Review dauert drei Stunden, bei unserem Satz 120 $ Aufwand. Die modellierten eingesetzten Ressourcen betragen insgesamt 145 $. Nimm an, das Feature erfüllt dieselben Anforderungen und Qualitätsprüfungen.

Zähle ich die alten Prozessschritte, verliere ich die Spezifikation. Die übrig gebliebene Umsetzung und das Review haben alte Gewichte von zusammen 480 $. Aber das Unternehmen hat das ganze Feature bekommen.

Schritte zu zählen verliert 20 % des Outputs, weil ein Dokument überflüssig wurde. Das ganze Feature zu zählen hält den Vergleich intakt.

Das funktioniert nur, wenn der Schritt wirklich überflüssig war. Eine Sicherheitsprüfung zu entfernen oder eine Anforderung fallen zu lassen würde ändern, was geliefert wurde. „Dasselbe Feature auf demselben Standard“ leistet in diesem Satz wichtige Arbeit.

„Das ganze Feature“ auch. Es kann nicht alles heißen, was zufällig Anfrage genannt wird. Teilst du ein Feature in drei Tickets, sollte es nicht drei Feature-Gewichte bekommen. Fasst du drei echte Features zu einem Epic zusammen, sollten nicht zwei verschwinden.

Dann gibt es Eltern und Kinder. Enthält das Ende-zu-Ende-Feature schon Design und Review, kann ich das Gewicht des Features nicht zu derselben Arbeit addieren, die diese Teams noch einmal zählen. Wir können Beiträge innerhalb der Summe zuordnen. Wir können keinen zusätzlichen Unternehmens-Output schaffen, indem wir ihn zwischen Abteilungen verschieben.

Versuch es mit einer Umorganisation derselben Arbeit, ohne zu ändern, was geliefert wird. Die Summe des Unternehmens sollte gleich bleiben. Versuch, einen Teil auszulagern. Gleicher Test.

Lange Projekte brauchen auch beim Timing Sorgfalt. Ich würde kumulative Vergleiche nehmen oder unabhängig nützliche Meilensteine, deren Gewichte sich zum vereinbarten Umfang addieren. Sonst führen Monate an Kosten zu einer einzigen riesigen Abschlussspitze, und ein Monats-Dashboard ist den Großteil des Jahres irreführend.

Schön. Was ist dasselbe Feature?

Ich war mit diesem Fünfzehn-Stunden-Feature ziemlich großzügig zu mir selbst. Eine Rechtschreibkorrektur und ein Abrechnungssystem kann man beide Feature nennen. Beides in eine Kategorie zu packen führt uns direkt zurück zum Support-Problem.

Nehmen wir etwas Konkreteres: einen CSV-Export der Audit-Historie eines Kunden. Ein berechtigter Account-Administrator muss acht festgelegte Felder für einen gewählten Zeitraum exportieren. Das Briefing definiert Volumen- und Antwortzeitgrenzen, Genauigkeitsanforderungen und Zugriffskontrollen. Es muss im Live-Produkt funktionieren.

Ich würde eine gelieferte Exportfunktion dieses Umfangs zählen. Nicht den Button, den Endpoint, die Tests und die Dokumentation einzeln. Auch nicht jedes Mal, wenn jemand die Datei herunterlädt. Hier messen wir die Lieferung einer Änderung, nicht den Betrieb des Produkts danach.

In diesem fiktiven Unternehmen nehmen wir an, wir finden fünf frühere Report-Export-Änderungen mit vergleichbarem Datenumfang, Nutzerverhalten, Betriebsgrenzen und Absicherungsanforderungen. Auf derselben Referenzpreisbasis lagen ihre Ende-zu-Ende-Kosten bei 480 $, 560 $, 600 $, 640 $ und 720 $. Der Mittelwert ist 600 $.

So könnten wir das Gewicht konstruieren. Fünf bequeme Zahlen belegen nicht, dass es ein gutes ist. Der Prüfer muss kontrollieren, was diese Jobs vergleichbar gemacht hat, statt einfach nach dem Wort „Export“ zu suchen. Anschließend würden wir die Klasse und ihr Gewicht an anderer Arbeit testen.

Jetzt haben wir eine Definition, an der man sich reiben kann:

Beachte, dass die Klasse nicht von der gewählten Implementierung abhängt, nicht von der Zahl der Pull Requests und nicht vom Gehalt des Entwicklers. Das kann die Kosten beeinflussen, ohne zu ändern, was das Unternehmen bekommen hat.

Der Event-Stream ist anders. Er ändert das geforderte Verhalten. Wir bräuchten eine passende Referenzklasse oder eine andere ausdrückliche Behandlung für diesen Umfang, einheitlich auf frühere und spätere Arbeit angewandt. Wir können nach einem teuren Build keine Kategorie „sehr komplexer Export“ erfinden und ihr mehr Output zusprechen.

Und was ist mit einer neuen Reporting-Plattform ohne glaubwürdigen Präzedenzfall? Ich würde sie nicht in diese Klasse pressen. Ich würde ihren Umfang, ihre Kosten und nützliche Meilensteine beschreiben und sie außerhalb dieser vergleichbaren Serie halten, bis wir eine Grundlage haben, sie aufzunehmen.

Ihre Kosten müssen sichtbar bleiben. Der Bericht muss den gemessenen Service mit nicht zugeordneter Arbeit und den übrigen Ausgaben abstimmen. Sonst würde ich die leicht klassifizierbaren Erfolge herauspicken und alle sperrigen Investitionen anderswo lassen.

Das ist der schwierigste Teil des Vorschlags. Ein anderer Prüfer könnte die Export-Klasse oder ihr Gewicht von 600 $ ablehnen. Wenigstens können wir die Meinungsverschiedenheit lokalisieren und sehen, ob eine andere vernünftige Wahl die Antwort ändert.

Manche Engineering-Arbeit trägt vielleicht Klassen wie diese. Manche nicht. Das herauszufinden wäre ein nützliches Ergebnis, auch wenn es meine Hoffnung auf eine unternehmensweite Summe ruiniert.

Die sechzig Stunden sind nicht von der Gehaltsliste verschwunden

Zurück zum Support und zu der Einsparung, die ich verlockend fand zu berichten.

Ursprünglich ergaben 180 Bearbeitungsstunden zu 40 $ 7.200 $. Danach ergeben 120 Stunden 4.800 $. Addiere eine beispielhafte Agentengebühr von 0,80 $ für jede seiner 600 Lösungen, und die zugeordneten Bearbeitungskosten betragen 5.280 $.

Das sind 1.920 $ weniger. Nur dass die Leute weiter zu denselben Bedingungen angestellt sind.

Nimm an, die Lohnsumme bleibt in diesem vereinfachten Beispiel bei 7.200 $. Addiere die Agentenrechnung von 480 $, und das Unternehmen gibt 7.680 $ aus. Der Bearbeitungsbedarf ist gesunken. Die Rechnung ist gestiegen.

Robert Kaplan und Steven Anderson machen diese Unterscheidung in ihrer Arbeit zum zeitgesteuerten Activity-Based Costing: Ungenutzte Kapazität bietet Chancen für Einsparungen oder Wachstum.¹⁹ Ich stimme zu, und es ändert hier die Regel. Freigesetzte Stunden kommen auf eine Kapazitätszeile. Einsparungen brauchen den Beleg gesunkener Ausgaben oder eine glaubwürdige Darstellung vermiedener Ausgaben.

Die sechzig Stunden könnten mehr Kunden ohne eine weitere Einstellung tragen. Sie könnten Überstunden senken, Spitzen abfangen oder den Job weniger hektisch machen. Sie könnten auch ungenutzt bleiben. Ich will nicht, dass die Buchhaltung ein Ergebnis wählt, bevor das Unternehmen irgendetwas mit der Zeit gemacht hat.

Für den Haupt-Kosteneffizienzindex würde ich die Kosten verwenden, die entstehen, um den gemessenen Service zu liefern, einschließlich erfolglose Arbeit und ungenutzt gebliebener Kapazität. Vergleiche das Lieferwachstum mit dem Kostenwachstum:

E_t = 100 × D_t / D_bC_t / C_b

(3)

D ist die Liefersumme. C sind die Kosten innerhalb derselben Berichtsgrenze. E startet bei 100, also bedeutet 100 keine Veränderung der Kosteneffizienz.

Im Support-Beispiel bleibt die Lieferung bei 7.200 $, während die Ausgaben von 7.200 $ auf 7.680 $ steigen. Der Index liegt bei 93,8: Die Kosteneffizienz ist in diesem Monat um 6,25 % gefallen.

Nimm das separate Modell der zugeordneten Bearbeitung, und das Verhältnis beträgt 136,4. Das ist die Verbesserung der für den Workflow nötigen Ressourcen, kein realisierter finanzieller Gewinn. Beide Zahlen sind nützlich, sobald sie beschriftet sind. „KI-Einsparungen“ über eine von beiden zu schreiben würde viel Erklärung sparen und ein viel größeres Problem schaffen.

Für eine echte Kostenrechnung gehören Lohnsumme und Nebenkosten, Freelancer, zugekaufte Services, Lizenzen, Agentennutzung und Infrastruktur dazu. Auch Review, Wartung und Messung verbrauchen Ressourcen. Rechne Review-Arbeit nicht doppelt, wenn sie schon in der Lohnsumme steckt.

Das Honorar eines Dienstleisters gehört einmal in die Rechnung, neben unsere eigene Aufsicht. Wir erfinden nicht zusätzlich seine interne Lohnsumme und seine Token-Kosten. Auslagerung sollte die Einkaufskosten weder verschwinden lassen noch doppelt zählen.

Wir brauchen außerdem eine konsistente Basis über die Zeit. Periodenausgaben sind keine Barzahlungen. Ein Build, der dieses Quartal bezahlt wurde, kann mehrere Jahre dienen. Wähle die Behandlung und lege sie offen. Buche den Build nicht in einem Vergleich sofort als Aufwand und verteile ihn in einem anderen über Jahre. Das Support-Beispiel nimmt an, dass Aufwand und Barausgaben zusammenfallen.

Auch Preise spielen eine Rolle. Billigere Tokens verbessern die Wirtschaftlichkeit, selbst wenn sich am Workflow nichts ändert. Eine Gehaltserhöhung bewirkt das Gegenteil. Wo sich Inputmengen und Qualität vergleichen lassen, hilft eine Sicht zu konstanten Preisen, Preisänderungen vom Ressourcenverbrauch zu trennen. Ohne diesen Beleg zeige das nominale Kostenergebnis und erkläre seine Grenzen.

Schließlich belegen sechzig Bearbeitungsstunden weniger nicht, dass eine ganze Stelle wegfallen kann. Die Besetzung muss die Arbeit weiter abdecken, wenn sie anfällt. Die nächste Frage betrifft Nachfrage und Servicezusagen, nicht die Division durch eine bequeme Stundenzahl.

Der Fehler, von dem ich dachte, er hebe sich auf

Ich hatte geschrieben, ein falsches Gewicht hebe sich auf, wenn wir ein Team mit sich selbst vergleichen. Derselbe Fehler steckt auf beiden Seiten, also passt das doch?

Nein. Nicht, wenn sich die Mischung verschiebt.

Nimm zwei Arten von Arbeit. Für dieses Beispiel legen wir fest, dass ihre korrekten Referenzgewichte 1 $ für einfache und 10 $ für komplexe Arbeit sind. Im ersten Quartal schließt das Team neunzig einfache Einheiten und eine komplexe ab. Im zweiten zehn einfache und neun komplexe. Korrekt gewichtet ist der Output in beiden Quartalen 100 $. Halte auch die gesamten Ressourcen unverändert.

Jetzt gib komplexer Arbeit ein falsches Gewicht von 20 $.

Wir melden 72,7 % Wachstum, wo es im korrekt gewichteten Maß keins gab. Der Fehler blieb gleich. Wir haben mehr von der Arbeit gemacht, die wir überbewertet hatten.

Ein falsches Gewicht kann Wachstum vortäuschen

i

Echtes Wachstum 0,0 %. Der Index meldet +72,7 %. Gleiche Arbeit, andere Mischung.

Wie falsch ist das Gewicht für komplexe Arbeit?+100 %

Komplexe Einheiten im zweiten Quartal9

Das Gewicht für einfache Arbeit um denselben Betrag falsch ansetzen

Der Zusammenhang lautet:

ĜG = 1 + ē_t1 + ē_b,ē_t = Σ_k w_k,t e_k

(4)

G ist das Wachstumsverhältnis mit den im Beispiel korrekten Gewichten. Ĝ nutzt unsere geschätzten Gewichte. e ist der proportionale Gewichtsfehler jedes Typs und w sein Anteil am korrekt gewichteten Output. ē ist der mit diesen Anteilen gewichtete Durchschnittsfehler.

Die Fehler heben sich auf, wenn dieser Durchschnitt in beiden Zeiträumen gleich ist. Eine unveränderte Arbeitsmischung würde das schaffen. Ebenso, wenn jedes Gewicht um denselben Anteil falsch ist. Auch andere Kombinationen können sich aufheben. Diese beiden sind nicht die einzigen Möglichkeiten.

Die praktische Prüfung ist, hinzusehen, was an Anteil gewonnen hat. Stammt die scheinbare Verbesserung aus einer Kategorie, deren Gewicht wir kaum trauen, probiere plausible Alternativen. Übersteht der Gewinn das? Die Ergebnisse auf Typebene sollten neben der Summe stehen, nicht erst auf besondere Bitte der Person, die zweifelt.

Die Kategorien können eine weitere Verschiebung verdecken. Nimmt der Agent die allereinfachsten der „einfachen Fälle“, passt sich sogar mein Support-Modell mit zwei Kategorien womöglich zu wenig an. Wir müssen auch prüfen, was sich innerhalb jeder Kategorie geändert hat.

Wir können auch besser darin werden, die Arbeit zu sehen

Selbst mit perfekten Gewichten können uns die Aufzeichnungen täuschen.

Angenommen, der echte Output wächst um 10 %. Wir erfassen im ersten Zeitraum 80 % des korrekt gewichteten Outputs und im zweiten 84 %. Der beobachtete Vergleich wird:

D̂_tD̂_b = 1,10 × 0,840,80 = 1,155

(5)

Das Dashboard meldet 15,5 % Wachstum. Vier Prozentpunkte bessere Abdeckung haben dem scheinbaren Wachstum 5,5 Prozentpunkte hinzugefügt. Ohne echtes Wachstum würde dieselbe Änderung der Abdeckung 5 % hervorbringen.

Ein Agent kann ein lückenloses Protokoll von Arbeit hinterlassen, die ein Mensch in einem Gespräch erledigt hätte. Bessere Aufzeichnungen wären willkommen. Mehr Produktion wären sie von sich aus nicht.

„Abdeckung“ bedeutet in dieser Gleichung den erfassten Anteil des Outputs, auf derselben Referenzbasis gewichtet. Es heißt nicht: der Prozentsatz der Lohnsumme, der an eine Integration angebunden ist, angeschlossene Seats oder sichtbare Ausgaben.

Zu wissen, wohin 80 % des Geldes gegangen sind, sagt uns nicht, dass wir 80 % der Arbeit gefunden haben. Das folgt nur mit weiteren Annahmen über die beobachtete und die fehlende Arbeit. Behalte die Ausgabenabdeckung als nützliche Finanzprüfung. Setze sie nicht in die Output-Gleichung, nur weil sie leichter zu bekommen ist.

Deshalb habe ich das Abdeckungsbeispiel behalten, obwohl ich das System zur Beleganalyse aus diesem Beitrag heraushalte. Eine Änderung dessen, was wir sehen können, ändert die Messung, egal wie wir die Aufzeichnungen sammeln.

Mehr Aufzeichnungen lösen das nicht automatisch. Volumen kann zufälliges Rauschen senken. Eine konsistente Verzerrung kann bleiben. Vier Quartale an Daten halbieren die Unsicherheit auch nicht automatisch. Fehler, die sich über Quartale hinweg teilen, verhalten sich nicht wie unabhängige Fehler.

Ich veröffentliche lieber eine engere Serie, die wir konsistent beobachten, als eine Aussage über das ganze Unternehmen auf einer Abdeckung, die wir nicht verteidigen können. Sie braucht eine klare Grenze, dieselben Nachverfolgungsfenster und Prüfungen auf Änderungen in der Erfassung. Arbeit außerhalb dieser Grenze bleibt als ungemessene Arbeit sichtbar.

Frühere Simulationen haben mir geholfen, diese Fehler zu erkunden. Ihre numerischen Bänder habe ich nicht als Beleg dafür behalten, wie genau die Methode wäre. Dafür müssen die Implementierung und die Annahmen veröffentlicht und dann an echter Arbeit geprüft werden. Die Beispiele hier belegen die Fehlermodi, ohne so zu tun, als wüssten wir, wie oft jeder auftritt.

Irgendwann wird sogar die Baseline zum Problem

Wir können einen Gewichtssatz nicht für immer einfrieren und annehmen, das Geschäft bleibe dankenswerterweise vergleichbar. Services ändern sich. Manche verschwinden, und neue kommen ohne alten Preis.

Eine Möglichkeit ist, die Gewichte regelmäßig zu aktualisieren und jedes Paar benachbarter Zeiträume mit denselben Gewichten zu vergleichen. Eine jährliche Verkettung mit den Gewichten des Vorjahres lautet:

L_t = Σ_k n_k,t s_k,t−1Σ_k n_k,t−1 s_k,t−1

(6)

Der Zähler zählt den Output dieses Jahres mit den Gewichten des Vorjahres. Der Nenner zählt den Output des Vorjahres mit denselben Gewichten. Multipliziere die Glieder für einen länger laufenden Index.

Das vermeidet, eine Änderung der Gewichte als Änderung der Produktion auszugeben. Es hat auch einen Haken: Einzeln verkettete Komponenten addieren sich in der Regel nicht zur verketteten Summe. Das BEA warnt ausdrücklich davor, verkettete Dollar-Komponenten als additiv zu behandeln.²⁰

Baue die Unternehmensreihe also aus einer eigenen, überschneidungsfreien Menge von Outputs. Addiere nicht unabhängig entworfene Team-Dashboards und hoffe, dass sie kompatible Dinge messen. Manche interne Arbeit kann in einer Funktionssicht nützlich sein und trotzdem schon im Ende-zu-Ende-Lieferergebnis des Unternehmens stecken.

Eine geänderte Klassifikation braucht außerdem eine Brücke: einen Überlappungszeitraum, eine glaubwürdige Rekonstruktion der früheren Reihe oder einen offen gelegten Bruch. Verkettung repariert weder eine schlechte Servicedefinition noch fehlende Arbeit, die wir gerade erst gefunden haben.

Das kann uns mit brauchbaren Vergleichen auf Funktionsebene zurücklassen und ohne belastbare Summe für das Unternehmen. Damit könnte ich leben. Besser, als eine Summe zu erfinden, weil das ursprüngliche Briefing eine verlangt hat.

Manchmal macht gute Arbeit die Zahl kleiner

Angenommen, Engineering behebt den Fehler hinter tausend Support-Konversationen. Unser Support-Fall-Index meldet weniger bearbeitete Fälle.

Soll er. Es gab weniger Fälle. Der Fehler wäre, daraus zu schließen, das Unternehmen sei weniger produktiv geworden.

Auf einer weiteren Grenze versuchen wir, Kunden zu helfen, das Produkt erfolgreich zu nutzen. Diesen Service mit weniger vermeidbaren Kontakten zu erhalten oder zu verbessern kann ein erheblicher Gewinn sein. Die enge Fallzahl braucht die weitere Servicedefinition oder die Outcome-Messungen daneben.

Zuverlässigkeit und Prävention haben dasselbe Problem. Eine ruhige Bereitschaftswoche kann eine gute Woche sein. Eine nützliche Compliance-Maßnahme kann verhindern, dass ein Fall überhaupt entsteht.

Für diese Funktionen würde ich Einheiten testen, die auf dem über einen Zeitraum aufrechterhaltenen Service beruhen: was lief weiter, für wen, unter welcher Last und welchem Risiko, nach welchem Standard. Ein Eintrag im Bereitschaftsplan reicht nicht. Ich würde auch nicht den Output eines Monats auf null setzen, weil ein Schwellenwert verfehlt wurde. Die Qualitätsanpassung muss den Fehler abbilden, statt alles von einem Schalter abhängig zu machen.

Diese Einheiten sind schwerer zu definieren. Das ist Teil des Problems, das ich zu verstehen versuche, nichts, was eine Ticketzahl uns zu umgehen erlaubt.

Und Arbeit, die wir vorher nicht machen konnten?

Ein Audit-Team, das Transaktionen stichprobenartig prüfte, kann jetzt alle prüfen. Setze die alten hypothetischen menschlichen Kosten für jede zusätzliche Prüfung an, und die Output-Behauptung wird gewaltig.

Aber niemand hätte diesen manuellen Prozess unbedingt gekauft. Mehr Prüfungen bedeuten auch nicht proportional mehr Sicherheit.

Ist der neue Service mit etwas vergleichbar, das wir schon messen, können wir den geänderten Umfang oder die geänderte Qualität auf dieser Basis berücksichtigen. Wenn nicht, würde ich die Fähigkeit, ihre Kosten und das, was wir uns davon erwarten, getrennt berichten, während wir eine nützliche Definition erarbeiten.

Ich nenne das ein Capability Ledger. Es bedeutet nicht, dass die Ausgaben aktivierungsfähig sind. Es bedeutet nicht, dass wir teure Arbeit unter „Innovation“ verstecken können, sobald die Effizienzquote enttäuscht. Die Rechnung muss weiter mit den Finanzen abgestimmt sein.

Sobald der Service wiederholbar und definierbar wird, kann er unter einer ausdrücklichen Einführungsregel in den Lieferindex aufgenommen werden. Dass KI ihn ermöglicht hat, sollte ihn nicht für immer draußen halten.

Hier kommt Acemoglus Punkt zur Nachfrage der Unternehmen wieder ins Spiel. Belohnen Unternehmen nur Einsparungen bei den Arbeitskosten, kaufen sie nur Tools, die Menschen ersetzen.¹ Ein Capability Ledger ist eine Möglichkeit, die andere Sorte zu belohnen.

Mein Beitrag hier ist enger. Gib dem Unternehmen einen Ort, um zu erklären, was die Investition möglich macht, statt von jedem Projekt zu verlangen, sich als billigere alte Arbeit zu rechtfertigen. Ein Verantwortlicher, Belege und ein Prüfdatum wären ein guter Anfang. „Es ist KI“ ist kein Investitionscase.

Acemoglu argumentiert außerdem gegen steuerliche Verzerrungen, die Kapital gegenüber Arbeit bevorzugen, gestützt auf Arbeiten mit Andrea Manera und Pascual Restrepo.¹²¹ Ich bin dafür, eine künstliche Vorliebe für Ersatz zu beseitigen. Für diesen Beitrag liegt die Entscheidung aber innerhalb des Budgets: Was kostet der bestehende Service jetzt, und was können wir tun, das wir vorher nicht konnten?

Das Ledger nimmt uns diese Entscheidung nicht ab. Es sollte sie schwerer vermeidbar machen.

Würde ich das einem CFO vorlegen?

Ja, aber neben dem Rest der Rechnung, nicht als Punktzahl für das Unternehmen.

Kent Beck und Gergely Orosz machen in ihrer Antwort auf McKinsey ein starkes Argument gegen Aufwands- und Output-Ziele. Zu den eigens entwickelten Kennzahlen schreiben sie: „Customers don’t care. Executives don’t care. Investors don’t care.“ (Kunden ist es egal. Führungskräften ist es egal. Investoren ist es egal.)²²

Ich finde, diese Abfuhr geht zu weit. Ein CFO kann vernünftigerweise fragen, ob wir denselben Gehaltsabrechnungsservice auf demselben Standard mit weniger Ressourcen liefern können. Wir sollten nicht auf eine Bewegung im Unternehmensgewinn warten müssen, um zu untersuchen, warum er teurer geworden ist.

Ihr Argument ist differenzierter als dieser Satz. Sie erkennen auch den Nutzen von Aufwand und Output bei der Diagnose von Problemen an und die Gefahren, Menschen nur nach Ergebnissen zu beurteilen.¹³ In seinem Schlussabschnitt empfiehlt Orosz, Aufwand und Output zur Untersuchung von Problemen zu verwenden, statt sie zu öffentlichen Erfolgsmaßen zu machen.

Das ist die engere Meinungsverschiedenheit, die sich lohnt. Ich glaube, dass ein regelmäßig berichteter Vergleich von Output und Kosten eines definierten Services neben den Ergebnissen helfen könnte. Er muss seine Kosten und seine Wirkung auf das Verhalten rechtfertigen. Ein wunderschönes Dashboard, das das Team in Vollzeit-Dashboard-Optimierer verwandelt, ist gescheitert.

Das wäre grob das, was ich sehen möchte:

Die Outcome-Maße sollten je nach Funktion verschieden sein. Bookings gehören in ein Vertriebsgespräch. Als Abnahmetest für Rechtsberatung taugen sie nicht. Ich zeige diese Unterschiede lieber, statt sie in einem „Impact-Multiplikator“ zu verstecken.

Auf Unternehmensebene muss die Finanzrechnung auch abbilden, wie wir die Arbeit eingekauft haben. Der Umsatz pro Mitarbeiter kann nach einer Auslagerung steigen, selbst wenn die gesamten Lieferkosten steigen. Addiere die relevanten zugekauften Services und KI-Kosten, bevor du entscheidest, das Geschäft sei effizienter geworden. Der Umsatz hat außerdem andere Treiber, also schreibt diese Quote die Veränderung nicht der KI zu.

Ich würde den Lieferindex nicht benutzen, um Einzelne zu ranken. Seine Gewichte beschreiben Klassen von Arbeit, nicht den vollen Beitrag einer Person. Mentoring, Unterbrechungen und jemandem beim Abschließen eines Jobs zu helfen passen nicht in die Output-Zahl eines Einzelnen. Koppelst du Gehalt an den Index, geben wir den Leuten einen Grund, für größere Gewichte und mehr zählbare Arbeit zu argumentieren.

Selbst der Vergleich von KI-unterstützter und rein menschlicher Arbeit braucht dieselbe Sorgfalt wie das Eingangsbeispiel. Die Zuweisungen können sich innerhalb einer Kategorie unterscheiden. Zu wissen, dass ein Agent beteiligt war, beweist nicht, dass er die Verbesserung verursacht hat.

Und ein fertiges Artefakt beweist nicht, dass die verantwortliche Person es verstanden hat. Das ist ein anderes Problem, besonders wenn wir behaupten, der Zweck sei, Menschen leistungsfähiger zu machen.

Der Test, den ich noch nicht gemacht habe

Ich habe gezeigt, wie sich ein paar Rechnungen mit Inputs verhalten, die ich selbst gewählt habe. Ich habe Methoden aus der Buchhaltung geborgt und aus den Einwänden anderer gelernt. Nichts davon sagt mir, ob zwei Teams diesen Vorschlag an echter Arbeit anwenden und zu einem nützlichen Ergebnis kommen können.

Das ist der nächste Test.

Ich würde mit drei Settings anfangen: einem wiederholbaren Fall- oder Transaktions-Workflow, einem Projekt-Workflow und einem laufenden Service. Für jedes schreibe ich Einheit, Umfang und Berichtsgrenze auf, bevor ich die Ergebnisse sehe. Dazu die Abschlussregel, die Behandlung der Qualität, die Referenzgewichte und die Kostenbasis. Sage, was mit nicht zugeordneter Arbeit und späteren Korrekturen passiert.

Dann gib einem anderen kompetenten Team dieselben Belege. Kann es die Rechnung nachvollziehen? Wo gehen die Meinungen darüber auseinander, was hineingehört?

Die Arithmetik sollte leicht abzustimmen sein. Das Export-Beispiel zeigt, wo der echte Streit liegen wird. Kehren zwei vernünftige Kategorienwahlen das Gesamtergebnis um, muss der Bericht das zeigen, statt die Meinungsverschiedenheit mit einer Dezimalstelle zu erledigen.

Wähle Referenzklassen und schätze ihre Gewichte anhand einer Arbeitsmenge, dann teste sie an einer anderen. Nimm ausgeschlossene Einträge und Arbeit außerhalb des Haupt-Tracking-Systems in die Prüfung auf. Zeichne die Kategorien nicht neu, bis die Historie überzeugend aussieht.

Wiederhole die Tests mit geteilten Tickets, zusammengelegten Tickets, Umorganisation und Auslagerung. Prüfe auf Änderungen in der Erfassung. Die Summe des Unternehmens sollte sich nicht bewegen, wenn wir nur geändert haben, wie wir dieselbe Arbeit beschreiben oder einkaufen.

Teste diese Buchhaltung zuerst mit einer unabhängig erstellten Darstellung der Arbeit. Ob eine Maschine diese Darstellung aus den vorhandenen Systemen rekonstruieren kann, ist ein späterer Implementierungstest. Wenn Menschen mit ausreichenden Belegen sich nicht auf die Einheiten einigen können, rettet auch ein besserer Klassifikator die Definition nicht.

Zu testen, ob KI eine Verbesserung verursacht hat, ist eine andere Aufgabe. Zufällig verteilter Zugang kann helfen, wo er machbar ist, ebenso ein sorgfältig entworfener gestaffelter Rollout mit einer glaubwürdigen Vergleichsgruppe. Lerneffekte, Spillovers, Aufgabenauswahl und gleichwertige Qualitätsnachverfolgung zählen alle. Begeisterte und zögerliche Anwender sind nicht automatisch vergleichbar, weil sie denselben Jobtitel haben.

Wie genau muss das Maß sein? Das hängt von der Entscheidung ab. Ein grobes Signal dafür, wo man nachsehen sollte, hat eine andere Beweislast als Belege, die für Personalabbau oder berichtete Einsparungen genutzt werden. Der akzeptable Fehler sollte sich nach dieser Entscheidung richten, nicht nach einer universellen Audit-Stichprobengröße.

Veröffentliche Definitionen, Rechnung und Revisionsregeln zusammen mit dem Ergebnis. Meine Messlatte ist, dass ein anderes Team die Methode anwenden, ihre Entscheidungen anfechten und sehen kann, ob die Schlussfolgerung hält. Die Anerkennung durch einen Buchhalter oder eine beeindruckend aussehende Gleichung würde nicht reichen.

Ich habe jetzt eine bessere Frage

Ich bin mit „Hat KI uns produktiver gemacht?“ gestartet. Jetzt will ich wissen, welcher Service sich geändert hat, ob wir dasselbe zählen und wohin die freigesetzte Kapazität gegangen ist. Diese Fragen sind auf einer Folie unbequemer. Sie sind viel nützlicher, wenn jemand fragt, was wir als Nächstes tun sollen.

Das ist für Flowstate wichtig, weil genau das Problem, das wir lösen wollen, darin besteht, Arbeit mit den Ressourcen dahinter zu verbinden. Ich will nicht, dass das Produkt davon abhängt, eine Formel zu verteidigen, an die ich beim Schreiben eines Blogposts Gefallen gefunden habe. Wenn echte Arbeit das Modell bricht, muss sich das Modell ändern.

Ich will weiterhin, dass Agenten die repetitive Arbeit aus den Tagen der Menschen nehmen. Ich will, dass ein Unternehmen den Nutzen erkennt, wenn jemand Zeit zum Nachdenken bekommt, einer Kollegin hilft oder etwas Neues ausprobiert, statt mehr Tickets zu verlangen, um zu beweisen, dass der Softwarekauf funktioniert hat.

Ich weiß nicht, wie viel davon in einen Index passt. Vielleicht weniger, als ich gehofft habe. Ein nützliches Ergebnis könnte eine Reihe von Vergleichen sein, denen wir trauen, mit den Lücken, die offen sichtbar bleiben.

Wenn der Agent die einfachen Fälle nimmt, sollten die verbleibenden Menschen keine Aktivität fabrizieren müssen, um sich zu verteidigen. Wenn jemand eine Einsparung behauptet, sollten wir fragen können, wohin sie gegangen ist. Und wenn die vorgeschlagene Zahl die Frage nicht beantwortet, sollten wir das sagen, bevor sie zu jemandes Ziel wird.

Ich bin losgezogen, um ein Maß zu finden. Gelandet bin ich bei einer Methode, die ich testen würde, und einer ziemlich langen Liste von Gründen, vorsichtig zu sein. Gemessen daran, wo ich angefangen habe, nenne ich das Fortschritt.

Technische Notizen

Das sind die Rechnungen hinter den Beispielen. Die Annahmen sind wichtig: Eine Identität kann exakt sein, ohne uns zu sagen, wie genau wir ihre Inputs in einem Unternehmen schätzen können. Die Verhältnisse unten setzen positive Referenzgewichte und Nenner ungleich null voraus.

Die Gewichtsfehler-Identität

Das festgelegte korrekte Referenzgewicht für Typ k sei s, und das geschätzte Gewicht sei:

ŝ_k = s_k(1 + e_k)

(7)

Für korrekt gezählten Output definieren wir die korrekt gewichtete Summe und den Anteil jedes Typs als:

D_t = Σ_k n_k,t s_k,w_k,t = n_k,t s_kD_t

(8)

Dann gilt:

D̂_t = Σ_k n_k,t s_k(1 + e_k) = D_t(1 + ē_t)

(9)

Das Verhältnis zwischen den Zeiträumen ergibt die oben verwendete Identität. Sie setzt feste proportionale Gewichtsfehler je Typ, korrekte Mengen und eine gemeinsame Output-Definition voraus. Sie modelliert weder ausgelassene Arbeit noch wechselnde Klassifikationen oder unsichere Lieferabgrenzungen.

Für kleine Fehler beträgt der relative Fehler des Wachstumsverhältnisses näherungsweise:

ĜG − 1 ≈ Σ_k (w_k,t − w_k,b) e_k

(10)

Sind die Typfehler zusätzlich unabhängige Zufallsvariablen mit Mittelwert null und gemeinsamer Standardabweichung, ist die Standardabweichung dieses Wachstumsverhältnis-Fehlers in erster Ordnung:

σ_G ≈ σ_e √Σ_k (w_k,t − w_k,b)²

(11)

Unter genau diesen Annahmen ergibt die Verschiebung von zwanzig Prozentpunkten Outputanteil zwischen zwei Typen bei einer Fehler-Standardabweichung von 20 % einen relativen Fehler des Wachstumsverhältnisses von etwa 5,66 %, eine Standardabweichung. Das ist kein empirisch belegtes Fehlerband, und es ist im Allgemeinen nicht dieselbe Zahl in Prozentpunkten des berichteten Wachstums. Korrelierte oder systematisch verzerrte Standards verlangen eine andere Rechnung.

Abdeckung ist in der Identität ein Output-Begriff

Im Beispiel mit reiner Abdeckung sei c der Anteil des korrekt gewichteten Outputs, der in den Aufzeichnungen sichtbar ist, ohne falsch positive Treffer und ohne andere Fehler. Dann ist der beobachtete Output c mal der vollständige Output, also:

D̂_t / D̂_bD_t / D_b = c_tc_b

(12)

Die Gleichung ist unter diesen Definitionen exakt. c zu schätzen ist der schwierige Teil. Ein Verhältnis von angebundenen Ausgaben zu Gesamtausgaben ist eine andere Statistik und kann nicht ohne ein ausdrückliches Modell eingesetzt werden, das Ressourcenabdeckung mit Produktionsabdeckung verknüpft.

Auch die Abgrenzung der Buchhaltung zählt hier. Einen Teil des Outputs zu beobachten und dabei die gesamte Kostenbasis zu verwenden schätzt nicht dasselbe Objekt wie das Messen von Output und Kosten für einen bewusst eingegrenzten, konsistent beobachteten Service. Keines von beiden sollte ohne Begründung in Gesamtunternehmenseffizienz umetikettiert werden.

Warum die Gesamtgenauigkeit eines Klassifikators nicht reicht

Für ein einfaches binäres Erkennungsproblem mit korrekt zugewiesenen, festen Gewichten definiere die Summen der richtig positiven, falsch positiven und falsch negativen Fälle über diese Gewichte statt über Stückzahlen. Die gewichtete Precision ist das richtig positive Gewicht geteilt durch das gesamte erkannte Gewicht. Der gewichtete Recall ist das richtig positive Gewicht geteilt durch das gesamte berechtigte Gewicht. Wo die Nenner ungleich null sind:

erkanntes Gewichtberechtigtes Gewicht = gewichteter Recallgewichtete Precision

(13)

Gewöhnliche zählbasierte Precision und Recall liefern diese Identität für einen kostengewichteten Index nicht. Eine Fehlklassifikation, die das Gewicht eines erkannten Eintrags ändert, braucht eine zusätzliche Behandlung. Ebenso Kandidaten, die nie gefunden wurden, und unsichere Beziehungen zwischen Eltern- und Kindeinträgen. Diese Fehler in einer einzigen multiplikativen Gleichung zu kombinieren verlangt kompatible Definitionen. Es ist nicht schon deshalb gerechtfertigt, weil jeder Term einen plausiblen Namen hat.

Probabilistische Erkennung ist möglich, aber ein vorgeschlagener Schätzer muss Klassifikationen gegenseitig ausschließend halten und überlappende Lieferergebnisse vermeiden. Eine Sammlung unabhängig bewerteter Tickets erfüllt diese Bedingungen nicht automatisch. Kalibrierte Wahrscheinlichkeiten behandeln Unsicherheit bei beobachteten Kandidaten, nicht Arbeit, die in der Kandidatenmenge ganz fehlt.

Was eine Audit-Stichprobe leisten kann

Die bekannte Schätzung von 385 Beobachtungen stammt aus einer bestimmten Rechnung: einer einfachen Zufallsstichprobe eines unabhängigen binären Anteils, einem 95-%-Intervall in Normalapproximation, einem Worst-Case-Anteil von einem Halben und einer Fehlermarge von fünf Prozentpunkten. Die ungerundete Stichprobengröße ist:

n ≈ 1,96² × 0,5 × 0,50,05² = 384,16

(14)

Sie belegt nicht, dass 385 Einträge Referenzkosten kalibrieren, jeden Arbeitstyp validieren oder eine kleine Veränderung zwischen Zeiträumen auflösen. Stratifizierung, Clustering, ungleiche Gewichte, seltene teure Fälle und Uneinigkeit der Prüfer verändern das nötige Design. Audit-Planung sollte von dem Fehler ausgehen, der die Geschäftsentscheidung ändern könnte, nicht von einer vertrauten runden Zahl.

Reproduzierbarkeit und Deutung

Die durchgerechneten Beispiele nutzen die genannten Inputs. Sie sind keine Schätzungen für typische Unternehmensleistung. Numerische Monte-Carlo-Fehlerbänder bräuchten außerdem die veröffentlichte Implementierung, Parameterverteilungen, Abhängigkeitsannahmen und Random Seeds. Wir müssten dann klären, welche Annahmen zur beobachteten Arbeit passen, bevor wir die Bänder als erwartete Genauigkeit deuten.

Die Liefersumme hat die Einheit einer Referenzkostenwährung. Ein Präsentationsindex kann diese Summe im Basiszeitraum auf 100 normieren. Der Kosteneffizienzindex nutzt diese Normierung bereits. Keiner von beiden misst ökonomischen Wert, kausale KI-Wirkung oder den Wert eines Mitarbeiters.

Will Hackett ist Mitgründer und CTO von Flowstate.

Footnotes

1. Daron Acemoglu, Will AI Replace Workers? Not If We Build It Right., The Humanist Review of AI, 15. Juli 2026. Plädiert für Tools, die Beschäftigte ergänzen, und für eine Unternehmensnachfrage, die auf Produktivität und Innovation statt allein auf Einsparungen bei den Arbeitskosten ausgerichtet ist. Die Verbindung zum hier beschriebenen Berichtsdesign ist meine eigene Schlussfolgerung, keine Methode, die dieser Essay vorschlägt. Quelle. ↩ ↩² ↩³

2. National Association of Letter Carriers, The Remote Encoding Center: Where bad addresses go to get better, The Postal Record, Juli 2022, S. 34 und 35. Der Bericht beschreibt, dass Maschinen leichtere Adressbilder übernehmen und schwierigere für menschliche Erfasser übrig lassen. Quelle. ↩

3. Intercom, How Fin AI Agent and Copilot Cut Handle Time and Boost Agent Productivity. Die Diskussion der verbleibenden menschlichen Fallmenge ist Anbieterkommentar, der den Mechanismus der Arbeitsmischung stützt, kein unabhängiger Beleg für die Größe eines Produktivitätsgewinns. Quelle. ↩

4. Erik Brynjolfsson, Danielle Li und Lindsey Raymond, Generative AI at Work, The Quarterly Journal of Economics 140(2), 2025, S. 889 bis 942. Die veröffentlichte Studie berichtet von durchschnittlich 15 % mehr gelösten Fällen pro Stunde in ihrem Kundensupport-Setting, mit unterschiedlichen Geschwindigkeits- und Qualitätseffekten bei verschiedenen Beschäftigten. Veröffentlichter Artikel. Zusammenfassung der Autoren. ↩

5. Joel Becker, Nate Rush, Beth Barnes und David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10. Juli 2025. Das Ergebnis betrifft die teilnehmenden erfahrenen Entwickler, ihre Repositories und die in diesem Experiment verfügbaren Tools. Quelle. ↩

6. Joel Becker und Kollegen, We are Changing our Developer Productivity Experiment Design, METR, 24. Februar 2026. Das Follow-up behandelt die Auswahl der Teilnehmer, die Auswahl der Aufgaben und die Schwierigkeiten, Zeit bei gleichzeitig laufenden Agenten zu messen. Quelle. ↩

7. McKinsey, The state of AI in 2026: On the road to ROI, 25. August 2026. Die Antworten stammen von 1.719 Teilnehmern, erhoben zwischen dem 4. Mai und dem 8. Juni 2026. Die berichteten 80 % bei der individuellen Produktivität und 37 % bei der EBIT-Wirkung beantworten verschiedene Fragen. Quelle. ↩

8. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck und Jenna Butler, The SPACE of Developer Productivity: There’s more to it than you think, ACM Queue 19(1), 2021. Argumentiert, dass sich Entwicklerproduktivität nicht in einer einzigen Kennzahl oder Dimension erfassen lässt. Der hier vorgeschlagene begrenzte Lieferindex wird nicht als Ersatz für dieses Framework dargestellt. Quelle. ↩

9. Alessandro Berti und Kollegen, OCEL (Object-Centric Event Log) 2.0 Specification, arXiv:2403.01975, eingereicht am 4. März 2024. Die Spezifikation unterstützt Ereignisse und Beziehungen, an denen mehrere Geschäftsobjekte beteiligt sind. Sie ist ein Darstellungsstandard, keine Produktivitätskennzahl. Quelle. ↩

10. ACCA, The standard hour in performance measurement. Standardstunden liefern ein gemeinsames Aktivitätsmaß für heterogene Produkte und stützen getrennte Kennzahlen für Volumen, Auslastung und Effizienz. Quelle. ↩

11. Office for National Statistics, Public service productivity estimates: sources and methods, überarbeitet am 1. Mai 2026, insbesondere Abschnitt 1 zu Output, Inputs und Indexzahlen. Die Methodik nutzt kostengewichtete Aktivitätsmaße für einen großen, aber nicht den gesamten Teil des öffentlichen Dienstleistungs-Outputs. Quelle. ↩ ↩²

12. Ron Jeffries, Story Points Revisited, 23. Mai 2019. Seine eingeschränkte Entschuldigung dafür, möglicherweise Story Points erfunden zu haben, ist hier die Referenz, kein Beleg gegen jede Form relativer Schätzung. Quelle. ↩

13. Gergely Orosz und Kent Beck, Measuring developer productivity? A response to McKinsey, Part 2, The Pragmatic Engineer, 31. August 2023. Ihre gemeinsame Diskussion behandelt Anreize, die nur auf Ergebnissen beruhen. Der gesondert gekennzeichnete Schlussabschnitt stammt von Orosz und enthält das Beispiel der aufgeblähten Schätzungen sowie die Empfehlung, Aufwand und Output zur Diagnose zu nutzen statt als öffentliche Erfolgsmaße. Quelle. ↩ ↩²

14. Alex Tamkin und Peter McCrory, Estimating AI productivity gains from Claude conversations, Anthropic, 25. November 2025. Die Prüfung an Softwareaufgaben berichtet Spearman-Korrelationen von 0,44 für Claude und 0,50 für Entwickler, neben komprimierten Modellschätzungen. Gute Rangfolgen belegen keine Kalibrierung in Stunden. Quelle. ↩

15. Intercom, Fin AI Agent outcomes, Dokumentation geprüft am 7. Oktober 2026. Siehe „Resolution definition“ und die Erklärung, dass spätere Anfragen nach weiterer Hilfe in derselben Konversation die Lösungsgebühr zurücknehmen. Die durchgerechneten Beispiele in diesem Beitrag verwenden nicht Fins tatsächliche Preise. Quelle. ↩

16. Tejal Patwardhan und Kollegen, GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks, 2025, Anhang A.2.1 und Tabelle 2. Die Review-and-Redo-Szenarien verwenden festgelegte Annahmen und lassen für die menschliche Vergleichsbasis eine vergleichbare Behandlung von Review und Fehlern aus. Sie sollten nicht als allgemeine Schätzungen für Einsparungen am Arbeitsplatz gelesen werden. Quelle. ↩

17. Ralf Seifert, Richard Markoff und Matthew Spooner, How a new approach to demand planning can redefine success, I by IMD, 5. August 2024. Behandelt Forecast Value Added und die Möglichkeit, dass eine bessere Baseline den inkrementellen Beitrag menschlicher Anpassungen verringert. Quelle. ↩

18. Tom Cunningham und Parker Whitfill, Task Substitution and Uplift, METR, 8. Mai 2026. Unterscheidet Uplift bei alten Aufgaben, neuen Aufgaben und Wert, mit unter ausdrücklichen Annahmen abgeleiteten Beziehungen. Quelle. ↩

19. Robert S. Kaplan und Steven R. Anderson, Rethinking Activity-Based Costing, Harvard Business School Working Knowledge, 24. Januar 2005. Unterscheidet bereitgestellte von verbrauchter Kapazität und behandelt Chancen, die aus ungenutzter Kapazität entstehen. Quelle. ↩

20. US Bureau of Economic Analysis, Chained-dollar estimates. Vermerkt die Nichtadditivität außerhalb des Referenzjahres und warnt davor, Komponenten wie gewöhnliche additive Dollarwerte zu behandeln. Quelle. ↩

21. Daron Acemoglu, Andrea Manera und Pascual Restrepo, Does the U.S. Tax Code Favor Automation?, Brookings Papers on Economic Activity, Frühjahr 2020. Analysiert steuerliche Behandlung, die Investitionen in Ausrüstung und Software gegenüber Arbeit bevorzugt. Die historischen Schätzungen in diesem Paper sind keine Berechnung der aktuellen steuerlichen Behandlung eines bestimmten Unternehmens. Quelle. ↩

22. Gergely Orosz und Kent Beck, Measuring developer productivity? A response to McKinsey, The Pragmatic Engineer, 29. August 2023, insbesondere Abschnitt 4. Die zitierte Abfuhr betrifft McKinseys eigens entwickelte Aufwands- und Output-Kennzahlen, nicht jede mögliche Form operativer Messung. Quelle. ↩