00:00:00 Introduzione all’intervista
00:01:41 Gli inizi della carriera di Ian Wright e la fondazione di Logistics Sciences
00:05:33 Il concetto di ottimalità nella supply chain
00:10:06 Ottimizzazione, incertezza e disruzioni nel mondo reale
00:18:18 Limiti dell’ottimizzazione tradizionale e impatto della pandemia
00:25:27 La risposta di Lokad e l’adattamento delle supply chain
00:32:45 Le sfide dei modelli deterministici e dei compromessi
00:41:09 Livelli di servizio, modelli finanziari e verifiche di consistenza
00:50:48 Competenza umana, euristiche e modellizzazione iterativa
00:58:39 Il costo dell’intervento umano nelle supply chain
01:06:24 La strategia come ingegneria e automazione decisionale
01:14:06 Il modello decentralizzato di Walmart e la rottura dei silos
01:21:39 Feedback loop e miglioramento continuo della supply chain
01:29:18 Raggiungere l’ottimalità e navigare tra l’hype dei fornitori
01:35:42 Considerazioni finali sulle tendenze della tecnologia nella supply chain
Riassunto
In una recente intervista a LokadTV, Conor Doherty ha ospitato Ian Wright, fondatore di Logistics Sciences, e Joannes Vermorel, CEO di Lokad, per discutere la nozione secondo cui non esistono decisioni ottimali nel supply chain management. Hanno messo in discussione le vedute tradizionali sull’efficienza, evidenziando le complessità e le incertezze che sfidano gli ideali da manuale. Ian e Joannes hanno sottolineato che i diversi stakeholder hanno definizioni differenti di ottimalità, e le soluzioni pratiche devono essere in linea con la realtà aziendale. Hanno discusso le limitazioni dei metodi tradizionali di ottimizzazione e l’importanza del giudizio umano nel processo decisionale strategico. La conversazione ha sottolineato la necessità di modelli in grado di gestire l’incertezza e focalizzati su risultati economici reali.
Riassunto Esteso
In un recente episodio di LokadTV, Conor Doherty, Direttore della Comunicazione di Lokad, ha condotto una discussione illuminante con Ian Wright, fondatore di Logistics Sciences, e Joannes Vermorel, CEO e fondatore di Lokad. La conversazione ruotava attorno all’idea provocatoria che non esistono decisioni ottimali nel supply chain management, un concetto che sfida le visioni tradizionali sull’efficienza e il processo decisionale.
Conor Doherty ha aperto la discussione evidenziando la comune convinzione che le decisioni ottimali rappresentino l’apice dell’efficienza, una situazione in cui le risorse sono allocate perfettamente, i costi ridotti e i profitti massimizzati. Tuttavia, ha osservato che tali ideali da manuale spesso crollano di fronte alle complessità della realtà. Ian Wright, con oltre 40 anni di esperienza in supply chain e logistica, ha condiviso il suo percorso dall’ambito accademico all’industria petrolifera, fino alla fondazione di Logistics Sciences. La sua carriera è stata caratterizzata da un focus sulla risoluzione dei problemi nel campo della logistica e della ricerca operativa, sottolineando l’applicazione pratica della pianificazione e dell’esecuzione.
Joannes Vermorel ha condiviso i sentimenti di Ian, osservando che sebbene le intenzioni alla base della ricerca operativa dopo la Seconda Guerra Mondiale fossero corrette, il settore ha affrontato sfide simili a quelle vissute dall’intelligenza artificiale, con periodi di aspettative gonfiate seguiti da delusioni. Ha sottolineato che molti metodi della ricerca operativa non sono riusciti a fornire benefici concreti alle aziende.
La conversazione si è poi addentrata nel documento di Ian, “Perché non esiste una soluzione ottimale nella pianificazione della supply chain e nell’ottimizzazione della rete logistica.” Ian ha spiegato che i diversi stakeholder hanno definizioni differenti di ottimalità, portando spesso a idee contrastanti. I professionisti si concentrano sugli aspetti matematici, mentre i dirigenti sono maggiormente interessati a soluzioni pratiche e implementabili. Ha sottolineato che modelli e strumenti sono solo aspetti di una soluzione più ampia che deve avere senso per l’azienda.
Joannes ha approfondito il discorso, discutendo le limitazioni dei metodi tradizionali di ottimizzazione, che spesso non riescono a incorporare la dimensione temporale e a gestire l’incertezza. Ha sottolineato l’importanza dei miglioramenti quantitativi nell’ottimizzazione aziendale, contrapposta alla prospettiva più statica e matematica della ricerca operativa tradizionale.
La discussione ha toccato anche il ruolo dell’incertezza nel processo decisionale della supply chain. Ian ha descritto diverse fonti di incertezza, da variazioni prevedibili a eventi Black Swan e incognite. Ha sottolineato la necessità di modelli capaci di gestire tali incertezze e fornire soluzioni contingenti.
Joannes ha illustrato l’approccio di Lokad durante i lockdown per il COVID-19, in cui hanno gestito le decisioni relative alla supply chain per clienti i cui impiegati erano in congedo. Iniettando una massiccia dose di incertezza nei loro modelli, Lokad è riuscita a prendere decisioni più prudenti, dimostrando l’efficacia dei loro sistemi di ottimizzazione.
La conversazione poi si è spostata sul ruolo dei compromessi nel processo decisionale. Ian ha sottolineato che i compromessi spesso si riducono a considerazioni finanziarie, bilanciando i costi con i livelli di servizio e altri fattori. Joannes ha affermato che molte aziende si concentrano sull’ottimizzazione delle percentuali anziché sui veri risultati economici, portando a decisioni subottimali.
Sia Ian che Joannes hanno concordato sull’importanza del coinvolgimento umano nel processo decisionale strategico. Sebbene gli strumenti di automazione e ottimizzazione possano gestire molti compiti, l’intuizione e il giudizio umano rimangono fondamentali, soprattutto in settori in cui l’input meccanicistico è insufficiente.
In conclusione, l’intervista ha evidenziato le complessità e le sfide dell’ottimizzazione della supply chain, sottolineando la necessità di soluzioni pratiche e implementabili che tengano conto dell’incertezza e coinvolgano il giudizio umano. Sia Ian che Joannes hanno fornito preziose intuizioni su come le aziende possano affrontare queste sfide, enfatizzando l’importanza di allineare i modelli con le operazioni reali e concentrarsi su veri risultati economici.
Trascrizione Completa
Conor Doherty: Bentornati a LokadTV. Una decisione ottimale è spesso considerata l’apice dell’efficienza, una situazione in cui le risorse sono allocate perfettamente, i costi ridotti e i profitti massimizzati. Ora, questo suona bene in un manuale o in aula, ma spesso tali idee vacillano al contatto con la realtà. L’ospite di oggi, Ian Wright, ci parlerà proprio di questa ricerca dell’ottimalità. Ian è il fondatore di Logistics Sciences e ha oltre 40 anni di esperienza nella supply chain.
Come sempre, se vi piace ciò che ascoltate, iscrivetevi al canale YouTube e seguiteci su LinkedIn. Con questo, vi presento la conversazione di oggi con Ian Wright.
Va bene, ottimo. Bene, Ian, ti ringrazio molto per essere con noi. Per chi potrebbe non conoscerti, cioè, ti ho già presentato in precedenza, ma per chi non conosce il tuo lavoro, potresti fare una breve presentazione, per favore?
Ian Wright: Beh, penso che tu abbia menzionato che sono in attività da 40 anni. In realtà, sono presente da molto più tempo di così, ma la mia carriera copre 40 anni. Dal punto di vista accademico, il mio percorso è iniziato grazie a un interesse per l’economia e la geografia, che ho unito nello studio di ciò che all’epoca era conosciuto semplicemente come trasporti o transport, da dove vengo. E in sostanza si trattava di economia, geografia, business, e questo ha suscitato in me un grande interesse per la risoluzione dei problemi, in particolare per quanto oggi viene chiamato logistica e ricerca operativa. Quindi sono passato alla ricerca operativa, concentrandomi tuttavia molto sui problemi dei trasporti, della logistica, e ora su ciò che tutti conosciamo come supply chain. Quindi è stato oltre 40 anni fa.
E poi, passando al bisogno effettivo di guadagnarsi da vivere, sono entrato nell’industria petrolifera come management scientist per Castrol. Sono stato quasi buttato a capofitto, per così dire, perché sono stato subito coinvolto in alcuni progetti di pianificazione strategica di alto livello. Ho scritto numerosi sistemi di manutenzione preventiva per la distribuzione dell’azienda e ho acquisito familiarità con il software di pianificazione sia dal punto di vista della rete che della pianificazione della flotta. Successivamente sono entrato a far parte dell’azienda che forniva tali sistemi, azienda composta al tempo da una sola persona – insomma, eravamo in due – e l’ho aiutato a svilupparli. Poi mi sono trasferito negli Stati Uniti con un cliente dell’azienda e mi sono occupato di GIS e dell’uso del GIS per la visualizzazione di ciò che facevamo nella pianificazione. Quindi è stata una prima introduzione a ciò che oggi è prevalente nel campo del GIS e della visualizzazione, già nei primi anni ‘80.
Da lì sono entrato nel campo della logistica terziaria inizialmente tramite un progetto di sviluppo software. Tuttavia, ho conosciuto il 3PL nel Regno Unito durante tutta la mia carriera, ma negli Stati Uniti, all’inizio degli anni ‘90, era ancora una novità, e stavano appena sviluppando l’idea di assemblare soluzioni da vendere ai clienti. Queste soluzioni riguardavano, ad esempio, dove posizionare il tuo magazzino, come gestire i tuoi asset di trasporto. È stata una grande applicazione del mio background, ma, cosa importante per me, è stata una lezione fondamentale in termini di pianificazione per l’implementazione e l’esecuzione, e di non allontanarsi mai dal fatto di dover operare la soluzione che si era messa insieme, il che credo sia una buona lezione per tutti coloro che sono coinvolti in ciò che facciamo.
Alla fine, ho abbandonato la pianificazione vera e propria. Ho messo insieme un paio di gruppi di soluzioni e li ho gestiti. Poi sono passato ad assumere sempre maggiori responsabilità nelle organizzazioni per cui ho lavorato. Ma alla fine, dopo aver attraversato un periodo nel settore della consulenza, che non mi ha particolarmente entusiasmato, ho deciso di fondare uno studio di consulenza, Logistic Sciences. E se volete sapere cos’è Logistic Sciences, è fondamentalmente il tentativo di tornare a ciò che mi piace fare, ovvero risolvere problemi, con un particolare focus sulle questioni relative alla supply chain e alla logistica, utilizzando le poche conoscenze e gli strumenti limitati di cui dispongo per aiutare le persone a risolvere problemi in questo ambito. Quindi, non so se questo vi aiuta a capire da dove vengo. Non ho idea di dove andrò, ma…
Conor Doherty: Bene, grazie Ian. E in realtà, Joannes, sono sicuro che molto di ciò risuoni con te. Voglio dire, l’idea di risolvere problemi e di riconsiderare il problema del processo decisionale nella supply chain, è qualcosa che ti sta davvero a cuore, vero?
Joannes Vermorel: Sì, voglio dire, per quanto riguarda le intenzioni, quelle poste dalla ricerca operativa dopo la Seconda Guerra Mondiale erano molto corrette, nel senso di cercare di ingegnerizzare quei metodi di gestione in qualcosa di numericamente solido e migliorabile. Credo che questa fosse una delle intenzioni corrette e che sia ancora molto rilevante oggi. La sfida è che è davvero interessante. Le persone parlano molto frequentemente dei vari inverni che l’IA, l’intelligenza artificiale, ha attraversato con speranze gonfiate seguite da delusioni per il fatto che non funzionasse. Credo che la ricerca operativa abbia attraversato fasi simili, e che alcune ondate di metodi che erano conosciute all’epoca non siano riuscite a trasformarsi in benefici concreti per le aziende.
Conor Doherty: Beh, in realtà, questo ci porta al tema della conversazione di oggi, a cui Ian si è ispirato vedendo il tuo lavoro su LinkedIn. Pubblicate davvero tanti articoli. Ne ho uno proprio qui davanti a me su cui ho preso appunti. Spero che la telecamera riesca a inquadrare il documento. Quindi l’ho letto, lo abbiamo tutti letto. Ma quel documento, e lo leggo, sono l’uomo, sono l’uomo. Sì, era gratuito, grazie. Quindi, in particolare, il documento che ha suscitato l’interesse per questa conversazione, “Why There Is No Such Thing as an Optimal Solution in Supply Chain Planning and Logistics Network Optimization.” Ora, è lungo circa 13 pagine. Per chi non lo avesse letto, una sintesi a livello esecutivo, per favore.
Ian Wright: Fondamentalmente, il mio obiettivo è trasmettere l’idea che persone diverse hanno concezioni differenti di cosa sia l’ottimalità. In generale, ciò che noto è che si tratta di idee contrastanti, o meglio, di idee in conflitto, nel senso che la concezione dell’ottimalità del professionista è spesso molto più focalizzata su ciò che fa con lo strumento o la tecnica impiegata. E, come ha ripreso Joannes, è spesso concentrata sulla matematica, mentre la persona che è il destinatario dell’ottimizzazione è l’uomo d’affari.
Ian Wright: Presumo che possiamo concentrarci sul settore privato e commerciale, anche se, ovviamente, si potrebbe fare molto di più nel campo della supply chain. Ma l’uomo d’affari non è affatto interessato – o non dovrebbe esserlo – alla matematica, alla metodologia, allo strumento o al modello. E quando collaboro con i miei clienti e nei progetti, mi concentro sul far capire loro che gli strumenti che utilizziamo, i modelli che costruiamo, sono solo una piccola parte della ricerca di una soluzione che possano impiegare per prendere decisioni e implementare qualcosa. Quindi, la premessa fondamentale dell’articolo era trasmettere l’idea che il modello non è l’elemento importante, è la soluzione. E ci sono molti altri componenti, molte altre sfaccettature in una soluzione che abbia senso per l’azienda.
Conor Doherty: Solo su questo, e Joannes, arrivo da te tra un minuto, ma il modo in cui hai inquadrato la questione, ancora una volta, quando la spieghi ai tuoi clienti, stai cercando – e l’ho annotato – di fare in modo che la gente capisca. E su questo punto, penso che una parola chiave da chiarire immediatamente sia che, quando parli di optimality, ancora una volta, hai fatto la distinzione tra il praticante e il matematico. Spesso certe terminologie possono significare cose leggermente diverse a seconda del contesto in cui vengono usate. Joannes ed io abbiamo recentemente discusso di euristiche, e ancora una volta, un’euristica in senso matematico rispetto a un senso economico può essere leggermente diversa. Quindi, quando parli di perseguire una decisione ottimale o di presentare l’optimality, cosa intendi esattamente, per favore?
Ian Wright: In generale, penso all’optimality non nel senso del matematico, perché a mio avviso quella è una nozione meravigliosa su cui concentrarsi se vivi nel mondo della matematica. Ma con ciò che devi convivere c’è la migliore soluzione nelle circostanze prevalenti. Quindi, cosa sta veramente succedendo? Cosa sta veramente succedendo nel mondo? Dobbiamo capire cosa stia accadendo, e poi dobbiamo presentare una soluzione che rappresenti il meglio che possiamo ideare in queste circostanze e che allevierà o mitigherà la maggior parte dei problemi che troviamo. Quella è la soluzione che stiamo cercando, quella che vogliamo presentare.
Conor Doherty: Joannes? Oh, sì, grazie, Ian. Quindi, ancora una volta, l’idea di essere il migliore disponibile non significa essere perfetti in senso assoluto. Vuoi aggiungere qualcosa o sei d’accordo?
Joannes Vermorel: Sì, intendo dire, per riprendere la caratterizzazione dell’ottimizzazione in matematica come qualcosa di bello, sono d’accordo. È qualcosa di estremamente semplice. Posso riassumerlo per il pubblico. È l’idea che prendi una funzione che assegna un punteggio su ciò che desideri, e poi parte dell’input di queste funzioni sono le tue variabili, cioè ciò che puoi decidere, ciò che può variare secondo la tua volontà. Quindi, questo costituisce l’input, e poi la funzione ti fornisce il punteggio. Fondamentalmente, l’ottimizzazione cerca quella combinazione di input che formalizza la tua decisione e che estreme il risultato – estreme come minimizzare se cerchi di ridurre i costi o massimizzare se vuoi aumentare i rendimenti, qualcosa del genere.
Ed è interessante notare che questo semplice problema viene accompagnato da una chiara e rigorosa caratterizzazione matematica. Da lì puoi dire ogni sorta di cosa interessante sui tuoi input, puoi dire tutto ciò che riguarda il comportamento del tuo output, e quali classi di algoritmi esistono per cercare una soluzione, e se, in termini matematici, potrai affermare che, sotto quelle ipotesi, il tuo metodo è il migliore possibile o meno, ecc. E a proposito, questo campo di ricerca ora è noto semplicemente come OR. Un tempo stava per operational research, ma oggi è soltanto ottimizzazione matematica. E non si preoccupano nemmeno più di sapere se stanno parlando di un problema aziendale o meno. Il loro interesse è lo sviluppo di solver, una classe di software progettati per eseguire quelle ottimizzazioni in senso matematico.
Quando pensiamo all’ottimizzazione in termini matematici, credo che sia la comprensione più, direi, cristallina di ciò che l’ottimizzazione sia. Non significa che, essendo cristallina, sia la più rilevante. Significa solo che è la forma più pura, per così dire, come la purezza del cristallo. Non vuol dire che sia lo strumento applicabile in ogni situazione. E quando consideriamo l’ottimizzazione in un contesto aziendale, intendiamo che vogliamo migliorare le cose, ma con un approccio quantitativo. Vedi, questa è la differenza.
Perché posso anche migliorare un’azienda, ad esempio, creando una cultura migliore in cui le persone siano più dedicate, ma è quasi impossibile quantificare qualcosa in merito. Quindi, quando parliamo di ottimizzazione, intendiamo migliorare utilizzando strumenti quantitativi e, idealmente, ottenere risultati quantitativi. Questo rappresenta, insomma, – e qui torno alla tua definizione di ottimizzazione come la intendi tu – un processo composto principalmente da miglioramenti quantitativi. Questo, insomma, è ciò che rappresenta la prospettiva aziendale sull’ottimizzazione.
Ian Wright: Penso, anzi, sono completamente d’accordo con Joannes. Una delle cose che dobbiamo comprendere è che l’optimality è anche correlata al fatto che ci sono dimensioni coinvolte nei problemi che stiamo esaminando, e che spesso queste dimensioni vengono ignorate o tralasciate. E una delle dimensioni più basilari, in effetti, forse la più basilare, è la dimensione del tempo.
Questo ha un impatto enorme su ciò che puoi fare con il modello, la tecnica e/o la tecnologia, e su ciò che devi fare nell’operatività reale e su ciò che sei in grado di fare in quelle circostanze. E cambia, cambia la natura di ciò che puoi considerare ottimale.
Conor Doherty: Beh, in realtà, ed è ancora una volta una frase perfetta, ciò che sei in grado di fare. E questo si trasforma nuovamente in una discussione su ciò che penso sia – e so che per Joannes rappresenta certamente un elemento chiave in ogni discussione sull’optimality o, fondamentalmente, sul processo decisionale – la natura dell’incertezza quando si cerca di prendere decisioni.
Quindi, nel tuo articolo, parli di incertezza e della reale complessità che esiste nella supply chain. Potresti commentare un po’ più approfonditamente sulle fonti di incertezza che effettivamente influenzano la ricerca dell’optimality in qualunque modo si voglia ottimizzare?
Ian Wright: Ci sono molte sfumature di incertezza e, uh, persino al punto che ce ne sono alcune che non puoi nemmeno “assaggiare” perché non sai neanche della loro esistenza. Quindi, c’è quella forma di incertezza su cui la maggior parte delle persone si concentra, che a mio avviso è semplicemente una riflessione della natura dinamica del campo delle operazioni della supply chain. Sono semplicemente dinamiche, perciò esiste un’incertezza legata a queste dinamiche, e questa è suscettibile ad analisi, analisi quantitative e analisi probabilistiche – come so che voi ragazzi fate.
Ma poi si va oltre, passando ad alcune aree di incertezza che si spostano maggiormente nell’ambito del rischio. Esistono piccoli rischi ed estremamente grandi rischi, e questo si riflette anche nel fatto che si va oltre un contesto prevedibile o prevedibilmente probabilistico fino al punto in cui si parla – come credo di aver fatto nel paper – di eventi Black Swan. E semplicemente, wow, ho perso del tutto il filo.
Quindi, scusate, potrebbe essere necessario modificare quanto detto, ma si passa da una scala del modello del piccolo mondo, che è prevedibile e in cui ci sono elementi che puoi anticipare grazie a dati facilmente acquisibili, per poi arrivare agli eventi Black Swan, che sostanzialmente, sai, possono accadere, ma la capacità di prevederli è molto più remota e, in effetti, alla fine, certi eventi Black Swan semplicemente non possono essere previsti. Sai solo che possono succedere. E poi penso, in modo ancora più catastrofico, che spesso in molte circostanze quello che io definisco – mutuando una frase nel paper – gli sconosciuti sconosciuti.
Donald Rumsfeld, beh, in realtà non era Donald Rumsfeld, era un tizio precedente che aveva rubato l’idea proprio come ho fatto io, ma comunque. E poi, questo ti porta a chiederti: fino a che punto dobbiamo realmente spingerci per comprendere non solo gli sconosciuti sconosciuti, per i quali non possiamo – non possiamo tenerne conto – perfino degli eventi Black Swan non possiamo necessariamente prevederli in termini operativi generali e di pianificazione, ma del prevedibile, basato sulla probabilità, possiamo e dobbiamo tenerne conto.
E quello che direi inoltre è che puoi spostarti in una dimensione operativa diversa, in cui – e credo di averne parlato nella modellazione – non si guarda soltanto a una soluzione, ma a una soluzione composta da numerosi elementi contingenti che puoi attivare o che possono essere attivati ed eseguiti secondo necessità. Ma l’obiettivo è rimanere il più vicino possibile a quella che hai definito come ottimale nella tua soluzione preferita.
Conor Doherty: Beh, in realtà, per riprendere la citazione non ispirata a Donald Rumsfeld, altre fonti di incertezza che la gente ritiene essere “known knowns” sarebbero, come hai detto nel paper, una domanda stabile e supply chains prevedibili. Joannes, questi sono “known knowns” o “known unknowns” o “unknown unknowns”?
Joannes Vermorel: Sì, penso che questa tipologia sia interessante, ma ancora una volta, se torniamo allo strumento di base che usiamo per quelle analisi quantitative, se ripensiamo alle metodologie sviluppate nell’ambito della research operativa, la dimensione del tempo era assente. Il primo motivo per cui era assente, in modo veramente banale, è che aumentava la dimensionalità dei problemi e quei metodi si comportavano molto male nel trattare problemi più complessi. Non sono molto scalabili, almeno non nel modo in cui oggi intendiamo soluzioni scalabili, specialmente se si guarda, alla luce degli sviluppi recenti, a quello che è successo, diciamo, sul fronte del deep learning.
Quindi, il primo problema è che avevamo un problema super basilare riguardante la scalabilità, senza la dimensione temporale. E poi, una volta che iniziamo a considerare la dimensione del tempo, il futuro non è perfettamente noto, dunque dobbiamo gestire una certa variabilità. E qui si parla semplicemente di “known unknowns”. Sai, si tratta di un caso molto lieve di incertezza. È atteso che i lead times varino, è atteso che la domanda vari, ecc. Quindi quei casi sono relativamente facili.
E poi entriamo nel territorio di quella che viene chiamata ottimizzazione stocastica, perché improvvisamente la tua decisione potrebbe rivelarsi buona o cattiva a seconda delle circostanze future che non controlli. Quindi, ci sono futuri alternativi in cui questa decisione appare positiva, ma ci sono sicuramente futuri in cui, col tempo, si rivelerà una scelta errata. Direi che questi sono i problemi molto banali che affrontiamo prima di saltare agli sconosciuti sconosciuti e a tutte quelle varietà selvagge di incertezza, problemi più basilari ancora, ed è qui che trovo particolarmente interessante questa nozione di sfaccettature.
Non sappiamo veramente come dovremmo attribuire un punteggio a qualcosa. Non è ovvio. Quando diciamo di voler ottimizzare i profitti, esistono un numero indefinito di modi per calcolare i profitti. Dovremmo includere gli effetti di secondo ordine, di terzo ordine? Cosa intendo per effetti di secondo ordine? Offri uno sconto del 10% ora, e il cliente si aspetta che la prossima volta, entrando nel negozio, riceva nuovamente uno sconto simile. Questo è un effetto di secondo ordine. Hai appena concesso uno sconto, ma ti è costato di più perché hai alimentato l’aspettativa. Quindi, anche questo andrebbe valutato.
E poi, se fai ciò, il tuo concorrente potrebbe decidere in modo aggressivo di competere ancora di più sul prezzo, oppure alla fine potrebbe rinunciare completamente a competere, lasciandoti da solo o almeno con meno concorrenti. Quindi, vedi, tutto ciò riguarda aspetti piuttosto banali di ciò che sto quantificando esattamente. Questi sono aspetti difficili. Penso che un’altra sfaccettatura, non realmente affrontata nella letteratura classica sull’ottimizzazione, sia il presupposto che i problemi fossero ben compresi fin dall’inizio.
Conor Doherty: Ian, nel tuo paper hai menzionato molti esempi concreti di aziende che hanno avuto successo o insuccesso nell’affrontare i tipi di incertezza di cui abbiamo appena parlato, sia per quanto riguarda i lead times, i modelli di domanda irregolari o altro. Potresti condividere qualche dettaglio in più di questi case study, per favore?
Ian Wright: Sì, molti dei progetti su cui lavoro sono di natura più strategica. Alcuni sono tattici. In generale, non opero più nel campo della pianificazione per l’esecuzione. Quindi, la maggior parte degli esempi che mi vengono in mente riguarda aziende che non pianificano tatticamente o strategicamente, non affrontando queste problematiche legate alla prevedibilità o alla mancanza di prevedibilità.
Proprio recentemente, negli ultimi tre anni, c’è stato un evento – l’anno precedente a quello – che penso nessuno avrebbe detto di aver previsto. Certamente, credo che nessun sistema di pianificazione in alcuna azienda avrebbe potuto concepire e incorporare elementi di pianificazione capaci di tenere conto dell’impatto della pandemia, di ciò che è successo alle scorte e delle implicazioni del calo degli inventari, del repentino calo della domanda, e così via. Tantissime implicazioni ampiamente diffuse. L’esempio classico riguarda i semiconduttori.
La mia esperienza è stata duplice: così tante aziende, uscendo dalla pandemia – non solo nel settore farmaceutico, ma anche in quello della produzione alimentare, negli apparecchi medicali, nel settore della logistica sanitaria nel suo complesso – si sono improvvisamente rese conto che dovevano pianificare per qualcosa che non avevano previsto. Stavano lavorando contro i loro sistemi interni che gestiscono l’azienda, che gestiscono la supply chain, perché quei sistemi non fornivano più dati in grado di costituire la base di modelli per capire cosa dovessero fare dopo.
Ho quindi lavorato su molti progetti per produttori alimentari che cercavano di far fronte all’immensa esplosione della domanda in aree in cui non avevano capacità, e dovevano capire molto rapidamente dove posizionare tale capacità e perché dovesse essere posizionata lì. C’erano così tanti problemi fondamentali nel cercare di capire come procedere, perché era molto simile a dire: come si costruisce una supply chain per un prodotto che oggi non esiste? Come si pianifica per questo? E poi l’intero concetto di come procedere con l’esecuzione è la fase successiva.
Conor Doherty: Ian, questa è una bella transizione allora verso Joannes. Voglio dire, questo è decisamente il tuo ambito, l’esecuzione di soluzioni in situazioni piene di incertezza. Hai qualche esempio di successi o fallimenti di aziende quando si tratta dei tipi di incertezza di cui stiamo parlando?
Joannes Vermorel: Sì, penso, sai, se torniamo agli anni dei lockdown, 2020, 2021, la cosa interessante è che Lokad ha ottenuto – direi – ottimi successi operativi, ma penso proprio perché stavamo facendo ottimizzazione.
Lasciatemi descrivere ciò che la maggior parte delle aziende sta facendo al giorno d’oggi mediante, fondamentalmente, un oceano di fogli di calcolo. Non stanno ottimizzando nulla, né in senso matematico né nel modo che abbiamo appena descritto. Quello che stanno essenzialmente facendo è in larga parte riprodurre quanto già fatto in precedenza. Stanno in pratica replicando le proprie decisioni passate. Non stanno nemmeno effettivamente seguendo la demand o altro; stanno semplicemente ripetendo quanto hanno fatto in passato, il che significa che il budget viene suddiviso e ripartito praticamente nello stesso modo in cui è stato fatto l’anno scorso, che le safety stocks sono nuovamente regolate minimamente rispetto a quanto fatto l’anno scorso, ecc. Quindi, tutto viene fatto in modo incrementale rispetto allo status quo. Non c’è ottimizzazione in corso. Stiamo semplicemente riflettendo lo status quo, guidandolo un po’ ma non in maniera quantitativa, un po’ nella direzione che sembrerebbe appropriata.
Funziona in un certo senso, ma il punto è questo: non c’è alcun processo di ottimizzazione in corso, il che significa che se modifichi ampiamente le tue condizioni operative, non disponi di alcun meccanismo per riflettere tali nuove condizioni. Ripeto, tutti i tuoi fogli di calcolo, tutti i tuoi processi esistenti sono progettati per replicare quanto fatto in precedenza. Al contrario, da Lokad, avevamo dei sistemi di ottimizzazione in atto. Cosa accadeva quando ci trovavamo in situazioni senza precedenti? In pratica, iniettavamo manualmente una massiccia dose di incertezza nei nostri modelli.
Non sapevamo cosa sarebbe successo. Abbiamo semplicemente detto: “Ok, demand è normalmente ciò che chiamiamo l’effetto shotgun.” Vedi il futuro della demand che procede in quel modo, insomma, possibilità. Beh, se ti trovi in una situazione come i lockdown, aumenti semplicemente l’angolo dello shotgun in modo che il futuro diventi molto sfocato. La stessa cosa per i tuoi ritardi, la stessa per i tuoi prezzi. Sostieni semplicemente che improvvisamente sai molto meno del futuro. Ma puoi farlo, e se presumi di sapere molto meno, puoi eseguire nuovamente la tua logica di ottimizzazione, quella è l’ottimizzazione stocastica, per ottenere decisioni che siano più prudenti rispetto al rischio che hai.
In un certo senso, prendi in considerazione leggermente il peggio che può accadere in termini di ritardi, prezzi, demand, ecc., e prendi decisioni molto più conservative rispetto a quei rischi che sono esplosi quantitativamente. La mia conclusione è che funziona. Funziona davvero molto bene, ma il problema è avere più ottimizzazione, non meno. Anche se non si tratta di quel tipo di prospettiva statica della ricerca operativa, un’ottimizzazione in cui nulla si muove.
La seconda cosa, è una sfaccettatura in più che penso sia stata quasi mai discussa durante l’era della ricerca operativa, probabilmente dal 1950 al 1980, quei 30 anni, ed era la qualità della tua strumentazione. Quanto velocemente puoi passare da un’istanza della tua modellizzazione alla successiva? È una questione operativa davvero pratica.
Ian Wright: Penso che ci fossero anche questioni pratiche legate a questo perché la tecnologia non era sufficiente. Mancavano i dati perché la tecnologia correlata a questo non era adeguata. Ma certamente, la tecnologia per consentire un’esecuzione più rapida della pianificazione semplicemente non esisteva. Te lo posso dire per aver visto modelli di ottimizzazione in esecuzione per 24 ore, a differenza di oggi dove, quando lavoro con delle persone, penso: “Bene, non è ancora finito, sono già passati cinque minuti, cosa dovrei fare?” Quindi, non intendo interromperti, Joannes, ma penso che gran parte di questo sia dovuto al fatto che oggi abbiamo una tecnologia molto migliore.
Joannes Vermorel: Sono completamente d’accordo, ed è una preoccupazione a parte, ma sono davvero problematiche pratiche. Se hai una tecnologia di ottimizzazione ma il ricalcolo richiede 24 ore e hai bisogno di 20 iterazioni per convergere a qualcosa che sia relativamente soddisfacente rispetto al nuovo stato della tua supply chain, non accadrà mai. La gente ritorna semplicemente ai fogli di calcolo. Non c’è semplicemente il tempo di affrontare tutte quelle complicazioni. Torni ai tuoi fogli di calcolo che potrebbero non fornirti questo tipo di ottimizzazione, ma ti daranno almeno una risposta entro un lasso di tempo ragionevole.
Penso che fosse anche quel tipo di situazione in cui Lokad si è comportata bene in quel periodo. Avevamo ottimizzazione, ma avevamo strumenti di ottimizzazione sufficientemente agili da poter essere testati ripetutamente, dozzine di volte al giorno, fino a ottenere qualcosa che funzionasse davvero. Altrimenti, i nostri clienti si sarebbero semplicemente arresi ai tipi di servizi che Lokad offriva all’epoca.
Ian Wright: Interessante, perché ho sempre avuto difficoltà con quella che chiamo l’ottimizzazione snapshot. In particolare, la pianificazione della supply chain e i modelli di rete sono sempre stati basati sull’integer programming snapshot. I solver sono tutti snapshot, e tutta questa questione del timing, ho sempre faticato a capire come poter sfruttare i benefici degli approcci di tipo simulazione, in cui siamo in grado di incorporare la dimensione del tempo in modo un po’ migliore, e come possiamo in qualche modo fondere un approccio.
Ad esempio, c’è un’azienda in Russia, un’azienda di simulazione, che ha ideato una combinazione con l’ottimizzazione. A quel tempo mi sembrava fantastico. Purtroppo, non sono molto familiare con la loro implementazione del lato ottimizzazione, perché sono un’azienda di simulazione. La questione del tempo è una cosa. L’altra questione, credo, nella determinazione di una soluzione con probabilità coinvolge anche un problema tecnologico che oggi siamo più in grado di affrontare. Comporta la quantità di dati, l’ambito dei dati che puoi incorporare per derivare la soluzione.
Molte cose sono al di fuori dell’ambito della corporazione, dell’azienda o della divisione per cui stai ottimizzando, e non vengono considerate quando hai un new product o quando entri in un mondo completamente nuovo a seguito di una pandemia. L’unica cosa su cui puoi spesso fare affidamento sono dati che non hanno nulla a che fare con la storia delle tue operazioni precedenti. Devi considerare un ambito molto più ampio di dati così che, quando arrivi a definire le probabilità, ad esempio, devi incorporare variabili esogene oltre a tutte le variabili tradizionali legate all’attività che stai cercando di portare avanti.
Joannes Vermorel: Concettualmente, sì, anche se sono leggermente in disaccordo su questo punto. Il fatto è che i dati oltre quelli transazionali sono molto costosi per le aziende. Acquisire dati sull’intelligence competitiva è abbastanza accettabile, non troppo costoso, ma se vai oltre, limitandoti a prelevare i prezzi dei tuoi concorrenti, diventa molto rapidamente estremamente complicato.
Il nostro approccio è che, di solito, innanzitutto, è necessario disporre di modelli in cui si analizzano i dati in modo più informativo. Un esempio potrebbe essere il lancio di un new product: non hai alcuna cronologia di vendite, quindi la tradizionale prospettiva delle time series dice che non hai nulla. Ma se abbandoni la prospettiva delle time series e abbracci una visione alternativa, potresti notare che i lanci dei tuoi prodotti seguono un pattern di successo o fallimento e che i successi che puoi aspettarti si comportano secondo una certa distribuzione, così come i fallimenti. Quindi sì, puoi utilizzare i tuoi dati storici per fare osservazioni sul prodotto.
Ancora, perché se un no-name studio lancia un film, le probabilità che questo no-name studio produca un film che incassi 1 miliardo al botteghino sono estremamente basse. Ma se si tratta di Disney o Warner Brothers, allora le probabilità sono forse intorno al 5%.
Quindi, innanzitutto, utilizzando i dati transazionali delle aziende, solitamente si può capire molto di più di quanto si pensi, poiché molti sono ancora legati alla prospettiva delle time series. Esistono altri metodi.
Il secondo aspetto è che, se ammetti che semplicemente non sai, realizziamo che le persone che prenderanno quelle decisioni in quanto umani non dispongono di una fonte segreta di informazioni. Non esiste una sfera di cristallo all’interno del cervello umano che ti permetta di sbirciare nel futuro o altro, specialmente quando parliamo di supply chain dove abbiamo decine di migliaia di prodotti che conosci solo per il fatto che esistono. Molte persone che sarebbero un pianificatore della domanda non saprebbero nemmeno esattamente cosa stia vendendo o producendo la loro azienda.
Quindi, tornando a questo, direi che, innanzitutto, abbiamo i nostri dati transazionali che possono essere sfruttati in molti modi più di quanto si pensi, non appena abbandoni questa prospettiva delle time series. Ma poi hai anche il fatto che queste informazioni extra sono molto difficili da ottenere. Quindi, forse, ciò che dovremmo invece accettare è avere molta incertezza.
Le soluzioni tradizionali non accettano nemmeno di trattare con l’incertezza. Quando dico soluzioni tradizionali, intendo tutti i solver che forniscono l’ottimizzazione matematica del mercato. Tutti i solver che so essere affermati sono semplicemente solver deterministici; non possono gestire l’incertezza. Abbiamo appena ricevuto su questo canale un pioniere che sta cercando di affermare il suo prototipo di ottimizzatore stocastico InsightOpt, Meinolf Sellmann, il quale aveva i suoi strumenti Seeker. Ma è davvero uno unico nel suo genere, ed è praticamente l’unico che conosco che sta cercando di perseguire questo da una prospettiva commerciale.
Quindi, tornando al caso in questione, la mia opinione è che, se non disponi di alcuno strumento per gestire l’incertezza in qualsiasi forma, l’idea di affrontare questa situazione semplicemente gonfiando l’incertezza e lasciandola stare non è nemmeno pensabile. Ma se hai quegli strumenti, allora diventa la cosa più naturale. Provi qualcosa di senza precedenti, l’incertezza sale alle stelle, e il tuo ottimizzatore ti permette di agire di conseguenza.
Ian Wright: Penso che qui ci stiamo un po’ allontanando, perché c’è una differenza di focus tra di noi quando si pianifica in maniera strategica e quando si pianifica, in particolare, più vicino all’esecuzione, dove le opzioni diminuiscono drasticamente. Io provengo da una sfera di pianificazione prevalentemente strategica. Quando dici, per esempio, che molti di questi dati di ambito aggiuntivo per un new product sono costosi, può essere vero, ma ci sono tanti, tanti tipi di dati differenti che puoi impiegare nella modellizzazione prima di arrivare all’ottimizzazione.
Puoi modellare la correlazione tra molti aspetti esogeni differenti dei dati economici e i dati demografici relativi al tipo di prodotto e al mercato a cui vuoi offrire quel prodotto. È da lì che vengo, Joannes, quando parlo di aggiungere più elementi di dati. Sto parlando di esaminare la correlazione con quei dati ragionevolmente accessibili, generalmente relativi alla demografia e alla penetrazione del mercato.
Un altro aspetto di tutto ciò, che penso sia in definitiva ciò a cui dovremmo sempre pensare come fornitori di tecnologia e professionisti in questo campo, è che le aziende, in ultima analisi, riguardano la finanza. Un elemento importante di ciò che dobbiamo fare nella pianificazione è ridurlo al costo e alla minimizzazione dei costi, a seconda delle circostanze. I dati sui costi, a mio avviso, sono stati impiegati in modo inadeguato, per esempio, nei modelli di rete per l’ottimizzazione della supply chain. Le persone sono state contente di accettare delle ipotesi sui costi man mano che inserivano i costi nei modelli, anziché uscire e cercare aspettative molto più concrete sui costi, il che è del tutto fattibile. Penso che sia semplicemente qualcosa che, con la tecnologia che ora possediamo, è molto più maturo per essere focalizzato e per una migliore comprensione di ciò che possiamo fare per integrare dati e comprendere meglio l’ambito del contesto in cui operiamo.
Conor Doherty: È un punto perfetto su cui insistere un po’ perché, una volta che hai tutti i dati, devi alla fine giungere a una decisione. Un’altra cosa di cui parli anche nel documento è il ruolo dei compromessi nel prendere tali decisioni. Una volta che hai il tuo modello e tutti i dati, ti vengono comunque presentate diverse decisioni, spesso semplicemente delle opzioni decisionali. In che modo i compromessi si inseriscono nella ricerca della decisione ottimale?
Ian Wright: Farò una considerazione rapidamente. Non avrai mai tutti i dati. Hai i dati che possiedi, ovviamente, ma sono sempre imperfetti. Quindi devi lavorare con ciò che hai. Sono un cinico nel profondo, come puoi notare, giusto? Per quanto riguarda i compromessi, ci sono i compromessi evidenti nella supply chain. Il tuo compromesso riguarda fondamentalmente gli aspetti finanziari. Voglio spendere i soldi per fornire il servizio e il prodotto che il mio cliente desidera? Voglio offrire il prodotto nel modo in cui il cliente vuole che lo offra, e questo significa che devo spendere denaro per farlo. Fino a che punto sono disposto ad andare lungo quella strada?
Il compromesso è, per esempio, tra inventario e costo dei trasporti, come base. Ma esistono compromessi relativi a quante contingenze implemento per mitigare il rischio? Quanti possibili percorsi operativi creo per la mia attività in modo da poter eseguire un piano probabilistico che risulti in qualcosa che non sia il mio normale percorso di esecuzione? Un compromesso è: guardo alle implicazioni a breve termine dei modelli che perseguo e dei piani che metto in atto, o coinvolgo il lungo termine, il che spesso può significare un compromesso finanziario, perché sto investendo ora per qualcosa che non accadrà fino a un periodo successivo?
I trade-off, per me, sono una sorta di eufemismo per dire: devo regolare correttamente il denaro. Come bilancio tutte queste cose? Non sono sicuro se sto rispondendo alla tua domanda, Conor, ma si riduce a: cosa sono disposto a bilanciare nel mio modello, dato che so che sono limitato nel modo in cui posso definire l’ambito del mio modello? Cosa sono disposto a bilanciare per ottenere il simbolo del dollaro o dell’euro nel posto giusto?
Conor Doherty: Grazie, Ian. E Joannes, ora passo a te perché, ancora una volta, sto fondamentalmente preparandoti per qualcosa di cui so che ti piace parlare. Ho fatto notare che, in sostanza, ciò per cui le persone cercano di ottimizzare esplicitamente, correggetemi se sbaglio, è in realtà il costo o le finanze. Ma il punto è: spesso, quando parliamo di decision making nella supply chain, le persone o le aziende cercano di ottimizzare aspetti come i livelli di servizio. Penso che tu abbia già fatto notare che quello che le persone pensano di ottimizzare è il costo, ma in realtà è solo un artefatto numerico. Quindi la domanda, se potessi commentare, è: quando le persone si concentrano su quegli obiettivi tradizionali nella supply chain, stanno effettivamente ottimizzando il costo o stanno guardando nella direzione sbagliata?
Joannes Vermorel: Quindi, se osserviamo le pratiche dominanti della supply chain al giorno d’oggi, nei PowerPoint direbbero di concentrarsi su ciò che è economicamente sostenibile. In pratica, non lo fanno. Si tratta di percentuali a tutti i livelli in termini di livelli di servizio, ritorni di inventario e via dicendo. Queste cose sono debolmente correlate al tuo risultato finale, ma solo debolmente.
Supporre che la tua redditività sia correlata in qualche modo ai livelli di servizio è semplicemente folle. Non funziona. È un punto di vista molto semplicistico. La prima cosa sarebbe affermare che le pratiche dominanti sono, in effetti, poiché le persone sanno intuitivamente che non possono convincere nessuno se dicono che vogliono ottimizzare delle percentuali. Così, nelle slide, diranno “ottimizziamo quei dollari”, ma in pratica, nei loro sistemi software, hanno regole che non sono assolutamente allineate in alcun modo con quelle modellizzazioni in dollari. Direi che solo quelle che ho visto in azione, escludendo Lokad, erano rigorosamente prospettive non finanziarie, non economiche.
Ora, se passiamo a una prospettiva economica in cui iniziamo a parlare di quei dollari, sono completamente d’accordo sul fatto che sia molto difficile farlo correttamente. È difficile, e in effetti, ci sono innumerevoli storie dell’orrore, spesso narrate nei film di Hollywood, in cui il tipo delle finanze è il cattivo che pensa in modo incredibilmente stupido a breve termine a scapito di qualcosa che si realizza un po’ più avanti nel futuro.
La prospettiva finanziaria ha una cattiva fama e, in effetti, quel tipo di approccio che la ricerca operativa enfatizzava 40 anni fa era un punto di vista molto semplicistico. Si concentravano davvero su un numero molto limitato di variabili fondamentali: costi—costo del magazzino, costo di questo, costo di quello—e voilà, fatto, lavoro completato, ora lasciamo che la magia operi con la soluzione ottimale che emergerà dal modello.
Da Lokad, abbiamo notato questo e ci siamo resi conto di avere un vero problema, ovvero come capire se la nostra funzione di scoring, la nostra funzione di scoring economico, quella che conta i dollari, stia fornendo una versione approssimativa della verità che sia abbastanza valida. È una domanda molto difficile e ciò che abbiamo scoperto è stata una metodologia documentata nella mia serie di lezioni sul supply chain chiamata ottimizzazione sperimentale.
Il modo per sapere che il tuo modello economico è corretto è quando genera decisioni sensate. È molto strano. Alla fine, si pensava che fosse necessario avere la metrica di scoring corretta in modo da produrre le decisioni ottimali. Quello che facciamo è praticamente il contrario. Generiamo le decisioni e poi, tra quelle decisioni che sono state spinte all’estremo secondo questa metrica, verifichiamo se siano sensate o meno.
Quando vediamo decisioni ovviamente disfunzionali che sono palesemente assurde, molto frequentemente torniamo alla modellizzazione economica e ci rendiamo conto che qualcosa non quadra, qualcosa ci è sfuggito. Così, seguiamo questo processo molto iterativo in cui scegliamo i nostri dollari, ottimizziamo, prendiamo decisioni, alcune delle quali sono insensate, rivediamo il modo in cui contiamo i dollari, e si riparte da capo.
Con molte iterazioni, alla fine convergiamo verso una situazione in cui nessuno ha più dubbi. Questo è ciò che chiamiamo il principio zero follia. Vogliamo arrivare a un setup in cui il sistema non generi righe che siano ovviamente palesemente insensate fin da subito. È in realtà il punto in cui noi di Lokad crediamo sia necessario arrivare prima di passare alla produzione.
Ma vedi, il punto è che invertiamo completamente il tipo di prospettiva che aveva la ricerca operativa. Invece di dire che la funzione di scoring è un dato di fatto, è qualcosa che scopriremo attraverso un processo incrementale. È molto strano perché va ben contro, almeno per i francesi, quella prospettiva cartesiana del pensiero dal basso verso l’alto e dell’applicazione dei principi uno dopo l’altro. È un processo molto più empirico.
Ian Wright: Devo confessare, e mi scuso per questo, ma devo ammettere la mia relativa ignoranza su Lokad. Però sono molto incuriosito dalla tua definizione di senso, nel contesto di cui stai parlando. Cosa costituisce una decisione sensata?
Joannes Vermorel: Ian, per fare un esempio che ho dato nella mia serie di lezioni, inizierò con un’analogia e poi torneremo al supply chain. Esistono classi di problemi in cui, se vuoi risolvere il problema generale, è impossibilmente difficile, ma le istanze particolari sono molto facili.
Un esempio di ciò sarebbe, diciamo, che ti do un film da guardare e ti dico che parla di un gladiatore romano o qualcosa del genere, e ti chiedo di individuare se ci sono elementi completamente fuori contesto rispetto al periodo storico, come ad esempio un aereo sullo sfondo. C’è un film famoso in cui combattono nell’arena e, sullo sfondo, c’è un aereo che vola nel cielo.
Se ti chiedessi di trovare un algoritmo generale che mi indichi tutte le cose che possono andare storte in un film e che non riflettano l’epoca o il periodo storico, sarebbe un compito del tutto scoraggiante. Ci vorrebbe un’enciclopedia di tutte le cose che non sono state inventate, persino i termini, l’atmosfera, l’atteggiamento, il modo di pensare. È semplicemente un problema incredibilmente complicato. Ma in pratica, se metti un tirocinante a guardare il film, lui ti dirà: “Oh, c’è un aereo qui, è male.” Non posso darti l’elenco di tutte le cose sbagliate, ma riesco a individuare questo frammento di follia.
I sistemi di supply chain sono molto simili a questo. È molto difficile fornirti una regola generale per stabilire esattamente cosa conti come assurdo o meno. È un problema di intelligenza generale, non qualcosa che si possa semplicemente condensare in un algoritmo semplice. Ma a quanto pare, le persone sono in realtà piuttosto brave a individuare questi problemi.
Un esempio potrebbe essere: hai una serie di stockouts nei tuoi dati storici, che non sono stati correttamente considerati, e all’improvviso la tua stima della domanda futura scende a zero perché hai avuto stockouts, quindi non hai venduto, e il tuo modello prevede stupidamente zero. Poi finisci per suggerire zero replenishment come buona politica. Dice: “Qual è il tuo livello di stock target? Zero, perché abbiamo osservato una domanda molto bassa, quindi manteniamolo a zero.”
Se ci pensi, sì, la mia previsione sarà accurata al 100% perché sto prevedendo zero, sto rifornendo zero, e tutto dovrebbe andare bene. Ma no, non va bene. Questo problema è definito congelamento dell’inventario. È un esempio di follia, e ci sono molte situazioni come questa in cui, osservando le decisioni, puoi identificare elementi disfunzionali, dove i numeri sono implausibilmente alti o bassi, o semplicemente le cose non hanno senso.
Un esempio che abbiamo avuto storicamente a Lokad, per uno dei nostri primi clienti nel settore aviation, è stato quando abbiamo iniziato a esaminare il replenishment dell’inventario e abbiamo suggerito l’acquisto di alcuni pezzi di ricambio. Il cliente ci ha risposto: “Oh no, non compreremo quei pezzi. Quelli andranno su un Boeing 747, e tra 10 anni non ci saranno più Boeing 747 che volano sopra l’Europa. Quelli hanno una durata di vita di quattro decenni, quindi se li compriamo ora, li useremo solo per 10 anni, e poi quegli aeromobili spariranno.”
Era qualcosa di ovvio in cui avevamo dimenticato di considerare il fatto che l’utilità di un pezzo non può superare la vita utile dell’aeromobile che serve. Questo è il tipo di situazione in cui, a seconda dei settori, la realtà ti offre un flusso infinito di elementi che ti si presentano come manifestazioni di quelle follie. Anche se non posso darti una regola generale o un algoritmo per rilevarle, in pratica funziona molto bene perché le persone riescono a individuarle.
Ian Wright: Adesso siamo brutalmente sulla stessa pagina, stranamente, perché so che vogliamo discutere di alcune cose che stanno per arrivare. Il mio principio fondamentale nella mia carriera, in termini di aver lavorato con tutta questa tecnologia e di averla introdotta nelle aziende, è sempre stato che non si può escludere l’umano. Bisogna tenere conto dell’umano e sfruttarlo nel processo di implementazione e utilizzo della tecnologia.
Perché in questo momento, e per il mio futuro prevedibile, non abbiamo tecnologia che possa sostituire molti degli aspetti umani di cui stai parlando, in termini di riconoscimento dell’assurdo, per esempio, o riconoscimento del folle. Semplicemente non esiste ancora. L’unico modo per farlo esistere è cercare in qualche modo di incorporare aspetti dell’umano nel processo. Oggi non è semplicemente fattibile.
Joannes Vermorel: Sì, sono d’accordo con te. Ci sono due aspetti a cui vorrei rispondere ai tuoi commenti. Innanzitutto, a volte le decisioni folli possono essere riconosciute come tali solo dopo i fatti. Devi commettere l’errore per renderti conto che qualcosa di inaspettato è accaduto ed è andato male. Ma, più che l’umano, è necessario che l’informazione ritorni dal mondo. Hai bisogno di un feedback reale per ottenere queste informazioni. Quindi, si tratta di una questione di intelligenza di alto livello. Anche se avessimo un’intelligenza artificiale altrettanto intelligente quanto un essere umano, ci sono dei limiti. In una certa misura, l’unico modo per conoscere il mondo è concedersi un po’ di margine per sperimentare. Questo sarebbe il primo aspetto.
Il secondo riguarda il ruolo delle persone. Il modo in cui i miei colleghi hanno progettato i sistemi è che usano gli esseri umani come co-processori. Il tuo sistema genera decisioni, numeri, allocazioni di risorse e così via. Poi hai tutte quelle righe che sono assurde e ti aspetti di avere un esercito di impiegati che intervengono manualmente per sistemarle. Per il pubblico, tutti i sistemi che hanno alert ed eccezioni fanno proprio questo. Gli alert e le eccezioni sono solo un altro modo per dire che abbiamo co-processori umani che elaborano ciò che il mio sistema non elabora.
Il mio problema con questo è che le persone sono piuttosto costose. Questo è il costo. Quindi, a mio avviso, non è un uso molto efficiente del loro tempo, perché quei co-processori umani finiranno per ripetere all’infinito le stesse sciocchezze degli stessi alert ed eccezioni.
Ecco perché da Lokad lo affrontiamo in modo completamente diverso. Diciamo che ogni volta che viene rilevata una sciocchezza, come un alert o un’eccezione, qualcuno a Lokad, il Supply Chain Scientist, deve intervenire e regolare l’implementazione di ciò che sta eseguendo l’ottimizzazione predittiva, in modo da risolvere il problema e impedire che si ripeta. Niente eccezioni. Ogni singolo episodio di sciocchezza che viene rilevato viene valutato. È davvero una sciocchezza oppure è un’ottimizzazione molto intelligente? Se risulta davvero essere sciocchezza, allora la logica di ottimizzazione stessa deve essere corretta. Non vuoi che lo stesso dipendente segnali lo stesso problema il giorno successivo.
Ian Wright: Penso che siamo ancora sulla stessa linea, certamente sullo stesso capitolo. Io vengo da una prospettiva più strategica e tattica, dove non mi preoccupo di andare a guardare una stanza piena di persone in stile Big Brother davanti a schermi al computer a correggere le cose. Sto parlando di ciò che è necessario per l’implementazione delle operazioni in un senso strategico o tattico. Significa coinvolgere il portatore di interessi esperto per mantenere il buon senso nella direzione intrapresa e nelle soluzioni adottate.
Quando si parla dell’idea complessiva in cui penso che tu stia inquadrando il tuo argomento, Joannes, man mano che progrediamo con il tipo di tecnologia che stai sviluppando e che hai sviluppato, e con il generale spostamento verso una maggiore capacità in termini di AI, la possibilità per un sistema di auto-correggersi in un contesto di gestione degli eventi diventerà più fattibile. Ci allontaneremo dalla costosa realtà di sale piene di operatori al computer. Ma non è così oggi, quindi bisogna operare entro i limiti delle capacità che si hanno al momento.
Conor Doherty: Se posso, solo perché sembra, Ian, che tu stessi commentando di più sul ruolo dell’umano in senso strategico, e Joannes, sembri commentare di più sul processo decisionale nel quotidiano banale. Questi sono ambiti che non si sovrappongono?
Joannes Vermorel: Questo perché, vedi, la mia prospettiva – e forse è un po’ strana – è che se entriamo nel campo della considerazione strategica, allora il tuo focus nell’operare una supply chain dovrebbe concentrarsi su come ingegnerizzare il meccanismo che genera le decisioni corrette. La gente pensa che esistano decisioni strategiche, tattiche, e così via. La mia visione è che ci sono decisioni che sono ripetibili. Alcune si ripetono ogni giorno, altre ogni ora, altre ogni mese, altre una volta all’anno. Quando si tratta di meccanizzazione, bisogna meccanizzare tutto ciò che si ripete con una frequenza ragionevole, lasciando gestire in maniera completamente ad hoc le altre.
La strategia, se inizi a pensare a questo approccio, non riguarda tanto il decidere qualcosa a un certo livello per poi lasciare che altri livelli della tua organizzazione svolgano il loro compito in altri ambiti. È più che altro la visione strategica che determina cosa fare affinché la cultura ingegneristica della mia azienda, da questa cultura, emerga in processi decisionali meccanizzati che migliorino davvero il mio risultato finale. È un modo completamente diverso di concepire la strategia.
Ian Wright: Sono completamente d’accordo con te. Il modo in cui l’ho spesso visto è il ruolo dell’architetto nel progettare il concetto di un edificio, che poi viene affidato all’ingegnere che decide come sarà messo insieme, poi all’impresa di costruzioni che effettivamente lo realizza, e infine alle persone che vi lavorano e lo mantengono. A tutti questi livelli, l’architetto non dovrebbe mettere insieme qualcosa che non possa essere ingegnerizzato, costruito o mantenuto. Questa è la mia analogia ad alto livello del processo in cui siamo coinvolti.
Nel supply chain, però, è un po’ diverso perché potresti creare una strategia oggi, ma devi farlo di nuovo l’anno prossimo. Il problema con il supply chain è che è dinamico e adattivo. Dobbiamo rispondere al mondo in continuo cambiamento e alle sue esigenze. Ripeti il processo strategico, ma devi farlo in maniera fattibile, pragmatica e che ti permetta di implementare una soluzione operativa.
Joannes Vermorel: Solo per darti un po’ di prospettiva, durante i lockdown del 2020 e del 2021 abbiamo avuto una serie di clienti, più di una dozzina, i cui lavoratori in ufficio (white-collar) sono andati in ferie per 14 mesi. Lokad si è ritrovata da sola a prendere tutte le decisioni del supply chain per aziende in cui la forza lavoro operativa (blue-collar) era ancora operativa. I lavoratori in ufficio erano in ferie governative, sovvenzionate. Venivano pagati, ma i governi europei imponevano anche che non si lavorasse da casa, altrimenti non si sarebbero percepite le sovvenzioni. Quindi, erano effettivamente in congedo.
Gestiamo, per una dozzina di clienti, un inventario del valore di oltre un miliardo di euro operato interamente per 14 mesi. Ciò rappresentava complessivamente più di mille dipendenti. E questo pone davvero la domanda su cosa stiano realmente fornendo quei processi di supply chain, presumibilmente strategici.
Quando guardo la maggior parte delle riunioni di S&OP, si instaurano lunghe discussioni per decidere quanto budget allocare per gli acquisti per i vari reparti. Tutto ciò può essere sostituito da una formula. Se non siamo d’accordo con una formula perché dà risultati assurdi, allora la sistemiamo. Ma non c’è bisogno di incontrare 12 direttori e rivedere tutte le spese per arrivare a questo calcolo di budget. Può essere automatizzato.
In termini di strategia, la domanda sarebbe: come faccio a garantire che l’ingegneria che sta dietro questa formula, che alloca le mie risorse di alto livello, venga realizzata in modo da essere allineata con gli interessi della mia azienda? È un problema molto interessante e sì, questo dovrebbe catturare l’interesse della direzione che vuole pensare in maniera strategica. L’idea di scegliere a mano alcune decisioni e dire “io mi occuperò di quello” non aggiunge davvero molto valore.
In molte aziende, in quelle che sono supposte riunioni strategiche, si spreca molto tempo. Sì, generano decisioni, ma con una produttività assolutamente abissale. Ricordo che un ospite precedente discuteva di S&OP e mi diceva che di solito finivano per prendere circa quattro decisioni all’ora.
Conor Doherty: Era Eric Wilson, sì, in un processo S&OP.
Joannes Vermorel: Sì, e stavo pensando, va bene, abbiamo davanti a noi centinaia di migliaia di decisioni da prendere, e ora abbiamo un ritmo di quattro decisioni all’ora. È ovvio che quando ti trovi in una situazione del genere, le operazioni saranno sempre ben avanti rispetto ai tuoi piani.
Quando finalmente prendi le decisioni, esse risultano completamente superate, e le persone hanno già fatto altro perché non potevano aspettare così tanto per quelle decisioni. Finisci in una situazione simile a una mascherata. Le persone prendono decisioni strategiche per eventi che sono già accaduti, tipo due anni fa.
Conor Doherty: Beh, questo mi interessa. Solo per prepararti al seguito, perché so che nel paper hai parlato di un decision-making della supply chain più decentralizzato, e hai fatto l’esempio di Walmart.
Puoi descriverlo meglio di quanto io riesca a fare.
Ian Wright: Farlo correttamente ed efficacemente significa decentralizzare la decisione, ma quella decentralizzazione e il processo decisionale avvengono comunque in un contesto progettato in modo efficace e appropriato, in modo da non allontanarti troppo dalla strategia centrale aziendale. È quasi come una scala mobile della strategia che scende fino alle operazioni.
In tal caso, stiamo parlando della decentralizzazione di quelle che definirei decisioni più tattiche. Ma tutto torna al punto di Joannes. Non sono per nulla in disaccordo con te. Quello di cui parliamo è che le persone non lavorano solo in silos all’interno delle organizzazioni, ma pianificano e operano anche in silos. I ragazzi della supply chain vanno a elaborare il loro piano strategico della supply chain, poi pensano al piano di trasporto e infine al piano di magazzino.
Tutti questi piani sono interdipendenti e, sfortunatamente, spesso eseguiti in maniera indipendente. Fondamentalmente, non possiamo arrivare a una soluzione strategica ottimale della supply chain a meno che non incorporiamo un piano di rete, un piano di trasporto e un piano di inventario in un modello operativo.
L’intera situazione di Lokad, che opera senza i dipendenti in abiti formali nell’edificio, è per me un ottimo esempio di avere un modello operativo che ti consente di sostenere le operazioni e di non discostarti troppo dal piano che credevi necessario per operare sei mesi fa, nonostante le disruption. Hai messo insieme le persone giuste, i processi giusti, e hai la tecnologia e i programmi necessari per supportare quell’esecuzione.
Sostengo davvero molto di più rispetto a tutta questa idea di ottenere l’ottimalità perfetta. Puoi avere un piano ottimale, ma devi essere in grado di eseguirlo e mantenerlo il più fedelmente possibile. Senza quel modello operativo – e vado oltre il tradizionale people, process e technology – devi averlo in atto. Quello è davvero il tuo piano strategico aziendale, e tutti gli altri piani strategici relativi alla supply chain devono operare nel contesto di quello. Se non abbini il modello operativo che possiedi ai piani che stai elaborando, allora quella sarà una ricetta per il disastro.
Conor Doherty: Ian, se posso riassumere ciò in una citazione, hai detto in precedenza che non si possono escludere gli umani. Quindi, Joannes, sei d’accordo che non si possa escludere l’umano, in particolare nel processo decisionale strategico di cui parla Ian? È qualcosa che potrebbe essere inserito in un framework automatizzato che hai già applicato alla gestione quotidiana e più banale dell’azienda?
Joannes Vermorel: Per quanto riguarda la domanda se abbiamo un’intelligenza artificiale generale, la risposta è no. Ci stiamo avvicinando, in modo concorde. Gli LLM mostrano scintille di intelligenza generale, ma solo scintille. Quindi, direi che al momento in Lokad, certamente non possiamo affermare di avere un software così sofisticato da poter bypassare la necessità della mente umana. In effetti, al centro della nostra pratica, abbiamo quelli che chiamiamo Supply Chain Scientist, che sono ingegneri che codificano le ricette numeriche. È una cosa molto umana che non stiamo ancora delegando alle macchine.
Anche se gli algoritmi possono aiutare a programmare più velocemente grazie all’autocomplete e simili, la vera domanda è: quando hai intelligenze umane, vengono impiegate in compiti che aggiungono realmente valore grazie al fatto che possiedono intelligenza generale, invece di essere semplicemente dei riconoscitori di schemi o qualcosa che può essere meccanizzato?
La mia controargomentazione sarebbe che molte aziende, soprattutto quelle che operano supply chain, non sfruttano al meglio il potenziale dei loro impiegati. Sono ancora imprigionate nella mentalità di avere orde di impiegati aziendali che seguono un processo, e la conformità al processo è il loro obiettivo.
Vedo molte di quelle aziende che operano supply chain trattare la maggior parte dei loro impiegati in bianco esattamente come trattano quelli in blu. C’è un processo, e l’aderenza al processo è definita come eccellenza.
Per gli operai è chiaro, è quello che serve. Ma se entriamo nel territorio degli impiegati, diventa molto strano perché l’informazione è di ordini di grandezza più facile da meccanizzare rispetto al mondo reale.
Gestire cose fisiche, per esempio, se vuoi avere un robot in grado di saldare in ogni situazione, è estremamente difficile. Solo muovere una mano, tenere uno strumento, sostenere qualcosa di pesante e trovarsi in un ambiente con polvere o contaminanti: stiamo parlando di robotica estremamente avanzata solo per fare qualcosa che una persona potrebbe apprendere in pochi mesi di formazione.
Ora, se entriamo in questo mondo dell’informazione, sai, sulla carta, i vincoli non sono affatto così esigenti. Possiamo spostare gigabyte di dati senza problemi. Le persone che svolgono quei lavori in ufficio stanno già utilizzando sistemi informatici. Tutte le informazioni che ricevono provengono da un computer, e tutte le informazioni che producono vengono già inserite in un computer. Quindi, abbiamo un sistema che è già interamente digitale.
Quello che sto dicendo è che le aziende stanno usando la maggior parte dei loro impiegati come co-processori. Hanno ciò che il processore del computer può fare con il software di cui disponiamo, e poi c’è sempre qualcuno nel mezzo a colmare le lacune. Ma stiamo davvero sfruttando l’intelligenza di quelle persone? Il mio argomento è no. Se c’è una questione di importanza strategica, è assicurarsi che tutti gli impiegati contribuiscano in ambiti dove solo l’intelligenza generale può fornire risultati. Se si tratta di qualcosa in cui non è necessaria l’intelligenza generale, allora dovrebbe essere meccanizzato.
Ian Wright: Sono d’accordo. Il tuo focus sull’approccio meccanicistico è ciò che definisce cosa sia l’automazione e per cosa serva l’umano. Il momento in cui l’umano fornisce realmente valore, e come dici tu, Joannes, probabilmente non è implementato correttamente, è nelle aree intuitive dove non puoi fornire input meccanicistici. Ad esempio, considerando che un aereo sarà obsoleto tra 10 anni, perché lo faremmo? È qualcosa che non si può costruire meccanicisticamente.
Dove serve l’intervento umano è dove occorre fornire un contributo organico a un problema o a una situazione, sia che si tratti della gestione degli eventi o della gestione operativa della supply chain. È abbastanza semplice implementare meccanismi diagnostici. Un ambito che è ancora ricco di possibilità è l’impiego di cicli di feedback che aiutano a generare soluzioni proattive in un contesto meccanicistico. Questo include l’accumulo di informazioni provenienti da una più ampia varietà di fonti dati per quella gestione operativa meccanicistica proattiva. Ma non si batte il lato intuitivo delle cose. C’è un aspetto emergente in ciò che un essere umano apporta in un contesto in cui cerca di analizzare un problema o, più importante, anticiparne uno.
Joannes Vermorel: Sono completamente d’accordo. Qui darei la colpa alla prospettiva delle serie temporali. La prassi prevalente nelle supply chain al giorno d’oggi ruota attorno alle serie temporali. Ma se guardi le aziende che sono molto brave in quello che fanno, sono molto brave nel fare qualcosa di intelligente con il feedback che ricevono, come Amazon. Amazon utilizza in modo molto intelligente il feedback dei suoi clienti per risolvere in maniera sistematica la maggior parte dei loro problemi di supply chain e logistica.
Se un corriere viene abitualmente segnalato per aver perso pacchi, Amazon smetterà di usare quel fornitore e passerà a un altro. Se un venditore crea problemi, lo cacceranno. Sfruttano in modo ragionevole i dati di feedback che raccolgono. Hanno bisogno di persone capaci di immaginare che tipo di feedback raccogliere e di ingegneri per elaborare le ricette numeriche che decidono quando cacciare un venditore o notificare un fornitore logistico.
Probabilmente fanno un’ottimizzazione intelligente, per esempio notando che un trasportatore è affidabile in determinate condizioni ma non in altre, e utilizzando questo trasportatore soltanto in quei contesti. Ciò richiede una visione su quali siano i dati rilevanti, non solo le serie temporali sulla domanda. Serve una mentalità ingegneristica per fornire soluzioni profonde ai problemi, non solo per intervenire d’urgenza. La maggior parte delle aziende passa da un’emergenza all’altra, consumando tutta la loro capacità e impedendo miglioramenti. Amazon, invece, ingegnerizza soluzioni profonde per ogni situazione incontrata, eliminando categorie di problemi e passando alla successiva.
Ian Wright: Sfortunatamente, tutto ricade sulle finanze. Se hai le tasche profonde per avere quel tipo di processo mentale a cui alludi, è una cosa. Ma la maggior parte dei manager della supply chain non lavora in un ambiente in cui abbondano i soldi per affrontare i problemi in questo modo. Sono sempre in ritardo, a spegnere incendi, e in un circolo vizioso.
Se hai l’opportunità, come professionista, di lavorare su un progetto strategico, non mettere il modello al primo posto. Comprendi il mondo del manager della supply chain com’è oggi, poi pensa come se fossi Amazon e sviluppa un’idea di come quel mondo possa funzionare in modo che non siano sempre a rincorrere il tempo. Purtroppo, la maggior parte dei manager della supply chain affronta i progetti strategici nello stesso modo del lavoro quotidiano, che è solo un altro incendio da spegnere. Le persone di entrambe le parti non lo affrontano correttamente, ma potrebbe essere approcciato in modo diverso ripensando al ruolo.
Conor Doherty: Signori, sono consapevole del tempo, quindi vorrei tornare su di te, Ian, e chiederti dell’ottimalità pratica. Per orientarci verso una conclusione, quali sono i passi pratici che le persone possono compiere nella ricerca dell’ottimalità?
Ian Wright: Ancora, lo affronto da un punto di vista strategico, non da quello del tizio in officina che cerca di mettere il prodotto nelle mani del cliente. Quello che devi fare quando consideri l’ottimalità è riflettere su come verrà effettivamente eseguita quell’implementazione. Assicurati di concentrarti sul portare in tavola una soluzione fattibile e operativa, che si adatti al modo in cui l’azienda opera oggi.
Se hai la capacità e la libertà, elabora una soluzione che raggiunga l’ottimalità in un contesto che possa essere eseguito in maniera ottimale. Comprendi i veri obiettivi degli stakeholder, i veri obiettivi degli sponsor e i veri obiettivi dell’azienda, e non solo quelli osservati o dichiarati. Nella misura in cui sono disposti ad ascoltare, prova a produrre una soluzione in quella direzione. In ogni momento, assicurati di lavorare con persone, non solo con il modello.
Conor Doherty: Grazie. Joannes, qualcosa da aggiungere a riguardo?
Joannes Vermorel: No, penso sia un buon punto. Dal punto di vista di un fornitore di software, direi che per quanto riguarda l’ottimalità, non bisogna fidarsi troppo dei software vendors. Sì, ovviamente, tranne noi. In particolare, tieni presente che esistono classi di software come i sistemi di registrazione e i sistemi di report che non si occupano di decisioni e quindi non possono occuparsi affatto di ottimizzazione.
I sistemi di registrazione, come ERP, CRM, WMS, e i sistemi di report, come business intelligence, sono spesso pubblicizzati come capaci di generare decisioni ottimizzate. Per loro design, queste classi di software non toccano nemmeno il problema. Non ottimizzano affatto. Quindi, il mio messaggio sarebbe: non cercare la via verso l’ottimalità nel tuo prossimo aggiornamento ERP. Per definizione, un ERP è un sistema di registrazione. Non si occupa di decisioni e si preoccupa ancora meno del fatto che quelle decisioni possano essere ottimali in qualsiasi forma.
Conor Doherty: Mi assicurerò di inserire quell’articolo davvero carino—beh, un articolo breve, come intendevo dire. In esso, parli di sistemi di registrazione, sistemi di report e sistemi di intelligence. Ma qui è consuetudine dare la parola finale all’ospite. Quindi, se c’è qualcos’altro che vuoi menzionare o qualcosa che non abbiamo detto, puoi chiudere senza interruzioni.
Ian Wright: Sì, mi piace. Dal punto di vista di un fornitore di software, non fidarti dei software vendors. Mi piace davvero questo concetto perché, in oltre 40 anni, una delle cose che mi ha sempre infastidito è stata l’enorme clamore intorno alla tecnologia. Il clamore sull’intera idea della supply chain, per molto tempo, a mio avviso, è stato un certo tipo di clamore. E in effetti, ne ho scritto, Conor, cosa che non ti sorprenderà. Ma penso che quello che dobbiamo fare è imparare a vivere in un mondo in cui sai come farti strada attraverso il clamore, muoverti tra le difficoltà e capire cosa funziona davvero. Questa è la chiave—ciò che è reale.
Conor Doherty: Beh, a proposito, direi che non ho altre domande. Joannes, grazie per il tuo tempo. Ian, grazie mille per esserti unito a noi.
Ian Wright: Grazie, ragazzi. È stato un privilegio per me essere stato invitato da voi, e non vedo l’ora di saperne di più su Lokad e di scoprire se sono pazzo o no. Questa è la chiave.
Joannes Vermorel: Sì, una delle chiavi. Ti invieremo una diagnosi.
Conor Doherty: Grazie e grazie per averci seguito. Ci vediamo alla prossima.
