De onmogelijkheid om AI-productiviteit te meten

Dit is een lang stuk, sorry. Ik heb eerder geschreven dat ik vaak schrijf als ik iets probeer uit te zoeken. Deze vraag houdt me al een tijd bezig, en elke keer dat ik dacht dat ik hem had beantwoord, vond ik weer iets mis met het antwoord.

Bij Flowstate vragen mensen ons regelmatig hoe je het rendement van AI-investeringen meet. Soms willen ze weten of hun teams productiever zijn. Soms hebben ze gewoon iets geloofwaardigs nodig om aan het bestuur te laten zien als dat naar de rekening vraagt. Terecht.

Ik vind dit om meer redenen interessant dan dat mijn bedrijf het moet kunnen beantwoorden. Ik geloof dat AI mensen veel capabeler kan maken, en ik wil dat we daarnaartoe bouwen. Laat agents het repetitieve rotwerk doen. Geef mensen meer tijd voor het werk dat ze echt willen doen, inclusief dingen die ze zich eerder niet konden veroorloven.

Dat is een groot deel van de gedachte achter Flowstate. Maar ik mag niet aannemen dat het gebeurt, alleen omdat ik het idee mooi vind.

Ik lees The Humanist Review, en verdomme, wat staat daar goed werk. Serieus, ga kijken. Het essay van Daron Acemoglu over AI en werk is de moeite waard om helemaal te lezen, maar deze zin over het bedrijfsleven bleef bij me hangen:¹

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

Ik denk dat hij gelijk heeft. Als ik de zaak voor AI helemaal opbouw rond salarissen die het kan vervangen, mag ik niet raar opkijken als het gesprek over banen schrappen gaat. Ik leg liever uit wat het team nu kan wat eerder niet kon. Of dat het afschaffen van een zielloos proces iemands werkdag echt beter heeft gemaakt.

Het probleem is dat aan te tonen. Iemand die zegt dat hij een uur per dag bespaart, is interessant, maar ik wil nog steeds weten wat er veranderd is. Kreeg diegene meer gedaan? Had hij eindelijk tijd om ergens goed over na te denken? Misschien bespaarde de tool hem een uur en gaf hij een ander een uur controlewerk.

Dus ging ik op zoek naar een manier om het werk dat een bedrijf doet te vergelijken met wat het eraan uitgeeft. Het liefst iets dat werkt voor verschillende teams, of het werk nu door medewerkers, freelancers, een dienstverlener of agents wordt gedaan. Ik verwachtte niet dat elke afdeling dezelfde opvatting van succes zou hebben. Ik hoopte wel dat we het over een deel van de boekhouding eens konden worden.

Ik ben uitgekomen bij een aanpak die volgens mij het testen waard is, niet bij een antwoord dat ik iedereen zou aanraden. Nogal wat van mijn eerdere ideeën klopten niet. Ik heb de nuttige fouten laten staan, want uitleggen waarom ze faalden helpt waarschijnlijk meer dan doen alsof ik de huidige versie met uitzonderlijk inzicht heb bereikt.

Het eerste probleem is makkelijk te laten zien: geef een agent de simpele supportvragen, en de mensen die de lastige overhouden kunnen ineens slechter lijken in hun werk.

Blijkbaar maakte het team helpen het slechter

Neem een supportteam dat per maand 800 eenvoudige en 200 lastige gevallen afhandelt. Een eenvoudig geval kost zes minuten menselijke afhandeling. Een lastig geval dertig. Alle worden tot dezelfde standaard opgelost.

Dit zijn verzonnen getallen.

Voor AI had dit hypothetische team 180 afhandeluren nodig voor zijn 1.000 gevallen. Dat is 5,56 gevallen per uur.

Nu handelt een agent 600 van de eenvoudige gevallen af. De mensen houden 200 eenvoudige en 200 lastige gevallen over: 120 uur voor 400 gevallen, oftewel 3,33 per uur.

Het dashboard meldt een daling van 40% in het tempo van het menselijke team. De gemiddelde afhandeltijd gaat van 10,8 minuten naar 18.

Niemand is langzamer geworden. De mensen hebben de moeilijkere gevallen. De makkelijke trokken het gemiddelde omlaag, en die zijn nu weg.

Het bedrijf krijgt nog steeds alle 1.000 gevallen opgelost en heeft zestig uur minder menselijke afhandeling nodig. Waar die uren op neerkomen, komt later. Voor nu geldt: het team vragen zijn oude gemiddelde terug te halen zou een behoorlijk domme reactie zijn op een verandering die we bewust hebben doorgevoerd.

Geef de eenvoudige gevallen aan een agent

i

Eenvoudig, mensenLastig, mensenEenvoudig, agent

Eenvoudige gevallen die de agent per maand oplost600 van 800

Gevallen per persoonsuur

5,56 → 3,33

Afhandeluren door mensen

180 → 120

Erkende oplevering

$7.200 → $7.200

Toegerekende afhandelkosten

$7.200 → $5.280

Werkelijke uitgaven, loonkosten ongewijzigd

$7.200 → $7.680

Gevallen per persoonsuur dalen met 40%. Dezelfde 1.000 gevallen worden nog steeds opgelost, en 60 afhandeluren zijn vrij voor iets anders.

Dit gebeurde al voor er chatbots waren. Het Remote Encoding Center van de US Postal Service verwerkt adresafbeeldingen die machines niet kunnen ontcijferen. Een verslag uit 2022 beschrijft hoe machines de makkelijkere afbeeldingen oppakten en mensen achterlieten met de afbeeldingen die meer tijd kostten om te lezen.² De video van Tom Scott uit het centrum is nog steeds een van mijn favoriete voorbeelden van een geautomatiseerd systeem dat een bedrijfsproces verandert, jaren voordat iemand het AI noemde. Intercom maakt dezelfde opmerking over de menselijke caseload die overblijft na support-automatisering.³

Er is ook goed onderzoek dat precies het tempo gebruikt dat ik net bekritiseerde. In Generative AI at Work melden Erik Brynjolfsson, Danielle Li en Lindsey Raymond gemiddeld 15% meer opgeloste issues per uur. Hun AI-assistent hielp de mensen die klanten te woord stonden. Hij nam geen aparte wachtrij met eenvoudige gevallen over. Ze keken ook naar kwaliteit en naar hoe het werk beleefd werd.⁴

Ik ben het er niet mee oneens om in die situatie gevallen te tellen. Ik ben het er niet mee eens dat ze nog vergelijkbaar zijn nadat je hebt veranderd welke gevallen de mensen krijgen. “Gevallen per uur” kan nuttig zijn. Het heeft wel een beschrijving van de gevallen nodig.

En zelfs in mijn nette voorbeeld kan een dag met minder makkelijke vragen een zwaardere dag zijn. Niets in de tabel zegt of het werk beter is geworden.

Wat vragen we eigenlijk?

Hebben we meer opgeleverd? Hadden we er minder middelen voor nodig? Heeft het werk iets nuttigs bereikt? Hadden de mensen die het deden een betere dag?

Dat zijn verschillende vragen. Ik heb me er schuldig aan gemaakt “productiviteit” te behandelen alsof het alle vier beantwoordt.

Aantallen vertellen ons over volume. Kosten vertellen wat we erin stopten. Doorlooptijd vertelt hoe lang iemand wachtte. Omzet en marge doen ertoe, maar ze vertellen niet wat er binnen elk team gebeurde. Een enquête waarin je mensen vraagt of ze zich sneller voelen ook niet.

Het ontwikkelaarsexperiment van METR uit begin 2025 maakt dat laatste punt vrij pijnlijk. Ervaren ontwikkelaars die in bekende open-sourcerepositories werkten, deden er 19% langer over met de beschikbare AI-tools. Achteraf schatten ze nog steeds dat de tools hen 20% sneller hadden gemaakt.⁵ Dat is een resultaat van die ontwikkelaars en die tools, geen oordeel over coding agents in 2026. METR’s update van februari 2026 zegt dat nieuwere tools waarschijnlijk meer helpen, en legt uit waarom selectie-effecten die verbetering lastig te schatten maken.⁶

