Una recensione di "How Generative AI Improves Supply Chain Management"

Joannes Vermorel

Harvard Business Review, come parte della loro edizione gennaio-febbraio 2025, ha recentemente pubblicato How Generative AI Improves Supply Chain Management¹ di Ishai Menache (Microsoft), Jeevan Pathuri (Microsoft), David Simchi-Levi (Professor, MIT) e Tom Linton (McKinsey). Come suggerisce il titolo, l’articolo fornisce una serie di esempi che presumibilmente illustrano come gli LLM (large language models) possano contribuire al supply chain management. Considerando la lista di organizzazioni d’élite (Microsoft, McKinsey, MIT, e persino Harvard) coinvolte nella pubblicazione di questo pezzo, ci si aspetterebbe alcuni approfondimenti significativi — del tipo che articolino con cura come una brillante tecnologia —gli LLM— contribuirà al miglioramento delle supply chains.

Invece, otteniamo un contributo mediocre. Più precisamente: è pigro, iperbolico e profondamente fuorviante — un pezzo che si aggancia casualmente a una parola d’ordine tecnologica. L’intero presupposto dell’articolo può essere riassunto come LLMs can both generate and explain code of supply chain relevance. Gli autori adottano quello che solitamente definisco un approccio gadgetoid. L’approccio gadgetoid consiste, quando si scopre un nuovo pezzo di tecnologia, nell’aggiungerlo frettolosamente a un sistema esistente. Questo viene tipicamente fatto senza alcuna considerazione delle limitazioni del pezzo o dei cambiamenti che verrebbero apportati al sistema. Di conseguenza, questo approccio produce invariabilmente gadget — strumenti divertenti di scarso interesse — e assolutamente nessun valore commerciale.

Alle varie organizzazioni coinvolte:

• Microsoft: avete molti ingegneri talentuosi a bordo. Dovete imporvi standard più elevati.

• McKinsey: non indirizzate i potenziali clienti verso direzioni che sono una garanzia di perdita di tempo e denaro.

• MIT e Harvard: dovreste essere voci della ragione e non amplificare le sciocchezze dei fornitori di tecnologia.

Chiarisco subito che, pur essendo d’accordo sul fatto che gli LLM possano essere usati per il miglioramento delle supply chains, gli LLM possono anche essere una completa distrazione — a seconda di come si affronta l’impresa. Questo punto è esattamente il problema fondamentale che affligge l’articolo in esame. Un articolo strettamente correlato di Microsoft² soffre anch’esso di questo problema; per lo meno, la mia recensione resterà concentrata sull’articolo di Harvard.

Prima di affrontare il nocciolo della sciocchezza tecnologica, evidenziamo una questione etica notevole. Questo articolo non è altro che un velato pezzo pubblicitario per Microsoft Cloud Supply Chain. Microsoft è naturalmente libera di pubblicizzare i propri servizi come meglio crede, ma coinvolgere sia Harvard (attraverso la pubblicazione) che il MIT (attraverso la co-autorialità) in un pezzo promozionale mi suscita non poche riserve. Per lo meno, l’articolo dovrebbe indicare che i coautori hanno evidenti conflitti di interesse. Il mondo accademico non dovrebbe tollerare attività promozionali occulte da parte dei fornitori di tecnologia, per quanto grandi e influenti possano essere.

Disclaimer: Il lettore attento si sarà reso conto che anch’io ho un conflitto di interesse. Sì, gestisco una software company per la supply chain e, dunque, ho un interesse personale nel contraddire le sciocchezze diffuse da Microsoft, McKinsey, MIT e Harvard. Ora ho messo tutte le carte sul tavolo.

Procediamo ora con una recensione delle affermazioni fatte nell’articolo.

I pianificatori monitorano anche i cambiamenti nel piano della domanda, denominato demand drift, su base mensile per garantire che il piano rivisto soddisfi tutti i requisiti del cliente e rientri nelle linee guida di budget […] La tecnologia basata su LLM ora fa tutto questo. Genera automaticamente un report via email che dettaglia chi ha effettuato ogni modifica e il motivo di tali modifiche.

