Consegna orientata al prodotto per Supply Chain - Lezione 1.3

00:22 Introduzione
02:40 Perché un prodotto? Per il capitalismo
08:18 Cosa dovrebbe fare il prodotto?
10:05 Diseconomie di scala nel software
12:50 Acquistiamo un prodotto SCO già pronto
21:58 SCM vs SCO
25:58 Interludio
28:21 SCO non è il solito prodotto software
33:26 Ingredienti Software per SCO
42:49 Tuttavia, i fogli di calcolo non sono la soluzione definitiva
46:51 Python non è nemmeno lui la soluzione definitiva
58:52 SC non è una divisione dell’IT
01:03:19 In conclusione, due sfide da superare
01:07:04 Prossima lezione e domande del pubblico

Descrizione

L’obiettivo di un’iniziativa Quantitative Supply Chain è quello di fornire o migliorare un’applicazione software che automatizza un insieme di decisioni di routine (es. riapprovvigionamenti, aggiornamenti dei prezzi). L’applicazione viene considerata come un prodotto da ingegnerizzare. La supply chain theory è qui per aiutarci a fornire un’applicazione che guidi l’azienda verso supply chain performance, pur essendo compatibile con tutte le restrizioni che la produzione comporta.

Trascrizione Completa

Ciao a tutti, grazie mille per esservi uniti a questa serie di lezioni sulla supply chain. Sono Joannes Vermorel e presenterò “Consegna orientata al prodotto per l’ottimizzazione della supply chain.”

Quindi, quando parlo di prodotto, intendo un prodotto software. Per chi ha avuto il privilegio di investigare cosa si cela sotto il cofano di un moderno applicativo aziendale, potrebbe essere un’esperienza piuttosto intensa.

Per chi conosce l’opera di H.P. Lovecraft, ci sono alcune inquietanti somiglianze. Lovecraft ha scritto una serie di romanzi, e uno dei temi ricorrenti è l’idea del sapere proibito. Non è che l’universo non possa essere compreso, può esserlo. È solo che l’unica cosa che preserva l’umanità è l’ignoranza. L’ignoranza non è un problema; è proprio ciò che ci protegge da un universo troppo terrificante per la nostra mente. Questa idea è stata riciclata in molti videogiochi moderni, soprattutto nei giochi di ruolo, dove, oltre ai tradizionali punti salute, i personaggi hanno punti sanità mentale. Se compi azioni che danneggiano la tua sanità mentale, perdi punti sanità. La sfida con il software aziendale è riuscire a crearlo preservando la propria sanità mentale, uno dei requisiti per aggiungere valore all’azienda. Quindi, procediamo.

Perché un prodotto, e in particolare un prodotto software? Diamo un’occhiata da vicino a come operano tradizionalmente le supply chain. Tradizionalmente, c’erano molte persone sul campo a spostare cose, a gestire pacchi, a guidare veicoli e a svolgere tutto il lavoro manuale. C’erano anche molte persone coinvolte nella produzione, così come nei negozi. Negli ultimi decenni il numero dei lavoratori impiegati in mansioni manuali è diminuito costantemente. Oggigiorno, in termini di produzione, le cose sono fortemente automatizzate. Rimangono tuttavia alcuni settori, come quello tessile, in cui è difficile automatizzare tutto, motivo per cui tali industrie si sono trasferite dove il lavoro manuale è più economico. La realtà è che i requisiti di forza lavoro grezza sono stati notevolmente ridotti.

Si finisce in una situazione piuttosto strana in cui, se si guarda al futuro con l’avvento dei veicoli autonomi, molte aziende avranno più impiegati, che lavorano con Excel fogli di calcolo, per far funzionare la supply chain, rispetto alle persone con mansioni manuali sul campo. Questo è a ciò a cui mi riferisco quando parlo di lavoro d’ufficio.

Un altro aspetto peculiare è che le supply chain sono state digitalizzate per molte aziende da almeno due decenni. Non è che stiamo per introdurre software nelle supply chain; esse sono già gestite e operate attraverso il software. Ma quando osserviamo il ruolo degli esseri umani in questi sistemi software, vediamo che gli umani sono letteralmente utilizzati come co-processori in un tipico sistema di supply chain. Esistono operazioni specifiche che la CPU normale, il processore della macchina, non può svolgere, e quindi l’intero compito viene delegato a un essere umano. In combinazione con semplici ricette numeriche, come l’analisi ABC, l’inventario min-max e metodologie simili, gli esseri umani finiscono per trascorrere le loro giornate a gestire emergenze. Sono costantemente impegnati a risolvere eccezioni e condizioni che non rientrano nel quadro standard.

Dal punto di vista dei costi, tutto ciò rientra nelle spese operative (OpEx). È necessario pagare ogni singolo giorno un esercito di impiegati per gestire tutte le decisioni banali che l’azienda deve prendere quotidianamente. Queste includono cosa acquistare, dove posizionare l’inventario, se spostare un’unità da un magazzino a un negozio, e molte altre decisioni di routine. Gli esseri umani prendono queste decisioni e intervengono per gestire le inadeguatezze delle decisioni automatiche generate in modo ingenuo dal sistema.

La mia proposta per voi oggi è passare dalle spese operative (OpEx) alle spese in conto capitale (CapEx). Questo è l’intero obiettivo di questa consegna orientata al prodotto. Vogliamo costruire un asset, e perché? Perché è capitalista. Se si osservano le 100 aziende più redditizie al mondo al giorno d’oggi, la metà di esse, in termini di profitto, sono società software. Esse rappresentano l’essenza delle aziende ultra-capitaliste, dove si effettua un investimento iniziale, che poi si traduce in un dispositivo o artefatto che genera valore aggiunto con un investimento marginale minimo.

Riprendendo l’argomento della mia lezione precedente, abbiamo bisogno della robotizzazione per rimettere la gestione al comando. Automazione e umani dovrebbero lavorare insieme; gli esseri umani non dovrebbero occuparsi delle inadeguatezze di politiche di inventario poco intelligenti come il min-max. Al contrario, dovrebbero contribuire ad aggiungere valore, migliorare le ricette numeriche e agire da strateghi. C’era un vecchio motto della IBM che recitava: “Le macchine devono lavorare; le persone devono pensare.” Questo è il tipo di mentalità che permea questa presentazione. Vogliamo trasformare la supply chain in un asset capitalista e, per farlo, dobbiamo trasformare la supply chain in una macchina che fornisce un prodotto software.

