Una recensione di "Come l'IA generativa migliora la gestione della supply chain"

Joannes Vermorel

L’Harvard Business Review, come parte del loro numero di gennaio-febbraio 2025, ha recentemente pubblicato Come l’IA generativa migliora la gestione della supply chain¹ di Ishai Menache (Microsoft), Jeevan Pathuri (Microsoft), David Simchi-Levi (Professore, MIT) e Tom Linton (McKinsey). Come suggerisce il titolo, l’articolo fornisce una serie di esempi che dovrebbero illustrare come i LLM (large language models) possano contribuire alla gestione della supply chain. Considerando l’elenco di organizzazioni di élite (Microsoft, McKinsey, MIT e persino Harvard) coinvolte nella pubblicazione di questo articolo, ci si aspetterebbe delle opinioni profonde e illuminanti, del tipo che spieghino attentamente come un brillante pezzo di tecnologia, i LLM, contribuirà al miglioramento delle supply chain.

Invece, otteniamo un contributo mediocre. Più precisamente: è pigro, iperbolico e profondamente fuorviante, un pezzo che si basa su una parola di moda tecnologica. Tutto il presupposto dell’articolo può essere riassunto come i LLM possono generare ed esporre il codice rilevante per la supply chain. Gli autori adottano quello che solitamente definisco un approccio gadgetoid all’argomento. L’approccio gadgetoid consiste, quando si scopre un nuovo pezzo di tecnologia, nel fissare in modo frettoloso il pezzo su un sistema esistente. Questo viene tipicamente fatto senza alcuna considerazione né dei limiti del pezzo né dei cambiamenti che verrebbero apportati al sistema. Di conseguenza, questo approccio produce inevitabilmente gadget, strumenti divertenti di interesse limitato e nessun valore commerciale.

Alle varie organizzazioni coinvolte:

• Microsoft: avete molti ingegneri talentuosi a bordo. Dovete porre standard più elevati a voi stessi.

• McKinsey: non indirizzate i potenziali clienti in direzioni che sono garantite di essere una perdita di tempo e denaro.

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

Cerchiamo subito di chiarire che, sebbene io sia d’accordo sul fatto che i LLM possano essere utilizzati per il miglioramento delle supply chain, i LLM possono anche essere una distrazione completa, a seconda di come l’impresa viene affrontata. Questo punto si rivela esattamente il problema fondamentale che affligge l’articolo in esame. Un articolo strettamente correlato di Microsoft² soffre anche di questo problema; anche se, per chiarezza, la mia recensione rimarrà focalizzata sull’articolo di Harvard.

Prima di affrontare l’assurdità tecnologica centrale, sottolineiamo un notevole problema etico. Questo articolo non è altro che un pezzo pubblicitario mascherato per Microsoft Cloud Supply Chain. Microsoft è naturalmente libera di pubblicizzare i suoi servizi nel modo che ritiene più opportuno, ma coinvolgere sia Harvard (attraverso la pubblicazione) che il MIT (attraverso la co-autorizzazione) in un pezzo promozionale mi lascia perplesso. Almeno, l’articolo dovrebbe sottolineare che i coautori hanno evidenti conflitti di interesse. L’accademia non dovrebbe approvare attività promozionali occulte dei fornitori di tecnologia, per quanto grandi e influenti possano essere.

Avvertenza: il lettore attento avrà capito che anch’io ho un conflitto di interesse. Sì, gestisco un’azienda di software per la supply chain e, quindi, ho un interesse personale nel contraddire le sciocchezze che Microsoft, McKinsey, MIT e Harvard stanno diffondendo. Ora le mie carte sono scoperte.

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

I pianificatori monitorano anche i cambiamenti nel piano della domanda, chiamato deriva della domanda, su base mensile per garantire che il piano rivisto soddisfi tutte le esigenze dei clienti e rientri nelle linee guida di bilancio […] La tecnologia basata su LLM fa tutto questo. Genera automaticamente un rapporto via email che dettaglia chi ha apportato ogni modifica e il motivo per farlo.

