Consegna orientata al prodotto per la 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 Comprare un prodotto SCO già pronto
21:58 SCM vs SCO
25:58 Intermezzo
28:21 SCO non è il solito prodotto software
33:26 Ingredienti software per SCO
42:49 Tuttavia, i fogli di calcolo non sono il fine
46:51 Nemmeno Python è il fine
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 consegnare o migliorare un’applicazione software che automatizza una serie di decisioni di routine (ad esempio, riapprovvigionamenti di inventario, aggiornamenti dei prezzi). L’applicazione è considerata un prodotto da progettare. La teoria della supply chain è lì per aiutarci a consegnare un’applicazione che orienta l’azienda verso le prestazioni della supply chain, pur essendo compatibile con tutti i vincoli che la produzione comporta.

Trascrizione completa

Ciao a tutti, grazie mille per unirvi 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 un prodotto, intendo un prodotto software. Per coloro che hanno avuto il privilegio di indagare su ciò che si nasconde dietro le quinte di un moderno software aziendale, potrebbe essere un’esperienza piuttosto interessante.

Per coloro che sono familiari con l’opera di H.P. Lovecraft, ci sono alcune similitudini inquietanti. 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, 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 giochi moderni, soprattutto giochi di ruolo, in cui, oltre ai tradizionali punti salute, i personaggi hanno punti sanità mentale. Se fai certe cose che danneggiano la tua sanità mentale, perdi punti sanità mentale. La sfida con il software aziendale è riuscire a crearlo preservando la tua sanità mentale, che è uno dei requisiti per aggiungere valore all’azienda. Quindi, procediamo.

Perché un prodotto, e in particolare, un prodotto software? Diamo un’occhiata ravvicinata a come le catene di approvvigionamento operano tradizionalmente. Tradizionalmente, c’erano molte persone sul campo che spostavano le cose, spostavano pacchi, guidavano veicoli e facevano tutto il lavoro manuale. C’erano anche molte persone coinvolte nella produzione, così come nei negozi. Ciò che è successo gradualmente negli ultimi decenni è che il numero di persone con lavori manuali è diminuito costantemente. Oggi, per quanto riguarda la produzione, le cose sono ampiamente automatizzate. Ci sono ancora alcune industrie, come il settore tessile, in cui è difficile automatizzare tutto, ed è per questo che queste industrie si sono spostate dove la manodopera è più economica. La realtà è che i requisiti di manodopera grezza sono stati notevolmente ridotti.

Ti ritrovi in una situazione piuttosto strana in cui, se guardi avanti con veicoli autonomi imminenti, molte aziende avranno più lavoratori impiegati nell’elaborazione di fogli di calcolo Excel spreadsheets per gestire la catena di approvvigionamento rispetto alle persone con mani blu sul campo per svolgere le operazioni di lavoro manuale. Questo è ciò a cui mi riferisco quando parlo di lavoro di ufficio.

Un altro aspetto peculiare è che le catene di approvvigionamento sono state digitalizzate per molte aziende da almeno due decenni. Non è che stiamo introducendo il software nelle catene di approvvigionamento; le catene di approvvigionamento sono già gestite e operate tramite software. Ma quando guardiamo al ruolo degli esseri umani in questi sistemi software, gli esseri umani vengono letteralmente utilizzati come co-processori umani nel sistema di catena di approvvigionamento medio. Ci sono tipi specifici di operazioni che l’unità centrale di elaborazione regolare, il processore nella macchina, non può fare, e quindi l’intero compito viene delegato a un essere umano. In combinazione con ricette numeriche semplicistiche, come l’analisi ABC, l’inventario min-max e ricette simili, gli esseri umani finiscono per passare le loro giornate a spegnere incendi. Si occupano sempre di eccezioni e condizioni che non si adattano al framework standard.

Dal punto di vista dei costi, tutto ciò è una spesa operativa (OpEx). Devi 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 spegnere incendi per far fronte alle inadeguatezze delle decisioni automatiche generate in modo ingenuo dal sistema.

La mia proposta per voi oggi è che vogliamo passare da OpEx a spesa di capitale (CapEx). Questo è il punto centrale di questa consegna orientata al prodotto. Vogliamo costruire un asset, e perché? Perché è capitalista. Se guardi alle prime 100 aziende più redditizie al mondo al giorno d’oggi, la metà di esse, in termini di profitto, sono aziende software. Rappresentano l’essenza delle aziende ultra-capitalistiche, dove hai un investimento iniziale e poi ti ritrovi con un dispositivo o un manufatto che genera valore aggiunto con un investimento marginale minimo.

Tornando all’argomento della mia precedente lezione, abbiamo bisogno di robotizzazione per riprendere il controllo della gestione. Automazione e esseri umani dovrebbero lavorare insieme; gli esseri umani non dovrebbero essere lì per affrontare le inadeguatezze delle politiche di inventario stupide come min-max. Invece, dovrebbero essere lì per aggiungere valore, migliorare le ricette numeriche e agire come strategi. C’era un vecchio motto di IBM che diceva: “Le macchine dovrebbero lavorare; le persone dovrebbero pensare.” Questo è il tipo di pensiero che sta dietro a 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 piuttosto semplice: prende decisioni. Non decisioni arbitrarie e aperte, ma decisioni banali e di routine come cosa produrre, quante unità acquistare da un fornitore e quante unità spostare da una posizione all’altra. A prima vista, potrebbe sembrare che ci siano molte decisioni coinvolte nella gestione della supply chain. Tuttavia, quando si analizzano le attività, anche le supply chain più complesse richiedono solo alcune dozzine di tipi di decisioni da prendere ogni singolo giorno. Questo non è schiacciante ed è abbastanza ragionevole in termini del numero di funzionalità. Interessantemente, queste decisioni sono in gran parte esclusive, quindi ci sono limiti a ciò che può essere fatto utilizzando un approccio divide-et-impera. Una volta deciso di acquistare 100 unità da un fornitore, non puoi avere un altro sottosistema che decide di acquistare invece 200 unità. Ad un certo punto, devi decidere quante unità acquistare e spostare da una posizione all’altra. Queste decisioni sono discrete, limitate in ambito e in gran parte esclusive. Quello che vogliamo è un pezzo di software che generi decisioni di ordine in modo completamente automatizzato ogni singolo giorno.