Cosa fa effettivamente questo prodotto? Si scopre che fa qualcosa di abbastanza semplice: prende decisioni. Non decisioni arbitrarie e senza limiti, ma quelle banali e di routine, come cosa produrre, quante unità acquistare da un fornitore e quante unità spostare da una località all’altra. A prima vista, potrebbe sembrare che la gestione della supply chain comporti molte decisioni. Tuttavia, esaminando i compiti, anche le supply chain più complesse richiedono solo qualche dozzina di tipologie decisionali da prendere ogni giorno. Questo non è travolgente ed è piuttosto ragionevole in termini del numero complessivo di funzionalità. Curiosamente, queste decisioni sono in gran parte esclusive, quindi esistono limiti a ciò che si può fare con un approccio divide-et-impera. Una volta deciso di acquistare 100 unità da un fornitore, non è possibile che un altro sottosistema decida al suo posto di comprarne 200. Ad un certo punto, bisogna decidere quante unità acquistare e spostare da una località all’altra. Queste decisioni sono discrete, limitate nell’ambito e per lo più esclusive. Quello che vogliamo è un software che generi decisioni d’ordine in maniera completamente automatizzata ogni singolo giorno.

Una cosa che ritengo spesso poco compresa riguardo al software è il concetto di diseconomie di scala. Mentre le economie di scala sono familiari alla maggior parte delle persone, il contrario è vero per il software, dove aggiungere un quarto in più di funzionalità può raddoppiare il costo. Questo concetto spiega perché le piccole startup possono sfidare le grandi aziende – concentrandosi su una frazione minore di funzionalità, il costo per portare il loro prodotto sul mercato può risultare significativamente inferiore a quello di una grande azienda.

Con l’idea delle diseconomie di scala in mente, dobbiamo decidere se costruire, acquistare o adottare un altro approccio per il nostro prodotto di ottimizzazione della supply chain. Se scegliamo di acquistare il prodotto da un fornitore, dobbiamo considerare le funzionalità che il venditore di software dovrà fornire per servire il mercato.

Quindi, consideriamo l’acquisto di un prodotto di ottimizzazione della supply chain già pronto all’uso. In queste slide, fornisco una panoramica di una piccolissima frazione di tutte le questioni che dobbiamo affrontare. Ho esperienza diretta in merito, poiché quando ho avviato Lokad nel 2008 ho iniziato con un piccolo prodotto software orientato più alla previsione che all’ottimizzazione della supply chain. Quando ho iniziato a lavorare con i clienti, mi sono reso conto che c’erano così tante funzionalità e capacità che non possedevo e, man mano che passavo ad altri clienti, trovavo ancora più funzionalità mancanti. Sembrava un processo senza fine di scoperta di nuovi requisiti.

Diamo un’occhiata alle funzionalità di base. Innanzitutto, esistono aziende B2C o B2B, che mostrano schemi completamente differenti nella gestione della supply chain. Ad esempio, le aziende B2B solitamente hanno meno clienti, ma questi ordinano quantità molto maggiori. Ciò crea diversi tipi di rischio, come quello di perdere un singolo cliente che rappresenta una parte significativa del fatturato dell’azienda. Poi ci sono modelli di business più complessi come B2B2C o B2B2B.

Considera i vari tipi di siti che devono essere coperti, come negozi, magazzini e impianti di produzione. Ogni tipo di sito comporta le proprie sfide. I negozi, ad esempio, sono soggetti a inesattezze nell’inventario, anche con la tecnologia RFID, semplicemente perché i clienti possono spostare i prodotti. I magazzini e gli impianti di produzione, come aziende agricole o operazioni minerarie, presentano problemi specifici e incertezze riguardo al rendimento della produzione.

Le reti della supply chain possono avere diversi livelli, o echelons, che vanno da sistemi a singolo livello a sistemi a più livelli. La complessità nella gestione della supply chain aumenta notevolmente con il crescere del numero di echelons. La topologia della rete è un altro aspetto importante da considerare. Una topologia ad albero è il percorso classico in avanti della supply chain, in cui pochi siti di produzione inviano a diversi magazzini, che a loro volta distribuiscono a numerosi negozi. Tuttavia, possono esistere altre topologie, come i grafi aciclici diretti (DAG), in cui un negozio può essere servito da più magazzini.

In sostanza, non si tratta solo di un albero in termini di grafi, può riconnettersi, anche se il flusso resta in avanti. Ma la stessa cosa può verificarsi con un Grafo Aciclico Diretto (DAG) quando ci sono più fornitori. Puoi persino avere cicli nel grafo della supply chain che si verificano ogni volta che sono coinvolte riparazioni. Ad esempio, nell’industria mineraria o nell’industria aeronautica, ci sono numerosi cicli di riparazione con attrezzature riparabili.

Ora, l’inventario in sé non ha un’unica natura; varia molto. Non puoi semplicemente dire: “Oh, ho questa idea che possiedo SKU ed è tutto qui.” No, non proprio, perché innanzitutto ci sono le materie prime, misurate letteralmente in quantità come grammi, chilogrammi o volume. Poi, ci sono le unità, quelle ben definite e prevalentemente usate. Ma puoi anche avere un inventario che si verifica molto frequentemente, ad esempio nel settore farmaceutico o alimentare, in cui il lotto ha date di scadenza specifiche. Infine, puoi persino avere un inventario completamente serializzato, dove ogni singola unità ha il proprio numero di serie. In termini di ottimizzazione della supply chain, questo cambia completamente le regole del gioco, rendendo il problema totalmente differente quando si considerano questi aspetti.

Poi, ovviamente, esistono tutti i problemi dei marketplace. In Lokad, abbiamo clienti in letteralmente ogni possibile situazione. Ci sono clienti che vendono tramite marketplace di terze parti, che possono avere il proprio marketplace o entrambi. Può trattarsi di qualcosa di secondario, da utilizzare per liquidare ciò che non è stato venduto. Le situazioni sono molteplici.

Ora, solo per fare un esempio, pensa per un attimo a cosa sia un ordine. C’è l’ordine spot, in cui fondamentalmente acquisti qualcosa direttamente al banco, ed è tuo. Ma poi puoi avere anche un ordine in cui si dice: “Lo sto acquistando, ma non voglio che venga consegnato immediatamente; desidero che venga consegnato tra un mese.” Ovviamente, dal punto di vista dell’ottimizzazione della supply chain, è un scenario completamente diverso, perché se sai in anticipo che dovrai consegnare una certa quantità di merce a una data specifica, non vorrai fare previsioni, quindi è una questione del tutto differente.

E poi c’è l’ordine configurato, che è, per esempio, quando acquisti un computer online e puoi scegliere quanta memoria, quanta capacità del disco, quale tipo di sistema operativo, quale lingua impostare sul computer e come disporre la tastiera, tra le altre cose. Quindi, puoi avere un configuratore massiccio, e questo cambia nuovamente il panorama. Lo stesso avviene per prodotti come biciclette o automobili, modificando completamente il contesto, poiché offre opzioni e modalità di affrontare il problema dell’ottimizzazione della supply chain che sono totalmente differenti.