Er is, onvermijdelijk, een McKinsey-enquête. In de resultaten van augustus 2026 zei 80% van de respondenten dat AI hun eigen productiviteit verbeterde. Slechts 37% schreef er enige invloed op de bedrijfswinst aan toe.⁷ Een handig gat voor een adviesbureau om te vinden. Ook twee verschillende zelfgerapporteerde vragen, dus we kunnen het ene percentage niet van het andere aftrekken en dan verklaren dat het ontbrekende voordeel is gestolen.

Het SPACE-framework hielp me een grens om de vraag te trekken. Nicole Forsgren, Margaret-Anne Storey en hun medeauteurs stellen dat de productiviteit van ontwikkelaars niet met één maatstaf of dimensie te vangen is.⁸ Daar ben ik het mee eens. Een maat voor leverefficiëntie kan nog steeds nuttig zijn. Hij moet alleen ophouden te beweren dat hij al het andere beschrijft.

Ik noem het voorstel een gestandaardiseerde opleverindex. Hij gaat over het geleverde werk en de middelen erachter. Het bedrijfsresultaat en de ervaring van het werk zelf hebben hun eigen bewijs nodig.

Ik probeerde de cijfers die we al hadden

Elk zag er redelijk uit, tot ik er een lastig voorbeeld op losliet.

De tabellen zijn geen reden om elke bestaande maatstaf weg te gooien. Ik had delen van meerdere nodig. Wat steeds misging, was de aanname dat één ervan het hele werk kon doen.

Ik testte de kandidaten op elf verzonnen gevallen, waaronder een agent die het makkelijke werk pakt en een team dat in tweeën splitst. In mijn werknotities staan de gevallen, de dummydata en de berekeningen. Zie het als een verslag van hoe het idee veranderde, niet als elf tests die bewijzen dat de eindversie in een bedrijf werkt.

Werk is geen ticket

Mijn eerste definitie was lekker strak: tel werk waar iemand om vroeg en dat werd geaccepteerd.

Helaas bestond het bedrijf dat ik had beschreven niet.

Bij Flowstate loopt onze eigen Linear-opzet bijna altijd achter op het werk dat daadwerkelijk wordt gedaan. Ik heb geen historische studie van issue trackers nodig om dat probleem te herkennen.

Een engineer merkt iets op, bespreekt het, lost het op en maakt ergens onderweg een ticket aan. Een klant opent een gesprek in Intercom. Er komt een factuur binnen. Een jurist geeft advies in een gesprek. De engineer met bereikbaarheidsdienst gaat op onderzoek uit omdat de dienst draaiende houden al zijn verantwoordelijkheid is.

Werk wordt niet legitiem doordat je het achter een goedkeuringsknop zet. De persoon die het record aanmaakt, is ook niet per se degene die het werk nodig had.

Wat ik probeer te tellen is een bedrijfsresultaat of dienst met een doel, een scope en een afrondingsvoorwaarde die we kunnen uitleggen. Een verzoek kan die dingen vastleggen. Een afgesproken doelstelling, een klantprobleem of een vaste verantwoordelijkheid ook. Een engineer hoort niet te hoeven wachten tot een andere afdeling een beveiligingsfix in opdracht geeft voordat die meetelt.

De definities zullen per functie verschillen. Ik zie geen manier om daaromheen te komen.

Dit zijn geen alternatieve namen voor rijen in een database. Een gemergede wijziging kan onvolledig zijn. Een factuur die als betaald is gemarkeerd, kan fout zijn. Een stille klant kan tevreden zijn of er helemaal klaar mee.

Het bewijs ligt verspreid. Eén incident kan een supportgesprek achterlaten, een engineering-issue, drie pull requests en een vervolgmail. Zes records tellen bewijst geen zes outputs. Object-centric process mining is hier nuttig, omdat het gebeurtenissen weergeeft die aan meerdere bedrijfsobjecten hangen.⁹ Het helpt de records aan elkaar te koppelen. Het bepaalt niet waar het incident voor moet tellen.

Of bedrijven de relevante context willen delen, en of AI die betrouwbaar kan interpreteren, zijn aparte problemen. Die laat ik buiten dit stuk. Neem voor de boekhouding aan dat we een voldoende goed beeld van het werk en de kosten kunnen krijgen, via menselijke review, automatisering of allebei.

Dan blijft er een lastige vraag over: wat tellen we, gegeven het bewijs? Ontbrekend bewijs moet werk onbeslist laten, niet waardeloos verklaren. Anders bouw ik een maat voor wie de enthousiaste afrondingsnotities schrijft.

De accountants zijn hier al eerder geweest

Het supportvoorbeeld heeft een manier nodig om zes minuten werk van dertig te onderscheiden. Dit deel is in elk geval niet nieuw.

ACCA beschrijft standaarduren als een manier om verschillende producten in één productiemaat te combineren. Het scheidt hoeveel er is geproduceerd, hoeveel van de beschikbare capaciteit is gebruikt en hoe efficiënt.¹⁰ Het ONS gebruikt kostengewogen activiteitenindices voor veel van de output van overheidsdiensten.¹¹

Ik leen die structuur: tel outputs per type en gebruik dan stabiele referentiegewichten om ze op te tellen. Dat geeft ons een schaal zonder dat elke interne dienst een verkoopprijs nodig heeft.

Het ONS geeft ook een nuttige toets op mijn ambitie. Ongeveer een derde van de output van overheidsdiensten die onder zijn methodologie valt, gebruikt nog steeds een conventie waarbij inputs gelijk zijn aan outputs, waardoor de productiviteit voor dat deel constant is.¹¹ Dat er kostengewogen metingen bestaan, betekent niet dat iemand al heeft uitgezocht hoe je elke dienst meet.

Terug naar support. Bij een referentieuurtarief van $40 per uur krijgt een eenvoudige oplossing een gewicht van $4 en een lastige een gewicht van $20. Vermenigvuldig elk aantal met zijn gewicht en tel op:

D = 800 × 4 + 200 × 20 = 7.200

(1)

We krijgen $7.200 voor de agent en $7.200 erna. Het bedrijf kreeg dezelfde 800 eenvoudige en 200 lastige oplossingen. Door er 600 goedkoper te maken, verdwijnen ze niet uit de output.

Algemeen geschreven is dat:

D_t = Σ_k n_k,t s_k,b

(2)

D is de geleverde output in dollars tegen referentiekosten. n is het aantal van elk type en s zijn end-to-end referentiekosten. t geeft de periode aan die we meten en b de referentieperiode. De som loopt over de soorten werk.

Die dollars zijn geen omzet of besparing. Ze laten ons hoeveelheden ongelijksoortig werk vergelijken met één verklaarde set gewichten.

Ik probeerde het gewicht eerst te rechtvaardigen met het argument dat historische kosten een ondergrens voor waarde zijn. Een bedrijf betaalt toch niet vier uur voor werk dat minder waard is dan vier uur?

Een buitengewoon royale inschatting van hoe bedrijven beslissingen nemen. Bedrijven kopen dingen die ze niet zouden moeten kopen, en verstandige investeringen kunnen mislukken. De oude kosten zeggen iets over de productie. Ze bewijzen niet wat het resultaat waard was.

Voor een echt bedrijf zou de standaard de relevante mix van mensen, tools, agents en ingekochte diensten omvatten. Waar we geloofwaardige rolgebaseerde inspanningsschattingen hebben, voorkomen vaste referentietarieven dat dezelfde klus een groter gewicht krijgt omdat een duurder persoon hem deed. Voor een ingekochte dienst is misschien juist een vergelijkbare referentieprijs nodig.

Werkelijke salarissen en facturen horen aan de kostenkant. Dezelfde afgebakende deliverable moet in Londen en Lissabon hetzelfde outputgewicht hebben. Van leverancier wisselen mag dat ook niet veranderen.

Standaarduren kunnen werken waar ze zinvol zijn. Maar een index die geautomatiseerd werk omvat, heeft meer nodig dan de resterende menselijke uren, anders kunnen de gewichten naar nul gaan naarmate automatisering slaagt. Referentiekosten van middelen geven ons een bredere basis.

En de referentieperiode hoeft niet van voor AI te zijn. Ze heeft bruikbaar bewijs nodig. “Voordat iemand ChatGPT gebruikte” blijft niet eeuwig een nuttige datum.

Is dit niet gewoon story points in dollars?