Una cosa che credo sia spesso poco compresa del software è la nozione di diseconomie di scala. Mentre le economie di scala sono familiari alla maggior parte delle persone, il contrario è vero nel software, dove aggiungere un quarto di funzionalità può raddoppiare il costo. Questo concetto spiega perché le piccole startup possono competere con le grandi aziende, perché si concentrano su una frazione più piccola 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 di 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 fornitore di software dovrà fornire per servire il mercato.

Quindi, consideriamo l’acquisto di un prodotto di ottimizzazione della supply chain già pronto. In queste diapositive, fornisco una panoramica solo di una piccola frazione di tutte le cose che dobbiamo affrontare. Ho esperienza diretta di questo, perché quando ho fondato Lokad nel 2008, ho iniziato con un piccolo prodotto software orientato più alla previsione che all’ottimizzazione della supply chain. Mentre lavoravo con i clienti, mi sono reso conto che c’erano così tante funzionalità e capacità che non avevo e, man mano che passavo ad altri clienti, ho scoperto ancora più capacità mancanti. Sembrava essere un processo infinito di scoperta di nuovi requisiti.

Diamo un’occhiata solo alle funzionalità principali. Innanzitutto, abbiamo aziende che sono B2C o B2B, che mostrano modelli completamente diversi nella gestione della supply chain. Ad esempio, le aziende B2B hanno tipicamente meno clienti, ma questi clienti ordinano quantità molto più grandi. Ciò crea diversi tipi di rischi, come il rischio 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.

Consideriamo i vari tipi di siti che devono essere coperti, come negozi, magazzini e impianti di produzione. Ogni tipo di sito presenta le proprie sfide. Ad esempio, i negozi sono soggetti a inesattezze dell’inventario, anche con la tecnologia RFID, semplicemente perché i clienti possono spostare i prodotti. I magazzini e i siti di produzione, come le fattorie o le operazioni minerarie, presentano i propri problemi specifici e incertezze nella resa della produzione.

Le reti di supply chain possono avere diversi livelli, o echeloni, che vanno dai sistemi a singolo echelon ai sistemi multi-echelon. La complessità della gestione della supply chain aumenta significativamente all’aumentare del numero di echeloni. La topologia della rete è un altro aspetto importante da considerare. Una topologia ad albero è il classico percorso di supply chain in avanti, in cui alcuni 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.

Quindi, fondamentalmente, non è solo un albero in termini di grafi, può riconnettersi, anche se è ancora solo in avanti. Ma la stessa cosa può accadere con un grafo aciclico diretto (DAG) quando si hanno più fornitori. È possibile avere anche cicli nel grafo della supply chain che si verificano quando sono coinvolti riparazioni. Ad esempio, nell’industria mineraria o nell’industria aeronautica, ci sono tonnellate di cicli di riparazione con attrezzature riparabili.

Ora, l’inventario stesso non ha una sola natura; varia molto. Non si può dire semplicemente: “Oh, ho questa idea che ho SKU e basta.” No, non proprio, perché prima di tutto hai le materie prime che vengono letteralmente misurate in quantità come grammi, chilogrammi o volume. Poi hai le unità che sono le belle, pulite unità, che sono prevalentemente diffuse. Ma poi puoi anche avere molto inventario che si verifica molto frequentemente, ad esempio, nel settore farmaceutico o nel settore alimentare, dove il lotto viene fornito con specifiche date di scadenza. Puoi persino avere inventario completamente serializzato, in cui ogni singola unità ha il proprio numero di serie. In termini di ottimizzazione della supply chain, questo cambia completamente il gioco, quindi è un problema completamente diverso quando si guarda ognuna di queste cose.

Poi, ovviamente, ci sono tutti i problemi dei marketplace. Da Lokad, abbiamo clienti in letteralmente ogni possibile situazione. Abbiamo clienti che vendono su un marketplace di terze parti, possono avere il proprio marketplace o possono averne entrambi. Può essere qualcosa di secondario in modo che possano usarlo per liquidare le cose che non hanno venduto. Ci sono molte situazioni.

Ora, solo per esempio, pensa per un attimo a cosa sia un ordine. Hai l’ordine immediato, dove fondamentalmente compri qualcosa direttamente dal banco, ed è tuo. Ma poi puoi anche avere un ordine che dice: “Lo sto comprando, ma non voglio che questa cosa venga consegnata immediatamente; voglio che venga consegnata 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 roba in una data specifica, non vuoi fare previsioni, quindi è una cosa completamente diversa.

E poi hai un ordine configurato, ed è, ad esempio, quando compri un computer online e puoi scegliere quanto memoria, quanto hard disk, che tipo di sistema operativo, che lingua verrà impostata per il tuo computer e quale sarà la tua tastiera, tra le altre cose. Quindi, puoi avere un configuratore massivo, e questo cambia nuovamente il panorama. Questo accade anche per cose come biciclette o automobili e cambia completamente il panorama quando hai questo tipo di cose perché ti offre opzioni e modi di guardare il problema dell’ottimizzazione della supply chain che sono completamente diversi.

