Conoscenza negativa nella supply chain - Lezione 2.3

00:15 Introduzione
02:28 Smart Fridge
05:28 Survivorship bias
07:28 La storia finora
08:46 Sui tabù (riassunto)
12:06 Euristiche di rifiuto (riassunto)
13:34 Conoscenza positiva di bassa qualità
15:27 Antipattern del software, 1/2
20:11 Antipattern del software, 2/2
25:34 Antipattern della supply chain
27:00 Previsioni nude
32:36 Il livello di servizio al 100%
37:06 L’iniziazione dei Jedi
44:31 L’orrore non euclideo
51:45 Avvocato del diavolo
57:35 Riassunto, conoscenza negativa per le supply chain
01:01:04 Conclusioni
01:02:45 Prossima lezione e domande del pubblico

Descrizione

Gli antipattern sono gli stereotipi di soluzioni che sembrano buone ma non funzionano nella pratica. Lo studio sistematico degli antipattern è stato pionieristico alla fine degli anni ‘90 nel campo dell’ingegneria del software. Quando applicabili, gli antipattern sono superiori ai risultati negativi grezzi, in quanto sono più facili da memorizzare e ragionare. La prospettiva degli antipattern è di primaria importanza per la supply chain e dovrebbe essere considerata come uno dei pilastri della sua conoscenza negativa.

Trascrizione completa

Ciao a tutti, benvenuti a questa serie di lezioni sulla supply chain. Sono Joannes Vermorel e oggi presenterò la conoscenza negativa nella supply chain. Per coloro che stanno guardando la lezione in diretta, potete fare domande in qualsiasi momento tramite la chat di YouTube. Durante la lezione non leggerò la chat, tuttavia tornerò alla chat alla fine della lezione per la sessione di domande e risposte.

Oggi, l’argomento di interesse è ciò che un’azienda effettivamente guadagna quando assume un direttore della supply chain esperto con forse due o tre decenni di esperienza. Cosa sta cercando l’azienda e potremmo, in misura marginale, replicare l’acquisizione di questa esperienza in un periodo di tempo molto più breve? Ecco esattamente di cosa si tratta la conoscenza negativa.

Quando guardiamo una persona molto esperta, qualcuno che ha lavorato per due decenni in un settore, stiamo davvero cercando che questa persona replichi soluzioni, processi o tecnologie che ha implementato uno o due decenni fa in altre aziende? Probabilmente no. Anche se potrebbe accadere marginalmente, sospetto che di solito sia una ragione molto marginale al massimo.

Quando cerchi una persona molto esperta, l’obiettivo non è necessariamente replicare le cose come sono state fatte in passato. Il valore chiave che si desidera acquisire è prendere qualcuno che sa come evitare tutti i tipi di errori ed ha l’esperienza per garantire che molte idee molto naive e sbagliate non verranno implementate nella tua azienda. C’è questo detto che in teoria, pratica e teoria sono la stessa cosa, ma in pratica non lo sono. Questo è esattamente il nocciolo della conoscenza negativa.

La mia proposta per te è che le cattive idee di business sono ovunque. Quando dico cattive, intendo idee che, se implementate, si rivelerebbero completamente non redditizie per l’azienda. Per illustrare questo, ho appena inserito la query “frigoriferi intelligenti” nel motore di ricerca Google Patents. Google Patents è un motore di ricerca specializzato fornito da Google, e puoi cercare un database di brevetti. Ecco che otteniamo 130.000 risultati di brevetti depositati su frigoriferi intelligenti.

Prendi questo numero con le pinze, poiché probabilmente ci sono molte duplicazioni. Tuttavia, un’ispezione sommaria dei risultati indica molto chiaramente che abbiamo diverse centinaia, se non diverse migliaia di aziende che, negli ultimi decenni, si sono impegnate a fare ricerca e sviluppo per depositare un brevetto su frigoriferi intelligenti. Quando guardi il tipo di idee trovate in quei brevetti, vedrai che è sempre una combinazione di prendere questo elettrodomestico molto diffuso, un frigorifero, e aggiungere qualcosa, come elettronica economica. Combiniamo i due, e voilà, abbiamo una soluzione di qualche tipo.

Per quale tipo di problema, però? È molto poco chiaro. Solo per darti l’idea della maggior parte dei brevetti, è il tipo di idea in cui, se hai un frigorifero che ha qualche tipo di sensori, il frigorifero stesso rileverà se stai finendo il latte e automaticamente effettuerà un riordino per te. Siamo nel 2021, e per quanto ne so, i frigoriferi intelligenti non esistono. Non è che non siano tecnicamente fattibili - lo sono molto. È solo che non c’è letteralmente mercato per loro. Quindi, abbiamo una quantità enorme di soluzioni sul mercato che cercano un problema. Negli ultimi due decenni, credo di aver visto due volte l’anno, in media, una startup che promuove un frigorifero intelligente di qualche tipo. Curiosamente, non ho mai più sentito parlare di nessuna di quelle startup. Non ho tenuto traccia, ma sospetto fortemente che ogni singola startup che ho visto promuovere un frigorifero intelligente durante gli ultimi due decenni sia fallita. Tuttavia, mentre l’idea è molto diffusa e popolare, come dimostrato da quei migliaia di brevetti, le conseguenze di quelle idee, che sono cattive perché probabilmente la maggior parte di quelle startup è semplicemente fallita, non si sono propagate.

Qui vediamo qualcosa di molto interessante: attraverso l’esperienza, puoi accedere a una sorta di conoscenza che non è facilmente accessibile agli osservatori sul mercato. Puoi vedere il lato oscuro, che sono le cose che mancano, il tipo di cose che sono state promesse e diffuse ma non si sono rivelate molto di successo.

C’è un esempio storico molto noto della Seconda Guerra Mondiale. L’esercito degli Stati Uniti ha condotto un’indagine sugli aerei che tornavano alla base per raccogliere la posizione degli impatti di proiettili sugli aerei. Quello che vedi sullo schermo era essenzialmente la raccolta della posizione dei proiettili osservata sugli aerei che tornavano dai campi di battaglia alla base. Inizialmente, gli ufficiali dell’esercito seguivano il ragionamento che dovevano aggiungere piastre corazzate nelle aree che venivano colpite di più, le aree che erano ovviamente sotto il maggior fuoco durante la battaglia.