Anche per i prezzi, puoi avere il prezzo per unità fisso, super semplice e perfettamente lineare, ma non è l’unica cosa. Puoi avere scale di prezzo, per esempio, se acquisti dieci unità, ottieni uno sconto. Oppure puoi avere programmi di loyalty in cui alcuni clienti con una carta fedeltà possono ottenere uno sconto, ma solo su certi tipi di prodotti o a determinate condizioni. E poi, persino in B2B, ci sono operazioni molto frequenti che vengono negoziate, quindi è letteralmente una transazione in cui molte cose verranno vendute, ma hai un prezzo catalogo standard. Tuttavia, un fornitore può concedere uno sconto a un cliente perché è importante, ed è semplicemente così che si fa. In definitiva, ho parlato per pochi minuti e ho coperto solo il nucleo essenziale. Non ho ancora iniziato a toccare le cose indispensabili. Quindi fermati un attimo e prova a pensare a come potrebbe essere un prodotto software enterprise confezionato che deve fornire ottimizzazione della supply chain. Il numero di funzionalità da coprire è semplicemente pazzesco e, quando cerchi di mettere insieme tutte queste cose in un monolite, stai letteralmente perdendo la testa. Siamo tornati a questa idea che non è che l’universo non possa essere conosciuto, è solo che, se vieni esposto alla cruda verità dell’universo, perdi la sanità mentale.

Quindi, abbiamo un problema fondamentale, e qui dobbiamo differenziare il supply chain management dall’ottimizzazione della supply chain. Questa è una distinzione che ho già introdotto in una mia lezione precedente. C’è una grande confusione tra la parte gestionale e quella dell’ottimizzazione. La gestione riguarda la contabilità, il supporto dei flussi di lavoro e principalmente i processi di inserimento dati. Se vuoi rappresentare tutte le cose che ho appena descritto, c’è un sacco di terreno da coprire, ma è fattibile. Un ERP “obeso” può farlo. Sì, finirai con 10.000 tabelle, sarà piuttosto brutto, ma è possibile. Ma non fraintendermi, l’ERP (che dovrebbe essere chiamato ERM, Enterprise Resource Management) non farà molto. Serve semplicemente a tenere traccia di queste cose. Quindi avrai tonnellate di entità – MOQs, check; scale di prezzo, check; negozi, check; magazzini, check – ma non serve che abbiano alcun grado di intelligenza. Si tratta semplicemente di controparti digitali banali che riflettono i dati, rendendo possibile inserirli nel sistema, e basta.

È possibile perché, qui, possiamo imbrogliare un po’ questa regola del “un quarto in più di funzionalità raddoppia il costo.” C’è qualcosa che non ho davvero detto a riguardo: funziona se mantieni le funzionalità completamente segregate. Finché le funzionalità non interagiscono tra loro, va bene; non sei soggetto a quella maledizione delle diseconomie di scala. Dal punto di vista dell’inserimento dei dati, non c’è problema. Non hai bisogno di avere un’interfaccia utente che ti permetta di collegare i MOQs a ciò che ti consente di aggiungere un negozio extra alla rete. Queste due cose possono rimanere completamente segregate.

Tuttavia, quando si tratta di ottimizzazione della supply chain, non è lo stesso. Se hai MOQs, avranno profonde implicazioni sulla frequenza degli ordini, su quanto spesso consegnerai le merci dal tuo magazzino ai tuoi negozi. Ci sono molte conseguenze a lungo raggio. Non puoi separare le cose perché, in definitiva, la tua supply chain è un unico sistema in cui tutto influenza tutto. Quindi, dal punto di vista dell’ottimizzazione della supply chain, hai letteralmente il problema che tutte queste componenti devono essere collegate se vuoi realizzare l’ottimizzazione, ed è qui che le cose vanno in malora.

Dal lato gestionale, potresti potenzialmente ottenere un prodotto. Tuttavia, per l’ottimizzazione della supply chain, la risposta è che non puoi. Voglio dire, puoi fingere di farlo, ma letteralmente non puoi. Anche a Lokad, che non è nata come azienda predittiva specializzata in ottimizzazione predittiva della supply chain, ma piuttosto come forecasting as a service. Se torni al blog di Lokad nel 2008, inizialmente ho cominciato con le previsioni basate sulle serie temporali, il che era gravemente mal indirizzato. Tuttavia, è così che ho cominciato. Persino per le previsioni delle serie temporali, che sono una piccola parte del problema complessivo, è ingestibile. Questa è la mia conclusione dopo oltre 12 anni in questo settore.

Se dobbiamo tornare al mondo specifico della produzione software, è qualcosa di molto unico. A meno che tu non sia stato formato come ingegnere del software e conosca il modo in cui le grandi aziende di successo producono software, è probabile che tu sappia ben poco in merito. Si scopre che è un mondo molto particolare, con numerosi aspetti totalmente controintuitivi. Le aziende tradizionali, specialmente quelle con una mentalità classica da ingegneria meccanica o di marketing, faticano immensamente a capire come funzioni il software.

Affronteremo questi aspetti più in dettaglio nelle lezioni future, ma c’è un libro che mi piace davvero, prodotto da Joel Spolsky, un ex dipendente Microsoft che ha lavorato nei primi team di Microsoft Excel. È anche il cofondatore di Stack Overflow e Trello. Nel 2004, quando ero ancora uno studente, ho letto il suo libro e il suo blog. Il libro si intitola “Joel on Software” e, in modo umoristico, ti offre un’idea di cosa implichi gestire un’azienda software di successo. È molto diverso da ciò che la maggior parte delle persone fuori da questo settore si aspetta. Aggiungerò i dettagli di questo libro nella descrizione del video.

Ma teniamo a mente che l’ottimizzazione della supply chain non è il tipico prodotto software. Di solito, quando si tratta di un prodotto software medio – voglio dire, sì, ci sono alcuni comportamenti avversi, a seconda del tipo di prodotto. Se hai a che fare con un social network, possono esserci molte persone che postano contenuti d’odio, che è un gioco completamente diverso. Tuttavia, quando si parla di classici software enterprise, come Microsoft Word o Excel, è un prodotto per il quale vuoi avere il design giusto, ma non c’è alcuna emergenza. Nel caso dei prodotti software tradizionali, va bene spendere anni a perfezionare il design e il prodotto. È un investimento a lungo termine e devi pensare a decenni nel futuro. Non c’è motivo di avere fretta nello sviluppo. Tuttavia, l’ottimizzazione della supply chain non funziona così. Non hai scelta, poiché le cose accadono continuamente, e il terreno è estremamente accidentato.

Puoi affrontare situazioni estreme come la pandemia o altri problemi come il ransomware, che possono bloccare metà della tua rete. Devi prendere decisioni intelligenti per sfruttare al meglio le capacità che hai ancora a disposizione. Potresti dover affrontare il fermo della flotta a causa di incidenti tragici, mosse politiche come tariffe che sconvolgono la tua strategia, o disastri naturali come disastri – tsunami, incendi, ondate di calore, come quelle in California o Australia. Questi eventi accadono e, quando succedono, devi essere in grado di reagire letteralmente in poche ore.