Anche per i prezzi, puoi avere il prezzo per unità che è fisso, super semplice e super lineare, ma non è l’unica cosa. Puoi avere sconti sul prezzo, ad esempio, se acquisti dieci unità, allora ottieni uno sconto. O puoi avere programmi di fedeltà in cui alcuni clienti con una carta fedeltà possono ottenere uno sconto, ma solo su determinati tipi di prodotti o solo a seconda di determinate condizioni. E poi puoi anche avere, nel B2B, cose molto frequenti che vengono negoziate, quindi è letteralmente una transazione in cui verranno vendute molte cose, ma hai un prezzo di catalogo regolare. Tuttavia, un fornitore può dare uno sconto a un cliente perché sono importanti, ed è così che si fa. In poche parole, ho appena parlato per pochi minuti adesso, e ho appena coperto il nucleo. Non ho nemmeno iniziato a toccare le cose indispensabili. Quindi, fermati un attimo e cerca di pensare a come sarà un prodotto software aziendale pronto all’uso che dovrebbe fornire l’ottimizzazione della supply chain. Il numero di funzionalità da coprire è letteralmente folle, e quando cerchi di pensare a come mettere insieme tutte queste cose in un monolite, perdi letteralmente la testa. Siamo tornati a questa idea che non è che l’universo non possa essere conosciuto, è solo che se sei esposto alla nuda verità dell’universo, perdi la tua sanità mentale.

Quindi, abbiamo un grosso problema, e qui dobbiamo differenziare la gestione della supply chain dall’ottimizzazione della supply chain. Questa è una distinzione che ho già introdotto in una delle mie lezioni precedenti. C’è una grande confusione tra il lato della gestione e il lato dell’ottimizzazione. La gestione riguarda la contabilità, il supporto ai flussi di lavoro e principalmente i processi di inserimento dati. Se vuoi rappresentare tutte le cose che ho appena descritto, è molto terreno da coprire, ma è fattibile. Un “obeso” ERP può farlo. Sì, finirai con 10.000 tabelle, sarà piuttosto brutto, ma è possibile. Ma non fraintenderti, l’ERP (che dovrebbe chiamarsi ERM, Enterprise Resource Management) non farà molto. Si limiterà semplicemente a tenere traccia di quelle cose. Quindi avrai tonnellate di entità - MOQs, check; sconti sul prezzo, check; negozi, check; magazzini, check - ma non hai bisogno di avere alcun grado di intelligenza. Si tratta solo di controparti digitali banali per riflettere i dati, rendendo possibile l’inserimento dei dati nel sistema, e basta.

È possibile perché, qui, possiamo imbrogliare un po’ su 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 tue funzionalità completamente separate. Finché le funzionalità non interagiscono tra loro, va bene; non sei soggetto a questa maledizione delle diseconomie di scala. Dal punto di vista dell’inserimento dati, non c’è problema. Non hai bisogno di avere l’interfaccia utente che ti consente di gestire i MOQs collegati a ciò che ti consente di aggiungere un negozio extra alla rete. Queste due cose possono essere completamente separate.

Tuttavia, per quanto riguarda l’ottimizzazione della supply chain, lo stesso non è vero. Se hai MOQs, avranno profonde implicazioni su quanto spesso stai ordinando, su quanto spesso consegnerai le cose dal tuo magazzino ai tuoi negozi. Ci sono molte conseguenze di vasta portata. Non puoi separare le cose perché, in definitiva, la tua supply chain è solo un sistema in cui tutto ha un’influenza su tutto. Quindi, dal punto di vista dell’ottimizzazione della supply chain, hai letteralmente il problema che tutte quelle cose devono essere collegate se vuoi ottenere l’ottimizzazione, ed è lì che le cose si sfaldano.

Sul lato della gestione, 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 presso Lokad, che non è iniziata come un’azienda di previsione della supply chain specializzata nell’ottimizzazione predittiva della supply chain, ma piuttosto come previsione come servizio. Se torni al blog di Lokad nel 2008, inizialmente ho iniziato con la previsione delle serie temporali, che era gravemente fuorviante. Tuttavia, è così che ho iniziato. Anche per la previsione delle serie temporali, che è un piccolo sottoinsieme dell’intero problema, è ingestibile. Questa è la mia conclusione dopo aver lavorato 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 stesso non sia stato addestrato come ingegnere del software e non sia familiare con il modo in cui le grandi e affermate aziende di software producono software, è probabile che tu ne sappia molto poco. Si scopre che è un mondo molto specifico con molti aspetti profondamente controintuitivi. Le aziende tradizionali, specialmente quelle con una mentalità di ingegneria meccanica classica o di marketing, faticano enormemente a capire come funziona il software in generale.

Affronteremo questi aspetti in maggior dettaglio nelle future lezioni, ma c’è un libro che mi piace molto, prodotto da Joel Spolsky, un ex dipendente di Microsoft che ha lavorato nei primi team di Microsoft Excel. È anche il co-fondatore 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 ti dà in modo umoristico un’idea di come sia gestire 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 teniamo presente che l’ottimizzazione della supply chain non è un prodotto software medio. Di solito, quando si tratta di un prodotto software medio, voglio dire, sì, ci sono alcuni comportamenti avversari, a seconda del tipo di prodotto software. Se stai affrontando un social network, puoi avere molte persone che pubblicano contenuti odiosi, che è un gioco completamente diverso. Tuttavia, quando si tratta di software aziendale classico, come Microsoft Word o Excel, è un prodotto in cui si desidera avere il giusto design, ma non c’è alcuna emergenza. Nel caso dei prodotti software tradizionali, va bene passare anni a perfezionare il design e il prodotto. È un investimento a lungo termine e devi guardare decenni avanti. Non c’è motivo di affrettare nulla in termini di sviluppo. Tuttavia, l’ottimizzazione della supply chain non funziona così. Non hai scelta, poiché le cose accadono tutto il tempo e il terreno è molto accidentato.

Puoi avere 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 massimo le capacità che hai ancora a disposizione. Potresti affrontare la messa a terra della flotta a causa di incidenti tragici, mosse politiche come tariffe che interrompono la tua strategia o disastri naturali come tsunami o incendi e ondate di calore, come quelli in California o in Australia. Questi eventi accadono e quando accadono, devi essere in grado di reagire letteralmente in poche ore.