Poi, un altro signore, Abraham Wald, disse no, è esattamente il contrario. La cosa è che quello che vedi sono gli aerei che sono riusciti a tornare alla base. Quello che non vedi è che, per tutte le aree in cui non vedi impatti di proiettili, è molto probabile che quando c’era un impatto di proiettile in questa area, si è rivelato letale sia per l’aereo che per l’equipaggio, o entrambi. Quindi, se devi aggiungere piastre corazzate, devi farlo precisamente in tutte le aree in cui non vedi gli aerei tornare alla base con impatti di proiettili. Sono quelle le aree che devono essere protette.

Quello che Abraham ha evidenziato è che c’era un fenomeno noto come bias di sopravvivenza, in cui ciò che osservi sono essenzialmente i sopravvissuti, non tutti gli aerei che non sono riusciti a tornare alla base. L’idea della conoscenza negativa è esattamente così: prendi questa foto fotografica e il negativo, ed è il resto che devi davvero catturare la tua attenzione perché è lì che succedono le cose veramente brutte. Questa è l’essenza, direi, della conoscenza negativa.

Questa è la quarta lezione della mia serie di lezioni, la prima lezione del secondo capitolo. Nel primo capitolo del prologo, ho presentato le mie opinioni sulla supply chain, sia come campo di studio che come pratica. Quello che abbiamo visto è che la supply chain è essenzialmente una collezione di problemi complessi, a differenza dei problemi semplici. I problemi complessi sono molto difficili da affrontare perché non si prestano né a studi facili né a pratiche facili. Fondamentalmente c’è qualcosa di avverso in termini di studio e pratica con i problemi complessi. Ecco perché il secondo capitolo è dedicato alle metodologie.

In questa lezione presente, stiamo adottando un approccio qualitativo, proprio come abbiamo fatto con la persona della supply chain, che è stata la prima lezione di questo capitolo. Approfondiremo il tipo di approcci qualitativi che possiamo avere per fornire miglioramenti alle supply chain in modo controllato, affidabile e potenzialmente misurabile.

Riepilogo: Sebbene questa sia una lezione dedicata alla conoscenza negativa, non è la prima volta in questa serie di lezioni che tocco elementi che potrebbero qualificarsi come piccoli frammenti di conoscenza negativa. Durante la prima lezione di questo secondo capitolo sulle persone della supply chain, ho presentato le mie opinioni sugli studi di caso. Ho detto che gli studi di caso positivi, ossia gli studi di caso che presentano risultati positivi associati a una soluzione di interesse, sono accompagnati da enormi conflitti di interesse che minano completamente la fiducia che potremmo avere nella validità dei risultati. D’altra parte, ho affermato che gli studi di caso negativi vanno bene perché quei conflitti di interesse, sebbene possano essere presenti, sono molto meno intensi.

In questa lezione sulle persone della supply chain, ho presentato un fantastico studio di caso negativo, “Gli ultimi giorni di Target Canada” di Joe Castaldo, che ha descritto un fallimento della supply chain su scala epica che ha portato alla bancarotta di Target Canada. Questa è una sorta di conoscenza negativa, in cui l’oggetto di studio è letteralmente ciò che non ha funzionato, a differenza di ciò che possiamo fare per ottenere qualcosa che funziona effettivamente.

Ora, potremmo utilizzare gli studi di caso negativi come pratica fondamentale per la nostra conoscenza negativa per la supply chain? Direi principalmente no, per due ragioni molto distinte. La prima ragione è semplicemente che gli studi di caso negativi sono estremamente rari. Stimo, solo come stima approssimativa, che ci siano effettivamente più di 100 volte più brevetti su frigoriferi intelligenti, che sono completamente inutili, rispetto agli studi di caso negativi sulla supply chain. Quindi, abbiamo un problema molto pratico: anche se quegli studi di caso negativi sono di primaria importanza e di grande interesse scientifico, si trovano essere estremamente rari. Ne abbiamo così poco che è molto difficile avere questo materiale come base della nostra conoscenza negativa per la supply chain.

Il secondo problema è l’intelligibilità. Quegli studi di caso negativi, come il fantastico articolo “Gli ultimi giorni di Target Canada”, mostrano che ci sono decine di problemi che si verificano contemporaneamente, e tutti quei problemi sono completamente intrecciati per portare infine a un fallimento epico. Il problema è che quegli studi di caso sono letteralmente la vita reale in azione, e quegli eventi sono molto complessi. È difficile comunicare e ragionare su quegli studi di caso perché i dettagli contano, e sono molto densi. C’è un problema più pedestre: come si comunica tutto ciò a un pubblico più ampio?

Nella mia ultima lezione sull’ottimizzazione sperimentale, abbiamo anche visto un altro tipo di conoscenza negativa: euristiche di rifiuto. Queste erano essenzialmente trucchi semplici che possono essere utilizzati quando viene presentata una proposta in termini di una soluzione quantitativa proposta come candidato potenziale per il miglioramento della vostra supply chain. È possibile utilizzare una serie di euristiche o regole semplici per scartare soluzioni che, con un grado molto elevato di certezza, semplicemente non funzioneranno. Tuttavia, qui abbiamo un problema di scalabilità. Queste euristiche funzionano solo perché sono oscure. Se diventassero ben note tra i circoli della supply chain, sia i documenti scientifici che i software per la supply chain si adatterebbero e cambierebbero il loro discorso, rendendo la situazione più confusa. Queste euristiche sono molto efficienti, ma se diventassero popolari, manterrebbero comunque la loro validità, ma perderebbero la loro efficienza come filtri, semplicemente perché le persone farebbero attenzione a aggirare queste euristiche.

Ecco perché queste euristiche, sebbene molto interessanti, non possono essere utilizzate come fondamenta per la nostra conoscenza negativa che vogliamo costituire per la supply chain.

Inoltre, non dovremmo confondere la conoscenza negativa con la conoscenza positiva di bassa qualità. La differenza è davvero una questione di intento. Ad esempio, l’intento delle scorte di sicurezza è quello di fornire alle aziende un modo controllato per guidare la qualità del servizio che otterranno. L’intento è positivo; è una soluzione per qualcosa che dovrebbe funzionare. Ora, la realtà è che il modello delle scorte di sicurezza si basa su assunzioni completamente abusive: la domanda futura e i tempi di consegna vengono considerati distribuiti normalmente, anche se queste assunzioni sono factualmente sbagliate. Non ho mai osservato set di dati sulla supply chain in cui né la domanda né i tempi di consegna fossero distribuiti normalmente. Le distribuzioni di interesse sono effettivamente distribuite secondo la legge di Zipf, come ho affrontato nelle mie lezioni precedenti sui principi quantitativi per la supply chain. Da una prospettiva corretta, le scorte di sicurezza sono falsificate, ma comunque, le scorte di sicurezza sono sicuramente ancorate nel campo della conoscenza positiva, anche se potrebbe essere argomentabile una conoscenza positiva di bassa qualità.

