Risorse Computazionali in supply chain - Ep 167

00:00:00 Introduzione alle risorse computazionali nella supply chain
00:02:21 Importanza delle risorse computazionali nella supply chain
00:07:04 Simpatia meccanica nel contesto della supply chain
00:09:38 Decisioni con l’hardware informatico
00:12:42 L’illusione dell’esperienza senza profondità
00:13:59 Dipendenza moderna della supply chain dall’informatica
00:18:32 Impatto della velocità dell’hardware sulle decisioni
00:21:40 Le inefficienze del software aumentano i costi
00:24:42 Proprietà e limitazioni dei database transazionali
00:27:59 L’aumento dei costi del cloud a causa dell’inefficienza
00:30:09 Ricette software più semplici ed economiche
00:32:40 Estremo spreco di risorse computazionali
00:36:14 Progresso hardware vs ritardo software
00:40:48 Importanza della conoscenza nella selezione dei fornitori
00:45:15 Conoscenza teorica vs pratica
00:50:00 Ordini di grandezza nell’efficienza dei computer
00:54:33 Considerazioni sulle prestazioni nel reintegro dell’inventario
00:56:18 Processo iterativo per la qualità dei risultati
00:58:50 La disruption richiede una reingegnerizzazione
01:00:18 Prossimi passi per i professionisti
01:02:17 Pagare per le inefficienze dei fornitori
01:05:04 Impatto finanziario delle decisioni
01:07:16 La mancanza di comprensione dei concorrenti
01:08:40 Osservazioni finali

Riepilogo

In un recente episodio di LokadTV, Conor Doherty, Head of Communication presso Lokad, ha conversato con Joannes Vermorel, CEO di Lokad, riguardo al ruolo critico delle risorse computazionali nell’ottimizzazione della supply chain. Vermorel ha sottolineato la necessità di comprendere sia l’hardware che il software per prendere decisioni informate sulla supply chain. Ha paragonato questa conoscenza fondamentale a una consapevolezza geografica di base, essenziale per prevenire problemi e garantire decisioni efficaci. Vermorel ha evidenziato che, sebbene i computer siano strumenti per meccanizzare le decisioni, è cruciale comprenderne capacità e limitazioni. Questa comprensione si estende ai paradigmi di programmazione, garantendo che i professionisti possano ottimizzare le risorse e ottenere risultati migliori.

Riepilogo Esteso

In un recente episodio di LokadTV, Conor Doherty, Head of Communication presso Lokad, ha intrapreso una discussione stimolante con Joannes Vermorel, CEO e fondatore di Lokad, una società software francese specializzata nell’ottimizzazione predittiva della supply chain. La conversazione ha esplorato il complesso mondo delle risorse computazionali all’interno della supply chain, un argomento che va ben oltre il semplice utilizzo dei computer. Richiede una comprensione sfumata di come queste macchine operino in modo ottimale, un concetto che Vermorel definisce “mechanical sympathy.”

Doherty ha aperto la discussione evidenziando l’ampio ambito delle risorse computazionali, che comprendono sia l’hardware che il software. Ha chiesto a Vermorel una definizione operativa, il quale ha spiegato che le risorse computazionali includono tutte le classi di hardware che costituiscono un computer moderno. Questa classificazione, sebbene in parte arbitraria, si è evoluta negli ultimi 70 anni, portando a categorie distinte come le CPU e la memoria, ognuna delle quali serve a scopi specifici nell’ecosistema computazionale.

Vermorel ha sottolineato l’importanza di queste risorse nel contesto della gestione della supply chain. Ha sostenuto che, se accettiamo il presupposto che le decisioni sulla supply chain vengano prese al meglio con l’ausilio dei computer, allora diventa cruciale comprendere l’hardware che facilita questi calcoli. Questa comprensione non riguarda solo la conoscenza dei componenti fisici, ma anche la comprensione delle classi più ampie di dispositivi e delle loro capacità computazionali.

Doherty ha poi cercato di sintetizzare queste informazioni per i professionisti della supply chain, chiedendo come dovrebbero integrare questa conoscenza nelle loro operazioni quotidiane. Vermorel ha chiarito che i computer non sono intrinsecamente bravi a prendere decisioni; sono semplicemente i migliori strumenti disponibili per meccanizzare i processi decisionali. Questa meccanizzazione, che ha guidato il progresso per secoli, si sta ora estendendo ai lavori impiegatizi grazie all’uso dei computer.

Vermorel ha paragonato la conoscenza fondamentale delle risorse computazionali alla conoscenza geografica di base. Proprio come sapere dove si trovano i paesi su una mappa è considerato essenziale, comprendere le basi dell’hardware informatico è fondamentale per i professionisti della supply chain. Questa conoscenza aiuta a prevenire una serie di potenziali problemi e garantisce che le decisioni siano prese con una chiara comprensione dell’infrastruttura computazionale sottostante.

Doherty ha ulteriormente sondato la profondità di questa conoscenza fondamentale, chiedendo se riguardasse il sapere cose semplici come la posizione di una porta USB o concetti più complessi come il funzionamento di un SSD. Vermorel ha risposto che si tratta più di comprendere le astrazioni e le categorie stabili di problemi che sono rimaste costanti nell’informatica per decenni. Tra questi si includono la memoria, l’archiviazione, la larghezza di banda, il calcolo aritmetico e i processi di input/output.

La conversazione poi si è spostata su come questa conoscenza fondamentale si traduca in decisioni migliori. Vermorel ha spiegato che senza una comprensione di base dell’hardware, i processi decisionali possono sembrare quasi magici, rendendo difficile valutare se un metodo sia adatto all’hardware disponibile. Ha utilizzato l’analogia della scelta di un’auto per illustrare questo concetto. Proprio come scegliere un’auto richiede di comprendere il suo uso previsto, selezionare le risorse computazionali richiede la conoscenza delle loro capacità e limitazioni.

Vermorel ha anche toccato il tema dell’importanza dei paradigmi di programmazione e di come essi si inseriscano nel processo decisionale. Ha osservato che, sebbene i casi d’uso specifici possano non essere sempre evidenti, possedere una conoscenza fondamentale di concetti come l’analisi statica, la programmazione array e il controllo delle versioni è cruciale. Questa conoscenza aiuta i professionisti a evitare di “barcollare nel buio” e garantisce che possano prendere decisioni informate sugli strumenti computazionali che utilizzano.

In conclusione, Vermorel ha sottolineato che le pratiche moderne della supply chain dipendono fortemente dall’hardware informatico. Anche le aziende che si considerano a bassa tecnologia fanno ampio uso dei computer, sia per algoritmi complessi che per strumenti semplici come Excel. Pertanto, possedere una conoscenza fondamentale delle risorse computazionali non è solo vantaggioso, ma essenziale per una gestione efficace della supply chain. Questa conoscenza consente ai professionisti di prendere decisioni informate, ottimizzare le loro risorse computazionali e, in ultima analisi, ottenere risultati migliori per le loro organizzazioni.

Trascrizione Completa

Conor Doherty: Bentornati su LokadTV. Oggi, Joannes e io parleremo delle risorse computazionali nella supply chain. Come sentirete, si tratta di molto più che sapere semplicemente come usare un computer. Piuttosto, richiede una buona comprensione di come esso operi al meglio. Questo viene chiamato mechanical sympathy, e come discuteremo, una buona mechanical sympathy può tradursi in un uso migliore delle risorse computazionali e, in definitiva, in decisioni migliori. Ora, come sempre, se vi piace ciò che ascoltate, considerate l’idea di iscrivervi al nostro canale YouTube e di seguirci su LinkedIn. Con questo, vi do il via alla conversazione di oggi.

Quindi, Joannes, le risorse computazionali nella supply chain sono un concetto molto ampio. Comprendono sia l’hardware che il software. Perciò, ai fini della conversazione di oggi, e considerando che il pubblico è della supply chain, qual è una buona definizione operativa di risorse computazionali?