Hai il tuo prodotto software, ma devi apportare modifiche e vuoi apportare modifiche programmatiche. Ricorda, se hai la mentalità di consegnare un asset software, hai un piccolo team che guida il software che, a sua volta, guida la tua supply chain. Non hai un esercito di impiegati che fanno interventi d’emergenza tutto il giorno. Anche se hai un esercito di impiegati, devi addestrarli e quando accade qualcosa di completamente inaspettato, ti ritrovi con un esercito che non è stato addestrato per quella situazione specifica. Nella mia esperienza, più persone devi gestire, più tempo ci vuole per ottenere qualcosa.

Solo pochi giorni fa, una nave da carico ha perso oltre 1.800 container a causa delle cattive condizioni meteorologiche. Queste cose accadono semplicemente e non puoi sperare di eliminarle. La supply chain non è come la produzione, dove puoi avere un sito di produzione con tutto sotto stretto controllo. Per definizione, le supply chain avvengono in un mondo vasto, dove nella maggior parte dei casi non hai controllo sugli elementi. Ci sono così tante forze al di fuori del tuo controllo che devi essere in grado di affrontare eventi sorprendenti. Sai già che ci saranno sorprese, quindi devi essere preparato. Essere preparati non significa avere tutto attentamente pianificato; 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 cosa abbiamo bisogno in termini di ingredienti software per l’ottimizzazione della supply chain? Prima di tutto, abbiamo bisogno di un sistema di archiviazione dati versatile per rappresentare tutti i diversi tipi di fonti di dati. Ci sono così tante cose che vogliamo rappresentare, quindi vogliamo qualcosa di molto versatile in questo senso, con molta struttura e varietà.

In secondo luogo, desideri una logica programmabile. Torno a questa idea: se non hai una logica programmabile, come affronti tutti questi problemi? Come unisci tutte queste cose insieme? Non puoi comprare un prodotto già pronto che abbia tutto pre-programmato per te; non funziona così.

Successivamente, hai bisogno di interfacce utente versatili perché il modo in cui desideri visualizzare 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 puoi presentare i numeri nel modo che preferisci; altrimenti, sarà una grande limitazione.

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

Infine, e forse in modo più controverso, desideri capacità programmabili accessibili a persone che non sono ingegneri software formati. Questo è importante per diverse ragioni. In primo luogo, non ci sono molti ingegneri software formati nel mercato del lavoro, quindi è molto competitivo assumerli. In secondo luogo, richiede così tanto impegno e dedizione diventare un talentuoso ingegnere software che è difficile essere contemporaneamente uno specialista della supply chain.

Non è molto comune trovare persone che abbiano competenze duali in entrambi i campi. Lo stesso vale se stai cercando qualcuno che sia sia programmatore che avvocato, o programmatore e medico. Sì, troverai alcune persone con queste competenze, ma puoi farlo su larga scala o assumere in modo affidabile più persone ogni anno se sei un’azienda di grandi dimensioni? Dalla mia esperienza di gestione di Lokad per un decennio, semplicemente non funziona.

Vuoi qualcosa di programmabile, ma non è necessario essere un ingegnere software professionista per gestire la programmazione. Ricorda, devi avere qualcuno con competenze nella supply chain perché devi essere in grado di far fronte in poche ore per applicare le correzioni di programmazione al tuo sistema senza aprire un ticket e passarlo all’IT. Se devi farlo in quel modo, allora ci vogliono settimane per affrontare i problemi, non ore. Quindi, che tipo di software può effettivamente risolvere il problema?

Beh, Excel può farlo. Non è bello e potrebbe non sembrare l’apice del software moderno, ma fa il trucco. Soddisfa tutti i requisiti.

Archiviazione dati versatile? Sì, fino a un certo punto, puoi inserire molti 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 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.

In termini di capacità collaborative, è un po’ rudimentale. Ci sono alcune versioni di Excel online, che sono leggermente migliori, ma fondamentalmente puoi condividere i tuoi fogli di calcolo. Il problema con la mancanza di funzionalità collaborative non è che si tratta di un’app desktop. Il problema è la mentalità che sta dietro ai fogli di calcolo, che non è adatta per un lavoro collaborativo intenso. Di solito, se hai un collega che ha creato un foglio molto complesso, è più facile ricreare il foglio piuttosto che cercare di capire cosa ha fatto. Quindi, il problema con la mancanza di funzionalità collaborative è la mentalità che accompagna i fogli di calcolo, che intrinsecamente ha forti limiti per la collaborazione.

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

Nella mia esperienza, la maggior parte delle supply chain del mondo, dalle più piccole alle più grandi e da quelle che non hanno mai investito un centesimo in software aziendali a quelle che hanno investito milioni di dollari in software aziendali complicati per l’ottimizzazione della supply chain, sono guidate da Excel. Ci sono pochissime eccezioni. A volte, le persone utilizzano Excel per modificare le impostazioni min-max in altri software, ma la manutenzione di queste impostazioni è delegata a coloro che lavorano con Excel.

Excel sta guidando il mondo della supply chain oggi, e credo che non sia un caso. Nel suo nucleo, 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 problema o a un’emergenza importante, sei fuori gioco. Le persone torneranno ai fogli di calcolo di 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ò ottenere risultati, le persone potrebbero inizialmente aprire ticket e aspettare pazientemente, ma entro tre mesi, molto probabilmente tutti torneranno a utilizzare i fogli di calcolo di Excel perché è più veloce. Excel non è il punto finale, ma qualsiasi cosa portiamo come un sostituto superiore dovrà soddisfare i requisiti giusti.

