Implementare software în retail: ce m-a învățat un rollout ERP de două luni

Primul sistem de business pe care l-am implementat l-am construit la nouăsprezece ani, singur, în aproximativ două luni. Privind în urmă, peste douăzeci de ani de implementări, aproape nimic din ce am făcut bine în cele două luni nu ținea de cod.

Compania distribuia ziare și reviste prin peste cincizeci de chioșcuri dintr-un oraș. Livrări, stoc, retururi, un depozit, gestiunea numerarului și deconturile cu furnizorii, toate pentru un produs cu o viață comercială brutal de scurtă. Un ziar își pierde valoarea mai repede decât laptele, iar fiecare proces din acea afacere era modelat de faptul ăsta.

Eram singurul programator. Un administrator de sistem m-a învățat cum să descompun o problemă și cum să țin codul într-o oarecare ordine. Tot ce ținea de implementare — să vorbesc cu oamenii, să le schimb modul de lucru, să fac lucrul acela adoptat — am învățat greșind în fața unui public.

Cincizeci de chioșcuri, două luni și habar n-aveam că era nerezonabil

Sarcina era să iau o bază software existentă și să o extind până acoperea operațiunile, stocul și numerarul din toată compania. Ce mă frapează acum este felul în care a gestionat lucrurile directorul general. De la primele discuții a vorbit cu un tânăr de nouăsprezece ani despre procese de business, despre cum își predau departamentele munca, unde se bloca informația și ce credea el că se poate organiza mai bine. Nu specificații. Afacerea.

O parte din motivul pentru care a funcționat nu mă avantajează: nu știam suficient cât să îmi dau seama că sarcina era nerezonabilă. Un manager cu experiență ar fi făcut o evaluare de riscuri, ar fi schițat un plan, ar fi cerut o echipă și ar fi explicat de ce două luni erau aproape imposibile. De multe ori ar fi avut dreptate. Neînțelegerea dimensiunii unei probleme furnizează ocazional o energie pe care un om calibrat corect nu ar cheltui-o niciodată.

Să nu știi cât de nerezonabilă e o sarcină poate fi o sursă reală de energie. Nu este însă un plan și nu supraviețuiește contactului cu a doua locație.

Scris noaptea, testat dimineața

Metoda, dacă merită cuvântul, era asta: scriam o bucată noaptea, o puneam dimineața în fața unor angajați reali care făceau muncă reală, o urmăream toată ziua, găseam cerința pe care o ratasem și o luam de la capăt. Când se termina rezerva, dormeam în camera serverelor, ținută la optsprezece grade, ceea ce la vârsta aceea se suportă. Nu îl consideram un pilot sau un rollout etapizat. Îi spuneam: cod noaptea, lansare dimineața, reparat peste zi.

Peste ani am citit lucrarea lui Hackman și Oldham din 1976 despre felul în care designul muncii produce motivație: autonomie, rezultate vizibile, sentimentul că munca are importanță și feedback imediat. Le aveam pe toate patru din întâmplare, pentru că nu era nimeni altcineva care să le aibă. Distanța dintre o decizie și consecința ei era de câteva ore, iar feedbackul venea de la oameni care trebuiau să trăiască cu ce livrasem. Rareori era diplomat și niciodată greșit.

Este cel mai puternic argument pe care îl cunosc pentru a ține oamenii de implementare aproape de operațiune. În companiile mai mari în care am lucrat după aceea, departamentele, predările și straturile de aprobare au întins distanța la săptămâni, iar calitatea feedbackului s-a degradat pe tot drumul.

De ce eroismul se oprește la a doua locație

Sistemul a intrat în funcțiune și a ajuns să țină evidența unei afaceri cu peste cincizeci de chioșcuri și câteva sute de cumpărători en-gros. Am primit un bonus de 300 de dolari și l-am dat pe o bicicletă, ceea ce la nouăsprezece ani este o alocare de capital defendabilă. Munca a continuat după punerea în funcțiune: logică de reaprovizionare, generare de comenzi de achiziție, recomandări pentru casarea retururilor și, în cele din urmă, un modul de depozit care le spunea oamenilor unde să meargă. A venit un al doilea programator și am devenit mentor fără să am idee cum se face.