Kan zijn. Eerst een correctie waar ik engineers terecht boos over zie worden: story points zijn geen uren. Ze waren bedoeld om werk te groottebepalen ten opzichte van ander werk, op complexiteit en onzekerheid, en daarom gebruiken zoveel teams een soort Fibonacci-schaal. De gaten worden groter naarmate het vertrouwen daalt. Punten omzetten in uren was nooit de bedoeling.

Het risico hier is anders. De schattingen van het team nemen, ze in dollars omzetten en het resultaat objectief noemen zou dezelfde gok zijn met een beter financieel merk.

De verontschuldiging van Ron Jeffries dat hij story points misschien heeft uitgevonden is grappig, maar beantwoordt dit bezwaar niet.¹² Gergely Orosz beschrijft een ontwikkelaar die schattingen opblies toen het team zijn sprintpunten als succestoets ging behandelen.¹³ Een systeem met referentiekosten biedt dezelfde verleiding. Geef het werk een groter gewicht en de score verbetert.

Ik wil een standaard voor een klasse van geleverd werk, niet een lopende schatting van hoe moeilijk deze specifieke poging aanvoelt. Een planningsschatting kan stijgen als we een probleem vinden. Het outputgewicht hoort niet te stijgen alleen omdat we er langer over deden. Als de scope veranderde, moeten we zeggen wat er veranderde.

Ik zou de standaard bouwen uit beoordeelde voorbeelden van vergelijkbaar werk en hem testen op andere voorbeelden. Leg de gewichten vast voor de vergelijking. Registreer wijzigingen, zodat noch het team noch zijn manager achteraf een gerapporteerd resultaat kan verbeteren door ze te vergroten.

Er zit nog steeds oordeelsvorming in. Welk werk hoort bij elkaar? Is het dure geval een ander soort werk, of een dure poging tot hetzelfde? Een reviewer moet zowel de categorie als het gewicht kunnen aanvechten.

Zelfs het kiezen van het gemiddelde doet ertoe. Een mediaan beschrijft een typisch geval. Vermenigvuldig je die met het volume, dan reproduceert hij in een werklast met een lange staart over het algemeen niet het totale middelengebruik. Voor een verwacht referentiekostengewicht zou ik normaal beginnen met een gemiddelde voor een goed gedefinieerde klasse en de spreiding tonen. Ik zou niet de statistiek kiezen die de index het mooist laat lijken.

AI kan helpen gewichten voor te stellen. Het werk van Anthropic over het schatten van taakduur vond bruikbare rangordeinformatie, maar Claude overschatte korte softwaretaken en onderschatte lange.¹⁴ Taken grofweg in de juiste volgorde zetten is niet genoeg als hun relatieve gewichten de uitkomst bepalen.

Een puntensysteem zou vergelijkbare controles kunnen overnemen. Ik mag geen overwinning claimen door de naam te veranderen. De toets is of een ander team de definities kan toepassen en of een redelijk meningsverschil de conclusie verandert.

Houdt dat geen stand, dan heb ik inderdaad story points in dollars opnieuw uitgevonden.

Hebben we het afgerond, of praten we er gewoon niet meer over?

Fin geeft ons een nuttig concreet voorbeeld. Intercom telt bevestigde oplossingen en aangenomen oplossingen, waarbij de klant na een antwoord vertrekt zonder om meer hulp te vragen. In de documentatie staat ook dat de kosten worden teruggedraaid als de klant terugkomt in hetzelfde gesprek om verdere hulp te vragen.¹⁵

Dat is een heldere factureringsregel. Er blijft een vraag over stille klanten, maar het is oneerlijk die te bespreken zonder de terugdraairegel. En gesprekken die door mensen zijn gesloten verdienen dezelfde kritische blik.

Voor deze index zou ik per soort werk vastleggen wat als afgerond telt. Soms is er een expliciete acceptatie. Soms is er een test, een betalingsrecord of bewijs van levering. Soms hebben we alleen indirecte signalen en moeten we die onzekerheid tonen. “Gesloten” kan niet elk geval beslechten.

Herwerk is ook niet simpel. Een heropend gesprek kan een mislukt antwoord zijn of een nieuwe vraag. Een teruggedraaide codewijziging kan een defect verhelpen of een veranderd productbesluit weerspiegelen. Een later geschil maakt het juridische advies dat eraan voorafging niet automatisch ongeldig.

We hebben een regel nodig voor welke correcties eerdere output terugdraaien, hoeveel ze terugdraaien en welke bij nieuwe scope horen. Gebruik die voor mensen en agents allebei. Vergelijk werk dat dezelfde kans heeft gehad om gebreken te laten zien, en herzie de oorspronkelijke periode als eerder toegekende credit niet meer standhoudt. Een net gesloten wachtrij hoort er niet beter uit te zien alleen omdat nog niemand tijd had om te klagen.

Het controleren kost ook middelen. De review-en-herdoen-scenario’s van GDPval laten zien hoeveel het schijnbare kostenvoordeel kan veranderen zodra je expertreview meerekent. Het zijn gemodelleerde scenario’s, geen waargenomen besparingen bij bedrijven, en het artikel merkt op dat gelijkwaardige review- en faalkosten niet zijn meegerekend voor de menselijke basislijn.¹⁶ Ik zou de hele workflow aan beide kanten willen doorrekenen.

Planning legde een andere fout in mijn eerdere versie bloot. Ik stelde voor een forecastcyclus geen credit te geven als de aanpassingen van de planner hem slechter maakten. Dat verwarde het afronden van het werk met een gunstige uitkomst krijgen.

Forecast value added is nuttig om aanpassingen te beoordelen over vergelijkbare waarnemingen.¹⁷ Het is geen universele schakelaar voor de vraag of er is gepland. Een degelijke forecast kan zijn opdracht halen en toch ernaast zitten. Goed juridisch advies kan een deal tegenhouden. Een experiment kan juist nuttig zijn omdat het ons vertelt het project te laten vallen.

Als de maat alleen goed nieuws erkent, mist hij een deel van het goede werk.

Veertig concepten van wat?

Geef de index nu wat marketingwerk.

Een team maakte vroeger vier advertentievarianten per week. Elk kostte twee uur, dus elk kreeg een referentiegewicht van $80 bij ons illustratieve tarief. De output van de week was $320.

Met AI maakt het er veertig. Pas het gewicht toe op elk gegenereerd bestand en de output wordt $3.200, terwijl de resultaten van de campagne nauwelijks bewegen.

Ik zag dat eerst als bewijs dat de maat kapot was. Dat kan, maar niet om de reden die ik dacht. Veertig verschillende, vergelijkbare deliverables kunnen tien keer zoveel productie zijn zonder tien keer zo nuttig te zijn. Ik had al gezegd dat ik geen waarde mat, en verwachtte toch dat het getal dat zou doen.

De andere vraag is of die veertig bestanden veertig deliverables waren. Het kunnen concepten zijn waarmee je kiest wat in één experiment gaat.

Stel voor dit voorbeeld dat de dienst een campagne-experiment is voor een bepaald publiek, met een gedefinieerde testvraag en rapportage-eisen. Ik zou dat experiment tellen. Vier concepten genereren of veertig verandert de eenheid niet. Het maken en kiezen ervan hoort bij de kosten.

Als het team een ander, werkelijk afzonderlijk experiment van vergelijkbare scope uitvoert, is dat meer output. Tien variaties op dezelfde test tien experimenten noemen is dat niet. We hebben de definitie nodig voordat we het resultaat zien, niet een vindingrijke verklaring achteraf.

In een andere workflow kan het opleveren van direct bruikbare varianten zelf de dienst zijn. Dan kunnen losse varianten de juiste eenheid zijn. Dat is een andere rapportagegrens, en ik zou niet wisselen tussen de twee afhankelijk van welke het grotere getal opleverde.

Tom Cunningham en Parker Whitfill van METR hielpen verduidelijken waarom de waardevraag apart blijft. Ze onderscheiden het effect van AI op de oude taakmix, de nieuwe taakmix en de geproduceerde waarde. Iets goedkoop maken verandert wat mensen kiezen te proberen, naast hoe snel ze de werklast van gisteren afronden.¹⁸

Ik ben het eens met het scheiden van die vragen. Een productietelling wordt geen waardemaat omdat het werk vroeger duur was. Een goedkeuring van een manager maakt veertig varianten ook niet veertig keer nuttiger dan één.

Wat gebeurt er als een stap verdwijnt?

