Consegna orientata al prodotto per Supply Chain - Lezione 1.3

00:22 Introduzione
02:40 Perché un prodotto? Perché il capitalismo
08:18 Cosa dovrebbe fare il prodotto?
10:05 Diseconomie di scala del software
12:50 Compriamo un prodotto SCO da scaffale
21:58 SCM vs SCO
25:58 Interludio
28:21 SCO non è un prodotto software come gli altri
33:26 Ingredienti software per SCO
42:49 Eppure, i fogli di calcolo non sono la soluzione definitiva
46:51 Python non è nemmeno la soluzione definitiva
58:52 SC non è una divisione dell’IT
01:03:19 In conclusione, due sfide da superare
01:07:04 Lezione successiva e domande del pubblico

Descrizione

L’obiettivo di un’iniziativa quantitativa Supply Chain è quello di realizzare o migliorare un’applicazione software che automatizza un insieme di decisioni di routine (ad es. rifornimenti, aggiornamenti dei prezzi). L’applicazione è concepita come un prodotto da ingegnerizzare. La supply chain theory serve ad aiutarci a realizzare un’applicazione che orienti l’azienda verso la supply chain performance, garantendo al contempo la compatibilità con tutti i vincoli 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”.

Innanzitutto, quando parlo di prodotto, intendo un prodotto software. Per chi di voi ha mai avuto il privilegio di scoprire cosa si cela dietro il funzionamento di un moderno pezzo di software, potrebbe essere un’esperienza davvero intensa.

Per chi conosce l’opera di H.P. Lovecraft, esistono alcune inquietanti somiglianze. Lovecraft ha prodotto una serie di romanzi, e uno dei temi ricorrenti è l’idea della conoscenza proibita. Non è che l’universo non possa essere conosciuto, lo è; è 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 perché le nostre menti possano sopportarlo. Questa idea è stata riproposta in molti giochi moderni, soprattutto nei giochi di ruolo, dove, oltre ai tradizionali punti salute, i personaggi hanno punti sanità mentale. Se fai certe cose che danneggiano la tua sanità mentale, perdi dei punti. La sfida con il enterprise software è riuscire a crearlo preservando la propria sanità, requisito fondamentale per aggiungere valore all’azienda. Quindi, procediamo.

Perché un prodotto, e in particolare un prodotto software? Esaminiamo attentamente come operano tradizionalmente le supply chains. In passato, c’erano molte persone sul campo che spostavano oggetti, smistavano pacchi, guidavano veicoli e svolgevano tutta la manodopera manuale. C’erano anche molte persone coinvolte nella produzione, così come nei negozi. Ciò che è accaduto gradualmente negli ultimi decenni è che il numero di persone con lavori manuali è diminuito costantemente. Oggi, dal punto di vista produttivo, le operazioni sono ampiamente automatizzate. Rimangono ancora alcuni settori, come quello tessile, dove è difficile automatizzare tutto, motivo per cui tali industrie si sono spostate dove la manodopera è più economica. La realtà è che i requisiti di manodopera grezza sono stati notevolmente ridotti.

Si arriva ad una situazione abbastanza paradossale in cui, guardando al futuro con l’avvento dei veicoli autonomi, molte aziende avranno più impiegati che si occupano di fogli Excel per gestire la supply chain, rispetto alle persone con mansioni manuali sul campo. A questo mi riferisco quando parlo di lavoro amministrativo.

Un altro aspetto peculiare è che le supply chains sono state digitalizzate per molte aziende da almeno due decenni. Non è che stiamo per introdurre il software nelle supply chains; le supply chains sono già gestite e operative tramite software. Ma se osserviamo il ruolo degli esseri umani in questi sistemi software, vediamo che vengono letteralmente impiegati come co-processori umani nel sistema medio di supply chain. Esistono tipi specifici di operazioni che la CPU tradizionale, il processore della macchina, non è in grado di eseguire, e quindi l’intero compito viene delegato a un umano. In combinazione con numerical recipes semplificate, come l’ABC analysis, l’inventario min-max e ricette simili, gli esseri umani finiscono per trascorrere le loro giornate a spegnere incendi. Si trovano sempre a gestire eccezioni e condizioni che non rientrano nel quadro standard.

Da un punto di vista dei costi, tutto ciò rientra nelle spese operative (OpEx). È necessario pagare un esercito di impiegati ogni singolo giorno per gestire tutte le decisioni banali che la tua 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 si occupano di situazioni d’emergenza per far fronte alle inadeguatezze delle decisioni automatiche generate in modo ingenuo dal sistema.

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

Ritornando al tema della mia lezione precedente, abbiamo bisogno della robotizzazione per rimettere il management al comando. L’automazione e gli esseri umani dovrebbero lavorare insieme; gli esseri umani non dovrebbero essere impiegati per far fronte alle inadeguatezze di politiche di inventario semplicistiche come il min-max. Invece, dovrebbero essere lì per aggiungere valore, migliorare le ricette numeriche e agire come strateghi. C’era un vecchio motto IBM che recitava: “Le macchine devono lavorare; le persone devono pensare.” È questo il tipo di pensiero 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 eroga un prodotto software.

