Modernizzare un sistema di magazzino vecchio di 12 anni senza fermare i camion

Il software più pericoloso in una piccola impresa è il software che funziona. Non lo strumento difettoso di cui tutti si lamentano: quello prima o poi viene sostituito. Quello pericoloso è il sistema di dodici anni che nessuno ama ma da cui tutti dipendono, quello che si avvia da un tower beige in un angolo e gestisce il magazzino da prima che venisse assunta metà del personale. Funziona. Fino al giorno in cui quasi non funziona più, e tutti si rendono conto in un colpo solo che l'intera attività è in equilibrio sopra di esso.

Questa è la storia di uno di quei sistemi e di come lo abbiamo sostituito. Il cliente è un distributore regionale — qualche migliaio di referenze, un unico magazzino, una trentina di persone tra reparto e ufficio. Lo abbiamo reso anonimo e arrotondato i numeri, ma la forma del progetto è esattamente quella che è avvenuta. Se siete seduti su un sistema invecchiato che avete paura di toccare, ecco più o meno come appare dall'interno una modernizzazione assennata.

In questa storia non c'è nessuna riscrittura eroica, nessun weekend in cui abbiamo abbassato un interruttore e tutto era nuovo. Il punto fondamentale — ciò che l'ha fatta funzionare — è che non è successo nulla di drammatico. I camion hanno continuato a caricare. Il magazzino ha appena percepito il terreno spostarsi sotto di sé. Questo è l'obiettivo nel lavoro sul legacy, e vale la pena capire perché.

La situazione: un sistema tenuto insieme dalla memoria di una sola persona

Il magazzino girava su un sistema su misura costruito intorno al 2013 da uno sviluppatore che se n'era andato da tempo. Faceva il lavoro essenziale — tracciare le scorte, stampare le liste di prelievo, far uscire gli ordini — e in una giornata normale lo faceva bene. Il problema non era davvero il software. Il problema era tutto ciò che era cresciuto attorno al software per tenerlo utilizzabile.

Nel corso di un decennio, il team aveva costruito in silenzio un sistema ombra fatto di nastro adesivo: un foglio di calcolo per le conte di magazzino che il software sbagliava, un secondo foglio che riconciliava il primo con la realtà, un gruppo WhatsApp in cui il responsabile di magazzino segnalava gli articoli che il sistema non sapeva rappresentare, e un raccoglitore stampato di soluzioni di ripiego che i nuovi assunti dovevano imparare a memoria. Niente di tutto questo era documentato in un solo posto. Viveva nella testa della responsabile delle operazioni, una donna pacata sulla cinquantina, lì da quattordici anni, che era, di fatto, la documentazione.

Quando il titolare ci ha chiamati la prima volta, non è stato per un crash. È stato perché lei aveva annunciato di voler andare in pensione tra due anni, e lui aveva fatto i conti e capito che il giorno in cui se ne fosse andata, una porzione significativa di come il magazzino funzionava davvero sarebbe uscita dalla porta con lei. È un fattore scatenante della modernizzazione più comune di qualsiasi guasto tecnico: non il sistema che si rompe, ma la consapevolezza che le persone che lo rattoppano non ci saranno per sempre.

I sintomi che tutti avevano smesso di notare

Quando abbiamo passato i primi due giorni semplicemente a guardare il magazzino al lavoro, i costi del vecchio sistema erano ovunque — ma erano diventati così normali che nessuno li segnalava più come problemi. Ci si fidava dei dati di magazzino al punto da darli per sbagliati di un margine prevedibile, così ogni ordine grande riceveva un controllo fisico manuale «per sicurezza». Il personale nuovo impiegava settimane a diventare utile, perché gran parte del mestiere era sapere non scritto. E il sistema girava su un sistema operativo così vecchio da non poter più essere aggiornato, su una rete che il titolare sapeva in privato essere un incidente di sicurezza in attesa di accadere.