Come possiamo migliorare qualcosa? In termini di archiviazione dati versatile, Excel è buono ma non molto scalabile. Elaborare 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 fragile. Se introduci involontariamente un errore o un bug nel tuo foglio di calcolo, risolverlo e individuare la fonte del problema diventa 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 è completamente basata sul web e i dati sono sempre intrecciati con l’interfaccia. Le capacità collaborative esistono, ma sono disordinate. La collaborazione dovrebbe avvenire a livello di logica programmabile. Molti fornitori di ottimizzazione della supply chain offrono collaborazione sugli output, come la modifica manuale delle previsioni e la partecipazione di più persone. Tuttavia, questo è il modo sbagliato. Le collaborazioni devono avvenire, ma devono avvenire a livello logico, a livello di logica programmabile. Excel è molto accessibile per i non sviluppatori, ma quando si desidera fare qualcosa di leggermente più complicato, diventa difficile. Nella gestione della supply chain, vogliamo affrontare tutti i futuri possibili, il che significa lavorare con previsioni probabilistiche, variabili casuali e affrontare l’incertezza. Anche se questo è possibile in Excel, è piuttosto complicato. Excel è facile per compiti semplici, ma per situazioni più complesse, devi diventare un mago di Excel.

La manutenibilità è importante, poiché si desidera creare un asset con un valore crescente nel tempo. Con i fogli di calcolo, è difficile raggiungere questo obiettivo ed è difficile creare qualcosa di veramente accurato, almeno nel senso di un prodotto software.

Le parole di moda 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, ritengo che Python sia inferiore a Excel.

Non fraintendetemi; amo 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. Prima di tutto, richiede ingegneri del software. Sebbene Python sia uno dei linguaggi di programmazione più accessibili, quando si desidera fare qualcosa di più complesso, è necessaria una squadra di ingegneri del software, il che crea sfide quando si hanno bisogno di persone che siano sia esperti di supply chain che ingegneri del software.

Python ha belle caratteristiche, ma il modo in cui vengono gestite le dipendenze è piuttosto complesso e la gestione dei pacchetti è scadente. I pacchetti sono blocchi di costruzione che forniscono funzionalità extra e quando dici di voler usare Python, non si tratta solo del linguaggio ma anche di tutto l’ecosistema di pacchetti di cui sei interessato, 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.

Anche le prestazioni sono scadenti, principalmente per design. Le prestazioni di calcolo si riferiscono alla qualità del lavoro svolto da Python per sfruttare la potenza di calcolo grezza disponibile dal tuo computer. Sorprendentemente, Microsoft Excel fa un lavoro molto migliore in questo senso. 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 comportano prestazioni 100 volte più lente di quanto la tua macchina potrebbe teoricamente offrire. Sebbene possa sembrare accettabile per alcuni, date le potenzialità dei computer moderni, non è ideale per le aziende con volumi di transazioni superiori a 50 milioni di dollari. Si desidera qualcosa che offra buone prestazioni fin dall’inizio.

L’idea di utilizzare una libreria di terze parti come NumPy per affrontare la mancanza di prestazioni di Python aggiunge solo complessità. Potresti risolvere il problema delle prestazioni, ma stai creando un nuovo problema introducendo la complessità aggiuntiva di NumPy, con cui devi fare i conti e mantenere nel tempo. Questo alza anche l’asticella sul lato dell’ingegneria del software del problema.

Quando si tenta di implementare soluzioni Python per la gestione reale della supply chain, sorgono vari problemi, come eccezioni di riferimento nullo, eccezioni di memoria esaurita e tempi di calcolo lunghi. Potresti trovarti ad aspettare 20 minuti per completare un calcolo, incerto se finirà mai o se dovresti semplicemente interrompere il processo e riavviarlo. Non lo so, quindi si desidera avere una buona idea di quanto tempo ci vorrà per completare. A proposito, se torno a Excel, al giorno d’oggi quando c’è un’operazione che richiede un po’ di tempo per completarsi, Excel ti darà un indicatore abbastanza affidabile, una barra di avanzamento su quanto tempo ci vorrà. Quindi, di nuovo, si desidera, ed è parte di ciò a cui mi riferisco come prontezza alla produzione. Si desidera avere qualcosa che è perché, ancora una volta, è probabile che il software che si sta producendo funzioni in modo non assistito, durante la notte o durante il batch notturno, ad esempio. Si desidera qualcosa che non richieda a un data scientist di sorvegliare l’intera cosa.

E ancora, se hai il problema con i data scientist, allora hai bisogno della terza competenza: esperto di supply chain, esperto di ingegneria del software e ora esperto di data scientist. È possibile avere tutte e tre queste qualità in una persona, ma buona fortuna a trovare più di una persona all’anno, anche se sei un’azienda grande che ha tutte queste competenze. È semplicemente molto raro.

Quindi vogliamo avere qualcosa che migliorerà. 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 ransomware. Perché improvvisamente, quando hai un programma, il programma sulla macchina può fare un sacco di cose, incluso dirottare la stessa macchina su cui sta girando. So che ci sono un sacco di modi per mitigare i problemi; puoi isolare le cose, puoi limitare, puoi avere diritti limitati e ci sono un sacco di modi per limitare i problemi. Tuttavia, ogni volta che hai qualcosa come un linguaggio di programmazione generico, la tua superficie di attacco, questo è un termine tecnico, è assolutamente gigantesca.

Quindi fondamentalmente, ogni volta che inserisci codice del genere, ti esponi enormemente in termini di problemi di sicurezza. E ricorda, il modo in cui viene tipicamente fatto in un’azienda di ingegneria del software regolare è che il codice viene revisionato dai pari. Quindi si revisiona il codice, si ha un processo di revisione del codice, qualcuno produce il codice e c’è un collega che lo revisiona per assicurarsi che non ci siano trucchi nel codice. Ma se torno al fatto che il software deve essere robusto, devi essere in grado di rispondere entro poche ore. Non sarai in grado, da una prospettiva di ottimizzazione della supply chain, di avere un processo di revisione del codice in atto. Semplicemente non è compatibile con i ritardi e le emergenze che affronterai.