In breve, gli LLM possono automatizzare il lavoro dei dipendenti. Tuttavia, ci sono due obiezioni ovvie. In primo luogo, gli LLM non sono affatto necessari per eseguire questo tipo di politica basata sul ruolo. Un semplice linguaggio di programmazione e alcune istruzioni imperative sono sufficienti. Inoltre, comunque sarà necessaria una programmazione per accedere ai dati e inviare l’email. In quelle situazioni, gli LLM sono garantiti per rappresentare 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 utilizzare come ultima risorsa, quando tutto il resto ha fallito. Questo chiaramente non è il caso qui.

In secondo luogo, il lavoro noioso indicato sopra è del tutto superfluo. L’azienda dovrebbe eliminare questa classe di compiti inutili[^burocrazie]. Le burocrazie sono già abbastanza negative, ma le tecnocrazie sono peggiori. Portare pezzi di tecnologia troppo complicati alla festa garantisce che la burocrazia si radichi ancora di più nei suoi modi disfunzionali. Lokad, la mia azienda, ha eliminato questo tipo di lavoro noioso da più di un decennio e non richiede nulla di complicato e costoso come gli LLM.

Questi contratti specificano i dettagli del prezzo pagato dall’OEM, i requisiti di qualità, i tempi di consegna e le misure di resilienza che i fornitori devono adottare per garantire la fornitura. Dopo aver alimentato i dati LLM con 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.

Sebbene sia vero che le aziende falliscono regolarmente nell’applicare alcune delle clausole contrattuali con i loro fornitori che sarebbero a loro vantaggio, l’individuazione delle clausole contrattuali rilevanti è solo una piccola parte della sfida, diciamo il 1% o forse anche 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 tipo di trivia appartiene a un post di LinkedIn intitolato “Le 10 cose che ho fatto oggi con ChatGPT” e non a una pubblicazione di Harvard-MIT.

Ora, la sfida effettiva è duplice: strumentazione e relazione. Sul lato della strumentazione, le operazioni di emissione di ordini e pagamenti sono in gran parte automatizzate nella maggior parte delle aziende che gestiscono qualcosa che può essere definito una “supply chain”. Pertanto, a meno che non ci sia un supporto strumentale esteso, occuparsi di casi limite marginali complicherà e ritarderà tutto.

Inoltre, sul lato della relazione, se una clausola contrattuale è stata ignorata per anni, è ingenuo pensare che l’azienda possa attivare la clausola senza conseguenze. Molto spesso, il fornitore ha già integrato questo comportamento negligente del cliente nei suoi prezzi e fare il pignolo su termini contrattuali marginali avrà una risposta adeguata, o forse attraverso un aumento di prezzo.

Più in generale, gli sconti e le riduzioni di prezzo dovrebbero essere gestiti come parte dei normali sistemi di business transazionali. Questo non è ingegneria aerospaziale, ma semplice vecchio CRUD³. Ancora una volta, portare un LLM dove poche regole imperative sarebbero sufficienti è tecnicamente insensato.

Un LLM consente ai pianificatori di fare domande dettagliate. Ecco alcuni esempi: “Quali sarebbero i costi di trasporto aggiuntivi se la domanda complessiva del prodotto aumentasse del 15%?” […] Ecco come un LLM può rispondere in modo accurato ed efficiente a domande come queste. 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 utilizzato per produrre il piano.

