Simpatia Meccanica: L'ingrediente mancante nel software supply chain

Joannes Vermorel

Quando ho iniziato a lavorare su problemi di supply chain quasi vent’anni fa, mi aspettavo che la parte difficile fosse la fisica: camion, navi, pallet, container, linee di produzione. Invece, mi sono trovato a lottare con schermi che impiegavano diversi secondi per aggiornarsi, lotti notturni che regolarmente si protraevano fino alla mattina seguente, e motori di “ottimizzazione” che dovevano essere semplificati fino a risultare a malapena migliori di un foglio di calcolo.

Il vero collo di bottiglia non era l’acciaio o il cemento. Era il software. Più precisamente, era la nostra indifferenza collettiva verso la macchina che esegue quel software.

Nel mio libro Introduzione to Supply Chain, sostengo che le moderne supply chains sono, prima di tutto, motori decisionali in condizioni di incertezza. La qualità di tali decisioni dipende dalla qualità del software che le prepara, e quel software, a sua volta, è vincolato dall’hardware informatico sottostante, dalle cache della CPU alla larghezza di banda della memoria.

Negli ultimi dieci anni, sono giunto a credere che la pratica della supply chain non possa progredire molto ulteriormente se non sviluppiamo quella che chiamo simpatia meccanica: una sensibilità istintiva per come effettivamente si comporta il calcolo, e una volontà di progettare i nostri metodi attorno a quella realtà invece di ignorarla.

Cosa intendo per “Simpatia Meccanica”

L’espressione proviene originariamente dal mondo delle corse automobilistiche. Un buon pilota non è solo abile nel seguire la traiettoria ideale; egli “sente” anche ciò che l’auto può o non può fare. Evita manovre brusche che surriscaldano i freni, ascolta il motore e percepisce quando le gomme stanno per cedere. Si identifica con la macchina.

Nel campo dell’informatica, l’equivalente consiste nel comprendere che un server moderno non è una calcolatrice magica e senza attrito che esegue “operazioni al secondo” in astratto. È un oggetto fisico con peculiarità: piccole cache che sono veloci ma limitate, memoria principale che è più lenta, dischi ancora più lenti e reti con una latenza che non si può semplicemente ignorare. La differenza tra rispettare questi vincoli e ignorarli di routine si traduce in incrementi di una o due ordini di grandezza in termini di prestazioni.

Abbiamo un esempio sorprendente nella storia del deep learning. La letteratura iniziale sulle reti neurali era ossessionata dall’ispirazione biologica: neuroni, sinapsi, regole di apprendimento che sembravano appartenere alle neuroscienze. La svolta avvenne quando i ricercatori abbandonarono ogni pretesa di imitare il cervello e optarono invece per un’ottimizzazione spietata per le GPU e la stabilità numerica. Unità lineari rettificate, mini-batch, layer densi, aritmetica a precisione mista: molte di queste idee riguardano meno le neuroscienze e più l’adattamento all’hardware. Il campo decollò nel momento in cui mostrò simpatia meccanica per il silicio.

La supply chain non è, ovviamente, il riconoscimento delle immagini. Ma è altrettanto computazionale, e ha tanto da guadagnare dal rispettare la macchina.

Supply Chain come Problema Computazionale

Le supply chains sono spesso descritte in termini di flussi fisici: fabbriche, magazzini, camion e negozi. Ciò che non è subito evidente, però, è che dietro ogni pallet in movimento ci sono dozzine di piccole decisioni: cosa acquistare, cosa produrre, quanta merce spedire, dove immagazzinare, a quale prezzo vendere, quando applicare sconti e quale ordine dare priorità.

Ognuna di queste decisioni viene presa in condizioni di incertezza. La domanda può aumentare vertiginosamente o crollare. I tempi di consegna possono allungarsi. I fornitori possono fallire. La capacità di trasporto può evaporare da un giorno all’altro. Se vogliamo prendere queste decisioni in modo sistematicamente migliore rispetto all’istinto umano, abbiamo bisogno di algoritmi che considerino molti scenari, non solo una singola previsione; che confrontino le opzioni in termini di profitto atteso, non solo di livello di servizio; che propagano i vincoli attraverso l’intera rete invece di trattare ogni magazzino o negozio isolatamente.