Software breekt de telling de andere kant op.

Stel dat een feature vroeger een specificatie van drie uur nodig had, tien uur implementatie en twee uur review. Tegen $40 per uur zijn de referentiekosten $600.

Nu kan een agent dezelfde feature bouwen uit de context die al beschikbaar is. Gebruik kost $25. Menselijke review kost drie uur, wat bij ons tarief $120 aan inspanning is. De gemodelleerde ingezette middelen komen op $145. Neem aan dat de feature aan dezelfde eisen en kwaliteitscontroles voldoet.

Als ik de oude processtappen tel, verlies ik de specificatie. De overgebleven implementatie en review hebben oude gewichten die samen $480 zijn. Maar het bedrijf kreeg toch de hele feature.

Stappen tellen verliest 20% van de output omdat één document overbodig werd. De hele feature tellen houdt de vergelijking intact.

Dat werkt alleen als de stap echt overbodig was. Een beveiligingscontrole schrappen of een eis laten vallen zou veranderen wat er is geleverd. Dezelfde feature, tot dezelfde standaard, doet in die zin belangrijk werk.

“De hele feature” ook. Het kan niet betekenen wat toevallig een verzoek heet. Splits je een feature in drie tickets, dan hoort hij geen drie featuregewichten te krijgen. Combineer je drie echte features tot een epic, dan horen er geen twee te verdwijnen.

Dan zijn er ouders en kinderen. Als de end-to-end feature al ontwerp en review omvat, kan ik het gewicht van de feature niet optellen bij hetzelfde werk dat die teams opnieuw tellen. We kunnen bijdragen binnen het totaal toerekenen. We kunnen geen extra bedrijfsoutput creëren door die tussen afdelingen te verschuiven.

Probeer hetzelfde werk te reorganiseren zonder te veranderen wat er wordt geleverd. Het bedrijfstotaal moet gelijk blijven. Probeer een deel uit te besteden. Dezelfde toets.

Lange projecten vragen ook om zorg met timing. Ik zou cumulatieve vergelijkingen gebruiken, of zelfstandig bruikbare mijlpalen waarvan de gewichten optellen tot de afgesproken scope. Anders leiden maanden aan kosten tot één enorme piek bij oplevering, en is een maanddashboard het grootste deel van het jaar misleidend.

Goed. Wat is dezelfde feature?

Ik ben nogal royaal voor mezelf geweest met die feature van vijftien uur. Een spelfoutcorrectie en een factureringssysteem kunnen allebei een feature heten. Ze in één categorie stoppen brengt ons direct terug bij het supportprobleem.

Laten we iets specifiekers kiezen: een CSV-export van de auditgeschiedenis van een klant. Een bevoegde accountbeheerder moet acht gespecificeerde velden exporteren voor een gekozen datumbereik. De briefing definieert de limieten voor volume en responstijd, de nauwkeurigheidseisen en de toegangscontroles. Het moet werken in het live product.

Ik zou één opgeleverde exportmogelijkheid van die scope tellen. Niet de knop, het endpoint, de tests en de documentatie apart. Ook niet elke keer dat iemand het bestand downloadde. Hier meten we de oplevering van een wijziging, niet het gebruik van het product daarna.

Stel dat we in dit fictieve bedrijf vijf eerdere wijzigingen voor rapportexport vinden met vergelijkbare datascope, gebruikersgedrag, operationele limieten en zekerheidseisen. Op dezelfde referentieprijsbasis waren hun end-to-end kosten $480, $560, $600, $640 en $720. Het gemiddelde is $600.

Zo zouden we het gewicht kunnen opbouwen. Vijf handige getallen bewijzen niet dat het een goed gewicht is. De reviewer moet nagaan waardoor die klussen vergelijkbaar waren, in plaats van gewoon te zoeken naar het woord “export”. Daarna testen we de klasse en het gewicht op ander werk.

Nu hebben we een definitie om over te kibbelen:

Merk op dat de klasse niet afhangt van de gekozen implementatie, het aantal pull requests of het salaris van de engineer. Die kunnen de kosten beïnvloeden zonder te veranderen wat het bedrijf ontving.

De eventstream is anders. Hij verandert het vereiste gedrag. Voor die scope hebben we een geschikte referentieklasse nodig of een andere expliciete behandeling, consequent toegepast op eerder en later werk. We kunnen niet na een dure bouw een categorie “zeer complexe export” verzinnen en die meer output toekennen.

En een nieuw rapportageplatform zonder geloofwaardig precedent? Dat zou ik niet in deze klasse proppen. Ik zou de scope, kosten en bruikbare mijlpalen beschrijven en het buiten deze vergelijkbare reeks houden tot we een basis hebben om het op te nemen.

De kosten moeten zichtbaar blijven. Het rapport moet de gemeten dienst afstemmen op niet-gematcht werk en op de rest van de uitgaven. Anders kies ik de makkelijk te classificeren successen en laat ik alle lastige investeringen elders liggen.

Dit is het moeilijkste deel van het voorstel. Een andere reviewer kan de exportklasse of het gewicht van $600 afwijzen. We kunnen in elk geval aanwijzen waar het meningsverschil zit en zien of een andere redelijke keuze het antwoord verandert.

Sommig engineeringwerk kan klassen als deze ondersteunen. Sommig niet. Dat uitzoeken zou een nuttig resultaat zijn, ook als het mijn hoop op een bedrijfsbreed totaal de grond in boort.

De zestig uur zijn niet van de loonlijst verdwenen

Terug naar support, en de besparing die ik wilde melden.

Oorspronkelijk gaven 180 afhandeluren tegen $40 ons $7.200. Daarna geven 120 uur $4.800. Tel daar een illustratieve agentvergoeding van $0,80 voor elk van de 600 oplossingen bij en de toegerekende afhandelkosten zijn $5.280.

Dat is $1.920 minder. Behalve dat de mensen nog onder dezelfde voorwaarden in dienst zijn.

Stel dat de loonkosten in dit vereenvoudigde voorbeeld $7.200 blijven. Tel de agentrekening van $480 erbij en het bedrijf geeft $7.680 uit. De afhandelbehoefte daalde. De rekening steeg.

Robert Kaplan en Steven Anderson maken dit onderscheid in hun werk over time-driven activity-based costing: ongebruikte capaciteit biedt kansen voor besparing of groei.¹⁹ Daar ben ik het mee eens, en het verandert hier de regel. Vrijgekomen uren gaan op een capaciteitsregel. Besparingen vragen bewijs van lagere uitgaven of een geloofwaardig verhaal over vermeden uitgaven.

De zestig uur kunnen meer klanten ondersteunen zonder dat je nog iemand hoeft aan te nemen. Ze kunnen overwerk verminderen, pieken opvangen of het werk minder hectisch maken. Ze kunnen ook ongebruikt blijven. Ik wil niet dat de boekhouding een uitkomst kiest voordat het bedrijf iets met de tijd heeft gedaan.

Voor de kostenefficiëntie-index zelf zou ik de kosten gebruiken van het leveren van de gemeten dienst, inclusief mislukt werk en ongebruikt gebleven capaciteit. Vergelijk de groei van de oplevering met de groei van de kosten:

E_t = 100 × D_t / D_bC_t / C_b

(3)

D is het opleveringstotaal. C zijn de kosten binnen dezelfde rapportagegrens. E begint bij 100, dus 100 betekent geen verandering in kostenefficiëntie.

In het supportvoorbeeld blijft de oplevering $7.200 terwijl de uitgaven stijgen van $7.200 naar $7.680. De index is 93,8: de kostenefficiëntie daalde die maand met 6,25%.

Gebruik het aparte model met toegerekende afhandeling en de verhouding is 136,4. Dat is de verbetering in de middelen die de workflow nodig heeft, geen gerealiseerde financiële winst. Beide getallen zijn nuttig zodra ze een label hebben. “AI-besparing” boven een van beide zetten scheelt veel uitleg en creëert een veel groter probleem.

Neem voor een echte kostenrekening loonkosten en bijkomende kosten, freelancers, ingekochte diensten, licenties, agentgebruik en infrastructuur mee. Ook review, onderhoud en meten verbruiken middelen. Tel reviewarbeid niet dubbel als die al in het loontotaal zit.