Joannes Vermorel: Le risorse computazionali sono un termine generico che copre tutte le classi di hardware che costituiscono un computer moderno. Al giorno d’oggi, la separazione tra queste classi è un po’ arbitraria, ma solo un po’. Non esiste nulla in natura che indichi l’esistenza di una classe di cose che dovremmo chiamare CPU (unità centrali di elaborazione) e un’altra classe di dispositivi che dovremmo chiamare memoria e simili. È una co-evoluzione del design dei computer e del ruolo del mercato che ha plasmato alcune nicchie, portando alla nascita di aziende che, a loro volta, hanno sviluppato dispositivi davvero competitivi per scopi specifici. È così che si è verificata questa evoluzione. Ora, a 70 anni dall’introduzione dei computer, disponiamo di classi ben definite di dispositivi di calcolo che non fanno tutto in maniera integrata. Sono come componenti nel processo di calcolo.

Ora, perché è importante avere tutto ciò? Quando mi riferisco alle risorse computazionali, intendo in senso lato l’hardware, ma implicito anche la classe di dispositivi e ciò che offrono per eseguire calcoli. Perché è importante per la supply chain? Perché se consideriamo la supply chain come un esercizio decisionale e se procediamo con la fede che questi calcoli verranno eseguiti meglio dai computer, allora questa è letteralmente la componente fisica che porterà a termine tali calcoli. Dopotutto, questo atto di fede è solo modesto. I computer si sono dimostrati piuttosto capaci in questi giorni. Tuttavia, tutto inizia da questa visione che tutte queste decisioni, quei milioni di decisioni che una supply chain significativa deve prendere, saranno in definitiva eseguite in un modo o nell’altro da un computer.

Pertanto, se iniziamo a pensarci, dovremmo prestare un po’ più di attenzione a questo livello hardware. La situazione è diventata molto più complessa negli ultimi quattro decenni. I computer continuano a progredire, ma in modi molto più complessi e meno intuitivi rispetto a quanto accadeva fino alla fine degli anni ‘90.

Conor Doherty: Bene, per riassumere, i computer sono bravi a prendere decisioni. Ma come si inserisce questo discorso per un professionista della supply chain che ascolta? Qual è il messaggio principale o la visione d’insieme per loro?

Joannes Vermorel: Innanzitutto, direi che i computer non sono particolarmente bravi a prendere decisioni. Sono semplicemente gli strumenti a nostra disposizione, e attualmente non abbiamo alcuna opzione valida per meccanizzare i processi decisionali. È un po’ un atto di fede. Perché vogliamo meccanizzare? Perché la meccanizzazione ha guidato il progresso negli ultimi due, forse anche tre secoli. Nel XX secolo, è stata la meccanizzazione dei lavori manuali con miglioramenti di produttività assolutamente sbalorditivi, dell’ordine di 100 volte. Ora, nel XXI secolo, stiamo vedendo esattamente lo stesso fenomeno per i lavori impiegatizi, e ciò sta accadendo grazie ai computer. Potremmo immaginare un universo parallelo in cui accadesse con altri ambiti, ma per ora, la nostra migliore opzione sono i computer.

Ora, perché è importante? Direi che dobbiamo considerare le risorse computazionali e l’hardware informatico come parte della conoscenza fondamentale. Quando è stata l’ultima volta che ti è stato utile sapere dove si trova il Canada sulla mappa del mondo? Quando è stata l’ultima volta che ti è stato utile sapere che la Russia non confina con il Brasile? Queste sono cose che, quotidianamente, potrebbero non sembrare di grande utilità, come ad esempio conoscere le nozioni di base della geografia mondiale. Tuttavia, se chiedessi alla stragrande maggioranza di questo pubblico, direbbero che è importante. Cosa penseresti di qualcuno che non sarebbe in grado di localizzare né la Cina, né il Canada, né la Russia su una mappa del mondo? Sarebbe qualcosa di molto strano, e probabilmente non ti fideresti di quella persona per molti ruoli nella tua organizzazione.

Quindi, si può considerare in parte come una curiosità, ma è anche una conoscenza fondamentale. Se non ne sai nulla, questo creerà problemi. Che tipo di problemi? Dipende molto dalle specificità della situazione, dell’azienda e del settore. Ma ci si può aspettare una serie di problemi. Credo che la conoscenza dell’hardware informatico e delle risorse computazionali rientri perfettamente in questa categoria di conoscenza fondamentale di cui i professionisti della supply chain dovrebbero essere consapevoli. Dovrebbero possedere una buona mechanical sympathy, un termine preso dalla Formula Uno, riguardo a questi aspetti.

Conor Doherty: Beh, mi piace l’analogia che usi, e cercherò di utilizzarla per approfondire questo punto. Se dici che la conoscenza fondamentale consiste nel sapere che il Brasile e la Russia non condividono un confine, questa è una granularità della conoscenza geografica. Un’altra granularità è sapere quante capitali ha il Sudafrica. Questi sono livelli qualitativamente diversi o granularità diverse della consapevolezza geografica. Per applicare questa differenza all’hardware o alle risorse computazionali, quando parli di conoscenza di base, si intende sapere dove si trova la porta USB del mio mouse, o si intende capire come funziona un SSD? Qual è l’ordine di grandezza della conoscenza in questo contesto?

Joannes Vermorel: Sto parlando più delle astrazioni. Esiste una quantità infinita di curiosità sull’hardware informatico. Non si tratta di conoscere ogni singolo dispositivo e i suoi prezzi. Se sei un appassionato, puoi divertirti a leggere a riguardo, e io lo faccio. Ma fondamentalmente si tratta di quelle classi di risorse molto grandi e ben consolidate. Questo è in parte dipendente dall’architettura, ma queste architetture sono state molto stabili per almeno cinque decenni, quindi ci si può aspettare che continui in questo modo.

Di cosa stiamo parlando? Stiamo parlando di cose come la memoria, la memoria volatile, l’archiviazione persistente, la larghezza di banda, il calcolo aritmetico, l’input e l’output (I/O), il throughput, la latenza. Tutti questi aspetti sono stati motivo di preoccupazione e hanno avuto categorie di problemi che sono rimaste stabili per molti decenni. È questo che intendo per avere questa conoscenza di base, per comprendere quali sono le categorie di problemi e l’hardware informatico corrispondente. Come si combinano tutti insieme per far funzionare un computer moderno?

Se facciamo un passo indietro in termini di livelli, in definitiva desideri che i tuoi processi decisionali vengano calcolati grazie a questo hardware di calcolo. Se non hai alcuna conoscenza di ciò che accade a livello hardware, tutto ciò è completamente magico. Quali sono le probabilità che tu possa comprendere se un metodo sia adatto per l’hardware che possiedi o meno? Non sto parlando di una comprensione dettagliatissima, ma solo di una comprensione molto basilare se funzionerà o meno.

Conor Doherty: Ad esempio, usi la frase… Scusa, lascia che faccia un passo indietro. Hai nominato alcuni paradigmi di programmazione. Credo che sia stato in una delle tue lezioni. Hai parlato di paradigmi di programmazione, analisi statica, RA programming, programmazione differenziale, controllo della versione, persistenza, tutti questi concetti. La mia domanda è: come si integrano per prendere le decisioni migliori di cui parli?

Joannes Vermorel: Questa è conoscenza di base, quindi non aspettarti casi d’uso molto specifici da parte mia, proprio come la geografia di base. Quando è stata l’ultima volta che hai assolutamente avuto bisogno di saperlo? Probabilmente mai. È ovunque. Il problema è che se ti mancano dei livelli di conoscenza fondamentale, stai avanzando a tentoni nel buio. Non ti accorgi nemmeno di essere nel buio. Non realizzi nemmeno quanta cosa non capisci. Questo è davvero il punto che intendo.