Quindi, devi avere qualcosa che ti dia una difesa in profondità per design. Poi vuoi avere qualcosa con prestazioni trasparenti, dove sì, le cose possono richiedere tempo, ma devi essere sotto controllo. Devi sapere in anticipo quanto tempo ci vorrà. Se non hai questo, ti esponi a un sacco di problemi molto stupidi, come ad esempio avere una finestra di due ore per consegnare i risultati e ritardarti. E sai cosa? I camion sono già partiti. È troppo tardi. Quindi devi avere qualcosa in cui ci si prenda cura.

E lo stesso vale per gli aggiornamenti trasparenti. Questa è la bellezza di Excel. Non devi pensare alla manutenzione di Excel. Microsoft ha firmato un patto di sangue decenni fa, che era: 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 al giorno d’oggi, supporta molti formati Excel concorrenti di concorrenti che non esistono più. Puoi ancora leggere fogli di calcolo prodotti con Lotus Notes e cose del genere. 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 cosa? È curato. Questo non è qualcosa che vedi quando guardi la transizione da Python 2 a Python 3; è stato un incubo e ci sono voluti dieci anni. Quindi, Python è ottimo per molte cose, ma immagina solo che quegli aggiornamenti avvengano nei momenti peggiori, quando hai la peggiore pandemia, la peggiore tariffa, l’emergenza peggiore e hai bisogno che le cose siano pronte e funzionanti. Non puoi permetterti di avere un’interruzione di sei mesi solo perché devi occuparti di un aggiornamento. Questo non è qualcosa che è compatibile con l’ottimizzazione della supply chain.

Quindi ora dobbiamo pensare a cosa succederebbe se considerassimo effettivamente qualcosa che potrebbe essere progettato tenendo a mente la supply chain? Questo sarà l’argomento della prossima lezione.

Inoltre, la supply chain non è la divisione IT. Quando dico una consegna orientata al prodotto, ancora una volta, non è che il software sia solo un mezzo, non un fine. Non venderai il tuo software per licenze o una tariffa come fa, diciamo, Microsoft. In questa visione che sto delineando davanti a voi in questa lezione, l’IT è responsabile delle pratiche fondamentali, delle pratiche fondamentali dell’IT, come cosa dovresti fare o non fare in termini di sicurezza, backup, infrastruttura di base, rete, come gestire e sincronizzare tutto in termini di dati a livello aziendale e fornire tutte le indicazioni e il coaching.

Ma l’idea è che la supply chain deve possedere le decisioni della supply chain. Devono possedere tutto l’apparato che genera quelle decisioni della supply chain, quindi quella è la loro proprietà principale. Nella lezione precedente, ho detto cosa definisce lo scienziato della supply chain: lo scienziato della supply chain è qualcuno che possiede le decisioni numeriche prodotte dal codice. Non è un sistema che produce decisioni; sono ricette numeriche che sono state scritte da uno o più scienziati della supply chain, e quegli scienziati della supply chain possiedono collettivamente quelle decisioni numeriche. Prendono possesso di quelle decisioni e la responsabilità della supply chain è assicurarsi che tutte le decisioni dell’azienda siano coerenti. Se c’è una promozione in corso o una grande spinta di marketing, le cose devono essere prodotte in tempo in modo che siano pronte per essere servite. Non vuoi finire in una situazione catastrofica in cui stai spingendo qualcosa quando sei già in una situazione di quasi esaurimento delle scorte, dove spendi soldi per una spinta di marketing per qualcosa che non puoi nemmeno vendere perché non hai le scorte o la capacità di produrle o fornire il servizio in tempo, ecc.

Quindi, abbiamo due divisioni che hanno focus molto diversi. Nella mia visione ideale di quello che dovrebbe essere il dipartimento IT, il dipartimento IT non è una divisione in cui passi i ticket. Non funziona così. Il dipartimento IT è responsabile dell’infrastruttura di base. È una cosa che funziona in modo impeccabile tutto il tempo. Non ci fai nemmeno caso, proprio come il Wi-Fi funziona. Non ci fai caso al Wi-Fi; ci fai caso solo quando non funziona. Un buon dipartimento IT fornisce tutta l’infrastruttura in modo che nemmeno ci fai caso. Nemmeno ti rendi conto che esistono perché funziona, proprio come le tue email funzionano in modo impeccabile, ecc. Di questo si tratta un buon IT di base. E poi, l’IT è il tipo di persone che vengono da te e ti aiutano a stabilire tutte quelle pratiche che ti danno una mano. La logica programmabile è un po’ difficile, quindi a volte, dove andrai a prendere il coaching per migliorare un po’ la programmazione? Beh, la risposta è che dovrebbe essere l’IT. Non dovrebbero venire a dire: “Lo programmeremo per te”, ma piuttosto: “Ti insegneremo in modo che tu possa effettivamente implementarlo da solo. Ti aiuteremo con alcuni concetti, forse ti aiuteremo con alcune cose che sono un po’ più tecniche di quanto dovrebbero essere.” A volte hai 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 stia commettendo un errore terminale che potrebbe esporre l’intera azienda a un rischio come un ransomware o qualcosa che potrebbe essere un rischio sistemico, dal punto di vista IT, per l’azienda.

Come test di verifica, se la tua interazione tra IT e supply chain passa attraverso documenti in cui elenchi specifiche o requisiti, questo non è il modo corretto per avere una buona relazione tra queste due divisioni. Quando dico una buona relazione, intendo qualcosa che aggiungerà effettivamente valore per l’azienda.

