I gemelli digitali valgono il clamore?

Trascrizione completa

Conor Doherty: Questo è Supply Chain Breakdown, e per i prossimi circa 30 minuti smonteremo il clamore intorno ai gemelli digitali, in particolare in supply chain. Mi chiamo Conor. Sono il Responsabile della Comunicazione di Lokad, e mi sta accompagnando in studio alla mia sinistra, come sempre, l’incommensurabile Joannes Vermorel, fondatore e CEO di Lokad.

Prima di iniziare, commenta qui sotto—innanzitutto, da dove vieni, e in secondo luogo, cosa pensi dei gemelli digitali? Ricorda, siamo qui per parlare delle tue preoccupazioni. Inoltre, inviaci le tue domande ogni volta che ne hai una. Se senti qualcosa che Joannes dice e vuoi metterlo in discussione, sentiti libero di farlo. Scrivilo qui sotto e glielo chiederò tra circa 20 minuti.

Detto ciò, niente più tempo sprecato. Joannes, smonta il clamore intorno ai gemelli digitali, perché so che c’è da un po’, ma spiega bene: cos’è un gemello digitale in termini semplici? E inoltre, qual è il problema che, almeno, la gente pensa che i gemelli digitali siano progettati per risolvere?

Joannes Vermorel: Quindi, considerando cosa sono i gemelli digitali, direi che se prendi la versione aziendale—che non seguirei—ti direbbero: è una rappresentazione accurata della tua supply chain, completamente digitale, che ti permette di proiettare praticamente qualsiasi cosa nel futuro. Come se avessi una simulazione completa, perfettamente accurata, dell’intera supply chain. Almeno, questa è la visione ideale dei gemelli digitali in supply chain.

E l’idea dei gemelli digitali esiste anche in altri ambiti, e per altri ambiti a volte puoi avere una simulazione molto accurata di un sistema fisico. Ora, nella pratica, cos’è? Nella pratica, è semplicemente un simulatore Monte Carlo riproposto. Questi simulatori esistono da circa quattro decenni. La caratteristica chiave è che sono molto, molto facili da implementare, ed è relativamente divertente, come progetto per hobby, implementare un simulatore Monte Carlo di un sistema, purché non ti interessi veramente nulla riguardo l’accuratezza delle simulazioni.

Conor Doherty: Interverrò subito, perché hai sollevato alcuni punti interessanti. Hai menzionato almeno due applicazioni: una, come i gemelli digitali potrebbero essere commercializzati in un contesto supply chain—questa è una categoria. Ma hai detto che esiste un’applicazione preesistente o più duratura; hai detto quella per prodotti fisici. Potresti sviscerare un po’ meglio questa distinzione?

Joannes Vermorel: Sì. Voglio dire, l’idea di avere simulatori—ci sono tre concetti chiave: micro-analitico, discreto e stocastico. Sono tre concetti. Quando si pensa a simulatori Monte Carlo, sono questi i tre aspetti che trovi.

Micro-analitico significa che vuoi decomporre il tuo sistema in elementi simili ad atomi o in componenti molto, molto piccoli che hanno comportamenti semplici regolati da leggi elementari che puoi quantificare completamente. Questa è la visione micro-analitica. Poi discreto: per il tuo computer presumerai che tutto si comporti con incrementi regolari—in supply chain ha senso—anche per la dimensione temporale. Quindi dirai, “Okay, creerò un simulatore che opera con un passo al giorno,” o qualcosa del genere.

E l’ultimo aspetto è quello stocastico: ad alcuni comportamenti semplicemente aggiungerai un po’ di casualità. Ecco perché parlo di un simulatore Monte Carlo. Attribuisci a certi comportamenti una natura casuale o stocastica, e poi puoi eseguire ripetutamente il tuo simulatore molte volte per proiettare, presumibilmente, uno stato futuro della tua supply chain, o almeno far avanzare il simulatore nel tempo. E poiché dovrebbe essere un gemello digitale della tua supply chain, rappresenta il futuro della tua supply chain.

Conor Doherty: Grazie, e penso che ciò sollevi nuovamente un punto chiave su come la conversazione possa essere divisa. Quando si parla di utilizzare un gemello digitale in, diciamo, produzione o riparazione, puoi dire, “Ho un gemello digitale. È una rappresentazione deterministica di un aereo completo.” Quindi un A320 ha circa 320.000 parti. Sai quante parti ci sono; puoi modellarlo; è fisso. Quella è una replica digitale o una rappresentazione digitale di un prodotto o proprietà fisica e conosciuta.

Quanto bene puoi applicare lo stesso concetto a una rete distribuita geograficamente come una supply chain che racchiude non solo parti fisiche come prodotti e trucks e simili, ma anche comportamenti, tendenze, politica—tutto ciò che incide su questi elementi?

Joannes Vermorel: Il problema principale sono le leggi che governano i tuoi atomi, le unità elementari della simulazione. Se sei nel mondo fisico, puoi letteralmente applicare l’elettromagnetismo e altro per ottenere un’evoluzione fisicamente accurata del tuo sistema, perché si presume che, se decomponi le cose a sufficienza, ciò che rimane obbedirà a leggi molto, molto note. Se vuoi descrivere un fluido che scorre attraverso vari tubi e simili, hai le equazioni microfluidiche e puoi fare una simulazione a elementi finiti.

Ma l’intuizione chiave qui è che si presume di avere leggi che governano gli elementi del tuo sistema in modo fondamentalmente perfetto, e l’unico punto debole è la risoluzione della simulazione, che potrebbe non essere sufficiente a garantire una super accuratezza. Il problema con un gemello digitale in supply chain è che la sfida non è tanto la risoluzione. La sfida è che non è affatto chiaro se si disponga di una conoscenza a priori rilevante sui comportamenti di queste unità elementari, perché queste unità semplici—diciamo, se vuoi simulare un fornitore—non sono affatto semplici.

Non esiste—puoi fare assunzioni semplificate sul comportamento di questo fornitore quanto vuoi, ma non significa che, inventando un’ipotesi su questa entità, essa dovrà essere vera. E lo stesso vale per tutto: clienti, magazzini, percorsi che collegano l’intera supply chain, ecc. Quindi c’è veramente un problema fondamentale: sì, puoi creare un simulatore decomponendo il tuo sistema e inventando comportamenti per tutti gli atomi, ma questi comportamenti hanno una qualche forma di correttezza? Questa è la grande, grande sfida, ed è tipicamente un aspetto di cui i gemelli digitali in supply chain non si discute mai—la correttezza della modellizzazione.

