Post #8 z 50 — Séria CFO & AI
Post #7 sa skončil opravou: pravidlom zdravého rozumu, ktoré pozastaví report na manuálnu kontrolu vždy, keď sa niektoré číslo oproti predchádzajúcemu obdobiu zmení viac, než je nastavený prah — namiesto toho, aby report odišiel rovno do schránky. O tri týždne neskôr toto pravidlo urobilo presne to, na čo bolo určené. Len tentoraz označilo niečo, čo napokon vôbec nebol problém.
Alert, čísla aj vysvetlenie nižšie sú modelová ilustrácia zostavená z opakujúcich sa vzorov, ktoré som počas kariéry videl; neopisujú konkrétnu firmu, dátovú sadu ani osobu.
1 — pravidlo prahu z Postu #7, teraz naostro
58 % — nárast v označenom čísle
0 — skutočných problémov, ktoré našlo
Čo alert označil
Pravidlo sleduje niekoľko kľúčových ukazovateľov a porovnáva každé nové číslo s predchádzajúcim obdobím. Jedno ráno pozastavilo report skôr, než odišiel: počet dní hotovosti na účte vyskočil z 45 na 71 v priebehu jediného týždňa — nárast o 58 %, ďaleko nad prahom nastaveným po Poste #7. Na papieri malo ísť presne o toto. Skok tejto veľkosti, bez vysvetlenia, je buď veľmi dobrá správa, alebo znak, že niečo v dátach nesedí.
Dni hotovosti na účte: 45 → 71 za jeden týždeň, nad kontrolným prahom — v skutočnosti klient vopred zaplatil zálohu na šesť mesiacov za projekt, ktorý začína v Q4: reálna hotovosť, správne zaznamenaná, len nezvyčajne načasovaná.
Ten istý účet bol znova označený o týždeň neskôr, stále zvýšený — nešlo o novú anomáliu, bol to ten istý vklad, stále na účte, presne podľa očakávania.
Prečo to vyzeralo ako problém
Pravidlo nevie, prečo sa číslo zmenilo — len to, že sa zmenilo o viac, než je nastavené percento. Nepozná rozdiel medzi „očakávané, ale nezvyčajné” a „neočakávané a nesprávne” — každé prekročenie prahu vyzerá zvnútra rovnako. Výpočet runwayu sám osebe nedokáže odlíšiť skorú platbu od chyby v modeli, duplicitného záznamu alebo ukazovateľa, ktorý teraz jednoducho meria niečo iné, než číslo, s ktorým sa porovnáva.
Systém, ktorý zbytočne kričí „vlk”, ťa stojí rovnakú dôveru ako ten, čo vlka prehliadne — len ju minie pomalšie.
Čo sa takmer stalo
Po druhom označení bol prvý inštinkt v miestnosti vyhlásiť celé pravidlo za „príliš citlivé” a znížiť prah — čo by potichu znova otvorilo presne tú medzeru, ktorú mal Post #7 zavrieť. To je skutočné riziko falošného poplachu: nie strata dvadsiatich minút na jeho overenie, ale erózia, ktorá spôsobí, že ľudia prestanú overovať ten ďalší — skutočný alebo nie.
Čo sa zmenilo potom
Pridali sa dve úpravy. Po prvé, krátky zoznam známych, opakujúcich sa, ale nepravidelných udalostí — zálohové platby, obnovenie poistky, ročné licenčné poplatky — ktoré sa označia už pri zápise, aby ich pravidlo prahu vedelo posudzovať inak než neobjasnený skok. Po druhé, každý pozastavený alert musí odteraz niesť jednu vetu vysvetľujúcu, čo sa zmenilo, skôr než na neho niekto zareaguje — nielen číslo a červenú vlajku. Ak túto vetu ešte nikto nevie napísať, report zostáva pozastavený, kým sa to nezistí.
Prečo môže falošný poplach vážiť viac než chyba, pred ktorou má chrániť
Podľa mojej skúsenosti alert, ktorý sa raz pomýli, samotný systém takmer nič nenaučí — ale naučí niečo človeka, ktorý ho číta, a to si zapamätá: že tejto konkrétnej vlajke sa nedá vždy veriť. Prehliadnutá chyba ťa stojí raz, keď sa odhalí neskoro. Falošný poplach ťa môže stáť zakaždým potom — potichu, v podobe alertu, ktorý už nikto neotvára.
Sledujte túto sériu
Post #9 sa pozerá na iné slepé miesto — také, ktoré sa meria v kurzoch mien, nie v dátumoch.
Prichytili ste sa niekedy, ako ignorujete upozornenie, lebo to predchádzajúce bolo nakoniec zbytočné? Odpovedz mi rovno na tento e-mail.
🇬🇧 ENGLISH VERSION BELOW
Post #8 of 50 — The CFO & AI Series
Post #7 ended with a fix: a sanity-check rule that holds a report for manual review whenever a number moves more than a set threshold from the prior period, instead of sending it straight to an inbox. Three weeks later, that rule did exactly what it was built to do. It just flagged the wrong thing — or rather, it flagged something that turned out to be completely fine.
The alert, the numbers, and the explanation below are a composite illustration, put together from patterns I’ve seen repeat across different projects; they don’t describe a specific company, dataset, or person.
1 — threshold rule from Post #7, now live
58% — jump in the flagged number
0 — actual problems it found
What the alert flagged
The rule watches a handful of core figures and compares each new one to the prior period. One morning, it held a report before it went out: days of cash on hand had jumped from 45 to 71 in a single week - a 58% move, well past the variance threshold set after Post #7. On paper, that’s exactly the kind of number the rule exists to catch. A jump that size, unexplained, is either very good news or a sign something in the data is broken.
Days of cash on hand: 45 → 71 in one week, above the review threshold - a client had paid a six-month retainer upfront for a project starting in Q4: real cash, correctly recorded, just unusually timed.
The same account was flagged again the following week, still elevated - not a new anomaly, it was the same deposit, still sitting there, exactly as expected.
Why it looked like a problem
The rule doesn’t know why a number moved, only that it moved more than a set percentage. It has no concept of “expected but unusual” versus “unexpected and wrong” - every threshold breach looks identical from the inside. Runway math has no way, on its own, to tell an early payment apart from a modeling error, a duplicate entry, or a metric that’s simply now measuring something different than the number it’s being compared to.
A system that cries wolf costs you the same trust as one that misses the wolf - it just spends it more slowly.
What almost happened
By the second flag, the instinct in the room was to mark the whole rule “too sensitive” and turn the threshold down - which would have quietly reopened the exact gap Post #7 was meant to close. That’s the real risk in a false alarm: not the twenty minutes spent checking it, but the erosion that makes people stop checking the next one, real or not.
What changed after that
Two adjustments went in. First, a short list of known, recurring-but-irregular events - advance payments, insurance renewals, annual license fees - that get tagged at the point of entry, so the threshold rule can treat them differently from an unexplained jump. Second, every held alert now has to carry one line explaining what changed before anyone acts on it, instead of just a number and a red flag. If nobody can write that line yet, the report stays held until someone can.
Why a false alarm can matter more than the mistake it’s guarding against
In my experience, an alert that’s wrong once teaches the system almost nothing on its own - but it teaches the person reading it something they don’t forget: that this particular flag isn’t always worth trusting. A missed error costs you once, when it’s caught late. A false alarm can cost you every time after it, quietly, in the form of an alert nobody opens anymore.
Follow the series
Post #9 looks at a different blind spot - one measured in exchange rates, not dates.
Have you ever caught yourself dismissing an alert because the last one turned out to be nothing? Reply directly to this email.