00:19 Introduzione
04:33 Due definizioni per ‘algoritmo’
08:09 Big-O
13:10 La storia finora
15:11 Scienze ausiliarie (riassunto)
17:26 Algoritmi moderni
19:36 Superare l’ “ottimalità”
22:23 Strutture dati - 1/4 - Lista
25:50 Strutture dati - 2/4 - Albero
27:39 Strutture dati - 3/4 - Grafo
29:55 Strutture dati - 4/4 - Tabella hash
31:30 Ricette magiche - 1/2
37:06 Ricette magiche - 2/2
39:17 Comprendere i tensori - 1/3 - La notazione ‘Einstein’
42:53 Comprendere i tensori - 2/3 - La scoperta del team di Facebook
46:52 Comprendere i tensori - 3/3 - Prospettiva della supply chain
52:20 Meta tecniche - 1/3 - Compressione
56:11 Meta tecniche - 2/3 - Memoizzazione
58:44 Meta tecniche - 3/3 - immutabilità
01:03:46 Conclusioni
01:06:41 Prossima lezione e domande del pubblico
Descrizione
L’ottimizzazione delle supply chain si basa sulla risoluzione di numerosi problemi numerici. Gli algoritmi sono ricette numeriche codificate destinate a risolvere problemi computazionali precisi. Algoritmi superiori significano che si possono ottenere risultati superiori con meno risorse di calcolo. Concentrandosi sulle specificità della supply chain, le prestazioni algoritmiche possono essere notevolmente migliorate, talvolta di ordini di grandezza. Gli algoritmi della “supply chain” devono anche abbracciare il design dei computer moderni, che è significativamente evoluto negli ultimi decenni.
Trascrizione completa
Benvenuti a questa serie di lezioni sulla supply chain. Sono Joannes Vermorel e oggi presenterò “Algoritmi Moderni per la Supply Chain”. Capacità di calcolo superiori sono fondamentali per ottenere una performance della supply chain superiore. Previsioni più accurate, ottimizzazione più dettagliata e ottimizzazione più frequente sono tutte desiderabili per ottenere una performance della supply chain superiore. C’è sempre un metodo numerico superiore appena al di là delle risorse di calcolo che puoi permetterti.
Gli algoritmi, per semplificarla, fanno andare più veloci i computer. Gli algoritmi sono un ramo della matematica e questo è un campo di ricerca molto attivo. I progressi in questo campo di ricerca spesso superano i progressi dell’hardware di calcolo stesso. L’obiettivo di questa lezione è capire di cosa si tratta con gli algoritmi moderni e, più specificamente, da una prospettiva della supply chain, come affrontare i problemi in modo da poter sfruttare al massimo quegli algoritmi moderni per la tua supply chain.
Per quanto riguarda gli algoritmi, c’è un libro che è un riferimento assoluto: Introduction to Algorithms, pubblicato per la prima volta nel 1990. È un libro da leggere assolutamente. La qualità della presentazione e della scrittura è semplicemente eccezionale. Questo libro ha venduto oltre mezzo milione di copie durante i suoi primi 20 anni di vita e ha ispirato un’intera generazione di scrittori accademici. Di fatto, la maggior parte dei recenti libri sulla supply chain che trattano la teoria della supply chain pubblicati nell’ultimo decennio sono spesso stati fortemente ispirati dallo stile e dalla presentazione trovati in questo libro.
Personalmente, ho letto questo libro nel 1997 ed era in realtà una traduzione francese della prima edizione. Ha avuto un’influenza profonda su tutta la mia carriera. Dopo aver letto questo libro, non ho mai più visto il software allo stesso modo. Una parola di cautela, però, è che questo libro adotta una prospettiva sull’hardware di calcolo che era prevalente alla fine degli anni ‘80 e all’inizio degli anni ‘90. Come abbiamo visto nelle precedenti lezioni di questa serie, l’hardware di calcolo è progredito in modo piuttosto drammatico negli ultimi decenni e quindi alcune delle supposizioni fatte in questo libro sembrano relativamente datate. Ad esempio, il libro assume che gli accessi alla memoria abbiano un tempo costante, indipendentemente da quanta memoria si desidera indirizzare. Questo non è più il modo in cui funzionano i computer moderni.
Tuttavia, credo che ci siano certe situazioni in cui essere semplicistici sia una proposta ragionevole se ciò che si guadagna in cambio è un grado molto più elevato di chiarezza e semplicità di esposizione. Questo libro fa un lavoro straordinario su questo fronte. Sebbene consigli di tenere presente che alcune delle supposizioni chiave fatte in tutto il libro sono datate, rimane comunque un riferimento assoluto che consiglierei all’intero pubblico.
Chiarifichiamo il termine “algoritmo” per il pubblico che potrebbe non essere così familiare con la nozione. C’è la definizione classica in cui è una sequenza finita di istruzioni informatiche ben definite. Questo è il tipo di definizione che troverai nei libri di testo o su Wikipedia. Sebbene la definizione classica di un algoritmo abbia i suoi meriti, credo che sia deludente, poiché non chiarisce l’intento associato agli algoritmi. Non è qualsiasi tipo di sequenza di istruzioni che è interessante; è una sequenza molto specifica di istruzioni informatiche. Pertanto, propongo una definizione personale del termine algoritmo: un algoritmo è essenzialmente un metodo software orientato alle prestazioni, dettagliato e orientato alla risoluzione di problemi.
Svisceriamo questa definizione, vero? Prima di tutto, la parte di risoluzione del problema: un algoritmo è completamente caratterizzato dal problema che cerca di risolvere. In questa schermata, puoi vedere il pseudocodice per l’algoritmo Quicksort, che è un algoritmo popolare e ben noto. Quicksort cerca di risolvere il problema della classificazione, che è il seguente: hai un array che contiene voci di dati e desideri un algoritmo che restituisca lo stesso array ma con tutte le voci ordinate in ordine crescente. Gli algoritmi si concentrano completamente su un problema specifico e ben definito.
Il secondo aspetto è come giudichi di avere un algoritmo migliore. Un algoritmo migliore è qualcosa che ti consente di risolvere lo stesso problema con meno risorse di calcolo, il che in pratica significa più velocemente. Infine, c’è la parte dettagliata. Quando diciamo il termine “algoritmi”, si intende che vogliamo guardare problemi molto elementari che sono modulari e possono essere composti all’infinito per risolvere problemi molto più complicati. Di questo si tratta davvero degli algoritmi.
Uno dei principali risultati della teoria degli algoritmi è fornire una caratterizzazione delle prestazioni degli algoritmi in modo piuttosto astratto. Oggi non avrò il tempo di approfondire i dettagli di questa caratterizzazione e del quadro matematico. L’idea è che, per caratterizzare l’algoritmo, vogliamo analizzare il comportamento asintotico. Abbiamo un problema che dipende da una o più dimensioni chiave che caratterizzano il problema. Ad esempio, nel problema di ordinamento che ho presentato in precedenza, la dimensione caratteristica è di solito il numero di elementi da ordinare. La domanda è: cosa succede quando l’array di elementi da ordinare diventa molto grande? Mi riferirò a questa dimensione caratteristica con il numero “n” come convenzione.
Ora, ho questa notazione, la notazione Big O, che potresti aver visto quando si tratta di algoritmi. Voglio solo delineare alcuni elementi per darti un’idea di cosa sta succedendo. Innanzitutto, diciamo, ad esempio, che abbiamo un set di dati e vogliamo estrarre un semplice indicatore statistico come una media. Se dico che ho un algoritmo Big O di 1, significa che sono in grado di restituire una soluzione a questo problema (calcolare la media) in tempo costante, indipendentemente dal fatto che il set di dati sia piccolo o grande. Il tempo costante, o Big O di 1, è un requisito assoluto quando si desidera fare qualcosa che è in tempo reale nel senso della comunicazione da macchina a macchina. Se non hai qualcosa che richiede tempo costante, è molto difficile, a volte impossibile, ottenere prestazioni in tempo reale.
Tipicamente, un altro aspetto chiave delle prestazioni è il Big O di N. Il Big O di N significa che hai una complessità per l’algoritmo che è strettamente lineare rispetto alla dimensione del set di dati di interesse. Questo è ciò che ottieni quando hai un’implementazione efficiente che è in grado di risolvere il problema leggendo i dati una sola volta o un numero fisso di volte. La complessità Big O di N è tipicamente compatibile solo con l’esecuzione batch. Se vuoi avere qualcosa che sia online e in tempo reale, non puoi avere qualcosa che attraversa l’intero set di dati, a meno che tu non sappia che il tuo set di dati ha una dimensione fissa.
Oltre alla linearità, hai il Big O di N al quadrato. Il Big O di N al quadrato è un caso molto interessante perché è il punto di esplosione della produzione. Significa che la complessità cresce quadraticamente rispetto alla dimensione del set di dati, il che significa che se hai 10 volte più dati, le prestazioni saranno 100 volte peggiori. Questo è tipicamente il tipo di prestazione in cui non vedrai alcun problema nel prototipo perché stai lavorando con piccoli set di dati. Non vedrai alcun problema nella fase di test perché, ancora una volta, stai lavorando con piccoli set di dati. Appena passi alla produzione, hai un software che è completamente lento. Molto spesso nel mondo del software aziendale, soprattutto nel mondo del software aziendale per la supply chain, la maggior parte dei problemi di prestazioni abissali che puoi osservare sul campo sono causati da algoritmi quadratici che non erano stati identificati. Di conseguenza, osservi il comportamento quadratico che è semplicemente molto lento. Questo problema non è stato identificato in anticipo perché i computer moderni sono abbastanza veloci e N al quadrato non è così male finché N è abbastanza piccolo. Tuttavia, appena ti trovi a che fare con un set di dati di produzione di grandi dimensioni, fa molto male.
Questa lezione è in realtà la seconda lezione del mio quarto capitolo in questa serie di lezioni sulla supply chain. Nel primo capitolo, il prologo, ho presentato il mio punto di vista sulla supply chain sia come campo di studio che come pratica. Quello che abbiamo visto è che la supply chain è una vasta collezione di problemi complessi, a differenza dei problemi semplici. I problemi complessi non possono essere affrontati con metodologie naive perché si hanno comportamenti avversari ovunque, e quindi è necessario prestare molta attenzione alla metodologia stessa. La maggior parte dei metodi ingenui fallisce in modo spettacolare. Ecco esattamente quello che ho fatto nel secondo capitolo, che è interamente dedicato a metodologie adatte allo studio delle supply chain e al miglioramento della pratica della gestione della supply chain. Il terzo capitolo, che non è ancora completo, è essenzialmente uno zoom su ciò che chiamo “personale della supply chain”, una metodologia molto specifica in cui ci concentriamo sui problemi stessi anziché sulle soluzioni che possiamo pensare per affrontare il problema. In futuro, alternerò il capitolo numero tre con il capitolo attuale, che riguarda le scienze ausiliarie della supply chain.
Durante l’ultima lezione, abbiamo visto che possiamo ottenere maggiori capacità di calcolo per la nostra supply chain attraverso hardware informatico migliore e più moderno. Oggi, stiamo guardando il problema da un altro punto di vista: stiamo cercando maggiori capacità di calcolo perché abbiamo un software migliore. Di questo si occupano gli algoritmi.
Un breve riassunto: le scienze ausiliarie sono essenzialmente una prospettiva sulla supply chain stessa. La lezione di oggi non riguarda strettamente la supply chain; riguarda gli algoritmi. Tuttavia, credo che sia di fondamentale importanza per la supply chain. La supply chain non è un’isola; i progressi che possono essere raggiunti nella supply chain dipendono molto dai progressi che sono già stati raggiunti in altri campi adiacenti. Mi riferisco a quei campi come le scienze ausiliarie della supply chain.
Credo che la situazione sia abbastanza simile al rapporto tra scienze mediche e chimica durante il XIX secolo. All’inizio del XIX secolo, le scienze mediche non si interessavano affatto di chimica. La chimica era ancora il nuovo arrivato e non veniva considerata una proposta valida per un paziente effettivo. Saltiamo al XXI secolo, la proposta che si possa essere un eccellente medico senza conoscere nulla di chimica sarebbe considerata completamente preposterous. Si è concordato che essere un eccellente chimico non ti rende un eccellente medico, ma è generalmente concordato che se non sai nulla di chimica del corpo, non puoi essere competente per quanto riguarda le moderne scienze mediche. La mia previsione per il futuro è che durante il XXI secolo, il campo della supply chain inizierà a considerare il campo degli algoritmi praticamente allo stesso modo in cui il campo delle scienze mediche ha iniziato a guardare alla chimica durante il XIX secolo.
Gli algoritmi sono un vasto campo di ricerca, un ramo della matematica, e oggi ne toccheremo solo la superficie. In particolare, questo campo di ricerca ha accumulato risultati sorprendenti dopo risultati sorprendenti per decenni. Può essere un campo di ricerca piuttosto teorico, ma non significa che sia solo teoria. In realtà, è un campo di ricerca piuttosto teorico, ma ci sono state tonnellate di scoperte che hanno trovato applicazione pratica.
Di fatto, qualsiasi tipo di smartphone o computer che stai usando oggi sta letteralmente utilizzando decine di migliaia di algoritmi che sono stati originariamente pubblicati da qualche parte. Questo curriculum è effettivamente molto più impressionante rispetto alla teoria della supply chain, dove la stragrande maggioranza delle supply chain non si basa ancora sui risultati della teoria della supply chain. Quando si tratta di computer moderni e algoritmi moderni, praticamente tutto ciò che è legato al software è completamente guidato da tutti quei decenni di scoperte della ricerca algoritmica. Questo è molto al centro di praticamente ogni singolo computer che stiamo usando oggi.
Per la lezione di oggi, ho selezionato una lista di argomenti che ritengo essere piuttosto illustrativi di ciò che dovresti conoscere per affrontare il tema degli algoritmi moderni. Prima, discuteremo come possiamo effettivamente superare algoritmi suppostamente ottimali, soprattutto per la supply chain. Poi, daremo un’occhiata veloce alle strutture dati, seguite da ricette magiche, compressione tensoriale e infine, tecniche meta.
Innanzitutto, vorrei chiarire che quando dico “algoritmi per la supply chain”, non intendo algoritmi che sono destinati a risolvere problemi specifici della supply chain. La prospettiva corretta è guardare agli algoritmi classici per problemi classici e rivedere quei problemi classici da una prospettiva della supply chain per vedere se possiamo effettivamente fare qualcosa di meglio. La risposta è sì, possiamo.
Ad esempio, l’algoritmo quicksort, secondo la teoria generale degli algoritmi, è ottimale nel senso che non puoi introdurre un algoritmo che sia arbitrariamente migliore del quicksort. Quindi, sotto questo punto di vista, il quicksort è il migliore che possa mai essere. Tuttavia, se ci concentriamo specificamente sulla supply chain, è possibile ottenere velocizzazioni sorprendenti. In particolare, se guardiamo ai problemi di ordinamento in cui la cardinalità dei dataset di interesse è bassa, come ad esempio date, prezzi, livelli di stock o categorie, tutti questi sono dataset a bassa cardinalità. Quindi, se hai delle assunzioni extra, come trovarsi in una situazione di bassa cardinalità, allora puoi utilizzare il bucket sort. Nella produzione, ci sono molte situazioni in cui puoi ottenere velocizzazioni assolutamente monumentali, come 500 volte più veloce del quicksort. Quindi, puoi essere di ordini di grandezza più veloce di quello che era supposto essere ottimale solo perché non ti trovi nel caso generale ma nel caso della supply chain. Questo è qualcosa di molto importante e credo che qui risieda il fulcro dei risultati sorprendenti che possiamo ottenere sfruttando gli algoritmi per la supply chain.
Credo che questa prospettiva sia sbagliata per almeno due motivi. Prima di tutto, come abbiamo visto, non è necessariamente l’algoritmo standard quello di interesse. Abbiamo visto che c’è un algoritmo suppostamente ottimale come il quicksort, ma se prendi lo stesso identico problema da un punto di vista della supply chain, puoi ottenere velocizzazioni massive. Quindi, è di primaria importanza essere familiari con gli algoritmi, anche solo per poter rivedere i classici e ottenere velocizzazioni massive solo perché non ti trovi nel caso generale ma nel caso della supply chain.
Il secondo motivo per cui credo che questa prospettiva sia sbagliata è che gli algoritmi riguardano molto le strutture dati. Le strutture dati sono modi in cui puoi organizzare i dati in modo da poter operare in modo più efficiente sui dati stessi. La cosa interessante è che tutte queste strutture dati formano un vocabolario di qualche tipo e avere accesso a questo vocabolario è essenziale per essere in grado di descrivere situazioni della supply chain in modo che si prestino a una facile traduzione in software. Se inizi con una descrizione usando termini comuni, finisci di solito con cose che sono estremamente difficili da tradurre in software. Se ti aspetti che un ingegnere del software, che non sa nulla della supply chain, implementi questa traduzione per te, potrebbe essere una ricetta per problemi. In realtà, è molto più facile se conosci questo vocabolario, in modo da poter parlare direttamente dei termini che si prestano facilmente alla traduzione delle idee che hai in software.
Rivediamo le strutture dati più popolari e semplici. La prima sarebbe la lista. La lista può essere utilizzata, ad esempio, per rappresentare un percorso di consegna, che sarebbe la sequenza di consegne da effettuare, con una voce per ogni consegna. Puoi enumerare il percorso di consegna man mano che procedi. Una lista può anche rappresentare un flusso di lavoro, che è una sequenza di operazioni necessarie per produrre un certo pezzo di attrezzatura, o una catena di comando, che determina chi deve prendere determinate decisioni.
Allo stesso modo, gli alberi sono un’altra struttura dati ubiqua. A proposito, gli alberi algoritmici sono capovolti, con la radice in alto e i rami in basso. Gli alberi ti permettono di descrivere tutti i tipi di gerarchie e le supply chain hanno gerarchie ovunque. Ad esempio, una distinta base è un albero; hai un pezzo di attrezzatura che vuoi produrre e questo pezzo di attrezzatura è composto da assemblaggi. Ogni assemblaggio è composto da sottocomponenti e ogni sottocomponente è composto da parti. Se espandi completamente la distinta base, ottieni un albero. Allo stesso modo, un catalogo prodotti, in cui hai famiglie di prodotti, categorie di prodotti, prodotti, sottocategorie, ecc., ha molto spesso un’architettura simile a un albero. Un organigramma, con il CEO in cima, i dirigenti di livello C sotto, e così via, è anche rappresentato da un albero. La teoria algoritmica ti fornisce una moltitudine di strumenti e metodi per elaborare alberi e svolgere operazioni in modo efficiente sugli alberi. Ogni volta che puoi rappresentare i dati come un albero, hai un intero arsenale di metodi matematici per lavorare in modo efficiente con quegli alberi. Ecco perché questo è di grande interesse.
Ora, i grafi ti permettono di descrivere tutti i tipi di reti. A proposito, un grafo, nel senso matematico, è un insieme di vertici e un insieme di archi, con gli archi che collegano due vertici insieme. Il termine “grafo” potrebbe essere un po’ fuorviante perché non ha nulla a che fare con la grafica. Un grafo è solo un oggetto matematico, non un disegno o qualcosa di grafico. Quando sai come cercare i grafi, vedrai che le supply chain hanno grafi ovunque.
Alcuni esempi: un assortimento in una rete di vendita al dettaglio, che è fondamentalmente un grafo bipartito, collega prodotti e negozi. Se hai un programma di fedeltà in cui registri quale cliente ha acquistato quale prodotto nel tempo, hai un altro grafo bipartito che collega clienti e prodotti. Nel settore dell’aftermarket automobilistico, dove devi eseguire riparazioni, di solito devi utilizzare una matrice di compatibilità che ti indica l’elenco delle parti che hanno compatibilità meccanica con il veicolo di interesse. Questa matrice di compatibilità è essenzialmente un grafo. Esiste un’enorme quantità di letteratura su tutti i tipi di algoritmi che ti permettono di lavorare con i grafi, quindi è molto interessante quando puoi caratterizzare un problema come supportato da una struttura a grafo perché tutti i metodi noti in letteratura diventano immediatamente disponibili.
Infine, l’ultima struttura dati di cui parlerò oggi è la tabella hash. La tabella hash è essenzialmente il coltellino svizzero degli algoritmi. Non è nuova; nessuna delle strutture dati che ho presentato è recente secondo gli standard attuali. La tabella hash è probabilmente la più recente di tutte, risalente agli anni ‘50, quindi non è recente. Tuttavia, la tabella hash è una struttura dati incredibilmente utile. È un contenitore che contiene coppie di chiavi e valori. L’idea è che con questo contenitore puoi memorizzare molti dati e ti offre prestazioni O(1) per la ricerca, l’inserimento e la cancellazione. Hai un contenitore in cui puoi, in tempo costante, aggiungere dati, verificare se i dati sono presenti o meno (guardando la chiave) e potenzialmente rimuovere dati. Questo è molto interessante e utile. Le tabelle hash sono letteralmente ovunque e vengono ampiamente utilizzate all’interno di altri algoritmi.
Una cosa che sottolineerò, e torneremo su questo punto in seguito, è che le prestazioni di una tabella hash dipendono molto dalle prestazioni della funzione hash che hai.
Ora, diamo un’occhiata alle ricette magiche e passeremo completamente a una prospettiva diversa. I numeri magici sono fondamentalmente un anti-pattern. Nella precedente lezione, quella sulla conoscenza negativa per la supply chain, abbiamo discusso di come gli anti-pattern iniziano tipicamente con una buona intenzione ma finiscono con conseguenze non volute che annullano i presunti benefici apportati dalla soluzione. I numeri magici sono un noto anti-pattern di programmazione. Questo anti-pattern di programmazione consiste nel scrivere codice disseminato di costanti che sembrano completamente fuori luogo, rendendo il software molto difficile da mantenere. Quando hai tonnellate di costanti, non è chiaro perché hai quelle restrizioni e come sono state scelte.
Di solito, quando vedi numeri magici in un programma, è meglio isolare tutte quelle costanti in un luogo dove sono più gestibili. Tuttavia, ci sono situazioni in cui una scelta attenta di costanti fa qualcosa di completamente inaspettato e si ottengono benefici quasi magici, completamente non voluti, utilizzando numeri che sembrano essere caduti dal cielo. Questo è esattamente ciò di cui tratta l’algoritmo molto breve che sto presentando qui.
Nella supply chain, molto spesso, vogliamo essere in grado di simulare un tipo di situazione. Le simulazioni o i processi di Monte Carlo sono uno dei trucchi di base che puoi utilizzare in una miriade di situazioni di supply chain. Tuttavia, le prestazioni della tua simulazione dipendono molto dalla tua capacità di generare numeri casuali. Per generare simulazioni, di solito è coinvolto un grado di casualità generata e quindi hai bisogno di un algoritmo per generare questa casualità. Per quanto riguarda i computer, di solito è pseudocasualità: non è vera casualità; è solo qualcosa che assomiglia a numeri casuali e ha le caratteristiche statistiche dei numeri casuali ma non è effettivamente casuale.
La domanda diventa, quanto efficientemente puoi generare numeri casuali? Si scopre che esiste un algoritmo chiamato “Shift”, pubblicato nel 2003 da George Marsaglia, che è piuttosto impressionante. Questo algoritmo genera numeri casuali di alta qualità, creando una completa permutazione di 2 alla potenza di 64 meno 1 bit. Si muoverà attraverso tutte le combinazioni di 64 bit, meno una, con zero come punto fisso. Lo fa con essenzialmente sei operazioni: tre spostamenti binari e tre operazioni XOR (o esclusivo), che sono operazioni bitwise. Anche gli spostamenti sono operazioni bitwise.
Quello che vediamo è che ci sono tre numeri magici in mezzo a tutto questo: 13, 7 e 17. A proposito, tutti questi numeri sono numeri primi; non è un caso. Si scopre che se si scelgono quelle costanti molto specifiche, si ottiene un eccellente generatore di numeri casuali che si rivela anche molto veloce. Quando dico molto veloce, intendo che puoi letteralmente generare 10 megabyte al secondo di numeri casuali. Questo è assolutamente enorme. Se torniamo alla lezione precedente, possiamo capire perché questo algoritmo è così efficiente. Non solo abbiamo solo sei istruzioni che corrispondono direttamente a istruzioni supportate nativamente dall’hardware di calcolo sottostante, come il processore, ma non abbiamo nemmeno alcun branch. Non c’è alcun test, e quindi significa che questo algoritmo, una volta eseguito, sfrutterà al massimo la capacità di pipelining del processore perché non ci sono branch. Possiamo letteralmente sfruttare al massimo la profonda capacità di pipelining che abbiamo in un processore moderno. Questo è molto interessante.
La domanda è, potremmo scegliere altri numeri per far funzionare questo algoritmo? La risposta è no. Ci sono solo alcune dozzine o forse un centinaio di diverse combinazioni di numeri che funzionerebbero effettivamente, e tutte le altre ti daranno un generatore di numeri di qualità molto bassa. Ecco dove sta la magia. Vedi, questa è una tendenza recente nello sviluppo algoritmico, trovare qualcosa di completamente inaspettato dove trovi una costante semi-magica che ti dà benefici completamente non intenzionali mescolando operazioni binarie molto inaspettate di un certo tipo. La generazione di numeri casuali è di fondamentale importanza per la supply chain.
Ma, come stavo dicendo, le tabelle hash sono ovunque ed è anche di grande interesse avere una funzione hash generica ad alte prestazioni. Esiste? Sì. Ci sono state intere classi di funzioni hash disponibili da decenni, ma nel 2019 è stato pubblicato un altro algoritmo che offre prestazioni straordinarie. Questo è quello che puoi vedere sullo schermo, “WyHash” di Wang Yi. Fondamentalmente, puoi vedere che la struttura è molto simile all’algoritmo XORShift. È un algoritmo che non ha branch, come XORShift, ed utilizza anche l’operazione XOR. L’algoritmo utilizza sei istruzioni: quattro operazioni XOR e due operazioni Multiply-No-Flags.
Multiply-No-Flags è semplicemente la moltiplicazione tra due interi a 64 bit e, come risultato, si ottengono i 64 bit alti e i 64 bit bassi. Questa è un’istruzione effettiva disponibile nei processori moderni, implementata a livello hardware, quindi conta come una sola istruzione del computer. Ne abbiamo due. Di nuovo, abbiamo tre numeri magici, scritti in forma esadecimale. A proposito, anche questi sono numeri primi, ancora una volta completamente semi-magici. Se si applica questo algoritmo, si ottiene una funzione hash non crittografica assolutamente eccellente che opera quasi alla velocità di memcpy. È molto veloce e di grande interesse.
Ora, passiamo a qualcosa di completamente diverso ancora una volta. Il successo del deep learning e di molti altri metodi moderni di machine learning si basa su alcune intuizioni algoritmiche chiave sui problemi che possono essere massicciamente accelerati dall’hardware di calcolo dedicato. Questo è ciò di cui ho parlato nella mia precedente lezione quando ho parlato dei processori con istruzioni super-scalari e, se volete di più, delle GPU e persino delle TPU. Rivediamo questa intuizione per vedere come l’intera cosa sia emersa in modo piuttosto caotico. Tuttavia, credo che le intuizioni rilevanti si siano cristallizzate negli ultimi anni. Per capire dove ci troviamo oggi, dobbiamo tornare alla notazione di Einstein, che è stata introdotta poco più di un secolo fa da Albert Einstein in uno dei suoi articoli. L’intuizione è semplice: si ha un’espressione y che è una somma da i uguale a 1 a i uguale a 3 di c_y volte x_y. Abbiamo espressioni scritte in questo modo e l’intuizione della notazione di Einstein è dire, in questo tipo di situazione, dovremmo scriverla omettendo completamente la sommatoria. In termini di software, la sommatoria sarebbe un ciclo for. L’idea è omettere completamente la sommatoria e dire che per convenzione facciamo la somma su tutti gli indici per la variabile i che ha senso.
Questa semplice intuizione porta a due risultati molto sorprendenti ma positivi. Il primo è la correttezza del design. Quando scriviamo esplicitamente la somma, rischiamo di non avere gli indici corretti, il che può portare a errori di indice fuori dai limiti nel software. Rimuovendo la sommatoria esplicita e affermando che prenderemo tutte le posizioni di indice valide per definizione, abbiamo un approccio corretto per design. Questo da solo è di primario interesse ed è correlato alla programmazione di array, un paradigma di programmazione di cui ho accennato brevemente in una delle mie lezioni precedenti.
La seconda intuizione, che è più recente e di grande interesse al giorno d’oggi, è che se si può scrivere il problema nella forma in cui si applica la notazione di Einstein, il problema può beneficiare di un’enorme accelerazione hardware nella pratica. Questo è un elemento che cambia il gioco.
Per capire il motivo, c’è un articolo molto interessante chiamato “Tensor Comprehensions” pubblicato nel 2018 dal team di ricerca di Facebook. Hanno introdotto il concetto di tensor comprehensions. Prima, permettetemi di definire le due parole. Nel campo delle scienze informatiche, un tensore è essenzialmente una matrice multidimensionale (in fisica, i tensori sono completamente diversi). Un valore scalare è un tensore di dimensione zero, un vettore è un tensore di dimensione uno, una matrice è un tensore di dimensione due e si possono avere tensori con dimensioni ancora più elevate. I tensori sono oggetti con proprietà simili ad array.
La comprensione è qualcosa di simile ad un’algebra con le quattro operazioni di base - più, meno, moltiplicazione e divisione - così come altre operazioni. È più estesa dell’algebra aritmetica regolare; ecco perché hanno una comprensione dei tensori invece di un’algebra dei tensori. È più completa ma non così espressiva come un linguaggio di programmazione completo. Quando si ha una comprensione, è più restrittiva rispetto a un linguaggio di programmazione completo in cui si può fare tutto ciò che si vuole.
L’idea è che se si guarda alla funzione MV (def MV), è fondamentalmente una funzione, e MV sta per moltiplicazione matrice-vettore. In questo caso, si tratta di una moltiplicazione matrice-vettore e questa funzione sta essenzialmente eseguendo una moltiplicazione tra la matrice A e il vettore X. Vediamo in questa definizione che la notazione di Einstein è in gioco: scriviamo C_i = A_ik * X_k. Quali valori dovremmo scegliere per i e k? La risposta è tutte le combinazioni valide per quelle variabili che sono indici. Prendiamo tutti i valori degli indici validi, facciamo la somma e nella pratica otteniamo una moltiplicazione matrice-vettore.
In fondo allo schermo, è possibile vedere lo stesso metodo MV riscritto con cicli for, specificando esplicitamente gli intervalli di valori. Il risultato chiave del team di ricerca di Facebook è che ogni volta che è possibile scrivere un programma con questa sintassi di comprensione dei tensori, hanno sviluppato un compilatore che consente di beneficiare ampiamente dell’accelerazione hardware utilizzando le GPU. Fondamentalmente, ti permettono di accelerare qualsiasi programma che puoi scrivere con questa sintassi di comprensione dei tensori. Ogni volta che puoi scrivere un programma in questa forma, beneficerai di un’accelerazione hardware massiccia, e stiamo parlando di qualcosa che sarà due ordini di grandezza più veloce di un processore normale. Questo è un risultato sorprendente di per sé.
Ora vediamo cosa possiamo fare da una prospettiva di supply chain con questo approccio. Un interesse chiave per la pratica moderna della supply chain è la previsione probabilistica. La previsione probabilistica, di cui ho parlato in una lezione precedente, è l’idea che non si avrà una previsione puntiforme, ma si prevederanno tutte le varie probabilità per una variabile di interesse. Consideriamo, ad esempio, una previsione del tempo di consegna. Si desidera prevedere il tempo di consegna e avere una previsione probabilistica del tempo di consegna.
Ora diciamo che il tempo di consegna può essere decomposto nel tempo di produzione e nel tempo di trasporto. In realtà, molto probabilmente si ha una previsione probabilistica per il tempo di produzione, che sarà una variabile casuale discreta che fornisce la probabilità di osservare un tempo di un giorno, due giorni, tre giorni, quattro giorni, ecc. Si può pensare ad essa come ad un grande istogramma che fornisce le probabilità di osservare questa durata per il tempo di produzione. Poi si avrà un processo simile per il tempo di trasporto, con un’altra variabile casuale discreta che fornisce una previsione probabilistica.
Ora si desidera calcolare il tempo di consegna totale. Se i tempi di consegna previsti fossero numeri, si farebbe semplicemente una semplice addizione. Tuttavia, i due tempi di consegna previsti non sono numeri; sono distribuzioni di probabilità. Quindi, dobbiamo combinare queste due distribuzioni di probabilità per ottenere una terza distribuzione di probabilità, che è la distribuzione di probabilità per il tempo di consegna totale. Si scopre che se facciamo l’assunzione che i due tempi di consegna, il tempo di produzione e il tempo di trasporto, siano indipendenti, l’operazione che possiamo fare per eseguire questa somma di variabili casuali è semplicemente una convoluzione unidimensionale. Può sembrare complesso, ma in realtà non è così complesso. Quello che ho implementato, e che puoi vedere sullo schermo, è l’implementazione di una convoluzione unidimensionale tra un vettore che rappresenta l’istogramma delle probabilità del tempo di produzione (A) e l’istogramma associato alle probabilità del tempo di trasporto (B). Il risultato è il tempo totale, che è la somma di quei tempi di consegna probabilistici. Se si utilizza la notazione di comprensione dei tensori, questo può essere scritto in un algoritmo molto compatto e di una sola riga.
Ora, se torniamo alla notazione Big O che ho introdotto in precedenza in questa lezione, vediamo che abbiamo fondamentalmente un algoritmo quadratico. È Big O di N^2, con N che rappresenta la dimensione caratteristica degli array A e B. Come ho già detto, le prestazioni quadratiche sono un punto dolente per i problemi di previsione. Quindi, cosa possiamo fare per affrontare questo problema? Prima di tutto, dobbiamo considerare che si tratta di un problema di supply chain e che abbiamo la legge dei piccoli numeri che possiamo sfruttare a nostro vantaggio. Come abbiamo discusso nella lezione precedente, le supply chain riguardano principalmente piccoli numeri. Se stiamo considerando i tempi di consegna, possiamo ragionevolmente assumere che quei tempi di consegna saranno inferiori, diciamo, a 400 giorni. Questo è già un periodo piuttosto lungo per questo istogramma di probabilità.
Quindi, quello che ci rimane è un Big O di N^2, ma con N inferiore a 400. 400 può essere piuttosto grande, poiché 400 volte 400 fa 160.000. È un numero significativo e ricorda che l’aggiunta a questa distribuzione di probabilità è un’operazione molto basilare. Appena iniziamo a fare previsioni probabilistiche, vorremo combinare le nostre previsioni in vari modi e molto probabilmente finiremo per fare milioni di queste convoluzioni, semplicemente perché fondamentalmente queste convoluzioni non sono altro che un’aggiunta glorificata proiettata nel campo delle variabili casuali. Pertanto, anche se abbiamo limitato N a essere inferiore a 400, è di grande interesse portare l’accelerazione hardware sul tavolo, ed è esattamente ciò che possiamo ottenere con la comprensione dei tensori.
La cosa fondamentale da ricordare è che non appena si può scrivere quell’algoritmo, si desidera sfruttare ciò che si sa sui concetti di supply chain per chiarire le ipotesi applicabili e quindi sfruttare gli strumenti che si hanno per ottenere l’accelerazione hardware.
Ora, parliamo delle tecniche meta. Le tecniche meta sono di grande interesse perché possono essere stratificate su algoritmi esistenti e quindi, se si ha un algoritmo, c’è la possibilità di utilizzare una di queste tecniche meta per migliorarne le prestazioni. La prima intuizione chiave è la compressione, semplicemente perché dati più piccoli significano un elaborazione più veloce. Come abbiamo visto nella lezione precedente, non abbiamo un accesso uniforme alla memoria. Se si desidera accedere a più dati, è necessario accedere a diversi tipi di memoria fisica e, man mano che la memoria cresce, si passa a tipi di memoria molto meno efficienti. La cache L1 all’interno del processore è molto piccola, circa 64 kilobyte, ma è molto veloce. La RAM, o memoria principale, è diverse centinaia di volte più lenta di questa piccola cache, ma è possibile avere letteralmente un terabyte di RAM. Pertanto, è di grande interesse assicurarsi che i dati siano il più piccoli possibile, poiché questo renderà quasi inevitabilmente i vostri algoritmi più veloci. Ci sono una serie di trucchi che è possibile utilizzare a tal proposito.
Innanzitutto, è possibile pulire e sistemare i dati. Questo è il campo del software aziendale. Quando si ha un algoritmo che viene eseguito su dati, spesso ci sono molti dati inutilizzati che non contribuiscono alla soluzione di interesse. È essenziale assicurarsi di non finire con i dati di interesse che vengono intercalati con dati che vengono ignorati.
La seconda idea è l’impacchettamento dei bit. Ci sono molte situazioni in cui è possibile impacchettare alcuni flag all’interno di altri elementi, come i puntatori. Potreste avere un puntatore a 64 bit, ma è molto raro che effettivamente abbiate bisogno di un intervallo di indirizzi a 64 bit fino in fondo. Potete sacrificare alcuni bit del vostro puntatore per inserire alcuni flag, il che vi consente di ridurre al minimo i vostri dati con una perdita di prestazioni praticamente nulla.
Inoltre, è possibile regolare la precisione. Hai bisogno di 64 bit di precisione in virgola mobile nella supply chain? È molto raro che effettivamente si abbia bisogno di questa precisione. Di solito, 32 bit di precisione sono sufficienti, e ci sono anche molte situazioni in cui 16 bit di precisione sono sufficienti. Potreste pensare che ridurre la precisione non sia significativo, ma spesso, quando si può dividere la dimensione dei dati per un fattore di due, non si accelera semplicemente l’algoritmo di un fattore di 2; lo si accelera letteralmente di un fattore di 10. L’impacchettamento dei dati produce benefici completamente non lineari in termini di velocità di esecuzione.
Infine, c’è la codifica dell’entropia, che è essenzialmente la compressione. Tuttavia, non si desidera necessariamente utilizzare algoritmi che siano efficienti quanto, diciamo, l’algoritmo utilizzato per un archivio ZIP. Si desidera qualcosa che potrebbe essere un po’ meno efficiente in termini di compressione, ma molto più veloce nell’esecuzione.
La compressione ruota fondamentalmente attorno all’idea che si può scambiare un po’ di utilizzo extra della CPU per ridurre la pressione sulla memoria, e in quasi tutte le situazioni, questo è il trucco di interesse.
Tuttavia, ci sono situazioni in cui si desidera fare esattamente l’opposto: scambiare la memoria per ridurre notevolmente il consumo di CPU. Questo è esattamente ciò che si sta facendo con il trucco della memoizzazione. La memoizzazione è fondamentalmente l’idea che se una funzione viene chiamata molte volte durante l’esecuzione della soluzione e la stessa funzione viene chiamata con gli stessi input, non è necessario ricalcolare la funzione. È possibile registrare il risultato, metterlo da parte (ad esempio, in una tabella hash) e quando si visita nuovamente la stessa funzione, si sarà in grado di verificare se la tabella hash contiene già una chiave associata all’input o se la tabella hash contiene già il risultato perché è stato precomputato. Se la funzione che si sta memoizzando è molto costosa, si può ottenere un enorme aumento di velocità. Dove diventa molto interessante è quando si inizia a utilizzare la memoizzazione non con la memoria principale, come abbiamo visto nella precedente lezione, la DRAM è molto costosa. Diventa molto interessante quando si inizia a mettere i risultati su disco o SSD, che sono economici e abbondanti. L’idea è che si possono scambiare gli SSD in cambio di una riduzione della pressione sulla CPU, che è, in un certo senso, l’opposto esatto della compressione che ho appena descritto.
L’ultima meta-tecnica è l’immutabilità. Le strutture dati immutabili sono fondamentalmente strutture dati che non vengono mai modificate. L’idea è che le modifiche vengano stratificate in cima. Ad esempio, con una tabella hash immutabile, quando si aggiunge un elemento, si restituisce una nuova tabella hash che contiene tutto nella vecchia tabella hash più il nuovo elemento. Il modo molto ingenuo per farlo è fare una copia completa della struttura dati e restituire l’intera copia; tuttavia, è molto inefficiente. La chiave per capire le strutture dati immutabili è che quando si modifica la struttura dati, si restituisce una nuova struttura dati che implementa solo la modifica, ma questa nuova struttura dati ricicla tutte le parti della vecchia struttura dati che non sono state toccate.
Quasi tutte le classiche strutture dati, come liste, alberi, grafi e tabelle hash, hanno le loro controparti immutabili. In molte situazioni, è molto interessante utilizzarle. A proposito, ci sono linguaggi di programmazione moderni che sono andati completamente fino in fondo nell’immutabilità, come Clojure, ad esempio, per coloro che potrebbero essere familiari con questo linguaggio di programmazione.
Perché è molto interessante? Prima di tutto, perché semplifica enormemente la parallelizzazione degli algoritmi. Come abbiamo visto nella precedente lezione, non è possibile trovare un processore che funzioni a 100 GHz per i processori di computer desktop generali. Quello che puoi trovare, però, è una macchina con 50 core, ognuno dei quali funziona a 2 GHz. Se vuoi sfruttare questi molti core, devi parallelizzare la tua esecuzione, e quindi la tua parallelizzazione è a rischio di bug molto fastidiosi chiamati race condition. Diventa molto difficile capire se l’algoritmo che hai scritto è corretto o meno perché potresti avere vari processori che, contemporaneamente, cercano di scrivere sulla stessa porzione di memoria del computer.
Tuttavia, se hai strutture dati immutabili, questo non succede mai per design, proprio perché una volta che una struttura dati viene presentata, non cambierà mai, solo emergerà una nuova struttura dati. Pertanto, puoi ottenere un enorme aumento delle prestazioni con il percorso immutabile proprio perché puoi implementare più facilmente versioni parallele dei tuoi algoritmi. Tieni presente che di solito il collo di bottiglia per l’implementazione di un miglioramento delle prestazioni algoritmiche è il tempo necessario per implementare effettivamente gli algoritmi. Se hai qualcosa che, per design, ti consente di applicare una sorta di principio di concorrenza senza paura, puoi effettivamente implementare miglioramenti delle prestazioni algoritmiche molto più velocemente, con meno risorse in termini del numero di programmatori coinvolti. Un altro importante vantaggio delle strutture dati immutabili è che facilitano notevolmente il debug. Quando modifichi distruttivamente una struttura dati e incontri un bug, potrebbe essere molto difficile capire come sei arrivato lì. Con un debugger, può essere un’esperienza piuttosto spiacevole individuare il problema. La cosa interessante delle strutture dati immutabili è che le modifiche non sono distruttive, quindi puoi vedere la versione precedente della tua struttura dati e comprendere più facilmente come sei arrivato al punto in cui si verifica un comportamento non corretto.
Per concludere, algoritmi migliori possono sembrare superpoteri. Con algoritmi migliori, ottieni di più dall’hardware di calcolo stesso, e questi vantaggi sono indefiniti. È uno sforzo unico, e poi hai un vantaggio indefinito perché hai accesso a capacità di calcolo superiori, considerando la stessa quantità di risorse di calcolo dedicate a un determinato problema di supply chain di interesse. Credo che questa prospettiva offra opportunità per miglioramenti massicci nella gestione della supply chain.
Se guardiamo a un campo completamente diverso, come i videogiochi, hanno stabilito le proprie tradizioni algoritmiche e scoperte dedicate all’esperienza di gioco. Le straordinarie grafiche che si possono sperimentare con i moderni videogiochi sono il prodotto di una comunità che ha passato decenni a ripensare l’intero stack algoritmico per massimizzare la qualità dell’esperienza di gioco. La prospettiva nel gaming non è avere un modello 3D corretto da un punto di vista fisico o scientifico, ma massimizzare la qualità percepita in termini di esperienza grafica per il giocatore, e hanno ottimizzato gli algoritmi per ottenere risultati sorprendenti.
Credo che questo tipo di lavoro sia appena iniziato per le supply chain. Il software di gestione della supply chain aziendale è bloccato, e secondo la mia percezione, non stiamo utilizzando nemmeno l'1% di ciò che l’hardware di calcolo moderno può fare per noi. La maggior parte delle opportunità è ancora da venire e può essere catturata attraverso algoritmi, non solo algoritmi di supply chain come algoritmi di routing dei veicoli, ma rivedendo gli algoritmi classici da una prospettiva di supply chain per ottenere miglioramenti di velocità massicci lungo il percorso.
Ora, darò un’occhiata alle domande.
Domanda: Hai parlato delle specificità della supply chain, come i numeri ridotti. Quando sappiamo in anticipo di avere numeri ridotti nelle nostre decisioni potenziali, che tipo di semplificazione comporta? Ad esempio, quando sappiamo che possiamo ordinare al massimo uno o due container, puoi pensare a qualche esempio concreto di come ciò influenzi il livello di granularità delle previsioni olistiche che verranno utilizzate per calcolare la funzione di ricompensa dello stock?
Prima di tutto, tutto ciò che ho presentato oggi è in produzione presso Lokad. Tutte queste intuizioni, in un modo o nell’altro, sono molto applicabili alla supply chain perché sono in produzione presso Lokad. Devi renderti conto che ciò che ottieni dal software moderno è qualcosa che non è stato ottimizzato per sfruttare al massimo l’hardware di calcolo. Pensa solo che, come ho presentato nella mia ultima lezione, oggi abbiamo computer che sono mille volte più potenti dei computer che avevamo qualche decennio fa. Funzionano mille volte più velocemente? No. Possono affrontare problemi molto più complicati di quelli che avevamo qualche decennio fa? No. Quindi non sottovalutare il fatto che ci sono potenzialità molto grandi per il miglioramento.
Il bucket sort che ho presentato in questa lezione è un semplice esempio. Ci sono operazioni di ordinamento ovunque nella supply chain, e a mia conoscenza è molto raro che ci sia un software aziendale che sfrutti algoritmi specializzati che si adattano bene alle situazioni della supply chain. Ora, quando sappiamo di avere uno o due container, ne approfittiamo presso Lokad? Sì, lo facciamo sempre, e ci sono un sacco di trucchi che possono essere implementati a quel livello.
I trucchi sono di solito a un livello inferiore, e i benefici si propagano alla soluzione complessiva. Devi pensare a scomporre i problemi di riempimento dei container in tutte le loro sotto-parti. Puoi ottenere vantaggi applicando le idee e i trucchi che ho presentato oggi a un livello inferiore.
Ad esempio, di quale precisione numerica hai bisogno se stiamo parlando di container? Forse numeri a 16 bit con solo 16 bit di precisione potrebbero essere sufficienti. Questo rende i dati più piccoli. Quanti prodotti distinti stiamo ordinando? Forse stiamo ordinando solo qualche migliaio di prodotti distinti, quindi possiamo usare il bucket sort. La distribuzione di probabilità è un numero inferiore e più piccolo, quindi in teoria abbiamo istogrammi che possono andare da zero unità, una unità, tre unità, fino all’infinito, ma andiamo all’infinito? No, non lo facciamo. Forse possiamo fare alcune supposizioni intelligenti sul fatto che è molto raro che ci troveremo di fronte a un istogramma in cui superiamo le 1.000 unità. Quando abbiamo questo, possiamo fare delle approssimazioni. Non è necessario avere una precisione di 2 unità se stiamo gestendo un container che contiene 1.000 unità. Possiamo fare delle approssimazioni e avere un istogramma con bucket più grandi e cose del genere. Non si tratta tanto, direi, di introdurre principi algoritmici come la comprensione dei tensori, che sono incredibili perché semplificano tutto in modo molto interessante. Tuttavia, la maggior parte degli acceleratori algoritmici alla fine si traducono in un algoritmo più veloce ma leggermente più complicato. Non è necessariamente più semplice perché di solito l’algoritmo più semplice è anche un po’ inefficiente. Un algoritmo più appropriato per un caso potrebbe richiedere un po’ più di tempo per essere scritto e potrebbe essere più complesso, ma alla fine funzionerà più velocemente. Questo non è sempre il caso, come abbiamo visto con le ricette magiche, ma quello che volevo mostrare è che dobbiamo rivedere i blocchi fondamentali di ciò che stiamo facendo per costruire effettivamente software aziendale.
Domanda: In che misura queste intuizioni sono implementate nei fornitori di ERP, APS e nei migliori della categoria come GTA?
La cosa interessante è che queste intuizioni sono fondamentalmente, per la maggior parte, completamente incompatibili con il software transazionale. La maggior parte del software aziendale è costruito attorno a un nucleo che è un database transazionale, e tutto viene canalizzato attraverso il database. Questo database non è un database specifico per la supply chain; è un database generico che dovrebbe essere in grado di gestire tutte le possibili situazioni che puoi immaginare, dalla finanza alla computazione scientifica, ai record medici e altro ancora.
Il problema è che se il software che stai guardando ha un database transazionale al suo nucleo, allora le intuizioni che ho proposto non possono essere implementate per design. È un po’ game over. Se guardi ai videogiochi, quanti videogiochi sono costruiti su un database transazionale? La risposta è zero. Perché? Perché non puoi avere una buona performance grafica implementata su un database transazionale. Non puoi fare grafica al computer in un database transazionale.
Un database transazionale è molto bello; ti dà la transazionalità, ma ti blocca in un mondo in cui quasi tutti gli speed-up algoritmici che puoi pensare semplicemente non possono essere applicati. Credo che quando iniziamo a pensare agli APS, non ci sia nulla di avanzato in questi sistemi. Sono bloccati nel passato da decenni ormai, e sono bloccati perché al centro del loro design sono completamente progettati attorno a un database transazionale che impedisce loro di applicare qualsiasi intuizione emersa dal campo degli algoritmi negli ultimi probabilmente quattro decenni.
Questo è il nocciolo del problema nel campo del software aziendale. Le decisioni di design che prendi nel primo mese di progettazione del tuo prodotto ti perseguitano per decenni, essenzialmente fino alla fine dei tempi. Non puoi fare un upgrade una volta che hai deciso un design specifico per il tuo prodotto; sei bloccato con esso. Proprio come non puoi semplicemente ristrutturare una macchina per farla diventare una macchina elettrica, se vuoi avere una macchina elettrica molto buona, ristrutturerai completamente la macchina intorno all’idea che il motore di propulsione sarà elettrico. Non si tratta solo di sostituire il motore e dire: “Ecco una macchina elettrica.” Non funziona così. Questo è uno di quei principi di design fondamentali in cui una volta che ti sei impegnato a produrre una macchina elettrica, devi ripensare tutto intorno al motore in modo che sia adatto. Purtroppo, gli ERP e gli APS che sono molto centrati sul database non possono utilizzare nessuna di queste intuizioni, mi dispiace. È sempre possibile avere una bolla isolata in cui beneficierai di questi trucchi, ma sarà un add-on aggiunto; non arriverà mai al nucleo.
Riguardo alle impressionanti capacità di Blue Yonder, per favore abbiate pazienza, poiché Lokad è un concorrente diretto di Blue Yonder, ed è difficile per me essere completamente imparziale. Nel mercato del software aziendale, devi fare affermazioni ridicolmente audaci per rimanere competitivo. Non sono convinto che ci sia alcuna sostanza in nessuna di quelle affermazioni. Metto in discussione la premessa che chiunque in questo mercato abbia qualcosa che possa essere considerato impressionante.
Se vuoi vedere qualcosa di sorprendente e ultra-impressionante, guarda l’ultima demo per l’Unreal Engine o gli algoritmi specializzati per i videogiochi. Considera la grafica al computer sull’hardware di prossima generazione PlayStation 5; è assolutamente sbalorditiva. Abbiamo qualcosa di simile in campo di software aziendale? Per quanto riguarda Lokad, ho un’opinione super di parte, ma guardando il mercato in modo più generale, vedo un oceano di persone che cercano di sfruttare al massimo i database relazionali da decenni. A volte portano altri tipi di database, come i database a grafo, ma questo perde completamente il punto delle intuizioni che ho presentato. Non fornisce nulla di sostanziale per offrire valore al mondo della supply chain.
Il messaggio chiave qui per il pubblico è che è una questione di design. Dobbiamo assicurarci che le decisioni iniziali che sono state prese nel design del tuo software aziendale non siano il tipo di cose che, per design, impediscono l’uso di queste classi di tecniche fin dall’inizio.
La prossima lezione si terrà tra tre settimane, mercoledì alle 15:00 ora di Parigi. Sarà il 13 giugno e rivedremo il terzo capitolo, che riguarda il personale della supply chain, i tratti di personalità sorprendenti e le aziende immaginarie. La prossima volta parleremo di formaggio. Ci vediamo allora!
