Cum investighezi o lipsă în stoc înainte să dai vina pe sistem

Acum peste douăzeci de ani am primit un telefon la care încă mă gândesc. Circa 10.000 de dolari lipsă la inventar, utilizatori care raportau erori și un patron care își formulase deja concluzia: sistemul pe care tocmai îl implementaserăm nu funcționa.

Conduceam pe atunci o filială regională de implementare, iar noi câștigaserăm licitația pentru automatizarea a șaptesprezece stații de carburant. Reclamațiile începuseră după punerea în funcțiune, iar o sumă mare dispăruse. Interpretarea lui nu era nerezonabilă. Succesiunea evenimentelor arăta direct spre noi.

Era însă personal într-un fel în care contractele rareori sunt. Negociasem eu însumi proiectul, iar proprietarii îl legaseră de mine, nu de compania din spatele meu. La ședința de final mi-au strâns mâna și mi-au spus direct că se așteaptă să răspund pentru orice bani pierduți din cauza proiectului. Acolo unde lucram, o strângere de mână de felul acesta avea cam greutatea unei clauze semnate.

Prima noastră greșeală: nu ne-am uitat la forma reclamațiilor

Suportul înregistra incidente de săptămâni bune. Nimeni nu pusese întrebarea evidentă despre acel registru: erau un singur defect care se repeta, mai multe defecte fără legătură între ele, o problemă locală de operare sau același eveniment raportat iar și iar de oameni diferiți?

Este o capcană standard în orice implementare. Sistemul cedează constant cât timp oamenii lucrează și se comportă impecabil în momentul în care un specialist stă lângă ei. Lăsată așa, distanța asta se transformă în suspiciune reciprocă: utilizatorii decid că softul e stricat, echipa de implementare decide că utilizatorii sunt neatenți și nimeni nu se uită la dovezi.

Întreabă ce formă are problema, nu cât de mare este

Înainte de întâlnirea cu patronul, i-am cerut echipei altceva decât totalul. Cinci întrebări, niciuna ingenioasă:

• Unde: în care dintre cele șaptesprezece stații stă diferența și cum se compară fiecare cu celelalte?
• Când: pe ce perioadă s-a acumulat și a început înainte sau după punerea în funcțiune?
• Cine: pe ce ture și ce oameni lucrau în ele?
• Ce: ce categorii de produse și ce au acele produse în comun, fizic și comercial?
• În altă parte: apare același tipar în vreo altă locație care rulează aceeași versiune?

Ce a arătat desfășurarea pe componente

Toate raportările de eroare veneau dintr-o singură stație, pe o singură tură. Nici lipsa, circa 10.000 de dolari acumulați într-o lună, nu era răspândită uniform pe sortiment. Stătea în trei categorii: țigări, băuturi spirtoase premium și ciocolată. Mici, scumpe, ușor de scos dintr-o clădire fără ca cineva să observe.

Am dus la întâlnire listingurile pe hârtie, pentru că asta se întâmpla cu mult înainte ca cineva să deschidă o defalcare pe telefon. Până în acel moment, patronul și cu mine ne uitaserăm la același total și citiserăm din el două situații diferite. El vedea o implementare eșuată în toată rețeaua. Ce arăta distribuția era că, orice ar fi fost, trăia într-o singură locație, pe o singură tură, într-un grup definit de produse.

Cifra nu s-a schimbat în ședința aceea. S-a schimbat cât de mult din afacere implica și, prin urmare, unde merita căutat în săptămâna următoare.

O verificare ulterioară a confirmat că pierderile veneau dintr-o abatere deliberată, nu dintr-o eroare de calcul. Vreau să fiu precis în privința a ceea ce datele au făcut și nu au făcut acolo. Nu au dovedit nimic. Dovada a venit din documente, inventare și discuții, adică de unde trebuie. Ce a făcut defalcarea a fost să îndrepte verificarea spre un loc în care chiar putea găsi ceva.

Dacă explicația ar fi adevărată, cum ar arăta datele?

Întrebarea aceasta este partea din poveste pe care am folosit-o cel mai des de atunci, și nu doar pentru lipsuri. Ia explicația pusă pe masă, presupune pentru un moment că e corectă și întreabă ce tipar ar trebui să lase în urmă:

• O eroare de calcul din sistem ar trebui să apară în toate locațiile, turele, la toți utilizatorii și pe toate categoriile, pentru că aceeași logică rulează peste tot. Rareori se limitează la un singur colț al rețelei.
• O problemă de instruire sau de utilizare tinde să urmeze anumiți oameni sau anumite ture și să dispară în locațiile unde aceeași versiune rulează cu o echipă experimentată.
• O eroare de configurare începe de obicei la data la care s-a schimbat ceva și se oprește la locațiile unde nu s-a schimbat.
• Pierderea din abateri tinde să se concentreze în produse compacte, valoroase și ușor de mutat, deseori într-o fereastră de timp îngustă.

Niciuna dintre acestea nu este un verdict. Sunt un mod de a decide de unde să înceapă verificarea, ceea ce este cu totul altceva decât a decide ce s-a întâmplat. Valoarea stă în eliminarea explicațiilor ale căror urme pur și simplu nu se văd în date.

Zece reclamații nu înseamnă zece defecte

Aceeași disciplină se aplică la tot ce semnalează un sistem. Zece reclamații pot fi un singur defect raportat de zece ori. O anomalie generată automat poate fi statistic neobișnuită și complet irelevantă operațional, în timp ce o abatere mică într-o categorie sensibilă merită atenție chiar în săptămâna asta. Volumul nu este gravitate, iar deviația standard nici atât.

Aici am devenit precaut față de sistemele care ridică alarme fără să ajute pe cineva să le judece. O alertă care spune că o cifră s-a mișcat îl lasă pe cititor exact acolo unde eram patronul și cu mine înainte să apară listingurile. Argumentul separat, despre de ce raportarea trebuie să treacă de la înregistrarea a ceea ce s-a întâmplat la ghidarea următorului pas, l-am făcut în De la contabilitate la navigație; textul de față este despre întrebarea mai îngustă și mai practică: cum citești o anomalie odată ce a apărut.

Ce înseamnă asta pentru alertele sistemului tău

Este motivul pentru care marql a fost construit să răspundă la defalcare, nu doar la total. Când apare o diferență în stoc, marjă sau numerar, ecranul util este distribuția: care locații, care perioade, care ture, care categorii și furnizori. Se conectează read-only la sistemele de POS, contabilitate și stocuri pe care rețeaua le rulează deja, găzduit în UE, iar întrebarea următoare este mesajul următor din aceeași conversație, nu o nouă cerere către cineva din financiar — frecarea despre care am scris în costul ascuns al raportării manuale.

Limitele merită spuse la fel de clar ca posibilitățile. Nu stabilește intenția, nu înlocuiește un inventar și nu conduce o anchetă. Ce face este să aducă un responsabil de operațiuni sau un responsabil financiar la aceleași listinguri pe care le duceam eu în ședința aceea, în câteva minute în loc de o săptămână de insistențe, cu prețuri de la 200 EUR pe lună.