Questo è un pensiero utopistico. Ad oggi, la percentuale di aziende che godono di un “codicebase monolitico unificato” per derivare le loro decisioni sulla supply chain è praticamente nulla (ne parleremo più avanti). Invece, le aziende hanno un oceano di fogli di calcolo. A differenza dell’immagine idilliaca che gli autori stanno dipingendo, non esistono “programmi matematici” con cui interagire per i LLM. Sebbene i LLM potrebbero, concettualmente, modificare e migliorare un mucchio disordinato di fogli di calcolo semi-obsolete, fino a prova contraria, questa è pura speculazione. Anche i LLM all’avanguardia avrebbero difficoltà a modificare un singolo grande foglio di calcolo: la duplicazione passiva del codice che i fogli di calcolo comportano non è affatto favorevole per i LLM, ma dare un senso a centinaia, se non migliaia, di fogli rimane pura fantascienza a questo punto.

Ora, ci sono effettivamente alcune aziende che beneficiano di un codicebase monolitico unificato che gestisce i processi decisionali della supply chain, ovvero i clienti di Lokad. Se gli autori avessero, come noi, effettivamente esperienza in materia, avrebbero saputo che questi codicebase sono di dimensioni considerevoli; tipicamente decine di migliaia di righe di codice, nonostante il fatto che utilizziamo un DSL (linguaggio specifico del dominio)⁴ dedicato alla supply chain. Questo DSL è circa 10 volte più conciso di Python o Java per questo tipo di compito, tra l’altro. Purtroppo non ci sono scorciatoie: per ogni decisione di interesse, ci sono decine di tabelle, che coprono centinaia di campi, che sono coinvolti nel calcolo. Sebbene sia concepibile che ulteriori miglioramenti al nostro DSL possano ridurre ulteriormente il numero di righe di codice, questi codicebase non saranno mai piccoli.

Ancora una volta, i LLM potrebbero, concettualmente, modificare e migliorare un codicebase complesso mentre sono guidati da un contributore non tecnico. Tuttavia, ci troviamo nuovamente in territorio di fantascienza. I LLM sono già stati dimostrati essere strumenti di produttività fantastici per programmatori capaci. In altre parole, se già sai come programmare, i LLM possono aiutarti a programmare più velocemente. Tuttavia, questo non è ciò che gli autori dell’articolo stanno dicendo. La loro proposta è precisamente che i LLM possano essere utilizzati per consentire a contributori non tecnici di effettuare contributi tecnici. Sulla base dello stato attuale dell’arte dei LLM, questa proposta è inevitabilmente falsa, tranne che nei limiti di piccole sandbox che non riflettono l’ampia complessità ambientale delle supply chain del mondo reale.

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

Gli autori stanno insistendo sulla fantascienza. Questa affermazione è tecnicamente indistinguibile da “un LLM può emettere patch a un repository di codice su GitHub basandosi su ticket presentati da utenti non tecnici”. Sarebbe una notizia fantastica se fosse possibile, ma ancora una volta, i LLM attuali sono lontani dall’essere in grado di realizzare questo tipo di impresa in modo affidabile per richieste serie. Quando si presentano casi d’uso per una nuova tecnologia, è fondamentale comunicare accuratamente i limiti di tale tecnologia. I quattro coautori sembrano essere completamente ignari dello stato attuale dell’arte dei LLM; detto questo, ho il sospetto che non lo siano affatto. Invece, otteniamo un discorso pubblicitario da persone che sono perfettamente consapevoli di ciò che stanno facendo, il che è argomentabile molto peggio.

La necessità di modificare il piano di approvvigionamento può essere determinata anche dalla tecnologia basata su LLM. Ad esempio, dopo aver analizzato i dati di spedizione di un fornitore specifico, potrebbe generare un allarme che il tempo di consegna dal fornitore è aumentato significativamente negli ultimi mesi.

