Modernizarea unui sistem de depozit vechi de 12 ani fără a opri camioanele

Cel mai periculos software dintr-o firmă mică este software-ul care funcționează. Nu unealta plină de erori de care se plânge toată lumea — aceea ajunge totuși înlocuită. Cel periculos este sistemul vechi de doisprezece ani pe care nu-l iubește nimeni, dar de care depind toți, cel care pornește dintr-un calculator bej din colț și care conduce depozitul de dinainte ca jumătate din echipă să fie angajată. Funcționează. Până în ziua în care aproape că nu mai funcționează, iar toți își dau seama deodată că întreaga afacere e echilibrată deasupra lui.

Aceasta este povestea unuia dintre aceste sisteme și a felului în care l-am înlocuit. Clientul este un distribuitor regional — câteva mii de linii de produse, un singur depozit, în jur de treizeci de angajați între hală și birou. I-am anonimizat și am rotunjit cifrele, dar forma proiectului este exact așa cum s-a întâmplat. Dacă stați pe un sistem îmbătrânit de care vă temeți să-l atingeți, cam așa arată din interior o modernizare cu cap.

În această poveste nu există o rescriere eroică, niciun weekend în care am apăsat un buton și totul a devenit nou. Tot rostul — lucrul care a făcut-o să meargă — este că nu s-a întâmplat nimic dramatic. Camioanele au continuat să se încarce. Depozitul abia dacă a simțit cum i se schimbă podeaua sub picioare. Acesta este scopul în lucrul cu sistemele vechi și merită înțeles de ce.

Situația: un sistem ținut laolaltă de memoria unei singure persoane

Depozitul funcționa pe un sistem personalizat construit prin 2013 de un dezvoltator care plecase de mult. Își făcea treaba de bază — urmărea stocul, tipărea listele de culegere, trimitea comenzile pe ușă afară — și într-o zi obișnuită o făcea bine. Problema nu era de fapt software-ul. Problema era tot ce crescuse în jurul software-ului pentru a-l păstra utilizabil.

Timp de un deceniu, echipa construise în liniște un sistem-umbră din bandă adezivă: un tabel pentru numărătorile de stoc pe care software-ul le greșea, un al doilea tabel care îl reconcilia pe primul cu realitatea, un grup de WhatsApp în care șeful de depozit semnala articolele pe care sistemul nu le putea reprezenta și un dosar tipărit de soluții de avarie pe care noii angajați trebuiau să le memoreze. Nimic din toate astea nu era scris într-un singur loc. Trăia în capul șefei de operațiuni, o femeie calmă de vreo cincizeci de ani, care era acolo de paisprezece ani și care era, practic, documentația.

Când proprietarul ne-a sunat prima dată, nu a fost din cauza unei căderi. A fost pentru că ea anunțase că vrea să se pensioneze peste doi ani, iar el făcuse socoteala și își dăduse seama că, în ziua plecării ei, o parte semnificativă din felul în care funcționa de fapt depozitul avea să iasă pe ușă odată cu ea. E un declanșator de modernizare mai frecvent decât orice avarie tehnică: nu sistemul care se strică, ci constatarea că oamenii care îl peticesc nu vor fi acolo pentru totdeauna.

Simptomele pe care toți încetaseră să le mai observe

Când am petrecut primele două zile doar privind cum lucrează depozitul, costurile sistemului vechi erau peste tot — dar deveniseră atât de normale încât nimeni nu le mai semnala drept probleme. Cifrele de stoc erau de încredere că sunt greșite cu o marjă previzibilă, așa că fiecare comandă mare trecea printr-o verificare fizică manuală „pentru orice eventualitate”. Noii angajați aveau nevoie de săptămâni ca să devină utili, fiindcă mare parte din muncă era folclor nescris. Iar sistemul rula pe un sistem de operare atât de vechi încât nu mai putea fi actualizat, stând pe o rețea despre care proprietarul știa în sinea lui că e un incident de securitate care aștepta să se întâmple.