In breve, gli LLM possono automatizzare i dipendenti nell’esecuzione di compiti ripetitivi. Tuttavia, esistono due ovvie obiezioni. Innanzitutto, gli LLM sono completamente superflui per eseguire questo tipo di politica basata sui ruoli. Un semplice linguaggio di programmazione e alcune istruzioni imperative saranno sufficienti. Inoltre, sarà comunque necessario del lavoro di integrazione programmatica per accedere ai dati e inviare l’email. In tali contesti, gli LLM rappresentano una complicazione ingegneristica massiccia che non offre benefici tangibili. Infatti, gli LLM sono molto lenti e molto costosi; circa 10 ordini di grandezza peggiori di una breve lista di regole. Sono uno strumento da usare come ultima risorsa, quando tutto il resto ha fallito. Ovviamente, questo non è il caso qui.

Secondo, i compiti ripetitivi sopra menzionati sono del tutto superflui. L’azienda dovrebbe eliminare questa categoria di mansioni inutili³. Le burocrazie sono già di per sé problematiche, ma le tecnocrazie sono peggiori. Introdurre pezzi di tecnologia eccessivamente complicati nella gestione garantisce che la burocrazia si consolidi ulteriormente nelle sue modalità disfunzionali. Lokad, la mia azienda, ha eliminato questo tipo di compiti ripetitivi da oltre un decennio e non richiede nulla di altrettanto complicato e costoso come gli LLM.

Questi contratti specificano i dettagli del prezzo pagato dall’OEM, i requisiti di qualità, i lead time, e le misure di resilienza che i fornitori devono adottare per garantire la supply. Dopo aver alimentato l’LLM con dati provenienti da migliaia di contratti, un OEM è stato in grado di identificare riduzioni di prezzo a cui aveva diritto per aver superato una certa soglia di volume.

Se è vero che le aziende falliscono di routine nell’applicare alcune delle clausole contrattuali con i loro fornitori che potrebbero avvantaggiarle, identificare i termini contrattuali rilevanti è solo una porzione microscopica della sfida — diciamo, l'1% o forse molto meno. Inoltre, può essere affrontato con uno strumento come ChatGPT senza alcuna preparazione. Basta comporre una query e inviare ripetutamente tutti i PDF tramite l’interfaccia utente. Questo genere di banalità appartiene a un post su LinkedIn intitolato “The 10 things I did with ChatGPT today” e non a una pubblicazione Harvard-MIT.

Ora, la vera sfida è duplice: l’instrumentation e la relazione. Dal lato dell’instrumentation, le fasi burocratiche per emettere ordini e pagamenti sono in gran parte automatizzate nella maggior parte delle aziende che operano qualcosa che si qualifica come una “supply chain”. Pertanto, a meno che non vi sia un’ampia strumentazione di supporto, gestire casi limite complessi complicherà e ritarderà tutto.

Inoltre, dal lato della relazione, se una clausola contrattuale è stata ignorata per anni, allora è ingenuo pensare che l’azienda possa attivarla senza alcuna conseguenza. Spesso il fornitore aveva già integrato questo comportamento lasciato dal cliente nei suoi prezzi, e critiche minuziose su clausole contrattuali marginali saranno replicate — o possibilmente tradotte in un aumento dei prezzi.

In generale, sconti e riduzioni di prezzo dovrebbero essere gestiti come parte dei sistemi transazionali aziendali regolari. Questo non è ingegneria missilistica, ma semplice CRUD⁴. Ancora una volta, introdurre un LLM dove alcune regole imperative sarebbero sufficienti è tecnologicamente insensato.

Un LLM consente ai pianificatori di porre domande dettagliate. Ecco alcuni esempi: “Quale sarebbe il costo aggiuntivo di trasporto se la domanda complessiva del prodotto aumentasse del 15%?” […] Ecco come un LLM può rispondere a domande di questo tipo in modo accurato ed efficiente. Molti compiti di ottimizzazione sono scritti sotto forma di programmi matematici […] Un LLM […] traduce una query umana in un codice matematico che rappresenta una piccola modifica al modello matematico originale usato per produrre il piano.