Facciamo un passo indietro. Vuoi generare quelle decisioni con un computer. Questo significa che sceglierai dei fornitori, probabilmente parecchi. Comprerai o affitterai risorse di calcolo dal cloud. Puoi delegare tutto alla tua IT, ma perché l’IT dovrebbe essere bravissima a scegliere l’hardware per qualcosa di cui non sanno nulla? Ad esempio, se ti dicessi, “Caro IT, per favore scegli per me la migliore auto,” non specificata. Ok, va bene. Allora, l’IT dice, “Va bene, allora ti procuriamo una Formula One.” E tu rispondi, “Ma in realtà, desidero guidare nelle dune lungo la spiaggia.” Poi la Formula One si rivela essere un veicolo completamente scarso perché assolutamente non progettato per guidare sulla sabbia.

Se tutto quello che mi dici è di prendere qualcosa di buono, prenderanno qualcosa di fondamentalmente buono, come una Formula One. È una buona auto? Sì, è una buona auto per un uso specifico. Ma se dici, “Voglio un’auto in cui posso sistemare la mia famiglia di otto persone,” quella sarà una definizione molto diversa di ciò che è buono. Abbiamo l’illusione che quando si tratta di IT, hardware di calcolo e tecnologie informatiche in generale, si parli di esperti. Proprio come scegliere un’auto, io non sono un esperto di automobili, quindi dirò semplicemente al reparto auto di procurarmi una buona auto e basta. Quelle persone hanno così tante opzioni su cosa significhi essere buono da scegliere qualcosa a caso. Poi ti puoi lamentare, “Oh, ma il costo di questa Formula One è stravagante. Non posso nemmeno mettere una seconda persona nell’auto, e dove voglio guidare, ovvero sulla sabbia, non farà nemmeno 10 metri prima che le ruote perdano trazione a causa della bassa altezza da terra.” Se fosse un’auto, la gente concorderebbe sul fatto che sarebbe ridicolo.

Ma quando parliamo di roba informatica, nella maggior parte delle aziende, alla gente sembra del tutto accettabile essere disinteressati al caso. Anche se, ancora una volta, torno alla pratica della supply chain. Una pratica moderna della supply chain è estremamente dipendente da questo hardware di calcolo. Le supply chain sono state digitalizzate decenni fa, e persino le aziende che pensano di essere a bassa tecnologia fanno enormemente affidamento sui computer, anche se solo per Excel.

Se dipendi quotidianamente da quegli strumenti, dipendi da essi in modo molto elaborato. Ad esempio, io dipendo dalla disponibilità dell’acqua, ma non ho bisogno di sapere nulla sull’approvvigionamento dell’acqua. Questo è corretto perché l’acqua come prodotto è estremamente semplice. È chimicamente semplice, e quando dici acqua del rubinetto, ti aspetti il 99,99% di H2O più un pochino di minerali e un pizzico di cloro per motivi igienici, e basta.

Quindi vedi, l’acqua e la temperatura dovrebbero essere qualcosa come tra i 10 e i 20 gradi, e basta. Quindi è qualcosa di estremamente semplice. Per questo motivo non hai, beh, il livello di astrazione che dice, “Prendo l’acqua del rubinetto ed è buona da bere.” Posso permettermi di non sapere nulla su ciò che accade a monte. Ma il problema, ed è qui che arrivo al punto delle risorse di calcolo, è che le risorse di calcolo sono multidimensionali. Sai, non è qualcosa di semplice come l’acqua. È molto più come un’auto. Ci sono così tanti tipi diversi di auto, così tanti modi diversi in cui potresti definire una buona auto.

Se dico, “Cos’è l’acqua buona?” sai, tranne se stai facendo esperimenti molto, molto specifici, come processi industriali che richiedono acqua ultrapura e simili, per praticamente tutte le situazioni che incontrerai nella vita, l’acqua del rubinetto base è tutto ciò di cui hai bisogno. Quindi non devi sapere nulla a riguardo perché, ancora una volta, stai trattando con un prodotto estremamente semplice. Ma se stai trattando con un prodotto che è multidimensionale, come un’auto, allora devi sapere una cosa o due sull’auto se vuoi acquistarla.

Quindi, ancora una volta, se passiamo ai professionisti della supply chain, risulta che siete estremamente dipendenti dalle risorse di calcolo per fare un sacco di cose. Queste cose diventeranno ancora più prevalenti in futuro. Cosa vi fa pensare di poter essere completamente ignoranti del livello fisico di tutto ciò?

Conor Doherty: Beh, ci sono alcuni punti, uno dei quali è che le supply chain sono ovviamente molto complesse. Stai cercando di risolvere molte, molte cose, e ciò dipende dal contesto. Ad esempio, forse vuoi che l’auto guidi nel deserto, forse la vuoi far guidare su colline, o in città. Questi sono tutti contesti differenti, ma ci sono comunque proprietà comuni in termini di ciò che almeno pensiamo che le aziende dovrebbero cercare di fare con le loro risorse di calcolo. Puoi, per favore, espandere un po’ su questo?

Joannes Vermorel: Sì, voglio dire, il punto qui è che, ok, vuoi, diciamo, analizzare come base la tua cronologia transazionale. Questo sarebbe qualcosa. Ok, quindi significa che questi dati devono essere archiviati. Quindi, dove verranno archiviati? Che tipo di hardware? Quali saranno le caratteristiche di questo hardware? Se vuoi archiviare i dati e poi accedervi, ha qualche impatto? La risposta è sì, ce l’ha. Solo per darti un’idea molto semplice, consideriamo che tu voglia archiviare questi dati su un disco rotante.

Non importa se è il tuo disco rotante o se è qualcosa che affitti da una piattaforma di cloud computing. Se i dati sono archiviati su un disco che ruota, significa che in media, quando vuoi accedere a un frammento di dati, il disco dovrà ruotare per metà giro affinché tu possa accedere all’area. Sai, è semplicemente perché i dati possono trovarsi ovunque sul disco. Vuoi accedere a un pezzo di dato, in media il disco dovrà ruotare per metà giro.

Ok, bene. Quali sono le conseguenze di ciò? Beh, la conseguenza è: quanto velocemente può ruotare il disco? Beh, un disco solitamente ruota a circa 7.000 giri al minuto, e se è un drive molto sofisticato, potrebbe arrivare a 11.000 o magari 12.000, ma ecco. Quindi, giri al minuto. Ciò significa che, in termini di latenze, dovresti aspettarti qualcosa come 20 millisecondi, o qualcosa del genere, per accedere a un qualsiasi pezzo di dato.

Quindi diresti, “Beh, 20 millisecondi sembrano pochi.” Ma lo sono? Perché 20 millisecondi significano che ogni secondo puoi accedere, se vuoi spostarti sul disco, a solo 50 pezzi diversi di dati al secondo. Se devi spostarti, 50 al secondo non sono tanti. Se devi recuperare milioni, decine di milioni di record, vedi che molto rapidamente questa cosa si trasforma in ritardi pazzeschi, davvero pazzeschi. Ora potresti dire, “Va bene, ma il mio disco può archiviare terabyte di dati.”

Sì, ma se recuperare i dati, a causa del fatto che devi saltare tanto sul disco, impiega giorni, non è per niente buono. Quindi forse posso, sai, prendere molti altri dischi che hanno una capacità minore, e avrò, sai, un throughput maggiore nell’accesso ai dati. Oppure posso anche, sai, usare un’altra classe di storage interamente e optare per SSD, solid state drives, che offrono latenze molto, molto migliori per quegli accessi casuali.

Ma vedi, è proprio questo il tipo di cosa in cui, ancora una volta, se non hai alcuna conoscenza riguardo alle risorse di calcolo e alle classi di hardware che forniscono tali risorse, quel tipo di domande semplicemente non ti verrebbero in mente. E può farti del male? Sai, di nuovo, questa è la domanda. Ciò che non conosci, può farti del male? Direi di sì, perché ancora una volta comprerai molte di quelle cose, sia direttamente che indirettamente.

Le comprerai direttamente se il tuo IT department si limita a comprare risorse di cloud computing, ma le comprerai anche indirettamente se scegli un fornitore di supply chain software. Perché vedi, se scegli un fornitore, stai scegliendo un modo specifico di consumare quelle risorse di calcolo per ottenere il risultato che desideri. E qui il mio messaggio è che se pensi che il fornitore medio di software abbia qualsiasi competenza in questo campo, sei completamente illuso.