• Acuratețea inventarului se învârtea în jur de 80%, așa că angajații verificau manual numărătorile la orice era important — ore pe zi, în tăcere.
• Logica listei de culegere nu făcea față dispunerii actuale a depozitului, așa că culegătorii mergeau pe ruta indicată de dosar, nu de ecran.
• Reconcilierea stocului la final de lună le lua la doi oameni mai bine de trei zile.
• Doar o singură mașină putea rula partea de administrare a software-ului, iar dacă murea, nimeni nu avea un plan clar.
• Nimic nu se conecta la canalul de comenzi online pe care firma îl adăugase în 2019 — acele comenzi erau retastate manual.

Ce am ales deliberat să nu facem

Mișcarea evidentă — cea pe care ar fi propus-o mulți furnizori — este să cumperi o platformă mare de gestiune a depozitului de-a gata, să migrezi totul într-un weekend și să oprești sistemul vechi luni dimineață. Am văzut această abordare dând greș de suficiente ori încât să nu o propunem unei afaceri ca aceasta. O trecere bruscă presupune că înțelegi complet sistemul vechi. Cu un deceniu de soluții de avarie nedocumentate, nimeni nu-l înțelegea — nici măcar cei care îl operau.

A doua mișcare tentantă este o rescriere personalizată completă, de la zero: iei tot ce face sistemul vechi, îl reconstruiești curat, lansezi noul sistem. Sună responsabil și e o cale clasică de a arde un an și un buget mare în timp ce afacerea așteaptă, înghețată, un înlocuitor care tot întârzie. Necazul e că o rescriere trebuie să reproducă fiecare ciudățenie înainte de a putea fi lansată — inclusiv ciudățeniile despre care nimeni nu-și amintește că sunt de rezistență până când lipsesc.

Așa că nu am făcut niciuna dintre ele. Am tratat sistemul vechi nu ca pe un lucru de demolat, ci ca pe un lucru de înconjurat și înlocuit încet — câte o capabilitate o dată, cu sistemul vechi rulând în continuare dedesubt ca plasă de siguranță tot drumul. Lipsit de glorie. Și totodată singura variantă a acestui lucru care funcționează de încredere.

Abordarea: sugrumă sistemul vechi, nu-l arunca în aer

Există un nume binecunoscut printre dezvoltatori pentru acest tipar — abordarea „strangulatorului”, după o liană care crește în jurul unui copac până se poate ține singură, iar originalul dispare în liniște. Nu înlocuiești sistemul vechi dintr-o mișcare. Construiești piese noi în jurul lui, direcționezi munca reală către ele una câte una și lași sistemul vechi să se micșoreze până ce ce rămâne e destul de mic încât să-l oprești fără ca nimeni să-și țină respirația.

Pentru acest depozit, asta a însemnat să convenim dinainte o ordine: ce capabilitate desprindem prima, pe care o păstrăm la urmă și — crucial — o regulă că la fiecare etapă, dacă piesa nouă se comporta prost, puteam reveni imediat la vechiul mod chiar în aceeași zi. Niciun pas nu a fost lăsat să fie un punct fără întoarcere până la final. Tocmai acea regulă i-a permis proprietarului să doarmă și i-a făcut pe angajații depozitului să aibă încredere în proiect, în loc să se crispeze împotriva lui.

1. 1
   Cartografiați ce face de fapt sistemul

   Trei săptămâni de urmărire a halei și a biroului pentru a documenta fluxul de lucru real — inclusiv fiecare tabel și soluție de avarie din dosar. Am scris sistemul care exista, nu pe cel descris de specificația originală.
2. 2
   Reparați datele înainte de a le muta

   Am făcut o numărătoare fizică completă a stocului și am curățat baza de date a produselor în raport cu ea. Migrarea datelor murdare într-un sistem nou îți dă doar un răspuns greșit mai rapid — așa că asta a venit înainte ca vreun software nou să atingă datele.
3. 3
   Înlocuiți prima dată piesa cea mai dureroasă

   Am construit noul modul de urmărire și numărare a stocului, l-am rulat în paralel cu cel vechi și ne-am încrezut în el abia când cifrele s-au potrivit cu realitatea timp de o lună întreagă.