Che cosa fa effettivamente questo prodotto? Si scopre che fa qualcosa di abbastanza semplice: prende decisioni. Non decisioni arbitrarie e a braccio, ma quelle banali e di routine, come cosa produrre, quante unità acquistare da un fornitore e quante unità spostare da una sede all’altra. A prima vista, potrebbe sembrare che nella gestione della supply chain ci siano molte decisioni da prendere. Tuttavia, esaminando le attività, anche le supply chains più complesse richiedono soltanto alcune decine di tipi di decisioni da adottare ogni singolo giorno. Questo non è opprimente ed è del tutto ragionevole in termini di numero assoluto di funzionalità. Curiosamente, queste decisioni sono in gran parte esclusive, il che implica dei limiti a ciò che si può fare adottando un approccio divide-et-impera. Una volta deciso di acquistare 100 unità da un fornitore, non puoi far sì che un altro sottosistema decida di comprarne 200 invece. Ad un certo punto, devi decidere con esattezza quante unità acquistare e spostare da una sede all’altra. Queste decisioni sono discrete, limitate nel campo d’azione e per lo più esclusive. Quello che desideriamo è un pezzo di software che generi decisioni d’ordine in maniera completamente automatica ogni singolo giorno.

Una cosa che credo venga spesso fraintesa riguardo al software è il concetto di diseconomie di scala. Mentre le economie di scala sono note alla maggior parte, il contrario è vero nel software, dove aggiungere un quarto di funzionalità in più può raddoppiare il costo. Questo concetto spiega perché le piccole startup possono competere con le grandi aziende: concentrandosi su una frazione minore di funzionalità, il costo per portare il loro prodotto sul mercato può essere significativamente inferiore rispetto 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 vendor software dovrà fornire per servire il mercato.

Quindi, consideriamo l’ipotesi di acquistare un prodotto di ottimizzazione della supply chain da scaffale. In queste diapositive offro una panoramica di una piccolissima frazione di tutte le cose che dobbiamo affrontare. Ho un’esperienza diretta in merito, poiché quando ho fondato Lokad nel 2008, ho iniziato con un piccolo prodotto software orientato più alla previsione che all’ottimizzazione della supply chain. Man mano che ho iniziato a lavorare con i clienti, mi sono reso conto che c’erano così tante funzionalità e capacità che mi mancavano e, passando ad altri clienti, ho riscontrato ancora più lacune. Sembrava un processo senza fine di scoperta di nuovi requisiti.

Diamo un’occhiata solo alle funzionalità di base. In primo luogo, abbiamo aziende che sono B2C o B2B, le quali presentano schemi completamente differenti nella gestione della supply chain. Ad esempio, le aziende B2B tipicamente hanno meno clienti, ma questi ordinano quantità molto maggiori. Ciò comporta diversi tipi di rischi, come il rischio di perdere un singolo cliente che rappresenta una parte significativa del fatturato aziendale. Poi ci sono modelli di business più complessi come B2B2C o B2B2B.

Considera i vari tipi di sedi che devono essere gestite, come negozi, magazzini e impianti di produzione. Ogni tipo di sede presenta il proprio insieme di sfide. I negozi, per esempio, sono soggetti ad imprecisioni 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 miniere, comportano problemi specifici e incertezze legate al rendimento produttivo.

Le reti di supply chain possono avere diversi livelli, o scaloni, che vanno da sistemi a singolo livello a sistemi multi-livello. La complessità di gestire la supply chain aumenta significativamente man mano che cresce il numero di scaloni. La topologia della rete è un altro aspetto importante da considerare. Una topologia ad albero è il classico percorso forward della supply chain, in cui pochi impianti di produzione smistano verso 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.

Quindi, fondamentalmente, non si tratta solo di un albero nel senso dei grafi, può riconnettersi, sebbene rimanga solo un flusso forward. Ma lo stesso può accadere con un Directed Acyclic Graph (DAG) quando si hanno più fornitori. Si possono avere persino cicli nel grafo della supply chain che si verificano ogni volta che sono coinvolte riparazioni. Ad esempio, nell’industria mineraria o nell’industria aviazione, ci sono innumerevoli cicli di riparazione con attrezzature riparabili.

Adesso, l’inventario stesso non ha una natura univoca; varia molto. Non puoi semplicemente dire: “Oh, ho questa idea che ho degli SKUs e basta.” No, non proprio, perché innanzitutto hai le materie prime che sono letteralmente misurate in quantità come grammi, chilogrammi o volume. Poi hai le unità, quelle pulite e ben definite, che sono le più diffuse. Ma poi puoi anche avere grandi quantità di inventario che si verificano molto frequentemente, ad esempio, in campo farmaceutico o nell’industria alimentare, dove il lotto è accompagnato da date di scadenza specifiche. Infine, puoi avere un inventario completamente serializzato, in cui ogni singola unità ha il proprio numero di serie. In termini di ottimizzazione della supply chain, questo cambia radicalmente le regole del gioco, diventando un problema completamente diverso quando si analizza ciascuno di questi aspetti.

Poi, ovviamente, ci sono tutti i problemi dei marketplace. Da Lokad, abbiamo clienti in ogni situazione possibile. Abbiamo clienti che vendono su un marketplace di terze parti, che possono avere il proprio marketplace, oppure entrambi. Può trattarsi di qualcosa di secondario, da utilizzare per liquidare ciò che non è stato venduto. Ci sono molte situazioni.