La stragrande maggioranza di, ovviamente questa è un’opinione personale, ma direi che la stragrande maggioranza dei miei concorrenti, i concorrenti di Lokad, quando guardi al management e al loro interesse, a grandi linee, non hanno alcun interesse, nessuna simpatia meccanica verso l’hardware di calcolo. E di conseguenza, non dovrebbe sorprendere troppo che il loro software, di conseguenza, sia orribilmente inefficiente. E perché? Beh, torna al fatto che, se non presti alcuna attenzione al tuo hardware, perché dovresti pensare che alla fine il software che svilupperai sopra ne farà un ottimo uso?

Sai, di nuovo, sarebbe proprio come scegliere una Formula One indipendentemente dalla strada su cui vuoi guidare, e poi ti chiedi perché in spiaggia questo sia un veicolo così scarso. Sai, sorpresa, sorpresa, è quello che accade quando non presti alcuna attenzione all’hardware di calcolo.

Quindi, ancora una volta, se vivessimo in un mondo perfetto, potresti fidarti, sai, di consulenti, fornitori di software, e quelle persone avrebbero preso tutte le decisioni giuste per te. Ma si è scoperto che, dato che la stragrande maggioranza dei professionisti della supply chain è completamente ignorante, i fornitori di software possono permettersi di essere altrettanto ignoranti. Perché non dovrebbero esserlo, dopotutto, se i clienti non riescono a notare la differenza al momento dell’acquisto del software o della soluzione? Non importa, intendo, non importa finché non subiscono le conseguenze di questa ignoranza.

Conor Doherty: Bene, quindi prima di tutto, non c’è nulla di male nel prendere una posizione, è proprio quello che facciamo qui. Ma quando dici che, in definitiva, quando le aziende acquistano software da un fornitore, penso tu abbia detto che consumano risorse per ottenere ciò che vogliono o per ottenere ciò che desideri. In definitiva, per essere pratici qui, stiamo parlando di prendere decisioni. Quindi hai dato un po’ di teoria, ma puoi essere un po’ più concreto per le persone curiose? In che modo un migliore utilizzo delle risorse di calcolo, come stai descrivendo, influenza o si traduce in decisioni, scelte prese nel mondo reale?

Joannes Vermorel: Quindi, quando hai decisioni, hai molti, molti modi per creare ricette numeriche che alla fine genereranno questa decisione. Il punto è che se il modo in cui consumi le tue risorse di calcolo è incredibilmente inefficiente, e lascia che faccia un esempio. Se inizi a usare, diciamo, un database relazionale, un database transazionale, un database SQL, la stessa cosa, niente a che fare con il denaro. Infatti, se usi un database transazionale e vuoi eseguire ricette analitiche, ricette numeriche, semplicemente fare qualche tipo di elaborazione numerica, pagherai una tassa di overhead probabilmente di un fattore 100, almeno due ordini di grandezza, se non 300, tre ordini di grandezza.

E perché? È perché questo strato software, lo strato di transazione, ti offre alcune proprietà molto interessanti, ma che non hanno nulla a che fare con il calcolo analitico. Ti offre essenzialmente le quattro proprietà note come ACID: atomicità, consistenza, isolamento, durabilità. Queste cose sono molto utili per i processi transazionali. Garanticono cose come, per esempio, se vuoi dichiarare che un fornitore è stato pagato, non potresti mai trovarti in una situazione in cui il denaro è stato inviato, l’ordine alla banca, ma la fattura del fornitore non è stata contabilizzata, solo perché, per esempio, il sistema informatico si è arrestato a metà dell’operazione.

Quindi, in teoria, potresti trovarti in una situazione in cui hai già emesso l’ordine di bonifico ma non hai registrato il fatto che la fattura di un fornitore è stata saldata. Così, la prossima volta che riavvii il sistema, emetterai un secondo pagamento e pagherai effettivamente il fornitore due volte. È il genere di cosa che può succedere con uno strato di transazione. È molto, molto importante per le operazioni transazionali, dove c’è essenzialmente un conto che viene incrementato e un altro conto, in senso contabile, che viene decrementato. Vuoi che queste cose avvengano logicamente allo stesso tempo in modo da non farle mai disallineare.

Bene, ma se usi questo tipo di paradigma software per costruire le tue risorse analitiche, sarai incredibilmente inefficiente. E a proposito, sorpresa, sorpresa, questo è esattamente ciò che fanno il 99% dei miei concorrenti. Cosa significa in termini di decisioni? Beh, se il modo in cui usi le risorse di calcolo inizia con un overhead di un fattore 100, significa che sei limitato a ricette numeriche molto, molto semplici. Appena hai un minimo di complessità, esaurisci completamente il budget in termini di risorse di calcolo. Ciò significa che i costi aumentano in maniera veramente stravagante molto rapidamente.

Vedi, questo non è un semplice elemento pubblicitario. Se non metti sotto controllo il budget delle tue risorse di calcolo, puoi finire con livelli di spesa folli. Solo per dare un punto di prezzo, molti dei miei colleghi, non concorrenti, colleghi che sarebbero aziende di software as a service che gestiscono pesanti carichi analitici, quando guardo l’S1—l’S1 è un documento che devi pubblicare quando vuoi quotarti in borsa negli Stati Uniti—è molto interessante perché è fondamentalmente un rapporto per gli investitori, per i futuri investitori. Qui puoi vedere la scomposizione delle spese degli ultimi tre, quattro anni.

Le maggiori aziende di software che erano analitiche, come Lokad, non proprio supply chain, possono essere qualsiasi cosa, per esempio, rilevamento delle frodi, elaborazione dei log di sistema, insomma. Di solito, destinavano metà dei loro investimenti alle risorse di cloud computing. Quindi l’ammontare delle spese è molto, molto significativo. Nonostante paghino, sai, abbiano in busta paga ingegneri estremamente costosi e una forza vendita altrettanto onerosa, riescono comunque a destinare metà delle loro spese ai fornitori di cloud computing. Così vedi, l’idea che il costo delle risorse di calcolo sia trascurabile è una completa assurdità per la maggior parte dei venditori di software della categoria analitica come Lokad.

Non sistemi quasi intelligenti, ma piuttosto sistemi di report o di indigenza, quelle spese possono essere molto, molto significative. Quando dico che se sei inefficiente spendi 100 volte di più, puoi notare che se stai già spendendo metà dei tuoi ricavi in risorse di calcolo, spendere 100 volte di più non è nemmeno in discussione. Non è neanche remotamente possibile. Quindi, per rimanere in budget, cosa fai? Beh, aumenti semplicemente il prezzo. È quello che fanno, ma anche in quel caso ci sono dei limiti. Puoi raddoppiare, magari quadruplicare il prezzo, ma non puoi moltiplicarlo per 100.

Quindi la maggior parte dei venditori di software opta per ricette più semplici ed economiche, anche se estremamente semplicistiche e al punto da fare un disservizio ai propri clienti. La realtà è che, come venditori, non possono permettersi qualcosa che potrebbe essere meno disfunzionale perché sarebbe troppo costoso. E perché non possono permetterselo? Perché sono assolutamente incredibilmente spreconi con le loro risorse di calcolo.

Conor Doherty: Beh, mi torna in mente che quando parli e spieghi come ritieni che le risorse di calcolo debbano essere assegnate, lo fai per persegue decisioni fondamentalmente migliori. Nella tua mente, questo è il problema da risolvere. Ma non è necessariamente lo stesso paradigma che tutte le aziende -o meglio, non tutte- applicano. Ad esempio, potresti essere un’azienda che dà la priorità a qualcosa come il perseguimento del livello di servizio o dell’accuratezza previsioni, e questo è l’obiettivo, il sogno irraggiungibile verso cui punti. In che modo l’allocazione delle risorse di calcolo sarebbe diversa in quella situazione? E sentiti libero di commentare.