Questo è un pensiero illusorio. Ad oggi, la percentuale di aziende che dispone di una “unified monolithic codebase” per derivare le loro supply chain decisions è praticamente nulla (di cui ne parleremo più avanti). Invece, le aziende hanno un oceano di fogli di calcolo. A differenza della bella immagine che gli autori dipingono, non esistono “programmi matematici” con cui interagire per gli LLM. Mentre in linea di principio gli LLM potrebbero modificare e migliorare un disordinato insieme di fogli di calcolo per metà obsoleti, fino a prova contraria, questa rimane pura speculazione. Anche gli LLM all’avanguardia farebbero fatica a modificare un singolo grande foglio di calcolo — la duplicazione passiva del codice che i fogli di calcolo comportano non è assolutamente favorevole agli LLM — ma dare un senso a centinaia, se non migliaia, di fogli rimane pura fantascienza in questo momento.

Ora, in effetti ci sono alcune aziende che beneficiano di una unified monolithic codebase per gestire i processi decisionali della supply chain — vale a dire i client di Lokad. Se gli autori avessero, come noi, una reale esperienza in materia, avrebbero saputo che quelle codebase sono consistenti; tipicamente contengono decine di migliaia di righe di codice, nonostante il fatto che noi utilizziamo un DSL (domain-specific language)⁵ dedicato alla supply chain. Questo DSL è, tra l’altro, circa 10 volte più conciso di Python o Java per questo tipo di compito. Purtroppo non esiste una scorciatoia: per ogni decisione di interesse, ci sono dozzine di tabelle, che coprono centinaia di campi, coinvolte nel calcolo. Sebbene sia concepibile che ulteriori miglioramenti al nostro DSL possano ridurre ulteriormente il numero di righe di codice, quelle codebase non saranno mai piccole.

Di nuovo, in linea di principio, gli LLM potrebbero modificare e migliorare una codebase complessa sotto la direzione di un collaboratore non tecnico. Tuttavia, ci troviamo ancora in un territorio da fantascienza. È già stato dimostrato che gli LLM sono strumenti fantastici per aumentare la produttività dei programmatori capaci. In altre parole, se già sai programmare, gli LLM possono aiutarti a programmare più velocemente. Eppure, non è questo ciò che dicono gli autori dell’articolo. La loro proposta è proprio che gli LLM possano essere usati per permettere a collaboratori non tecnici di dare contributi tecnici. In base allo stato dell’arte attuale degli LLM, questa proposta è invariabilmente falsa, eccetto all’interno di piccoli sandbox che non riflettono la massiccia complessità ambientale delle supply chain reali.

I pianificatori possono usare la tecnologia LLM per aggiornare i modelli matematici della struttura di una supply chain e i requisiti aziendali per riflettere l’ambiente attuale di business. Inoltre, un LLM può aggiornare i pianificatori in caso di un cambiamento delle condizioni di business.

Gli autori stanno insistendo sulla fantascienza. Questa affermazione è tecnicamente indistinguibile da “un LLM può emettere patch a un repository di codice su GitHub in base a ticket inviati da utenti non tecnici”. Sarebbe una notizia fantastica se ciò fosse possibile, ma ancora una volta, gli LLM attuali sono ben lontani dall’essere in grado di compiere in modo affidabile questo tipo di impresa per richieste serie. Quando si presentano casi d’uso per una tecnologia innovativa, è fondamentale comunicare accuratamente i limiti di detta tecnologia. I quattro coautori sembrano essere completamente ignari dello stato dell’arte attuale degli LLM; detto ciò, ho il sospetto che non lo siano. Invece, assistiamo a un banale discorso promozionale da parte di persone ben consapevoli di ciò che stanno facendo — il che è, in effetti, di gran lunga peggio.

La necessità di modificare il piano della supply potrebbe essere guidata anche dalla tecnologia basata su LLM. Ad esempio, dopo aver analizzato i dati di spedizione di un fornitore specifico, potrebbe generare un allarme sul fatto che il lead time del fornitore è aumentato significativamente negli ultimi mesi.

Rilevare se un lead time è anomalo non è assolutamente ciò che un LLM può fare. Tuttavia, un LLM può essere incentivato a scrivere un pezzo di codice per effettuare questa analisi. Siamo tornati al post su LinkedIn “Top 10 things I did with ChatGPT today”. Perché fermarsi qui e non aggiornare direttamente la logica di ordinazione dove l’informazione sul lead time viene utilizzata? Questo è esattamente ciò che gli autori suggeriscono più avanti nell’articolo.