Ora, ad esempio, pensa per un momento a cosa sia un ordine. C’è l’ordine spot, in cui fondamentalmente compri qualcosa al momento e diventa tuo. Ma poi c’è anche l’ordine che recita: “Lo sto acquistando, ma non voglio che venga consegnato immediatamente; desidero che la consegna avvenga tra un mese.” Ovviamente, dal punto di vista dell’ottimizzazione della supply chain, è un gioco completamente diverso, perché se sai in anticipo che dovrai consegnare una certa quantità di merci in una data specifica, non vuoi prevederlo, quindi è qualcosa di completamente differente.

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

Anche per i prezzi, puoi avere il prezzo unitario che è fisso, super semplice e super lineare, ma non è l’unica cosa. Puoi avere scalini di prezzo, per esempio, se acquisti dieci unità, allora ottieni uno sconto. Oppure puoi avere programmi di loyalty in cui alcuni clienti con una tessera fedeltà possono ottenere uno sconto, ma solo su determinati tipi di prodotti o a determinate condizioni. E poi puoi anche avere, nel B2B, cose molto frequenti che vengono negoziate, quindi si tratta letteralmente di una transazione in cui verranno vendute molte cose, ma hai un prezzo di listino regolare. Tuttavia, un fornitore può concedere un rimborso a un cliente perché è importante, ed è proprio così che si fa. In sostanza, ho parlato per pochi minuti e ho solo coperto l’essenziale. Non ho nemmeno iniziato ad affrontare le cose imprescindibili. Fermati un attimo e prova a immaginare come potrebbe essere un prodotto software aziendale standard, pensato per fornire l’ottimizzazione della supply chain. Il numero di funzionalità da coprire è letteralmente pazzesco, e quando provi a pensare a come mettere insieme tutte quelle cose in un monolito, stai letteralmente perdendo la testa. Siamo tornati all’idea che non è che l’universo non possa essere conosciuto, ma semplicemente che se sei esposto alla cruda verità dell’universo, perdi la sanità mentale.

Abbiamo un problema importante, e qui dobbiamo differenziare tra la gestione della supply chain e l’ottimizzazione della supply chain. È una distinzione che ho già introdotto in una delle mie lezioni precedenti. C’è una grande confusione tra la parte gestionale e quella di ottimizzazione. La gestione riguarda la contabilità, il supporto ai flussi di lavoro e, soprattutto, 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 per avere 10.000 tabelle, sarà piuttosto brutto, ma è possibile. Ma non fraintenderti, l’ERP (che andrebbe chiamato ERM, Enterprise Resource Management) non farà molto. Si limiterà a tenere traccia di quelle cose. Quindi avrai tonnellate di entità – MOQs, check; scalini di prezzo, check; negozi, check; magazzini, check – ma non è necessario che abbiano un minimo di “intelligenza”. Si tratta semplicemente di controparti digitali banali che riflettono i dati, rendendo possibile l’inserimento degli stessi nel sistema, e basta.

È possibile perché, qui, possiamo imbrogliare un po’ con la 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 separate. Finché queste non interagiscono tra loro, va bene; non sei soggetto a quella maledizione delle diseconomie di scala. Dal punto di vista dell’inserimento dati, non c’è problema. Non ti serve avere un’interfaccia utente che ti permetta di gestire i MOQs collegati a ciò che ti consente di aggiungere un negozio in più alla rete. Queste due cose possono essere completamente separate.

Tuttavia, quando si tratta dell’ottimizzazione della supply chain, non è lo stesso. Se hai dei MOQs, questi avranno profonde implicazioni su quanto frequentemente fai ordini e su quanto frequentemente consegni le merci dal tuo magazzino ai negozi. Ci sono numerose conseguenze di vasta portata. Non puoi separare le cose perché, in definitiva, la tua supply chain è un sistema unico in cui tutto influenza tutto. Quindi, da una prospettiva di ottimizzazione della supply chain, letteralmente hai il problema che tutte quelle cose devono essere integrate se vuoi ottenere l’ottimizzazione, ed è qui che tutto viene meno.

Dal lato gestionale, potresti eventualmente 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 in Lokad, che non è partita come un’azienda specializzata in previsioni per la supply chain o in ottimizzazione predittiva della supply chain, ma piuttosto offrendo forecasting as a service. Se torni al blog di Lokad nel 2008, ho iniziato inizialmente con le previsioni time series, che erano fortemente fuorvianti. Comunque, è così che ho cominciato. Anche per le previsioni delle serie temporali, che rappresentano un minuscolo sottoinsieme dell’intero problema, è ingovernabile. Questa è la mia conclusione dopo essere stato in questo settore per oltre 12 anni.

Se dobbiamo tornare al mondo specifico della produzione di software, è qualcosa di molto unico. A meno che tu non sia stato formato come ingegnere del software e non conosca il modo in cui le grandi aziende di software di successo producono i loro prodotti, è probabile che tu sappia molto poco a riguardo. Risulta che si tratti di un mondo molto particolare con numerosi aspetti fortemente controintuitivi. Le aziende tradizionali, specialmente quelle con una mentalità classica da ingegneria meccanica o da marketing, lottano enormemente per capire come funziona il software.