Joannes Vermorel: Quindi, va bene, ti poni un obiettivo. Qui non sto mettendo in discussione quella parte. Quando dico decisioni migliori, intendo secondo qualsiasi metrica, qualsiasi obiettivo tu abbia deciso. Quindi non importa. Se vuoi un livello di servizio migliore, va bene. Questo è il tuo obiettivo. Ora ti sei fissato un obiettivo e adesso hai a disposizione potenza di calcolo, risorse di calcolo che puoi impiegare per ottenere decisioni migliori in base a quegli obiettivi. Va bene.

Adesso chiarifichiamo qual è il paradigma ambientale per praticamente tutti i miei concorrenti. Il paradigma ambientale è che avrai ingegneri che inizieranno a lavorare su qualcosa, e poi, non appena quella cosa è compatibile con il miglior hardware che il denaro può comprare, smettono di lavorare e iniziano a vendere il prodotto ai clienti. Cosa significa? Significa che, ok, voglio fare il riapprovvigionamento dell’inventario per una rete di vendita al dettaglio. Quindi ho, diciamo, 20 milioni di SKUs. Bene. Inizialmente provo diverse soluzioni, non funzionano, e allora ricorro, diciamo, all’analisi del safety stock, che è estremamente banale in termini di risorse di calcolo.

E poi, poiché il mio sistema è così inefficiente con un hardware di calcolo estremamente costoso, riesco a farlo funzionare. E poi mi fermo e lo vendo al cliente. Allora, quale era il ragionamento alla base di questo paradigma? Perché, in realtà, questo era il paradigma dominante nell’industria del software fino alla fine degli anni ‘90 del secolo scorso. Questo paradigma sostanzialmente affermava che l’hardware di calcolo progrediva in modo esponenziale. L’idea era quindi che ottenessi il miglior hardware che il denaro potesse comprare e, non appena funziona, hai qualcosa che opera, anche se i costi sono insensati, anche se non sfrutti bene le tue risorse di calcolo, non importa.

Perché? Perché hai una progressione esponenziale dell’hardware di calcolo su tutte le metriche. Questo è ciò a cui la gente si riferisce come Legge di Moore, ma in realtà esistevano molte altre leggi per ogni cosa. Tutte le risorse di calcolo miglioravano, tutte le metriche progredivano, ed era proprio una delle idee che rese Microsoft estremamente di successo negli anni ‘90. L’idea è che se funziona, non importa quanto terribile sia la performance, perché tra cinque anni l’hardware di calcolo avrà evoluto così tanto da rendere banali quelle risorse.

Questo funzionava fino alla fine degli anni ‘90, ma da circa l’anno 2000 in poi, in questo ambito, abbiamo intere classi di metriche che non sono migliorate. Per esempio, la latenza tra CPU e memoria non è cambiata praticamente negli ultimi due decenni. Dato che ora siamo limitati dalla velocità della luce, non cambierà nel prossimo futuro prevedibile.

Un altro elemento è, ancora una volta, la velocità della luce. I pacchetti su Internet, su lunghe distanze, ora viaggiano a circa due terzi della velocità della luce, quindi non c’è molto margine per migliorare la velocità dei pacchetti su Internet perché siamo già molto, molto vicini a quella velocità. Possiamo avere più larghezza di banda e quindi poter trasmettere molti più pacchetti, nessun problema, ma in termini di velocità effettiva dei pacchetti, siamo ormai vicinissimi ai limiti della fisica, almeno della fisica come la conosciamo.

Quindi, è proprio questo il tipo di situazione in cui, ancora una volta, questo paradigma, molto diffuso nell’industria del software alla fine degli anni ‘90, era “fai qualcosa che funzioni, poi vendilo e poi non preoccuparti delle performance perché è un’impresa da pazzi.” L’industria, quella dell’hardware, migliorerà tutto così tanto che tutte quelle preoccupazioni sulle performance diventeranno irrilevanti nel giro di pochi anni. Questa era la mentalità.

Curiosamente, abbiamo ancora un bel progresso nell’hardware di calcolo, ma tale progresso è diventato molto sottile. Ci sono ancora progressioni esponenziali, ma lungo direzioni molto specifiche, non tutte le metriche, soltanto alcune. La cosa interessante è che la maggior parte dell’industria del software B2C ha prestato molta attenzione a questo. Ad esempio, l’industria dei videogiochi presta un’enorme attenzione a questi dettagli. Ma quando si tratta di software enterprise, la stragrande maggioranza vive ancora, al 99%, come negli anni ‘90, senza badare a nulla, operando come se, tra cinque anni, il progresso dell’hardware di calcolo avesse reso banale il costo del loro sistema. Non è così.

Infatti, a causa del fatto che la quantità di dati gestiti dalle aziende continua ad aumentare, ci troviamo in una situazione in cui, anno dopo anno, il costo necessario per mantenere operativi i sistemi tende, per la maggior parte dei venditori di software, ad aumentare più rapidamente della diminuzione dei prezzi dell’hardware di calcolo. Così, anno dopo anno, finisci per spendere ancora di più pur mantenendo funzionalmente lo stesso livello di qualità dei tuoi processi decisionali o del supporto a tali processi, se questi ultimi non sono completamente automatizzati.

Conor Doherty: Beh, il progresso dell’hardware o delle tecnologie di calcolo è diventato sottile, credo sia il termine che hai usato. È sottile, non sono più salti esponenziali.

Joannes Vermorel: È in direzioni specifiche, non in dimensioni. Negli anni ‘90, la cosa interessante era che tutto migliorava su tutti i fronti. Non c’era una sola metrica che non progredisse. Oggi, molte metriche non si muovono da letteralmente un decennio.

Se guardi, per esempio, la quantità di calore che un computer riesce a dissipare, il computer deve eliminare quel calore. Puoi usare cablaggi in rame, ventole, puoi fare varie cose per estrarre il calore dall’interno del computer affinché questi componenti non si surriscaldino. Ma abbiamo già raggiunto il limite di ciò che è realizzabile con l’aria. Ci sono limiti che sono stati raggiunti due decenni fa. Puoi usare l’acqua per renderlo un po’ più performante. Se vuoi andare davvero sul superlativo, puoi optare per l’azoto liquido. È piuttosto poco pratico, ma è possibile per dei bei benchmark, ecc.

Quindi, abbiamo raggiunto i limiti. Non abbiamo materiali magici che ci permettano di evacuare il doppio del calore. Voglio dire, potremmo usare magari il diamante. Il diamante è un conduttore di calore fantastico, ma l’idea di avere chilogrammi di diamanti per evacuare il calore è ancora molto lontana. Anche così, ci darebbe solo un modesto incremento rispetto al rame, che è già un eccellente conduttore.

Conor Doherty: Beh, questo in realtà dimostra il mio punto un po’ più chiaramente. Quindi, per concludere il concetto, se…

Okay, in realtà prendo l’esempio che hai appena dato. Quindi, parlavi della differenza tra il filo di rame e i diamanti come conduttori di calore. Ottenere un po’ più di performance dalle proprietà di dispersione del calore di un computer richiederà una comprensione piuttosto sfumata e specializzata dell’ingegneria informatica. Quindi, per tornare all’argomento principale, come si traduce l’incremento della tua conoscenza fondamentale ambientale in una maggiore supply chain performance quando i margini sono così sottili come descrivi?

Joannes Vermorel: No, penso che ancora una volta il punto della conoscenza fondamentale sia che essa chiarisca l’intera situazione. Il tuo reparto IT sta acquistando il tipo giusto di prodotti, almeno in linea generale? Hai qualche idea in merito? Riesci persino a discuterne con il tuo IT? Se non puoi, perché dovresti aspettarti che ciò che acquistano abbia anche un minimo di senso?

Ancora, torna alla Formula 1 per andare in spiaggia. Non ha alcun senso, ma è proprio il tipo di situazione che si verifica quando le persone non hanno alcuna conoscenza di ciò che è in gioco. Quando vuoi scegliere un fornitore, riesci ad avere una discussione intelligente su come stanno consumando le risorse di calcolo per offrirti decisioni migliori o un supporto migliore per le tue decisioni? Stanno consumando quelle risorse in maniera appropriata rispetto all’hardware di calcolo che abbiamo? L’architettura ha senso o assolutamente no?