Durante questa lezione, non avremo tempo per approfondire tutti gli elementi che, dal mio punto di vista, possono essere considerati conoscenza positiva di bassa qualità, ma sarò felice di rispondere se qualcuno vorrà farmi domande su uno qualsiasi di questi elementi durante la sessione di domande e risposte.

Quando si tratta di conoscenza negativa effettiva di interesse pratico, c’è un libro chiamato “Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis” che rappresenta una pietra miliare nella storia dell’ingegneria del software. Pubblicato nel 1998, questo libro inizia con un’osservazione casuale secondo cui nell’industria del software, quando ci sono buone idee e progetti che sfruttano le buone idee, i fornitori di software vedono le buone idee consumate dal successo del progetto. Gli autori si chiedono se una buona idea rimanga una buona pratica dopo che il prodotto è stato implementato, e la risposta è essenzialmente no. C’è un vantaggio del primo arrivato che è molto specifico dell’industria del software, e di conseguenza abbiamo un problema. Praticamente qualsiasi insieme di regole che si utilizzerebbe per prevedere il successo di qualsiasi cosa nell’industria del software è autodistruttivo, a causa del fatto che gli approcci migliori tendono ad essere consumati dal successo che generano. Gli autori di “Anti-Patterns” hanno notato che è quasi impossibile, secondo loro, garantire il successo di un’iniziativa software. Tuttavia, hanno anche notato che la situazione è molto asimmetrica quando si tratta di fallimenti. Hanno osservato che è possibile prevedere, con un grado di confidenza molto elevato (a volte al limite della certezza), che un determinato progetto sta per fallire. Questo è molto interessante perché non puoi garantire il successo, ma puoi avere qualcosa di simile a una scienza che garantisce il fallimento. Ancora meglio, questa conoscenza degli elementi che garantiscono il fallimento sembra essere estremamente stabile nel tempo e molto indipendente dalle specificità tecniche dell’azienda o del settore considerato.

Se torniamo all’idea iniziale del frigorifero intelligente, possiamo vedere che tutti quei brevetti per frigoriferi intelligenti sono incredibilmente diversi nelle soluzioni che presentano. Ma si scopre che tutti quei brevetti per frigoriferi intelligenti portano a fallimenti commerciali perché rientrano tutti nella stessa categoria: una soluzione alla ricerca di un problema. La combinazione di un elettrodomestico ubiquo con elettronica economica crea una soluzione, ma è qualcosa che ha davvero senso? In questo caso, quasi mai.

Gli autori di “Anti-Patterns” hanno iniziato il loro viaggio studiando le cause profonde dei fallimenti del software e hanno identificato i sette peccati capitali dell’ingegneria del software, che sono fretta, apatia, mentalità ristretta, avarizia, ignoranza, orgoglio e invidia. Questi problemi saranno indipendenti dal contesto e dalle tecnologie coinvolte perché sono invarianti della stessa natura umana. Quando si cerca un direttore della supply chain con due decenni di esperienza, si tratterà di qualcuno che ha semplicemente vissuto più a lungo e ha interiorizzato la maggior parte dei problemi che sorgono quando sono coinvolti esseri umani reali, con tutti i tipi di difetti.

L’idea degli autori è che sia utile formalizzare questa conoscenza per renderla più digeribile e comprensibile in modo che sia più facile comunicare e ragionare su questi problemi. Questa è l’essenza degli anti-patterns: un formato per catturare piccoli frammenti di conoscenza negativa.

Nel loro libro, gli autori presentano un modello per un anti-pattern, che inizia con un nome accattivante e facile da memorizzare. È necessario caratterizzare la scala, che sia a livello di codice sorgente, a livello di architettura del software, a livello aziendale o a livello industriale. Si desidera identificare le cause profonde effettive e le conseguenze che sono tipicamente associate ad esse. Si desidera caratterizzare le forze in gioco, i sintomi e le conseguenze non volute che le persone non si aspettano, le quali minano completamente i benefici attesi della soluzione iniziale.

Gli autori sostengono che è necessario presentare prove aneddotiche, ed è per questo che utilizzano aziende immaginarie nei loro anti-patterns. Ciò viene fatto per evitare i tabù legati alla discussione di aziende e persone reali, che potrebbero impedire l’instaurarsi di una comunicazione onesta. Il modello di anti-pattern deve concludere con una soluzione ristrutturata, che è un percorso per trasformare ciò che è essenzialmente una soluzione sbagliata in una variante di quella soluzione che funziona effettivamente nel mondo reale, dove le conseguenze non volute sono mitigati e idealmente eliminati.

Questa lezione non riguarda gli anti-pattern della supply chain, ma solo per dare due esempi di anti-pattern del software di cui potresti aver sentito parlare, il primo è il Martello d’Oro. Il Martello d’Oro è l’idea che quando hai un martello d’oro in mano, tutto il resto è un chiodo. Questo anti-pattern afferma essenzialmente che se chiedi a un programmatore Java come affronterebbe un nuovo problema, probabilmente suggerirà di scrivere un programma in Java per risolvere quel problema. Se presenti un altro problema alla stessa persona, la stessa persona direbbe che anche questo altro problema potrebbe essere risolto con un programma Java. Se presenti 20 problemi diversi, ogni volta la risposta sarà: “Credo che un programma Java vada bene”. Questo è un enorme pregiudizio in cui le persone con esperienza in una determinata tecnologia hanno la tendenza a riciclare la loro conoscenza tecnica per risolvere nuovi problemi, invece di prendersi il tempo per valutare se la loro conoscenza sia davvero rilevante dal punto di vista tecnico per affrontare il nuovo problema. È molto più facile intellettualmente ricorrere a ciò che si conosce effettivamente.