De vergoeding van een leverancier hoort één keer in de rekening, naast ons eigen toezicht. We verzinnen niet ook zijn interne loonkosten en tokenkosten. Uitbesteden mag de aankoopkosten niet laten verdwijnen, en ook niet dubbel tellen.

We hebben ook een consistente basis over tijd nodig. Periodekosten zijn geen kasbetalingen. Een bouwproject dat dit kwartaal wordt betaald, kan meerdere jaren dienen. Kies en vermeld de behandeling. Boek de bouw niet in de ene vergelijking als kosten en verspreid hem in een andere over jaren. Het supportvoorbeeld gaat ervan uit dat kosten en kasuitgaven samenvallen.

Prijzen doen er ook toe. Goedkopere tokens verbeteren de economie, ook als er niets aan de workflow verandert. Een loonsverhoging doet het omgekeerde. Waar hoeveelheden en kwaliteit van inputs vergelijkbaar zijn, helpt een constante-prijzenweergave om prijsveranderingen te scheiden van middelengebruik. Zonder dat bewijs toon je het nominale kostenresultaat en leg je de beperkingen uit.

Verder: zestig afhandeluren minder bewijst niet dat een hele functie kan verdwijnen. De bezetting moet nog steeds het werk dekken als het komt. De volgende vraag gaat over vraag en servicetoezeggingen, niet over delen door een handig aantal uren.

De fout waarvan ik dacht dat die zou wegvallen

Ik had geschreven dat een verkeerd gewicht wegvalt als we een team met zichzelf vergelijken. Dezelfde fout zit aan beide kanten, dus het komt wel goed?

Nee. Niet als de mix verschuift.

Neem twee soorten werk. Stel voor dit voorbeeld dat hun juiste referentiegewichten $1 zijn voor simpel werk en $10 voor complex werk. In het eerste kwartaal voltooit het team negentig simpele eenheden en één complexe. In het tweede tien simpele en negen complexe. Correct gewogen output is in beide kwartalen $100. Houd ook de totale middelen gelijk.

Geef complex werk nu een onjuist gewicht van $20.

We melden 72,7% groei waar in de correct gewogen maat geen groei was. De fout bleef gelijk. We deden meer van het werk dat we te hoog hadden gewaardeerd.

Een verkeerd gewicht kan schijngroei geven

i

Echte groei 0,0%. De index zegt +72,7%. Zelfde werk, andere mix.

Hoe fout is het gewicht van complex werk?+100%

Complexe eenheden in kwartaal 29

Maak het gewicht van simpel werk ook met hetzelfde bedrag fout

De relatie is:

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

(4)

G is de groeiverhouding met de juiste gewichten in het voorbeeld. Ĝ gebruikt onze geschatte gewichten. e is de proportionele gewichtsfout van elk type en w is zijn aandeel in de correct gewogen output. ē is de gemiddelde fout na weging met die aandelen.

De fouten vallen weg als dat gemiddelde in beide periodes gelijk is. Een ongewijzigde werkmix doet dat. Dat geldt ook als elk gewicht in dezelfde verhouding fout zit. Andere combinaties kunnen ook wegvallen. Die twee zijn niet de enige mogelijkheden.

De praktische controle is kijken wat aandeel won. Komt de schijnbare verbetering uit een categorie waarvan we het gewicht nauwelijks vertrouwen, probeer dan plausibele alternatieven. Houdt de winst stand? De resultaten per type horen naast het totaal te staan, en hoeven niet op speciaal verzoek van de twijfelaar te komen.

De categorieën kunnen nog een verschuiving verbergen. Als de agent de allermakkelijkste van de “makkelijke gevallen” pakt, kan zelfs mijn supportmodel met twee categorieën te weinig bijsturen. We moeten ook controleren wat er binnen elke categorie veranderde.

We kunnen ook beter worden in het zien van het werk

Zelfs met perfecte gewichten kunnen de records ons voor de gek houden.

Stel dat de echte output met 10% groeit. In de eerste periode leggen we 80% van de correct gewogen output vast en in de tweede 84%. De waargenomen vergelijking wordt:

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

(5)

Het dashboard meldt 15,5% groei. Vier procentpunten betere dekking voegden 5,5 procentpunt toe aan de schijnbare groei. Zonder echte groei zou dezelfde verandering in dekking 5% fabriceren.

Een agent kan een uitputtend logboek achterlaten van werk dat een mens via een gesprek zou hebben afgerond. Betere registratie is welkom. Het zou op zichzelf geen grotere productie zijn.

“Dekking” betekent in die vergelijking het aandeel van de output dat is vastgelegd, gewogen op dezelfde referentiebasis. Het betekent niet het percentage van de loonkosten dat aan een integratie hangt, aangesloten licenties of zichtbare uitgaven.

Weten waar 80% van het geld naartoe ging, zegt ons niet dat we 80% van het werk hebben gevonden. Dat volgt pas met aanvullende aannames over het waargenomen en het ontbrekende werk. Houd uitgavendekking als nuttige financiële controle. Zet hem niet in de outputvergelijking omdat hij makkelijker te krijgen is.

Daarom hield ik het dekkingsvoorbeeld erin, ook al laat ik het systeem voor het verzamelen van bewijs buiten dit stuk. Een verandering in wat we kunnen zien verandert de meting, hoe we de records ook verzamelen.

Meer records lossen het niet automatisch op. Volume kan willekeurige ruis verminderen. Een consistente bias kan blijven. Vier kwartalen aan data halveren de onzekerheid ook niet automatisch. Fouten die kwartalen delen, gedragen zich niet als onafhankelijke vergissingen.

Ik publiceer liever een smallere reeks die we consistent waarnemen dan dat ik een bedrijfsbrede claim doe op een dekking die we niet kunnen verdedigen. Die heeft een duidelijke grens nodig, dezelfde opvolgvensters en controles op veranderingen in registratie. Werk buiten die grens blijft zichtbaar als ongemeten werk.

Eerdere simulaties hielpen me deze fouten te verkennen. Ik heb hun numerieke bandbreedtes niet bewaard als bewijs van hoe nauwkeurig de methode zou zijn. Daarvoor moeten de implementatie en aannames worden gepubliceerd en daarna aan echt werk worden getoetst. De voorbeelden hier laten de faalwijzen zien, zonder te doen alsof we weten hoe vaak elk voorkomt.

Uiteindelijk wordt zelfs de basislijn een probleem

We kunnen niet één set gewichten voor altijd bevriezen en ervan uitgaan dat het bedrijf braaf vergelijkbaar blijft. Diensten veranderen. Sommige verdwijnen, en nieuwe komen niet met een oude prijs.

Een optie is de gewichten periodiek bij te werken, waarbij elk paar aangrenzende periodes met dezelfde gewichten wordt vergeleken. Een jaarlijkse schakel met de gewichten van het voorgaande jaar is:

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

(6)

De teller telt de output van dit jaar met de gewichten van vorig jaar. De noemer telt de output van vorig jaar met diezelfde gewichten. Vermenigvuldig de schakels voor een langer lopende index.

Zo noemen we een verandering van gewichten geen verandering in productie. Het heeft ook een addertje: apart geketende componenten tellen over het algemeen niet op tot het geketende totaal. Het BEA waarschuwt er uitdrukkelijk voor om geketende-dollarcomponenten als additief te behandelen.²⁰

Bouw de bedrijfsreeks dus op uit een eigen, niet-overlappende set outputs. Tel niet de onafhankelijk ontworpen dashboards van teams bij elkaar op in de hoop dat ze compatibele dingen meten. Sommig intern werk kan nuttig zijn in een functieoverzicht maar al in de end-to-end deliverable van het bedrijf zitten.

Een veranderde classificatie heeft ook een brug nodig: een overlapperiode, een geloofwaardige reconstructie van de eerdere reeks of een vermelde breuk. Ketenen herstelt geen slechte servicedefinitie of ontbrekend werk dat we net pas hebben gevonden.

Dit kan ons nuttige vergelijkingen op functieniveau opleveren en geen verdedigbaar bedrijfsbreed totaal. Daar zou ik vrede mee hebben. Het is beter dan een totaal verzinnen omdat de oorspronkelijke opdracht erom vroeg.

Soms maakt goed werk de telling kleiner

Stel dat engineering het defect repareert achter duizend supportgesprekken. Onze supportcase-index meldt minder afgehandelde gevallen.