Ancora, se pensi in termini di un’auto, ci sono tante cose che comprendi intuitivamente. L’aerodinamica, per esempio. Se guardassi un’auto che violasse in maniera massiccia le leggi dell’aerodinamica, penseresti: “Ok, questa cosa avrà un’attrito così immenso con l’aria, il consumo sarà orribile.” Non c’è alternativa. Quindi, vedi, è il tipo di situazione in cui, grazie alla conoscenza fondamentale, tutto diventa istintivo. Non devi necessariamente essere informato che, vedendo un’auto molto bassa, l’aerodinamica sarà buona e che molto probabilmente quell’auto andrà più veloce.

Questa è la questione. Non devi nemmeno riflettere sulle dinamiche dei fluidi in gioco e simili. È intuitivo. È il genere di situazione in cui, se cerchiamo decisioni migliori, riesci a individuare in modo istintivo cosa sia estremamente disfunzionale. Il mio punto è che, dato che il 99,9% dei clienti o dei professionisti della supply chain è completamente all’oscuro della questione, se ci sono pochi nerd in giro, sei una minoranza minuscola. Se sei all’oscuro, ciò significa che, ancora una volta, la reazione dell’ecosistema, dei venditori di software, dei fornitori di soluzioni, dei consulenti, è che non hanno bisogno di prestare attenzione. I loro clienti non prestano attenzione. Perché dovrebbero?

Se vivessi in un paese dove la benzina è gratuita, perché i produttori di auto dovrebbero badare al consumo dei loro veicoli? Per loro, se la benzina è gratuita, significa che è per lo più una questione irrilevante per i clienti. Se i clienti non prestano attenzione, i venditori di auto non lo fanno. Se passiamo ai venditori di software, se i clienti sono incompetenti e non prestano attenzione, perché i fornitori enterprise dovrebbero farlo? La risposta è: beh, non lo fanno. In effetti, non prestano attenzione.

È per questo che, ai giorni d’oggi, la gente rimane sempre sorpresa quando guarda il software enterprise. Fai clic, vuoi solo vedere un report, vuoi fare qualcosa di minimale, e ci vogliono secondi. In termini di reattività, il software enterprise mediamente è molto scarso. È estremamente lento. Se paragoniamo, per esempio, la ricerca sul web, vuoi fare una ricerca su Google. In circa 50 millisecondi, forse 100, Google è in grado di scansionare il web e fornirti un riassunto delle informazioni che corrispondono alla tua query. Questo è estremamente veloce e reattivo.

Al contrario, vuoi semplicemente fare qualcosa di super basilare come “Voglio controllare lo stato di questo SKU”, e ci vogliono secondi. La parte interessante è che ci vogliono secondi sull’hardware di calcolo che abbiamo nel 2024. Già 20 anni fa ci voleva un secondo, nonostante l’hardware fosse 100 volte meno performante. Cos’è successo? Beh, ciò che è successo è che l’hardware di calcolo extra, le capacità aggiuntive di questo hardware, sono state semplicemente sprecate a causa di un software inefficiente.

Conor Doherty: Grazie. Quando parli di conoscenza fondamentale, mentre ascoltavo mi è venuto in mente che c’è una specie di… si può dividere ciò che stai descrivendo, e vorrei avere il tuo parere in merito. Prendendo un’analogia da prima, hai detto che se prendi un’auto e vai nel deserto, è quella il miglior veicolo per il deserto? Mi sembra che, in termini di conoscenza fondamentale, esistano sia componenti teoriche che pratiche.

Quindi, puoi avere una comprensione fondamentale teorica di come funziona un motore a combustione interna, ovvero come fa a muoversi l’auto. Quella è una comprensione teorica. Esiste anche una conoscenza fondamentale pratica, che è, beh, se quella gomma si forasse, ho le competenze e le conoscenze di base per cambiarla? Se il motore non parte, posso effettuare una riparazione di base? E se devi guidare nel deserto, dove sarai solo, avrai fondamentalmente bisogno sia di una conoscenza teorica sia almeno di una pratica di base.

Quindi, per tornare all’argomento in questione, hai descritto in certa profondità le conoscenze teoriche di base che le persone dovrebbero possedere. In termini di conoscenze pratiche di base, ci sono delle competenze che ritieni tutti debbano avere in questo ambito?

Joannes Vermorel: Sì, ancora, guardando al lato pratico, sarebbe utile avere un’idea dei livelli di prezzo di cui parliamo. Sai, qual è il costo di un terabyte di storage? Qual è approssimativamente il costo di un terabyte di memoria? Qual è il costo di una CPU che ti offre 2 GHz di throughput computazionale? Insomma, basta avere un’idea tale che, se riesci ad indovinare un numero che non sia sbagliato di un ordine di grandezza, è già molto buono. Vedi, con l’informatica, di solito se la gente dovesse azzardare una stima, le proprie ipotesi sarebbero sbagliate di molti ordini di grandezza.

Ancora, se ti dico qual è il peso di un’auto e ti mostro l’automobile, la tua stima potrebbe essere sbagliata del 50%. Sai, potresti dire: “ok, una tonnellata e mezza”, ma poi risulta che è un’auto elettrica e pesa due tonnellate più qualcosa. Va bene, ma pur sempre eri nell’ordine di grandezza corretto. Non si guarda a un’auto e si pensa che pesi 20 chilogrammi o 500 tonnellate. Tuttavia, il problema è che quando chiedi alla gente qual è il costo di un terabyte di storage persistente, il più economico che si possa trovare, alcuni ti darebbero prezzi che variano, non so, da 10.000 a 2, e così via, e nessuno avrebbe alcuna idea a riguardo.

E la stessa cosa se ti dico qual è il costo di un chip che può eseguire un ordine di grandezza pari a 100 miliardi di operazioni aritmetiche al secondo, quale sarebbe un chipset in grado di farlo, e a che prezzo? La gente dice, “non lo so, 100.000 euro o forse 50 dollari”. Ancora, questo è il tipo di situazione in cui dico che la conoscenza pratica consiste nell’avere un’idea dei livelli di prezzo. Non è una stima precisa, ma se hai l’ordine di grandezza, sei già in linea per fare scelte sensate.

Questo aspetto molto strano delle risorse computazionali è che ci sono letteralmente 15 ordini di grandezza. È abbastanza, penso, unico. Non conosco nessun altro campo in cui gli ordini di grandezza siano così incredibilmente dispersi. 15 ordini di grandezza significano che, da una parte, stiamo parlando di unità, sai, una addizione, una moltiplicazione, che costituisce un’unità di calcolo. Dall’altra parte, stiamo parlando essenzialmente di miliardi di miliardi. È davvero uno spettro enorme di ordini di grandezza.

E questo è difficile da comprendere per la mente. Ed è per questo, tra l’altro, che quando ho detto che si possono commettere errori in termini di spreco di risorse computazionali, è perché, a differenza dell’analogia con l’auto, anche l’auto peggiore sarà solo circa 10 volte più dispendiosa in termini di consumo rispetto alla migliore. Diciamo, ad esempio, che se devo percorrere 100 chilometri, se ho un’auto super, super efficiente, mi consumerà circa cinque litri di carburante per quei 100 chilometri.

Se invece scelgo un SUV super pesante, inefficiente e simili, consumerà, diciamo, 50 litri: un fattore di 10. Con i computer non è così. Sarebbe come se l’oggetto più efficiente consumasse 5 centilitri per 100 chilometri e il meno efficiente consumasse cinque metri cubi per gli stessi 100 chilometri. Quindi, gli ordini di grandezza sono davvero sconcertanti. Ed è per questo che, in termini pratici, è necessario avere qualche idea dei livelli di prezzo. Inoltre, è importante avere un’idea di cosa stia migliorando e cosa non stia migliorando.

Conor Doherty: Cosa intendi con “cosa sta migliorando” e “cosa non sta migliorando”?