De aici vine corecția pe care i-aș da-o celui de nouăsprezece ani. Responsabilitatea personală duce un prim proiect remarcabil de departe, iar apoi se oprește. Nicio organizație nu ar trebui să depindă de disponibilitatea unui singur om de a renunța la somn. Trebuie convertită în proces, documentație, cunoaștere pe care o dețin mai mulți oameni și sisteme care merg fără salvare. Punctul înrudit despre stratul de raportare în particular, că nu poate fi specificat o dată și lăsat ani întregi, este subiectul articolului de ce stack-ul tău de raportare nu mai poate fi un proiect unic.

Întrebările care îți spun că implementarea a funcționat

Tentația este să judeci un rollout după cât de bine a respectat planul și după cât de curată e partea de inginerie. Arhitectura contează, iar o arhitectură proastă devine până la urmă o problemă de business, doar pe un ceas mai lent. Dar o echipă de tehnologie nu se poate nota singură doar după cât de bine își organizează propriul proces. Iată întrebările pe care le pun în schimb, la o lună sau două după punerea în funcțiune:

• A scăzut într-adevăr rata erorilor și se vede asta în date, nu doar în impresii?
• Oamenii termină aceeași muncă mai repede sau munca s-a mutat doar la altcineva?
• Managementul primește aceeași informație mai devreme sau doar într-un format mai frumos?
• Stocul este mai inteligibil decât era, pe locație, categorie și perioadă?
• Ce pași manuali au dispărut complet și care doar și-au schimbat proprietarul?
• S-a schimbat vreo decizie de business din cauza sistemului și poți numi decizia?

Dacă niciuna dintre ele nu are răspuns, sistemul este funcțional. Nu este același lucru cu implementat, iar distanța dintre cele două este locul în care se pierd cei mai mulți bani din astfel de proiecte.

Softul devine parte din operațiune, nu o unealtă de lângă ea

Lucrarea lui Eric Trist despre sistemele sociotehnice, mai veche decât aproape tot softul despre care ne certăm astăzi, spune asta mai bine decât pot eu. Un sistem nou nu înlocuiește doar o unealtă. Schimbă relații, cine ce decide, cum se distribuie responsabilitatea, cât de mult au oamenii încredere în ce văd și pe ce ajung să se certe.

Dacă oamenii nu au încredere în datele de la bază, nu pot urmări de ce sistemul recomandă ceva sau petrec o parte din fiecare zi corectându-l, paguba a ieșit din software și a intrat în relațiile de muncă din jurul lui. Apariția AI a ascuțit argumentul, nu l-a înmuiat. O recomandare pe care nimeni nu o poate inspecta este o problemă de încredere înainte să fie una de experiență a utilizatorului.

Ce am dus mai departe în marql

marql este un strat deasupra sistemelor de POS, contabilitate și e-commerce pe care un lanț de magazine, un grup de restaurante sau o rețea de francize le rulează deja, read-only și găzduit în UE. Nu înlocuiește un POS sau un ERP și nu scrie nimic înapoi în ele, ceea ce este o alegere deliberată despre cât dintr-o operațiune are voie să tulbure un singur rollout.

Angajamentul pe care îl luăm este intenționat îngust: o evaluare calificată a stack-ului, o primă vizualizare live în 24 de ore și prețuri de la 200 EUR pe lună. Am prefera însă să fim judecați după lista de mai sus — dacă un responsabil de operațiuni primește un răspuns mai devreme decât înainte și dacă asta schimbă ceva. Un exemplu concret despre cum arată asta când o cifră o ia razna este în cum investighezi o lipsă în stoc.