00:00:00 La storia della fondazione di Lokad e i primi anni
00:02:31 Errate convinzioni sull’ottimizzazione della supply chain
00:04:31 Le teorie esistenti della supply chain non funzionavano
00:06:32 Il paradosso dei fallimenti nelle previsioni
00:08:33 Come “forecasting nothing” ha battuto i concorrenti
00:10:25 La sfida di rifiutare le idee consolidate
00:12:00 Rivolgersi verso la previsione probabilistica
00:14:07 L’importanza degli scenari di domanda estrema
00:16:32 La complessità dell’integrazione dei dati aziendali
00:20:55 Perché i modelli della supply chain su carta falliscono
00:27:30 Problemi di ingegneria nell’adozione dell’IA aziendale
00:35:00 L’impatto del COVID-19 sulle supply chain
00:42:49 I LLM sono basati sul testo, non matematici
00:50:25 L’evoluzione parallela dell’industria finanziaria
01:09:00 Domande e risposte e osservazioni finali
Riepilogo
Joannes Vermorel, CEO e Fondatore di Lokad, ha tenuto una conferenza in francese, condividendo il suo percorso nel Supply Chain management. Vermorel ha raccontato la fondazione di Lokad dopo la laurea all’École Normale Supérieure e il passaggio dalla bioinformatica alle sfide della supply chain. Ha discusso lo sviluppo di Envision, il linguaggio di programmazione di Lokad, e l’evoluzione dell’azienda dal 2007. Vermorel ha criticato le teorie tradizionali della supply chain, paragonandole all’astrologia, e ha sottolineato l’importanza di sfidare il consenso. Ha evidenziato il successo di Lokad con metodi probabilistici e l’impatto del COVID-19 sulla robotizzazione. Vermorel ha previsto l’obsolescenza dei ruoli tradizionali e ha incoraggiato gli studenti a guidare la rivoluzione del settore.
Sintesi Estesa
In una conferenza tenuta in francese agli studenti, Joannes Vermorel, CEO e Fondatore di Lokad, ha condiviso il suo percorso e le sue intuizioni sul mondo del Supply Chain management e sull’evoluzione della sua azienda. Vermorel ha iniziato presentandosi e raccontando le origini di Lokad, un’azienda fondata subito dopo la laurea all’École Normale Supérieure. Inizialmente, Vermorel ha tentato di intraprendere una tesi in bioinformatica, ma ben presto si rese conto che il campo era già saturo di talenti. Per caso, si è imbattuto nelle sfide del Supply Chain management, che divennero il suo nuovo obiettivo.
Vermorel ha espresso la sua sorpresa e gioia nel vedere studenti di Centrale utilizzare Envision, un linguaggio di programmazione che ha creato per l’ottimizzazione della supply chain. Ha raccontato lo sviluppo di Envision, osservando che il primo compilatore che aveva scritto fu rapidamente sostituito da una versione superiore creata da Victor Nicolet, CTO di Lokad. Da allora, Envision è notevolmente evoluto, e l’azienda è ormai sul punto di rilasciare la versione 6.
Il percorso di Lokad è iniziato nel 2007, con l’azienda ufficialmente fondata nel 2008. Tuttavia, Envision non fu introdotto fino al 2013, a cinque anni dall’esistenza di Lokad. Vermorel ha spiegato che la decisione di creare un nuovo linguaggio di programmazione arrivò dopo aver esaurito tutte le altre alternative. Inizialmente, credeva che la supply chain fosse un campo ben consolidato, con decenni di letteratura e numerosi concorrenti come SAP, Oracle, IBM e Microsoft. Pensava che la chiave del successo sarebbe stata il riformattare le teorie esistenti della supply chain in applicazioni web, sfruttando il passaggio da applicazioni client-server a soluzioni basate sul cloud.
Nonostante la sua iniziale fiducia, Vermorel scoprì presto che le teorie e i modelli consolidati non funzionavano come previsto. Raccontò un’esperienza particolarmente assurda nel 2011, in cui Lokad vinse un benchmark presentando previsioni a zero, superando i concorrenti del 20% in termini di accuratezza. Questa esperienza spinse Vermorel a mettere in discussione la validità delle teorie tradizionali della supply chain, paragonandole all’astrologia piuttosto che all’astronomia.
Vermorel ha sottolineato l’importanza di sfidare il consenso nella scienza, osservando che la storia è piena di esempi di credenze ampiamente accettate ma in definitiva errate. Concluse che, sebbene la supply chain stessa sia un campo legittimo, le teorie classiche che la sostengono erano difettose. Questa constatazione lo spinse ad esplorare approcci alternativi, come previsioni distorte e predizioni per quantili, che si sono rivelati più efficaci.
L’approccio di Lokad si è evoluto per abbracciare metodi probabilistici e programmatici, allontanandosi dai modelli tradizionali che non riuscivano ad affrontare le complessità dei problemi reali della supply chain. Vermorel ha evidenziato l’importanza di disporre di un linguaggio di programmazione robusto, studiato per queste sfide, criticando l’uso di linguaggi di uso generale come Python, che spesso portavano a iniziative fallimentari a causa di vari problemi tecnici.
La conferenza ha toccato anche l’impatto della pandemia di COVID-19, che ha accelerato la robotizzazione delle supply chain. Vermorel ha notato che le soluzioni di Lokad si sono dimostrate efficaci su larga scala, gestendo scorte per miliardi di euro con un intervento umano minimo. Questo cambiamento rispecchia la transizione nel settore finanziario, dove il trading è diventato prevalentemente algoritmico.
Vermorel ha discusso il futuro del Supply Chain management, prevedendo che i ruoli tradizionali dei gestori di inventario e dei demand planners sarebbero diventati obsoleti man mano che più aziende adottano processi di decision-making automatizzati. Ha incoraggiato gli studenti a essere proattivi nel guidare questa rivoluzione anziché limitarvisi ad osservarla.
In risposta alle domande degli studenti, Vermorel ha spiegato che le aziende con un forte focus tecnologico potrebbero internalizzare le soluzioni di Lokad, mentre altre probabilmente continueranno ad esternalizzare questi servizi. Ha inoltre evidenziato le limitazioni dei modelli di linguaggio di grandi dimensioni (LLM) come ChatGPT, sottolineando la loro mancanza di capacità di apprendimento e memoria.
Vermorel ha concluso riflettendo sull’irrazionalità dei mercati e sulla persistenza dei progetti falliti nell’industria della supply chain. Ha condiviso aneddoti di concorrenti che hanno raccolto ripetutamente ingenti fondi nonostante i fallimenti passati, evidenziando la natura caotica del mercato. Nonostante queste sfide, Vermorel ha espresso orgoglio per i successi di Lokad e per l’inaspettato trionfo di Envision tra gli studenti di istituzioni prestigiose come Centrale. Ha invitato gli studenti a considerare l’idea di unirsi a Lokad, sottolineando gli sforzi continui di reclutamento dell’azienda.
Trascrizione completa
Il discorso originale in francese è stato tradotto in inglese.
Joannes Vermorel: Permettetemi di presentarmi: sono Joannes Vermorel, fondatore di Lokad. Ho creato l’azienda quando ho terminato gli studi. Ero all’École Normale Supérieure, ho iniziato un dottorato in bioinformatica, ma alla fine, così tante persone facevano cose interessanti in bioinformatica che probabilmente non avevano bisogno di me. E per caso, mi sono imbattuto in questi problemi della supply chain. Sono molto felice di vedere che oggi avete utilizzato Envision. È davvero notevole trovarmi di fronte a studenti di Centrale a parlare di questo linguaggio. È qualcosa che non avrei mai immaginato quando ho creato Envision, circa dodici anni fa.
Ho scritto il primo compilatore di Envision, poi Victor Nicolet—CTO di Lokad—lo ha scartato e ha rapidamente scritto il secondo compilatore, che era molto migliore. E ora state sostanzialmente utilizzando la versione 5, mentre la versione 6 sta per essere rilasciata. Il linguaggio è evoluto molto. Ma ciò su cui avete lavorato—il pezzo che avete visto—non era affatto da dove era partita Lokad. In realtà, arrivò abbastanza tardi. Lokad è un progetto iniziato nel 2007 e formalmente costituito nel 2008, mentre Envision risale al 2013.
L’idea di creare un linguaggio è nata dopo aver esaurito tutte le altre alternative; non era il piano del fondatore visionario sin dall’inizio—semplicemente perché tutto il resto che avevamo provato era fallito.
Per darvi un’idea di ciò che è così sorprendente della supply chain: quando ho lanciato Lokad nel 2008, la mia visione era che la supply chain fosse un campo ben consolidato. Dopotutto, ci sono 60 o 70 anni di letteratura al riguardo, letteralmente milioni di articoli. Se digitate “supply chain management” su Amazon, ottenete—ho verificato—circa 10.000 libri attualmente disponibili sull’argomento. Nel corso dei decenni, ne sono stati pubblicati molti altri, ma quei 10.000 sono quelli ancora in vendita.
Quando ho iniziato, ho visto grandi concorrenti con nomi importanti: SAP, Oracle, IBM, persino Microsoft—operatori di primo piano nella supply chain. Se sommate il fatturato totale dei vostri concorrenti, si aggira intorno a mezzo trilione di dollari. Questo è significativo. La mia intuizione originale—completamente sbagliata, a quanto pare—era che avrei potuto prendere le teorie consolidate della supply chain e semplicemente riformattarle in un’app web. Era il 2008, e tutto il enterprise software stava passando dalle cosiddette app “thick client”, che si installano sul PC, alle app “thin client”, ovvero web app. Così c’era l’opportunità di ricostruire il software per la supply chain come un’app web, possibilmente con hosting cloud. Lokad si è spostata sul cloud molto presto. Questo potrebbe darci un vantaggio rispetto alle grandi aziende che utilizzano ancora sistemi client-based più vecchi e pesanti. E poiché esistono interi libri che spiegano come ottimizzare le supply chain—come il manuale del MIT, il manuale di Stanford, il manuale del Caltech—li ho letti, tutti quei volumi da 1000 pagine scritti da due o tre professori con tutte le equazioni.
Ho poi codificato quei metodi—e nulla ha funzionato. Curiosamente, ciò non ha impedito a Lokad di crescere o di acquisire clienti. Si potrebbe pensare che, per fare soldi come startup, sia necessario un prodotto che funzioni davvero, ma nel settore dell’enterprise software, si può vendere qualcosa che non funziona affatto e trovare comunque clienti. Può sembrare strano, ma è così. La realtà è che, se c’è un grosso problema che un’azienda vuole risolvere, c’è un budget per cercare di risolverlo. Questo budget potrebbe non essere enorme—soprattutto se il prodotto non funziona davvero—ma per una startup, quelle somme possono sembrare molto grandi. Se un gigante come Carrefour mette in palio 100.000 euro “solo per vedere”, per Carrefour non è nulla, ma per una piccola azienda è molto.
Quindi, sfruttando quella asimmetria, ho iniziato a tentare di implementare queste teorie standard della supply chain: previsioni time-series, safety stock, ottimizzazione del livello di servizio, ecc. Niente di tutto ciò ha funzionato; per nulla. Abbiamo avuto discussioni alquanto schizofreniche con i clienti: dicevano, “Devi aver codificato in modo errato la formula dello safety stock,” così ritornavamo, prendendo letteralmente i valori dalle tabelle dei manuali, ricontrollando i parametri—ed era esattamente come indicato. Quindi la teoria era implementata correttamente, ma il risultato era totale non-senso.
Penso che il culmine del non-senso sia arrivato nell’estate del 2011. Abbiamo partecipato a una grande richiesta di offerta (RFP) con mezza dozzina di fornitori di software, metà europei, metà americani. Lokad era tra gli europei. Il caso, se ricordo bene, riguardava circa dieci supermercati, con 5.000 SKU per supermercato, con la necessità di fare previsioni per alcuni giorni in anticipo, perché questi supermercati venivano riforniti forse due o tre volte alla settimana. Il cliente usava un criterio di errore di backtesting sui forecast giornalieri a livello di prodotto per ogni negozio—fondamentalmente l’errore assoluto tra previsione e reale. Lokad finì per vincere quel benchmark—con un’accuratezza migliore del 20%, schiacciando assolutamente la concorrenza. Il mio metodo segreto? Ho inviato zeri. Zeri per tutto. Grazie al mio “zero forecast,” ho anche battuto tutti gli altri in velocità di calcolo: restituire zeri è estremamente veloce. E ho ottenuto un’accuratezza del better forecasting del 20% superiore rispetto agli altri.
Ovviamente, era un non-senso totale. Ma se consideri l’approccio raccomandato da tutti i manuali della supply chain e il processo standard del cliente, il risultato fu un’assurdità totale. La conclusione a cui sono giunto fu piuttosto inquietante. Avevamo un’azienda redditizia e in crescita, ma ho dovuto rendermi conto che forse mi ero imbattuto in uno schema. Puoi iniziare qualcosa, fare soldi, ma è puro non-senso. Forse all’inizio sei semplicemente troppo inesperto per accorgertene. Ma una volta che te ne rendi conto, continui? Quando ti laurei e scopri che quello che stai facendo è non-senso, continui? Questo ha innescato profonde riflessioni. Potrebbe essere che la supply chain sia semplicemente astrologia—del tipo della divinazione, non dell’astronomia?
Alla fine, ho concluso che la supply chain come campo è reale, ma che la teoria standard della supply chain è fondamentalmente astrologia. Questo era il problema. È molto difficile accettare che 70 anni di ricerca, oltre un milione di articoli, migliaia di professori, possano tutti sbagliare. Immagina l’arroganza intellettuale necessaria. Se vedi quattro medici diversi, ognuno dei quali ti dice che hai la stessa diagnosi, a che punto dici che hanno tutti torto e tu hai ragione? Ma la scienza non funziona per consenso. Mille persone possono essere d’accordo su qualcosa e sbagliarsi comunque. La storia della scienza è piena di esempi: un consenso estremamente ampio su idee che si sono rivelate folli.
Così Lokad giunse alla conclusione dal benchmark: il metodo tradizionale era una follia. Dovevamo cercare qualcos’altro. La nostra grande svolta arrivò all’inizio del 2012, perseguendo previsioni con bias con ciò che è noto come quantile forecasts. A quel tempo, avevo clienti che impiegavano 50 persone a tempo pieno solo per rimuovere il bias. Così mi chiesero, “Perché diavolo vorresti una previsione con bias, dato che paghiamo persone per eliminarlo?” Rimasero piuttosto allarmati perché il nuovo metodo aggiungeva così tanto bias da non poterlo mai rimuovere manualmente. Ma se la chiamo “quantile forecasting”, suona più scientifico di “biased forecasting”. In realtà, però, una previsione quantile è solo una previsione con bias.
Abbiamo provato questo approccio con il nostro primo cliente e-commerce. In una notte siamo passati da risultati assurdi—come prevedere zero per tutto—a qualcosa di mediocre ma almeno in parte sensato. Potrebbe non sembrare straordinario, ma passare dall’assurdo totale alla mera mediocrità è stato un enorme miglioramento.
Questo ci ha quindi portato a rivedere tutte le assunzioni della supply chain presenti nei manuali—mettendo in discussione ogni fondamento, che si è rivelato molto instabile, praticamente errato. Il quantile forecasting è solo la versione semplificata di ciò. È uno strumento statistico che guarda specificamente agli estremi. Economicamente, nella supply chain, gli estremi sono dove si perde denaro: una domanda inaspettatamente alta che crea un stockout, una domanda inaspettatamente bassa che crea overstock, tempi di lead time inaspettatamente lunghi che rovinano i piani, ecc. Non è mai il centro della distribuzione a farti veramente male; sono le code. Una previsione quantile è uno strumento che si concentra su quegli estremi. Una versione migliorata è il forecasting probabilistico—che è su cui avete lavorato—dove si ottiene una distribuzione di probabilità completa. Nel 2012, abbiamo iniziato con le previsioni quantili perché era più semplice in termini di matematica, statistica e calcolo. Gestire una distribuzione di probabilità attraverso milioni di SKUs è molto più impegnativo che generare un singolo numero di previsione per SKU.
Nel frattempo, Envision—che era stato originariamente sviluppato per qualcosa di completamente diverso, un progetto interno in codice “Priceforge” per la determinazione dei prezzi—si è rivelato perfetto per affrontare il nuovo approccio. Prima di allora, l’idea di Lokad era di costruire un software standard per la supply chain con menu, pulsanti e opzioni, come è tipico nel software aziendale. Ma, dal punto di vista dell’editore del software, era un caos: man mano che aggiungi più funzionalità, il mapping dei dati dall’ambiente del cliente alle tue strutture diventa un incubo ingegneristico.
Perché? Perché le architetture dei dati dei clienti sono sempre uniche. L’ERP di un cliente potrebbe avere 10.000 tabelle, ognuna con 50 campi, molti dei quali non documentati e usati in modi insoliti. In realtà, potrebbero avere due o tre ERP, più un WMS, più una piattaforma e-commerce… L’ecosistema è complicato. Nessuna azienda ha le stesse definizioni di dati. Anche qualcosa apparentemente semplice come “order date” può avere 20 definizioni diverse: la data di creazione del record, la data in cui il cliente ha confermato l’ordine, la data in cui l’ordine è stato confermato da te, la data in cui il fornitore del pagamento lo ha autorizzato, la data in cui l’ordine è stato spedito, e così via. Moltiplica ciò per altre mille potenziali definizioni.
Se crei un software “classico” con definizioni fisse per prodotto, SKU, varianti, fornitore, località, e così via, quelle definizioni raramente combaciano con la realtà del cliente. Anche nel settore dell’abbigliamento, ad esempio, un’azienda potrebbe definire le varianti esclusivamente in base a colore e taglia, mentre un’altra potrebbe includere anche la composizione del tessuto. Oppure, nel settore alimentare, potresti avere “expiration date” intesa come il giorno in cui il prodotto non può assolutamente essere venduto, o il giorno in cui non può essere esposto in negozio. Ci sono infiniti dettagli.
Pertanto, le teorie standard della supply chain si sono rivelate inadeguate. Avevamo bisogno di qualcosa di nuovo: un approccio programmatico. Questo è un argomento di cui i manuali della supply chain non parlano mai. I modelli preconfezionati non aiutano perché il mondo reale non si adatta mai perfettamente a quegli schemi. C’è sempre qualcosa—come la quantità minima d’ordine, vincoli di scadenza, vincoli sugli orari di spedizione. I vincoli di ogni azienda sono unici. Così abbiamo capito che la soluzione è programmatica, non una formula statica. La domanda è quindi diventata: qual è il giusto paradigma di programmazione per la supply chain?
Nel 2012, la gente poteva dire, “Perché non usare semplicemente Python?” In effetti, a quei tempi era esattamente quello che facevano tutti i miei clienti e-commerce americani. Quasi ogni iniziativa di data science che ho visto allora falliva a causa di Python (o poteva essere Java, C# o, successivamente, Julia—lo stesso problema). Il modello era: in tre settimane un team di data science costruiva un prototipo impressionante per qualche problema della supply chain. Poi volevano metterlo in produzione, e un anno dopo era ancora in fase di sviluppo; il management perdeva la pazienza, cancellava il progetto, e basta.
Perché ha fallito? Morte per mille colpi: NullReferenceException, OutOfQuotaException, problemi di concorrenza, pacchetti incompatibili, violazioni di sicurezza, ransomware nel tuo ambiente, e così via. Nulla di tutto ciò è direttamente collegato al problema della supply chain in sé. Il problema fondamentale è che se usi un linguaggio di uso generale in un grande ambiente di produzione, la superficie di attacco ai problemi diventa enorme. Ad esempio, se il tuo codice può scrivere sul file system, puoi accidentalmente corrompere l’ambiente che lo ospita—facile da fare se stai gestendo gigabyte di dati in parallelo. Forse un file è bloccato da un processo, o un disco è pieno, e così via. Queste cose succedono inevitabilmente nel cuore della notte, senza che ci sia nessuno a rimediare sul momento. Poi, al mattino, il cliente è furioso perché si aspettava che il sistema terminasse le elaborazioni alle 2 del mattino, ma è andato in crash a mezzanotte.
Nei demo di data science di solito c’è qualcuno che controlla l’esecuzione dello script, così se va in crash lo aggiustano subito. Ma l’automazione della supply chain nel mondo reale deve funzionare ogni giorno senza supervisione. Anche i tempi di esecuzione possono variare da 20 minuti a due ore, e questo rompe la produzione. Questo era il problema nel 2012: queste iniziative di data science fallivano in produzione a causa della complessità intrinseca dei linguaggi di uso generale, non per la logica della supply chain.
Tutto ciò portò Lokad a rendersi conto che avevamo bisogno di un ambiente programmatico sicuro e sufficientemente specializzato da gestire operazioni quotidiane su larga scala senza una fragile supervisione. Inoltre, una volta riconosciuto che era necessario procedere anche con previsioni avanzate (probabilistiche, quantili, ecc.), Envision fu predisposto per gestire quei flussi di lavoro come cittadini di prima classe. Ad esempio, se desideri la programmazione differenziabile per il machine learning, in un linguaggio di uso generale devi incorporare un “mini-linguaggio” come PyTorch per questo scopo. Poi hai Python più un blocco di codice PyTorch, ed è facile commettere errori, perché il tuo codice PyTorch è essenzialmente una stringa non compilata. Lo stesso vale per il mescolare query SQL all’interno del codice Python. Sono tutte stringhe, così scopri gli errori solo a runtime. Envision, invece, può trattare queste funzionalità come caratteristiche integrate con controlli in fase di compilazione.
L’approccio di Lokad si è evoluto parallelamente ai progressi come il deep learning—dove non hai più solo una libreria di modelli preconfezionati, ma componi il tuo modello programmaticamente. TensorFlow è sostanzialmente un linguaggio per costruire grafi computazionali. Non sei vincolato a un “catalogo” di modelli; costruisci strutture. Envision può incorporare nativamente anche queste idee. Ad esempio, recentemente abbiamo lavorato all’ottimizzazione stocastica. Qualcuno sa cos’è? È l’ottimizzazione matematica di una funzione il cui esito è incerto—come decidere quante unità acquistare quando la domanda futura è sconosciuta. È una sfida classica della supply chain. Hai visto versioni più semplici con vincoli minimi, ma le aziende reali si trovano a dover gestire una miriade di vincoli: minimi d’ordine, fill rate dei container, vincoli di categoria o calendari complicati. Inoltre, la tua funzione costo/beneficio è incerta. Quindi questi sono concetti programmatici avanzati.
In definitiva, Envision ha continuato ad aggiungere funzionalità. Ad oggi siamo anche sulla soglia di un’altra rivoluzione: i large language models (LLMs). Probabilmente conoscete ChatGPT. Forse alcuni di voi lo usano per fare i compiti. (Non vi sto valutando, quindi potete ammetterlo!) O addirittura pagando per la versione pro. La parte interessante per noi è che Lokad ha una cultura della scrittura, alquanto insolita per un’azienda di supply chain. Facciamo affidamento sul testo a due livelli. Prima di tutto, abbiamo il codice di Envision, che codifica letteralmente “cosa” stiamo facendo. Non vogliamo un processo che generi ordini consigliati in Excel per poi essere modificati manualmente. Il nostro obiettivo è che i numeri finali vengano generati automaticamente senza interventi manuali. E se sono necessarie modifiche—a volte lo sono, almeno all’inizio—queste vengono registrate in un flusso di lavoro in modo da poter discutere con il cliente: “Perché hai modificato ciò che è stato generato? Cosa potremmo cambiare affinché le modifiche manuali non siano più necessarie?” Oppure, a volte, notiamo che le modifiche non sono state davvero utili, così possiamo incorporare quella conoscenza.
Poi abbiamo un secondo artefatto testuale, il JPM o Joint Process Manual, che spiega il “perché”. È il nostro documento di riferimento per le consegne e per fornire al cliente una visione d’insieme dell’iniziativa in linguaggio semplice—senza che debbano leggere direttamente il codice di Envision. Quindi abbiamo uno strato di codice che descrive il “cosa” e un livello documentale separato che spiega il “perché”.
Questo si adatta piuttosto bene agli LLM, perché gli LLM elaborano il testo. Non sono così bravi con dati numerici grezzi. Se inserisci una grande tabella in ChatGPT, non otterrai una regressione sensata. ChatGPT può solo generare un pezzo di codice Python che esegue la regressione. Gli LLM stessi sono solo enormi modelli di previsione del token successivo; non sono costruiti per l’aritmetica. Da qui le battute su ChatGPT che fallisce nella matematica di base. Ma se gli fornisci codice o istruzioni testuali, si comportano abbastanza bene nella manipolazione e generazione.
Quindi, ecco dove si colloca Lokad: abbiamo automazioni avanzate per la supply chain che possono funzionare per mesi senza alcuna intervento umano—qualcosa che è stato dimostrato durante i lockdown del 2020–2021, quando molti dei nostri clienti hanno mandato a casa i loro impiegati d’ufficio. Nel frattempo, la supply chain doveva comunque operare perché la forza lavoro operativa nei magazzini e sui camion era ancora attiva. Lokad funzionava già in larga parte in modalità remota, così i nostri supply chain scientists potevano continuare a lavorare da casa. Quello è stato il vero banco di prova: vedere come le nostre ricette funzionavano senza supervisione quotidiana. In alcuni casi, grandi clienti avevano letteralmente centinaia di pianificatori, manager o analisti che improvvisamente non c’erano, ma la loro supply chain doveva comunque operare.
E per noi, ha funzionato sorprendentemente bene. Nessuno dei nostri clienti ne ha subito le conseguenze—nessuno è sparito. Ci si chiede: se puoi far funzionare la tua supply chain per 12 o 14 mesi senza 500 impiegati d’ufficio, ti servono davvero tutti al ritorno? Questo era un esperimento che non avremmo mai potuto fare diversamente, dato che le aziende di solito temono di affidarsi completamente a un sistema automatizzato. Ma i lockdown li hanno costretti a puntare sull’automazione, dimostrando che possiamo gestire supply chain massive con interventi manuali minimi o addirittura assenti. Certo, continuiamo a discutere modi per migliorare le ricette numeriche; non significa zero collaborazione. Però non si vedono più grandi team che ogni giorno apportano modifiche in Excel a ciascun SKU in ogni negozio.
Quindi, se provo a immaginare dove sta andando il mondo della supply chain: per me assomiglia al cambiamento avvenuto nella finanza 20 anni fa, quando il trading divenne elettronico. I trader umani che una volta leggevano il giornale al mattino e decidevano a mano se comprare o vendere un titolo furono sostituiti dai quants con ampi portafogli automatizzati. Vedo la stessa trasformazione in arrivo per la supply chain, e credo che diventerà la prassi standard molto prima che tu vada in pensione—che sia dopo 61 anni di lavoro o come cambieranno le leggi. Continuerai a imbatterti in molte aziende legate a metodi più vecchi, ma quella rivoluzione è già in corso.
Attualmente, diversi dei nostri clienti lasciano che il sistema operi interamente da solo. Ad esempio, possiamo citare Cdiscount, un grande rivenditore e-commerce francese: gestiamo l’inventario dei loro negozi in modo totalmente automatico, senza interventi manuali. Questo non ferma le discussioni su come migliorare le ricette, ma l’approccio quotidiano “più o meno unità” è terminato. È finito nel 2020, e funziona ancora oggi.
Di conseguenza, penso che siamo alla fine di un’era, quella in cui esistono circa cinque milioni di persone in tutto il mondo il cui lavoro consiste nell’esaminare quotidianamente mille SKU in Excel per decidere se è necessario riapprovvigionarsi, produrre di più, riassegnare l’inventario, cambiare i prezzi, e così via. Tutti i tipi di posizioni lavorative—inventory manager, demand planner, supply planner, category manager, analista S&OP—si riducono alla stessa routine quotidiana: esaminare un blocco di SKU. Con budget elevati, potrebbero essere 100 SKU per persona; con budget minori, forse 5.000 SKU per persona. In ogni caso, credo che questo stia per finire.
Perché adesso? Perché per decenni nessuno è riuscito ad automatizzare tutte quelle decisioni. Ma una volta che un certo numero di aziende dimostrerà che è possibile, le altre seguiranno. Mantenere grandi team di pianificazione manuale è estremamente costoso, oltre a rendere difficile un cambiamento strategico quando bisogna riqualificare centinaia di pianificatori in più paesi, abituati per 20 anni alla stessa routine quotidiana su fogli di calcolo. Cambiare ciò è molto lento. Ma una volta che puoi operare in modo puramente programmatico, puoi reagire rapidamente.
Questo è ciò che ci aspetta: lo stesso cambiamento che abbiamo visto nel settore bancario. Prima c’erano persone che facevano trading manualmente tutto il giorno; ora è per lo più automatizzato. Vedo la stessa meccanizzazione in arrivo per la supply chain, e credo che diventerà la prassi standard molto prima che tu vada in pensione—sia che tu vada in pensione dopo 61 anni di lavoro o in base a come cambieranno le leggi. Continuerai a incontrare molte aziende legate a metodi più vecchi, ma quella rivoluzione è in atto.
Quindi il mio messaggio è che puoi essere un attore attivo di questo cambiamento oppure rimanere semplicemente un passeggero. Dato che siete studenti di Central, avete sicuramente il potenziale per essere protagonisti attivi e non solo osservatori.
Va bene, magari possiamo passare alle domande. Vi ho sottoposto ad un monologo di 50 minuti, quindi se avete domande su tutto questo, prego, fate pure.
Studente: Quindi significa che queste aziende diventeranno dipendenti da soluzioni come Lokad, oppure potranno sviluppare tecnologie simili internamente?
Joannes Vermorel: Entrambe le possibilità sono valide. Se si tratta di un’azienda esperta di tecnologia—come un grande attore nell’e-commerce—talvolta inviano dei team ad essere formati da noi, con l’idea di internalizzare le pratiche che Lokad utilizza. Se un’azienda ha una forte cultura tecnologica e sviluppa molto internamente, può sicuramente farlo. Ma se la loro cultura è “Esternalizziamo tutto ciò che è troppo complicato”, allora probabilmente esternalizzeranno. In generale, penso che la maggior parte opterà per fornitori specializzati, che si tratti di Lokad o di altri. Ovviamente, sono di parte—mi piacerebbe credere che Lokad sarà tra queste soluzioni—ma in ogni caso sono convinto che la rivoluzione stia accadendo, in un modo o nell’altro.
Studente: Hai detto che i LLMs non sostituiranno gli ingegneri, ma solo quelli che non usano i LLMs. Quale fattore limita l’IA in modo tale che non possa sostituire quegli ingegneri che invece usano i LLMs? In altre parole, cosa impedisce all’IA di superare gli ingegneri che essa stessa utilizza?
Joannes Vermorel: Se conoscessi la risposta definitiva, varrebbe mille miliardi di dollari. Nel corso dei decenni ci sono state molte scoperte rivoluzionarie nell’intelligenza artificiale, ognuna delle quali ha rivelato un aspetto di ciò che è l’intelligenza—che non avevamo compreso appieno. Ancora e ancora ci rendiamo conto di aver frainteso cosa costituisce l’intelligenza “reale”.
Ad esempio, se nel 1940 vi chiedessero cosa dimostra un’intelligenza superiore, potrebbero rispondere: “Qualcuno che sa diagonalizzare una matrice.” L’École Polytechnique addirittura aveva un dipartimento dedicato alla diagonalizzazione delle matrici, considerato l’apice del successo intellettuale. Ora un semplice algoritmo informatico può diagonalizzare una matrice; e non lo riteniamo affatto intelligente.
Abbiamo avuto venti simili episodi nella storia dell’IA, scoprendo ogni volta che qualcosa che pensavamo essere “intelligenza” non lo è. I Large Language Models hanno attualmente alcuni evidenti difetti—come il fatto di non apprendere nulla durante l’uso. Sono modelli statici. Puoi fornire loro un prompt, ricevere una continuazione, e basta. Se fornisci lo stesso prompt di nuovo, ottieni la stessa continuazione. Non apprendono dalla conversazione. Puoi eseguire del fine-tuning, sì, ma si tratta di un processo esterno. Giorno per giorno, non c’è memoria o miglioramento persistente. Un essere umano che fa un esercizio impara qualcosa; un LLM no. Puoi ripetere lo stesso scenario 200 volte, e non accumula conoscenza.
Un altro aspetto strano è la quantità massiccia di dati di cui i LLMs hanno bisogno. Un bambino impara a parlare in circa tre anni, con al massimo 1.000 ore di ascolto. Un LLM apparentemente deve leggere l’intero internet—miliardi di token. Oppure pensa alle auto a guida autonoma: percorrono milioni di miglia, virtuali o reali, per imparare a fare ciò che un umano padroneggia in 20 ore di lezioni. Perché così tanti dati per “intelligenza”?
Quindi percepiamo che manca qualcosa di fondamentale, ma non sappiamo esattamente cosa. Forse la prossima iterazione dei LLMs o un nuovo approccio completamente diverso risolverà queste lacune, ma non siamo sicuri se ciò avverrà domani o tra 20 o 50 anni. Alcune persone, come Yann LeCun, dicono che dovremmo abbandonare completamente l’approccio LLM e fare qualcos’altro. Non ne sono così sicuro; forse possiamo modificare i LLMs per affrontare questi problemi. Poiché nessuno ha ancora una soluzione, semplicemente non lo sappiamo.
In ogni caso, queste sono limitazioni profonde che impediscono a un LLM di sostituire completamente un essere umano, anche in lavori relativamente semplici. Quindi sì, i LLMs sostituiranno gli ingegneri che scelgono di non usarli; ma non sostituiranno necessariamente gli ingegneri che li usano—questi individui rimarranno indispensabili.
Studente: In precedenza, hai detto che Lokad è rimasta redditizia nonostante il prodotto inizialmente non funzionasse. Com’è possibile? Avete ricevuto finanziamenti o sussidi? O fornivate altri servizi?
Joannes Vermorel: No, nessun sussidio o finanziamento esterno. Lasciami spiegare: il mercato della supply chain è un po’ folle. I piani aziendali tipici dei concorrenti dagli anni ‘80 sono così: Passo 1, raccogliere una montagna di denaro—decine di milioni. Passo 2, conquistare quote di mercato concentrandosi su un settore verticale, come aviation, per due o tre anni. Passo 3, assumere 200 venditori, prendere il 20% del mercato, poi infine implodere. Ripeti.
Lo vediamo costantemente. Anche giganti come Nike sono quasi andati in bancarotta nel 2004 a causa di un noto fiasco del software della supply chain con uno dei nostri concorrenti. Il “disastro Nike” è documentato sulla loro pagina Wikipedia. Hanno fondamentalmente rovinato nove mesi della produzione di Nike. Nel frattempo, lo stesso fornitore ha causato disagi a molti clienti, è stato acquisito, e l’acquirente ha finito per pagare 250 milioni di dollari di risarcimenti. Dalla mia esperienza, nel software enterprise, anche se sei mediocre, di solito non vieni citato in giudizio, quindi questi ragazzi devono essere stati davvero pessimi. Ma nonostante quel curriculum, hanno semplicemente avviato una nuova azienda—le stesse persone—e raccolto altri 500 milioni di dollari. Il mercato non impara mai.
Molti dei nostri clienti vengono effettivamente da noi dopo mezza dozzina di tentativi disastrosi di progetti di supply chain con diversi fornitori. L’automazione della supply chain è un vecchio sogno; i dati sottostanti sono stati digitalizzati dagli anni ‘80 o ‘90, quindi ci hanno provato per decenni. È normale che le grandi aziende abbiano una pila di progetti falliti nel loro armadio.
Questo è l’ambiente in cui operiamo. C’è un’enorme inerzia. Le persone dimenticano. Il bisogno rimane, quindi riprovano ancora e ancora. Il mercato potrebbe sembrare razionale da lontano, ma è lento a risolvere questi problemi—soprattutto in un’area opaca come il software enterprise. Puoi anche avere un’implementazione catastrofica, eppure il cliente potrebbe comunque offrirti un caso di studio brillante, perché il manager che ha scelto il tuo prodotto non vuole essere incolpato. Quindi, ironicamente, un fiasco può essere presentato come un successo nella narrazione di marketing. È così caotico.
Joannes Vermorel: Altre domande? Tutto quello che ho descritto vi sembra normale, razionale—ciò che vi aspettate dal mondo degli affari?
Va bene. In ogni caso, grazie a tutti voi per il tempo dedicato a programmare gli script Envision. Sono molto orgoglioso di vedere gli studenti di Central rimboccarsi le maniche e utilizzare Envision. Davvero non avrei mai immaginato, quando scrissi il primo compilatore oltre un decennio fa, che un giorno avrei visto gli studenti di Central lavorarci. All’epoca era una scommessa rischiosa; non era nel nostro piano aziendale farvi conoscere Envision, ma sono felice che sia successo. E se Rémi o Basil non ve l’hanno ancora detto: Lokad sta assumendo, giusto per farvelo sapere!