Conor Doherty: Correttezza e altri parametri di cui torneremo, ma voglio approfondire un po’. Infatti, ti leggerò una definizione molto chiara. Che tu sia d’accordo o meno, è una definizione limpida, e vorrei conoscere la tua reazione. Non ti dirò ancora da chi provenga—potrai indovinarlo più tardi—ma è davvero incisiva. Quindi, citando: “I gemelli digitali possono essere usati per modellare l’interazione tra processi fisici e digitali lungo tutta la supply chain, dalla concezione del prodotto e produzione allo stoccaggio e distribuzione, dagli acquisti in negozio o online alla spedizione e ai resi. Così, i gemelli digitali dipingono un quadro chiaro di un processo supply chain ottimale end-to-end.” Ora, qual è la tua opinione in merito? Quali parti di questa definizione non ti convincono?

Joannes Vermorel: Questa definizione non dice altro che l’intento. Dice solo: “Okay, l’intento è avere qualcosa che faccia tutte le cose descritte in questa definizione”, ossia una rappresentazione end-to-end accurata di bla, bla, bla. Questo è l’intento. Non dice nulla su come lo faccia. E il mio messaggio è: il come conta.

Puoi inventare o desiderare tanti strumenti incredibili. Io vorrei—cos’è un assistente AI perfetto?—qualcosa che abbia un’intelligenza molto superiore a quella umana e che possa fare tutto ciò che un essere umano può fare, ma meglio. Okay, ho appena definito cosa sarebbe un assistente AI perfetto. Ma questo significa che ce ne sia uno già disponibile? Il problema è che se definisci qualcosa attraverso il suo intento, non dice nulla sulla fattibilità o sul fatto che questa cosa sia reale.

Quindi sì, abbiamo una bella definizione intenzionale. E io, quando dico “simulatore Monte Carlo”, ho fatto esattamente l’opposto. Ho cominciato con, “Okay, cosa fanno le aziende dietro le quinte quando usano la parola d’ordine ‘gemello digitale’?” E la mia risposta è, per quanto posso osservare: un simulatore Monte Carlo. Perché? Perché è estremamente semplice da implementare. Letteralmente, uno studente del primo anno di informatica può farlo in pochi giorni—probabilmente anche i più intelligenti ce la fanno in un pomeriggio. E sì, purché non ti interessi se la tua simulazione abbia rilevanza per il mondo reale, è super semplice da implementare.

Conor Doherty: Tornando al discorso, stai parlando dell’intento. Lo scopo, almeno secondo quanto presentato da molti, sarebbe—per darti uno spunto—quello che molti venditori, consulenti e sostenitori di un gemello digitale affermano: un gemello digitale migliora il decision-making fornendo effettivamente—anche se tramite Monte Carlo—una sandbox in cui poter giocare con scenarios, tipo “E se il fornitore fosse in ritardo? E se ci fosse un blocco nel Canale di Suez?” o simili.

Joannes Vermorel: Un’intelligenza artificiale generale migliora la redditività di qualsiasi azienda—per definizione. Se possiedi qualcosa che è intelligente quanto un essere umano ma non ha uno stipendio, sì, migliorerà. Okay. Ma torniamo alla domanda: questa cosa è disponibile, e quali sono le tecniche? Queste parti la presentano come un fatto compiuto: è già lì, ce l’abbiamo, possiede tutte queste buone proprietà. Ma, aspetta—cosa hai dietro le quinte?

E il mio messaggio è: per quanto ne so, letteralmente tutte le aziende che ho visto promuovere i gemelli digitali non avevano altro che dei semplici simulatori Monte Carlo, che a mio avviso rappresentano una sofisticazione da giocattolo. È sofisticato. È il tipo di piacevole esercizio che darei a studenti del primo anno di informatica. Sì, è divertente da implementare, ed è facile. Ma il problema è, di nuovo, che è completamente inventato.

Sì, puoi scomporre la tua supply chain in una lista di SKUs, una lista di clienti, una lista di fornitori, e assegnare comportamenti a tutte queste entità, e poi far partire la simulazione—assolutamente. Ma è realmente corretta? Questa è una domanda molto importante. Un’analogia sarebbe: prendi SimCity 2000, il videogioco—uno vecchio. Hanno un editor di mappe. Puoi letteralmente modificare una mappa che somiglierebbe a Parigi, tracciando tutte le strade esattamente com’è a Parigi—quasi, di nuovo, c’è il problema della discretizzazione, quindi non sono esattamente le stesse strade, ma abbastanza vicine. Poi puoi dire, “Questa zona è residenziale, quest’altra è industriale, quest’altra è commerciale.” Sì, potresti farlo, e poi lasciare che la simulazione del gioco prosegua.

Questo ti dà una simulazione accurata del futuro dell’ambiente urbano parigino? La mia risposta è decisamente no—soprattutto quando entra in gioco Godzilla; quello è un disaster che accade nel gioco. Non è perché sia molto facile creare tali simulazioni. Ripeto: è molto semplice creare simulatori, ed è divertente. La domanda è veramente: perché pensi che possa avere una qualche forma di accuratezza?

In altri settori, come le scienze fisiche—diciamo le scienze dei materiali—il tuo simulatore è valido perché obbedisce fondamentalmente alle leggi della fisica, che sono molto ben note e verificate. Quindi, fondamentalmente, i tuoi comportamenti non sono inventati: prendi letteralmente i libri di testo di fisica e applichi l’elettromagnetismo o la dinamica dei fluidi o simili, e questi sono i comportamenti che governano i tuoi elementi, i tuoi atomi. Ma in un gemello digitale in supply chain devi inventare e conjurare quei comportamenti—o scoprirli in qualche modo—ed è una parte molto, molto complicata. A mia conoscenza, i gemelli digitali per la supply chain—i venditori, le persone che li promuovono—non dicono veramente nulla a riguardo, e questo è il cuore del problema.