Prevediamo che nei prossimi anni la tecnologia basata su LLM supporterà scenari decisionali end-to-end.

Se con supportare gli autori intendevano rendere i programmatori più produttivi — con i programmatori incaricati di codificare il processo decisionale end-to-end — allora ciò è già possibile — infatti, è qualcosa che Lokad fa da tempo. Tuttavia, se eliminiamo i programmatori umani dall’equazione, questa affermazione si avvicina a “prevediamo che nei prossimi anni le tecnologie basate su LLM raggiungeranno l’AGI (artificial general intelligence)”.

Gli autori, cavalcando l’onda della buzzword “Gen AI”, sono completamente scettici sul fatto che gli LLM possano avere in qualche modo delle proprie limitazioni. Ecco cosa propongono gli autori nella sezione conclusiva “Overcoming Barriers”:

Adozione e formazione. Utilizzare un LLM per ottimizzare le supply chain richiede un linguaggio molto preciso […] Ogni interpretazione porta a decisioni differenti.

No, questo è completamente sbagliato—a meno che “linguaggio molto preciso” non venga inteso come “linguaggio di programmazione” (dato che questi sono effettivamente molto precisi). Per ottimizzare una supply chain utilizzando un LLM, è necessario un ingegnere umano capace di scrivere il codice interamente da solo, seppure più lentamente. Per il prevedibile futuro, nessuna quantità di formazione, se non quella che porta a diventare esperti di programmazione, renderà gli utenti in grado di eseguire ottimizzazioni della supply chain con il supporto degli LLM.

Dire al CEO o al direttore della supply chain che deve semplicemente formare il suo team per usare un “linguaggio preciso” è del tutto fuorviante. I workshop formativi che ne deriverebbero sarebbero garantiti una completa perdita di tempo per tutte le parti coinvolte.

Verifica. La tecnologia LLM può occasionalmente produrre un output errato. Pertanto, una sfida generale è mantenere la tecnologia “nei binari” — ovvero, identificare gli errori e riprendersi.

Pur essendo gli LLM probabilistici per natura, questo problema è oscurato dall’incertezza semantica uncertainty che pervade i sistemi di supply chain. In altre parole, è molto probabile che l’LLM ti dia la risposta corretta al problema sbagliato. L’esperienza di Lokad indica che spesso l’unico modo per verificare se una data implementazione (che guida una decisione sulla supply chain) sia corretta è eseguire un test sperimentale limitato⁶. Il feedback reale non è un’opzione. La conoscenza non può essere improvvisata dal nulla — anche gli LLM a livello AGI si confronterebbero comunque con questo ostacolo.

Qui, gli autori si limitano a compilare. Fanno un’affermazione corretta — ma banale — sulla natura degli LLM senza nemmeno tentare di verificare se il problema sia centrale o meno. Se gli autori avessero effettivamente gestito supply chain reali utilizzando gli LLM, si sarebbero resi conto, come noi, che questa preoccupazione è un problema minimo rispetto a una lunga lista di problemi molto più grandi — e molto più impattanti.

Per concludere, la legge di Brandolini si applica qui: La quantità di energia necessaria a confutare le stronzate è di un ordine di grandezza superiore a quella richiesta per produrle. Questo articolo è così pessimo che potrebbe essere stato scritto da ChatGPT—e magari lo è stato, per quel che ne so. In base alle mie osservazioni casuali, ogni giorno vengono prodotti decine di articoli altrettanto scadenti su Gen-AI e supply chain. La notorietà degli autori mi ha motivato a mettere insieme questa recensione. Riflettendoci, non sarebbe la prima volta che un fornitore promette di rivoluzionare un dominio pur non avendo nulla di sostanziale da offrire. Tuttavia, lo stesso fornitore che lo fa due volte⁷ per due anni consecutivi all’interno dello stesso dominio potrebbe essere eccessivo. D’altro canto, l’accademia dovrebbe almeno cercare di esercitare un pensiero critico invece di saltare felice a bordo del carro delle buzzword.