Tutto ciò è computazionalmente costoso. Un approccio probabilistico che tiene traccia di migliaia di futuri plausibili e valuta le decisioni rispetto a ciascuno di essi eseguirà molte più operazioni aritmetiche rispetto a una formula semplificata di scorta di sicurezza. Una visione a livello di rete che integra l’inventario, i prezzi e la pianificazione della capacità farà passare molti più dati attraverso la macchina rispetto a un calcolo locale del punto di riordino.

Qui è dove la simpatia meccanica diventa decisiva. Se lo stack sottostante di software e hardware è approssimativo, se ogni query scatena dozzine di richieste di andata e ritorno a un database transazionale, se gli algoritmi sono scritti in modi che annullano l’efficacia della cache e del parallelismo, allora questi metodi più sofisticati semplicemente non rientrano nella finestra temporale disponibile. Finisci per ridurre il problema finché non si adatta alla macchina, invece di migliorarla affinché affronti il vero problema.

Quando vedo un’azienda la cui “ottimizzazione” del rifornimento deve iniziare alle 18 per finire alle 6, so che l’organizzazione non sperimenterà mai alternative in modo serio. Ogni nuova idea diventa un progetto di diverse settimane, perché solo un singolo ciclo richiede mezza giornata. L’economia della sperimentazione collassa.

La visione dominante: l’hardware come ripensiero

Se dai un’occhiata ai manuali di supply chain mainstream, troverai ampie discussioni su design di rete, strategie di sourcing, contratti, politiche di inventario, modalità di trasporto e metriche di performance. Troverai anche capitoli su “information technology” che descrivono sistemi ERP, strumenti di pianificazione e integrazione. Quello che quasi non troverai mai è una discussione seria su come il sistema informatico sottostante si comporti.

L’IT viene trattata come un abilitatore neutro. Il messaggio, grosso modo, è che una volta scelto il tuo software e integrati i tuoi dati, puoi concentrarti sulla progettazione dei processi e sulle leve manageriali. La vita interna della macchina – come è organizzata la memoria, come vengono memorizzati i dati, come viene schedulata l’elaborazione – spetta ai fornitori e ai tecnici.

La stessa mentalità pervade la maggior parte del software aziendale nel nostro settore. I sistemi di pianificazione sono costruiti sopra database transazionali che erano stati originariamente progettati per prenotare ordini e aggiornare i livelli di stock, e non per elaborare miliardi di scenari probabilistici durante la notte. L’architettura è solitamente organizzata intorno a schermi e moduli che creano, leggono, aggiornano e cancellano record. Moduli aggiuntivi di “ottimizzazione” vengono poi agganciati: un motore di previsione qui, un risolutore di routing là, un euristico per l’inventario da qualche altra parte.

Dall’esterno, questo apparirebbe abbastanza moderno: interfacce web, deployment in cloud, API, forse anche “AI” nel depliant di marketing. Sotto il cofano, tuttavia, il nucleo computazionale è spesso affamato. I calcoli vengono inviati attraverso strati di astrazione che frammentano i dati, disperdono il lavoro e annullano i punti di forza dell’hardware. Il risultato è un software che fatica a tenere il passo con i volumi di dati odierni, nonostante giri su macchine migliaia di volte più veloci di quelle di trent’anni fa.

Niklaus Wirth ha scherzato famosamente che il software sta rallentando più rapidamente di quanto l’hardware stia accelerando. Nella supply chain, questo è evidente: in molti grandi sistemi ci vogliono ancora diversi secondi per aprire la pagina dei “dettagli” per una singola combinazione prodotto-luogo, anche se l’hardware sottostante dovrebbe essere in grado di scansionare milioni di tali record nello stesso lasso di tempo. Siamo riusciti a consumare quasi tutto il progresso dell’hardware in strati di inefficienza.