Conor Doherty: Hai menzionato l’accuratezza e la correttezza, e ancora, giusto per replicare—tra l’altro, quella definizione precedente era di McKinsey, quella con cui eri in disaccordo. E da uno all’altro, perché questa ora viene da BCG—oh, scusa, vuoi dire qualcosa?

Joannes Vermorel: Ancora, il problema è che descrivono l’intento. Quando si tratta di una tecnologia, preferisco concentrarmi sul come. Definire una tecnologia tramite l’intento di ciò che si vuole raggiungere è bello, ma non ti permette di ragionare se effettivamente quella tecnologia sia buona o meno. Non sono in disaccordo con l’intento—l’intento va bene, sì. La domanda è: hai una definizione che ti permetta di capire se questa tecnologia sia migliore o peggiore rispetto a un’altra per la tua supply chain?

Conor Doherty: A proposito, secondo—ancora, stiamo citando fonti—il Boston Consulting Group ha affermato che le aziende con gemelli digitali hanno migliorato l’accuratezza delle previsioni del 20-30%. Voglio dire, non è qualcosa per cui la maggior parte delle aziende farebbe di tutto? Hanno torto a perseguire questo obiettivo?

Joannes Vermorel: Per quanto ne so, i gemelli digitali non sono mai apparsi in nessuna competizione di forecasting. Ci sono molte competizioni di forecasting; ci sono dozzine di tecniche usate per ottenere previsioni migliori in queste competizioni. Non ho mai sentito nulla che riguardi i gemelli digitali nel contesto del forecasting.

Quindi vedi, il problema per me è che, dal momento che non definiscono a quali tecniche si riferiscono effettivamente, potrebbe essere qualsiasi cosa. La mia opinione—basata sull’osservazione empirica—è che le aziende che commercializzano i gemelli digitali stanno essenzialmente costruendo simulatori Monte Carlo, e questi non apportano un’accuratezza superiore. Di nuovo, non so come siano stati raccolti quei numeri, ma la realtà è che non rientrano nemmeno nel campo di ciò che possa veramente migliorare l’accuratezza delle previsioni.

Conor Doherty: Ma ammettiamo che ci sia un altro punto da considerare, ovvero: una maggiore accuratezza porta necessariamente a un miglior processo di [decision-making]? C’è un uso strumentale e poi c’è ciò che si vuole realmente ottenere—l’obiettivo, lo scopo.

Joannes Vermorel: Sì. Se diciamo che ciò che vogliamo sono decisioni migliori con un ritorno sugli investimenti più alto, allora concettualmente il digital twin potrebbe dire: se ho una policy A, la faccio girare attraverso il mio digital twin, valuto il ritorno sull’investimento; poi ho una policy B, faccio la stessa cosa, e sceglierò la policy che governa la mia decisione e che mi garantisce un tasso di ritorno superiore. Concettualmente, va bene—perché no?

Ma ancora, tutto questo dipende dal fatto che il tuo digital twin ti stia fornendo una valutazione economica corretta. Quindi questo problema di accuratezza si traduce in termini di denaro: hai un tasso di ritorno per la policy A, un tasso di ritorno per la policy B. Ma ancora: il tuo digital twin possiede qualche forma di correttezza? Perché dovresti fidarti di lui? È una domanda molto complicata.

Possiamo tornare a SimCity 2000 e Parigi. Posso far progredire il gioco con diversi livelli di tassazione per la città—ce l’hanno nel gioco. Ma questo strumento mi dirà qualcosa di molto accurato riguardo alla città di Parigi? Penso che sarebbe ovviamente completamente folle pensare che un videogioco possa essere usato per modellare accuratamente l’evoluzione di una metropoli reale. Questo è lo stesso tipo di problema che ho con quei digital twin per supply chain. A meno che non aggiungi molte cose, quello che ottieni è semplicemente un pensiero illusorio.

Sì, sarebbe davvero bello se avessimo qualcosa che faccia tutto ciò in modo molto accurato. Se mi dici che questa simulazione Monte Carlo è qualcosa di rivoluzionario che renderà possibile tutto ciò—non lo credo davvero. Al massimo è un piccolo ingrediente: super semplice. Sarebbe un po’ come dire: “I computer saranno coinvolti.” Sì, probabilmente. È una buona idea coinvolgere i computer, proprio come avere un simulatore Monte Carlo è una bella tecnica. È un ingrediente minuscolo; non potrei non esser d’accordo. È semplicemente molto, molto superficiale. È un po’ come dire: “Sarebbe meglio usare il metallo per un’auto.” Certamente il metallo sarebbe coinvolto, ma non ti farà ottenere un’auto.

Conor Doherty: Non voglio dilungarmi troppo su questo perché ci sono domande dal pubblico e voglio anche parlare di alcune cose menzionate su LinkedIn, ma prima di procedere, un’ultima domanda, direi, di carattere tecnico. Una delle ragioni per cui le persone amano i digital twin—e sono così popolari—è che vengono esaltati, vengono commercializzati come un modo per affrontare la volatilità e confrontarsi con l’incertezza. Ora io so che per noi di Lokad, e per molti altri professionisti, la previsione probabilistica sarà il modo per farlo. Quindi, a un livello elevato, quali sono le limitazioni? In tua stima, come colma la previsione probabilistica le lacune lasciate dal digital twin?

Joannes Vermorel: Per prima cosa, un simulatore Monte Carlo alla scala della tua supply chain è in effetti nient’altro che un modello di previsione probabilistica. È letteralmente questo. Quando diciamo previsione probabilistica, non siamo molto specifici su quali modelli sottostanti siano effettivamente usati per questo scopo. Nella lezione fornisco una serie di esempi su come costruire tali modelli. Ma quando si dice semplicemente “previsione probabilistica”, non si dice nulla riguardo al modello stesso.

Puoi costruire il tuo modello di previsione probabilistica con un simulatore Monte Carlo. Lasci che la simulazione venga eseguita, raccogli le distribuzioni di probabilità empiriche, e se esegui le simulazioni migliaia di volte, otterrai dei bei istogrammi multidimensionali che ti forniranno le distribuzioni di probabilità; ed ecco la tua previsione probabilistica. Quindi c’è una dualità tra un simulatore Monte Carlo e una previsione probabilistica. Dalle probabilità, puoi generare deviazioni—così ottieni quei comportamenti stocastici. Ma se hai i comportamenti stocastici, puoi eseguirli e ottenere le distribuzioni di probabilità. Fondamentalmente è la stessa cosa.