Dat hoort ook. Er waren minder gevallen. De fout zou zijn te besluiten dat het bedrijf minder productief was geworden.

Op een bredere grens proberen we klanten het product succesvol te laten gebruiken. Die dienst met minder vermijdbare contacten in stand houden of verbeteren kan een flinke winst zijn. De smalle gevallentelling heeft de bredere servicedefinitie of de outcomemaatstaven ernaast nodig.

Betrouwbaarheid en preventie hebben hetzelfde probleem. Een rustige week met bereikbaarheidsdienst kan een goede week zijn. Een nuttige compliance-interventie kan voorkomen dat een zaak ooit bestaat.

Voor die functies zou ik eenheden testen die gebaseerd zijn op de dienst die over een periode in stand wordt gehouden: wat werkend bleef, voor wie, onder welke belasting en welk risico, tot welke standaard. Een regel in het rooster is niet genoeg. Ik zou de output van een maand ook niet op nul zetten omdat één drempel werd gemist. De kwaliteitscorrectie moet het falen weerspiegelen in plaats van alles van één schakelaar te laten afhangen.

Deze eenheden zijn moeilijker te definiëren. Dat is een deel van het probleem dat ik probeer te begrijpen, niet iets wat een ticketaantal ons laat ontlopen.

En werk dat we eerder niet konden doen?

Een auditteam dat steekproeven van transacties nam, kan nu alle transacties onderzoeken. Zet de oude hypothetische menselijke kosten tegen elke extra controle en de outputclaim wordt enorm.

Maar niemand ging dat handmatige proces per se kopen. Meer controles betekenen ook geen evenredige toename van zekerheid.

Als de nieuwe dienst vergelijkbaar is met iets wat we al meten, kunnen we op die basis rekening houden met de gewijzigde scope of kwaliteit. Zo niet, dan zou ik de capability, de kosten en wat we ervan verwachten apart rapporteren terwijl we een bruikbare definitie vaststellen.

Ik noem dat een capability-register. Het betekent niet dat de uitgaven in aanmerking komen voor activering. Het betekent niet dat we dure werkzaamheden onder “innovatie” kunnen verstoppen wanneer de efficiëntieverhouding tegenvalt. De boekhouding moet nog steeds aansluiten op de financiën.

Zodra de dienst herhaalbaar en definieerbaar wordt, kan hij onder een expliciete invoerregel bij de opleverindex komen. Door AI mogelijk gemaakt zijn mag hem niet voor altijd buiten houden.

Hier komt het punt van Acemoglu over bedrijfsvraag terug. Als bedrijven alleen besparingen op arbeidskosten belonen, kopen ze alleen tools die mensen vervangen.¹ Een capability-register is een manier om de andere soort te belonen.

Mijn bijdrage hier is smaller. Geef het bedrijf een plek om uit te leggen wat de investering mogelijk maakt, in plaats van elk project te laten bewijzen dat het goedkoper oud werk is. Een eigenaar, bewijs en een reviewdatum zouden een nuttig begin zijn. “Het is AI” is geen investeringscase.

Acemoglu pleit ook tegen belastingverstoringen die kapitaal boven arbeid bevoordelen, op basis van werk met Andrea Manera en Pascual Restrepo.¹²¹ Ik ben het eens met het weghalen van een kunstmatige voorkeur voor vervanging. Voor dit stuk ligt de beslissing echter binnen het budget: wat kost de bestaande dienst nu, en wat kunnen we wat we eerder niet konden?

Het register neemt die beslissing niet voor ons. Het moet die beslissing moeilijker te ontwijken maken.

Zou ik dit aan een CFO voorleggen?

Ja, maar naast de rest van de rekening, niet als score voor het bedrijf.

Kent Beck en Gergely Orosz maken in hun reactie op McKinsey een sterk punt tegen inspanning- en outputdoelen. Over de eigen maatstaven van McKinsey schrijven ze: “Customers don’t care. Executives don’t care. Investors don’t care.”²²

Ik vind dat die afwijzing te ver gaat. Een CFO mag redelijk vragen of we dezelfde salarisdienst, tot dezelfde standaard, met minder middelen kunnen leveren. We hoeven niet te wachten op een beweging in de bedrijfswinst om uit te zoeken waarom het duurder werd.

Hun betoog is genuanceerder dan die zin. Ze erkennen ook het gebruik van inspanning en output bij het diagnosticeren van problemen, en de gevaren van mensen alleen op uitkomsten beoordelen.¹³ In zijn slotgedeelte raadt Orosz aan inspanning en output te gebruiken om problemen te onderzoeken in plaats van ze de openbare maatstaven van succes te maken.

Dat is het smallere meningsverschil dat het waard is om te hebben. Ik denk dat een regelmatig gerapporteerde vergelijking van output en kosten van een gedefinieerde dienst kan helpen, naast uitkomsten. Hij moet zijn kosten en zijn effect op gedrag verantwoorden. Een prachtig dashboard dat het team verandert in fulltime dashboardverbeteraars is mislukt.

Dit is ongeveer wat ik zou willen zien:

De uitkomstmaten moeten per functie verschillen. Boekingen horen in een salesgesprek. Ze zijn geen verstandige acceptatietoets voor juridisch advies. Ik laat die verschillen liever zien dan ze te verstoppen in een “impactvermenigvuldiger”.

Op bedrijfsniveau moet de financiële rekening ook weerspiegelen hoe we het werk hebben ingekocht. Omzet per medewerker kan stijgen na uitbesteding, ook als de totale leveringskosten stijgen. Voeg de relevante ingekochte diensten en AI-kosten toe voordat je besluit dat het bedrijf efficiënter is geworden. Omzet heeft nog andere drijfveren, dus die verhouding schrijft de verandering niet aan AI toe.

Ik zou de opleverindex niet gebruiken om individuen te rangschikken. De gewichten beschrijven klassen werk, niet de volledige bijdrage van één persoon. Mentoring, onderbrekingen en iemand anders helpen een klus af te maken passen niet in de outputtelling van een individu. Koppel je salaris aan de index, dan geef je mensen een reden om te pleiten voor grotere gewichten en meer telbaar werk.

Zelfs AI-ondersteund en puur menselijk werk vergelijken vraagt dezelfde zorg als het openingsvoorbeeld. De opdrachten kunnen binnen een categorie verschillen. Weten dat een agent betrokken was, bewijst niet dat die de verbetering veroorzaakte.

En een afgerond product bewijst niet dat de verantwoordelijke persoon het begreep. Dat is een ander probleem, zeker als we beweren dat het doel is mensen capabeler te maken.

De test die ik nog niet heb gedaan

Ik heb laten zien hoe een paar berekeningen zich gedragen met inputs die ik koos. Ik heb boekhoudmethoden geleend en geleerd van de bezwaren van anderen. Niets daarvan vertelt me of twee teams dit voorstel op echt werk kunnen gebruiken en tot een nuttig resultaat komen.

Dat is de volgende test.

Ik zou beginnen met drie contexten: een herhaalbare case- of transactieworkflow, een projectworkflow en een doorlopende dienst. Leg voor elk de eenheid, scope en rapportagegrens vast voordat je de resultaten ziet. Voeg de afrondingsregel, kwaliteitsbehandeling, referentiegewichten en kostenbasis toe. Zeg wat er gebeurt met niet-gematcht werk en latere correcties.

Geef dan een ander competent team hetzelfde bewijs. Kunnen zij de berekening reproduceren? Waar zijn ze het oneens over wat erin hoort?

Over de rekensom moet makkelijk overeenstemming te bereiken zijn. Het exportvoorbeeld laat zien waar de echte discussie zit. Als twee redelijke keuzes van categorie het hoofdresultaat omkeren, moet het rapport dat laten zien in plaats van het meningsverschil te beslechten met een cijfer achter de komma.

Kies referentieklassen en schat hun gewichten met één set werk, en test ze dan op een andere. Neem uitgesloten records en werk buiten het hoofdtrackingsysteem mee in de review. Teken de categorieën niet opnieuw tot de geschiedenis overtuigend lijkt.

Herhaal de tests met gesplitste tickets, samengevoegde tickets, reorganisatie en uitbesteding. Controleer op veranderingen in registratie. Het bedrijfstotaal mag niet bewegen als we alleen hebben veranderd hoe we hetzelfde werk beschrijven of inkopen.