Una volta che l’inefficienza è radicata nell’architettura, le conseguenze non sono solo tecniche; diventano dottrinali. Se la tua piattaforma non può permettersi di tenere traccia di migliaia di scenari per ogni SKU, allora favorirai metodologie che richiedono solo una singola previsione. Se il tuo motore non è in grado di valutare l’impatto finanziario delle decisioni a livello di rete, tenderai verso regole locali e indicatori chiave di prestazione che possono essere calcolati in isolamento. Le limitazioni “teoriche” diventano rapidamente dogmi “pratici”.

Ciò che cambia quando ti importa della macchina

Cosa succede se invertiamo la storia? Supponiamo di partire dall’assunto che la macchina conti.

Innanzitutto, cominciamo a progettare flussi di dati che rispettino la località. Invece di disperdere le informazioni in decine di tabelle e chiedere al database di riassemblarle per ogni calcolo, organizziamo i dati in modo che una singola lettura della memoria fornisca tutto ciò di cui un algoritmo ha bisogno. Ciò da solo può migliorare le prestazioni di un intero ordine di grandezza.

In secondo luogo, favoriamo operazioni batch e vettorializzate rispetto a un’elaborazione verbosa riga per riga. L’hardware è straordinariamente bravo a eseguire la stessa operazione ripetutamente su grandi array. È pessimo nel rispondere a migliaia di piccole domande non correlate che richiedono di saltare nella memoria e attraverso la rete. Quando la parte analitica di un sistema di supply chain è espressa come un programma coerente anziché come uno sciame di transazioni basate su moduli, diventa molto più facile sfruttare questa potenza.

In terzo luogo, consideriamo l’intera pipeline decisionale, dai dati grezzi alle quantità che compaiono negli ordini di acquisto e nelle liste di prelievo, come qualcosa che può e deve essere profilato, ottimizzato e rielaborato nel tempo. Smettiamo di trattare “il modello” come una scatola nera e iniziamo a considerare la ricetta come software. Questo è esattamente ciò che ha permesso a settori come la computer grafica e l’informatica scientifica di evolversi da lenti prototipi a strumenti industriali: gli ingegneri hanno impiegato anni per eliminare le inefficienze a ogni livello.

Il beneficio diretto è la velocità. Un calcolo che una volta richiedeva sei ore potrebbe ora richiederne sei minuti o sei secondi. Ma il beneficio più profondo non è il numero puro; è ciò che la velocità permette di realizzare. Se il tuo team può eseguire cento varianti di una politica di rifornimento in un giorno anziché una variante a settimana, esplorerà idee che prima erano impensabili. Affineranno i modelli in risposta alle interruzioni, testeranno ipotesi alternative e spingeranno gradualmente il confine di ciò che è economicamente realizzabile.

Questo non è vanità da geek, è economia

Alcuni lettori potrebbero temere che tutto ciò suoni come l’ossessione di un ingegnere per l’eleganza fine a se stessa. A chi importa quante cache miss produce un algoritmo, finché gli scaffali sono riforniti e i camion partono puntuali?

La risposta è che l’inefficienza non è gratis. Nell’era del cloud, ne paghi il doppio.

Paghi direttamente, sotto forma di infrastrutture sovradimensionate. Se il tuo software richiede dieci volte più capacità di calcolo e storage del necessario per produrre le stesse decisioni, pagherai dieci volte di più al tuo cloud provider o per il tuo hardware – oppure accetterai tempi di esecuzione dieci volte più lunghi, che è semplicemente un’altra forma di costo.

Paghi anche indirettamente, sotto forma di una logica decisionale più debole. Poiché i sistemi inefficienti faticano a elaborare politiche sofisticate su larga scala, i fornitori semplificano la matematica per adattarla alla macchina. Riducono le distribuzioni di probabilità a numeri singoli. Scollegano processi che in realtà sono strettamente legati, in modo da poter essere calcolati in passate separate. Nascondono approssimazioni grezze dietro dashboard lucenti. Potresti non notare mai le scorciatoie, ma le sentirai sotto forma di scorte di sicurezza eccessive, vendite mancate e reazioni fragili agli shock.