In conclusione, abbiamo due sfide qui dal lato tradizionale della gestione della supply chain, che potrebbe aver fatto programmazione ma solo marginalmente per fogli di calcolo di Excel, senza nemmeno rendersi conto 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, ed è un cambiamento enorme. Sì, ma è qualcosa con cui puoi affrontare. Perché? Perché se hai gli strumenti giusti, sì, c’è programmazione coinvolta, ma non è fondamentalmente, radicalmente più difficile di Excel. Di nuovo, la sfida non sta nella tecnicalità dello strumento; sta letteralmente nella complessità della supply chain stessa. Il problema è difficile non perché il tuo strumento è difficile da gestire, ma perché hai una supply chain complicata in primo luogo.

Per la parte del pubblico che è forse più orientata verso il data scientist o il lato IT, ciò che devi superare è la sovrafiducia. Ho visto, ancora e ancora, data scientist, e mi includo in questa categoria, che erano troppo fiduciosi nella loro capacità di portare un prototipo in produzione. Questo è difficile, e le supply chain hanno un modo di esplodere in faccia nel modo più sorprendente. Posso solo ricordare un aneddoto in cui anni fa abbiamo iniziato con un’azienda leader europea di e-commerce di parti auto. Gestivamo i loro rifornimenti di parti con la nostra tecnologia di previsione, facendo suggerimenti per i rifornimenti di parti, servendo parti auto. La settimana successiva, abbiamo visto che tutte le nostre previsioni erano sbagliate di un fattore due. La domanda era raddoppiata. Cosa era successo era che il loro principale concorrente aveva deciso di andare 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 di ottimizzazione dei motori di ricerca. Erano più ottimizzati in termini di SEO, quindi fondamentalmente, le persone vedevano l’annuncio TV del concorrente, ma non ricordavano naturalmente il nome del concorrente. Quindi, andavano su Google e digitavano “parti auto” finché non finivano sul sito web del mio cliente. Per dimostrare quanto fosse grande Lokad, la prima settimana quando stavamo iniziando, eravamo sbagliati 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, e molte cose sono intatte.

Quindi è questo il tipo di cosa, e devi essere in grado di reagire prontamente. Di questo si tratta: paura e sovrafiducia. Grazie mille per il tempo dedicato.

Ora, darò un’occhiata alle domande tramite la chat.

Domanda: Il software può prendere la decisione su quale fornitore effettuare un ordine extra nel caso in cui sia necessario di più per domani? Ad esempio, i vasetti di fragole da 200 grammi 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 i due lati della gestione della supply chain e dell’ottimizzazione della supply chain. C’è il lato della gestione della supply chain, che consiste nel mettere letteralmente in atto tutte le pipeline di dati, compreso l’EDI, dove puoi inviare un ordine elettronico a un fornitore senza alcuna intervento umano. Quindi hai un ponte elettronico end-to-end. Ma poi, ciò significa che devi avere, sul lato dell’ottimizzazione, un software che funzioni in modo continuo durante tutto il giorno e, ad un certo punto, possa notificare il lato della gestione, dicendo: “Esegui questo ordine, per favore”. E poi, sul lato della gestione, che sarà gestito da IT, si assicurano semplicemente che questo ordine venga completamente eseguito. È 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à, rispetti tutti i vincoli, come l’elenco esatto dei fornitori che sono anche idonei a servire questi prodotti, se hanno ancora qualche stock rimasto e come fare la scelta giusta tra tutti i fornitori concorrenti, ecc. Potrebbero esserci molte cose in corso. Assolutamente sì, ma dobbiamo letteralmente separare l’esecuzione banale, che è la parte transazionale che si trova sul lato della gestione della supply chain, dall’avere l’ingrediente dell’ottimizzazione nel momento in cui decidi che hai bisogno di riordinare di più.

Domanda: Sai che stai competendo con i Campionati Mondiali di eSports in questo momento?

No, in questo momento non sto competendo con quei campionati di eSports, ma è molto bello. A proposito, da Lokad, giochiamo frequentemente a Dota 2, quindi anche il team di gestione gioca. Alcuni dei nostri dipendenti vogliono giocare a League of Legends, ma come CEO dell’azienda, disapprovo fermamente.

Domanda: Ho visto che molte aziende non hanno un ERP o un WMS in primo luogo, e che la gestione sta lavorando sull’ottimizzazione della supply chain.

Beh, assolutamente. Non puoi evitare l’ottimizzazione della supply chain fin dal primo giorno; devi prendere quelle decisioni. L’ottimizzazione della supply chain c’era anche prima che fosse in uso qualsiasi tipo di software per la gestione della supply chain. Anche se torniamo indietro di 60 anni fa, quando non c’erano software, le persone dovevano comunque prendere decisioni. Quindi l’ottimizzazione della supply chain era già una cosa; le persone lo facevano con penna e carta. Se guardi i primi lavori sulla supply chain, come la Formula di Wilson, nota anche come formula EOQ, ha un secolo di storia. Chiaramente precede il software. Quindi sì, l’ottimizzazione della supply chain è qualcosa che avviene fin dal primo giorno, indipendentemente dal fatto che tu abbia o meno un software nella tua organizzazione.

Ora, effettivamente, devi avere dei sistemi IT adeguati, ma è una mentalità completamente diversa. La gestione della supply chain consiste nel fare molto bene compiti banali, come l’inserimento dei dati, potenzialmente con il supporto per i codici a barre e altre cose. Ma si tratta di compiti molto banali, solo di rappresentazione dei dati. Il problema è che le persone vogliono qualcosa che faccia sia la gestione della supply chain che l’ottimizzazione della supply chain, e di conseguenza si finisce con un prodotto che è troppo complicato, di solito pieno di bug, e hai bisogno di funzionalità scadenti come avvisi ed eccezioni, che dovresti evitare. Tornerò su questo argomento 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ò richiedere mesi se separi questa cosa dalle tue decisioni.

Domanda: Quando la direzione dell’azienda può capire che è il momento di passare dal monitoraggio delle informazioni all’ottimizzazione delle decisioni sulla supply chain e infine iniziare a concentrarsi sull’ottimizzazione della supply chain?