Un altro esempio è l’Analisi Paralisi. Nel mondo del software, ci sono molte situazioni in cui le possibilità sono infinite ed è tentatore dire: “Invece di testare 20 approcci diversi che falliranno, pensiamo molto attentamente al design e una volta che siamo assolutamente sicuri di avere la soluzione giusta in mente, allora implementeremo”. Purtroppo, questo è molto difficile da eseguire e di solito porta ad un’analisi paralisi, in cui si spende più tempo ed energia considerando tonnellate di opzioni potenziali invece di provare una soluzione e vedere se funziona o no.

Ora, ovviamente, abbiamo discusso che questo libro riguardava gli anti-pattern del software e credo che l’ingegneria del software abbia molte somiglianze con i problemi che affrontiamo nella supply chain, soprattutto nell’ottimizzazione della supply chain. Entrambi i settori sono essenzialmente collezioni di problemi complessi e la supply chain moderna riguarda molto la consegna di un prodotto software. Quindi, c’è un certo grado di sovrapposizione tra i problemi della supply chain e i problemi dell’ingegneria del software, ma questi due settori non sono completamente lontani anni luce l’uno dall’altro.

Qui presenterò cinque anti-pattern della supply chain, che possono essere trovati in forma scritta sul sito web di Lokad, con una presentazione più estesa disponibile per coloro che sono interessati.

Il primo è Naked Forecast. Ispirato alla breve storia “I vestiti nuovi dell’imperatore” di Hans Christian Andersen, il contesto è un’azienda con un’iniziativa in corso per migliorare l’accuratezza delle previsioni. Alcuni sintomi includono previsioni di lunga data di cui tutti si lamentano: produzione, marketing, vendite, acquisti e persino supply chain, con la divisione delle previsioni che di solito fa parte della supply chain. Ci sono stati tentativi di migliorare l’accuratezza delle previsioni negli ultimi uno o due decenni, ma sembra che non importa quanto sforzo venga messo nel caso, ci sia una serie infinita di scuse da parte delle persone responsabili delle previsioni per giustificare la loro scarsa accuratezza.

La cosa è che c’è questa prossima iniziativa in cui l’intento è ottenere l’accuratezza delle previsioni in modo chiaro, per risolvere una volta per tutte questo problema di previsioni inaccurate. Questo è l’anti-pattern del Naked Forecast in gioco. Le conseguenze non volute di ciò sono, in primo luogo, che non produrrà previsioni significativamente più accurate. In secondo luogo, attraversare un’altra iniziativa creerà solo un’organizzazione ancora più bizantina in cui ciò che è iniziato come una piccola pratica per fornire le previsioni diventa sempre più complesso, con più persone coinvolte nella produzione di quelle previsioni. Lungo la strada, ti ritrovi con qualcosa che è ancora impreciso come sempre ma è passato da qualcosa di modesto e impreciso a una grande burocrazia che è ancora imprecisa come sempre.

Credo che la causa principale qui sia ciò che io chiamo razionalismo ingenuo o l’illusione della scienza. Quando questa iniziativa inizia, il problema si presenta come se fosse perfettamente oggettivo: “Produrremo previsioni più accurate secondo una metrica, diciamo l’errore medio assoluto”. Tutto sembra molto semplice, con un problema ben definito. Tuttavia, il problema è che tutto ciò è molto ingenuo perché non c’è una correlazione diretta tra l’accuratezza delle previsioni e la redditività dell’azienda. Ciò che dovresti cercare sono modi per migliorare la redditività dell’azienda, quindi dovresti pensare in termini di errori in dollari o euro, non in percentuali di errore.

Fondamentalmente, la causa principale è che queste previsioni sono isolate e non ricevono alcun feedback dal business effettivo. L’accuratezza delle previsioni è solo un artefatto numerico; non è un ritorno sugli investimenti reale e tangibile per l’azienda. Come prova aneddotica, se avessi ricevuto una busta paga extra di mille dollari ogni volta che ho avuto una discussione al telefono con un direttore della supply chain che mi ha detto che stava avviando una nuova iniziativa per migliorare l’accuratezza delle previsioni, sarei un uomo ancora più ricco.

La conclusione è che, in termini di soluzione ristrutturata, finché le previsioni sono nude, non funzioneranno. Devi metterci dei vestiti, e quei vestiti sono decisioni. Come abbiamo esplorato nella precedente lezione sull’ottimizzazione sperimentale, se le previsioni non sono direttamente collegate alla vita reale, a decisioni tangibili, come quanto acquistare, quanto produrre o se aumentare o diminuire i prezzi, non otterrai mai il feedback reale che conta. Il feedback reale che conta non è l’indicatore KPI del back-test sulla misurazione; ciò che conta sono quelle decisioni. Pertanto, in termini di soluzione ristrutturata per affrontare l’anti-pattern del Naked Forecast, fondamentalmente devi decidere che le stesse persone che generano le previsioni devono convivere con le conseguenze di quelle previsioni quando si tratta delle effettive decisioni sulla supply chain che vengono implementate su di esse.

Il secondo sarebbe il mitico livello di servizio al 100%. La situazione di solito inizia così: il consiglio di amministrazione si riunisce e, da qualche parte sulla stampa o sui social network, alcune persone si lamentano rumorosamente della qualità del servizio. Non sembra bene per l’azienda, sembra che l’azienda non stia rispettando le promesse fatte. Il consiglio mette una pressione enorme sul CEO perché faccia qualcosa riguardo a questo problema di qualità del servizio, che sta influenzando negativamente il marchio, l’immagine e potenzialmente la crescita dell’azienda. Il CEO dice: “Dobbiamo davvero porre fine a questa infinita serie di problemi di qualità del servizio”. Quindi, il CEO si rivolge al VP della Supply Chain e gli chiede di porre fine a questi problemi di qualità del servizio. Il VP della Supply Chain, a sua volta, chiede al Direttore della Supply Chain di fare lo stesso, e il Direttore della Supply Chain chiede al Responsabile della Supply Chain di affrontare il problema. Il Responsabile della Supply Chain quindi aumenta il livello di servizio a un valore molto alto, vicino al 100%.

Ecco, anche se nel breve termine si ottengono livelli di servizio leggermente più alti, molto presto i problemi di qualità del servizio tornano. Questi livelli di servizio più alti non sono sostenibili e si finisce con fluttuazioni di inventario, inventario sprecato e, anche se l’intento era quello di aumentare il livello di servizio, spesso si ottengono livelli di servizio più bassi sei o dodici mesi dopo.

