Chiacchierare con il tuo Supply Chain non lo risolverà
Ogni pochi giorni, una nuova demo fa il giro: scrivi una domanda in inglese semplice—“Cosa succede se la domanda aumenta in Germania?”, “Cosa accade se chiudiamo questo impianto?”, “Cosa succede se cambiamo fornitore?”—e un assistente risponde con sicurezza con un piano rivisto, una breve spiegazione e un elenco ordinato di prossime azioni. Il discorso è irresistibile: supply chain, finalmente resa conversazionale. La pianificazione, finalmente resa senza attriti. L’ottimizzazione, finalmente resa accessibile.
Nel mio libro Introduction to Supply Chain (vedi Capitolo 6, in particolare le parti che trattano di “intelligenza generale” e dell’eredità della OR), ho sostenuto che la supply chain è una disciplina che scambia ripetutamente interfacce eleganti per progresso. Questo argomento è importante ora, perché i modelli linguistici di grandi dimensioni (LLMs) vengono posizionati—sia da ricercatori seri che da fornitori seri—come il tassello mancante che finalmente collegherà la matematica alle operazioni, e la pianificazione alla realtà.
Ciò che la comunità sta effettivamente costruendo
La comunità della ricerca operativa è stata sorprendentemente coerente su ciò che desidera dagli LLM: un traduttore universale tra l’intento umano e la macchina matematica.
La serie di competizioni NL4Opt a NeurIPS è esplicita sull’obiettivo: aumentare l“accessibilità e l’usabilità dei solver di ottimizzazione” permettendo ai non esperti di esprimere problemi in linguaggio naturale, per poi generare gli artefatti di modellazione (incluso il codice di modellazione LP e MIP) che i solver possono utilizzare. Non si tratta di un’idea marginale; sta infatti venendo formalizzata in compiti di riferimento, set di dati, metriche di valutazione e strutture di competizioni a premi.
OptLLM spinge la stessa idea dal lato della ricerca in un flusso di lavoro end-to-end: l’utente enuncia un problema di ottimizzazione in linguaggio naturale; il sistema lo converte in formulazioni matematiche e codice di programmazione; poi chiama un solver esterno e itera attraverso un dialogo a più turni per perfezionare il modello. In altre parole: English → matematica → codice → solver → risultati → English, con l’LLM che orchestra il ciclo.
Il capitolo TutORials 2024 di INFORMS, a cura di Wasserkrug, Boussioux e Sun, offre un’inquadratura più ampia e rivolta ai professionisti: gli LLM possono accelerare la creazione e il dispiegamento di soluzioni OR/MS riducendo (i) il tempo di sviluppo migliorando al contempo la qualità delle soluzioni, (ii) estraendo dati strutturati da testi non strutturati senza dover costruire modelli NLP su misura (viene esplicitamente menzionato il demand forecasting come caso d’uso motivante), e (iii) abilitando interfacce in linguaggio naturale affinché gli utenti aziendali possano interagire in modo flessibile con i modelli analitici. Il capitolo è notevole non solo per l’ottimismo, ma anche per l’enfasi sull’uso responsabile: gli LLM vengono presentati come strumenti potenti, ma strumenti che necessitano di governance e responsabilità.
Nel frattempo, il settore dell’apprendimento per l’ottimizzazione sta assorbendo gli LLM—non solo come “interfacce”, ma come componenti dell’ecosistema dei solver stessi. L’ambizione del “foundation model” è arrivata nel MILP: i ricercatori di Microsoft propongono l’addestramento di un modello unico attraverso diverse classi MILP e introducono MILP‑Evolve, un framework evolutivo basato su LLM che genera classi di problemi MILP ampie e diversificate “con una quantità illimitata di istanze”, supportando compiti come il learning to branch e l’allineamento delle istanze MILP con descrizioni in linguaggio naturale. Un sondaggio del 2025 sugli LLM per l’ottimizzazione evolutiva va oltre, categorizzando i paradigmi emergenti: LLM come ottimizzatori autonomi, LLM incorporati all’interno degli algoritmi di ottimizzazione, e LLM usati a un livello superiore per la selezione e la generazione di algoritmi—puntando esplicitamente verso “ecosistemi agentic auto-evolutivi” per l’ottimizzazione.
Nel campo della pianificazione della supply chain, le proposte si accordano quasi perfettamente con l’agenda dell’OR—ma con un punto focale diverso: non “rendere i solver accessibili”, ma “rendere i pianificatori veloci.”
Il contributo 2025 di MIT Sloan Executive Education sugli LLM nella pianificazione della supply chain è rappresentativo. Descrive i pianificatori che pongono complesse domande what-if in linguaggio naturale; l’LLM traduce la domanda in aggiustamenti matematici e restituisce intuizioni leggibili. Sostiene che ciò che in precedenza richiedeva “giorni” di interazioni con gli ingegneri può diventare “minuti”, ed estende la promessa anche alle interruzioni in “tempo reale”: i pianificatori possono “regolare dinamicamente i modelli matematici” senza dover contare sui team IT, e rieseguire l’ottimizzazione per ottenere piani rivisti spiegati in linguaggio semplice. Lo stesso articolo ammette, quasi in via marginale, la difficoltà centrale: la validazione—assicurarsi che gli aggiustamenti generati dall’IA corrispondano alle condizioni reali di business—rimane una sfida.
Simchi-Levi, Mellou, Menache e Pathuri (2025) rendono esplicita la tesi della “democratizzazione”: attualmente, i pianificatori e gli esecutivi impiegano troppo tempo a comprendere i risultati, a eseguire scenari e ad aggiornare i modelli, per cui gli LLM possono “democratizzare la supply chain technology” facilitando la comprensione e l’interazione “senza l’human-in-the-loop”, riducendo il tempo decisionale da “giorni e settimane” a “minuti e ore.”
Il progetto OptiGuide di Microsoft Research si colloca esattamente in questa intersezione tra OR e pianificazione: mira a “democratizzare il processo decisionale” combinando ottimizzazione con IA generativa, e afferma un uso in produzione per i pianificatori di supply chain cloud che rispondono a domande “what if” e ricevono raccomandazioni operative.
I fornitori di software, non sorprendentemente, si sono concentrati sugli stessi temi: copilots, agents, query in linguaggio naturale e decisioni più rapide.
SAP posiziona Joule come un copilot basato su IA generativa integrato nelle sue applicazioni aziendali, inclusa la supply chain, e le pagine specifiche di SAP IBP enfatizzano l’accesso conversazionale alla documentazione di prodotto (un modo più fluido per cercare e recuperare indicazioni) e l’integrazione di Joule con SAP IBP. Le note di rilascio della comunità di SAP per IBP menzionano l’integrazione di Joule come un’innovazione in quella linea di rilascio.
Gli annunci di Oracle del 2025 enfatizzano “AI agents” integrati in Oracle Fusion Cloud Applications. Per la supply chain, Oracle afferma che questi agents automatizzano i processi, ottimizzano la pianificazione e l’evasione degli ordini e accelerano il processo decisionale; addirittura elenca agents come un consulente di pianificazione per eccezioni e note che riassume avvisi e annotazioni. La documentazione di readiness di Oracle descrive anche un agente “Supply Chain Planning Process Advisor” costruito con LLMs + RAG per rispondere alle domande dei pianificatori su responsabilità, compiti quotidiani e processi di escalation, basato sui documenti aziendali caricati dal cliente.
Il comunicato stampa ICON 2025 di Blue Yonder presenta “AI agents” e un “supply chain knowledge graph”, affermando che gli agents consentono alle aziende di “vedere, analizzare, decidere e agire” con velocità meccanica e che l’IA agentica è infusa sia nella pianificazione che nell’esecuzione.
Kinaxis descrive capacità di IA agentica e generativa che abbassano le barriere all’interazione con i dati della supply chain—interrogando un “digital twin” in linguaggio naturale e ricevendo risposte—e i suoi materiali pubblici e le analisi indipendenti descrivono un framework multi-agente destinato a ridurre la dipendenza dall’IT e permettere ai pianificatori di interagire direttamente con i dati operativi.
o9 spinge la stessa narrazione con un branding diverso: “GenAI agents” più un enterprise knowledge graph che evolve in un “large knowledge model”, posizionati come un cambiamento radicale in termini di produttività ed expertise per le funzioni di pianificazione.
Sopra tutto ciò si trova Gartner, che fornisce il linguaggio di categoria. In un comunicato stampa di agosto 2025, Gartner prevede una rapida proliferazione di assistenti IA e agents IA specifici per compiti nelle applicazioni aziendali, delinea le “fasi” dell’evoluzione dell’IA agentica e avverte che un’idea sbagliata comune è quella di chiamare gli assistenti “agents”—un malinteso che etichetta come “agentwashing.”
Quindi, sì: c’è un lavoro reale in corso. Benchmark, framework, architetture agentiche, integrazioni e molta ingegneria orientata alla produzione. La questione non è se gli LLM possono essere integrati negli strumenti della supply chain—lo sono già. La questione è se tale integrazione affronti le vere ragioni per cui il processo decisionale nella supply chain rimane ostinatamente mediocre.
Perché non sono convinto che l’interfaccia sia il collo di bottiglia
La comunità dell’OR ha ragione su una cosa: l’ottimizzazione è difficile da esprimere in modo chiaro. Anche la comunità della pianificazione ha ragione su una cosa: le persone perdono tempo a tradurre le domande in fogli di calcolo, email, riunioni, ticket e modifiche ad hoc ai modelli. Un LLM può ridurre quell’attrito. Può abbreviare il percorso tra “mi chiedo…” e “ecco una risposta calcolata”, proprio come descritto nel contributo di MIT Sloan.
Ma le supply chains non falliscono perché ai pianificatori manca un modo più veloce per porre domande.
Esistono già decenni di solver, linguaggi di modellazione e progressi accademici. L’affermazione insita in NL4Opt—“rendere i solver utilizzabili dai non esperti attraverso il linguaggio naturale”—presuppone che l’ostacolo principale sia l’incapacità dell’utente di formulare il problema. Questa è una narrazione rassicurante per i ricercatori, perché trasforma un fallimento organizzativo caotico in un problema di traduzione. Accade, inoltre, che sia in gran parte falsa nella supply chain.
Ciò che impedisce l’adozione nel mondo reale non è che le persone non siano in grado di digitare vincoli. È che i vincoli, gli obiettivi e la semantica dei dati sono regolarmente errati—o, più precisamente, sono errati in modi che hanno un impatto economico. Puoi generare montagne di codice di modellazione e continuare a ottimizzare assurdità.
Questa non è una critica nuova. Russell Ackoff sosteneva nel 1979 che l’OR fosse diventata “contextualmente ingenua” e che la sua applicazione fosse sempre più limitata a problemi relativamente insensibili al loro contesto. Le supply chains sono l’opposto di quelle insensibili all’ambiente. Sono dominate da volatilità, effetti di sostituzione, dati mancanti, feedback ritardati e incentivi che rimodellano il comportamento non appena si inizia a “ottimizzare.”
L’agenda degli LLM in OR tende a sottovalutare un’asimmetria brutale: scrivere un modello è più facile che validarlo. OptLLM può generare formulazioni e codice, per poi iterare attraverso un dialogo. Tuttavia, la vera difficoltà non è produrre un altro oggetto matematico—ma assicurarsi che l’oggetto corrisponda ai veri trade-off economici dell’azienda, ai vincoli operativi e alla realtà delle misurazioni. Un LLM può produrre un vincolo plausibile; non può certificare che questo vincolo sia ciò che il tuo magazzino sperimenta realmente alle 3 del mattino durante una promozione, con il vero roster del personale, le vere politiche di imballaggio, le vere regole di rifornimento e i veri modi di fallire.
Nella pianificazione, la stessa asimmetria diventa ancora più pericolosa, perché il riflesso culturale è quello di fidarsi del piano. L’articolo di MIT Sloan celebra il fatto che i pianificatori possano “regolare dinamicamente i modelli matematici” senza l’IT. Simchi-Levi e i coautori lo inquadrano come l’eliminazione della necessità di team di data science e fornitori di tecnologia nella catena. Questo viene venduto come empowerment. Io lo vedo come un modo per bypassare quell’attrito che in passato preveniva una deriva incontrollata del modello.
Se modificare il modello è facile, l’organizzazione cambierà il modello costantemente. Non perché sia saggio, ma perché sia psicologicamente soddisfacente. Ogni interruzione invita a una nuova eccezione. Ogni domanda esecutiva suscita un nuovo scenario. Ogni riunione invita a una nuova modifica per soddisfare l’intuizione di qualcuno. Si ottiene un movimento più veloce, sì—ma anche un’entropia più rapida.
I fornitori, comprensibilmente, si sono orientati verso “agents” che riassumono, spiegano e guidano. Il Planning Process Advisor di Oracle è essenzialmente uno strato LLM+RAG sopra le politiche e le procedure: risponde alle domande basandosi sui documenti che carichi e integra questa esperienza di chat all’interno delle pagine di workflow. Il posizionamento di Joule in IBP da parte di SAP evidenzia in modo simile la ricerca conversazionale e le risposte basate sulla documentazione. Queste sono funzionalità di produttività legittime. Possono ridurre il tempo sprecato alla ricerca del giusto documento di processo. Ma non cambiano in modo significativo la qualità delle decisioni. Sono, nel migliore dei casi, un sistema di aiuto migliore.
Poi arriviamo alla più ampia narrazione “agentica”. Blue Yonder annuncia molteplici AI agents, infusi sia nella pianificazione che nell’esecuzione, puntando a un’ottimizzazione continua e a decisioni a velocità meccanica. Kinaxis descrive framework agentici, AI agents che monitorano e agiscono in tempo reale, e l’interazione in linguaggio naturale con un digital twin. Gartner prevede un mondo pieno di queste soluzioni, avvertendo però che gran parte di ciò che viene venduto come agents sono in realtà assistenti—“agentwashing.”
L’ironia è che l’avvertimento di Gartner non è un’osservazione secondaria; è il fatto centrale. La maggior parte di questi “agents” sono semplici involucri. Si posizionano sopra i workflow esistenti, automatizzano frammenti di interazione e rendono l’interfaccia più gradevole. Non riparano la logica economica delle decisioni, né risolvono le questioni fondamentali relative alla fedeltà dei dati, all’incertezza e agli incentivi. Possono ridurre il ritardo decisionale in senso stretto perché qualcuno può cliccare più velocemente—ma non nel senso profondo di compiere meno errori.
Anche le integrazioni accademiche più sostanziali—LLM + network optimization, con dashboard e spiegazioni consapevoli del ruolo—inquadano la difficoltà centrale come il “colmare il divario” tra gli output dell’OR e la comprensione degli stakeholder traducendo i risultati in linguaggio naturale e KPI contestuali. Di nuovo: utile. Ma mantiene intatto lo stesso presupposto: il modello è corretto; le persone devono solo capirlo. Nella supply chain, il modello è spesso il problema.
Quindi, quando sento dire “LLMs democratizzeranno l’ottimizzazione”, lo interpreto come: “democratizzeremo la produzione di pseudo-modelli.” Quando sento dire “LLMs permetteranno ai pianificatori di aggiornare i modelli senza IT”, lo interpreto come: “accelereremo il ritmo con cui modelli fragili vengono patchati, non patchati e ripatchati.” E quando sento dire “l’IA agentica orchestrerà i workflow end-to-end”, mi chiedo: orchestrare verso quale obiettivo, su quale semantica, con quale responsabilità?
Dove gli LLM possono essere veramente utili
Nulla di tutto ciò è un argomento per ignorare gli LLM. È un argomento per smettere di fingere che la conversazione sia un sostituto della competenza.
Il capitolo TutORials di OR/MS ha ragione nell’enfatizzare che gli LLM possono accelerare la produzione di applicazioni per il processo decisionale, aiutare a trasformare testi non strutturati in segnali strutturati e fornire interfacce in linguaggio naturale—pur insistendo sull’uso responsabile. Questo è esattamente il punto di forza degli LLM: non come motore decisionale, ma come moltiplicatore di produttività per gli ingegneri e gli analisti che costruiscono il vero motore decisionale.
Se usi LLMs per scrivere glue code più velocemente, per generare test, per redigere documentazione, per estrarre regole aziendali disordinate da contratti e SOPs in rappresentazioni strutturate, stai migliorando la parte della pipeline che in realtà è il collo di bottiglia: l’ingegnerizzazione lenta, costosa e soggetta a errori di dati e logica. Se usi LLMs per aiutare auditor, dirigenti e operatori a capire perché è stata presa una decisione calcolata—producendo spiegazioni basate su prove tracciabili—puoi migliorare l’adozione senza cedere il controllo.
Anche la linea della “democratizzazione” può essere riformulata in modo produttivo. L’affermazione di OptiGuide secondo cui è stato utilizzato in produzione per cloud supply chain planners che rispondono a domande ipotetiche non è banale. Ma il valore non sta nel fatto che un planner possa chattare con un ottimizzatore. Il valore sta nel fatto che un’azienda con una solida spina dorsale di ottimizzazione può costruire un’interfaccia più sicura e fruibile—una che espone le leve e le spiegazioni giuste, anziché permettere a chiunque di riscrivere casualmente la matematica sottostante.
E sì, l’agenda di apprendimento dei solver—foundation models per MILP, learned branching, e così via—potrebbe portare a veri miglioramenti algoritmici. Ma supply chain trarrà beneficio da questi miglioramenti solo se il resto della struttura è sano: semantica corretta, obiettivi economici, gestione robusta dell’incertezza e un ciclo di esecuzione che trasforma le raccomandazioni in azioni in modo affidabile.
In altre parole, tratta gli LLMs come tratti qualsiasi strumento potente ma fallibile: come un accelerante per le persone che costruiscono sistemi, non come uno strato di vernice su processi rotti. Trattali come un modo per ridurre il costo della rigorosità, non come un modo per saltarla.
Supply chain non è carente di parole. È carente di buone decisioni. Gli LLMs sono eccezionali nel produrre parole. Possono aiutarci a costruire sistemi migliori, più velocemente. Ma se confondiamo l’eloquenza con la correttezza, otterremo semplicemente errori presentati in una prosa migliore—e a una velocità superiore.