La simpatia meccanica, al contrario, ti permette di investire il tuo budget computazionale dove conta di più: nell’esplorare l’incertezza e i compromessi. Un sistema efficiente può permettersi di simulare migliaia di futuri e scegliere decisioni che massimizzano il profitto atteso controllando il rischio, invece di affidarsi a regole empiriche. Può permettersi di ricalcolare frequentemente, in modo che le decisioni rimangano aggiornate di fronte a nuovi dati. Può permettersi di mantenere una visione dell’intera rete invece di ottimizzare in modo miope ogni nodo isolato.

In questo senso, la simpatia meccanica non è una preferenza tecnica; è una posizione economica. Dice: non sprecheremo risorse computazionali scarse in overhead gratuiti; le spenderemo per i calcoli che effettivamente cambiano i nostri flussi di cassa.

Cosa mi aspetto dai leader della supply chain

Nulla di tutto ciò significa che ogni dirigente della supply chain debba diventare un programmatore di sistemi. Ma credo che i team di leadership abbiano bisogno di un senso di scala e direzione di base. Non è necessario progettare motori per sapere che un camion che consuma tre volte più carburante rispetto ai suoi pari per lo stesso percorso rappresenta un problema. Non serve essere un progettista di chip per riconoscere che un sistema che impiega ore per eseguire un calcolo che potrebbe ragionevolmente essere fatto in secondi è un problema.

Quando selezioni un software o un fornitore, dovresti sentirti a tuo agio nel fare domande come:

Con quale frequenza possiamo realisticamente ricalcolare tutte le decisioni chiave per l’intera rete?

Cosa succede se raddoppiamo il numero di SKU o di sedi – i tempi di esecuzione raddoppiano o esplodono?

Quanto hardware richiede questa piattaforma per elaborare i nostri dati, e quanto siamo sicuri che tali requisiti non aumenteranno in modo smisurato in due anni?

Se le risposte sono evasive, o se nessuno in sala riesce nemmeno a stimare ordini di grandezza, c’è qualcosa che non va. Nella conversazione su LokadTV riguardante le risorse computazionali, ho paragonato questo alla geografia di base: non è necessario conoscere l’altitudine esatta di ogni montagna, ma dovresti sapere se una determinata strada attraversa le Alpi o una pianura.

Allo stesso modo, i team interni dovrebbero essere incoraggiati a vedere il loro lavoro analitico come codice che può essere profilato e migliorato, e non come “modelli” statici che sono o corretti o errati. La capacità di ragionare sulle prestazioni fa parte della competenza professionale, proprio come la capacità di ragionare sull’economia unitaria fa parte della finanza.

Un Tipo Diverso di Simpatia

La simpatia meccanica è, in definitiva, una forma di rispetto.

È rispetto per la macchina: riconoscere che i nostri server non sono infiniti, che le loro stranezze e limitazioni sono reali, e che ignorarle significa mettere in pericolo noi stessi.

È rispetto per le persone che dipendono da quelle macchine: planner che necessitano di raccomandazioni tempestive e affidabili; manager che hanno bisogno di spazio per sperimentare; dirigenti che devono impegnare capitali basandosi su ciò che il software comunica loro.

Ed è rispetto per la disciplina della supply chain stessa. Se affermiamo che il nostro settore si occupa di prendere decisioni migliori in condizioni di incertezza, allora non possiamo ignorare la qualità dei macchinari che producono tali decisioni. Ce lo dobbiamo a noi stessi – e alle aziende che si fidano di noi – trattare le risorse computazionali con la stessa serietà con cui trattiamo magazzini e flotte.

La visione dominante è stata quella di trattare gli interni hardware e software come una preoccupazione dietro le quinte, qualcosa di cui “IT” si occuperà. Credo che tale visione abbia raggiunto la fine della sua utilità. Più le nostre supply chains dipendono da algoritmi e dati, più è necessario mettere la macchina in primo piano.

“Mechanical sympathy” non significa trasformare ogni planner in un programmatore. Significa coltivare, a ogni livello, una curiosità informata su come funzionano veramente i nostri strumenti – e un rifiuto di accettare lentezza, opacità e sprechi come inevitabili.