Tratteremo questi aspetti in modo più dettagliato nelle prossime lezioni, ma c’è un libro che mi piace molto, curato 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 solo uno studente, ho letto il suo libro e il suo blog. Il libro si intitola “Joel on Software” e, in modo ironico, ti dà un’idea di come si gestisca un’azienda di software di successo. È molto diverso da quello che la maggior parte delle persone al di fuori di questo settore si aspetta. Aggiungerò i dettagli di questo libro nella descrizione del video.

Ma ricordiamo che l’ottimizzazione della supply chain non è un prodotto software qualunque. Di solito, quando hai a che fare con un prodotto software medio – voglio dire, sì, possono esserci comportamenti avversi, a seconda del tipo di software – se si tratta di un social network, potresti avere tante persone che pubblicano contenuti d’odio, il che è un gioco completamente diverso. Tuttavia, quando parliamo di software aziendale classico, come Microsoft Word o Excel, si tratta di un prodotto in cui desideri avere un design adeguato, ma non esiste 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 al futuro su decenni. Non c’è motivo di avere fretta nello sviluppo. Tuttavia, l’ottimizzazione della supply chain non funziona così. Non hai la scelta, poiché le cose accadono continuamente e il terreno è molto accidentato.

Puoi affrontare situazioni estreme come una 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 le tariffe che interrompono la tua strategia, o disastri naturali come tsunami, incendi o ondate di calore, come quelli in California o in 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 un cambiamento, e vuoi che questo cambiamento sia programmabile. Ricorda, se hai in mente di fornire un asset software, hai un piccolo team che gestisce il software che, a sua volta, guida la tua supply chain. Non hai un esercito di impiegati che si occupa di risolvere problemi tutto il giorno. Anche se avessi un esercito di impiegati, dovresti formarli, e quando accade qualcosa di completamente inaspettato, ti ritrovi con un esercito che non è stato addestrato per quella situazione specifica. Secondo la mia esperienza, più persone devi gestire, più tempo ci vuole per ottenere risultati.

Solo pochi giorni fa, una nave da carico ha perso oltre 1.800 container a causa di cattive condizioni meteorologiche. Queste cose semplicemente 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 operano in un mondo vasto, in cui per la maggior parte del tempo non hai alcun controllo sugli elementi. Ci sono così tante forze al di là del tuo controllo che devi essere in grado di far fronte ad eventi sorprendenti. Sai già che le sorprese accadranno, quindi devi essere preparato. Essere preparato non significa avere tutto mappato con cura; significa avere un sistema che ti permetta di 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 un’archiviazione dati versatile per rappresentare tutti i diversi tipi di fonti. Ci sono così tante cose che vogliamo rappresentare, quindi desideriamo qualcosa di molto versatile in questo senso, con molta struttura e varietà.

In secondo luogo, desideri una logica programmabile. Torno su questo concetto: se non hai una logica programmabile, come farai fronte a tutti questi problemi? Come farai a mettere insieme tutte queste cose? Non puoi acquistare un prodotto confezionato che abbia tutto pre-programmato per te; non funziona.

Successivamente, hai bisogno di interfacce utente versatili perché il modo in cui vuoi analizzare i tuoi problemi varierà enormemente da una situazione all’altra. I KPI saranno completamente diversi da un’azienda all’altra, quindi hai bisogno di un’interfaccia utente versatile in cui poter presentare i numeri nel modo che ritieni più opportuno; altrimenti, sarà una grande limitazione.

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

Infine, e forse in modo più controverso, desideri funzionalità programmabili accessibili a persone che non sono ingegneri del software formati. Questo è importante per diverse ragioni. Innanzitutto, non ci sono molti ingegneri del software formati sul mercato del lavoro, quindi è molto competitivo assumerli. In secondo luogo, ci vuole così tanto impegno e dedizione per diventare un ingegnere del software di talento che è difficile essere contemporaneamente un Supply Chain Scientist.

Non è molto comune trovare persone che abbiano competenze doppie in entrambi i campi. Lo stesso accadrebbe se cercassi qualcuno che sia sia programmatore che avvocato, o programmatore e medico. Sì, troverai alcune persone con queste competenze, ma è possibile farlo su larga scala o assumere costantemente altre persone simili ogni anno se sei una grande azienda? Dalla mia esperienza nel gestire Lokad per un decennio, semplicemente non funziona.

Desideri qualcosa di programmabile, ma non è necessario essere un ingegnere del software professionalmente formato per occuparsene. Ricorda, hai bisogno di una persona con competenza nella supply chain perché devi essere in grado di intervenire in poche ore per applicare le correzioni di programmazione al tuo sistema, senza aprire un ticket e passarle all’IT. Se devi farlo in quel modo, ci vorranno settimane per risolvere i problemi, non ore. Quindi, che tipo di software può davvero risolvere il problema?

Beh, Excel può farlo. Non è bello da vedere, e potrebbe non sembrare il culmine del software moderno, ma fa il suo lavoro. Risponde a tutti i requisiti.

