Idei principale
- AI va prelua o mare parte din ce văd utilizatorii într-un ERP — meniuri, rapoarte standard, întrebări de rutină. Nu va prelua stratul care înregistrează că o vânzare a avut loc, că marfa s-a mișcat sau că o factură a fost înregistrată: acolo e nevoie de consecvență, drepturi de acces și pistă de audit, iar AI este probabilistic prin construcție.
- Testul util pentru un sistem operațional nu este dacă arată o abatere, ci dacă urmărește o decizie până la rezultatul ei: observație, ipoteză, acțiune, dovadă. Majoritatea software-ului se oprește la primul pas.
- Când datele nu mai alimentează doar rapoarte, ci acțiuni, erorile devin mai scumpe și mai greu de văzut — explicația unui agent rămâne coerentă, dar coerentă despre versiunea greșită a afacerii.
În ultimele două decenii am lucrat cu implementări de ERP, cu date operaționale și cu firme de retail aflate în stadii foarte diferite de maturitate. Un tipar s-a repetat constant: o companie poate investi serios într-un ERP și tot pregătește raportul săptămânal al patronului combinând manual câteva fișiere Excel.
Rareori problema este lipsa software-ului. Mai des, sisteme diferite conțin definiții, procese și versiuni diferite ale aceleiași realități de business. Cineva trebuie să le pună cap la cap, să decidă în ce cifre are încredere și să explice rezultatul conducerii. Pe drum se pierde sau se reinterpretează informație, oamenii repetă aceeași muncă în fiecare lună, iar urmărirea unei cifre discutabile până la sursă devine dificilă. Am scris separat despre cât costă asta zi de zi.
Pentru multe firme de retail și HoReCa, această problemă de bază a raportării încă nu e rezolvată. Între timp, așteptările au trecut cu mult dincolo de raportare. Companiile vor un sistem care observă o abatere importantă, oferă o explicație, pornește o reacție și, în cele din urmă, spune dacă acea reacție a produs un rezultat măsurabil.
Când analiza se transformă în acțiune
Imaginează-ți că marja pe o categorie începe să scadă în mai multe magazine. Un sistem BI clasic pune schimbarea pe un dashboard. Tot cineva trebuie să o observe, să caute cauza, să decidă ce face, să comunice decizia și să revină mai târziu ca să vadă dacă a funcționat.
Un sistem mai capabil ar analiza structura scăderii: dacă a crescut ponderea produselor cu marjă mică, dacă o promoție a mers altfel decât se planificase, dacă s-au schimbat prețurile de achiziție, dacă produsele-cheie au lipsit de pe raft, dacă s-a modificat mixul de vânzări. Apoi ar putea propune o acțiune — verificarea expunerii, mutarea stocului între magazine, ajustarea următoarei comenzi, schimbarea unei promoții, atribuirea unei sarcini managerului potrivit — iar peste o săptămână sau o lună ar reveni la acea decizie și ar compara-o cu vânzările, marja, rulajul stocului, pierderile și cash-ul.
Observație, ipoteză, acțiune, dovada rezultatului. Majoritatea software-ului de business arată destul de bine ce s-a întâmplat. Mult mai puțin din el poate duce o decizie până la efectul ei economic.
Eu numesc secvența asta buclă de dovadă; eticheta contează mai puțin decât ultimul pas. Odată ce el există, raportarea nu mai e doar un mod de a privi afacerea, ci devine parte din felul în care afacerea reacționează — schimbarea pe care am argumentat-o în de la contabilitate la navigație, și motivul pentru care marql ține un registru de impact cu ce a făcut fiecare recomandare pusă în practică asupra cifrelor.
Există mai multe niveluri posibile de reacție și nu sunt interschimbabile. Un sistem poate pune o recomandare în fața unui manager și să se oprească. Poate crea o sarcină și să îi urmărească finalizarea. Pentru un proces îngust și repetitiv, poate acționa singur în limite stabilite dinainte. Poate pregăti un transfer de marfă între locații, dar să ceară aprobarea unui responsabil de operațiuni; poate mări o comandă într-un interval agreat, dar să escaladeze o achiziție mai mare. Deciziile care ating prețurile, angajamentele mari de achiziție sau o parte însemnată din stoc cer alt nivel de control decât ajustările de rutină.
Scopul nu este să predai cât mai multe decizii. Partea grea este să stabilești ce acțiuni sunt reversibile, ce limite pot fi fixate din start și unde costul unei erori justifică în continuare aprobarea unui om.
Același lucru e valabil și pentru ideea la modă de a discuta cu propria afacere. O interfață conversațională chiar e utilă, dar nu pentru că patronii ar fi așteptat încă o cale de a cere un raport. Ei vor să știe care abatere contează, ce a putut-o cauza, cine trebuie să reacționeze și dacă decizia a meritat. Limbajul natural face procesul mai ușor de atins. Nu face informația de dedesubt mai de încredere.
Partea din ERP pe care AI nu o poate înlocui
Întrebarea dacă AI va înlocui ERP-ul amestecă, de obicei, două funcții destul de diferite.
Prima e tot ce văd utilizatorii: meniuri, formulare, rapoarte standard, ecrane de aprobare, fluxuri analitice predefinite. Mare parte din asta se va schimba. Oamenii vor pierde mai puțin timp căutând un raport anume sau parcurgând un șir lung de ecrane, iar agenții vor prelua multe interogări, verificări și pași de flux de rutină.
A doua e mai puțin vizibilă. ERP-ul, POS-ul, contabilitatea și gestiunea înregistrează evenimente de business. Ele stabilesc că o vânzare a avut loc, că marfa a fost recepționată, că un produs a fost casat, că bunurile s-au mutat între locații, că un preț s-a schimbat, că o factură a fost înregistrată. Aceste evenimente nu se nasc în stratul de AI. Ele tot trebuie captate, legate între ele și stocate după reguli definite.
Un sistem contabil nu poate concluziona că o tranzacție probabil a avut loc. Trebuie să înregistreze ce s-a întâmplat, să păstreze documentele justificative și un istoric pe care cineva îl poate verifica mai târziu. Un retailer are nevoie să știe nu doar soldul curent al stocului, ci și ce recepții, vânzări, transferuri, retururi și casări l-au produs. AI este probabilistic prin construcție, ceea ce ajută atunci când sarcina cere interpretare, informație incompletă sau o gamă de răspunsuri plauzibile. Un sistem de înregistrare are altă responsabilitate: consecvență, repetabilitate, drepturi de acces, pistă de audit. Adăugarea de AI nu face aceste cerințe să dispară.
Granița nu e totuși absolută. AI poate îmbunătăți considerabil introducerea și controlul datelor în ERP fără să devină el însuși sistemul de înregistrare. Un agent bine țintit poate citi o factură, o comandă sau un aviz și poate pregăti câmpurile pentru verificare, poate potrivi un furnizor sau un SKU cu nomenclatorul existent, poate observa un detaliu lipsă și semnala o eroare probabilă înainte ca tranzacția să fie înregistrată. Alți agenți pot urmări ce s-a înregistrat deja, căutând dubluri, înregistrări lipsă, valori neobișnuite, clasificări inconsecvente sau tranzacții care nu se împacă cu operațiunile conexe. În loc să iasă la iveală la închiderea lunii, aceste probleme pot fi rezolvate aproape de momentul în care apar.
Nu tot ce ține de asta merită numit AI. Dacă un câmp obligatoriu e gol sau o valoare iese dintr-un interval cunoscut, o regulă clasică prinde problema mai sigur și mai ieftin. Metodele statistice și învățarea automată tradițională sunt bune la găsit tipare neobișnuite în volume mari de tranzacții. AI-ul generativ și agenții își merită locul acolo unde sistemul trebuie să citească un document nestructurat, să interpreteze context, să explice o anomalie sau să propună ce urmează. O arhitectură practică le folosește pe toate trei și alege după natura problemei. Piața lucrează adesea în ordinea inversă: totul e descris ca AI mai întâi, iar problema e definită după aceea.
Datele proaste devin mai scumpe
Când datele sunt folosite doar pentru raportare, o eroare strică un raport. Când aceleași date încep să genereze recomandări și acțiuni, consecințele se schimbă. Un sold de stoc greșit duce la o achiziție inutilă. Un SKU duplicat distorsionează performanța categoriei. Clasificările inconsecvente afectează deciziile de sortiment, iar înregistrările întârziate fac sistemul să reacționeze la o situație care nu mai există. Aceleași probleme spulberă orice încercare ulterioară de a calcula ce a adus o decizie.
AI poate face riscul ăsta mai puțin vizibil, pentru că răspunsul lui sună convingător. Un agent poate răspunde cu încredere la întrebarea patronului, poate identifica un tipar plauzibil și poate recomanda o direcție rezonabilă. Dacă datele sursă sunt incomplete sau inconsecvente, explicația va rămâne coerentă. Doar că va fi coerentă despre versiunea greșită a afacerii.
Un Porsche 911 poate avea o inginerie excepțională, și nimic din ea nu elimină nevoia de combustibil. Într-un sistem de business condus de AI, combustibilul e format din date corecte, structurate și la timp.
Tot de aceea nu sunt convins că AI va ieftini automat implementările de ERP. Va reduce costul unor sarcini individuale — procesarea documentelor, potrivirea nomenclatoarelor, detectarea anomaliilor, documentarea integrărilor, diagnosticul de primă linie. Dar, în același timp, companiile cer mai mult de la datele lor: mai mult detaliu, disponibil mai devreme, consecvent între tot mai multe sisteme. Natura muncii se schimbă; munca nu dispare. În unele cazuri implementarea devine mai pretențioasă, fiindcă rezultatul nu mai e destinat doar unui raport de management. Un analist se poate uita la o cifră ciudată și poate decide că ceva e probabil greșit. Un proces automat are nevoie ca acea incertitudine să fie detectată înainte să ajusteze o comandă sau să realoce stoc — argumentul pentru a trata raportarea drept ceva ce ții în funcțiune, nu un proiect pe care îl termini.
De unde se începe, practic
Pentru un patron, punctul de plecare rezonabil nu e nici cel mai spectaculos produs de AI, nici încercarea de a înlocui tot mediul contabil. Este o singură decizie de management care se repetă și unde un răspuns mai bun și mai rapid ar aduce valoare măsurabilă — marja pe categorie, pierderile, rupturile de stoc, alocarea mărfii, achizițiile.
Odată scenariul definit, poți întreba de ce date are nevoie, de unde vin ele, cât sunt de sigure, ce anume are voie sistemul să facă și cum se va măsura rezultatul. De obicei asta scoate destul de repede la iveală starea reală a infrastructurii și împiedică proiectul să devină o inițiativă generală de AI, fără proprietar operațional și fără rezultat economic.
Pentru majoritatea lanțurilor de magazine și a grupurilor HoReCa deja consolidate, înlocuirea POS-ului, a ERP-ului sau a platformei contabile nu e primul pas. Ruta practică e să lucrezi cu sistemele deja existente. POS-ul dă de obicei datele de bază; ERP-ul, contabilitatea și gestiunea adaugă achiziții, costuri, stocuri și informație financiară. Conectarea lor e doar începutul — produsele, categoriile, locațiile, tranzacțiile, prețurile și soldurile tot trebuie aduse într-un singur model, care rămâne comparabil între magazine, sisteme și perioade.
Asta e partea din marql care atrage cel mai puțin atenția și decide cel mai mult. Se conectează read-only la sistemele pe care lanțul le rulează deja, găzduit în UE, le normalizează într-un singur model și răspunde la a doua întrebare despre o cifră în aceeași conversație cu prima. O parte din reconciliere e automatizată; excepțiile tot cer oameni care înțeleg afacerea. Prețurile pornesc de la 200 EUR pe lună.
Nu mă aștept ca AI să elimine sistemele ERP și contabile în viitorul previzibil. Le va face interfețele mai puțin centrale, va prelua munca analitică de rutină, va simplifica introducerea datelor și va întări controalele. Responsabilitatea de a înregistra corect evenimentele de business rămâne unde este. De-a lungul anilor am văzut de repetate ori cum instrumentele analitice noi scot la iveală slăbiciunile evidenței operaționale, în loc să elimine nevoia de ea. AI le va scoate la iveală mai repede și, în unele cazuri, va acționa pe baza informației înainte ca un om să o fi verificat.
Vezi pe datele tale
Alege decizia pe care o iei în fiecare săptămână și pe care ai prefera-o luată pe dovezi. Conectăm sistemele pe care le ai deja și îți arătăm ce pot și ce nu pot răspunde datele tale despre ea.
Înregistrează ce s-a întâmplat. Decide ce faci. Apoi verifică dacă a funcționat.

Scris de
Evan Kazakov
Cofondator, marql