00:00:00 Introduzione all’intervista
00:00:47 Background di Paul Jan e esperienza nell’insegnamento
00:02:16 Ruolo dei dati nella supply chain e nell’insegnamento
00:04:00 Collaborazione con Lokad e il suo impatto
00:06:20 Sfide reali nella supply chain e ostacoli nell’insegnamento
00:10:49 Spiegazione dei problemi ‘complessi’ nella supply chain
00:14:37 Impatto della messaggistica aziendale sulla percezione del prodotto
00:16:11 Analisi continua dei dati e limitazioni di Excel
00:19:11 Gestione dei dati relazionali e limitazioni di Excel
00:21:49 Transizione a SQL per l’elaborazione dei dati
00:24:11 Benefici dell’introduzione di Lokad agli studenti
00:26:33 Considerazioni sui costi nell’insegnamento della supply chain
00:29:13 Uso di Envision e critica del software aziendale
00:32:24 Pensiero di soluzione e limitazioni degli strumenti
00:35:16 Migliori strumenti per migliori soluzioni nella supply chain
00:37:57 Esperienza e filosofia di insegnamento di Joannes Vermorel
00:41:15 Strutture dati fondamentali e limitazioni delle previsioni
00:45:31 Metodi di insegnamento visuale e assunzioni solide
00:48:32 Necessità di interruzione nell’industria della supply chain
00:51:12 Supply chain come una collezione di problemi complessi
00:54:24 Essere approssimativamente corretti nella supply chain
00:57:55 Insegnare la complessità nella supply chain
01:00:47 Parole finali e importanza degli investimenti del settore privato
01:03:24 Superare la paura delle statistiche e osservazioni conclusive
Riassunto
Conor Doherty, conduttore di Lokad TV, ha recentemente intrapreso una discussione con Joannes Vermorel, fondatore di Lokad, e Paul Jan, professore di supply chain presso l’Università di Toronto. La conversazione si è incentrata sul campo in evoluzione della gestione della supply chain, sul ruolo dei dati e sull’importanza dell’istruzione. Vermorel ha introdotto il concetto di “problemi complessi” nella supply chain, evidenziando i limiti di Excel e la necessità di strumenti come SQL Server. Jan ha condiviso la sua esperienza nella transizione da Excel a opzioni più programmatiche, elogiando lo strumento di Lokad, Envision. Entrambi hanno sottolineato la necessità di una interruzione nell’industria e l’importanza dell’istruzione nella gestione della supply chain.
Riassunto Esteso
In un’intervista recente, Conor Doherty, il conduttore, ha intrapreso una discussione stimolante con Joannes Vermorel, il fondatore di Lokad, e Paul Jan, professore associato di Operations and Supply Chain Management presso la Rotman School of Management. La conversazione ruotava attorno all’evoluzione del panorama della gestione della supply chain, al ruolo dei dati e all’importanza dell’istruzione in questo campo.
Paul Jan, con la sua vasta esperienza nella consulenza e nel mondo aziendale, insegna da circa quattro anni corsi di analisi delle operazioni e della supply chain presso l’Università di Toronto. I suoi corsi, che includono una classe fondamentale sulla gestione delle operazioni e della supply chain e una classe in collaborazione con Lokad, mirano a colmare il divario tra teoria e pratica. Jan riconosce che, sebbene i dati siano diventati più prominenti nell’industria, gli studenti spesso mancano di fiducia nell’applicare ciò che imparano al mondo reale. Qui entra in gioco la collaborazione di Lokad, fornendo un ambiente pronto per gli studenti per lavorare su compiti legati alla supply chain, consentendo loro di concentrarsi sugli aspetti della supply chain anziché sulle tecniche di configurazione di un ambiente di codifica.
Vermorel ha introdotto il concetto di “problemi complessi” nella supply chain, che sono problemi che sfidano un’analisi diretta di primo livello e richiedono un percorso di scoperta. Ha evidenziato i limiti di Excel nel gestire i dati moderni della supply chain, affermando che non scala nella misura richiesta dalle supply chain di oggi. Vermorel ha suggerito che la risposta di Microsoft a questo problema sia SQL Server e altri strumenti che gestiscono dati relazionali. Ha anche menzionato che il playground di Lokad mira a esporre gli studenti alla realtà dei dati relazionali.
Jan ha condiviso la sua esperienza nella transizione da Excel a opzioni più programmatiche, concordando con i punti di Vermorel sui limiti di Excel. Ha menzionato di aver imparato SQL in uno dei suoi progetti e di aver apprezzato la sua potenza nel processare e semplificare i dati. Jan ha anche elogiato Envision, lo strumento di Lokad, per la sua semplicità e facilità d’uso, che ha contribuito a semplificare il processo di regolazione delle ipotesi e a ridurre gli errori che potrebbero verificarsi in Excel.
La conversazione si è poi spostata sulla mentalità necessaria per utilizzare questi strumenti e se in classe vengano insegnati concetti come il costo opportunità. Jan ha risposto che, sebbene il concetto di costo opportunità non sia semplice, gli studenti con una formazione in economia possono comprenderlo. Ha notato una discrepanza tra ciò che i dirigenti e gli operatori operativi comprendono e a cui prestano attenzione, con i primi che si concentrano sui risultati finanziari e i secondi sulle metriche tradizionali.
Vermorel ha concordato con i punti di Jan e ha discusso dei limiti del pensiero all’interno del paradigma di Excel. Ha spiegato che se Excel è l’unico strumento a cui si può pensare, limita le soluzioni che si possono immaginare. Vermorel ha criticato la percezione che le tecnologie digitali siano in continua evoluzione e che le conoscenze nel campo siano usa e getta. Ha sostenuto che molti argomenti fondamentali, come la struttura dei dati relazionali e i tipi di dati di base, difficilmente cambieranno significativamente nel tempo.
L’intervista si è conclusa con Vermorel e Jan che hanno sottolineato la necessità di una interruzione nell’industria e l’importanza dell’istruzione nella gestione della supply chain. Vermorel ha spiegato che la gestione della supply chain comporta una serie di problemi complessi a causa della natura interconnessa delle aziende moderne. Ha sostenuto l’uso di paradigmi e strumenti in grado di gestire questi problemi complessi, anziché cercare soluzioni esatte che potrebbero essere errate. Jan, d’altra parte, ha descritto il suo approccio didattico come graduale e dirompente, partendo dalle teorie tradizionali prima di introdurre complessità del mondo reale attraverso la collaborazione con aziende come Lokad. Ha riconosciuto la difficoltà di insegnare problemi complessi, che sono complessi e dipendono dalle azioni degli altri.
Trascrizione Completa
Conor Doherty: Bentornati a Lokad TV. Le competenze richieste per eccellere nella supply chain sono cambiate radicalmente negli ultimi 20 anni e continueranno a farlo per il momento. Nulla di tutto ciò, ovviamente, è una novità per gli ospiti di oggi. Unendoci da remoto alla Rotman School of Management, il professore associato di Operations and Supply Chain Management, Paul Jan. Paul, benvenuto a Lokad. Grazie per avermi qui. È un piacere essere qui.
Ora Paul, ho detto, benvenuto a Lokad, un po’ un nome improprio. Voglio dire, siamo già molto familiari. Hai collaborato con noi per un po’ di tempo e infatti, ci hai visitato qui negli uffici nuovi a Parigi. Ma per le persone che non sono familiari con il tuo lavoro, potresti fare una presentazione, descrivere il tuo background, per favore?
Paul Jan: Grazie per avermi qui. Mi chiamo Paul Jan. Attualmente sono professore presso l’Università di Toronto, dove insegno corsi di analisi delle operazioni e della supply chain. Vengo da un background industriale con una vasta esperienza nella consulenza e nell’industria americana. Ho trascorso gli ultimi 15 anni circa sia nell’industria che nella consulenza, e ora sto insegnando, condividendo le mie conoscenze e esperienze con tutti gli studenti qui a UofT.
Conor Doherty: E da quanto tempo insegni alla Rotman School of Management?
Paul Jan: Sono alla Rotman da circa quattro anni e, prima di questo, ero all’Università della California, Irvine. Quindi, in totale, insegno da circa sette anni.
Conor Doherty: E come sono evoluti i corsi sulla supply chain anche solo in quel breve periodo di tempo?
Paul Jan: Qui alla Rotman, insegno una classe fondamentale, che è un’introduzione alle operazioni e alla gestione della supply chain. È lì che gli studenti imparano le teorie fondamentali, le applicazioni e alcune delle pratiche. Insegno anche un altro corso in collaborazione con Lokad. Si tratta di prendere quelle teorie e pratiche e metterle in pratica con un’azienda. Nel corso degli anni, ci sono sempre più dati disponibili dalle aziende ERP, e anche dalle aziende di medie e piccole dimensioni, tutte hanno qualche tipo di sistema di acquisizione dati o ERP. Quindi i dati sono diventati più prominenti e gli studenti, da quanto ho osservato, mancano di fiducia ed esperienza su come applicare ciò che imparano a scuola nel mondo reale.
Conor Doherty: Beh, e Joannes, arriverò da te tra un attimo, ma voglio solo approfondire questo perché hai un’ampia esperienza nel settore privato. Quando selezioni le teorie fondamentali da insegnare agli studenti, quanto di ciò è conoscenza tradizionale della supply chain e quanto è influenzato dalla tua vasta esperienza?
Paul Jan: Nella classe fondamentale che insegno, non ho molto spazio per deviare. Devo seguire un programma e i requisiti stabiliti dall’università e dal dipartimento. Quindi la maggior parte di quelle sono le teorie e i modelli tradizionali che uno studente imparerà. Quello che faccio è integrare quelle con aneddoti e storie o cose a cui fare attenzione come integrazione per gli studenti quando entrano nel mondo del lavoro. Ma come requisito della scuola, le fondamenta sono le teorie tradizionali, che è ciò che impareranno in quella classe. Nell’altra, nella collaborazione con Lokad, ho la libertà di applicare di più l’insegnamento da un punto di vista del praticante. Quindi in termini di essere consapevoli delle realtà, essere consapevoli delle linee di fondo finanziarie, che dal punto di vista finanziario, le teorie tradizionali fondamentali non tengono conto di questo. Ma nella pratica, gli esecutivi guarderanno l’impatto finanziario di fare XYZ. Quindi questa è la differenza tra le due e come applico la mia esperienza a queste diverse classi.
Conor Doherty: Beh, grazie, Paul. E ora Joannes, passiamo a te, potresti descrivere esattamente quale è la collaborazione con Paul come parte dell’iniziativa educativa più ampia di Lokad?
Joannes Vermorel: Sì, da Lokad abbiamo avviato un’iniziativa circa un anno fa per rendere la nostra infrastruttura tecnologica più ampiamente disponibile. Normalmente, Lokad viene fornito come un software aziendale, accessibile solo ai nostri clienti e prospetti VIP. Quello che abbiamo fatto è riproporlo come quello che abbiamo chiamato un playground, che è una versione leggermente semplificata di Lokad accessibile su tr.lo.com. Questo offre un ambiente di programmazione basato su Envision e un piccolo sistema di file. In termini di scopi educativi, l’idea è quella di avere una serie di workshop in cui gli studenti possono effettivamente prendere un set di dati che è una versione semplificata di ciò che si trova nelle configurazioni reali ma comunque abbastanza rappresentativo. Non volevamo rendere il compito troppo facile e troppo teorico. L’idea è che possiamo fornire un ambiente pronto in cui lo studente può iniziare direttamente con un set di dati e una piccola sfida di un compito di supply chain che deve essere eseguito su questo set di dati. Questo riflette il tipo di sfide che le persone possono avere quando entrano in un’azienda in cui ci sono problemi con i fornitori. È necessario analizzare e capire chi sono i fornitori che non sono in grado di consegnare in tempo e in modo completo, o si desidera prevedere la domanda o qualsiasi altra di quelle attività analitiche di supply chain. L’idea è che Lokad voleva fornire un ambiente per farlo. Il motivo è che gli studenti che studiano materiali di supply chain non sono ingegneri del software. Quindi sì, se chiedessi a una classe piena di futuri ingegneri del software di farlo, potrebbero prendersi il tempo per configurare un ambiente Python, per configurare la propria pipeline di dati e la logica di parsing e così via in modo da poter effettivamente lavorare su un set di dati utilizzando tecnologie open-source. Il problema è che considerando il periodo di tempo che abbiamo per gli studenti che non sono ingegneri del software ma ingegneri della supply chain o futuri ingegneri della supply chain, abbiamo bisogno di un ambiente pronto per un workshop che riguarda principalmente la supply chain, non le complessità di come analizzare un file CSV in Python. Quindi quel tipo di cose deve essere prontamente preparato, ed è quello che possiamo fare con questo ambiente. Condividiamo un ambiente in cui i dati sono già stati preparati, lo script che legge i dati è già stato scritto, quindi possono passare direttamente al cuore del problema, che è capire cosa fare con una supply chain, con un fornitore, con la domanda, e applicare il ragionamento della supply chain attraverso uno strumento programmabile. La nostra ambizione è quella di consentire a quei curricula che sono tipicamente molto leggeri in termini di strumenti tecnici di fare cose più avanzate ma senza essere completamente bloccati in pura tecnica. Quindi in sintesi, forniamo un ambiente che potrebbe essere replicato senza problemi in 5.000 righe di codice Python. Questo è molto fattibile, ma il problema è che se lo fai, allora improvvisamente non puoi aspettarti di fare una sessione di lavoro di tre ore fruttuosa con i tuoi studenti di supply chain. Staresti facendo una sessione di codifica di tre ore in cui scopriresti solo come analizzare un file CSV, cosa che non è molto interessante dal punto di vista della supply chain.
Conor Doherty: E Paul, solo un approfondimento su questo. Quanto sono impegnative queste competenze ingegneristiche come la codifica per gli studenti di supply chain di livello fondamentale medi?
Paul Jan: Posso darti un esempio concreto in cui abbiamo iniziato il semestre qui un paio di settimane fa. Direi che forse il 20% di questa nuova classe ha qualche tipo di esperienza di codifica precedente, ma in quel caso avevano già seguito, ad esempio, un corso di Python in aula. Quindi la maggior parte non l’ha fatto. Quando arrivano, penso che siano entusiasti perché si rendono conto che questa è una competenza che li beneficerà in futuro, dato che ci sono molte più cose, molti più dati, ed Excel è solo ingombrante quando si tratta di analizzare una quantità così grande di dati. Quindi la codifica aiuta a semplificare questo processo. Ma allo stesso tempo, sono anche un po’ spaventati, preoccupati perché non hanno esperienza. È una competenza molto importante ora, ma è anche qualcosa che manca nella formazione degli studenti di economia, non solo nella supply chain ma in generale.
Conor Doherty: Beh, grazie. E questo in realtà si collega perfettamente. Joannes, qualcosa che aspetto da molto tempo di chiederti. Hai descritto in passato nelle tue lezioni i problemi della supply chain come “wicked”. Quindi due parti di questa domanda. Primo, cosa intendi esattamente per problemi “wicked” nella supply chain? E secondo, seguendo quanto detto da Paul, perché strumenti come Excel non sono in grado di affrontare questi problemi “wicked”?
Joannes Vermorel: La nozione di problema “wicked” non proviene da me. Sono essenzialmente problemi che sfidano un’analisi diretta di primo livello. È qualcosa in cui deve essere un viaggio, non importa cosa, in cui scoprirai il problema stesso.
Un esempio di ciò è, cos’è un buon annuncio? Se ti chiedo di calcolare l’area di una forma geometrica in pollici quadrati o centimetri quadrati, la forma potrebbe essere molto complicata, quindi il calcolo potrebbe essere difficile, ma è un problema chiuso. C’è una soluzione analitica che ti darà la risposta esatta o un’approssimazione molto buona.
Ma se ti chiedo cosa sia un buon annuncio, la risposta dipende davvero, e dipende anche da ciò che fanno i tuoi concorrenti. Ad esempio, se crei un annuncio fantastico, ma poi i tuoi concorrenti ti copiano così tanto che il tuo annuncio, che era brillante, ora è diventato indistinguibile da tutta la concorrenza, era un annuncio molto buono ma è diventato un annuncio cattivo solo perché tutti lo avevano copiato.
Questo è il tipo di malvagità. La stessa risposta che dai può potenzialmente annullare la risposta stessa. È un po’ strano. Do una risposta molto buona e perché è una risposta molto buona, viene copiata e perché viene copiata, diventa una risposta sbagliata. Questo è un tipo di problema “wicked”.
La supply chain è piena di problemi “wicked”. Decidi di posizionare un centro di distribuzione da qualche parte per superare qualcun altro. Questa persona decide di replicare e rispondere riorganizzando i propri centri di distribuzione per superarti. Questo è il tipo di cosa.
Quindi le cose non sono stabili. Una risposta non è stabile. Questi problemi “wicked” sono problemi in cui sono competitivi per natura. Ci sono persone che rispondono a ciò che stai facendo. Questo non è come il problema di calcolare la superficie di una forma geometrica, che è un problema in cui la risposta non dipende da ciò che il resto dell’universo sta facendo, da ciò che le altre persone stanno decidendo. Questo è ben isolato.
E poi hai anche problemi in cui non sei nemmeno sicuro di aver formulato correttamente il problema. Cosa significa qualità del servizio? Sì, possiamo dire che la qualità del servizio riguarda l’aumento del livello di servizio, ma la realtà è che la qualità del servizio è nell’occhio del cliente e cosa significa davvero? È una domanda molto difficile.
Per alcune persone, potrebbero pensare che se ci sono sostituti, va bene. Non si aspettano che questo prodotto sia disponibile. Forse se ci sono sostituti, vanno bene. Altre persone potrebbero non essere d’accordo. Potrebbero avere una concezione molto limitata di ciò di cui hanno effettivamente bisogno e dicono: “Voglio esattamente questo codice a barre o non funziona”.
E poi, a seconda del messaggio che l’azienda ha, della comunicazione più ampia, potresti effettivamente amplificare o diminuire se le persone vedono altri prodotti come sostituti o meno. Se hai una comunicazione che dice che questa cosa è completamente unica, non c’è alcun sostituto, allora non stupirti se le persone non sono nemmeno disposte a prendere altri tuoi prodotti come sostituti perché quella è la tua comunicazione. Questo potrebbe essere vantaggioso contro la concorrenza, ma può essere più difficile se vuoi convincere le persone ad accettare alternative.
Le situazioni sono incredibilmente varie. Quindi, il punto chiave di questi problemi complessi, e questo è un modo tipico di pensare di Lokad, è che di solito quando hai questi problemi complessi, è meglio iterare sul problema con i dati anziché operare senza dati.
Non importa la domanda che viene posta, come ad esempio se è un buon annuncio, è più facile rispondere a questa domanda se puoi misurare le vendite e correlare un po’ con la tua spesa pubblicitaria, ad esempio. Non significa che risolverà completamente la domanda, ma sarai più informato rispetto a cercare di rispondere a questa domanda senza alcun dato.
Di solito, anche se stai affrontando un problema complesso, avere dati a disposizione aiuta. Il problema è che a causa della natura complessa, è necessario essere in grado di rivedere la propria posizione su quale tipo di analisi e di elaborazione significa che non ci sarà una risposta unica per tutti. Elaborerai i dati e poi penserai e poi potresti fare una domanda leggermente diversa a seconda di ciò che sta accadendo.
Quindi, i problemi complessi, è qui che entriamo in gioco. Quando ti trovi di fronte a un problema complesso, avere dati è buono perché ti permette di essere più informato, il che è generalmente meglio. Ma significa anche che dovrai ripetere la tua analisi di tanto in tanto perché non ci sarà una risposta definitiva.
Excel è buono in questo senso. Excel ti permette di rivedere la tua analisi tutte le volte che vuoi. Il problema è che Excel non scala fino al punto in cui le moderne catene di approvvigionamento richiedono. Oggi stiamo parlando di decine di migliaia di prodotti, milioni di transazioni, molti dati transazionali. Excel semplicemente non è adatto a questo.
La sfida principale è che i dati delle moderne catene di approvvigionamento superano ciò che può essere ragionevolmente inserito in Excel, e superano in due modi. Prima di tutto, superano per il numero di righe. Excel è limitato a un milione di righe. Ma questa parte non è effettivamente il grande problema. In teoria, Microsoft potrebbe rielaborare un po’ Excel e farlo estendere a 100 milioni di righe. Non è impossibile, e in realtà ci sono alcuni concorrenti di Excel che possono farlo.
Ma quando diciamo che una moderna catena di approvvigionamento supera, è che fondamentalmente, Excel ha una mentalità di una sola tabella alla volta. Assume che i dati siano come una tabella piatta. Ma la realtà è che i dati transazionali come si trovano in una catena di approvvigionamento sono tabelle multiple. Hai una tabella per i fornitori, una tabella per le transazioni, una tabella per i clienti, una tabella per i prodotti, una tabella per i colori o le forme o qualsiasi altra cosa.
Quindi, molto spesso ti troverai a che fare con almeno mezza dozzina di tabelle. E quindi ciò di cui hai bisogno è qualcosa come un’algebra relazionale, che è davvero al centro dei tuoi dati transazionali. I tuoi dati nella catena di approvvigionamento sono transazionali e relazionali. Hai come mezza dozzina di tabelle, ed è qui che Excel non funziona davvero.
Non solo hai questo vincolo sul numero di righe, ma questo potrebbe essere risolto. Ma più in generale, hai questo problema che sei limitato in termini di semantica. Excel non ti offre questa cosa di tabelle multiple.
E a proposito, questo è dovuto a una ragione molto più profonda per cui Microsoft non è nemmeno davvero interessata ad espandere questo limite di 1 milione. Le persone di Microsoft sanno, e lo sanno da molto tempo, che anche se possono espandersi fino a 100 milioni di righe, la prossima fase sarà: “Oh, abbiamo bisogno di diverse tabelle”, e poi non funzionerà molto bene con Excel.
Ecco perché la risposta di Microsoft è stata: “Se vuoi dati relazionali, hai SQL Server, o hai strumenti che considerano i dati relazionali come cittadini di prima classe”, invece di cercare di averli in un foglio di calcolo. E a proposito, questo è anche qualcosa che stiamo cercando di fare con questo playground, è quello di far conoscere agli studenti questa realtà dei dati relazionali offrendo un linguaggio che ha i dati relazionali come cittadini di prima classe.
Perché è qualcosa in cui credo che non cambierà. Quarant’anni da ora, gli ERP avranno ancora tabelle e colonne. Questa cosa è stata stabilita quattro decenni fa, quindi è stato un aspetto molto stabile della catena di approvvigionamento digitale per più di quattro decenni già.
Conor Doherty: Paul, un punto interessante da approfondire perché hai una vasta esperienza nel settore privato e sei stato addestrato in questo campo. Quando stavi sviluppando la tua esperienza, presumo che tu abbia lavorato con Excel. E se sì, a che punto hai detto: “Devo considerare opzioni più ricche e più programmatiche”? Quindi, cosa ha causato la divergenza da Excel?
Paul Jan: La divergenza è ciò a cui Joannes ha accennato prima. Excel è ottimo, sai, è un tipo di una tabella alla volta, ed è molto complicato collegare tutte queste tabelle o schede all’interno di Excel. E anche se hai successo nel farlo, è anche un altro compito molto dispendioso in termini di tempo se devi cambiare le tue ipotesi, le variabili per verificare tutte le modifiche che hai apportato in Excel.
Spesso si verificano errori. Spesso si commettono errori alla fine perché hai dimenticato di cambiare questa variabile lì o questa ipotesi lì, il che ha causato un aspetto finale leggermente diverso. Quindi, penso che sia stato forse un paio d’anni in cui ho avuto la possibilità di imparare SQL. Non conoscevo SQL prima, ma ho imparato SQL in uno dei progetti, e ho davvero apprezzato il linguaggio e anche la potenza che puoi elaborare e semplificare, almeno nella prima parte, la ricerca dei dati descrittivi, cercando di trovare le anomalie all’interno dei dati stessi.
Questo semplifica almeno la prima parte, trovare i dati descrittivi e cercare le anomalie all’interno dei dati stessi. Assicurarsi che i dati siano puliti e trovare modi per integrare diverse fonti di dati insieme ha semplificato molto le cose. È stato allora che ho davvero fatto una transizione. In quel momento, SQL è diventato la mia prima scelta di strumenti analitici a cui mi rivolgevo per elaborare, o meglio pre-elaborare, i dati per capire come sono fatti i dati e se ci sono anomalie. Poi, farei la prima analisi descrittiva da quello, ed Excel sarebbe usato di più per la facilità di visualizzazione. Una volta completato, lo visualizzeremmo più facilmente con Excel facendo grafici e grafici e cose del genere.
Mi piacerebbe aggiungere a quanto detto da Joannes riguardo alla scoperta di Lokad. Ho scoperto anche Lokad un paio di anni fa, ma non ho preso un’iniziativa simile a quella che ho preso l’anno scorso per introdurre questo agli studenti. Avevo paura, ad essere onesto, che l’aspetto della programmazione avrebbe scoraggiato gli studenti dall’usare lo strumento e dal divertirsi o imparare dalla classe. Ma devo dire che mi sbagliavo. Dati i mesi scorsi della nostra collaborazione, ho scoperto che Envision è uno strumento molto facile da capire. Anche con la mia formazione in programmazione e database, è molto facile da capire, e penso che sia anche più facile per gli studenti da capire perché i codici possono essere letti come un linguaggio comune.
È diverso, ad esempio, da Python e altri dove a volte le cose potrebbero non avere molto senso e non seguono l’una l’altra senza l’esplicazione di qualcuno che ha scritto il programma. Finora, è stato un esercizio molto utile introdurre questo. Ha davvero semplificato il processo di adeguamento alle ipotesi, alle cose che potremmo non aver considerato nei dati, ma per aggiornarlo nel codice stesso e poi rifletterlo nel dashboard perché lo studente lo veda.
Chiamo ancora questo un livello introduttivo. Per gli studenti, è per loro capire da un punto di vista generale, dall’alto verso il basso, cosa sta facendo un’azienda e come sta facendo da questi dati descrittivi come il numero di clienti che hanno, le vendite più alte, la tendenza ABC del loro prodotto. Da lì, possono capire come configurano le catene di approvvigionamento, e poi approfondiamo la loro catena di approvvigionamento da lì. Quindi, avere questo programma, questa esperienza di programmazione con Envision, ha davvero aiutato molto da questo punto di vista e ha anche ridotto gli errori che potremmo commettere in Excel.
Conor Doherty: Ti seguirò, Paul, e poi Joannes. Quindi, benvenuti, è una domanda filosofica che vi piacerà. Mi viene in mente che abbiamo parlato degli strumenti, quindi Envision è lo strumento, ma utilizzare o sfruttare gli strumenti comporta una mentalità. Come hai appena accennato, qualcosa che è alla base di ciò che Lokad fa con Envision è adottare una prospettiva puramente finanziaria per i problemi della catena di approvvigionamento e ridurre gli errori in dollari o euro. Questo è un mix, suppongo, di economia ma è anche un po’ filosofico, capire bene se faccio questo, non posso fare quello, costo opportunità.
Per quanto riguarda la mentalità, capire come usare questi strumenti, è qualcosa che devi anche insegnare in classe o gli studenti capiscono automaticamente, “Oh sì, costo opportunità, userò semplicemente questo strumento ed è davvero ovvio per loro”?
Paul Jan: Non direi che sia ovvio, ma gli studenti hanno avuto una formazione in economia quindi capiscono quale sia il tradeoff, il costo opportunità. Anche nel corso fondamentale di catena di approvvigionamento o di operazioni che insegno qui, introduciamo gli studenti al costo in eccesso, al costo di recupero, ai diversi costi che possono derivare dalla decisione che prendi, quanto stock tenere in termini di inventario e quando. Questi sono comprensibili e relazionabili agli studenti una volta che spieghi loro che il modo in cui arriviamo a questo risultato finanziario è basato su ABC.
Nella pratica, questi risultati finanziari sono ciò che cerchiamo anche di quantificare per i dirigenti in qualsiasi tipo di progetto di consulenza. I dirigenti capiscono quando dici loro che questo è il tuo costo in dollari o opportunità in dollari. Ma per le persone della catena di approvvigionamento, direi, o per le persone delle operazioni, sono principalmente guidate dalle metriche tradizionali, i turni, l’accuratezza delle previsioni. Capiscono ma prestano più attenzione a quello. Quindi c’è un po’ di divario tra ciò che capiscono i dirigenti e ciò che le persone operative o almeno sono istruite a seguire. Dal punto di vista degli studenti, introdurre o spiegare questi concetti non è un compito difficile.
Conor Doherty: Grazie, Paul. E Joannes, torniamo a te. Quindi, basandoci su ciò che è stato appena detto, capisco perfettamente perché cose come Python, SQL e ovviamente Envision, il nostro linguaggio specifico del dominio, possano essere sconosciute ai nuovi professionisti della catena di approvvigionamento. Ma il concetto di risorse scarse, utilizzi alternativi, la base dell’economia, ha più di un secolo. Quindi perché quell’aspetto della mentalità economica è così diverso nei circoli della catena di approvvigionamento rispetto a come Paul ha appena descritto, che viene intuitivamente compreso in aula?
Joannes Vermorel: Vorrei prima commentare l’osservazione di Paul. Quando dicevi che eri preoccupato nell’usare Envision, penso che tu avessi ragione. Solo per il pubblico, la mia convinzione personale è che la stragrande maggioranza del software aziendale sia una vera schifezza, letteralmente una vera schifezza. E il software di acquisto, sto guardando proprio te. Quindi è comprensibile un’assunzione molto ragionevole che preveda che sia una vera schifezza e poi essere piacevolmente sorpresi se non è il caso. Ma penso che sia un’assunzione ragionevole. Credo fermamente che Envision non faccia parte di questa categoria, abbiamo fatto un buon lavoro. Ma ancora una volta, penso che sia ragionevole aspettarsi che il software aziendale sia di bassa qualità, soprattutto rispetto ai progetti open source popolari. È un’assunzione equa e molto razionale da fare sul panorama applicativo.
Ora, la cosa con questo tipo di mentalità con la questione finanziaria, e quando Paul ha menzionato ABC come nel costo basato sull’attività, a proposito, non nel corso di analisi ABC. La cosa è che è molto difficile pensare ai problemi se non puoi immaginare la soluzione. Quindi la cosa è che quando le persone dicono che vogliono pensare in termini di accuratezza o livello di servizio, queste sono metriche molto classiche. La cosa è che se tutto ciò che hai è un foglio di calcolo Excel, è praticamente tutto ciò che puoi implementare. Pertanto, se puoi solo pensare in termini di fogli di calcolo, allora hai difficoltà a raggiungere quei risultati perché devi pensare ai problemi. Come posso trasformare tutto ciò in dollari mentre hai davvero difficoltà a pensare alla soluzione?
Le persone spesso pensano prima alla soluzione prima del problema. È molto difficile anche enunciare un problema senza concepire prima una soluzione. Ti imbatterai prima in una soluzione approssimativa e poi, quando vorrai spiegare ciò che hai fatto a qualcun altro, inventerai effettivamente il problema che corrisponde alla soluzione. Le persone immaginano istintivamente la soluzione prima e poi, per poter comunicare al riguardo, inventano il problema.
La tua capacità di pensare alle soluzioni dipende dagli strumenti che hai a disposizione nella tua mente. Se hai Excel nella tua mente, allora tutte le soluzioni a cui puoi pensare sono quelle che possono funzionare in Excel. Questo ti limita al paradigma di accuratezza e livello di servizio perché sono le cose che puoi fare in Excel.
Ecco perché è molto importante nei corsi fondamentali familiarizzare gli studenti con strumenti migliori in cui possono pensare, ad esempio, con tabelle e colonne e concetti come SQL. Il problema non è SQL di per sé, è il paradigma che si ottiene con SQL - tabelle, filtri, aggregazioni, colonne, tipi di valore come stringhe rispetto a numeri, booleani. Queste cose sono molto importanti e improvvisamente, quando hai questi paradigmi, puoi pensare a classi di soluzioni più elaborate.
Per pensare agli indicatori finanziari, è necessario collegare il costo di archiviazione, quindi è necessaria un’altra tabella che ti fornirà alcune ipotesi sul costo di archiviazione. Devi avere il costo di stock out, quindi devi avere queste informazioni da qualche altra parte. Non è che tradizionalmente le persone siano incapaci di pensare al costo di archiviazione o al costo dell’assicurazione, lo sanno. Ma quando si tratta di immaginare una soluzione, se Excel è tutto ciò a cui possono pensare, è molto difficile per loro pensare a un foglio di calcolo che sarà in grado di collegare queste 20 cose diverse.
Ma se puoi pensare con dati relazionali, allora improvvisamente hai gli strumenti che ti permettono di pensare, “Okay, sto solo collegando tutti quei costi con quante più tabelle servono.” E concettualmente, se quei costi sono individualmente semplici, è solo una questione di aggregare tutto ciò.
Questa è una spiegazione lunga, ma è anche il motivo per cui la gestione tradizionale della supply chain è molto titubante. Non hanno avuto la possibilità di ottenere questo tipo di formazione in cui possono davvero pensare con strumenti più moderni.
Paul Jan: Sono completamente d’accordo con la valutazione di Joannes. Se dovessimo fare una valutazione delle competenze nelle operazioni della supply chain di qualsiasi azienda, penso che troverai una grande lacuna nella loro comprensione di ciò di cui abbiamo appena parlato. Questa è davvero la sfida nell’educare questa prossima generazione di giovani professionisti a un modo di pensare diverso e innovativo.
Joannes Vermorel: Insegno da sette anni, non supply chain, ma informatica distribuita e ingegneria del software. La mia filosofia quando insegnavo all’Eon Normal Superior di Parigi, dove avevo completa libertà di decidere cosa insegnare, era di concentrarmi su argomenti che sarebbero ancora rilevanti tra quattro decenni.
La mia più grande paura era insegnare qualcosa che fosse solo una moda, qualcosa che dopo cinque anni ti rendi conto che era solo una tecnicalità e ora è sparita. Quindi, il mio approccio era sempre chiedermi, è qualcosa che resisterà alla prova del tempo? Che tra 40 anni avrà molte probabilità di essere ancora un punto di importanza?
Ad esempio, SQL è stato stabilito come standard dal 1989. Si è evoluto, ma la maggior parte non è cambiata da allora. Il modello sottostante, i dati relazionali, non è cambiato dalla fine degli anni ‘70. Si è dimostrato incredibilmente di successo, con praticamente il 99% del mercato ERP che utilizza questo formato di dati relazionali in un modo o nell’altro.
Le persone hanno l’impressione che le tecnologie digitali cambino tutto il tempo, che devi imparare qualcosa e tra due anni sparirà. Credo che sia un problema perché dà alle persone l’impressione che questa conoscenza sia usa e getta. Dà anche una falsa impressione alla direzione aziendale che possono aggirarla e non importa perché tra due anni sarà qualcos’altro.
Se fatto correttamente, abbiamo molti argomenti che sono molto fondamentali. La struttura dei dati relazionali sarebbe uno di questi. I tipi di dati di base, testo, booleani, numeri, erano già così alla fine degli anni ‘70. Anche Python 3, l’ultima versione, li ha ancora al loro nucleo. È qualcosa che è molto improbabile che cambi nel corso dei prossimi quattro decenni.
Allo stesso modo, se pensiamo alle previsioni, l’idea di come pensare al futuro, serie temporali, quali sono i limiti delle serie temporali, cosa ci dà una previsione delle serie temporali, cosa non ci dà, cosa questa cosa non può darci per design, anche questo non cambierà. Il tipo più basilare di previsione tra quattro decenni sarà ancora una previsione delle serie temporali al giorno, alla settimana, al mese, e la limitazione di una tale previsione sarà ancora la stessa.
Se dovessi insegnare le previsioni, anziché concentrarmi su quale sia il miglior modello di previsione delle serie temporali, che cambierà, mi concentrerei sulle assunzioni incorporate che hai con la previsione delle serie temporali, su cosa ti dà e su cosa non ti dà, e sulle pericolose limitazioni e su come pensare all’incertezza.
Capisco che è una sfida molto grande. La maggior parte dei professori universitari non ha avuto il lusso che ho avuto io, dove l’amministrazione non si preoccupava minimamente di ciò che stavo effettivamente insegnando.
Conor Doherty: Paul, quando parli di previsione della domanda in classe, ti occupi delle distribuzioni di probabilità, della comprensione dell’incertezza del futuro?
Paul Jan: Nel corso fondamentale ne parliamo, così come nella gestione della domanda, nelle previsioni e nel controllo delle scorte. Ma facciamo l’assunzione che le variabilità, le incertezze seguano la distribuzione normale, il che semplifica molto l’insegnamento.
Tuttavia, nell’applicare l’approccio probabilistico, che considera la probabilità delle variazioni nel tempo per un prodotto, puoi osservarlo graficamente. Le persone sono visive, quindi possono capire perché un prodotto si comporta in modo diverso rispetto a un altro.
Questo semestre sto pensando di portare alcuni contenuti della classe superiore nella classe inferiore come modo per spiegare le incertezze e le variazioni in modo più visivo.
Joannes Vermorel: Fare assunzioni forti per scopi didattici va bene. Ricordo quando ero all’università, un mio professore di fisica semplificava i calcoli assumendo che una mucca fosse una sfera. Ovviamente, una mucca non è una sfera, ma per il bene dell’esercizio, è ragionevole permettere agli studenti di fare un calcolo semplificato. Questo li aiuta a sperimentare con i concetti senza impantanarsi nei calcoli.
Tuttavia, nel mondo della supply chain, le persone fanno assunzioni equivalenti, come assumere che la domanda sia distribuita normalmente. Questa è un’assunzione didattica che non regge nel mondo reale. Eppure, i fornitori di software aziendali continuano a farlo e codificano queste assunzioni nel loro software. Questo è folle. È come se la General Motors codificasse assunzioni su sfere e passeggeri nelle loro auto. Le persone penserebbero che sia pazzesco. Non dovresti farlo per una vera auto che guiderà nel mondo reale.
Eppure, in modo bizzarro, i fornitori di software per la supply chain dicono che non c’è problema a codificare queste assunzioni nel loro software. Questa è la mia reazione allo status quo di questa industria, che trovo un po’ folle. C’è bisogno di una svolta. Per qualche strana ragione, sembra che i fornitori di software per la supply chain stiano traducendo direttamente nel software queste assunzioni folli introdotte per scopi didattici.
Ma forse non è giusto chiedere questo ai professori. Forse sono i fornitori di software per la supply chain stessi che devono fare i conti con la realtà.
Conor Doherty: Questo è qualcosa che stavo per chiedere. Dal punto di vista di Paul alla Rotman School of Management, è sua responsabilità insegnare questi concetti. Ma per Lokad, un fornitore di software per la supply chain, perché l’educazione è così importante? Perché concentrarsi così tanto su questo?
Joannes Vermorel: La supply chain è una collezione di problemi complessi a causa del fatto che stiamo mettendo insieme tutte le forze delle aziende. Per definizione, la supply chain tiene insieme l’azienda, quindi significa che stiamo mettendo insieme vendite, produzione, trasporto, marketing, finanza, tutto insieme. Questa non è una semplice proposta. Le aziende moderne operano in molti paesi, quindi non hai solo vendite contro marketing, ma puoi anche avere Francia contro Italia contro Spagna.
La supply chain è una serie di problemi complessi per design o per la stessa natura della supply chain che collega insieme molti interessi contrastanti all’interno e all’esterno dell’azienda. Dobbiamo pensare in termini di paradigmi e strumenti che ti permettano di abbracciare questi problemi complessi, anche in modo approssimativo. Le persone invece di cercare l’approssimazione corretta, cercano l’esatto contrario e si concentrano su molte ricette numeriche che sono molto più precise di quanto dovrebbero essere.
Conor Doherty: Stiamo arrivando alla fine, ma voglio tornare a te. La concezione di Joannes della supply chain mi sembra profondamente filosofica. Quando parliamo di problemi di primo e secondo ordine, è quasi come Wittgenstein. Sono curioso, adotti un approccio altrettanto filosofico alla supply chain? L’amministrazione te lo permette? Il primo giorno, dobbiamo ripensare l’intera sfera delle filosofie della supply chain? È questo il tipo di cose che dici agli studenti, che dobbiamo ripensare completamente la ruota, o è più graduale?
Paul Jan: È graduale e anche disruptivo. All’università, mentre uno studente sta imparando, inizia con le basi, poi qualche corso intermedio di gestione delle operazioni della supply chain, e poi arriva a un corso più avanzato che sto insegnando questo semestre in collaborazione con Lokad. Imparano gradualmente teorie e applicazioni tradizionali. Ma poi arriva la disruptzione quando in questo corso, almeno nella mia esperienza, non so come insegnare agli studenti la complessità della supply chain senza che loro la vivano. Ecco perché lavoriamo con un’azienda. Gestiamo dati reali e pensiamo con uno strumento. Vedono la complessità, l’incertezza e si rendono conto che le cose che hanno imparato negli anni precedenti o nei corsi precedenti non possono essere applicate immediatamente. Puoi farlo, ma potrebbe non avere senso.
Quindi, è una questione filosofica. E a proposito, questo è un problema aperto. Se vai alla pagina Wikipedia sui problemi complessi, tutte le discipline che si trovano di fronte a questo tipo di problema, in cui una risposta buona o cattiva a un problema dipende da quello che fanno gli altri, sono incredibilmente difficili da insegnare. Non è specifico della supply chain, ci sono altre aree in cui è semplicemente incredibilmente difficile.
Joannes Vermorel: Ci sono persino aree in cui, ad esempio, abbiamo avuto un ospite di recente sul trading sui mercati pubblici, dove se anche rivelassi come lo fai, minerebbe la tua stessa soluzione e il tuo stesso flusso di entrate. Quindi il segreto è fondamentale in questo tipo di cose. Se capisci qualcosa, professionalmente non dovresti parlarne perché se lo fai, le persone lo useranno contro di te.
Ma la mia opinione è che Lokad continuerà a cercare. Continueremo a cercare di sostenere le buone università che stanno cercando di seguire questa direzione, come l’Università di Toronto. Non ci aspettiamo una soluzione, ma qualsiasi passo compiuto in questa direzione è già qualcosa di meglio che fingere che non esista nemmeno.
Conor Doherty: Esattamente, approssimativamente corretto. Beh, Paul, è consuetudine qui dare l’ultima parola all’ospite. C’è qualcosa che vorresti dire alle persone o consigliare ai tuoi studenti per gli esami finali?
Paul Jan: Nessun consiglio sugli esami finali ancora, ma vorrei tornare al commento di Joannes su perché il settore privato sta investendo nell’istruzione. Investi in lezioni, articoli e blog, e lo apprezzo. Molti di questi studenti, dopo la laurea, si rivolgono a fornitori, fornitori e siti web per trovare informazioni o per capire cosa sia la gestione della supply chain, o per rinfrescare la memoria.
Ad esempio, la statistica è un argomento molto temuto dagli studenti. Quindi, non dare per scontato che tutto sia normale rende le cose molto più facili perché elimina quella paura. Ma se hai delle prove concrete per giustificare comportamenti diversi, potrebbero essere più disposti a imparare a superare quella paura. Dopo l’università, le tue informazioni diventano più accessibili per loro, quindi diventa un rinforzo per uscire da questa mentalità che si può applicare la stessa soluzione a tutti i diversi problemi complessi.
Conor Doherty: Perfetto. Su questa nota, in realtà non ho altre domande. Joannes, grazie per il tuo tempo.
Joannes Vermorel: Grazie mille anche a te e per la tua collaborazione continua.
Conor Doherty: E grazie a tutti voi per aver guardato. Ci vediamo la prossima volta.
