De ce stack-ul tău de raportare nu mai poate fi un proiect unic

Un lanț de retail sau un grup de restaurante putea cândva să planifice implementarea unei tehnologii așa cum planifica renovarea unui magazin. Alegea un sistem, îl implementa în șase luni până la un an și îl folosea aproape neschimbat în următorii trei până la cinci ani. Acest calendar avea sens când și afacerea se schimba cam în același ritm.

Acum nu mai are. O rețea care își revizuia strategia o dată pe an ajunge astăzi să schimbe direcția într-un trimestru, uneori în câteva săptămâni, pentru că s-a schimbat relația cu un furnizor, s-a deschis sau s-a închis un canal ori mișcarea unui concurent a impus o reacție pe care nimeni nu o putea planifica cu un an înainte. Toate afacerile cu care am lucrat au ajuns să aibă nevoie de schimbare mai repede. Foarte puține dintre sistemele lor de raportare au ținut pasul.

Ce înseamnă de obicei „digitalizare” și de ce se oprește acolo

Majoritatea implementărilor de raportare și BI pe care le-am văzut au aceeași formă. Cineva definește rapoartele de care afacerea are nevoie astăzi, un sistem este construit sau configurat să producă exact acele rapoarte, iar proiectul este declarat încheiat. Un an sau doi funcționează bine. Apoi afacerea pivotează, iar rapoartele construite cu grijă pentru întrebările anului trecut încetează discret să mai fie rapoartele de care are nevoie cineva.

În acel moment, actualizarea stack-ului de raportare devine un proiect în sine. Cineva trebuie să definească noile cerințe, să obțină bugetul și să aștepte un ciclu de dezvoltare, iar până când noile rapoarte sunt livrate, afacerea poate să fi schimbat deja din nou direcția. Acest lucru corespunde unei idei cunoscute din managementul strategic. Teoria capabilităților dinamice a lui Teece, Pisano și Shuen susține că avantajul competitiv vine rareori din faptul că ai luat o dată decizia corectă sau ai construit planul perfect. El vine din observarea continuă a schimbărilor și oportunităților, înțelegerea semnificației lor pentru afacere și adaptarea suficient de rapidă pentru a le folosi (Teece, Pisano & Shuen, 1997). Un fost șef, care m-a obișnuit și să fac sport, numea asta să ții periscopul ridicat. Majoritatea stack-urilor de raportare sunt construite ca și cum această observare continuă s-ar încheia în ziua în care se închide proiectul.

De ce afectează asta mai ales retailul și HoReCa cu mai multe locații

O afacere cu o singură locație poate uneori să compenseze un stack de raportare învechit cu un tabel și un manager care cunoaște bine magazinul. O rețea cu zece, treizeci sau o sută de locații nu are această opțiune. Fiecare pivotare, un format nou, un canal nou de livrare, o schimbare în mixul de categorii, o regiune nouă, trebuie să fie vizibilă consecvent în toate locațiile aproape imediat. Altfel, conducerea pierde tocmai lucrul care a făcut rețeaua gestionabilă: o perspectivă comparabilă între locații.

Când stack-ul de raportare nu poate ține pasul, de obicei nu apare un eșec dramatic. Apare o derivă lentă. Conducerea începe să pună întrebări la care rapoartele actuale nu pot răspunde, cineva construiește un tabel punctual pentru a acoperi golul, acel tabel devine sursa neoficială de adevăr pentru o anumită întrebare, iar într-un an compania funcționează discret pe un mozaic de soluții improvizate pe care nimeni nu le-a planificat și în care nimeni nu are încredere deplină.

Un strat de raportare care nu trebuie redefinit de fiecare dată când afacerea schimbă direcția este un alt tip de sistem.

Un mod diferit de a construi stratul de raportare

Încercarea de a anticipa fiecare întrebare viitoare printr-o implementare mai mare și mai cuprinzătoare nu funcționează, fiindcă nimeni nu poate defini întrebările unei afaceri cu trei pivotări înainte. Funcționează mai bine un strat de raportare care nu trebuie redefinit de fiecare dată când afacerea schimbă direcția, iar acesta este un alt tip de sistem de construit.

Acesta este motivul practic pentru care marql este construit în jurul unei întrebări, nu al unui set fix de rapoarte. Un lanț de retail, un grup de restaurante sau o rețea de franciză își păstrează sistemele existente exact așa cum sunt, POS, contabilitate, inventar, conectate read-only și găzduite în UE. Când afacerea pivotează și apare o întrebare nouă, fie că este despre performanța timpurie a unui canal nou sau despre efectul unei schimbări de categorie asupra stocului, aceasta devine o conversație nouă, nu un ciclu nou de dezvoltare. Nimeni nu trebuie să depună o cerere pentru un raport care încă nu există.

Nu pretindem că acest lucru face singur o organizație agilă. Un strat de raportare este o parte dintr-un tablou mai larg care include oamenii, procesele și drepturile de decizie, iar niciun produs nu schimbă singur toate acestea. Ceea ce putem spune clar este mai restrâns: o analiză calificată a stack-ului, o primă vizualizare live în 24 de ore și prețuri de la 200 EUR pe lună, cu scopul precis de a elimina întârzierea dintre pivotarea unei afaceri și un stack de raportare capabil să răspundă întrebărilor despre ea.

Întrebarea care merită pusă înainte de următoarea pivotare

Majoritatea companiilor descoperă că stack-ul lor de raportare a rămas în urma afacerii în cel mai prost moment posibil, chiar în mijlocul unei pivotări, când conducerea are nevoie de un răspuns pe care rapoartele actuale nu au fost construite să îl ofere. Merită verificat mai devreme. Când afacerea ta și-a schimbat ultima dată direcția, cât a durat până când raportarea a putut vedea clar noua imagine?