Test deze boekhouding eerst met een onafhankelijk vastgesteld beeld van het werk. Of een machine dat beeld uit de beschikbare systemen kan terughalen is een latere implementatietest. Als mensen met voldoende bewijs het niet eens kunnen worden over de eenheden, redt een betere classifier de definitie niet.

Testen of AI een verbetering veroorzaakte is een andere klus. Gerandomiseerde toegang kan helpen waar dat haalbaar is, evenals een zorgvuldig ontworpen gefaseerde uitrol met een geloofwaardige vergelijkingsgroep. Leren, spillovers, taakselectie en gelijkwaardige kwaliteitsopvolging doen er allemaal toe. Enthousiaste en terughoudende gebruikers zijn niet automatisch vergelijkbaar omdat ze dezelfde functietitel hebben.

Hoe nauwkeurig moet de maat zijn? Dat hangt af van de beslissing. Een grof signaal om te bepalen waar je moet onderzoeken heeft een andere bewijslast dan bewijs dat wordt gebruikt om formatie te schrappen of besparingen te melden. De aanvaardbare fout moet die beslissing volgen, niet een universele omvang van een auditsteekproef.

Publiceer de definities, berekening en herzieningsregels samen met het resultaat. Mijn maatstaf is dat een ander team de methode kan toepassen, de keuzes kan aanvechten en kan zien of de conclusie standhoudt. Erkenning van een accountant of een indrukwekkend ogende vergelijking zou niet genoeg zijn.

Ik heb nu een betere vraag

Ik begon met “heeft AI ons productiever gemaakt?” Nu wil ik weten welke dienst veranderde, of we hetzelfde tellen en waar de vrijgekomen capaciteit naartoe ging. Die vragen passen minder handig op een slide. Ze zijn veel nuttiger als iemand vraagt wat we hierna moeten doen.

Dit doet ertoe voor Flowstate, omdat werk koppelen aan de middelen erachter het probleem is dat wij proberen op te lossen. Ik wil niet dat het product afhangt van het verdedigen van een formule waar ik aan gehecht raakte terwijl ik een blogpost schreef. Als echt werk het model breekt, moet het model veranderen.

Ik wil nog steeds dat agents het repetitieve werk uit de dag van mensen halen. Ik wil dat een bedrijf het voordeel erkent wanneer iemand tijd krijgt om na te denken, een collega helpt of iets nieuws probeert, in plaats van meer tickets te eisen om te bewijzen dat de softwareaankoop werkte.

Ik weet niet hoeveel daarvan in één index past. Misschien minder dan ik hoopte. Een nuttig resultaat kan een set vergelijkingen zijn die we vertrouwen, met de gaten duidelijk zichtbaar gelaten.

Als de agent de makkelijke gevallen pakt, hoeven de overgebleven mensen geen activiteit te fabriceren om zichzelf te verdedigen. Als iemand een besparing claimt, moeten we kunnen vragen waar die naartoe ging. En als het voorgestelde getal de vraag niet beantwoordt, moeten we dat zeggen voordat het iemands target wordt.

Ik ging op zoek naar een maat. Ik ben uitgekomen bij een methode die ik zou testen en een vrij lange lijst redenen om voorzichtig te zijn. Gezien waar ik begon, vind ik dat vooruitgang.

Technische notities

Dit zijn de berekeningen achter de voorbeelden. De aannames doen ertoe: een identiteit kan exact zijn zonder ons te vertellen hoe nauwkeurig we de inputs ervan in een bedrijf kunnen schatten. De verhoudingen hieronder nemen positieve referentiegewichten en noemers ongelijk aan nul aan.

De identiteit van de gewichtsfout

Laat het gestipuleerde juiste referentiegewicht voor type k s zijn, en het geschatte gewicht:

ŝ_k = s_k(1 + e_k)

(7)

Definieer voor nauwkeurig getelde output het correct gewogen totaal en het aandeel van elk type als:

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

(8)

Dan geldt:

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

(9)

De verhouding tussen periodes nemen geeft de identiteit die hierboven is gebruikt. Ze gaat uit van vaste proportionele gewichtsfouten per type, nauwkeurige hoeveelheden en een gemeenschappelijke outputdefinitie. Ze modelleert geen weggelaten werk, veranderende classificaties of onzekere grenzen van deliverables.

Voor kleine fouten is de relatieve fout in de groeiverhouding bij benadering:

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

(10)

Als de typefouten bovendien onafhankelijke willekeurige variabelen zijn met gemiddelde nul en een gemeenschappelijke standaardafwijking, is de eerste-orde standaardafwijking van die fout in de groeiverhouding:

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

(11)

Onder die specifieke aannames geeft het overdragen van twintig procentpunten outputaandeel tussen twee typen, bij een standaardafwijking van de fout van 20%, ongeveer 5,66% relatieve fout in de groeiverhouding, één standaardafwijking. Het is geen empirisch vastgestelde foutmarge, en het is over het algemeen niet hetzelfde aantal procentpunten gerapporteerde groei. Gecorreleerde of systematisch vertekende standaarden vragen om een andere berekening.

Dekking is een outputbegrip in de identiteit

Laat in het voorbeeld met alleen dekking c het aandeel van de correct gewogen output zijn dat zichtbaar is in de records, zonder valse positieven en zonder andere fouten. Dan is de waargenomen output c keer de complete output, dus:

D̂_t / D̂_bD_t / D_b = c_tc_b

(12)

De vergelijking is exact onder die definities. c schatten is het moeilijke deel. Een verhouding van aangesloten uitgaven tot totale uitgaven is een andere statistiek en kan niet worden ingezet zonder een expliciet model dat middelendekking aan productiedekking koppelt.

De boekhoudkundige grens doet hier ook ertoe. Een deel van de output waarnemen terwijl je de hele kostenbasis gebruikt, schat niet hetzelfde object als output en kosten meten voor een bewust beperkte, consistent waargenomen dienst. Geen van beide mag zonder rechtvaardiging worden omgedoopt tot efficiëntie van het hele bedrijf.

Waarom de algehele nauwkeurigheid van een classifier niet volstaat

Definieer voor een eenvoudig binair herkenningsprobleem met correct toegekende, vaste gewichten de totalen van true positives, false positives en false negatives met die gewichten in plaats van itemaantallen. Gewogen precision is het true-positive-gewicht gedeeld door al het herkende gewicht. Gewogen recall is het true-positive-gewicht gedeeld door al het in aanmerking komende gewicht. Waar de noemers ongelijk zijn aan nul:

herkend gewichtin aanmerking komend gewicht = gewogen recallgewogen precision

(13)

Gewone op aantallen gebaseerde precision en recall geven die identiteit niet voor een kostengewogen index. Misclassificatie die het gewicht van een herkend item verandert, vraagt om extra behandeling. Dat geldt ook voor kandidaten die nooit zijn gevonden en onzekere relaties tussen ouder- en kindrecords. Deze fouten samenvoegen in één multiplicatieve vergelijking vraagt om compatibele definities. Het is niet gerechtvaardigd alleen omdat elke term een aannemelijke naam heeft.

Probabilistische herkenning is mogelijk, maar een voorgestelde schatter moet classificaties wederzijds uitsluitend houden en voorkomen dat overlappende deliverables worden geteld. Een verzameling onafhankelijk gescoorde tickets voldoet niet automatisch aan die voorwaarden. Gekalibreerde kansen pakken onzekerheid in waargenomen kandidaten aan, niet werk dat helemaal ontbreekt in de kandidatenset.

Wat een auditsteekproef kan vaststellen

De bekende schatting van 385 waarnemingen komt uit een bepaalde berekening: een enkelvoudige aselecte steekproef van een onafhankelijke binaire proportie, een 95%-interval met normale benadering, een worstcaseproportie van een half en een marge van vijf procentpunten. De onafgeronde steekproefomvang is:

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

(14)

Het stelt niet vast dat 385 records referentiekosten kalibreren, elk soort werk valideren of een kleine verandering tussen periodes oplossen. Stratificatie, clustering, ongelijke gewichten, zeldzame dure gevallen en meningsverschillen tussen reviewers veranderen het vereiste ontwerp. Auditplanning moet beginnen bij de fout die de bedrijfsbeslissing kan veranderen, niet bij een bekend rond getal.

