Alerte operaționale în loc de dashboards: cum afli de probleme în 10 minute, nu la ședința de luni

Problema nu e lipsa rapoartelor

Aproape orice companie de 50-300 de angajați are deja rapoarte. Multe au și dashboards — de obicei între 5 și 15, construite în Power BI, Metabase sau direct în ERP. Când ne uităm la logurile de acces, rezultatul e aproape mereu același: 2-4 dashboards sunt deschise săptămânal, restul de 2-3 ori pe lună, de regulă chiar de persoana care le-a construit.

Nu e o problemă de disciplină. Un dashboard cere ca cineva să se întrebe, din proprie inițiativă, dacă s-a întâmplat ceva — exact în ziua în care s-a întâmplat. Nimeni nu face asta de 40 de ori pe lună pentru 12 ecrane.

Cum arată costul concret al acestei latențe:

• O ruptură de stoc la un articol din top 50 se observă luni dimineață, după ce s-au pierdut 4 zile de vânzări
• O comandă de 22.000 EUR stă blocată în aprobare 6 zile, fără ca nimeni să primească vreo notificare
• Un furnizor crește prețul cu 9%; creșterea intră în ~300 de linii de comandă înainte să o vadă cineva la raportul lunar de marjă
• Un flux de integrare moare joi seara; se descoperă marți, de la clientul care sună
• Un client care comanda de 14.000 EUR/lună scade la 3.000 EUR; se discută în ședința trimestrială, când deja a plecat

În toate cazurile datele existau în sistem la momentul potrivit. Ce lipsea era ca cineva să fie anunțat.

Ce înseamnă concret un sistem de alerte operaționale

Nu e monitorizare de infrastructură — aceea urmărește dacă serverele și API-urile trăiesc. Aici vorbim despre indicatori de business care se abat de la normal. Șase componente:

1. Un singur strat de date de încredere. Alertele se calculează dintr-un depozit de date care adună ERP, CRM, WMS și platforma de facturare. Dacă fiecare alertă interoghează direct sistemul-sursă, vei avea alerte care se contrazic între ele.

2. Reguli deterministe, cu praguri. Majoritatea valorii stă aici, nu în modele: stoc sub acoperire de 7 zile pe articolele din clasa A, marjă pe linie sub 8%, comandă neconfirmată după 48 de ore, aviz emis fără factură după 5 zile.

3. Detecție de anomalii pentru ce nu poate fi pus în prag. Vânzările unui client, numărul de retururi, timpul mediu de livrare — acestea au sezonalitate. Compari cu media mobilă pe 8 săptămâni, pe aceeași zi a săptămânii, și semnalezi abateri de peste 2,5 deviații standard.

4. Rutare către o persoană, cu context. O alertă pe un canal general nu are proprietar. Fiecare regulă are un responsabil, iar mesajul conține articolul, clientul, cifra, variația și link-ul direct în sistem — nu "verifică raportul".

5. Confirmare, escaladare, istoric. Alerta se închide cu un motiv: rezolvat, fals pozitiv, acceptat. Fără asta nu poți calibra nimic după trei luni.

6. Bucla de calibrare. Lunar: câte alerte au fost false pozitive, care regulă produce zgomot, ce incident a trecut neobservat și trebuie regulă nouă.

De ce "mai punem un dashboard" nu rezolvă

• Pull vs. push. Dashboardul presupune că omul vine la date. Alerta duce datele la om. La incidente care costă bani în 24-48 de ore, diferența e decisivă.
• Lipsa pragului. Un grafic arată o linie care coboară. Nu spune dacă e normal pentru octombrie. Pragul forțează o decizie pe care dashboardul o lasă deschisă.
• Nimeni nu e responsabil. Un dashboard e al tuturor, deci al nimănui. O alertă are un nume în spate.

Dashboardurile rămân utile — pentru investigație, după ce primești alerta. Rolul lor e de context, nu de detecție.

Studiu de caz: distribuitor FMCG, 7 depozite, 4.200 de SKU-uri

Un distribuitor cu 190 de angajați și rulaj de 31 de milioane EUR avea 9 rapoarte în Power BI și un controller care trimitea manual un email de sinteză vineri. Problemele apăreau constant între două rapoarte.

Ce am construit împreună cu echipa de la NEXVA SYSTEM:

• Un depozit de date alimentat din ERP și WMS la fiecare 15 minute, plus încărcare nocturnă pentru date de contabilitate
• 23 de reguli deterministe la lansare, din care doar 11 cu prioritate ridicată: acoperire de stoc, marjă sub prag pe linie, comenzi blocate, avize nefacturate, diferențe de preț furnizor față de contract
• Detecție de anomalii pe vânzările celor mai importanți 200 de clienți și pe timpul de livrare per depozit
• Rutare în Slack pe trei canale (achiziții, vânzări, financiar) și SMS doar pentru două reguli critice
• Buton de confirmare pe fiecare alertă, cu motiv de închidere, și raport lunar de calibrare

Rezultate după 6 luni:

• Timp median de la apariția problemei la cineva care o vede: de la ~3,5 zile la 22 de minute
• Rupturi de stoc pe articolele din clasa A: -34% (de la 61 la 40 de evenimente/lună)
• Diferențe de preț furnizor prinse înainte de facturare: 18.400 EUR recuperați în primele 5 luni
• Avize nefacturate la final de lună: de la 46 la 3 în medie
• Rata de fals pozitive: 31% în prima lună, 9% după două runde de calibrare
• Volum de alerte: a scăzut de la 140/săptămână la 48/săptămână după eliminarea a 6 reguli redundante — cu mai multe incidente prinse, nu mai puține

Observația care nu era în plan: două depozite aveau timpi de livrare constant cu 1,8 zile mai mari decât restul. Nu apărea în medie națională. Alerta pe anomalie per depozit a scos-o la lumină în a treia săptămână.

Cum eviți oboseala de alerte

Aici eșuează majoritatea proiectelor. Reguli care funcționează în practică:

• Maxim 5 alerte pe zi per persoană. Peste acest nivel oamenii încep să le ignore, inclusiv pe cele reale.
• Trei niveluri de severitate, cu canale diferite: critic (SMS, răspuns în 1 oră), important (Slack, în aceeași zi), informativ (sinteză zilnică, nu notificare).
• Fereastră de deduplicare. Același articol, aceeași regulă: o singură alertă la 24 de ore, nu una la fiecare rulare.
• Fiecare alertă trebuie să aibă o acțiune posibilă. Dacă răspunsul e "bine, și ce fac acum?", regula nu are ce căuta în sistem.
• Calibrare pe date istorice înainte de lansare. Rulează regula pe ultimele 6 luni și numără câte alerte ar fi generat. Dacă ies 400, pragul e greșit.

Cât costă și când se întoarce investiția

| Componentă | Cost |

|-----------|------|

| Analiză: ce incidente costă bani, ce date există, cine răspunde | 2.000-3.500 EUR |

| Strat de date unificat din ERP, CRM, WMS | 4.000-9.000 EUR |

| Motor de reguli, praguri, rutare și confirmare | 3.500-6.500 EUR |

| Detecție de anomalii pe serii sezoniere | 2.500-5.000 EUR |

| Hosting, mentenanță și calibrare lunară | 200-450 EUR/lună |

Returul are două componente. Prima, directă: timpul eliberat la controlling și la raportarea manuală — 15-25 de ore/lună, adică 3.000-6.000 EUR/an.

A doua e cea care contează. La un rulaj de 30 de milioane EUR cu marjă brută de 18%, o reducere de 30% a rupturilor pe articolele cu rotație rapidă valorează ușor 60.000-120.000 EUR/an în vânzări nepierdute. Adaugă diferențele de preț prinse înainte de plată și avizele facturate la timp, și proiectul se amortizează, tipic, în 4-7 luni.

Greșelile care strică proiectul

• Lansare cu 60 de reguli. Zgomot din prima săptămână și pierderea încrederii. Începi cu 8-12 reguli care acoperă incidentele care te-au costat efectiv bani anul trecut.
• Alerte pe date de proastă calitate. Dacă stocul din ERP e inexact, alerta de ruptură va fi fals pozitivă constant. Repară datele înainte, nu după.
• Notificări pe email. Ajung în folderul cu rapoarte automate și mor acolo. Canalul trebuie să fie cel în care echipa lucrează deja.
• Fără proprietar pe regulă. Alerta fără nume în spate nu produce nicio acțiune.
• AI pentru ce se rezolvă cu un prag. Detecția de anomalii are sens pe serii sezoniere, nu pe "stoc sub 10 bucăți".
• Fără măsurătoare de bază. Notează acum: de câte zile afli de o problemă, câte rupturi ai pe lună, câte avize nefacturate. Fără asta nu vei putea demonstra nimic.

Cum începi

1. Fă lista incidentelor din ultimele 12 luni care au costat peste 1.000 EUR fiecare. Grupează-le. Vei vedea că 6-8 tipuri acoperă 80% din pierderi.

2. Verifică pentru fiecare dacă datele existau în sistem cu 24 de ore înainte. Dacă nu, problema e de colectare, nu de alertare.

3. Scrie 8-12 reguli cu prag, proprietar și acțiune așteptată. Pe hârtie, înainte de orice linie de cod.

4. Rulează-le pe date istorice și ajustează pragurile până ieși sub 5 alerte/zi per persoană.

5. Lansează cu un singur canal și un singur departament, 4 săptămâni. Abia apoi extinde la restul și adaugă detecția de anomalii.

Diferența dintre o companie care reacționează în 20 de minute și una care află luni dimineață nu e în calitatea analiștilor. E în faptul că una dintre ele a transformat 10 întrebări recurente în 10 reguli care se întreabă singure, non-stop.

Vrei să vezi care dintre incidentele care te-au costat bani anul trecut puteau fi prinse automat cu datele pe care le ai deja? Programează o consultație gratuită.