Tuttavia, c’è un aspetto chiave: non appena inizi a considerare il tuo simulatore Monte Carlo come un forecasting engine probabilistico, puoi valutarne l’accuratezza—il che è anche molto importante e che trovo estremamente carente nei fornitori che promuovono i digital twin. Non menzionano nemmeno il fatto che ciò che possiedono è un forecasting engine probabilistico, e pertanto deve essere valutato in termini di accuratezza con metriche rilevanti per la previsione probabilistica.

Conor Doherty: Ok. So che potremmo parlarne all’infinito, ma ancora, l’argomento come pubblicizzato era specificamente i digital twin. Qualche giorno fa hai condotto un sondaggio su LinkedIn in cui hai chiesto al tuo pubblico, “Quali sono i maggiori ostacoli per i digital twin?” perché molte delle persone che stanno guardando, e che lo vedranno in seguito, sono aziende che stanno considerando l’adozione di questa tecnologia o che l’hanno già adottata.

Ora, in quel sondaggio, il 52% degli intervistati ha affermato che il maggiore ostacolo era rappresentato da dati disordinati o incompleti. Prima di tutto—e questo è qualcosa che ricordo tu avessi detto qualche anno fa—considerando le dimensioni delle aziende che potrebbero adottare un digital twin, stiamo parlando di aziende molto grandi; presumibilmente dispongono di costosi e affidabili ERPs. Quindi la domanda diventa: in che modo dati disordinati o incompleti rappresentano un ostacolo per qualcosa che hai detto essere piuttosto semplice da implementare?

Joannes Vermorel: Qui, se definisci per dati mancanti i comportamenti—quello che caratterizza il comportamento di tutte quelle entità—direi di sì. Ma non c’era mai, penso, l’aspettativa di trovare in un ERP i parametri che potrebbero caratterizzare il comportamento di uno qualsiasi dei tuoi clienti, per esempio. Quindi non credo che sia questo ciò che le persone intendano—senza dubbio.

La mia opinione è che i dati siano sempre il capro espiatorio. Quando la tecnologia è super superficiale e non consegna ciò che era stato promesso, invariabilmente i cattivi dati diventano il capro espiatorio. Ciò non combacia affatto con l’esperienza che abbiamo a Lokad. La mia esperienza è che le aziende con oltre un miliardo di dollari o euro di fatturato annuo hanno dati eccellenti. Sanno quasi esattamente cosa stanno vendendo, cosa stanno acquistando e cosa hanno in magazzino. Sì, ci sono errori amministrativi qua e là, ma parliamo di errori dell’ordine dello 0,1% per errori di questo tipo.

In generale, per quanto riguarda l’accuratezza dei dati, essa è perfetta. L’intero flusso della merce—dall’acquisizione, trasporto, trasformazione e distribuzione—è noto con quasi certezza. La qualità di questi dati è molto elevata. Sì, altri dati possono essere un po’ più sfocati, specialmente se si parla di piani promozionali o simili, ma la storia transazionale di base è eccellente. Tecnicamente, è l’unica cosa di cui hai veramente bisogno per costruire un simulatore. Avresti questi sistemi che evolvono nel tempo, generando transazioni, e il tuo digital twin dovrebbe essere in grado di fungere da specchio per proiettare nel futuro e prevedere lo stato futuro dei tuoi sistemi.

Ma non lo sono. Questo è il problema. Secondo loro, non lo sono, e poi si dà la colpa ai dati. Ogni volta che sento quei lamenti riguardo ai problemi dei dati, ciò che sento è una tecnologia inadeguata che essenzialmente generava spazzatura, e la gente dice: “Oh, l’output è spazzatura”, ma deve essere perché l’input è spazzatura—il problema GIGO, spazzatura entra, spazzatura esce. Ma cosa succede se l’input è perfetto? La mia opinione è che l’input sia del tutto perfetto, praticamente—e lo è stato per gli ultimi due decenni—per la stragrande maggioranza delle grandi aziende.

Questo non significa che non ci siano sfide riguardo ai dati. Una delle sfide principali è che, guardando un ERP, ci sono 10.000 tabelle e ogni tabella ha circa 50 campi. Questa è una sfida enorme. Ma ciò non significa che i dati contenuti siano spazzatura. Rappresenta semplicemente il fatto che i tuoi sistemi aziendali non sono stati progettati per semplificare la vita di un Supply Chain Scientist, al fine di progettare il tuo simulatore Monte Carlo. Questo è un problema completamente diverso.

Conor Doherty: A proposito di problemi, un altro problema citato dal 21% degli intervistati era la modellazione fragile o difettosa. In precedenza avevi detto che l’installazione di questo non era particolarmente complicata—è il tipo di cosa che potresti consegnare a uno studente del primo anno di informatica. Quindi, ancora, torno alla domanda: se hai aziende multimiliardarie, e un esercizio che è un processo molto semplice, perché un quinto dei rispondenti dice che il problema è la modellazione?

Joannes Vermorel: I simulatori Monte Carlo sono concettualmente super semplici, e in termini di implementazione, estremamente diretti. Tuttavia, molto presto ti troverai ad affrontare problemi di performance basilari. Lascia che ti spieghi. Di quanti SKU stiamo parlando? Un milione—più o meno per un’azienda che supera il miliardo. Diciamo un milione di SKU.

Poi, quanti cicli CPU ci vogliono per simulare un SKU solo per il comportamento di cui stiamo parlando? Diciamo almeno 10 cicli CPU, e saremmo super efficienti se lo dicessimo. Quindi, quanti giorni? Supponiamo di avere un simulatore che esegue una simulazione per un giorno alla volta—100 giorni. Quindi stiamo parlando di 1 milione per 1.000—un miliardo di operazioni CPU—per simulare 100 giorni, a grandi linee.

Il problema è che è stocastico—è un simulatore stocastico, discreto, micro-analitico—quindi devi ripetere le esecuzioni. Quante volte devi far girare la simulazione affinché tu possa ottenere statistiche almeno ragionevolmente affidabili? A causa del problema di risoluzione, è necessario ripetere almeno mille volte. Quindi ora siamo a mille miliardi di operazioni. Non è un problema con i computer moderni, a meno che non faccia qualcosa di veramente sofisticato con il computer e inizi a fare parallelizzazione e simili. Stiamo parlando di circa 20 minuti di calcolo; ci sono tante soluzioni per parallelizzare tutto ciò, ma le persone che usano un simulatore semplice e veloce non faranno tutto ciò. Quindi assumiamo qualcosa di semplice—va bene. Venti minuti non sembrano troppo male—tranne…