La prima cosa è che devi renderti conto fin dall’inizio che ci sono due problemi e che lo stesso software non affronterà mai entrambi gli aspetti. Penso che questa sia la grande illusione e i fornitori di software sono stati incredibilmente confusi in questo settore. Se guardi i più grandi fornitori di ERP, il loro messaggio riguarda l’ottimizzazione della supply chain, ma tutto ciò che effettivamente offrono e tutte le cose che il loro prodotto fa effettivamente riguardano il lato della gestione della supply chain, che è molto meno interessante perché non c’è intelligenza artificiale o intelligenza reale. Nel mondo del software, è noto come applicazioni CRUD (Create, Read, Update, Delete). Gli ERP sono solo enormi collezioni 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 collezione 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 sulla gestione, il problema è che se sei un manager, leggi il depliant del fornitore di ERP e i fornitori di ERP ti dicono che questa cosa ottimizzerà la tua supply chain. La risposta è: no, assolutamente no. Ciò che farà è migliorare la produttività e garantire una contabilità accurata della tua supply chain. Questo è già molto, poiché può ridurre drasticamente il furto, la sottrazione, la merce smarrita e migliorare la produttività con i codici a barre per un magazzino. Ci sono molti vantaggi aggiunti in questi prodotti. Non sto sottovalutando il valore che un ERP o un WMS porta sul tavolo; è enorme, ma non riguarda l’ottimizzazione della supply chain. Un WMS, ad esempio, è per definizione qualcosa che si preoccupa del magazzino; non si preoccupa dell’intera supply chain che include clienti e fornitori. È progettato per concentrarsi su posizioni specifiche, non sull’intera catena.

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

Li abbiamo fatti lavorare insieme in alcune situazioni storicamente. Per il pubblico, Envision è un linguaggio di programmazione specifico del dominio progettato da Lokad che è stato sviluppato esclusivamente per l’ottimizzazione predittiva delle supply chain. Nella prossima lezione, mostrerò Envision in modo che le persone possano capire meglio di cosa sto parlando, con veri pezzi di codice.

Storicamente, abbiamo usato Python ed Envision insieme perché, quando abbiamo iniziato, Envision aveva capacità molto limitate, quindi mancavano molte cose e ricorrevamo a Python in molte situazioni. Nel corso degli anni, abbiamo gradualmente ampliato le capacità di Envision, in modo da eliminare gradualmente la necessità di avere componenti Python. Non si tratta solo di componenti Python; si tratta anche di una serie di strumenti che devono essere collegati insieme, come Airflow.

A proposito, la sintassi di Envision è stata appositamente allineata in molti aspetti a Python. Ho fatto la scelta consapevole di progettare la sintassi di Envision in modo che non fosse in contrasto con i programmatori Python, in modo che se sei familiare con Python, puoi imparare Envision in una settimana. Differisce in modi sottili e profondi, ma per quanto riguarda la sintassi, ci sono molti aspetti che 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 risolti, non significa che Python non abbia meriti. Non è questo che sto dicendo. Credo che Python abbia molti meriti. Di nuovo, stiamo parlando specificamente di come gestire le supply chain 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é, sinceramente, la situazione peggiore è quando un potenziale cliente viene da me e dice: “Il nostro ERP, un ERP legacy, non sta fornendo alcun valore e ora vogliamo passare al prossimo ERP che offre ottimizzazione della supply chain”. È una situazione terribile per me perché devo dire al cliente che ciò che sta cercando non è un solo prodotto, ma due: uno che sostituirà il loro ERP e gestirà meglio il lato gestionale e uno che si occupa dell’ottimizzazione.

Quando si pensa a quegli ERP legacy, ho molto rispetto per loro, specialmente quei prodotti AS/400 con un terminale a riga di comando su vecchi mainframe IBM. Dal lato gestionale del problema, di solito fanno un lavoro molto equo. Quello che i clienti cercano veramente potrebbe essere un’interfaccia web anziché una riga di comando, ma questo renderà le loro squadre sul campo più produttive? Metto in discussione questo. Le righe di comando con terminali di testo possono essere incredibilmente rapide e produttive senza distrazioni.

Quindi, è piuttosto difficile perché dobbiamo districare tutte le sciocchezze spinte dai nostri concorrenti. Inoltre, dobbiamo spiegare che l’ERP non ottimizzerà la supply chain e che non esiste una cosa del genere come l’IA o la blockchain, solo classi di modelli statistici. Sfortunatamente, perdiamo la maggior parte dei nostri potenziali clienti in questa fase. Questo è uno dei motivi per cui sto facendo queste lezioni in primo luogo, perché ci vogliono ore per arrivare in fondo e spiegare perché dobbiamo vedere il problema nel modo in cui lo vedo io.

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

Beh, Lokad, ovviamente. Ma ricorda che, essendo il CEO di Lokad e il maggior azionista dell’azienda, ho un conflitto di interessi nella mia opinione. Sono profondamente convinto che Lokad sia la piattaforma di cui hai bisogno, ma per favore capisci che è anche l’azienda che possiedo e gestisco. Farò del mio meglio per rimanere obiettivo quando si tratta di questo.

A proposito, Lokad è stato letteralmente progettato per gestire la distribuzione di domanda probabilistica, e non solo la distribuzione di domanda probabilistica. Affronta anche la distribuzione del tempo di consegna stocastico, la distribuzione stocastica dei resi e altro ancora. Dobbiamo considerare tutti i futuri possibili con le probabilità, considerando tutti i tipi di incertezze. La domanda è molto importante, di solito la più importante, ma non è l’unica.

Credo di aver risposto a tutte le domande. Controllo solo se ho perso qualcosa… Nessuna ulteriore 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: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity - Di Joel Spolsky, 2004