• L'accuratezza dell'inventario si aggirava intorno all'80 %, così il personale ricontava a mano qualsiasi cosa importante — ore al giorno, in silenzio.
• La logica della lista di prelievo non reggeva l'attuale layout del magazzino, così i preparatori seguivano il percorso indicato dal raccoglitore, non dallo schermo.
• La riconciliazione delle scorte di fine mese impegnava due persone per buona parte di tre giorni.
• Solo una macchina poteva eseguire la parte amministrativa del software, e se si fosse guastata, nessuno aveva un piano chiaro.
• Niente si collegava al canale di ordini online che l'azienda aveva aggiunto nel 2019 — quegli ordini venivano ridigitati a mano.

Ciò che deliberatamente non abbiamo fatto

La mossa ovvia — quella che molti fornitori avrebbero proposto — è acquistare una grande piattaforma di gestione del magazzino pronta all'uso, migrare tutto in un weekend e spegnere il vecchio sistema il lunedì mattina. Abbiamo visto questo approccio andare storto abbastanza volte da non proporlo a un'impresa come questa. Un passaggio in un colpo solo presuppone di comprendere il vecchio sistema per intero. Con un decennio di ripieghi non documentati, nessuno lo comprendeva — nemmeno chi lo faceva girare.

La seconda mossa allettante è una riscrittura completa su misura da zero: prendere tutto ciò che fa il vecchio sistema, ricostruirlo in modo pulito, rilasciare il nuovo. Sembra responsabile ed è un modo classico di bruciare un anno e un budget grande mentre l'impresa attende, congelata, un sostituto che continua a slittare. Il guaio è che una riscrittura deve riprodurre ogni stranezza prima di poter partire — comprese le stranezze che nessuno ricorda essere portanti finché non mancano.

Quindi non abbiamo fatto né l'una né l'altra cosa. Abbiamo trattato il vecchio sistema non come qualcosa da demolire, ma come qualcosa da circondare e sostituire lentamente — una capacità alla volta, con il vecchio sistema che continuava a girare sotto come rete di sicurezza per tutto il percorso. Senza gloria. E anche l'unica versione di questo che funziona in modo affidabile.

L'approccio: strangolare il vecchio sistema, non farlo saltare

Tra gli sviluppatori c'è un nome ben rodato per questo schema — l'approccio «strangler» (strangolatore), dal nome di un rampicante che cresce attorno a un albero finché non riesce a reggersi da solo e l'originale scompare in silenzio. Non si sostituisce il vecchio sistema in una sola mossa. Si costruiscono nuovi pezzi attorno a esso, si indirizza il lavoro reale verso di essi uno alla volta, e si lascia che il vecchio sistema si rimpicciolisca finché ciò che resta è abbastanza piccolo da spegnerlo senza che nessuno trattenga il fiato.

Per questo magazzino, ciò ha significato concordare in anticipo una sequenza: quale capacità staccare per prima, quale tenere per ultima e — fondamentale — una regola per cui a ogni fase, se il pezzo nuovo si comportava male, potevamo tornare subito al vecchio metodo quello stesso giorno. A nessun passo è stato permesso di essere un punto di non ritorno fino alla fine vera e propria. È quest'unica regola ad aver fatto dormire il titolare e ad aver fatto sì che il personale di magazzino si fidasse del progetto anziché opporvisi.

1. 1
   Mappare ciò che il sistema fa davvero

   Tre settimane affiancando il reparto e l'ufficio per documentare il flusso di lavoro reale — compreso ogni ripiego su foglio di calcolo e raccoglitore. Abbiamo messo per iscritto il sistema che esisteva, non quello descritto dalla specifica originale.
2. 2
   Pulire i dati prima di spostarli

   Abbiamo eseguito una conta fisica completa delle scorte e ripulito il database prodotti rispetto a essa. Migrare dati sporchi in un nuovo sistema dà solo più in fretta la risposta sbagliata — quindi questo è venuto prima che qualsiasi software nuovo toccasse i dati.
3. 3
   Sostituire prima il pezzo più doloroso

   Abbiamo costruito il nuovo modulo di tracciamento e conta delle scorte, l'abbiamo fatto girare in parallelo al vecchio e ci siamo fidati solo quando i numeri hanno corrisposto alla realtà per un mese intero.