…tranne che ora vuoi verificare delle opzioni. Per esempio, “Dovrei posizionare questa unità qui o questa unità lì?” Ogni singola opzione che esplori, dovrai “pagarci” questo costo, perché eseguirai la simulazione per il tuo scenario base e poi proverai qualcosa e la eseguirai di nuovo. Se hai solo una preoccupazione a livello molto alto—come “E se il costo del capitale circolante cambia? Voglio solo conoscere l’output”—va bene: la esegui due volte e otterrai la differenza.

Ma se vuoi iniziare a chiederti, “Quante unità dovrei posizionare in ogni singola sede del negozio?” allora dovrai eseguire il tuo simulatore migliaia e migliaia di volte—una per ogni singola micro domanda a cui vuoi rispondere. Improvvisamente le persone si rendono conto, “Oh, 20 minuti sono così lenti. Devo far girare questo simulatore centinaia di migliaia di volte, possibilmente milioni—una per ogni SKU o qualcosa del genere.” E allora diventa un grosso problema. La soluzione diventa: questo approccio micro-analitico in cui simulavo tutto a livello di SKU—ah, diventa una seccatura. “Quindi passeremo a una simulazione a un livello molto più aggregato.”

Ma ora abbiamo un altro grosso problema, ovvero: tutto dipendeva dal fatto che i comportamenti per le unità di simulazione fossero corretti a livello di SKU. Era già difficile affermare che fosse semplice, che esistessero comportamenti evidenti applicabili. Se inizi ad aggregare a livello di DC, cosa ti fa pensare che potrai mai individuare le leggi corrette che governano il flusso in entrata e in uscita da un centro di distribuzione? Questo è un aspetto molto complesso della tua rete. Non c’è motivo di pensare che leggi semplicistiche regoleranno questo ambito. La stessa cosa vale se parliamo di un cliente in B2B—un cliente che ordina tonnellate di prodotti molto diversi in calendari differenti, ecc.

Quindi hai questo problema del simulatore. Il simulatore è facile a livello micro, ma molto rapidamente si presentano problemi di performance. Puoi riaggregare, ma se lo fai il problema di avere comportamenti accurati per il tuo simulatore si amplifica enormemente.

Conor Doherty: Penso che una parte chiave di ciò—nel caso sia la prima volta che la gente ci ascolta parlare—sia che, quando si parla di decisioni, le decisioni secondo il metodo Lokad non si limitano a “Beh, ho una unità; la mando lì o no.” Voglio dire, ci sono combinazioni per tutte queste decisioni. Potrei inviarne una lì o nessuna. Posso inviarne una lì e una lì o nessuna, o due lì e una lì, o liquidare, oppure posso aumentare il prezzo di una unità qui in questo posto. Quindi la prospettiva locale è incredibilmente granulare, nel caso non fosse chiaro quanto siamo granulari in questo contesto. È come al microscopio—così granulare.

E a proposito, la ragione per cui siamo così granulare è che, se torniamo a modellare quei comportamenti, se vogliamo avere fiducia nell’esito economico, dobbiamo analizzare al livello più basso. È l’unica area in cui possiamo effettivamente collegare quanto costi produrre qualcosa, quanto il cliente paga per una determinata unità, ecc.

Joannes Vermorel: Esattamente. Questa è la ragione per cui siamo al livello più basso. Il problema con le iniziative di digital twin è che molto rapidamente—con i loro simulatori Monte Carlo—si rendono conto di avere problemi di performance, e quindi passano direttamente a un livello di aggregazione più elevato che è più facile da calcolare. Ma allora il problema di avere quei comportamenti corretti diventa assolutamente enorme, e sì, hai un simulatore che è potenzialmente ampiamente impreciso. Non è nemmeno chiaro perché dovresti fidarti del simulatore in primo luogo, perché quei comportamenti che governano quelle entità sono interamente inventati.

Conor Doherty: Ancora, torneremo su questo argomento in un’altra conferenza sul valore delle decisioni—ne abbiamo parlato recentemente con Adam Dejans Jr e Warren Powell. Chiunque voglia saperne di più, controlli il video più recente qui. Continuando: un altro ostacolo chiave all’adozione menzionato dal tuo pubblico è stato il change management. Quella è una questione che tipicamente emerge per praticamente qualsiasi tipo di tecnologia. Ma quando parliamo di qualcosa—hai usato un’immagine speculare—l’hai descritta essenzialmente come, se funziona bene, hai un’immagine speculare di ciò che già possiedi. Quindi la domanda è: perché un’immagine speculare di uno stato preesistente richiederebbe un ampio change management?

Joannes Vermorel: Se avessi—e sfido davvero che le aziende che promuovono queste tecnologie lo facciano—qualcosa che sia un predittore ad alta dimensionalità dello stato futuro della tua supply chain, che è ispirazionalmente ciò a cui aspirano quei digital twins, la cosa interessante è che se il processo è eseguito end-to-end puoi—non esistono più silos. Puoi letteralmente simulare l’effetto di ogni singola modifica di policy da applicare in ogni silo, e poi ottenere il tasso di rendimento per l’intera azienda. È molto attraente. Non lo nego. Lokad è decisamente sulla stessa strada.

Ritengo, inoltre, che—e questo richiede una notevole gestione del cambiamento—poiché se hai una tecnologia che ti permette di bypassare tutti i silos dell’azienda, essa creerà sfide ovunque. All’improvviso ti renderai conto che la politica adottata, ad esempio, da questa divisione è in realtà dannosa per l’azienda nel suo complesso. Magari migliora gli indicatori KPI di quella divisione, ma a spese della performance complessiva. Quindi sì, ci si può aspettare naturalmente che il cambiamento e la resistenza siano molto forti. Quella parte, a mio avviso, è ragionevole.