Archiviazione dati versatile? Sì, in una certa misura, puoi inserire un sacco di dati di qualsiasi tipo in Excel. Logica programmabile? Assolutamente, Excel è completamente programmabile. Interfaccia utente versatile? Sì, puoi avere grafici a barre, grafici a linee e molti altri modi per presentare i dati. Per quanto riguarda le interfacce utente, è molto versatile. Potrebbe non essere il più rifinito, 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 marginalmente migliori, ma fondamentalmente puoi condividere i tuoi fogli di calcolo. Il problema della mancanza di funzionalità collaborative non è tanto che si tratti di un’app desktop, quanto la mentalità che sta alla base dei fogli di calcolo, che non è adatta a un lavoro collaborativo intenso. Di solito, se un collega ha creato un foglio molto complesso, è più semplice ricrearlo piuttosto che cercare di capire cosa abbia fatto. Quindi, il problema della mancanza di funzionalità collaborative è legato alla mentalità che accompagna i fogli di calcolo, che intrinsecamente ha forti limiti nella collaborazione.

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

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

Excel sta guidando il mondo della supply chain oggi, e credo che non sia un caso. Fondamentalmente, i fogli di calcolo affrontano molti dei problemi giusti. Molte altre opzioni vengono presentate come superiori, ma falliscono di default se non sai programmare. Se non sai programmare, vuol dire che quando affronti un problema importante o un’emergenza, sei fregato. Le persone ricorrono ai fogli di calcolo Excel in situazioni in cui manca un’interfaccia utente versatile o quando una soluzione non è accessibile ai non sviluppatori. Se solo un team IT può portare risultati, inizialmente le persone apriranno ticket e aspetteranno pazientemente, ma nel giro di tre mesi, probabilmente tutti torneranno a usare i fogli di calcolo Excel perché è più veloce. Excel non è l’obiettivo finale, ma qualunque cosa proporremo come sostituto superiore, dovrà soddisfare i requisiti essenziali.

Come possiamo migliorare qualcosa? In termini di storage dati versatili, Excel è buono 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 prestazioni sorgono rapidamente quando si opera su larga scala. La logica programmabile in Excel è possibile, ma è molto fragile e delicata. Se inavvertitamente 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, risultando in migliaia di copie della stessa logica, rendendo difficile identificare e correggere gli errori.

L’interfaccia utente non è ideale, poiché non è interamente basata sul web 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 collaborazioni sui risultati, come la modifica manuale delle previsioni e il coinvolgimento di più persone. Tuttavia, questo è l’approccio sbagliato. Le collaborazioni devono avvenire, ma devono verificarsi a livello logico, a livello della logica programmabile. Excel è molto accessibile per i non sviluppatori, ma quando si vuole fare qualcosa di leggermente più complicato, diventa una sfida. Nella gestione della supply chain, vogliamo affrontare tutti i futuri possibili, il che significa lavorare con previsioni probabilistiche, variabili casuali e gestire l’incertezza. Sebbene ciò sia possibile in Excel, è abbastanza complicato. Excel è semplice per compiti basilari, ma per situazioni più complesse bisogna diventare un mago di Excel.

La manutenibilità è importante, poiché vuoi costruire un bene il cui valore cresca 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 l’hype che circondano la data science. Tuttavia, per la gestione della supply chain, credo che Python sia inferiore a Excel.

Non fraintendermi; adoro Python e penso che sia un linguaggio brillante. Lo insegno persino 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 si vuole fare qualcosa di più complesso, serve un team di ingegneri del software, il che crea difficoltà nel trovare persone che siano sia esperte della supply chain che ingegneri del software.

Python ha funzionalità interessanti, ma il modo in cui vengono gestite le dipendenze è abbastanza complesso e la gestione dei pacchetti è scarsa. I pacchetti sono i mattoni che forniscono capacità extra, e quando dici che vuoi usare Python, non si tratta solo del linguaggio ma anche dell’intero ecosistema di pacchetti a cui sei interessato, come NumPy, Pandas, TensorFlow e SciPy – tutte dipendenze di terze parti o librerie software. La gestione dei pacchetti è stata carente per oltre un decennio, e sebbene stia migliorando, i progressi sono lenti. Ci sono molti aspetti del design del sistema che ne rendono difficile il potenziamento.

Anche le prestazioni sono scarse, principalmente per design. Le prestazioni computazionali si riferiscono alla qualità del lavoro svolto da Python nell’utilizzare la potenza di calcolo grezza disponibile dal tuo computer. Sorprendentemente, Microsoft Excel fa un lavoro molto migliore a questo proposito. Excel è altamente ottimizzato, sfruttando sistemi multi-CPU, multi-core ed eseguendo logica compilata nativamente. Microsoft ha investito molto per rendere Excel estremamente veloce.

Al contrario, Python ha problemi intrinseci che spesso portano a prestazioni 100 volte più lente di quanto la tua macchina possa teoricamente offrire. Sebbene possa sembrare accettabile per alcuni, data la potenza 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 affrontare la mancanza di prestazioni di Python aggiunge solo complessità. Puoi risolvere il problema delle prestazioni, ma stai creando un nuovo problema introducendo la complessità aggiuntiva di NumPy, di cui dovrai occuparti e mantenere nel tempo. Ciò innalza anche gli standard sul fronte dell’ingegneria del software.