Joannes Vermorel: Ad esempio, le GPU stanno progredendo in termini di tendenze di rete. Le GPU sono migliorate a livelli incredibili negli ultimi 5 anni e ci si aspetta che continuino a migliorare in modo altrettanto impressionante per i prossimi cinque. Quindi, si tratta di una classe di risorse computazionali che sta rapidamente migliorando. Stanno migliorando in termini di numero di operazioni al secondo. Stanno migliorando anche in termini di memoria. Quindi, è davvero molto positivo. Le CPU seguono un percorso simile. Forse non migliorano altrettanto velocemente, ma stanno comunque progredendo molto rapidamente in termini di numero di core e della dimensione della memoria L3, che è la memoria presente all’interno della CPU.

Continua a migliorare rapidamente. Al contrario, se guardiamo alla DRAM, essa viene utilizzata per la memoria principale del computer, la memoria volatile. Quindi, se spegni il computer, la perdi. Questa tecnologia è rimasta praticamente immutata nell’ultimo decennio. Ci sono pochissimi produttori; esistono tipo quattro fabbriche nel mondo. Quindi, questo è un mercato in cui non ci si dovrebbe aspettare grandi cambiamenti in termini di calo dei prezzi. Non ci si dovrebbe aspettare troppi cambiamenti nel breve termine, ecc. Insomma, direi che in termini pratici si tratta di avere un’idea degli ordini di grandezza, conoscere un po’ i livelli di prezzo, sapere cosa aspettarsi e, anche, avere l’intuizione se, ad esempio, l’hardware di livello professionale offre qualcosa di molto diverso rispetto a quello consumer.

A seconda di ciò che osservi, a volte il meglio che puoi ottenere è semplicemente hardware di livello consumer, e il meglio che una società può acquistare è solo marginalmente migliore. Vedi, in altri settori non è così. In alcuni casi, ciò che una società può acquistare è di molti ordini di grandezza superiore a quello che è generalmente considerato adatto al mercato consumer. Ancora, è proprio questo il tipo di conoscenza che ti aiuta a orientarti nel panorama, a scegliere il fornitore giusto, o meglio, a eliminare quelli incompetenti. Sai, è una cosa che, se presti attenzione, ti permette di filtrare l’incompetenza, sia da parte dei consulenti che dei fornitori, e anche nei progetti interni. Questo conta davvero.

Conor Doherty: Bene, hai toccato il tema dei costi in diverse occasioni, ma hai parlato principalmente in termini del costo diretto di acquistare fisicamente l’hardware. Considerando sia il costo diretto che indiretto di non essere più intelligenti nell’utilizzo delle risorse computazionali, qual è l’ordine di grandezza di cui stiamo parlando? E per questo, supponi un grande negozio al dettaglio, pardon, una grande azienda retail, una vasta rete retail, omnicanale, dipingi pure il quadro che preferisci, ma qual è un ordine di grandezza ragionevole in termini di quello che potresti perdere non essendo più esperto in queste cose?

Joannes Vermorel: Beh, direi che, come stima prudente, oltre il 90% delle iniziative di ottimizzazione della supply chain falliscono. E una grossa percentuale di questo 90% – praticamente tutte le iniziative software – falliscono, e una gran parte di ciò è dovuta, sebbene non unicamente, alla pessima performance. Ora, quando pensiamo alla performance, dobbiamo considerarla da diverse prospettive. La gente potrebbe pensare: “ok, devo rifornire il mio inventario ogni giorno, quindi il calcolo di tutto deve essere completato in meno di 24 ore.”

Va bene, è scontato. Sai, se vuoi eseguire il calcolo ogni giorno e non riesci a completarlo in 24 ore, sei nei guai. Quindi quella è la soglia massima di tempo che puoi dedicare. Ora, potresti pensare che se acquisti il doppio delle risorse computazionali, puoi farlo il doppio velocemente. Beh, non necessariamente, perché tutto dipende dall’architettura software che adotti. Esistono molte architetture e design pattern che non si prestano a quello che viene chiamato, tecnicamente, “scale-out”. Quindi ci sono molti approcci in cui, aggiungendo più hardware, non ottieni un aumento di velocità.

Conor Doherty: Fondamentalmente rendimenti decrescenti.

Joannes Vermorel: Sì, e a volte non ottieni alcun guadagno. Puoi aggiungere letteralmente più risorse e avere esattamente zero aumento di velocità. Dipende davvero da come hai progettato il tuo software per sfruttare quelle risorse computazionali extra. Ora, andiamo avanti. Supponiamo che tu abbia qualcosa in grado di calcolare il rifornimento in, diciamo, quattro ore, e tu pensi: “Grande, per la mia rete retail ci vogliono solo quattro ore.” Così hai 24 ore al giorno, quindi sembra che eseguirai il calcolo durante la notte. Ma è soddisfacente?

Beh, la mia risposta è no, assolutamente no. Perché? Perché qui stai considerando il tutto una sola volta in produzione. Non tieni conto del fatto che la tua ricetta numerica dovrà essere ottimizzata e che dovrai iterare molte volte per convergere a quella finale che sia soddisfacente. Questo processo sperimentale risulterà molto più costoso.

Per molte ragioni. Innanzitutto, quando conduci esperimenti, non inizi essendo molto economico. Sarai efficiente solo dopo aver individuato qualcosa che, in termini di qualità decisionale, ti dia risultati soddisfacenti. Quindi è del tutto normale aspettarsi che, durante la fase di prototipazione di nuove ricette, sarai molto meno efficiente. L’efficienza arriverà successivamente, quando inizierai a ottimizzare davvero il consumo delle risorse computazionali.

Quindi, questo è un aspetto. Ma un altro problema è che devi pagare per far aspettare le persone fino a quando il calcolo non è completato, così che possano esaminare i risultati, valutarli e procedere con la successiva iterazione. E qui il grosso problema è che, se torno all’iniziativa software di supply chain che fallisce, questo processo può diventare drasticamente lento. Voglio dire, stavamo parlando di circa quattro ore. Diciamo ancora che gli esperimenti saranno due volte più lenti a causa del fatto che ti trovi in un contesto sperimentale che non è così ottimale.

Il che significa otto ore. Ciò significa che potrai condurre un solo esperimento al giorno. E se devi fare 500 iterazioni, questa cosa impiegherà due anni. Sarà così lenta che inizierai ad avere altri problemi, per esempio che le persone che eseguono gli esperimenti cominceranno a passare ad un altro lavoro. Gli ingegneri con cui lavori non rimangono con te per 40 anni. Quindi, a un certo punto, chi ha iniziato a lavorare sul progetto se ne andrà, e dovrai sostituirlo con nuove persone, che naturalmente non ricorderanno tutti gli esperimenti già condotti.

Quindi vedi, questo tipo di problema crea tantissimi problemi. Anche se alla fine convergi a una ricetta numerica soddisfacente, sei sempre a una sola disruption di distanza – lockdown o altro – e devi rielaborare la ricetta. Se il tuo processo iterativo è incredibilmente lento, fallirai sistematicamente nel far fronte a tutte le interruzioni. Quando finalmente avrai ingegnerizzato la soluzione per un’interruzione, sarai già passato ad altro. Quindi è necessario avere qualcosa di estremamente performante affinché le iterazioni siano molto rapide.

E ciò comporta un altro aspetto, ovvero che in termini di performance, tra un’iterazione e l’altra, si può fare “scorciatoia”. Perché forse, da un esperimento all’altro, rifarai la maggior parte degli stessi calcoli. Quindi, è necessario riallocare tutte quelle risorse se, in effetti, stai eseguendo quasi esattamente la stessa ricetta numerica con piccole divergenze? Forse, adottando un approccio intelligente, potresti riciclare gran parte di quanto già calcolato, così da iterare molto più rapidamente senza rifare tutto ogni singola volta.

Ma, ancora una volta, questo funzionerà solo se riesci a capire dove vanno le mie risorse computazionali, cosa sto sprecando, cosa sto facendo due o dieci volte di seguito, e che dovrei fare solo una volta.