Conor Doherty: Joannes, abbiamo parlato per circa 35 minuti, credo, e ci sono effettivamente diverse domande a cui rispondere. Tra un attimo passerò alle domande del pubblico. Per favore, fate le vostre domande prima che terminiamo. Ma, come pensiero conclusivo per questa sezione—dato tutto ciò di cui abbiamo discusso—qual è il tuo consiglio finale per i responsabili della supply chain e per i dirigenti che stanno adottando o stanno considerando di adottare questa tecnologia?

Joannes Vermorel: È necessario dare un serio sguardo a ciò che c’è sotto il cofano. Il mio parere è—proprio come nel caso del “demand sensing”, e di altri buzzword che circolano nei circoli della supply chain—che, penso, nel demand sensing non ci sia nulla; mentre, nel caso dei digital twins, nella maggior parte delle situazioni c’è un pizzico di qualcosa: è semplicemente un simulatore Monte Carlo. Ma devi davvero mettere in discussione ciò che avviene dietro le quinte.

Sì, le persone possono costruire ogni sorta di interfacce utente eleganti su questo. Possono avere grafici sofisticati. Se inseriscono una mappa, puoi avere una mappa animata e così via. Quello è vendere un sogno. Devi davvero verificare cosa c’è dentro. Applica la mechanical sympathy: dovresti chiedere al tuo fornitore, “Per favore, spiega perché questa cosa funzionerà.” E non confondere l’intento. La gente dice, “Questo ottimizza quello.” No, aspetta. Stai ottimizzando il profitto—l’ottimizzazione è l’outcome. Non ti sto chiedendo dell’outcome. Mi stai vendendo qualcosa di molto positivo per l’azienda, ma spiegami come viene realizzato numericamente.

Indaga. Se alla fine scopri che si tratta solo di regole hard-coded applicate in sequenza per questo simulatore Monte Carlo, allora l’imperatore non ha vestiti. È semplicemente molto, molto superficiale.

Conor Doherty: Per concludere il tuo discorso: ho detto all’inizio che questa è una conversazione che hai avuto prima del mio arrivo qui. Già ad agosto 2022, su questo argomento, hai detto, e cito, “La mia percezione sui digital twins è che siano solo uno di quei buzzword. Sembrano nient’altro che un simulatore glorificato.” Quindi, in chiusura, negli ultimi tre anni, sostieni ancora quelle parole?

Joannes Vermorel: Poiché si tratta dell’intento—“digital twin”—non ho visto nessun fornitore che abbia proposto qualcosa di veramente sostanziale sotto il profilo tecnologico. Non metto in discussione l’intento. Se domani qualcuno venisse e dicesse, “Ho un digital twin, ma invece di realizzare un semplice simulatore Monte Carlo da studente del primo anno di informatica, ho questa straordinaria nuova tecnica, e ti offro il blueprint di questo approccio incredibile; è molto sofisticato, e funziona in modi infinitamente migliori rispetto a questo ingenuo simulatore Monte Carlo,” risponderei, “Sì, assolutamente, forse è davvero rilevante.”

È proprio come se qualcuno dicesse “AGI è super buono,” e io rispondessi, “Sì, AGI è super buono. Ne hai uno?” Quindi, ancora una volta, non metto in discussione l’intento associato a ciò. Metto veramente in discussione il complesso di tecniche sottostanti. E, per ora, tre anni dopo, non ho ancora visto nessun fornitore presentare tecniche che io possa considerare straordinarie.

C’è qualche fornitore—e sarei molto interessato se il pubblico potesse suggerirne qualcuno—che direbbe, “Joannes, guarda queste tecniche veramente straordinarie; stanno spingendo l’avanguardia quando si tratta di simulazioni stocastiche”? Io direi: sono tutto orecchi. Non l’ho visto.

Conor Doherty: Questa è una sfida aperta. Se qualcuno ha qualcosa da condividere con Joannes, metteteci in contatto con lui e fatelo. Comunque, Joannes, passerò ora alle domande del pubblico. Ce ne sono alcune da affrontare. Leggerò—alcune sono piuttosto lunghe—quindi fate attenzione.

Da Philip: prendiamo ad esempio l’incidente del Canale di Suez. Supponiamo che il mio modello stimi un lead time di un mese per spedire merci dall’Australia alla Francia, considerando le condizioni di traffico normali. E se una nave bloccasse inaspettatamente il canale come accaduto in passato? Il modello non sarebbe in grado di prevedere tale interruzione, e io subirei seri ritardi e disagi di conseguenza. Domanda: come gestiamo tali eventi imprevedibili nella modellazione della supply chain?

Joannes Vermorel: È un’ottima domanda. Qui, infatti, il simulatore Monte Carlo offre un’iniziativa che non è affatto male, ed è lo stesso approccio che utilizza Lokad. Si tratta di un approccio programmatico. Il simulatore Monte Carlo è fondamentalmente un paradigma programmatico: implementi, in un linguaggio di programmazione relativamente generale, le regole che caratterizzano i comportamenti.

Da Lokad, il metodo consiste nel fatto che una grande parte dei comportamenti viene appresa dai dati storici. Ma poiché si tratta di un programma, puoi interferire con esso e introdurre un’interferenza, intenzionale e programmata. Perché è necessario? Perché devi essere davvero sicuro di aumentare selettivamente i lead time—i lead time previsti—forniti ai fornitori che subiranno il problema in questo canale.

Ad esempio, se hai fornitori in Asia che spediscono le merci via aerea, non vorrai aumentare il loro lead time. Quindi devi stare molto attento, e magari verificare nei dati storici chi erano i fornitori che avevano un lead time corrispondente a una spedizione via nave—oppure possiedi già questa informazione—e poi puoi aggiungere programmaticamente questo incentivo extra. Credo che adottare un approccio programmatico qui sia una scelta vincente. Per quanto riguarda il digital twin, ritengo che stiano affrontando il problema dalla prospettiva corretta, ovvero attraverso lenti programmatiche, proprio come fa Lokad. Su questo fronte, è positivo. La situazione è in effetti più chiara rispetto ad approcci alternativi non programmatici che si limitano ad avere menù e pulsanti per coprire ogni possibile situazione. Se hai accesso a un linguaggio di programmazione al cuore del tuo modello, potrai sempre implementare regole personalizzate per gestire eventi imprevisti.