Quando si tenta di implementare soluzioni Python per una vera gestione della supply chain, sorgono vari problemi, come eccezioni di riferimento nullo, esaurimento della memoria ed elevati tempi di calcolo. Potresti trovarti ad aspettare 20 minuti affinché un calcolo termini, incerto se finirà mai o se dovresti semplicemente terminare il processo e riavviare. Non lo so, quindi vuoi qualcosa in cui avere un’idea molto, molto chiara di quanto tempo ci vorrà per completare. A proposito, tornando a Excel, oggi 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 ci vorrà. Quindi, ancora una volta, vuoi – e questo fa parte di ciò che chiamo prontezza alla produzione – avere qualcosa che, dato che il software che produci probabilmente girerà in modalità non monitorata, durante la notte o durante il batch notturno, ad esempio, non richiede che un data scientist faccia da babysitter all’intero processo.

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

Quindi vogliamo avere qualcosa che possa essere migliorato. A proposito, la prima cosa che vogliamo migliorare è la difesa in profondità. I ransomware sono in aumento e, ogni volta che inserisci qualcosa di programmabile nella tua organizzazione, ti esponi al rischio di ransomware. Perché improvvisamente, quando hai un programma, questo sulla macchina può fare una miriade di cose, incluso prendere il controllo proprio della macchina su cui gira. So che esistono innumerevoli modi per mitigare i problemi; puoi utilizzare sandbox, limitare, avere diritti ristretti e ci sono tantissimi modi per ridurre i problemi. Tuttavia, ogni volta che usi qualcosa come un linguaggio di programmazione generico e di uso generale, la tua superficie d’attacco – termine tecnico – è assolutamente gigantesca.

In sostanza, ogni volta che incorpori codice di questo tipo, ti esponi enormemente a problemi di sicurezza. E ricorda, il modo in cui viene solitamente fatto in un’azienda di ingegneria del software è che il codice viene revisionato dai colleghi. Così, si revisiona il codice, si ha un processo di code review: qualcuno produce il codice e un collega lo esamina per assicurarsi che non vi siano cavolate al suo interno. Ma se torno al fatto che il software deve essere robusto, devi poter rispondere in poche ore. Da una prospettiva di ottimizzazione della supply chain, non sarai in grado di avere un processo di revisione del codice in atto. Non è semplicemente compatibile con i ritardi e le emergenze che affronterai.

Quindi, hai bisogno di qualcosa che ti garantisca una difesa in profondità per progettazione. Poi vuoi avere qualcosa con prestazioni trasparenti, dove sì, le operazioni possono richiedere tempo, ma devi essere in controllo. Devi sapere in anticipo quanto tempo ci vorrà. Se non ce l’hai, ti esponi a un’infinità di problemi davvero stupidi, per esempio se avevi una finestra di due ore per consegnare i risultati e poi arrivi in ritardo. E sai una cosa? I camion se ne sono già andati. È troppo tardi. Quindi hai bisogno di qualcosa in cui sia tutto sotto controllo.

E lo stesso vale per gli aggiornamenti trasparenti. Questa è la bellezza di Excel. Non devi preoccuparti della manutenzione di Excel. Microsoft ha siglato un patto di sangue decenni fa, 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. E la cosa più incredibile è che, se si guarda Excel oggi, esso supporta molti formati Excel concorrenti di aziende che ormai non esistono più. Puoi ancora leggere fogli di calcolo prodotti con Lotus Notes e 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. Questo non è ciò che si osserva nella transizione da Python 2 a Python 3; è stato un incubo e ci è voluto un decennio. Quindi, Python è ottimo per molte cose, ma immagina che quegli aggiornamenti possano verificarsi nei momenti peggiori, durante la peggior pandemia, la tariffa più alta, l’emergenza più grave, e hai bisogno che tutto sia operativo e pronto. Non puoi permetterti un downtime di sei mesi solo perché devi occuparti di un aggiornamento. Non è qualcosa di compatibile con l’ottimizzazione della supply chain.

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

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

Ma l’idea è che la supply chain debba essere titolare delle decisioni della supply chain. Deve possedere tutto l’apparato che genera tali decisioni, ed è questa la sua proprietà fondamentale. Nella lezione precedente ho definito il Supply Chain Scientist: il Supply Chain Scientist è colui che detiene 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 Scientist, e questi ultimi le possiedono collettivamente. Si assumono la responsabilità e il compito della supply chain è assicurarsi che tutte le decisioni in azienda siano coerenti. Se è in corso una promozione o una grande spinta di marketing, le cose devono essere prodotte in tempo affinché siano pronte per essere servite. Non vuoi trovarti in una situazione catastrofica in cui stai spingendo qualcosa mentre sei già in una situazione di quasi esaurimento scorte, dove spendi denaro per una campagna di marketing per qualcosa che non riesci neanche a vendere perché non hai lo stock o la capacità di produrlo o di fornire il servizio in tempo, ecc.