Hai il tuo prodotto software, ma devi apportare cambiamenti, e desideri introdurre cambiamenti in modo programmatico. Ricorda, se hai in mente di consegnare un asset software, hai un piccolo team che guida il software che, a sua volta, gestisce la tua supply chain. Non hai un esercito di impiegati che si occupa di spegnere incendi tutto il giorno. Anche se avessi un esercito di impiegati, devi addestrarli, e quando accade qualcosa di completamente inaspettato, finisci per avere un esercito non preparato per quella situazione specifica. Nella mia esperienza, più persone devi gestire, più tempo ci vuole per ottenere risultati.

Pochi giorni fa, una nave cargo ha perso oltre 1.800 container a causa di cattive condizioni metereologiche. Queste cose accadono e non puoi sperare di eliminarle. La supply chain non è come la produzione, dove potresti avere un sito produttivo con tutto rigidamente controllato. Per definizione, le supply chain si svolgono in un mondo vasto, dove per la maggior parte del tempo non hai alcun controllo sugli elementi. Ci sono così tante forze al di fuori del tuo controllo che devi essere in grado di far fronte a eventi sorprendenti. Sai già che le sorprese accadranno, per cui devi essere preparato. Essere preparato non significa avere tutto mappato nei minimi dettagli; significa avere un sistema in cui puoi reagire in poche ore, se necessario. Questa è l’essenza di ciò che puoi fare per affrontare realisticamente il problema.

Ora, di quali ingredienti software abbiamo bisogno per l’ottimizzazione della supply chain? Innanzitutto, abbiamo bisogno di uno storage dati versatile per rappresentare tutti i vari tipi di fonti di dati. Ci sono così tante cose che vogliamo rappresentare, per cui desideriamo qualcosa di molto versatile in questo ambito, con molta struttura e varietà.

In secondo luogo, ti serve una logica programmabile. Torno a questa idea: se non hai logica programmabile, come affronti tutti questi problemi? Come fai a mettere insieme tutte queste cose? Non puoi comprare un prodotto confezionato che abbia tutto pre-programmato per te; non funziona.

Successivamente, ti servono interfacce utente versatili perché il modo in cui desideri analizzare i tuoi problemi varierà enormemente da una situazione all’altra. Gli indicatori chiave di prestazione (KPI) saranno completamente diversi da un’azienda all’altra, quindi ti serve un’interfaccia utente versatile in cui poter presentare i dati come meglio credi; altrimenti, sarà un grande limite.

Inoltre, desideri capacità collaborative perché la supply chain è, per definizione, un lavoro di squadra. Ci sono molte persone coinvolte e, essendo distribuita, le capacità collaborative devono essere al centro.

Infine, e forse in maniera più controversa, desideri capacità programmabili accessibili anche a persone che non sono ingegneri del software formati professionalmente. Questo è importante per diverse ragioni. Innanzitutto, non ci sono molti ingegneri del software formati sul mercato, quindi è molto competitivo assumerli. In secondo luogo, serve tanto impegno e dedizione per diventare un ingegnere del software di talento, tanto che è difficile essere contemporaneamente un supply chain scientist.

Non è molto comune trovare persone che abbiano competenze in entrambi i campi. Lo stesso verrebbe in mente se cercassi qualcuno che fosse sia programmatore che avvocato, o programmatore e medico. Sì, troverai alcune persone con queste competenze, ma riesci a farlo in scala o ad assumerne altre in modo affidabile ogni anno se sei una grande azienda? Dalla mia esperienza alla guida di Lokad per un decennio, semplicemente non funziona.

Vuoi qualcosa di programmabile, ma non serve essere un ingegnere del software formale per occuparsi della programmazione. Ricorda, devi avere qualcuno con competenze di supply chain perché devi essere in grado di intervenire in poche ore per applicare le correzioni programmatiche al tuo sistema, senza dover aprire un ticket e passarle all’IT. Se devi fare così, ci vorranno settimane per risolvere i problemi, non ore. Quindi, che tipo di software può realmente risolvere il problema?

Beh, Excel lo può fare. Non è bello da vedere e potrebbe non sembrare l’apice del software moderno, ma fa il suo dovere. Soddisfa tutti i requisiti.

Storage dati versatile? Sì, in una certa misura, puoi immetterci tanti dati di ogni tipo. Logica programmabile? Assolutamente, Excel è completamente programmabile. Interfaccia utente versatile? Sì, puoi avere grafici a barre, grafici a linee e molteplici modi per presentare i dati. In termini di interfacce utente, è molto versatile. Potrebbe non essere il più raffinato, ma in termini di versatilità, può fare molto.

Per quanto riguarda le capacità collaborative, è un po’ grezzo. Esistono alcune versioni di Excel online, che sono leggermente migliori, ma fondamentalmente, puoi condividere i tuoi fogli di calcolo. Il problema della mancanza di funzionalità collaborative non è dovuto al fatto che sia un’app desktop. Il problema sta nella mentalità che accompagna i fogli di calcolo, che non è adatta a un lavoro collaborativo intenso. Di solito, se un collega ha creato un foglio molto complesso, è più facile ricrearlo piuttosto che cercare di capire cosa abbia fatto. Quindi, il problema con la mancanza di funzionalità collaborative è proprio quella mentalità, che intrinsecamente pone forti limiti alla collaborazione.

Tuttavia, Excel è completamente accessibile anche a chi non è sviluppatore, e c’è persino il Visual Basic for Applications per compiti più complicati. In termini di ingredienti, Excel soddisfa tutti i requisiti, il che, credo, spieghi in gran parte il successo operativo che ha nella maggior parte delle supply chain.

Nella mia esperienza, la maggior parte delle supply chain del mondo, dalle aziende più piccole alle più grandi, e da quelle che non hanno mai investito un centesimo in software enterprise a quelle che hanno investito milioni di dollari in software aziendale complicato per l’ottimizzazione della supply chain, sono gestite tramite Excel. Ci sono pochissime eccezioni. A volte, le persone usano Excel per rivedere le impostazioni min-max in altri software, ma la manutenzione di queste impostazioni viene affidata a chi lavora con Excel.

Excel guida il mondo della supply chain oggi e credo non sia un caso. Alla base, i fogli di calcolo affrontano fondamentalmente molti dei problemi giusti. Molte altre opzioni vengono presentate come superiori, ma falliscono per impostazione predefinita se non sai programmare. Se non sai programmare, significa che quando ti trovi di fronte a un grosso problema o a un’emergenza, sei nei guai. Le persone ricorreranno ai fogli di calcolo Excel nelle situazioni in cui manca un’interfaccia utente versatile, o quando una soluzione non è accessibile ai non sviluppatori. Se solo il team IT può portare risultati, inizialmente le persone apriranno ticket e aspetteranno pazientemente, ma entro tre mesi, probabilmente tutti torneranno a usare i fogli di calcolo Excel perché è più veloce. Excel non è la soluzione finale, ma qualunque cosa proponiamo come sostituzione superiore, dovrà soddisfare i requisiti necessari.