Conor Doherty: Grazie. Proseguo— da Manuel: “In teoria questa tecnologia, i digital twins, potrebbe avere un impatto notevole sul supporto decisionale nella supply chain. Cosa ne pensi dell’evoluzione di questa tecnologia e del raggiungimento del suo potenziale?” Credo che ne abbiamo già parlato in parte.

Joannes Vermorel: Come direzione ispiratrice, l’idea di avere una modellizzazione end-to-end della supply chain è grandiosa. Lokad è anch’esso su questa strada. Quali sono gli ingredienti chiave? Ce ne sono molti: differentiable programming è uno di questi; l’algebra delle variabili casuali è un altro; l’algebra relazionale lo è pure. Hai tantissimi ingredienti.

L’idea di avere simulatori Monte Carlo—a proposito, ad esempio, Lokad ha anche componenti Monte Carlo—apre la porta a cose molto interessanti da esplorare. Se hai comportamenti casuali—intenzionalmente casuali—parte di questo processo Monte Carlo, si crea un problema molto sottile in termini di debugabilità. Esegui il programma: va in crash—ed è un problema. Lo esegui di nuovo: non va in crash—e questo è peggio, perché riscontri un bug che appare intermittentemente, e quando cerchi di analizzarlo nel dettaglio, scompare. Da Lokad, chiamiamo questi problemi “Heisenbugs.” È un bug che compare solo intermittentemente; quando lo osservi da vicino, sparisce.

Questo è un difetto massiccio della classica e semplicistica concezione del simulatore Monte Carlo. È qualcosa che la finanza ha incontrato agli inizi degli anni ‘90. Quello che vuoi è una pseudo-casualità e, in effetti, qualcosa di completamente deterministico, anche se stai eseguendo una simulazione Monte Carlo. Ci vogliono degli accorgimenti piuttosto ingegnosi. Inoltre, vuoi che questo determinismo regga anche nel computing distribuito, in modo che l’intero sistema venga eseguito su molte CPU e molte macchine—perché, come ho sottolineato, se hai una singola CPU, single-threaded, incorrerai rapidamente in problemi di prestazioni. Nessun problema: puoi scalare su molte CPU e macchine. Ma ciò richiede strumenti in cui, anche in presenza di bug o crash, l’intero sistema rimanga completamente deterministico.

La mia opinione è che ci siano moltissime cose da ingegnerizzare per realizzare quei digital twins che i fornitori possono proporre. Spero che Lokad ne stia proponendo parecchie. Quello che sto dicendo—il punto cruciale della mia critica—è che le persone che si pubblicizzano con questo termine, questo buzzword, non offrono molta sostanza. È estremamente superficiale, e quando scruti ciò che c’è dietro—chiedi una demo—vedi solo una simulazione Monte Carlo molto semplicistica e ingenua, che non sarà in grado di fornire questo genere di prestazioni.

Conor Doherty: Transizione perfetta alla terza domanda, grazie. Da Shashank—perdonami se lo pronuncio male: “Joannes, qual è la tua opinione sul simulatore Monte Carlo rispetto ai modelli stocastici agentici nelle reti della supply chain?”

Joannes Vermorel: Ci sono diversi punti di osservazione. Il Monte Carlo è uno strumento molto utile; è un trucco numerico. È estremamente utile—proprio come l’algebra lineare, è un trucco di base, fondamentale. Di per sé, è molto funzionale. Ora, in un simulatore Monte Carlo, tutta l’intelligenza risiede nei comportamenti che simuli, perché essenzialmente un simulatore Monte Carlo funziona così: ho un milione di elementi; prendo l’elemento uno; applico il mio comportamento; ottengo una deviazione—un comportamento non deterministico—quindi ricevo una devianza in output dall’elemento uno. Poi ripeto per l’elemento due, tre, ecc., e continuo per ogni periodo.

I particolari sono proprio quei comportamenti, ed è davvero, davvero complicato. Il vantaggio del trucco numerico Monte Carlo è che si integra piuttosto bene nel mondo molto quantitativo e ad alta dimensionalità della supply chain. Se parliamo di IA agentica—ovvero, per essere specifici, degli LLM—gli LLM, invece, trattano sequenze di simboli. Un LLM—un large language model—è una macchina in grado di prevedere sequenze future di simboli, chiamati token.

In termini di corrispondenza con i dati che possiedi, la situazione non è propriamente chiara. Un LLM non rappresenta esattamente un abbinamento ovvio per il tuo sistema di supply chain. La mia opinione è che, nello scenario futuro delle tecnologie per la supply chain, i simulatori Monte Carlo saranno ancora presenti tra 10 anni? Sì, perché rappresentano un blocco costitutivo fondamentale. È come dire, “Hai delle radici quadrate nei tuoi sistemi?” Sì. L’IA agentica, come gli LLM—penso che abbiano il loro posto, ma il loro ruolo potrebbe non essere nella valutazione quantitativa della supply chain. Il loro ruolo è più periferico, dove si deve interagire con clienti, fornitori, o potenzialmente anche terze parti, e dove avvengono conversazioni basate su testo. È un modo per introdurre alcuni dati o per completare interazioni, ma non rappresenta il nocciolo dell’ottimizzazione.

Conor Doherty: Grazie. Passo a Tao: “A tuo parere, il problema reale dei digital twins è che gli strumenti attualmente utilizzati per simulare la supply chain siano difettosi, oppure il giusto strumento per l’ottimizzazione della supply chain potrebbe non richiedere affatto un digital twin?”

Joannes Vermorel: È esattamente per la prima ragione. Quegli strumenti sono difettosi—e in un modo molto specifico. Si tratta di uno strumento estremamente superficiale e facile da implementare. La gente tende a pensare che, nel mondo dell’enterprise software, esista la tentazione: non appena concludi un accordo col board, con un CEO, il prezzo sarà molto elevato—anche se ciò che vendi è sostanzialmente nulla. Può sembrare strano, ma nel software enterprise venderai qualcosa a oltre $100,000 all’anno, praticamente indipendentemente da ciò che stai effettivamente vendendo.