La causa principale qui non è solo l’ignoranza, ma anche il pensiero illusorio. Matematicamente parlando, se si desidera un livello di servizio al 100%, significa una quantità infinita di inventario, che tecnicamente non è possibile. Si ha questa potente illusione che si possa affrontare completamente questo problema, anche se non è possibile. Al massimo, si possono mitigare i problemi di qualità del servizio; non si possono mai eliminare completamente.

In termini di prove aneddotiche, ho visto che molte aziende hanno maggiori difficoltà perché hanno questa mentalità del mitico obiettivo del livello di servizio al 100%. Se la tua azienda non è disposta ad accettare che, per alcuni prodotti (non tutti o i più importanti), i livelli di servizio saranno effettivamente abbassati intenzionalmente, allora stai andando incontro a seri problemi. L’unico modo per migliorare effettivamente la qualità del servizio è prima accettare che se il focus è su tutto, è equivalente a dire che il focus è su nulla. Finché non sei pronto ad accettare che, per alcuni SKU, avrai un livello di servizio più basso intenzionalmente come risultato accettabile, non sarai in grado di migliorare la tua qualità del servizio complessiva.

In termini di soluzioni ristrutturate, la soluzione ristrutturata sono i driver economici. È un punto che ho presentato nella seconda lezione del primo capitolo, la visione per la catena di approvvigionamento quantitativa. I driver economici mostrano che hai il costo delle rotture di stock e il costo di gestione, e c’è un equilibrio da trovare. Non puoi semplicemente puntare a un livello di servizio del 100% perché è completamente sbilanciato dal punto di vista economico; non è sostenibile. Cercare di spingere in questa direzione è molto fuorviante perché danneggia solo l’azienda. La soluzione è iniettare una sana dose di driver economici nella tua pratica di supply chain.

Ora, il terzo anti-pattern, l’iniziazione Jedi, può essere osservato quando i vertici aziendali di molte grandi aziende sono sotto costante pressione dai media a causa del costante flusso di parole di moda che si dirigono verso di loro. Queste parole di moda includono intelligenza artificiale, blockchain, cloud computing, big data, IoT, ecc. Gli influencer dicono loro che se la loro azienda non si adatta a queste tendenze, diventerà obsoleta. C’è una costante paura di perdere l’occasione, che agisce come una potente forza, applicando una pressione costante sui vertici aziendali della maggior parte delle grandi aziende che gestiscono grandi catene di approvvigionamento.

I sintomi dell’iniziazione Jedi possono essere osservati se la tua azienda ha una divisione con giovani ingegneri entusiasti che hanno parole di moda nei loro titoli di lavoro, come ricercatori di intelligenza artificiale, ingegneri blockchain o scienziati della supply chain. Il motto è “padroneggiare la forza”, la forza è la parola di moda di interesse in quel momento. La direzione prende persone giovani o inesperte e dice loro di fare qualcosa di grandioso per l’azienda, ma senza essere coinvolti o familiari con gli aspetti tecnici di questi concetti.

Quello che succede è che queste squadre creano prototipi interessanti che alla fine non riescono a fornire valore concreto nel mondo reale per l’azienda. Di conseguenza, anche se è iniziato con l’idea che l’azienda sarebbe stata rivoluzionata secondo la parola di moda del giorno, le pratiche e la tecnologia legacy rimangono prevalenti, non modificate dalla parola di moda o dalla squadra aggiuntiva creata attorno ad essa.

In termini di prove aneddotiche, al giorno d’oggi, nel 2021, la stragrande maggioranza delle aziende con un team di data science non ottiene alcun rendimento dal loro investimento. Il team di data science crea prototipi Python fantasiosi utilizzando librerie open-source molto interessanti, ma in termini di ritorno sull’investimento pratico per la stragrande maggioranza del mercato, è esattamente zero. Questo è esattamente il tipo di iniziazione Jedi in cui i vertici aziendali cadono: leggono sulla stampa che la data science è la nuova tendenza, quindi assumono un team di data science. Come curiosità aneddotica, vedo che questi team non sono solo piuttosto giovani e inesperti, ma rimangono tali nel tempo. Questo perché il turnover è molto elevato. Puoi avere un’azienda molto solida e robusta, in cui il turnover medio è di solito di cinque-dieci anni, tranne per il team di data science, dove le persone rimangono in media per 18 mesi. Uno dei motivi per cui non esce nulla di valore da questi team è che le persone entrano, fanno alcuni prototipi e poi se ne vanno. Per l’azienda non c’è capitalizzazione e non riesce mai davvero a trasformarsi.

In termini di ristrutturazione di questa soluzione, innanzitutto non c’è altra soluzione se non guidare con l’esempio. Se vuoi effettivamente fare data science, allora i vertici aziendali devono essere molto competenti in materia di data science. Ad esempio, Jeff Bezos ha dimostrato familiarità con le tecniche di machine learning all’avanguardia del suo tempo. Amazon può avere molto successo con il machine learning, ma succede perché i vertici aziendali sono molto familiari con i dettagli. Guidare con l’esempio è essenziale.

In secondo luogo, devi assicurarti che quando assumi questi giovani, entusiasti e potenzialmente talentuosi ingegneri, li confronti con problemi reali, non con problemi meta. Deve essere collegato alla realtà. Questo torna alla mia precedente lezione sull’ottimizzazione empirica ed sperimentale. Se assumi un data scientist per fare la segmentazione dei clienti o un’analisi ABC migliore per la tua azienda, questi non sono problemi reali. Sono solo numeri inventati. Se assumi queste persone e le metti a capo del rifornimento effettivo e le rendi responsabili delle quantità esatte da rifornire da una serie di fornitori, questo è molto reale. Questo è il motivo per cui, dieci anni fa, Lokad è passata internamente da data scientist a supply chain scientist. L’obiettivo era avere un impegno completamente diverso e allontanarsi da questo antipattern di iniziazione Jedi.

