Alerta care ajunge luni dimineața la persoana greșită: de ce detecția riscului nu e același lucru cu decizia
Cum se măsoară și se scurtează traseul de la semnal la decizie, astfel încât un risc identificat marți să fie tratat tot marți, de omul care are mandatul să-l trateze.
Pe scurt
Majoritatea companiilor de distribuție care au investit în automatizare au deja detecția rezolvată: sistemele văd depășirea de limită de credit, ruptura de stoc sau marja negativă. Pierderea apare între semnal și decizie — alerta pleacă pe email către o adresă generică, ajunge într-o căsuță cu 200 de mesaje pe zi și e citită după ce fereastra de acțiune s-a închis. Un semnal are valoare economică doar în intervalul în care decizia mai poate schimba rezultatul: la o factură scadentă, acel interval e de ore, nu de săptămâni. Soluția nu e mai multă detecție, ci rutarea fiecărui tip de semnal către o persoană nominală, cu prag de materialitate, termen de răspuns și escaladare automată.
Aveți alertele. Aveți și pierderile.
Întrebați-vă directorul financiar câte alerte automate generează sistemele companiei într-o lună. Apoi întrebați câte dintre ele au produs o decizie documentată în aceeași zi.
Diferența dintre cele două cifre e locul unde se duc banii. Nu în lipsa detecției — sistemele moderne de ERP, WMS și bancare văd aproape tot ce trebuie văzut. În traseul dintre momentul în care un sistem a observat ceva și momentul în care un om cu mandat a decis ceva.
Un client depășește limita de credit marți la ora 10. Regula există, sistemul o aplică, se generează o notificare. Notificarea pleacă pe o adresă de grup. Directorul de credit control e în concediu, colegul care îl înlocuiește primește 180 de emailuri pe zi, iar comanda se livrează miercuri dimineață pentru că nimeni nu a oprit-o. Riscul a fost identificat corect. Pierderea s-a produs oricum.
Ce s-a schimbat: detecția a devenit ieftină, decizia nu
În ultimii ani, costul detecției a scăzut dramatic. Reguli în ERP, dashboard-uri de BI, scripturi, iar acum modele care citesc text liber din emailuri și contracte. O companie de distribuție de talie medie poate ajunge, fără efort mare, la câteva zeci de tipuri de semnale generate zilnic.
Capacitatea de decizie a rămas aceeași. Aceiași cinci-șase oameni cu mandat de a opri o livrare, de a bloca o plată, de a renegocia un preț sau de a aproba o derogare. Aceleași ore de lucru.
Când volumul de semnale crește de zece ori și numărul de decidenți rămâne constant, rezultatul nu e mai multă siguranță. E dezensibilizare: oamenii încep să ignore categoria întreagă de alerte.
Fenomenul e documentat de mult în alte industrii sub numele de alarm fatigue — studiat în medicina de terapie intensivă și în aviație, unde excesul de alarme duce la ignorarea lor sistematică. Mecanismul e identic într-o companie: dacă nouă din zece alerte nu cer nimic de la mine, o voi deschide pe a zecea cu aceeași atenție ca pe celelalte nouă.
Mecanismul: valoarea unui semnal se evaporă în timp
Un semnal de risc nu are o valoare fixă. Are o valoare care scade pe măsură ce se închide fereastra în care decizia mai poate schimba rezultatul.
Fereastra de acțiune, pe tipuri de semnal
| Semnal | Fereastra în care decizia mai contează | Ce se pierde după |
|---|---|---|
| Client peste limita de credit, comandă în picking | Ore — până iese marfa din depozit | Expunere necolectabilă, recuperare pe cale juridică |
| Factură furnizor cu discount pentru plată anticipată | Zile — până la data limită | Discountul, integral |
| Marjă negativă pe o linie de comandă | Ore — până la confirmarea comenzii | Vânzarea se face în pierdere și intră în istoric ca preț de referință |
| Stoc cu rotație oprită, aproape de termen | Săptămâni | Scăderea prețului de lichidare, apoi casarea |
| Diferență între extras bancar și încasare în ERP | Zile | Timp de reconciliere, risc de dublă urmărire a aceluiași client |
Observați asimetria. Semnalele cu cea mai scurtă fereastră sunt exact cele care circulă cel mai prost: trec prin email, prin telefon, prin „îi spun eu lui Andrei când îl văd".
Cele trei puncte în care se pierde traseul
1. Destinatarul nu e o persoană. Alertele trimise la finance@ sau operatiuni@ nu au proprietar. Responsabilitatea difuză înseamnă zero responsabilitate — fiecare presupune că altcineva se uită.
2. Semnalul nu vine cu context de decizie. „Clientul X a depășit limita" nu e suficient. Decidentul are nevoie, în același ecran, de: soldul curent, vechimea pe intervale, istoricul de plată din ultimele 12 luni, valoarea comenzii în curs și marja pe ea. Dacă trebuie să deschidă trei sisteme ca să afle, decizia se amână. Amânarea e decizia.
3. Nu există prag de materialitate. O depășire de 400 de lei și una de 40.000 de lei ajung pe același canal, cu același format. Directorul financiar învață să trateze canalul, nu cazul.
Ce se face concret, în ce ordine
- Inventariați semnalele existente. Câte tipuri de alerte generează sistemele, în ce volum zilnic, pe ce canal pleacă. În majoritatea companiilor, acest inventar nu există scris nicăieri.
- Atribuiți fiecărui tip un proprietar nominal și un înlocuitor. Nume de persoană, nu departament. Cu regula de preluare în caz de absență.
- Stabiliți pragul de materialitate pe fiecare tip. Sub prag, semnalul intră într-un raport agregat săptămânal. Peste prag, ajunge la om în aceeași zi. Pragul se decide de CFO, nu de IT.
- Definiți termenul de răspuns și escaladarea. Dacă semnalul de clasă A nu are decizie în patru ore, urcă automat la nivelul următor. Escaladarea nu e o pedeapsă, e un mecanism.
- Livrați semnalul cu contextul complet atașat. Toate datele necesare deciziei, într-un singur loc, împreună cu o propunere de acțiune. Omul confirmă sau respinge.
- Măsurați timpul de la semnal la decizie. E singurul indicator care arată dacă automatizarea funcționează. Numărul de alerte generate nu spune nimic.
Cum abordează CIBINNO această problemă
CIBINNO AI Business OS se așază peste sistemele pe care compania le are deja — ERP, WMS, conturile bancare, ANAF, emailul, fișierele de lucru. Implementarea existentă rămâne neatinsă și nu există migrare de date.
Primul strat este infrastructura de date: aceleași informații, aduse într-un singur loc, astfel încât un semnal despre un client să poată conține simultan soldul din ERP, starea comenzii din WMS și încasarea din extrasul bancar. Al doilea strat identifică zilnic riscurile și oportunitățile, nu la raportul de final de lună. Al treilea strat îl formează agenții AI, care preiau sarcinile repetitive din jurul semnalului — adunarea contextului, verificarea istoricului, pregătirea propunerii — și o pun în fața omului care decide. Aprobarea rămâne a omului.
Primul ecran funcțional pe datele dumneavoastră apare la patru săptămâni de la semnarea contractului, cu condiția ca accesul la ERP să fie disponibil în prima săptămână. Nu e termenul implementării complete; e momentul în care vedeți propriile date, nu o prezentare.
Capcane frecvente
- Mai multe alerte ca dovadă de progres. Un proiect care raportează „am ajuns la 40 de tipuri de alerte" raportează un risc, nu un rezultat.
- Dashboard-ul în locul rutării. Un ecran la care trebuie să te uiți activ nu înlocuiește un semnal trimis unei persoane. Oamenii ocupați nu deschid dashboard-uri în zilele aglomerate — exact zilele în care se produc problemele.
- Praguri setate de IT. Materialitatea e o decizie financiară. Dacă o stabilește echipa tehnică, va fi fie prea joasă, fie arbitrară.
- Absența buclei de feedback. Dacă nimeni nu marchează alertele false, rata lor rămâne constantă și încrederea scade lună de lună.
- Confundarea escaladării cu raportarea. Un semnal care ajunge în raportul lunar al directorului general nu a fost escaladat. A fost arhivat.
Concluzii
Detecția riscului e rezolvată în majoritatea companiilor de distribuție de talie medie. Decizia nu.
Întrebarea care contează în următoarea ședință de management nu e „ce alerte avem", ci „cât durează, în medie, de la generarea unui semnal de clasă A până la decizia unui om cu mandat". Dacă nimeni nu poate răspunde cu o cifră, traseul nu e proiectat — e întâmplător.
Un semnal fără destinatar nominal, fără prag și fără termen de răspuns este un cost de sistem, nu un instrument de control.
Întrebări frecvente
+Care e diferența între detecția unui risc și decizia asupra lui?
Detecția înseamnă că un sistem a observat o abatere: depășire de limită de credit, marjă negativă, diferență de reconciliere. Decizia înseamnă că o persoană cu mandat a ales o acțiune și a asumat-o. Între cele două stă traseul — cine primește semnalul, în cât timp și cu ce context. Majoritatea pierderilor se produc pe acest traseu, nu în lipsa detecției.
+Cum stabilesc pragul de materialitate pentru alerte?
Pragul se stabilește de directorul financiar, pe fiecare tip de semnal, nu de echipa tehnică. Sub prag, cazurile intră într-un raport agregat săptămânal; peste prag, semnalul ajunge în aceeași zi la o persoană nominală. Un prag bine ales reduce volumul de alerte cu care se confruntă decidentul fără să reducă acoperirea riscului.
+De ce nu e suficient un dashboard pentru riscurile zilnice?
Un dashboard cere ca omul să se uite activ la el. În zilele aglomerate — exact cele în care apar problemele — nimeni nu-l deschide. Semnalele cu fereastră scurtă de acțiune, cum e o comandă în picking pentru un client peste limita de credit, trebuie împinse către o persoană, cu termen de răspuns și escaladare dacă răspunsul nu vine.
+Ce indicator arată dacă automatizarea riscului funcționează?
Timpul mediu de la generarea semnalului până la decizia documentată a unui om cu mandat, măsurat separat pe fiecare clasă de semnal. Numărul de alerte generate nu spune nimic despre eficacitate; poate chiar semnala o problemă, dacă volumul depășește capacitatea de decizie a echipei.
+Trebuie să schimb ERP-ul ca să rezolv traseul de la alertă la decizie?
Nu. CIBINNO AI Business OS se așază peste sistemele existente — ERP-ul pe care îl aveți, WMS, conturile bancare, ANAF, emailul și fișierele — fără migrare de date și fără modificări în implementarea actuală. Problema nu e sistemul sursă, ci lipsa unui traseu proiectat între semnal și decident.
+În cât timp vedem ceva pe datele noastre?
Primul ecran funcțional pe datele proprii apare la patru săptămâni de la semnarea contractului, dacă accesul la ERP este disponibil în prima săptămână. Acesta nu este termenul implementării complete, ci momentul în care verificați rezultatele pe datele companiei, nu pe o demonstrație.
Cosmin Balaban · 15 octombrie 2026
Vă scriem în ziua în care publicăm un articol nou. Atât. Vă puteți dezabona oricând.