Come possiamo rendere qualcosa di migliore? In termini di memorizzazione dati versatile, Excel è valido ma non molto scalabile. L’elaborazione di milioni di righe diventa un problema, anche con le versioni moderne di Excel che possono gestire un milione di righe. I problemi di performance sorgono rapidamente quando si opera su larga scala. La logica programmabile in Excel è possibile, ma è molto fragile e delicata. Se accidentalmente introduci un errore o un bug nel tuo foglio di calcolo, il debug e l’individuazione della fonte del problema diventano un incubo. La logica viene duplicata all’infinito, generando migliaia di copie della stessa logica, rendendo difficile individuare e correggere gli errori.

L’interfaccia utente non è ideale, in quanto non è interamente web-based e i dati sono sempre intrecciati con l’interfaccia. Esistono capacità collaborative, ma sono disordinate. La collaborazione dovrebbe avvenire a livello di logica programmabile. Molti fornitori di ottimizzazione della supply chain offrono collaborazione sui risultati, come ad esempio modificare manualmente le previsioni e permettere la partecipazione di più persone. Tuttavia, questo è l’approccio sbagliato. Le collaborazioni devono avvenire, ma devono svolgersi a livello logico, a livello di logica programmabile. Excel è molto accessibile ai non sviluppatori, ma quando vuoi fare qualcosa di leggermente più complicato, diventa difficile. Nella gestione della supply chain, vogliamo affrontare tutti i possibili futuri, il che significa lavorare con previsioni probabilistiche, variabili casuali e gestire l’incertezza. Sebbene ciò sia possibile in Excel, risulta piuttosto complicato. Excel è semplice per compiti basilari, ma per situazioni più complesse, devi diventare un mago di Excel.

La manutenibilità è importante, poiché vuoi costruire un asset che cresca di valore nel tempo. Con i fogli di calcolo è difficile ottenere ciò, ed è complicato creare qualcosa di veramente accurato, almeno nel senso di un prodotto software.

Le parole d’ordine del giorno sono AI e Python, con tutte le tendenze e il clamore attorno alla data science. Tuttavia, per la gestione della supply chain, credo che Python sia inferiore a Excel.

Non fraintendermi; amo Python e penso che sia un linguaggio brillante. Lo insegno addirittura a mia figlia di 10 anni. Tuttavia, ci sono diverse ragioni per cui Python non è la scelta migliore per la gestione della supply chain. Innanzitutto, richiede ingegneri del software. Sebbene Python sia uno dei linguaggi di programmazione più accessibili, quando vuoi fare qualcosa di più complesso, hai bisogno di un team di ingegneri del software, il che crea delle sfide quando serve trovare persone che siano sia esperte della supply chain sia ingegneri del software.

Python ha delle caratteristiche interessanti, ma il modo in cui vengono gestite le dipendenze è piuttosto complesso, e la gestione dei pacchetti è scarsa. I pacchetti sono i mattoni fondamentali che forniscono capacità extra, e quando dici che vuoi usare Python, non ti interessa solo il linguaggio, ma anche l’intero ecosistema di pacchetti, come NumPy, Pandas, TensorFlow e SciPy – tutte dipendenze di terze parti o librerie software. La gestione dei pacchetti è stata scadente per oltre un decennio, e sebbene stia migliorando, i progressi sono lenti. Ci sono molti aspetti del design del sistema che rendono difficile migliorarlo.

Le prestazioni sono anche scarse, in gran parte per design. Le prestazioni computazionali si riferiscono alla qualità del lavoro svolto da Python nello sfruttare la potenza di calcolo grezza disponibile nel tuo computer. Sorprendentemente, Microsoft Excel svolge un lavoro molto migliore in questo ambito. Excel è altamente ottimizzato, sfrutta sistemi multi-CPU e multi-core, ed esegue logica compilata nativamente. Microsoft ha investito molto per rendere Excel estremamente veloce.

Al contrario, Python ha problemi intrinseci che spesso fanno sì che le prestazioni siano 100 volte più lente di quanto la tua macchina potrebbe teoricamente offrire. Sebbene a qualcuno possa sembrare accettabile, dato il potere dei computer moderni, non è l’ideale per aziende con volumi di transazioni superiori a 50 milioni di dollari. Vuoi qualcosa che offra buone prestazioni fin da subito.

L’idea di utilizzare una libreria di terze parti come NumPy per compensare la mancanza di performance di Python aggiunge solo complessità. Potresti risolvere il problema delle prestazioni, ma stai creando una nuova difficoltà introducendo la complessità aggiuntiva di NumPy, con cui devi confrontarti e che devi mantenere nel tempo. Questo alza anche il livello di complessità dal punto di vista dell’ingegneria del software.

Quando si tenta di implementare soluzioni Python per una gestione reale della supply chain, sorgono vari problemi, come eccezioni di riferimento nullo, eccezioni per esaurimento della memoria e lunghi tempi di calcolo. Potresti trovarti ad aspettare 20 minuti per il completamento di un calcolo, incerto se finirà o se dovresti semplicemente terminare il processo e riavviarlo. Non lo so, quindi desideri soluzioni per le quali hai un’idea davvero precisa di quanto tempo ci vorrà. A proposito, se torno a parlare di Excel, oggigiorno quando c’è un’operazione che richiede un po’ di tempo per essere completata, Excel ti fornisce un indicatore abbastanza affidabile, una barra di avanzamento che mostra quanto tempo mancherà al completamento. Quindi, ancora, desideri avere qualcosa che, come parte della prontezza alla produzione, ti permetta di sapere in anticipo i tempi di esecuzione. Vuoi avere qualcosa che, dato che il software che stai producendo probabilmente girerà in modalità non supervisionata, durante la notte o durante il batch notturno, non richieda la presenza di un data scientist a monitorarlo continuamente.

E ancora, se hai il problema dei data scientist, allora ti serve una terza competenza: esperto di supply chain, esperto di ingegneria del software e, infine, un data scientist esperto. È possibile avere tutte e tre le qualità in una sola persona, ma buona fortuna a ingaggiare più di una persona all’anno, anche se sei una grande azienda che possiede tutte queste competenze. È semplicemente molto raro.

Quindi, vogliamo avere qualcosa che possa migliorare. A proposito, la prima cosa che vogliamo migliorare è la difesa in profondità. I ransomware sono in aumento, e ogni volta che introduci qualcosa di programmabile nella tua organizzazione, ti esponi a ransomware. Perché, improvvisamente, quando hai un programma, quest’ultimo sulla macchina può fare un’infinità di cose, incluso dirottare la stessa macchina su cui gira. So che esistono molti modi per mitigare i problemi; puoi isolare le applicazioni in sandbox, puoi imporre restrizioni, puoi avere diritti limitati, e ci sono molteplici metodi per contenere le problematiche. Tuttavia, ogni volta che utilizzi un linguaggio di programmazione generico e a uso generale, la tua superficie di attacco – che è un termine tecnico – diventa assolutamente gigantesca.

