Raportul de luni dimineață se face, în multe firme, vineri după-amiază: cineva exportă din gestiune, din programul de vânzări și din evidența producției, lipește totul într-un Excel și corectează de mână ce nu se leagă. Până ajunge la tine, cifrele sunt deja vechi, iar la întrebarea „de ce a scăzut marja?” răspunsul vine peste încă o săptămână. Un proiect de automatizare a rapoartelor elimină exportul și lipitul și lasă timp pentru întrebarea în sine.
Greul nu stă în grafice. Stă în a face programe diferite, cumpărate în perioade diferite, să vorbească la fel despre același produs, același cumpărător și aceeași zi.
Trei programe, trei răspunsuri la aceeași întrebare
Întrebi cât s-a vândut luna trecută. Vânzările îți dau valoarea comenzilor, contabilitatea valoarea facturată, iar depozitul ce a plecat pe poartă. Toate trei sunt corecte și diferite, pentru că fiecare program numără altceva: cu sau fără TVA, cu sau fără retururi, la data comenzii sau a livrării.
La fel se întâmplă cu stocul (la ce oră a zilei?) și cu marja (față de ce cost: ultimul preț de achiziție sau costul mediu?). Ședințele ajung să fie despre a cui cifră e bună, nu despre ce e de făcut.
Se adaugă codurile. Același articol are un cod în gestiune și altul în producție, iar același cumpărător apare de trei ori, scris ușor diferit.
Definițiile comune ale cifrelor
Primul lucru predat nu este un tablou de bord, ci un dicționar: pentru fiecare indicator, o propoziție care spune ce include, ce exclude, din ce program vine și la ce dată se raportează. Îl scriem cu oamenii care folosesc cifra și îl aprobă conducerea: asta face ca raportul să fie crezut.
Dicționarul se transpune apoi în calcule făcute o singură dată, în depozitul de date. Dacă definiția marjei se schimbă, o modifici într-un loc și toate rapoartele o urmează.
Tot aici stabilim cine ce vede. Un șef de punct de lucru își vede cifrele lui, nu salariile sau marjele întregii firme.
Ce cuprinde o automatizare rapoarte, de la extragere la alertă
Arhitectura este aceeași, fie că ai două programe sau opt: datele se extrag din surse, se curăță și se unesc într-un depozit, iar rapoartele citesc doar din depozit. Programele de lucru nu sunt modificate, pentru că le accesăm numai în citire, iar extragerile mari le programăm în afara orelor de vârf, ca să nu le încetinească.
Ia o firmă de producție cu două depozite și o echipă de vânzări pe teren. Componentele obișnuite ar fi:
- Conectori: câte unul pentru fiecare program, prin API (interfața oferită de program pentru schimbul de date), prin citire directă din baza de date sau prin fișiere exportate automat.
- Încărcare incrementală: la fiecare rulare se aduc doar înregistrările noi sau modificate.
- Tabele de corespondență: coduri de articole, cumpărători, puncte de lucru, unități de măsură.
- Verificări de calitate: totaluri comparate cu sursa, valori lipsă, dubluri; raportul nu se publică dacă verificarea eșuează.
- Tablouri de bord: câteva ecrane pe roluri, din care poți coborî de la total până la document.
Actualizarea programată și alertele la abateri
Cât de des se actualizează datele este o decizie de afaceri. Pentru cele mai multe rapoarte de conducere ajunge o actualizare în fiecare noapte; pentru stocuri sau producție pe schimburi poate fi nevoie de una la fiecare oră. Timpul real costă mult mai mult și rareori schimbă o decizie.
O alertă bună are prag, destinatar și acțiune. „Stocul articolului a coborât sub nivelul minim” merge la achiziții. „Rebutul pe o linie depășește media obișnuită” merge la șeful de producție. Începem cu puține alerte, alese de tine, fiindcă zece mesaje pe zi nu le mai citește nimeni.
Alertăm și despre sistemul însuși: dacă o sursă nu a răspuns, raportul o spune vizibil, lângă titlu.
Ordinea lucrului și limitele unui depozit de date
Folosim de obicei PostgreSQL ca depozit (o bază de date relațională, fără costuri de licență), scripturi Python rulate programat pentru extragere și un instrument de vizualizare precum Metabase sau Power BI, ales după ce licențe ai deja.
Limitele se spun de la început. Un program vechi, fără API și fără acces la baza de date, poate fi citit doar prin exporturi, cu mai multă muncă. Iar depozitul nu repară datele introduse greșit: dacă recepțiile se operează cu întârziere, raportul de stoc va fi la fel de întârziat.
- Discuția de început: ce decizii iei pe baza cifrelor și ce întrebări rămân azi fără răspuns.
- Primul indicator: unul singur, dus de la sursă la ecran, ca să probăm tot lanțul.
- Extinderea: indicator cu indicator, fiecare comparat cu raportul manual până când cifrele coincid.
- Predarea: dicționarul, schema depozitului și instruirea celui care va întreține rapoartele.
Întrebări frecvente
Ce se întâmplă dacă un program nu are API?
Căutăm altă cale: citire directă din baza de date, dacă furnizorul o permite, sau exporturi programate în fișiere. Dacă nu există nicio cale de a scoate datele, îți spunem de la început.
Cât de proaspete sunt cifrele din rapoarte?
Atât cât stabilim la programarea actualizării: de regulă zilnic, mai des unde se justifică. Momentul ultimei actualizări apare pe fiecare ecran.
Cât durează până apare primul raport?
Depinde de felul în care programele-sursă permit accesul la date și de cât de repede se stabilește definiția primului indicator. Curățarea codurilor de articole și de parteneri este, de obicei, etapa cea mai lungă.
Aceasta este o descriere de proiect-tip: arată cum abordăm de obicei o astfel de lucrare și nu prezintă un proiect făcut pentru un client anume. Fiecare proiect real pornește de la situația firmei tale, iar etapele, termenele și prețul se stabilesc după discuția de început.