4. 4
   Collegare i canali che il vecchio sistema ignorava

   Poi abbiamo cablato il canale di ordini online direttamente ai nuovi dati di magazzino, eliminando la ridigitazione manuale che esisteva in silenzio dal 2019.
5. 5
   Staccare il resto, poi mandare in pensione il vecchio nucleo

   Prelievo, reportistica e riconciliazione sono migrati uno alla volta. Quando quasi nulla di reale girava più sul vecchio sistema, lo abbiamo finalmente spento — ormai un non evento.

Le parti che sono state davvero difficili

Sarebbe disonesto presentare tutto questo come liscio. Il lavoro tecnico è stato la parte facile. Le parti difficili erano umane e procedurali, e sono le stesse parti difficili di quasi ogni progetto legacy.

La regola non documentata che ha rotto una funzione

Due settimane dopo l'avvio del nuovo modulo di magazzino in parallelo, i numeri sono andati alla deriva per una categoria di prodotto e non riuscivamo a capire perché. Dopo una giornata di scavo, la responsabile delle operazioni ha menzionato, quasi di sfuggita, che certi articoli sfusi venivano contati a pallet, non a unità, e che il vecchio sistema aveva una conversione nascosta incorporata che nessuno aveva documentato in un decennio. Non era in alcuna specifica. Viveva solo nella sua testa e nel raccoglitore. Non l'avremmo mai trovata dal solo codice — solo facendo girare entrambi i sistemi affiancati e chiedendoci perché non concordassero. Questo è l'intero argomento a favore dell'esecuzione in parallelo, in un aneddoto.

Conquistare il reparto

Il personale di magazzino era sopravvissuto a più di un «miglioramento» ben intenzionato che gli aveva peggiorato la giornata, perciò ha accolto il progetto con un ragionevole sospetto. Non l'abbiamo combattuto con una presentazione. Abbiamo scelto il preparatore che si lamentava più forte, ci siamo seduti con lui per una mattinata e abbiamo ricostruito la schermata di prelievo attorno a come percorreva davvero il reparto. Appena ha iniziato a difendere il nuovo sistema in sala pausa, il resto è seguito. Nei progetti legacy il critico più duro, una volta conquistato, diventa il vostro migliore sostenitore — e questo non lo si compra con una circolare.

I risultati, un anno dopo

Diffidiamo dei numeri prima-dopo patinati, perché ogni impresa misura in modo diverso e i vostri varieranno. Considerateli quindi cifre oneste e arrotondate di un progetto, pensate per mostrare la forma del ritorno più che una promessa. Il titolo riguarda meno una singola metrica e più ciò che ha smesso di fare paura.

Il numero a cui il titolare teneva di più non era su alcun grafico. Era che, quando la responsabile delle operazioni è andata davvero in pensione — qualche mese prima del previsto, come si è scoperto —, il magazzino non ha nemmeno vacillato. Il sapere che un tempo viveva nella sua testa ora viveva in un sistema su cui chiunque poteva essere formato in pochi giorni. La ragione originaria dell'intero progetto era risolta, in silenzio e per intero.

Se siete seduti su un sistema come questo

La maggior parte dei titolari con un sistema centrale invecchiato prova due cose contemporaneamente: è rischioso tenerlo ed è terrificante sostituirlo. Entrambe sono vere. L'errore è lasciar vincere la seconda paura, perché il rischio del vecchio sistema non resta costante — cresce in silenzio ogni anno, man mano che le persone che lo capiscono si avvicinano all'uscita e la piattaforma su cui gira si allontana sempre più dal supporto.

Non dovete scegliere tra «lasciarlo stare e pregare» e «scommettere l'azienda su una grande riscrittura». La via di mezzo — circondarlo, sostituirlo un pezzo alla volta, tenere il vecchio come rete finché il nuovo non si è guadagnato la fiducia — è più lenta e molto meno eroica. È anche la versione che non ferma i camion. Se c'è una cosa da portare via da tutta questa storia, è questa.

Domande frequenti