Conor Doherty: Ok, bene, Joannes, le persone che ci ascoltano oggi – e sono sicuro che tutte direbbero: “Sono d’accordo con quest’uomo. Mi fido di lui. È affidabile.” – quali sono i prossimi passi immediati per, diciamo, il praticante medio della supply chain e per i dirigenti di livello C che ti ascoltano e pensano: “Ok, voglio essere più esperto in queste cose”?

Joannes Vermorel: Direi di iniziare a leggere materiale introduttivo su come funzionano i computer. Ci sono molti libri che ti spiegano il funzionamento dei computer, e prova a informarti, ad esempio, su cosa viene offerto dai fornitori di cloud computing. Sai, puoi informarti: tutti i prezzi sono pubblici. Quindi puoi andare su Microsoft Azure e vedere: “Ok, qual è il livello di prezzo per lo storage, per le CPU, per le macchine virtuali, per la banda larga, e così via?” Insomma, bastano poche ore. Direi che si possono prendere libri elementari. Voglio dire, esistono persino libri destinati alle scuole medie o superiori, ed è perfettamente accettabile. L’idea è quella di cercare di acquisire questa conoscenza.

E poi, ogni volta che si presenta il tema di un’evoluzione tecnologica, chiedi al fornitore, chiedi al consulente: “Ok, qual è la tua opinione sulle risorse computazionali? Vogliamo prendere le decisioni migliori secondo le metriche e gli obiettivi che ti sei prefissato.” Avvia una discussione su come quelle risorse computazionali grezze che stai acquistando possano tradursi, da un lato, nelle decisioni migliori. Se le persone da cui stai per acquistare un sacco di roba non ne hanno idea, allora dovresti scappare. Sai, questo è il mio consiglio: usalo come test per individuare i cosiddetti esperti che, in realtà, non dovrebbero nemmeno esserlo, perché sono, direi, assolutamente incompetenti.

Perché, in definitiva, se scegli quei tipi di fornitori, finirai per pagare il prezzo delle loro inefficienze. E il prezzo sarà duplice. Innanzitutto, pagherai molto di più per l’hardware computazionale, al punto da risultare esorbitante. Come regola generale, Lokad, quando vende un abbonamento, si posiziona ben al di sotto del costo dei nostri concorrenti solo per le risorse computazionali, senza nemmeno considerare il costo del personale – gli ingegneri necessari per installare e manutenere il sistema.

Questo è un aspetto. Ma poi accade qualcosa di ancora più grave: il tuo fornitore ti costringerà ad adottare ricette super semplificate, cercando di convincerti che rappresentano il meglio che la scienza possa offrire, mentre in realtà è solo il riflesso della loro incapacità di sfruttare adeguatamente le risorse computazionali. Ecco perché si finiscono per proporre soluzioni iper-semplificate, come gli stock di sicurezza, che sono ancora prevalenti. Voglio dire, i fornitori sanno in fondo che è una sciocchezza. Il problema è che sono così inefficienti nell’uso delle risorse computazionali che per loro diventa estremamente impraticabile considerare soluzioni migliori.

Quindi vedi, il costo è duplice: costo diretto, ovvero una spesa sfarzosa per risorse di calcolo che non hanno senso, e poi c’è il costo di secondo ordine, cioè ti trovi costretto a ricorrere a ricette semplificate dove, alla fine, sarai obbligato come practitioner a intervenire con i tuoi fogli di calcolo per sistemare manualmente tutta la follia che esce da quei sistemi. Perché? Perché il sistema utilizza ricette eccessivamente semplicistiche che di fatto delegano a te tutte le sottigliezze, dato che la ricetta è banale e non affronta alcuna forma di sofisticazione.

Conor Doherty: In realtà, c’era, o meglio, non era proprio un’analogia, ma una vera regola empirica che hai usato prima, o scusami, una domanda. Hai detto, “Se non sai in che modo o quanto costa un terabyte di cloud computing o qualcosa del genere, se non hai nemmeno l’ordine di grandezza, fondamentalmente è un problema.” Ed è interessante quello che dici, perché nella vita personale, anche chi ascolta, se entrassero in un caffè per ordinare un caffè e venissero informati, “Va bene, sono €45,” rimarrebbero perplessi. Sarebbero scioccati e direbbero, “Ok, beh, non va bene. Non so quanto dovresti addebitarmi personalmente, ma €45 sono decisamente troppo.” E presumibilmente se ne andrebbero altrove.

Anche se si trovasse in una zona turistica, diresti comunque, “45, no, non va bene.” Ma alla fine nulla dipende da ciò. Voglio dire, non rovinerai te stesso, presumibilmente non rovinerai la tua situazione finanziaria. Non perderai il tuo lavoro per questo.

Tuttavia, lo stesso tipo di istinto, l’istinto di sopravvivenza o semplicemente la prontezza generale potrebbe essere completamente assente quando si tratta di, “Ok, devo prendere decisioni molto costose su quale tipo di risorse computazionali o software l’azienda utilizzerà.” I costi diretti e indiretti a lungo termine di ciò, i costi indiretti a breve termine e a lungo termine, sono inimmaginabili. Tipo, “Oh, costa 555.000 per secondo di calcolo o qualcosa del genere.” Di nuovo, in realtà potrebbe essere corretto. Non lo so, probabilmente no. Ma il punto è che, se non riesci a rispondere a queste domande, concordo che c’è un enorme vuoto nella tua conoscenza professionale che dovresti colmare.

Joannes Vermorel: Sì, di nuovo, forse è un po’ esigente per i supply chain practitioners, ma cosa c’è in gioco? Grandi budget. Voglio dire, le grandi aziende spendono volentieri milioni e talvolta decine di milioni di Euro o dollari all’anno su quei sistemi. E rimango sempre completamente sbalordito quando si può spendere così tanto e, guarda, nessuno, fornitore compreso, ha la minima idea di questi problemi di base.

Ancora, sarebbe come comprare un edificio, perché è qualcosa di molto costoso. È come comprare un edificio e avere un architetto che non ha la minima idea di cosa sia realmente il cemento. Diresti, “Sai una cosa, non sono sicuro. Forse l’edificio è fatto di cartone, o di cemento, o magari di legno o, addirittura, di marshmallow. Sai, non mi importa, basta pitturarlo e tutto sembra uguale.”

Sai, ancora, penso che le cose informatiche e il software, sai, l’industria del software sia molto particolare in questo senso. Ci sono tonnellate di soldi in gioco e c’è quell’accordo implicito che va bene se tutti sono completamente ignoranti in merito. E questo è, per me, molto intrigante come settore.

E ho parlato con la maggior parte dei miei concorrenti, e quando dico concorrenti, intendo i team di gestione. Rimango sempre sbalordito quando nessuno ha la minima idea di quella sorta di mechanical sympathy, ovvero una comprensione di base di ciò che c’è dietro.

Ancora, potrebbe essere come, immagina un pilota di Formula 1 che dice, “Sai una cosa, ho quattro ruote. Che cosa sta succedendo tra il pedale e le ruote? Sai, è magia, magia. Sai, c’è qualcosa. Fa un rumore forte. So che è rumoroso, ma oltre a questo, c’è solo roba.” Sai, la mia visione dell’auto è roba. Questo è il livello di granularità a cui le persone penserebbero che fosse folle. Dovresti sapere molto di più se ti aspetti di sfruttare al meglio l’auto.

E a mio modo, penso che i supply chain practitioners usino tonnellate di strumenti digitali ogni giorno, proprio come un pilota di Formula 1 usa una Formula 1. E quindi hanno bisogno di capire un po’ per avere questa mechanical sympathy su cosa stia succedendo, come funzioni questa roba, in modo da poter prendere decisioni informate. Almeno, per evitare che gli vengano vendute cose completamente insensate che finiscono per fallire per ragioni interamente prevenibili.

Conor Doherty: Non avrei potuto dirlo meglio. Grazie, e grazie mille per il tuo tempo. Non ho altre domande, e grazie infinite per aver guardato. Ci vediamo la prossima volta.