In sostanza, ogni volta che inserisci codice in questo modo, ti esponi in maniera massiccia a problemi di sicurezza. E ricorda, il modo tipico in cui viene fatto in una normale azienda di ingegneria del software è che il codice viene revisionato dai colleghi. Quindi rivedi il codice, hai un processo di code review, qualcuno produce il codice e un collega lo esamina per assicurarsi che non ci siano imprecisioni. Ma se torno al fatto che il software deve essere robusto, devi essere in grado di rispondere in poche ore. Dal punto di vista dell’ottimizzazione della supply chain, non potrai avere un processo di revisione del codice in atto. Non è compatibile con i ritardi e le emergenze che affronterai.

Quindi, hai bisogno di qualcosa che ti offra per design una difesa in profondità. Poi, vuoi avere qualcosa con prestazioni trasparenti, dove sì, le operazioni possono richiedere tempo, ma devi avere il controllo. Devi sapere in anticipo quanto tempo ci vorrà. Se non ci sei, ti esponi a una marea di problemi veramente sciocchi, come avere una finestra di due ore per consegnare i risultati e arrivare in ritardo. E sai una cosa? I camion sono già partiti. È troppo tardi. Quindi, hai bisogno di qualcosa in cui tutto sia già sistemato.

E lo stesso vale per gli aggiornamenti trasparenti. Questa è la bellezza di Excel. Non devi preoccuparti della manutenzione di Excel. Decenni fa, Microsoft ha firmato un patto di sangue, secondo il quale: se hai prodotto un foglio di calcolo Excel, qualunque sia la prossima versione di Excel che arriverà sul mercato, sarà in grado di supportare i tuoi fogli di calcolo. E la cosa più incredibile è che, se guardi Excel oggi, supporta molti formati Excel concorrenti di aziende che non esistono più. Puoi ancora leggere fogli di calcolo prodotti con Lotus Notes e cose simili. Quindi, la proposta di valore di Microsoft in termini di aggiornamenti trasparenti è che la logica che hai prodotto funzionerà per sempre, e sì, continueranno a migliorare Excel per decenni, ma sai una cosa? È tutto a posto. Non è qualcosa che si vede nel passaggio da Python 2 a Python 3; fu un incubo e ci volle un decennio. Quindi, Python è ottimo per molte cose, ma immagina che quegli aggiornamenti possano accadere nei momenti peggiori, quando hai la peggior pandemia, la peggior tariffa, la peggiore emergenza, e hai bisogno che tutto sia operativo e pronto. Non puoi permetterti sei mesi di inattività solo perché devi occuparti di un aggiornamento. Non è qualcosa di compatibile con l’ottimizzazione della supply chain.

Quindi ora dobbiamo pensare: e se considerassimo qualcosa progettato appositamente tenendo in mente la supply chain? Questo sarà l’argomento della prossima lezione.

Ora, inoltre, la supply chain non è il reparto IT. Quando dico una consegna orientata al prodotto, non intendo che il software sia solo un mezzo, non un fine. Non venderai il tuo software per licenze o una tariffa come, ad esempio, fa Microsoft. In questa visione che sto delineando in questa lezione, l’IT è responsabile delle pratiche core, le pratiche IT di base, come ciò che dovresti fare o non fare in termini di sicurezza, backup, infrastruttura core, rete, come gestire e sincronizzare tutto in termini di dati a livello aziendale, e nel fornire tutta la guida e il coaching.

Ma l’idea è che la supply chain debba essere proprietaria delle decisioni della supply chain. Deve possedere tutto l’apparato che genera tali decisioni, ed è questo il loro nucleo di proprietà. Nella lezione precedente ho detto cosa definisce il Supply Chain Scientist: il Supply Chain Scientist è colui che possiede le decisioni numeriche prodotte dal codice. Non si tratta di un sistema che genera decisioni; sono ricette numeriche scritte da uno o più Supply Chain Scientists, e questi Supply Chain Scientists possiedono collettivamente tali decisioni numeriche. Se ne fanno carico, e la responsabilità della supply chain è assicurarsi che tutte le decisioni in azienda siano coerenti. Se c’è una promozione in corso o un grande slancio di marketing, le cose devono essere prodotte in tempo per essere pronte ad essere servite. Non vuoi trovarti in una situazione catastrofica in cui lanci qualcosa mentre sei già in una situazione di quasi stock-out, dove spendi soldi per un’azione di marketing per qualcosa che non riesci nemmeno a vendere perché non hai lo stock o la capacità di produrli o di fornire il servizio in tempo, ecc.

Quindi, abbiamo due divisioni con focalizzazioni molto diverse. Nella mia visione ideale di cosa dovrebbe essere il reparto IT, il reparto IT non è una divisione dove si smistano ticket. Non funziona così. Il reparto IT è responsabile dell’infrastruttura core. È quel tipo di cosa che funziona in modo impeccabile tutto il tempo. Non ci pensi nemmeno, proprio come il Wi-Fi funziona: non ti accorgi del Wi-Fi, ma ti rendi conto della sua assenza solo quando non funziona. Un buon reparto IT fornisce tutta l’infrastruttura in modo che tu non debba nemmeno pensarci. Non ti rendi nemmeno conto della loro esistenza, perché tutto funziona automaticamente, proprio come le tue email che funzionano alla perfezione, ecc. Questo è il vero senso di un buon core IT. E poi, l’IT è il tipo di persone che viene da te e ti aiuta a stabilire tutte quelle pratiche che ti danno una mano. La logica programmabile è un po’ complicata, quindi a volte, dove trovi il coaching per migliorare in termini di programmazione? Beh, la risposta è: dovrebbe essere l’IT. Non dovrebbero venire a dire “Lo programmeremo per te”, ma piuttosto “Ti faremo da mentori affinché tu possa implementarlo tu stesso. Ti aiuteremo con alcuni concetti, magari ti spiegheremo cose un po’ più tecniche di quanto dovrebbero essere.” A volte, c’è una complessità accidentale, quindi l’IT è lì per supportarti. Ma fondamentalmente, non sono lì per fare il lavoro al posto tuo. Dovrebbero essere mentori e coach, assicurandosi che nessuno compia un errore fatale che possa esporre l’intera azienda a rischi come quelli di un ransomware o a un rischio sistemico, da un punto di vista IT.

Come test del limone, se l’interazione tra IT e supply chain avviene tramite documenti in cui elenchi specifiche o requisiti, questo non è il modo corretto per instaurare un buon rapporto tra queste due divisioni. Quando dico un buon rapporto, intendo qualcosa che aggiunga effettivamente valore all’azienda.