Quindi esiste questo flusso continuo di attori che entrano nel mercato e dicono, “Guarda, ho questa cosa, e se riesco a creare abbastanza entusiasmo intorno ad essa, alcune aziende vi pagheranno.” Alla loro scala è una goccia nel mare. Se sei un’azienda da oltre un miliardo e paghi $100,000 all’anno per un gadget, non è un grosso problema; non metterà a rischio la tua redditività. Di conseguenza, i CEO e i board—i dirigenti C-level in generale—non hanno necessariamente molto tempo da dedicare ad approfondire esattamente ciò che stanno acquistando, soprattutto se il prezzo non è esorbitante. Per il livello enterprise, $100,000 non è un prezzo astronomico. Per quel prezzo, il CEO di un’azienda da miliardi non passerà giorni a validare questi aspetti; sarà una decisione che dovrà essere presa molto rapidamente.

La conseguenza è che, purtroppo, ci sono molti attori che propongono tecnologie molto semplici—super superficiali—ma hanno padroneggiato l’arte dell’impacchettamento. Hai il tuo simulatore Monte Carlo—francamente, è un niente—ma viene presentato con un packaging elegante. Poi inseriscono, proprio come nella definizione che abbiamo ricevuto, una descrizione tipo, “Chi non vorrebbe avere qualcosa che ottimizzi ciocchè e quelciocchè, e migliori ciocchè e quelciocchè, per la produzione e tutto il resto?” Sì. “Qual è il prezzo di questo widget che rende migliore l’intera mia azienda?” “Determinato a circa $100,000.” “Va bene, è super economico. Proviamolo.”

Ma il mio messaggio è: indaga su ciò che c’è sotto il cofano. È veramente sostanza? Il packaging non basta. Quello che vedo è un modello: il digital twin è arrivato con un packaging. Una volta che hai visto un altro fornitore con un package, replicare quel packaging diventa semplice, perché il packaging è letteralmente ciò che vedi dall’esterno. Quello che c’è all’interno—se si tratta solo di un simulatore Monte Carlo—puoi assumere un ingegnere del software e questa cosa verrà implementata in pochi giorni.

Tutti questi ingredienti insieme creano la tentazione di andare sul mercato con il pacchetto giusto, di proporre ai dirigenti a tutti i livelli e, se hai abbastanza fortuna, concluderai una serie di affari—ed ecco, hai un business. Sto solo dicendo che questo è tipicamente il genere di anti-patterns che osservo nel mondo del software aziendale.

Conor Doherty: Grazie. E Joannes, questa è l’ultima domanda—sento di poter indovinare la risposta, ma viene da Murthy: “Come possono i gemelli digitali evolversi da strumenti di monitoraggio reattivi ad agenti proattivi nel processo decisionale all’interno di ecosistemi aziendali reali?”

Joannes Vermorel: Innanzitutto, in questa definizione e nella presentazione tecnica che ho appena illustrato, cosa rende il gemello digitale reattivo anziché proattivo? Concettualmente, nulla. Perché non utilizzeresti questo simulatore—super dettagliato, end-to-end—per sfidare in modo proattivo ogni singola politica che stai per adottare per la tua supply chain? Ovviamente, questo strumento è pensato per essere proattivo.

Quindi, se il modo in cui viene utilizzato nella pratica non è proattivo, dobbiamo chiederci perché. Su carta, un simulatore Monte Carlo: hai qualcosa di ragionevolmente accurato e rappresentativo della tua supply chain e del suo stato futuro; puoi—poiché è programmabile—iniettare ogni tipo di politica al suo interno. Fantastico. Ciò significa che puoi mettere in discussione tutto; ovviamente, è destinato ad essere proattivo.

Ma non lo è. Perché? Analizza da un punto di vista software: cosa stanno facendo, come è implementato? Questa analisi ti darà la risposta. La risposta è: torniamo a un milione di SKU, 10 cicli CPU, 100 giorni, ecc. Finisci per dire: sì, questo strumento può offrirti una simulazione di ciò che accadrà, ma a meno che tu non compia sforzi ingegneristici sostanziali—cosa che quei fornitori non fanno—otterrai una risposta ogni, diciamo, 20 minuti, o addirittura ogni ora se non è implementato in maniera ottimale.

Improvvisamente ti rendi conto di avere un problema, perché come puoi guidare qualcosa in avanti quando hai questo tipo di problema prestazionale? Non sto nemmeno parlando del problema dell’accuratezza della modellazione—solo delle prestazioni di base in termini di risorse di calcolo che devi impiegare. È un problema molto reale. Ecco perché le persone finiscono per adottare un approccio estremamente reattivo, perché si rendono conto che l’intero sistema è super lento. Fondamentalmente, stai cercando di fare milioni di domande al tuo sistema, ma se devi aspettare 20 minuti per ogni singola risposta, è incredibile—e devi porre quel milione di domande ogni giorno.

Finisci per avere problemi molto basilari. Se ri-aggregi i dati, improvvisamente non puoi porre domande davvero importanti, perché ti trovi ad un livello di aggregazione che non rispecchia più le decisioni che devi prendere, come: “Devo produrre questo? Devo spostare l’inventario lì? Dovrei aumentare il prezzo di questi prodotti?” Improvvisamente, se sei a un livello aggregato—per esempio, se vuoi ragionare sul pricing di una categoria di prodotti—non ha molto senso dire: “Aumenterò o diminuirò il prezzo per tutti i prodotti in questa categoria.” Probabilmente vorrai differenziare in base alle caratteristiche di ogni singolo prodotto. Ma ancora, questo contrasta con l’idea di aggregare tutto.

Conor Doherty: Come breve plug, so che tratti in modo approfondito il concetto di optionalità decisionale insito nel flusso dei beni fisici—la tua definizione di supply chain. Penso che ciò sia trattato nella Lezione 1.2, “Supply Chain in a Nutshell.”

Quella è letteralmente la prima—ok. Beh, guarda almeno le prime due, perché poi arrivi a “Quantitative Supply Chain in a Nutshell.” È davvero ottima—meglio di quanto si possa dire. Comunque, Joannes, siamo già arrivati a un’ora. Abbiamo esaurito le domande, e ora il tempo è finito. Come sempre, ti ringrazio moltissimo per essere stato con me e per le tue risposte. E a tutti gli altri, grazie per essere presenti. Grazie per le vostre domande. Se ancora non lo fate, seguite Lokad su LinkedIn, per favore. E se non siete connessi con noi, inviateci una richiesta di collegamento. Siamo sempre felici di discutere questioni di supply chain. E con questo, a tutti dico: tornate al lavoro.