Quindi, abbiamo due divisioni con focus molto diversi. Nella mia visione ideale di ciò che dovrebbe essere il reparto IT, l’IT non è una divisione in cui si risolvono ticket. Non è così che funziona. Il reparto IT è responsabile dell’infrastruttura centrale. È quel tipo di cosa che funziona senza intoppi tutto il tempo. Non ci fai nemmeno caso, proprio come il Wi-Fi che funziona: non te ne accorgi se funziona, ma te ne accorgi quando non funziona. Un buon reparto IT fornisce tutta l’infrastruttura in modo che tu non debba nemmeno preoccupartene. Non ti rendi nemmeno conto che esistono, perché funziona tutto, proprio come le tue email che operano senza intoppi, ecc. Questo è ciò che significa avere un buon core IT. E poi, l’IT è il tipo di reparto che viene da te per aiutarti a stabilire tutte quelle pratiche che ti danno una mano. La logica programmabile è un po’ complessa, quindi a volte, dove troverai il coaching per migliorare un po’ in termini di programmazione? Beh, la risposta è: dovrebbe essere l’IT. Non dovrebbero venire a dire “Lo coderemo per te”, ma piuttosto “Ti guideremo affinché tu possa effettivamente implementarlo da solo. Ti aiuteremo con alcuni concetti, magari con alcune cose un po’ più tecniche di quanto dovrebbero”. A volte si verifica una complessità accidentale, e l’IT è lì per supportarti. Ma fondamentalmente, non sono lì per fare il lavoro al tuo posto. Dovrebbero essere mentori e coach, assicurandosi che nessuno commetta un errore fatale che possa esporre l’intera azienda a rischi come il ransomware o altri rischi sistemici, dal punto di vista IT.

Come banco di prova, se l’interazione tra IT e supply chain avviene tramite documenti che elencano specifiche o requisiti, questo non è il modo corretto per instaurare un buon rapporto tra le due divisioni. Quando dico “buon rapporto”, intendo qualcosa che aggiunga effettivamente valore all’azienda.

In conclusione, abbiamo due sfide dal lato della gestione tradizionale della supply chain, che forse ha fatto programmazione, ma solo ai margini, con i fogli Excel, senza nemmeno rendersi conto inizialmente che era già una forma di programmazione. Devi superare le tue paure. Devi pensare che il mondo di domani, la tua divisione, sarà responsabile della consegna di un prodotto che funziona come un prodotto software, e questo rappresenta un enorme cambiamento. Sì, ma è qualcosa con cui puoi fare i conti. Perché? Perché se hai gli strumenti giusti, sì, è coinvolta la programmazione, ma non è fondamentalmente, radicalmente più difficile di Excel. Ancora una volta, la sfida non sta nella tecnicità dello strumento; sta letteralmente nella complessità della supply chain stessa. Il problema è difficile non perché il tuo strumento sia complicato da gestire, ma perché hai una supply chain complicata in primo luogo.

Per quella parte del pubblico che è forse più orientata verso il data scientist o l’IT, ciò che devi superare è l’eccesso di fiducia. Ho visto, ancora e ancora, data scientists, e mi includo in questa categoria, che erano troppo sicuri della loro capacità di portare un prototipo in produzione. Questo è difficile, e supply chains hanno il 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 il loro replenishment delle parti con la nostra tecnologia di previsione, facendo suggerimenti per il rifornimento delle parti, servendo ricambi auto. La settimana successiva, abbiamo visto che tutte le nostre previsioni erano sbagliate di un fattore due. La domanda si era raddoppiata. Ciò che era successo era che il loro principale concorrente aveva deciso di espandersi in più paesi contemporaneamente, letteralmente al momento in cui stavamo iniziando la nostra previsione, uno dei concorrenti aveva deciso di andare in onda su tutte le TV nazionali e di 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 termini di SEO. Le persone vedevano l’annuncio televisivo del concorrente, ma non ricordavano naturalmente il nome del concorrente. Così, andavano su Google e digitavano “car parts” finché non finivano sul sito web del mio cliente. Per dimostrare quanto fossimo grandiosi da Lokad, la prima settimana in cui avevamo iniziato eravamo sbagliati di un fattore due, e pensavamo: “Che diavolo sta succedendo?” Abbiamo dovuto rivedere tutto perché, quando vedi che la domanda raddoppia, non è che tutto raddoppia; alcune cose fanno 10 volte tanto, e molte cose restano invariate.

Quindi, è questo il tipo di situazione, e devi essere in grado di reagire rapidamente. Si tratta proprio di paura e di eccessiva fiducia in se stessi. 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 sia necessario avere di più per domani? Ad esempio, vaschette da 200 grammi di fragole negli uffici in Australia possono 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, compreso l’EDI, dove puoi inviare un ordine elettronico a un fornitore senza alcun intervento umano. Così hai un ponte elettronico end-to-end. Ma questo significa che devi avere, dal lato dell’ottimizzazione, un software che funzioni ininterrottamente per tutto il giorno e che, a un certo punto, possa notificare il management dicendo “Si prega di eseguire questo ordine.” E poi, dal lato management, gestito dall’IT, ci si assicura semplicemente che questo ordine venga eseguito per intero. È solo una questione di pura transazionalità; non c’è più intelligenza. Hai ricevuto un ordine che dice “questa quantità”, ed è il lato dell’ottimizzazione che è responsabile di assicurarsi che, quando generi una certa quantità, tu rispetti tutti i vincoli, come l’elenco esatto dei fornitori che sono addirittura idonei a servire questi prodotti, se hanno ancora scorte e come fare la scelta giusta tra tutti i fornitori concorrenti, ecc.

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

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