In conclusione, abbiamo due sfide qui dal fronte della gestione tradizionale della supply chain, che forse ha fatto programmazione solo al limite dei fogli di calcolo Excel, senza nemmeno rendersi conto inizialmente che si trattasse già di una forma di programmazione. Devi superare le tue paure. Devi concepire che il mondo di domani, la tua divisione, sarà responsabile di fornire un prodotto che funziona come un prodotto software, e questo rappresenta un cambiamento enorme. Sì, ma è qualcosa con cui puoi fare i conti. Perché? Perché se hai gli strumenti giusti, sì, c’è della programmazione, ma non è fondamentalmente o radicalmente più difficile di Excel. Ancora una volta, la sfida non risiede nella tecnicità dello strumento; risiede letteralmente nella complessità della supply chain stessa. Il problema è difficile non perché il tuo strumento sia difficile da maneggiare, ma perché hai una supply chain complicata sin dall’inizio.

Per quella parte del pubblico che è forse più orientata al lato data scientist o IT, ciò che devi superare è l’eccesso di fiducia. Ho visto, ancora e ancora, data scientist, e mi includo in questa categoria, che erano troppo sicuri della loro capacità di portare un prototipo in produzione. Questo è difficile, e le supply chains hanno un modo di esplodere in faccia nel modo più sorprendente. Riesco a ricordare solo un aneddoto in cui, anni fa, abbiamo iniziato con una delle principali aziende europee di e-commerce per ricambi auto. Gestivamo i loro rifornimenti di parti con la nostra tecnologia di previsione, fornendo suggerimenti per il rifornimento, servendo ricambi auto. La settimana successiva, abbiamo visto che tutte le nostre previsioni erano sbagliate di un fattore due. La domanda era raddoppiata. Quello che era successo era che il loro principale concorrente aveva deciso di espandersi in più paesi contemporaneamente, letteralmente nel momento in cui stavamo iniziando la nostra previsione, uno dei concorrenti aveva deciso di andare in tutte le TV nazionali e iniziare a trasmettere il loro servizio online. La cosa interessante è che il mio cliente non ne era nemmeno a conoscenza, e avevano risultati migliori in ottimizzazione SEO. Le persone vedevano lo spot TV del concorrente, ma non ricordavano naturalmente il nome del concorrente. Quindi, andavano su Google e digitavano “ricambi auto” finché non finivano sul sito web del mio cliente. Per dimostrare quanto fosse fantastico Lokad, la prima settimana in cui abbiamo iniziato eravamo fuori di un fattore due, e pensavamo: “Ma che diavolo sta succedendo?” Abbiamo dovuto rivedere tutto, perché quando vedi che la domanda raddoppia, non è che tutto raddoppia; alcune cose fanno 10 volte di più, e molte rimangono invariate.

Quindi, è questo il genere di situazione, e devi essere in grado di reagire rapidamente. Di questo si tratta: paura ed eccesso di fiducia. Grazie mille per il vostro tempo.

Ora darò un’occhiata alle domande attraverso la chat.

Domanda: Il software può prendere la decisione su quale fornitore piazzare un ordine extra nel caso in cui se ne abbia bisogno per domani? Ad esempio, contenitori da 200 grammi di fragole negli uffici in Australia potrebbero avere 10 fornitori che consegnano gli stessi prodotti al centro di distribuzione nello stesso giorno.

Assolutamente, e qui dobbiamo differenziare le due facce della supply chain management e della supply chain optimization. Da un lato c’è la supply chain management, che consiste letteralmente nell’avere in atto tutte le data pipelines necessarie, inclusi gli EDI, tramite i quali è possibile inviare un ordine elettronico a un fornitore senza alcun intervento umano. Così si dispone di un ponte elettronico end-to-end. Ma ciò significa che, sul lato optimization, è necessario avere un software che funzioni continuamente durante tutto il giorno e che, a un certo punto, possa notificare il lato management dicendo: “Per favore, esegui questo ordine.” E poi, sul lato management, che sarà gestito dall’IT, ci si assicura semplicemente che quest’ordine venga eseguito completamente. Si tratta unicamente di pura transazionalità; non c’è più intelligenza. Hai ricevuto un ordine che indica “questa quantità”, ed è il lato optimization che si assume la responsabilità di assicurarsi che, quando generi una certa quantità, tu sia conforme a tutti i vincoli, come l’elenco esatto dei fornitori che sono effettivamente idonei a servire questi prodotti, se hanno ancora scorte e come fare la scelta giusta tra tutti i fornitori in concorrenza, ecc. Potrebbero esserci moltissime variabili in gioco. Assolutamente sì, ma dobbiamo letteralmente separare l’esecuzione banale, che è la parte transazionale che risiede sulla supply chain management, dall’ingrediente optimization nel momento in cui decidi che hai bisogno di riordinare di più.

Domanda: Sai che stai competendo con gli eSports World Championships in questo momento?

No, non sto competendo con quegli eSports championships in questo momento, ma è molto interessante. A proposito, in Lokad giochiamo spesso a Dota 2, quindi anche il team di management partecipa. Alcuni dei nostri dipendenti vogliono giocare a League of Legends, ma in qualità di CEO dell’azienda, mi oppongo fermamente.

Domanda: Ho visto che molte aziende non dispongono di un ERP o WMS in primo luogo, e che la gestione sta lavorando sulla supply chain optimization.

Beh, assolutamente. Non puoi evitare la supply chain optimization fin dal primo giorno; devi prendere quelle decisioni. La supply chain optimization esisteva già prima che esistesse un qualsiasi software per la supply chain management. Anche se torniamo indietro di 60 anni, quando non c’era software, le persone dovevano comunque prendere decisioni. Quindi la supply chain optimization era già una realtà; la gente la gestiva con carta e penna. Se guardi le prime opere sulla supply chain, come la Formula di Wilson, nota anche come formula EOQ, risale a un secolo fa. È chiaramente antecedente al software. Quindi sì, la supply chain optimization è qualcosa che accade fin dal primo giorno, indipendentemente dal fatto che la tua organizzazione disponga o meno di software.

Ora, in effetti, è necessario disporre di sistemi IT adeguati, ma è una mentalità completamente diversa. La supply chain management riguarda l’esecuzione accurata di compiti banali, come l’inserimento dei dati, eventualmente con il supporto di codici a barre e altre tecnologie. Ma si tratta di compiti molto routinari, semplicemente di rappresentare i dati. Il problema è che le persone vogliono qualcosa che faccia sia la supply chain management sia la supply chain optimization, e di conseguenza si finisce per avere un prodotto troppo complicato, solitamente pieno di bug, e che presenta funzionalità scadenti come avvisi ed eccezioni, che andrebbero evitate. Ne tornerò in una lezione successiva.

Fondamentalmente, al giorno d’oggi, implementare un WMS o un ERP, se non ne hai già uno, è una questione di settimane. Se ne hai già uno, può richiedere mesi se riesci a disaccoppiare questo aspetto dalle tue decisioni.

Domanda: Quando può la direzione dell’azienda rendersi conto che è il momento di passare dal monitorare le informazioni all’ottimizzazione delle decisioni sulla supply chain e, infine, iniziare a concentrarsi sulla supply chain optimization?