L’orrore non euclideo. In questo contesto, hai un’azienda che gestisce una grande supply chain e il panorama IT è molto complesso. Ci sono diversi software aziendali, come ERP, WMS ed EDI, che sono complessi di per sé. Poi hai tutta la colla che collega queste cose insieme e l’intera immagine è straordinariamente complessa. Quindi, come sai di essere effettivamente in un’azienda che sta affrontando una soluzione non adeguata? Quali sono i sintomi? I sintomi sono che tutti in azienda sentono che c’è un’incompetenza dilagante nella divisione IT. Le persone dell’IT sembrano sopraffatte e sembrano non capire cosa sta succedendo nel sistema che dovrebbero gestire e far funzionare. Un altro sintomo è che si verificano problemi IT che influiscono sulla produzione quotidianamente. Questi sono i sintomi chiave della soluzione non adeguata.

La conseguenza di avere un panorama IT non adeguato è che i cambiamenti che devono essere apportati all’azienda, e di solito, quando c’è un cambiamento da apportare all’azienda, ci sono anche dei cambiamenti da apportare ai sistemi IT. Le moderne supply chain sono molto guidate dai loro componenti software. Tutti questi cambiamenti avvengono molto lentamente ed è sempre un processo noioso in cui anche i piccoli cambiamenti richiedono una vita. Ogni volta che c’è un qualsiasi grado di cambiamento, di solito ci sono tonnellate di regressioni. Come si dice, si fanno due passi avanti e tre indietro, poi si fanno di nuovo due passi avanti e uno indietro. Il cambiamento non è solo lento, ma comporta anche un flusso costante di regressione. La situazione non migliora realmente nel tempo; al massimo si stagna.

In termini di cause principali, la direzione non si preoccupa davvero dei dettagli, e la direzione non IT non si preoccupa davvero di tutti quei sistemi IT. Questo porta a un approccio che chiamo incrementalismo, in cui qualsiasi cambiamento che vogliono che avvenga nel sistema IT dell’azienda, quei cambiamenti saranno richiesti dalle supply chain, ad esempio. Ogni volta che c’è un cambiamento che deve avvenire, la direzione dirà sempre: “Per favore, prendi il percorso più facile, il percorso che richiede il minor sforzo e il minor tempo in modo da poter vedere questo implementato il più rapidamente possibile.” Di questo si tratta l’incrementalismo.

Credo che l’incrementalismo sia una causa radice molto pericolosa. Il problema dell’incrementalismo è che è letteralmente una morte per mille tagli. Ogni singolo cambiamento che viene apportato al sistema lo rende un po’ più complesso, un po’ più difficile da gestire e un po’ più difficile da testare. Sebbene ogni singolo cambiamento individualmente sia insignificante, quando accumuli un decennio di dozzine di cambiamenti apportati ai sistemi IT quotidianamente, ti ritrovi con un oceano di complessità. Ogni cambiamento ha reso il sistema più complesso e l’immagine generale è completamente persa. Avanti veloce di un decennio e ti ritrovi con un sistema massiccio e contorto che sembra folle.

Come esempio di prova, puoi vedere che ci sono ancora grandi aziende di e-commerce in cui, come consumatore, puoi regolarmente vedere che hanno tempi di inattività. Queste cose non dovrebbero mai accadere. Come azienda di e-commerce nel 2021, il tuo tempo di attività dovrebbe essere qualcosa come consentire 10 minuti di inattività all’anno. Ogni singolo secondo di inattività è un’opportunità sprecata. Progettare software per il carrello della spesa nel 2021 non è più una scienza missilistica; è in realtà un software molto semplice per quanto riguarda il software aziendale. Non c’è motivo di non avere qualcosa che sia sempre attivo. Tuttavia, la realtà è che quando vedi l’e-commerce andare giù, di solito non è il carrello della spesa che fallisce; è una soluzione non acclimatata che si trova proprio dietro l’e-commerce. L’e-commerce inattivo è solo il riflesso di un problema che è accaduto da qualche parte nel panorama IT.

Se vogliamo rifattorizzare la soluzione non acclimatata, dovremmo smettere di cercare la soluzione più facile per apportare cambiamenti. Dobbiamo pensare non a una soluzione facile, ma a una soluzione semplice. Una soluzione semplice differisce dalla soluzione facile in un modo cruciale: rende l’intero panorama un po’ più ordinato e sano, rendendo più facile apportare ulteriori cambiamenti in seguito. Potresti dire: “Ma è solo una questione puramente tecnica, quindi questo è il lavoro dell’IT.” Io direi di no, assolutamente no. È molto più un problema di supply chain. Adottare una soluzione semplice non è una questione di avere una soluzione semplice dal punto di vista dell’IT; è avere una soluzione semplice dal punto di vista della supply chain.

La semplicità della soluzione e la sua conseguenza intenzionale di rendere più facile l’implementazione di cambiamenti successivi dipendono dalla tua roadmap. Che tipo di cambiamenti futuri vuoi apportare al tuo panorama IT? L’IT, come divisione, non ha il tempo di essere esperto di supply chain e di sapere esattamente dove vuoi guidare l’azienda tra dieci anni in termini di esecuzione della supply chain. Deve essere la gestione della supply chain che ha questa visione e deve guidare lo sviluppo, potenzialmente con il supporto dell’IT, in una direzione in cui i cambiamenti diventano sempre più facili da implementare nel tempo.

Infine, come ultimo antipattern per oggi, l’avvocato del diavolo. Il contesto è tipicamente una grande azienda che ha avuto significativi problemi di supply chain e ha deciso di affidarsi a un grande fornitore, mettendo molti soldi sul tavolo. L’iniziativa viene avviata e, qualche mese dopo, di solito sei mesi circa, il fornitore ha molto poco da mostrare. Sono stati spinti molti soldi verso il fornitore e c’è molto poco da mostrare. A proposito, nel 2021, sei mesi sono molto tempo. Se hai un’iniziativa software che non produce risultati tangibili e di qualità produttiva in sei mesi, dovresti preoccuparti molto perché, secondo la mia esperienza, se non riesci a ottenere risultati tangibili in sei mesi, le probabilità che l’iniziativa sia destinata al fallimento sono alte e non avrai mai un ROI positivo per l’azienda.

Quello che succede è che la direzione vede il progetto subire ritardi e c’è molto poco da mostrare. La direzione, anziché diventare sempre più aggressiva nei confronti del fornitore tecnologico e stare all’avanguardia del fornitore tecnologico, improvvisamente cambia fronte e diventa molto difensiva nei confronti del fornitore. Questo è molto sorprendente. Si avvia una grande iniziativa, si dà molti soldi a un’altra azienda e l’iniziativa va avanti ma male e ha poco da mostrare. Invece di chiarire che l’iniziativa sta effettivamente fallendo, la direzione raddoppia e inizia a difendere il fornitore, il che è molto strano. È come se ci fosse una sorta di sindrome di Stoccolma in gioco, dove qualcuno ti fa del male, ma se ti fa abbastanza male, a un certo punto inizi a piacere a quelle persone.