Rilevare se un tempo di consegna è anomalo è assolutamente ciò che un LLM non può fare. Tuttavia, un LLM può essere sollecitato a scrivere un pezzo di codice per eseguire questa analisi. Siamo tornati al post di LinkedIn “Le 10 cose che ho fatto oggi con ChatGPT”. Perché fermarsi qui e non aggiornare direttamente la logica di ordinazione dove le informazioni sul tempo di consegna vengono utilizzate? 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 supporto gli autori intendevano rendere i programmatori più produttivi - i programmatori che sono responsabili della codifica delle decisioni end-to-end - allora questo è già possibile - infatti, è qualcosa che Lokad fa da tempo. Tuttavia, se rimuoviamo i programmatori umani dall’immagine, questa affermazione diventa qualcosa di più simile a “prevediamo che nei prossimi anni le tecnologie basate su LLM raggiungeranno l’AGI (intelligenza artificiale generale)”.

Gli autori, cavalcano l’onda del buzzword “Gen AI”, sono completamente sprezzanti del fatto che i LLM potrebbero avere limitazioni proprie. Ecco cosa gli autori propongono nella loro sezione conclusiva “Superare le barriere”:

Adozione e formazione. Utilizzare un LLM per ottimizzare le catene di approvvigionamento richiede un linguaggio molto preciso […] Ogni interpretazione porta a decisioni diverse.

No, questo è completamente sbagliato - a meno che “linguaggio molto preciso” non sia inteso come “linguaggio di programmazione” (poiché quelli sono effettivamente molto precisi). Per ottimizzare una catena di approvvigionamento utilizzando un LLM, è necessario un ingegnere umano in grado di fare la codifica interamente da solo, sebbene più lentamente. Nel futuro prevedibile, nessuna quantità di formazione, tranne che diventare competenti nella programmazione, renderà gli utenti capaci di eseguire ottimizzazioni delle catene di approvvigionamento con il supporto dei LLM.

Dire al CEO o al direttore della catena di approvvigionamento che deve solo formare il suo team a usare un “linguaggio preciso” è completamente fuorviante. Il tipo di workshop di formazione che deriverebbe da questa visione è garantito per essere 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 “sulla giusta strada”, ovvero identificare gli errori e riprendersi da essi.

Sebbene i LLM siano probabilistici per design, questa problematica è oscurata dall’incertezza semantica che permea i sistemi di catene di approvvigionamento. In altre parole, è molto probabile che il LLM ti dia la risposta corretta al problema sbagliato. L’esperienza di Lokad indica che spesso l’unico modo per verificare se una determinata implementazione (che guida una decisione di catena di approvvigionamento) è corretta è effettuare un test sperimentale limitato⁵. Il feedback del mondo reale non è un’opzione. La conoscenza non può essere evocata dal nulla, anche i LLM di livello AGI sarebbero ancora confrontati con questa difficoltà.

Qui, gli autori vengono colti a riempire. Fanno una dichiarazione corretta ma banale sulla natura dei LLM senza nemmeno cercare di capire se la questione è una preoccupazione centrale o meno. Se gli autori avessero effettivamente gestito catene di approvvigionamento del mondo reale utilizzando LLM, avrebbero capito, come noi, che questa preoccupazione è un piccolo problema all’interno di una lunga lista di problemi molto più grandi e molto più impattanti.

Per concludere, si applica la legge di Brandolini: La quantità di energia necessaria per confutare le sciocchezze è un ordine di grandezza maggiore di quella necessaria per produrle. Questo articolo è così brutto che potrebbe essere stato scritto da ChatGPT, e forse lo è stato per quanto ne so. Sulla base delle mie osservazioni casuali, ogni giorno vengono prodotti decine di articoli altrettanto scadenti su Gen-AI e SCM. La notorietà degli autori mi ha motivato a scrivere questa recensione. Tuttavia, non sarebbe la prima volta che un fornitore promette di rivoluzionare un settore senza avere nulla di concreto da offrire. Tuttavia, lo stesso fornitore che lo fa due volte⁶ due anni di seguito nello stesso settore potrebbe essere eccessivo. D’altra parte, l’accademia dovrebbe almeno cercare di fare un po’ di pensiero critico invece di salire felicemente sul carrozzone delle parole di moda.