Reproduceerbaarheid en interpretatie

De uitgewerkte voorbeelden gebruiken de vermelde inputs. Het zijn geen schattingen van de typische prestaties van een bedrijf. Numerieke Monte Carlo-foutmarges zouden ook vragen dat de implementatie, parameterverdelingen, afhankelijkheidsaannames en random seeds worden gepubliceerd. Daarna moeten we vaststellen welke aannames bij waargenomen werk passen voordat we de marges lezen als verwachte nauwkeurigheid.

De opleveringssom heeft de eenheid van de referentiekostenvaluta. Een presentatie-index kan die som in de basisperiode normaliseren op 100. De kostenefficiëntie-index gebruikt die normalisatie al. Geen van beide meet economische waarde, causale AI-impact of de waarde van een medewerker.

Will Hackett is medeoprichter en CTO van Flowstate.

Footnotes

1. Daron Acemoglu, Will AI Replace Workers? Not If We Build It Right., The Humanist Review of AI, 15 juli 2026. Pleit voor tools die werknemers aanvullen en voor bedrijfsvraag die draait om productiviteit en innovatie in plaats van alleen besparing op arbeidskosten. Het verband met het rapportageontwerp hier is mijn eigen gevolgtrekking, geen methode die in dat essay wordt voorgesteld. Bron. ↩ ↩² ↩³

2. National Association of Letter Carriers, The Remote Encoding Center: Where bad addresses go to get better, The Postal Record, juli 2022, pp. 34 en 35. Het verslag beschrijft hoe machines de makkelijkere adresafbeeldingen oppakken en de moeilijkere voor menselijke invoerders overlaten. Bron. ↩

3. Intercom, How Fin AI Agent and Copilot Cut Handle Time and Boost Agent Productivity. De bespreking van de resterende menselijke caseload is commentaar van een leverancier dat het mechanisme van de werkmix onderbouwt, geen onafhankelijk bewijs voor de omvang van een productiviteitswinst. Bron. ↩

4. Erik Brynjolfsson, Danielle Li en Lindsey Raymond, Generative AI at Work, The Quarterly Journal of Economics 140(2), 2025, pp. 889 tot 942. De gepubliceerde studie meldt gemiddeld 15% meer opgeloste issues per uur in haar klantsupportomgeving, met uiteenlopende effecten op snelheid en kwaliteit per medewerker. Gepubliceerd artikel. Samenvatting van de auteurs. ↩

5. Joel Becker, Nate Rush, Beth Barnes en David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 juli 2025. Het resultaat betreft de deelnemende ervaren ontwikkelaars, hun repositories en de tools die in dat experiment beschikbaar waren. Bron. ↩

6. Joel Becker en collega’s, We are Changing our Developer Productivity Experiment Design, METR, 24 februari 2026. Het vervolg bespreekt de selectie van deelnemers en taken en de moeilijkheden bij het meten van tijd met gelijktijdige agents. Bron. ↩

7. McKinsey, The state of AI in 2026: On the road to ROI, 25 augustus 2026. De enquêteresponsen zijn verzameld onder 1.719 deelnemers tussen 4 mei en 8 juni 2026. De gemelde cijfers van 80% individuele productiviteit en 37% EBIT-impact beantwoorden verschillende vragen. Bron. ↩

8. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck en Jenna Butler, The SPACE of Developer Productivity: There’s more to it than you think, ACM Queue 19(1), 2021. Betoogt dat de productiviteit van ontwikkelaars niet met één maatstaf of dimensie te vangen is. De afgebakende opleverindex die hier wordt voorgesteld, wordt niet gepresenteerd als vervanging van dat framework. Bron. ↩

9. Alessandro Berti en collega’s, OCEL (Object-Centric Event Log) 2.0 Specification, arXiv:2403.01975, ingediend op 4 maart 2024. De specificatie ondersteunt gebeurtenissen en relaties waarbij meerdere bedrijfsobjecten betrokken zijn. Het is een representatiestandaard, geen productiviteitsmaatstaf. Bron. ↩

10. ACCA, The standard hour in performance measurement. Standaarduren bieden een gemeenschappelijke activiteitsmaat voor heterogene producten en ondersteunen aparte verhoudingen voor volume, benutting en efficiëntie. Bron. ↩

11. Office for National Statistics, Public service productivity estimates: sources and methods, herzien op 1 mei 2026, met name sectie 1 over output, inputs en indexcijfers. De methodologie gebruikt kostengewogen activiteitsmaten voor veel, maar niet alle, output van overheidsdiensten. Bron. ↩ ↩²

12. Ron Jeffries, Story Points Revisited, 23 mei 2019. Zijn voorwaardelijke verontschuldiging dat hij story points misschien heeft uitgevonden is hier de verwijzing, geen bewijs tegen elke vorm van relatieve schatting. Bron. ↩

13. Gergely Orosz en Kent Beck, Measuring developer productivity? A response to McKinsey, Part 2, The Pragmatic Engineer, 31 augustus 2023. Hun gezamenlijke bespreking gaat over prikkels die alleen op uitkomsten zijn gebaseerd. Het apart aangeduide slotgedeelte is van Orosz en bevat het voorbeeld van opgeblazen schattingen en de aanbeveling om inspanning en output te gebruiken om problemen te diagnosticeren in plaats van als openbare succesmaatstaven. Bron. ↩ ↩²

14. Alex Tamkin en Peter McCrory, Estimating AI productivity gains from Claude conversations, Anthropic, 25 november 2025. De controle op softwaretaken meldt Spearman-correlaties van 0,44 voor Claude en 0,50 voor ontwikkelaars, naast gecomprimeerde modelschattingen. Prestaties bij het rangschikken bewijzen geen kalibratie in uren. Bron. ↩

15. Intercom, Fin AI Agent outcomes, documentatie gecontroleerd op 7 oktober 2026. Zie “Resolution definition” en de uitleg dat latere verzoeken om verdere hulp in hetzelfde gesprek de oplossingskosten terugdraaien. De uitgewerkte voorbeelden in dit stuk gebruiken niet de werkelijke prijzen van Fin. Bron. ↩

16. Tejal Patwardhan en collega’s, GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks, 2025, appendix A.2.1 en tabel 2. De review-en-herdoen-scenario’s gebruiken gespecificeerde aannames en laten een vergelijkbare behandeling van review en falen voor de menselijke basislijn weg. Ze mogen niet worden gelezen als algemene schattingen van besparingen op de werkvloer. Bron. ↩

17. Ralf Seifert, Richard Markoff en Matthew Spooner, How a new approach to demand planning can redefine success, I by IMD, 5 augustus 2024. Bespreekt forecast value added en de mogelijkheid dat een betere basislijn de incrementele bijdrage van menselijke aanpassingen verkleint. Bron. ↩

18. Tom Cunningham en Parker Whitfill, Task Substitution and Uplift, METR, 8 mei 2026. Onderscheidt uplift op oude taken, nieuwe taken en waarde, met relaties afgeleid onder expliciete aannames. Bron. ↩

19. Robert S. Kaplan en Steven R. Anderson, Rethinking Activity-Based Costing, Harvard Business School Working Knowledge, 24 januari 2005. Onderscheidt geleverde capaciteit van verbruikte capaciteit en bespreekt kansen die ontstaan uit ongebruikte capaciteit. Bron. ↩

20. US Bureau of Economic Analysis, Chained-dollar estimates. Merkt non-additiviteit buiten het referentiejaar op en waarschuwt ervoor componenten te gebruiken alsof het gewone additieve dollarwaarden zijn. Bron. ↩

21. Daron Acemoglu, Andrea Manera en Pascual Restrepo, Does the U.S. Tax Code Favor Automation?, Brookings Papers on Economic Activity, voorjaar 2020. Analyseert belastingbehandeling die investeringen in apparatuur en software bevoordeelt boven arbeid. Historische schattingen in dat artikel zijn geen berekening van de huidige belastingbehandeling van een specifiek bedrijf. Bron. ↩

22. Gergely Orosz en Kent Beck, Measuring developer productivity? A response to McKinsey, The Pragmatic Engineer, 29 augustus 2023, met name sectie 4. De geciteerde afwijzing betreft de eigen inspanning- en outputmaatstaven van McKinsey, niet elke mogelijke vorm van operationele meting. Bron. ↩