Domanda: Ho visto che molte aziende non hanno in primo luogo un ERP o un WMS, e che il management 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 qualsiasi tipo di software per la supply chain management. Anche se torniamo indietro di 60 anni, quando non esisteva il 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 i primi studi sulle supply chains, come la Wilson Formula, nota anche come formula EOQ, ha un secolo di età. Precede chiaramente il 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, devi avere dei sistemi IT adeguati, ma è una mentalità completamente diversa. La supply chain management riguarda il fare molto bene compiti banali, come l’inserimento dei dati, potenzialmente con supporto per codici a barre e altre cose. Si tratta di compiti veramente ordinari, semplicemente rappresentare i dati. Il problema è che le persone vogliono qualcosa che faccia sia la supply chain management che la supply chain optimization, e di conseguenza finisci con un prodotto troppo complicato, solitamente pieno di bug, e che include funzionalità indesiderate 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, è questione di settimane. Se ne hai già uno, può essere questione di mesi se riesci a disaccoppiare questa cosa dalle tue decisioni.

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

La prima cosa è che devi renderti conto, in primo luogo, che ci sono due problemi e che lo stesso software non potrà mai affrontare entrambe le angolazioni. Penso che questa sia la grande illusione, e i fornitori di software sono stati incredibilmente fuorvianti in quest’area. Se guardi ai maggiori 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 nel campo della supply chain management, che è molto meno affascinante perché non c’è intelligenza artificiale o vera intelligenza. Nel mondo del software è noto 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 eliminare 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 basta. Quindi, se torno alla tua domanda sul management, il problema è che se sei un manager, leggi la brochure del fornitore di ERP, e questi ti dicono che questo prodotto ottimizzerà la tua supply chain. La risposta è: no, assolutamente no. Quello che farà sarà migliorare la produttività e garantire una contabilità accurata della tua supply chain. Questo è già molto, poiché può ridurre drasticamente furti, perdite, merci smarrite e migliorare la produttività con i codici a barre in un magazzino. C’è molto valore aggiunto in questi prodotti. Non sto sminuendo il valore che un ERP o un WMS possono apportare; è enorme, ma non si tratta di supply chain optimization. Un WMS, per esempio, è per sua natura qualcosa che si occupa del magazzino; non si interessa dell’intera supply chain che include clienti e fornitori. È progettato per concentrarsi su luoghi specifici, non sull’intera supply chain.

Domanda: Come puoi passare senza problemi 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 ed ingegnerizzato esclusivamente per la predictive optimization delle supply chains. Nella prossima lezione, dimostrerò Envision affinché le persone possano comprendere meglio di cosa sto parlando, con esempi di codice reale.

Storicamente, abbiamo usato Python ed Envision insieme perché, quando abbiamo iniziato, Envision aveva capacità molto limitate, quindi mancavano molte funzionalità, e in molte situazioni ricorrevamo a Python per default. Nel corso degli anni, abbiamo gradualmente ampliato le capacità di Envision, eliminando progressivamente la necessità di componenti Python. Non si tratta solo di componenti Python; è anche una serie di strumenti che devono 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 già conosci Python, puoi imparare Envision in una settimana. Essa differisce in modi sottili e profondi, ma dal punto di vista sintattico ci sono molti aspetti uguali. Python ha molti meriti, come la semplicità e la purezza del design. Anche se dico che Python non soddisfa tutte le esigenze e crea gravi problemi 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. Di nuovo, stiamo parlando specificamente di come gestire le supply chains in produzione, il che rappresenta un problema molto specifico.

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

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

Quando pensi a quegli ERP legacy, nutro molto rispetto per loro, soprattutto per quei prodotti AS/400 con terminale a riga di comando su vecchi mainframe IBM. Dal punto di vista del management, solitamente fanno un lavoro molto discreto. Quello che i clienti cercano realmente potrebbe essere un’interfaccia web anziché una riga di comando, ma questo renderà i loro team sul campo più produttivi? Io dubito. Le righe di comando con terminali testuali possono essere incredibilmente reattive e produttive, senza distrazioni.

Quindi, è piuttosto difficile perché dobbiamo sciogliere tutta la confusione promossa 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 sto tenendo queste lezioni, perché ci vogliono ore per arrivare al nocciolo della questione e spiegare perché dobbiamo vedere il problema come lo vedo io.

Domanda: Qual è la tua raccomandazione per una piattaforma in grado di affrontare la complessità di pianificare più prodotti con distribuzione probabilistica della domanda?

Beh, ovviamente Lokad. Ma tieni presente che, essendo il CEO di Lokad e il principale proprietario dell’azienda, 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 a riguardo.

A proposito, Lokad è stato letteralmente ingegnerizzato per gestire la distribuzione probabilistica della domanda, e non riguarda solo questo aspetto. Affronta anche la distribuzione stocastica del lead time, la distribuzione stocastica dei resi e altro ancora. Dobbiamo considerare tutti i futuri possibili con le relative probabilità, prendendo in considerazione ogni tipo di incertezza. La domanda è una delle più importanti, di solito la più importante, ma non è l’unica.

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

Riferimenti

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