La resilienza della supply chain richiede banda

Joannes Vermorel

Gli ultimi anni non sono stati gentili con le supply chain. Infatti, l’unica cosa che sembra non essere stata in breve scorta sono le forze di disruption: lockdown, guerre, inflazione, ecc. Di conseguenza, è emerso un rinnovato interesse per le supply chain ‘resilienti’. Naturalmente, i soliti sospetti - consulenti, professori e software vendors (incluso il sottoscritto) – sono stati occupati a trovare ‘soluzioni’ che, almeno, potessero mitigare l’impatto di quelle disruption, e che, nel migliore dei casi, eliminassero del tutto intere categorie di disruption. Tuttavia, le mie osservazioni casuali indicano che quelle ‘soluzioni’, per quanto possano apparire meritevoli, sono solitamente nient’altro che illusioni.

Infatti, nell’ultimo decennio ho osservato che la maggior parte dei direttori delle supply chain, insieme ai loro team, è già sepolta sotto micro-crisi, anche in periodi per lo più privi di qualsivoglia disruption su larga scala. Di conseguenza, la maggior parte delle divisioni delle supply chain non ha il lusso nemmeno di pensare alla gestione delle crisi (o a qualsivoglia piano strategico grandioso): sono interamente impegnati a spegnere un flusso ininterrotto di incendi.

Alcuni decenni fa, l’industria del software coniò un termine per riferirsi a questo stesso problema: la mancanza di banda, quando il management non riesce nemmeno a pensare ad un ulteriore problema perché la loro attenzione è già dispersa su troppe questioni. Ciò che rende il concetto di banda così rilevante sia per il software che per le supply chain è che, in entrambe le situazioni, la solita risposta aziendale a un eccessivo carico di lavoro – ossia, mettere più persone sul caso – non funziona. Questa è l’essenza della legge di Brooks: aggiungere ulteriore manodopera a un progetto software che è già in ritardo serve solo a ritardarlo ancora di più. Nell’industria del software, che vanta alcune delle aziende più redditizie mai esistite in mercati liberi, questo problema di banda è estremamente fastidioso. Mentre l’azienda potrebbe essere abbastanza redditizia da raddoppiare la forza lavoro e il suo management, ciò non farebbe alcuna differenza al problema ¹.

Forse sorprendentemente (o forse no), la causa principale di questo flusso infinito di micro-crisi nelle supply chain è quasi esclusivamente il software. Paradossalmente, non è la guerra in Ucraina o la possibilità di un altro conflitto in Asia a prosciugare la banda della divisione delle supply chain, ma tipicamente problemi che si qualificano al meglio come “completamente aneddotici”, come ad esempio il WMS che non è sincronizzato con l’ERP (…ancora); oppure fare pressioni sull’IT per ottenere un ulteriore campo personalizzato nel database per le scorte “riservate” ²; o inseguire previsioni del tutto irragionevoli fornite dal processo di S&OP.

In una galleria di software prosciuganti banda, i prodotti analitici sono, di gran lunga, i peggiori colpevoli. Questi strumenti – in particolare quelli per la pianificazione – richiedono spesso non solo una forza lavoro imponente per essere gestiti, ma generano anche delle proprie mini-burocrazie. Di conseguenza, il management delle supply chain deve risolvere sia i problemi legati al software, sia quelli di processo generati dalla stessa burocrazia. Questo processo diventa frustrantemente riflessivo e spreca sempre più banda.

Lokad, essendo parte di questo ecosistema di software analitico, non è immune a questo problema. Tuttavia, anni fa abbiamo sviluppato l’antidoto attraverso il quarto punto del nostro manifesto ³: Essere in controllo richiede l’automazione di ogni compito banale. Ci siamo resi conto che era necessario trovare un delicato equilibrio tra gestione e ottimizzazione. Ad esempio, se la generazione degli ordini giornalieri di acquisto/produzione consuma l’intero budget di banda della divisione delle supply chain, non rimane nulla da investire in miglioramenti (in termini di resilienza o altro).

Al contrario, se tutti i compiti banali vengono completamente automatizzati, ciò libera una quantità massiccia di banda all’interno dell’organizzazione delle supply chain. Tuttavia, questo processo richiede tempo. Non è un caso che, quando Lokad inizia a lavorare per un cliente, di solito ci voglia circa un anno prima di poterci concentrare direttamente su qualsiasi argomento che possa essere considerato strategico (come la resilienza). Lokad non solo deve entrare in produzione (ciò richiede circa 6 mesi), ma l’organizzazione deve anche imparare a rinunciare al controllo di tutti i processi che sono stati automatizzati (richiedendo altri 6 mesi, o di più nelle organizzazioni più grandi).

Automatizzando le decisioni banali, tuttavia, i team delle supply chain ritrovano qualcosa che avevano perso decenni fa, quando la loro organizzazione si è digitalizzata: la capacità di scegliere le proprie battaglie. Questo è probabilmente il beneficio più importante dell’automazione, superando di gran lunga i risparmi in produttività. Non sto dicendo che il passaggio a una supply chain digitale negli anni ‘80 e ‘90, operata tramite una collezione di ERP, MRP e APS, non sia stata la mossa giusta. In parole povere, sebbene questo percorso digitale sia stato necessario, ha comportato gravi svantaggi: le aziende (del libero mercato) non sono mai state così radicate nel proprio panorama applicativo, dove migrazioni e aggiornamenti si misurano tipicamente in anni. Molte supply chain sono state travolte dal “digital firefighting” per così tanto tempo che pochi dipendenti ricordano di aver iniziato la giornata lavorativa senza un flusso infinito di avvisi, eccezioni e problemi. E questo senza contare il corrispondente flusso infinito di riunioni per affrontare tali avvisi, eccezioni e problemi. Tutti questi processi comportano costi in termini di banda, e il carico mentale è sempre elevato.

A titolo di prova aneddotica, consideriamo che in meno di 5 anni (dal 1903 al 1908), Henry Ford passò dal nulla alla Model T. Ford rivoluzionò la produzione industriale, introducendo oltre una dozzina di modelli nel processo (Model A, Model B, Model C, ecc.), il tutto gestendo simultaneamente un’offerta e una domanda in costante mutamento. Anche a Ford non fu facile: il Panic del 1907 fu una delle crisi finanziarie più grandi e gravi di tutti i tempi. Al giorno d’oggi, dati 5 anni di “business as usual”, molte (forse la maggior parte?) aziende non riescono nemmeno a completare l’aggiornamento del loro ERP.

Pertanto, per diventare resilienti, una supply chain deve liberare banda. La resilienza è un argomento difficile ed elusivo, perciò è necessaria molta banda, il che rende il tutto ancora più impegnativo. Peggio ancora, la scarsità di banda disponibile nelle supply chain, come l’industria del software ha scoperto decenni fa, non può essere semplicemente risolta spendendo enormi somme di denaro ⁴. Piuttosto, la strada migliore per ottenere la resilienza è una via indiretta: automatizzare spietatamente le decisioni banali per guadagnare la libertà di pensare ed eseguire quelle strategiche, resilienza compresa.