La direzione e l’iniziativa stessa diventano troppo grandi per fallire e di conseguenza si spreca un sacco di denaro e si perde un’enorme opportunità, soprattutto in termini di tempo. Man mano che l’iniziativa va avanti, si perdono soldi, ma ancora più importante, si perde tempo: sei mesi, un anno, due anni. Il costo reale è il tempo. Come prova aneddotica di questo tipo di situazione, si può leggere molto spesso sulla stampa di fallimenti su larga scala nell’implementazione di ERP per progetti che durano quasi un decennio o a volte cinque-dieci anni. Si pensa, come si può avere un progetto di cinque anni? La risposta è che le persone continuano a raddoppiare su questo progetto e ci vogliono letteralmente anni e anni per ammettere finalmente che è stato un completo fallimento e che non avrebbe mai funzionato.

Un altro piccolo esempio di prova aneddotica è che, avendo assistito dall’interno a quelle implementazioni di ERP su larga scala che durano anni, accade spesso che il progetto non si interrompa perché le persone sono d’accordo sul fatto che il fornitore abbia effettivamente fallito. Il modo in cui viene gestita la situazione è che a un certo punto, la direzione superiore coinvolta nella decisione di portare il fornitore iniziale si sposta semplicemente verso altre aziende. Quando tutte quelle persone che facevano inizialmente parte della decisione di portare il grande fornitore se ne sono andate dall’azienda, le altre persone che non si sentono così impegnate nei confronti di questo particolare fornitore si mettono d’accordo per chiudere il progetto e dargli una conclusione.

In termini di soluzione ristrutturata, credo che le aziende debbano essere più tolleranti verso il fallimento. Bisogna essere duri con i problemi ma gentili con le persone. Se si coltiva una cultura in cui si dice cose come “Dobbiamo farlo bene fin da subito”, questo è molto dannoso perché significa che si avranno meno fallimenti. È un fraintendimento della mente umana e della natura umana pensare che se si ha una cultura che tollera il fallimento, si ottengono effettivamente più fallimenti. Sì, si ottengono marginalemnte più piccoli fallimenti, ma ciò che si ottiene sono persone inclini a riconoscere gli errori e andare avanti. Se, al contrario, si ha una cultura del “farlo bene fin da subito”, allora fondamentalmente nessuno può perdere la faccia. Quindi, anche quando c’è qualcosa di completamente disfunzionale, l’istinto di sopravvivenza delle persone coinvolte consiste nel raddoppiare su questa cosa che non funziona solo per preservare la loro faccia e potenzialmente passare a un’altra azienda in modo da non dover affrontare le conseguenze dei loro errori.

Per riassumere, abbiamo la conoscenza positiva rispetto alla conoscenza negativa. La conoscenza positiva riguarda essenzialmente la risoluzione dei problemi; è una sorta di intelligenza da dottorato, un tipo di intelligenza basata sulla risoluzione dei problemi, in cui abbiamo enigmi e possiamo passare da una soluzione a una soluzione migliore. È possibile valutare che una soluzione sia migliore dell’altra e l’apice di questo tipo di pensiero è raggiungere una soluzione ottimale. Tuttavia, ciò che le persone pensano di cercare - soluzioni ottimali che siano perfettamente valide e immortali - è ciò che ottengono sono soluzioni molto effimere.

Come esempio, nel corso della vita di Lokad, la mia azienda, abbiamo attraversato sei generazioni di motori di previsione. La conoscenza positiva è effimera nel senso che questa conoscenza, questa soluzione, è a rischio quando arriva qualcosa di migliore e si scarta semplicemente questo pezzo di conoscenza. Da Lokad, abbiamo affrontato l’arduo compito di riscrivere la nostra stessa tecnologia di previsione da zero sei volte fin dall’inizio nel 2008. Ecco perché dico che la conoscenza positiva è molto effimera perché diventa obsoleta rapidamente quando arrivano nuove soluzioni migliori.

Al contrario, se si guarda alla conoscenza negativa, è una prospettiva completamente diversa. Si pensa in termini di errori gravi e il tipo di intelligenza che si vuole catturare è l’intelligenza da strada, il tipo che ti aiuta a sopravvivere in una strada pericolosa di notte. L’attenzione non è tanto sugli enigmi o sulle cose molto complicate da capire e che comportano un trasferimento; è più su ciò che non si sa o sui tabù. Non è ciò che non si sa; è ciò che le persone non ti diranno, o il tipo di cose in cui le persone ti mentiranno anche solo perché vogliono salvare la faccia. La conoscenza negativa riguarda la lotta contro tutti quei tabù che ti impediscono di vedere la realtà per quello che è.

Con la conoscenza negativa, la mentalità non è quella del progresso; è una mentalità di sopravvivenza. Vuoi solo sopravvivere in modo da poter combattere un altro giorno. È una prospettiva molto diversa e è esattamente il tipo di cosa che le aziende cercano istintivamente quando assumono un direttore della supply chain molto esperto. Vogliono assicurarsi che attraverso questa persona, l’azienda possa vivere un altro giorno. Quello che potrebbe sorprendere è che la conoscenza negativa tende ad essere molto più duratura. Questi sono praticamente i difetti della natura umana che sono coinvolti e non cambiano nel tempo solo perché c’è una nuova tecnologia, un nuovo approccio o un nuovo metodo. Queste cose sono qui per restare.

In conclusione, direi che la conoscenza negativa è di primaria importanza per tutti i problemi complessi, la supply chain è solo il focus di interesse di questa lezione, ma non è l’unico ambito in cui la conoscenza negativa può essere applicata.

Gli anti-pattern della supply chain sono solo alcuni esempi, ma sono abbastanza sicuro che se ne potrebbero individuare decine di altri per catturare i problemi che continuano a verificarsi nelle supply chain del mondo reale. Non possiamo sperare di catturare tutto attraverso gli anti-pattern, ma credo che possiamo catturare una buona parte. Dopo aver letto un libro sugli anti-pattern del software, la mia opinione soggettiva era che avevo acquisito l’equivalente di cinque anni di esperienza nell’ingegneria del software in soli 200 pagine. La mia speranza è che per una raccolta di anti-pattern della supply chain, potremmo replicare anche questo effetto, dove qualcuno potrebbe acquisire qualcosa come cinque anni di esperienza in un periodo di tempo molto più breve, forse solo poche settimane.

