<!– B1:taak –>
Deze agent leest je stuurgetallen op de frequentie waarop ze veranderen, vergelijkt elke waarde met een drempel die jij vastlegt, en stuurt alleen een melding als iets die drempel overschrijdt. Bij de melding staat een uitleg van de vermoedelijke oorzaak, nooit een kaal cijfer. Alles binnen de drempel krijgt geen melding. Dat is de hele taak.
<!– B2:probleem –>
Je hebt waarschijnlijk al een dashboard. Het probleem is niet dat de cijfers ontbreken, het probleem is dat er te veel van zijn en dat niemand ze allemaal dagelijks leest met evenveel aandacht. Reken het uit. Tel hoeveel stuurgetallen op je huidige dashboard staan, en hoeveel minuten je zelf, of je operationeel leidinggevende, gemiddeld besteedt aan het doorscannen ervan per dag. Vermenigvuldig dat met het aantal werkdagen per maand. Dat is de tijd die nu gaat naar het zoeken naar de afwijking, niet naar het oplossen ervan.
Het mechanisme achter die tijd komt uit de aandachtseconomie van een dashboard. Hoe meer cijfers gelijktijdig groen, oranje of rood kleuren, hoe sneller het oog eraan went en hoe later een echte afwijking wordt opgemerkt. Een dashboard dat altijd wat oranje toont, traint je om oranje te negeren. Tegen de tijd dat iemand het rode getal ziet, is de onderliggende oorzaak vaak al twee of drie weken aan de gang.
De tweede kost zit in de vorm van de melding zelf. Een cijfer dat daalt, zegt niets over waarom het daalt. Wie het cijfer ziet, moet zelf uitzoeken of het een seizoenspatroon is, een systeemstoring, een vertraagde import, of een echte trendbreuk. Die uitzoektijd komt bovenop de scantijd, en ze wordt zelden meegeteld als kost van het dashboard. Ze voelt als gewoon werk, terwijl het reactief speurwerk is dat een vooraf ingebouwde uitleg had kunnen voorkomen.
Beide kosten schalen mee met het aantal stuurgetallen. Elke nieuwe metric die je toevoegt aan een dashboard, verlaagt de kans dat de bestaande metrics nog dagelijks bekeken worden. Meer meten levert dan minder sturing op, niet meer.
<!– B3:diagnose –>
Vier vragen om te bepalen of dit bij jou speelt.
Hoeveel stuurgetallen staan er op je belangrijkste dashboard, en kun je zonder te kijken zeggen welke drie daarvan deze week buiten de normale bandbreedte lagen?
Is er voor elk stuurgetal een vastgelegde drempel waarboven of waaronder iemand actie onderneemt, of wordt dat per keer op gevoel besloten?
Wanneer een cijfer afwijkt, komt er dan een verklaring mee, of alleen het cijfer zelf, waarna iemand handmatig gaat uitzoeken wat er aan de hand is?
Hoeveel van je huidige meldingen blijken achteraf ruis, een tijdelijke schommeling zonder onderliggende oorzaak, en weegt dat percentage tegen de tijd die eraan besteed wordt?
<!– B4:werking –>
De agent draait de PRAL-lus op je stuurgetallen. Perceive, hij leest de brongegevens rechtstreeks uit het systeem waar het cijfer ontstaat: het ERP, het CRM, het boekhoudpakket of de productiedatabase. Dat gebeurt op de frequentie die bij dat cijfer past, dagelijks voor operationele cijfers, wekelijks voor cijfers die pas na verwerking stabiel zijn. Reason, hij toetst elke waarde aan de drempel die jij vastlegde. Bij een overschrijding zoekt hij de meest waarschijnlijke verklarende factor in dezelfde brondata: een vertraagde levering, een uitval in een productielijn, een factuur die laat is ingeboekt. Act, hij stuurt alleen bij een overschrijding een melding, met het cijfer, de drempel, de gevonden verklaring en een vermeld betrouwbaarheidsniveau van die verklaring. Learn, elke keer dat jij een melding als ruis markeert of de verklaring corrigeert, wordt die correctie een regel voor de volgende keer.
Drempels zijn geen kunstwerk, ze zijn een besluit. Onze vuistregel, geen gemeten norm: begin met vier tot zes stuurgetallen, niet meer. Voor elk cijfer leg je drie dingen vast voordat de agent draait. De bandbreedte waarbinnen een afwijking normaal is, de bron van het cijfer, en wie de melding ontvangt als de drempel wordt overschreden. Een drempel die te strak staat, genereert weer de ruis die je probeerde weg te filteren. Een drempel die te ruim staat, mist de afwijking die je wilde zien. Stel hem bij na de eerste maand draaien, niet ervoor.
De agent onderscheidt drie uitkomsten per cijfer, niet twee. Binnen bandbreedte krijgt geen melding. Buiten bandbreedte met een gevonden verklaring krijgt een melding met die verklaring en het betrouwbaarheidsniveau erbij. Buiten bandbreedte zonder gevonden verklaring krijgt ook een melding, maar dan expliciet gemarkeerd als onverklaard, zodat jij niet op zoek gaat naar een uitleg die de agent al verzon. Dat onderscheid voorkomt het omgekeerde probleem van een dashboard: een agent die overal een verklaring bij verzint, is gevaarlijker dan een dashboard dat niets verklaart.
Op de autonomieladder blijft deze agent laag, en dat is precies het punt. Perceive en Reason draaien zonder mens, Act stuurt een melding maar wijzigt nooit een systeem, een contract of een beoordeling. Elke actie die verder gaat dan een melding versturen, is uitgesloten: een correctie in de brondata doorvoeren, een target aanpassen, een medewerker aanspreken. Dat hoort bij een ander proces, met een ander besluitniveau.
<!– B5:databehandeling –>
Lees dit voordat je de instructie hieronder gebruikt, want het bepaalt wat de agent wel en nooit mag lezen. Deze agent bewaakt processen, nooit personen. Hij leest geaggregeerde procescijfers: doorlooptijd van een order, foutpercentage van een batch, omzet per dag, voorraadniveau. Hij leest nooit individuele activiteitsdata van een medewerker, geen inlogtijden, geen productiviteit per persoon, geen e-mailvolume per naam. Elke koppeling die dat wel zou doen, is uitgesloten, ook als de techniek het toelaat. Bij Femke’s koopcomité heeft de Ondernemingsraad hier veto, en terecht: een cijfer over een proces mag nooit herleidbaar worden tot een beoordeling van een persoon.
Doe dit in een zakelijk abonnement met een verwerkersovereenkomst, nooit in een consumentenaccount, zodra er bedrijfsdata in de prompt komt. Anonimiseer voor je plakt: geen klantnamen, geen namen van medewerkers, geen contractnummers. Werk met rollen, niet met namen, en met geaggregeerde getallen, niet met onderliggende regels. Leg vast hoe lang de uitwisseling met de modelleverancier bewaard blijft, en wie toegang heeft tot dat logboek. En benoem vooraf wie een melding overneemt als de agent een verklaring geeft met een laag betrouwbaarheidsniveau: dat mens-in-de-lus-moment is het enige punt waarop een cijfer een besluit wordt.
<!– B6:instructieblok –>
“` Je bent mijn analist voor stuurgetallen. Ik plak hieronder een tabel met vier tot zes procescijfers, per dag of per week gemeten, over de laatste twaalf periodes. Kolommen: periode, cijfernaam, waarde, vastgelegde ondergrens, vastgelegde bovengrens. Er staan geen namen van klanten of medewerkers in, alleen procescijfers.
Doe exact dit, in deze volgorde.
- Markeer per cijfer en periode of de waarde binnen de bandbreedte valt.
Toon alleen de periodes waar dat niet zo is.
- Zoek voor elke overschrijding een mogelijke verklaring binnen dezelfde
tabel, bijvoorbeeld een gelijktijdige uitschieter in een ander cijfer. Geef aan of die verklaring sterk, zwak of afwezig is. Verzin geen externe oorzaak die niet in de data staat.
- Groepeer de overschrijdingen per cijfer en geef aan of het patroon
incidenteel is, een trend over meerdere periodes, of een terugkerend seizoenspatroon.
- Stel per cijfer voor of de huidige bandbreedte te strak, passend of
te ruim lijkt, op basis van hoe vaak hij wordt overschreden.
- Sluit af met een lijst van maximaal vijf regels: cijfer, uitkomst,
verklaring, betrouwbaarheid, voorstel voor de drempel.
Vraag geen aanvullende gegevens. Als een verklaring niet in de data zit, zeg dat expliciet in plaats van een aanname te presenteren als feit. “`
Wat hieruit komt is een eerste versie van je meldingsregels, niet een definitief systeem. Test die regels een maand tegen wat er werkelijk gebeurde voordat je ze automatisch laat versturen.
<!– B7:grens –>
Deze agent past niet overal. Heb je geen vastgelegde bandbreedtes en geen tijd om die eerst te bepalen, dan bouw je een machine die willekeurig meldt of juist alles doormeldt. Begin dan met de drempels, niet met de agent. Verandert je proces zo vaak dat een bandbreedte van vorige maand deze maand al voorbijgestreefd is, dan achtervolg je een bewegend doel en is handmatige beoordeling voorlopig goedkoper. En als het onderliggende doel is om te zien wie onderpresteert, niet welk proces vastloopt, hoort deze agent hier niet. Zoek dan eerst uit waarom die vraag gesteld wordt, want dat is geen procesvraag meer.
<!– B8:links-cta –>
De stuurgetallen die deze agent bewaakt, komen niet uit het niets. Welke vijf financiële metrics een board al herkent en hoe je ze zelf berekent, staat op financiële executie, en die pagina levert precies het soort cijfer dat hier een drempel krijgt. Het onderscheid tussen een cijfer dat je kunt sturen en een cijfer dat pas achteraf verschijnt, komt uit 4DX. Die lead-lag-logica bepaalt welke stuurgetallen deze agent überhaupt de moeite waard zijn om te bewaken. Wat agentic wel en niet betekent op de autonomieladder die hierboven terugkwam, staat uitgewerkt bij de introductie op agentic. Terug naar de homepage voor het volledige overzicht.
Wil je weten welke vier tot zes stuurgetallen bij jou de moeite waard zijn om te bewaken, en welke drempel daarbij hoort? Ik werk dat met je uit in een sessie van 90 minuten, en je loopt eruit met een vastgelegde drempeltabel per cijfer. Ik wil die drempeltabel.