La prima cosa è che devi prima renderti conto che esistono due problemi, e che lo stesso software non potrà mai affrontare entrambe le prospettive. Credo che questa sia la grande illusione, e i fornitori di software sono stati incredibilmente confusi in quest’area. Se guardi i più grandi fornitori di ERP, il loro messaggio riguarda la supply chain optimization, ma tutto ciò che effettivamente offrono e tutte le funzionalità del loro prodotto rientrano nella supply chain management, che è molto meno intrigante perché non c’è né AI né vera intelligenza. Nel mondo del software, queste applicazioni sono note come app CRUD (Create, Read, Update, Delete). Gli ERP sono semplicemente collezioni gigantesche di schermate CRUD, in cui ogni singola schermata può creare, leggere, aggiornare o cancellare righe da un database relazionale, e basta. Un ERP è fondamentalmente, semplificando un po’, una raccolta di migliaia di tabelle per varie entità. Per ogni entità che può essere raggruppata logicamente, hai una o due schermate, e questo è tutto. Quindi, se torno alla tua domanda riguardo alla direzione, il problema è che se sei un manager, leggi la brochure del fornitore di ERP, e questi ti dicono che questo sistema sta per ottimizzare la tua supply chain. La risposta è: no, assolutamente no. Quello che farà è migliorare la produttività e garantire una contabilità accurata della tua supply chain. Questo è già molto, poiché può ridurre drasticamente furti, perdite, articoli smarriti e migliorare la produttività con i codici a barre per un magazzino. C’è molto valore aggiunto in questi prodotti. Non sto sminuendo il valore che un ERP o un WMS porta al tavolo; è enorme, ma non riguarda la supply chain optimization. Un WMS, ad esempio, è per design concepito per occuparsi del magazzino; non si preoccupa dell’intera supply chain che include clienti e fornitori. È per design focalizzato su posizioni specifiche, non sull’intera catena.

Domanda: Come si può passare in modo fluido da Python a Envision o farli lavorare insieme?

Storicamente, li abbiamo fatti lavorare insieme in alcune situazioni. Per il pubblico, Envision è un linguaggio di programmazione specifico per il dominio, progettato da Lokad e ingegnerizzato esclusivamente per la predictive optimization delle supply chains. Nella prossima lezione, dimostrerò Envision in modo che le persone possano comprendere meglio di cosa sto parlando, con esempi reali di codice.

Storicamente, abbiamo utilizzato Python ed Envision insieme perché, quando abbiamo iniziato, Envision aveva capacità molto limitate, quindi mancavano molte funzionalità e in molte situazioni ricorrevamo di default a Python. Nel corso degli anni, abbiamo gradualmente ampliato le capacità di Envision, eliminando progressivamente la necessità di componenti Python. Non si trattava solamente di componenti Python; c’era anche una serie di strumenti che dovevano essere integrati, come Airflow.

A proposito, la sintassi di Envision è stata volutamente allineata in molti aspetti a Python. Ho fatto la scelta consapevole di progettare la sintassi di Envision in modo da non antagonizzare i programmatori Python, così che, se hai familiarità con Python, puoi imparare Envision in una settimana. Essa differisce in modi sottili e profondi, ma per quanto riguarda la sintassi, molti aspetti sono gli stessi. Python ha molti meriti, come la semplicità e la purezza del design. Anche se dico che Python non soddisfa tutti i requisiti e crea problemi gravi in produzione che non possono essere recuperati, non significa che Python sia privo di meriti. Non è questo che intendo dire. Credo che Python abbia molti meriti. Ancora una volta, stiamo parlando specificamente di come gestire le supply chains in produzione, che è un problema molto specifico.

Domanda: Come faresti capire a un cliente che il suo ERP non sta ottimizzando nulla?

È molto difficile perché, a dire il vero, la situazione peggiore è quando un potenziale cliente mi dice: “Il nostro ERP, un ERP legacy, non sta fornendo alcun valore, e ora vogliamo passare al prossimo ERP che offra supply chain optimization.” È una situazione terribile per me, perché devo spiegare al cliente che ciò che sta cercando non è un solo prodotto, ma due: uno che sostituirà il loro ERP e gestirà meglio il lato management, e uno che si occuperà dell’optimization.

Quando pensi a quegli ERP legacy, li rispetto molto, specialmente quei prodotti AS/400 con terminale a riga di comando su vecchi mainframe IBM. Dal punto di vista del management, di solito fanno un lavoro molto decente. Quello che i clienti cercano davvero potrebbe essere un’interfaccia web piuttosto che una riga di comando, ma questo renderà i loro team sul campo più produttivi? Lo metto in discussione. Le righe di comando con terminali testuali possono essere incredibilmente veloci e produttive, senza distrazioni.

Quindi, è abbastanza difficile perché dobbiamo districare tutte le sciocchezze spingevate dai nostri concorrenti. Inoltre, dobbiamo spiegare che l’ERP non ottimizzerà la supply chain e che non esiste qualcosa come l’AI o la blockchain, ma solo classi di modelli statistici. Purtroppo, perdiamo la maggior parte dei potenziali clienti a questo punto. Questo è uno dei motivi per cui tengo queste lezioni, perché ci vogliono ore per arrivare al nocciolo della questione e spiegare perché dobbiamo vedere il problema nel modo in cui io lo vedo.

Domanda: Qual è la tua raccomandazione per una piattaforma che affronti la complessità della pianificazione di più prodotti con distribuzione probabilistica della domanda?

Beh, Lokad, ovviamente. Ma tieni presente che, essendo il CEO di Lokad e il proprietario di maggioranza della società, ho un conflitto di interessi, a mio parere. Sono profondamente convinto che Lokad sia la piattaforma di cui hai bisogno, ma per favore comprendi che è anche l’azienda che possiedo e gestisco. Farò del mio meglio per rimanere obiettivo al riguardo.

A proposito, Lokad è stata letteralmente progettata per gestire la distribuzione probabilistica della domanda, e non si occupa solo di questo aspetto. Affronta anche la distribuzione stocastica dei lead time, la distribuzione stocastica dei resi e altro ancora. Dobbiamo considerare tutti i possibili futuri con le rispettive probabilità, tenendo conto di ogni tipo di incertezza. La domanda è una delle più importanti, solitamente la più rilevante, ma non è l’unica.

Penso di aver affrontato tutte le domande. Controllo se mi è sfuggito qualcosa… Nessun’altra domanda. Quindi, grazie a tutti per aver seguito questa lezione, e ci vediamo la prossima settimana, lo stesso giorno, alla stessa ora. A presto. Arrivederci.

Riferimenti

• Joel on Software: E su questioni varie e occasionalmente correlate che risulteranno di interesse per sviluppatori software, designer e manager, e per coloro che, per buona sorte o sfortuna, lavorano con loro in qualche veste - Di Joel Spolsky, 2004