Questo è tutto per questa lezione. La prossima lezione sarà sulla valutazione dei fornitori, che è un problema molto interessante. Le supply chain moderne vivono o muoiono in base ai prodotti software che le supportano e la domanda è come ragionare su quei prodotti software e come scegliere quelli giusti e i fornitori giusti. Nonostante abbia avuto la mia giusta dose di conflitti di interesse, è un problema interessante e la domanda è come possiamo avere una metodologia in cui anche se tutte le persone hanno dei pregiudizi, possiamo ottenere dei risultati imparziali dal metodo.

Ora, risponderò alle domande.

Domanda: Cosa costituisce una buona previsione in un contesto di ottimizzazione probabilistica e come misurarne la qualità? C’è un ruolo per gli arricchimenti manuali?

Una buona previsione probabilistica ha metriche per le accuratezze probabilistiche, ma probabilmente non è quello a cui stai guardando. Come parte di un’iniziativa di ottimizzazione sperimentale, vorrai ottimizzare. Metriche come entropia incrociata o verosimiglianza si applicano alle previsioni probabilistiche. Ancora più importante, ci saranno cose che scoprirai gradualmente mentre identifichi decisioni insensate. La previsione è solo un mezzo per un fine, che è la decisione. Devi prestare attenzione alle decisioni. Abbiamo accennato brevemente a questo nella lezione precedente sull’ottimizzazione sperimentale. Il processo è lo stesso per le previsioni classiche o probabilistiche. Se vuoi avere esempi concreti di previsioni probabilistiche, questo sarà trattato ampiamente nelle lezioni successive. Mi scuso se mi sto allontanando un po’ nel rispondere a questa domanda.

Domanda: Cosa ne pensi dell’uso dell’AI (Appreciative Inquiry) per supportare la tua AI (Intelligenza Artificiale)? Quali tecniche utilizzerai per trovare logicamente grandi set di dati e perché i tassi di conversione stanno diminuendo nonostante le buone prestazioni complessive? Cosa affrontare per causare l’attività?

L’IA, come insieme di algoritmi, è principalmente deep learning al momento. Il deep learning è un insieme di tecniche molto capaci di gestire dati altamente non strutturati. La domanda che dovresti davvero farti è come collegare tutto ciò alla realtà. Nella supply chain, i dati tendono ad essere molto sparsi. La maggior parte dei prodotti in un determinato negozio viene venduta a meno di un’unità al giorno. I grandi set di dati sono grandi solo in aggregato quando si guarda a un’azienda molto grande con tonnellate di transazioni. Se guardi alle granularità che contano davvero, non hai così tanti dati.

L’appreciative inquiry, in termini di metodologie, riguarda davvero l’ottimizzazione sperimentale discussa nella lezione precedente.

Domanda: Molti manager non capiscono il potere della scienza dei dati e dare loro problemi finti è una strada sicura. Se non vogliono approfondire l’apprendimento sulla scienza dei dati, qual è un modo alternativo per far loro credere nella scienza dei dati e nell’approccio decisionale? Come iniziare in piccolo e implementare in grande?

Prima di tutto, se hai persone che non credono in una tecnologia, va benissimo. Prendi ad esempio Warren Buffett. È un investitore molto ricco che ha passato la sua vita investendo in aziende che capisce. Investe in aziende con modelli di business semplicistici, come aziende di trasporto ferroviario o aziende di leasing di mobili. Warren Buffett ha detto: “Non sono interessato a capire tutte quelle tecnologie”. Ad esempio, quando le persone gli chiedevano perché non investisse in Google, Buffett rispondeva: “Non capisco nulla di quello che sta facendo Google, quindi anche se potrebbe essere un buon investimento, non sono abbastanza intelligente per quello. Mi limiterò ad investire in aziende che capisco”.

Il mio punto è che, per la gestione, penso che sia una completa illusione avventurarsi in aree che non si capiscono. Ad un certo punto, se non sei disposto a fare lo sforzo, semplicemente non funzionerà. Questo è il modello anti-Jedi in azione: la gestione non è disposta a fare alcuno sforzo e pensa che assumere ingegneri intelligenti, giovani e intelligenti farà il trucco. Se fosse così, Amazon non avrebbe avuto il successo che ha avuto. Se fosse possibile per un’azienda tradizionale di catena di vendita al dettaglio assumere alcuni ingegneri per avviare un sito di e-commerce e competere con Amazon, lo avrebbero fatto tutte. Fino al 2005 circa, queste aziende avevano risorse e capacità ingegneristiche significativamente superiori rispetto ad Amazon stesso.

Il problema è che è un’illusione, ed è di questo che si tratta la conoscenza negativa: fare luce su quei tipi di problemi che sono ubiqui. Ecco perché hai bisogno di un titolo accattivante per comunicare il problema ai manager. Non dovresti nemmeno avere paura di imparare cose nuove. Quando prendi davvero la parte buona della nuova tecnologia, di solito non è così complicata. Non tutto è super tecnico; molte parti potrebbero essere spiegate. Ad esempio, anche qualcosa come le blockchain: la metà di quelle tecnologie blockchain supposte super avanzate potrebbe essere spiegata a un bambino di 10 anni. Molte delle idee dietro queste tecnologie sono in realtà abbastanza semplici. Ci sono tonnellate di tecnicismi matematici accidentali che sono molto difficili, ma non è l’essenza del problema.

Quindi, la mia risposta a te sarebbe che se la gestione vuole credere alle favole, non c’è molto che si possa fare in quella situazione. Se la gestione è disposta a investire nella scienza dei dati, dovrebbe essere anche disposta a investire un po’ di tempo per capire di cosa si tratta la scienza dei dati. Altrimenti, è solo un’illusione.

Questo è tutto per oggi. Grazie mille e la prossima lezione sarà nello stesso giorno, mercoledì, tra due settimane, alla stessa ora. Ci vediamo allora.

Riferimenti

• ‘‘AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis’’. di William J. Brown, Raphael C. Malveau, Hays W. “Skip” McCormick, Thomas J. Mowbray, 1998