4. 4
   Conectați canalele pe care sistemul vechi le ignora

   Apoi am legat canalul de comenzi online direct la noile date de stoc, eliminând retastarea manuală care exista în liniște din 2019.
5. 5
   Desprindeți restul, apoi retrageți nucleul vechi

   Culegerea, raportarea și reconcilierea au trecut una câte una. Când aproape nimic real nu mai rula pe sistemul vechi, l-am oprit în sfârșit — un non-eveniment până atunci.

Părțile care au fost cu adevărat grele

Ar fi necinstit să prezentăm asta ca pe ceva lin. Munca tehnică a fost partea ușoară. Părțile grele au fost umane și procedurale și sunt aceleași părți grele de pe aproape orice proiect cu sistem vechi.

Regula nedocumentată care a stricat o funcție

La două săptămâni de la rularea în paralel a noului modul de stoc, cifrele au derivat pentru o categorie de produs și nu vedeam de ce. După o zi de săpat, șefa de operațiuni a menționat, aproape în treacăt, că anumite articole în vrac erau numărate pe palet, nu pe bucată, iar sistemul vechi avea o conversie ascunsă încorporată pe care nimeni nu o documentase de un deceniu. Nu era în nicio specificație. Trăia doar în capul ei și în dosar. Nu am fi găsit-o niciodată doar din cod — ci doar rulând ambele sisteme alături și întrebând de ce nu se potrivesc. Acela e tot argumentul pentru rularea în paralel într-o singură anecdotă.

Cucerirea halei

Angajații depozitului supraviețuiseră mai multor „îmbunătățiri” bine intenționate care le înrăutățiseră ziua, așa că au întâmpinat proiectul cu o suspiciune rezonabilă. Nu am combătut-o cu o prezentare. L-am ales pe culegătorul care se plângea cel mai tare, am stat cu el o dimineață și am reconstruit ecranul de culegere în jurul felului în care parcurgea el de fapt hala. Odată ce a început să apere noul sistem la cafea, restul l-au urmat. În proiectele cu sisteme vechi, cel mai dur critic, odată câștigat, devine cel mai bun susținător al tău — și asta nu o cumperi cu o circulară.

Rezultatele, un an mai târziu

Suntem precauți cu cifrele lustruite de tip înainte-și-după, fiindcă fiecare afacere măsoară diferit, iar a voastră va varia. Așa că tratați-le ca pe niște cifre oneste, rotunjite, dintr-un singur proiect, menite să arate forma randamentului, nu o promisiune. Esența ține mai puțin de vreo metrică anume și mai mult de ce a încetat să mai fie înspăimântător.

Cifra de care proprietarului îi păsa cel mai mult nu era pe niciun grafic. Era că, atunci când șefa de operațiuni chiar s-a pensionat — cu câteva luni mai devreme decât planificat, după cum s-a dovedit — depozitul nici măcar nu a clătinat. Cunoștințele care trăiau cândva în capul ei trăiau acum într-un sistem pe care oricine putea fi instruit în câteva zile. Motivul inițial al întregului proiect fusese rezolvat în liniște, complet.

Dacă stați pe un sistem ca acesta

Majoritatea proprietarilor cu un sistem-nucleu îmbătrânit simt deodată aceleași două lucruri: e riscant să-l păstrezi și e înspăimântător să-l înlocuiești. Ambele sunt adevărate. Greșeala e să lași a doua teamă să învingă, fiindcă riscul sistemului vechi nu rămâne constant — crește în liniște în fiecare an, pe măsură ce oamenii care îl înțeleg se apropie de plecare, iar platforma pe care rulează se îndepărtează tot mai mult de suport.

Nu trebuie să alegeți între „lasă-l în pace și roagă-te” și „pariază firma pe o rescriere mare”. Calea de mijloc — înconjoară-l, înlocuiește-l bucată cu bucată, păstrează-l pe cel vechi ca plasă până când cel nou și-a câștigat încrederea — e mai lentă și mult mai puțin eroică. E și varianta care nu oprește camioanele. Dacă e un singur lucru de reținut din toată povestea asta, acela este.

Întrebări frecvente