00:00 Introduzione
02:31 Cause radice dei fallimenti nel mondo reale
07:20 Prodotto finale: una ricetta numerica 1/2
09:31 Prodotto finale: una ricetta numerica 2/2
13:01 La storia finora
14:57 Completare le attività di oggi
15:59 Cronologia dell’iniziativa
21:48 Ambito: panorama applicativo 1/2
24:24 Ambito: panorama applicativo 2/2
27:12 Ambito: effetti di sistema 1/2
29:21 Ambito: effetti di sistema 2/2
32:12 Ruoli: 1/2
37:31 Ruoli: 2/2
41:50 Pipeline dei dati - Come
44:13 Una parola sui sistemi transazionali
49:13 Una parola sul data lake
52:59 Una parola sui sistemi analitici
57:56 Salute dei dati: livello basso
01:02:23 Salute dei dati: livello alto
01:06:24 Ispettori dei dati
01:08:53 Conclusioni
01:10:32 Prossima lezione e domande del pubblico
Descrizione
Condurre con successo un’ottimizzazione predittiva della supply chain è una combinazione di problemi soft e hard. Purtroppo, non è possibile separare questi aspetti. I fattori soft e hard sono profondamente intrecciati. Di solito, questo intreccio si scontra frontalmente con la divisione del lavoro definita dall’organigramma dell’azienda. Osserviamo che, quando le iniziative sulla supply chain falliscono, le cause principali del fallimento sono di solito errori commessi nelle prime fasi del progetto. Inoltre, gli errori iniziali tendono a plasmare l’intera iniziativa, rendendoli quasi impossibili da correggere in seguito. Presentiamo le nostre principali scoperte per evitare tali errori.
Trascrizione completa
Benvenuti a questa serie di lezioni sulla supply chain. Sono Joannes Vermorel e oggi presenterò “Iniziare con un’iniziativa quantitativa sulla supply chain.” La maggior parte delle iniziative di analisi dei dati sulla supply chain fallisce. Dal 1990, la maggior parte delle aziende che gestiscono grandi supply chain ha lanciato importanti iniziative di ottimizzazione predittiva ogni tre o cinque anni con pochi o nessun risultato. Oggi, la maggior parte dei team nella supply chain o nella scienza dei dati, avviando un altro ciclo di ottimizzazione predittiva - tipicamente definito come un progetto di previsione o un progetto di ottimizzazione degli inventari - non si rende nemmeno conto che la propria azienda è già stata lì, ha già fatto tutto ciò e ha già fallito forse mezza dozzina di volte.
Andare avanti con un altro ciclo è talvolta motivato dalla convinzione che questa volta sarà diverso, ma spesso i team non sono nemmeno consapevoli dei numerosi tentativi falliti che sono stati fatti in precedenza. Una prova aneddotica di questa situazione è che Microsoft Excel rimane lo strumento numero uno per prendere decisioni sulla supply chain, mentre quelle iniziative avrebbero dovuto sostituire i fogli di calcolo con strumenti migliori. Eppure, al giorno d’oggi ci sono ancora pochissime supply chain che possono funzionare senza fogli di calcolo.
Lo scopo di questa lezione è capire come dare una possibilità di successo a un’iniziativa sulla supply chain che intende fornire qualsiasi tipo di ottimizzazione predittiva. Esamineremo una serie di ingredienti critici - questi ingredienti sono semplici eppure molto spesso risultano controintuitivi per la maggior parte delle organizzazioni. Al contrario, esamineremo una serie di anti-pattern che quasi garantiscono il fallimento di tale iniziativa.
Oggi, il mio focus è sull’esecuzione tattica dell’inizio stesso di un’iniziativa sulla supply chain con una mentalità “fai le cose”. Non discuterò delle grandi implicazioni strategiche per l’azienda. La strategia è molto importante, ma ne parlerò in una lezione successiva.
La maggior parte delle iniziative sulla supply chain fallisce e il problema viene raramente menzionato pubblicamente. L’accademia pubblica decine di migliaia di articoli all’anno che vantano ogni tipo di innovazione nella supply chain, compresi framework, algoritmi e modelli. Spesso, gli articoli affermano persino che l’innovazione è stata messa in produzione da qualche parte. Eppure, la mia osservazione informale del mondo della supply chain è che queste innovazioni non si vedono da nessuna parte. Allo stesso modo, i fornitori di software promettono da tre decenni sostituti superiori per i fogli di calcolo e ancora una volta, la mia osservazione informale indica che i fogli di calcolo sono ancora onnipresenti.
Stiamo riprendendo un punto che è stato già toccato nel secondo capitolo di questa serie di lezioni sulla supply chain. In poche parole, le persone non hanno alcun incentivo a pubblicizzare il fallimento e quindi non lo fanno. Inoltre, poiché le aziende che gestiscono supply chain tendono ad essere grandi, il problema è tipicamente aggravato dalla naturale perdita di memoria istituzionale mentre i dipendenti si spostano da una posizione all’altra. Ecco perché né l’accademia né i fornitori riconoscono questa situazione piuttosto triste.
Propongo di iniziare con un breve sondaggio sulle cause più frequenti di fallimento dal punto di vista dell’esecuzione tattica. Infatti, queste cause sono tipicamente riscontrate nella fase iniziale dell’iniziativa.
La prima causa di fallimento è il tentativo di risolvere problemi sbagliati - problemi che non esistono, che sono insignificanti o che riflettono una sorta di fraintendimento sulla supply chain stessa. Ottimizzare le percentuali di accuratezza delle previsioni è probabilmente l’archetipo di un problema errato del genere. Ridurre la percentuale di errore di previsione non si traduce direttamente in euro o dollari di ritorno per l’azienda. La stessa situazione si verifica quando un’azienda cerca specifici livelli di servizio per i suoi inventari. È molto raro avere qualche euro o dollaro di ritorno da mostrare in cambio.
La seconda causa di fallimento è l’utilizzo di tecnologie software e design software non adatti. Ad esempio, i fornitori di ERP cercano invariabilmente di utilizzare un database transazionale per supportare le iniziative di analisi dei dati perché è ciò su cui si basa l’ERP. Al contrario, i team di data science cercano invariabilmente di utilizzare il toolkit di machine learning open-source all’avanguardia del momento perché è una cosa cool da fare. Purtroppo, le tecnologie non adatte generano tipicamente un’enorme frizione e molta complessità accidentale.
La terza causa di fallimento è una divisione del lavoro e un’organizzazione errate. Nel tentativo sbagliato di allocare specialisti in ogni fase del processo, le aziende tendono a frammentare l’iniziativa su troppe persone. Ad esempio, la preparazione dei dati viene molto spesso effettuata da persone che non sono responsabili delle previsioni. Di conseguenza, situazioni di garbage-in-garbage-out sono ovunque. Diluire marginalmente la responsabilità delle decisioni finali sulla supply chain è una ricetta per il fallimento.
Un elemento che non ho elencato in questo breve elenco come causa principale è il cattivo dato. I dati sono spesso additati come causa dei fallimenti delle iniziative di supply chain, il che è molto comodo, poiché i dati non possono rispondere esattamente a quelle accuse. Tuttavia, di solito i dati non sono responsabili, almeno non nel senso di lottare con dati errati. La supply chain delle grandi aziende è diventata digitale decenni fa. Ogni articolo che viene acquistato, trasportato, trasformato, prodotto o venduto ha registri elettronici. Quei registri potrebbero non essere perfetti, ma di solito sono molto accurati. Se le persone non riescono a gestire correttamente i dati, non è davvero la transazione a essere responsabile.
Perché un’iniziativa quantitativa abbia successo, dobbiamo combattere la battaglia giusta. Cosa stiamo cercando di ottenere in primo luogo? Uno dei principali risultati per una supply chain quantitativa è una ricetta numerica di base che calcola le decisioni finali della supply chain. Questo aspetto è stato già discusso nella Lezione 1.3 nel primo capitolo, “Consegna orientata al prodotto per la supply chain”. Rivediamo le due proprietà più critiche di questo risultato.
Prima di tutto, l’output deve essere una decisione. Ad esempio, decidere quante unità riordinare oggi per un determinato SKU è una decisione. Al contrario, prevedere quante unità saranno richieste oggi per un determinato SKU è un artefatto numerico. Per generare una decisione che sia il risultato finale, sono necessari molti risultati intermedi, cioè molti artefatti numerici. Tuttavia, non dobbiamo confondere i mezzi con il fine.
La seconda proprietà di questo risultato è che l’output, che è una decisione, deve essere completamente automatizzato come risultato di un processo software puramente automatizzato. La ricetta numerica stessa, la ricetta numerica di base, non deve coinvolgere alcuna operazione manuale. Naturalmente, la progettazione della ricetta numerica stessa dipende molto da un esperto umano in ambito scientifico. Tuttavia, l’esecuzione non dovrebbe dipendere da un intervento umano diretto.
Avere una ricetta numerica come risultato è essenziale per rendere l’iniziativa di supply chain un’impresa capitalista. La ricetta numerica diventa un asset produttivo che genera ritorni. La ricetta deve essere mantenuta, ma ciò richiede uno o due ordini di grandezza di meno persone rispetto agli approcci che coinvolgono gli esseri umani a livello di micro-decisione.
Tuttavia, molte iniziative di supply chain falliscono perché non inquadrano correttamente le decisioni di supply chain come risultato dell’iniziativa. Invece, queste iniziative si concentrano sulla consegna di artefatti numerici. Gli artefatti numerici sono intesi come ingredienti per arrivare alla risoluzione finale del problema, supportando tipicamente le decisioni stesse. Gli artefatti più comuni incontrati nella supply chain sono le previsioni, le scorte di sicurezza, i lotti economici, gli indicatori chiave di prestazione. Anche se questi numeri possono essere interessanti, non sono reali. Questi numeri non hanno un corrispondente fisico immediato nella supply chain e riflettono prospettive di modellazione arbitrarie sulla supply chain.
Concentrarsi sugli artefatti numerici porta al fallimento dell’iniziativa perché questi numeri mancano di un ingrediente fondamentale: un feedback diretto dal mondo reale. Quando la decisione è sbagliata, le conseguenze negative possono essere ricondotte alla decisione stessa. Tuttavia, la situazione è molto più ambigua per quanto riguarda gli artefatti numerici. Infatti, la responsabilità è diluita ovunque, poiché ci sono molti artefatti che contribuiscono ad ogni singola decisione. Il problema è ancora peggiore quando c’è un intervento umano in mezzo.
Questa mancanza di feedback si rivela fatale per gli artefatti numerici. Le moderne supply chain sono complesse. Scegliere una qualsiasi formula arbitraria per calcolare una scorta di sicurezza, una quantità economica di ordine o un KPI; ci sono probabilità schiaccianti che questa formula sia sbagliata in tutti i modi possibili. Il problema della correttezza della formula non è un problema matematico; è un problema aziendale. Si tratta di rispondere alla domanda: “Questa calcolo riflette veramente l’intento strategico che ho per la mia azienda?” La risposta varia da un’azienda all’altra e varia anche da un anno all’altro poiché le aziende si evolvono nel tempo.
Poiché gli artefatti numerici mancano di un feedback diretto dal mondo reale, mancano del meccanismo stesso che consente di iterare da un’implementazione iniziale ingenua, semplicistica e molto probabilmente ampiamente errata verso una versione approssimativamente corretta della formula che potrebbe essere considerata di produzione. Tuttavia, gli artefatti numerici sono molto allettanti perché danno l’illusione di avvicinarsi alla soluzione. Danno l’illusione di essere razionali, scientifici, persino impegnativi. Abbiamo numeri, formule, algoritmi, modelli. È persino possibile fare benchmark e confrontare quei numeri con numeri altrettanto inventati. Migliorare rispetto a un benchmark inventato dà anche l’illusione di progresso ed è molto rassicurante. Ma alla fine della giornata, rimane un’illusione, una questione di prospettiva di modellazione.
Le aziende non ottengono profitti pagando le persone per guardare i KPI o fare benchmark. Ottengono profitti prendendo una decisione dopo l’altra e, sperabilmente, migliorando nel prendere la decisione successiva ogni volta.
Questa lezione fa parte di una serie di lezioni sulla supply chain. Sto cercando di mantenere queste lezioni in qualche modo indipendenti, ma siamo arrivati a un punto in cui ha più senso guardare queste lezioni in sequenza. Questa lezione è la prima lezione del settimo capitolo, che è dedicato all’esecuzione delle iniziative di supply chain. Con iniziative di supply chain intendo iniziative quantitative di supply chain, iniziative che intendono fornire qualcosa nell’ordine dell’ottimizzazione predittiva per l’azienda.
Il primo capitolo era dedicato alle mie opinioni sulla supply chain sia come campo di studio che come pratica. Nel secondo capitolo ho presentato una serie di metodologie essenziali per la supply chain, poiché le metodologie ingenua sono sconfitte a causa della natura avversaria di molte situazioni di supply chain. Nel terzo capitolo ho presentato una serie di personaggi della supply chain con un focus esclusivo sui problemi; in altre parole, su cosa stiamo cercando di risolvere?
Nel quarto capitolo ho presentato una serie di settori che, sebbene non siano propriamente supply chain, ritengo siano essenziali per una pratica moderna della supply chain. Nel quinto e sesto capitolo ho presentato gli elementi chiave di una ricetta numerica destinata a guidare le decisioni di supply chain, ovvero l’ottimizzazione predittiva (la prospettiva generalizzata delle previsioni) e la presa di decisioni (essenzialmente l’ottimizzazione matematica applicata ai problemi di supply chain). In questo settimo capitolo, discutiamo come mettere insieme questi elementi in un’iniziativa di supply chain effettiva che intende portare questi metodi e tecnologie in produzione.
Oggi, esamineremo ciò che viene considerata la pratica corretta per condurre un’iniziativa di supply chain. Ciò include la definizione dell’iniziativa con il giusto risultato atteso, di cui abbiamo appena discusso, ma anche con la giusta tempistica, la giusta portata e i giusti ruoli. Questi elementi rappresentano la prima parte della lezione di oggi.
La seconda parte della lezione sarà dedicata alla pipeline dei dati, un elemento critico per il successo di un’iniziativa basata sui dati o dipendente dai dati. Sebbene la pipeline dei dati sia un argomento piuttosto tecnico, richiede una corretta divisione del lavoro e un’organizzazione tra IT e supply chain. In particolare, vedremo che i controlli di qualità dovrebbero essere principalmente nelle mani della supply chain, con la progettazione di report sulla salute dei dati e ispettori dei dati.
L’onboarding è la prima fase dell’iniziativa, in cui viene sviluppata la ricetta numerica di base, quella che genera la decisione insieme solo a elementi di supporto. L’onboarding si conclude con un rollout progressivo in produzione e durante questo rollout, i processi precedenti vengono gradualmente automatizzati dalla stessa ricetta numerica.
Quando si considera la tempistica appropriata per la prima iniziativa quantitativa di supply chain in un’azienda, si potrebbe pensare che dipenda dalle dimensioni dell’azienda, dalla complessità, dal tipo di decisioni di supply chain e dal contesto generale. Sebbene sia vero in misura limitata, l’esperienza che Lokad ha raccolto in oltre un decennio e decine di tali iniziative indica che sei mesi sono quasi invariabilmente la tempistica appropriata. Sorprendentemente, questa tempistica di sei mesi ha poco a che fare con la tecnologia o anche con le specifiche della supply chain; ha molto più a che fare con le persone e le organizzazioni stesse e il tempo che impiegano per sentirsi a proprio agio con ciò che viene generalmente percepito come un modo molto diverso di condurre la supply chain.
I primi due mesi sono dedicati alla configurazione della pipeline dei dati. Torneremo su questo punto tra qualche minuto, ma questo ritardo di due mesi è causato da due fattori. Primo, dobbiamo rendere la pipeline dei dati affidabile ed eliminare problemi poco frequenti che potrebbero richiedere settimane per manifestarsi. Il secondo fattore è che dobbiamo capire la semantica dei dati, ovvero capire cosa significano i dati da una prospettiva di supply chain.
I mesi tre e quattro sono dedicati a iterazioni rapide sulla ricetta numerica stessa, che guiderà le decisioni di supply chain. Queste iterazioni sono necessarie perché generare decisioni finali effettive è di solito l’unico modo per valutare se c’è qualcosa di sbagliato o meno nella ricetta sottostante o in tutte le assunzioni incorporate nella ricetta. Questi due mesi sono anche tipicamente il tempo che i professionisti della supply chain impiegano per abituarsi alla prospettiva molto quantitativa e finanziaria che guida queste decisioni basate su software.
Infine, gli ultimi due mesi sono dedicati alla stabilizzazione della ricetta numerica dopo un periodo di iterazione rapida di solito piuttosto intenso. Questo periodo è anche l’opportunità per far funzionare la ricetta in un ambiente simile alla produzione, ma senza ancora guidare la produzione. Questa fase è importante affinché i team di supply chain acquisiscano fiducia in questa soluzione emergente.
Sebbene potrebbe essere desiderabile comprimere ulteriormente questa linea temporale, si è scoperto che è tipicamente molto difficile. La configurazione della pipeline dei dati può essere accelerata fino a un certo punto se l’infrastruttura IT adeguata è già in atto, ma acquisire familiarità con i dati richiede tempo per capire cosa significano i dati da una prospettiva di supply chain. Nella seconda fase, se l’iterazione sulla ricetta numerica converge molto rapidamente, allora è probabile che i team di supply chain inizino a esplorare le sfumature della ricetta numerica, il che estenderà anche il ritardo. Infine, gli ultimi due mesi sono tipicamente ciò che serve per vedere lo sviluppo della stagionalità e acquisire fiducia nel software che guida decisioni importanti di supply chain in produzione.
Nel complesso, ci vogliono circa sei mesi e, sebbene sarebbe auspicabile comprimerlo ulteriormente, è difficile farlo. Tuttavia, sei mesi sono già un periodo di tempo considerevole. Se fin dal primo giorno, il periodo di integrazione, in cui la ricetta numerica non guida ancora le decisioni di supply chain, si prevede che duri più di sei mesi, allora l’iniziativa è già a rischio. Se il ritardo aggiuntivo è associato all’estrazione dei dati e alla configurazione della pipeline dei dati, allora c’è un problema IT. Se il ritardo aggiuntivo è associato alla progettazione o configurazione della soluzione, eventualmente portata da un fornitore esterno, allora c’è un problema con la tecnologia stessa. Infine, se dopo due mesi di esecuzione stabile simile alla produzione, il rollout della produzione non avviene, allora di solito c’è un problema con la gestione dell’iniziativa.
Quando si cerca di introdurre una novità, un nuovo processo o una nuova tecnologia in un’organizzazione, la saggezza comune suggerisce di iniziare in modo piccolo, assicurandosi che funzioni e costruendo sul successo iniziale per espandersi gradualmente. Purtroppo, la supply chain non è gentile con la saggezza comune, e questa prospettiva ha un particolare twist riguardo alla definizione del perimetro della supply chain. In termini di definizione del perimetro, ci sono due forze trainanti principali che definiscono in larga misura cosa è e cosa non è un perimetro idoneo per quanto riguarda un’iniziativa di supply chain.
Il panorama applicativo è la prima forza che influenza la definizione del perimetro. Una supply chain nel suo complesso non può essere osservata direttamente; può essere osservata solo indirettamente attraverso gli occhiali del software aziendale. I dati saranno ottenuti attraverso questi pezzi di software. La complessità dell’iniziativa dipende molto dal numero e dalla diversità di questi pezzi di software. Ogni app è una propria fonte di dati, e estrarre e analizzare i dati da qualsiasi app aziendale tende ad essere un’impresa significativa. Gestire più app di solito significa gestire più tecnologie di database, terminologie inconsistenti, concetti inconsistenti e complicare notevolmente la situazione.
Pertanto, quando si stabilisce il perimetro, dobbiamo riconoscere che i confini idonei sono di solito definiti dalle stesse app aziendali e dalla loro struttura del database. In questo contesto, iniziare in modo piccolo deve essere inteso come mantenere l’impronta iniziale di integrazione dei dati il più piccola possibile, preservando al contempo l’integrità dell’iniziativa di supply chain nel suo complesso. È meglio andare in profondità anziché in ampiezza in termini di integrazione delle app. Una volta che si ha il sistema IT per ottenere alcuni record da una tabella in un’app data, di solito è semplice ottenere tutti i record da questa tabella e tutti i record da un’altra tabella nella stessa app.
Un errore comune nella definizione del perimetro consiste nel campionamento. Il campionamento di solito avviene attraverso la selezione di una breve lista di categorie di prodotti, siti o fornitori. Il campionamento è ben intenzionato, ma non segue i confini definiti dal panorama applicativo. Per implementare il campionamento, è necessario applicare filtri durante l’estrazione dei dati, e questo processo crea una serie di problemi che potrebbero mettere a rischio l’iniziativa di supply chain.
In primo luogo, l’estrazione filtrata dei dati da un software aziendale richiede più sforzo da parte del team IT rispetto a un’estrazione non filtrata. I filtri devono essere progettati in primo luogo, e il processo di filtraggio stesso è soggetto a errori. Risolvere i filtri errati è inevitabilmente noioso perché richiede numerosi scambi con i team IT, il che rallenta l’iniziativa e, di conseguenza, la mette a rischio.
In secondo luogo, permettere all’iniziativa di operare su un campione di dati è una ricetta per problemi di prestazioni del software quando l’iniziativa si espande successivamente verso l’intero perimetro. La scarsa scalabilità, o l’incapacità di elaborare una grande quantità di dati mantenendo i costi di calcolo sotto controllo, è un difetto molto frequente nel software. Lasciando che l’iniziativa operi su un campione, i problemi di scalabilità sono mascherati ma torneranno con forza in una fase successiva.
Operare su un campione di dati rende le statistiche più difficili, non più facili. Infatti, avere accesso a più dati è probabilmente il modo più semplice per migliorare l’accuratezza e la stabilità di quasi tutti gli algoritmi di machine learning. Il campionamento dei dati va contro questa intuizione. Pertanto, quando si utilizza un piccolo campione di dati, l’iniziativa potrebbe fallire a causa di comportamenti numerici erratici osservati sul campione. Questi comportamenti sarebbero stati in gran parte mitigati se invece fosse stato utilizzato l’intero set di dati.
Gli effetti di sistema sono la seconda forza che influisce sulla definizione del perimetro. Una supply chain è un sistema, e tutte le sue parti sono in qualche modo collegate. La sfida con i sistemi, qualsiasi sistema, è che i tentativi di migliorare una parte del sistema tendono a spostare i problemi anziché risolverli. Ad esempio, consideriamo un problema di allocazione delle scorte per una rete di vendita al dettaglio con un centro di distribuzione e molti negozi. Se scegliamo un singolo negozio come perimetro iniziale per il nostro problema di allocazione delle scorte, è banale garantire che questo negozio riceverà un servizio di alta qualità dal centro di distribuzione riservando le scorte in anticipo. Facendo ciò, possiamo assicurarci che il centro di distribuzione non rimarrà mai senza scorte mentre serve questo negozio. Tuttavia, questa riserva di scorte sarebbe fatta a discapito della qualità del servizio per gli altri negozi della rete.
Pertanto, quando si considera un perimetro per un’iniziativa di supply chain, è necessario considerare gli effetti di sistema. Il perimetro dovrebbe essere progettato in modo da prevenire in larga misura l’ottimizzazione locale a discapito degli elementi che si trovano al di fuori del perimetro. Questa parte dell’esercizio di definizione del perimetro è difficile perché tutti i perimetri sono in qualche modo permeabili. Ad esempio, tutte le parti della supply chain competono in ultima analisi per la stessa quantità di denaro disponibile a livello aziendale. Ogni dollaro allocato da qualche parte è un dollaro che non sarà disponibile per altri scopi. Tuttavia, certi perimetri sono molto più facilmente manipolabili di altri. È importante scegliere un perimetro che tenda a mitigare gli effetti di sistema anziché amplificarli.
Pensare alla definizione del perimetro di un’iniziativa di supply chain in termini di effetti di sistema potrebbe sembrare strano per molti professionisti della supply chain. Quando si tratta di definire il perimetro, la maggior parte delle aziende tende a proiettare la propria organizzazione interna sull’esercizio di definizione del perimetro. Pertanto, i confini scelti per il perimetro tendono inevitabilmente a imitare i confini della divisione del lavoro all’interno dell’azienda. Questo modello è noto come Legge di Conway. Proposta da Melvin Conway mezzo secolo fa per i sistemi di comunicazione, la legge è stata successivamente trovata ad avere un’applicabilità molto più ampia, inclusa una rilevanza primaria per la gestione della supply chain.
I confini e i silos che dominano le catene di approvvigionamento odierna sono determinati dalle divisioni del lavoro che sono il risultato di processi piuttosto manuali per prendere decisioni sulla supply chain. Ad esempio, se un’azienda valuta che un pianificatore di approvvigionamento e domanda non può gestire più di 1.000 SKU e l’azienda ha complessivamente 50.000 SKU da gestire, l’azienda avrà bisogno di 50 pianificatori di approvvigionamento e domanda per farlo. Tuttavia, suddividere l’ottimizzazione della supply chain tra 50 coppie di mani è garantito per introdurre molte inefficienze a livello aziendale.
Al contrario, un’iniziativa che automatizza queste decisioni non ha bisogno di adattarsi a quei confini che riflettono solo una divisione del lavoro obsoleta o destinata a diventarlo. Una ricetta numerica può ottimizzare quelle 50.000 SKU in una volta sola ed eliminare le inefficienze che derivano dal fatto che decine di silos si scontrano tra loro. Pertanto, è naturale che un’iniziativa che intende automatizzare in modo significativo queste decisioni si sovrapponga a molti confini preesistenti nell’azienda. L’azienda, o in realtà la direzione dell’azienda, deve resistere alla tentazione di imitare i confini organizzativi esistenti, soprattutto a livello di definizione del perimetro, poiché tende a impostare il tono per ciò che segue.
Le catene di approvvigionamento sono complesse in termini di hardware, software e persone. Sebbene sia sfortunato, avviare un’iniziativa quantitativa di supply chain aumenta ulteriormente la complessità della supply chain, almeno inizialmente. Nel lungo termine, può effettivamente ridurre notevolmente la complessità della supply chain, ma probabilmente ne parleremo in una lezione successiva. Inoltre, più persone sono coinvolte nell’iniziativa, maggiore è la complessità dell’iniziativa stessa. Se questa complessità aggiuntiva non viene immediatamente controllata, le probabilità che l’iniziativa collassi sotto il peso della sua stessa complessità sono alte.
Pertanto, quando si pensa ai ruoli dell’iniziativa, cioè chi farà cosa, è necessario pensare al più piccolo insieme possibile di ruoli che rende l’iniziativa fattibile. Riducendo al minimo il numero di ruoli, si riduce la complessità dell’iniziativa, il che a sua volta migliora notevolmente le probabilità di successo. Questa prospettiva tende ad essere controintuitiva per le grandi aziende che amano operare con una divisione del lavoro estremamente dettagliata. Le grandi aziende tendono a favorire specialisti estremi che fanno una cosa e una sola cosa. Tuttavia, una supply chain è un sistema e, come tutti i sistemi, è la prospettiva end-to-end che conta.
Sulla base dell’esperienza acquisita da Lokad nel condurre questo tipo di iniziative, abbiamo identificato quattro ruoli che di solito rappresentano la divisione del lavoro minima necessaria per condurre l’iniziativa: un dirigente della supply chain, un responsabile dei dati, un esperto di supply chain e un praticante di supply chain.
Il ruolo del dirigente della supply chain è quello di sostenere l’iniziativa affinché possa avvenire in primo luogo. Ottenere una ricetta numerica ben progettata per guidare le decisioni sulla supply chain in produzione rappresenta un enorme impulso sia in termini di redditività che di produttività. Tuttavia, è anche un cambiamento molto impegnativo da assimilare. Ci vuole molta energia e supporto dalla direzione aziendale perché un tale cambiamento avvenga in un’organizzazione di grandi dimensioni.
Il ruolo del responsabile dei dati è quello di configurare e mantenere il flusso di dati. La maggior parte dei loro contributi si prevede che avvenga nei primi due mesi dell’iniziativa. Se il flusso di dati è correttamente progettato, c’è molto poco sforzo continuativo per il responsabile dei dati in seguito. Il responsabile dei dati di solito non è coinvolto molto nelle fasi successive dell’iniziativa.
Il ruolo dell’esperto di supply chain è quello di creare la ricetta numerica di base. Questo ruolo parte dai dati transazionali grezzi resi disponibili dal responsabile dei dati. Non ci si aspetta alcuna preparazione dei dati da parte del responsabile dei dati, solo l’estrazione dei dati. Il ruolo dell’esperto di supply chain si conclude con l’assunzione della responsabilità della decisione sulla supply chain generata. Non è un pezzo di software che è responsabile della decisione; è l’esperto di supply chain. Per ogni decisione generata, lo scienziato stesso deve essere in grado di giustificare perché questa decisione è adeguata.
Infine, il ruolo del praticante di supply chain è quello di mettere in discussione le decisioni generate dalla ricetta numerica e fornire feedback allo scienziato di supply chain. Il praticante non ha speranza di prendere la decisione. Questa persona è stata di solito responsabile di tali decisioni fino ad ora, almeno per una sottoscopo, e di solito con l’aiuto di fogli di calcolo e sistemi in uso. In una piccola azienda, è possibile che una persona svolga contemporaneamente il ruolo di dirigente della supply chain e di praticante della supply chain. È anche possibile bypassare la necessità di un responsabile dei dati se i dati sono facilmente accessibili. Questo potrebbe accadere in aziende molto mature per quanto riguarda la loro infrastruttura dati. Al contrario, se l’azienda è molto grande, è possibile che poche, ma solo poche, persone ricoprano ciascun ruolo.
Il successo dell’implementazione in produzione della ricetta numerica di base ha un impatto significativo sul mondo del praticante di supply chain. Infatti, in larga misura, lo scopo dell’iniziativa è automatizzare il lavoro precedente del praticante di supply chain. Tuttavia, ciò non implica che il miglior corso di azione sia licenziare questi praticanti una volta che la ricetta numerica è in produzione. Ritorneremo su questo aspetto specifico nella prossima lezione.
Essere organizzati non significa essere efficienti o efficaci. Ci sono ruoli che, nonostante le buone intenzioni, aggiungono attrito alle iniziative di supply chain, spesso fino al punto di farle fallire del tutto. Oggi, il primo ruolo che contribuisce maggiormente al fallimento di tali iniziative tende ad essere il ruolo dello scienziato dei dati, e ancora di più quando è coinvolta un’intera squadra di scienziati dei dati. A proposito, Lokad ha imparato questa lezione a caro prezzo circa dieci anni fa.
Nonostante la somiglianza di nome tra scienziati dei dati e scienziati di supply chain, i due ruoli sono in realtà molto diversi. Lo scienziato di supply chain si preoccupa prima di tutto di fornire decisioni di produzione reali. Se ciò può essere ottenuto con una ricetta numerica semi-triviale, ancora meglio; la manutenzione sarà un gioco da ragazzi. Lo scienziato di supply chain si assume la piena responsabilità di gestire i dettagli più minuti della supply chain. L’affidabilità e la resilienza al caos ambientale contano più della sofisticazione.
Al contrario, lo scienziato dei dati si concentra sulle parti intelligenti della ricetta numerica, sui modelli e sugli algoritmi. Lo scienziato dei dati, in termini generali, si considera un esperto di machine learning e ottimizzazione matematica. In termini di tecnologie, uno scienziato dei dati è disposto a imparare l’ultima suite numerica open-source all’avanguardia, ma di solito non è disposto a conoscere l’ERP trentennale che gestisce l’azienda. Inoltre, lo scienziato dei dati non è un esperto di supply chain, né di solito è disposto a diventarlo. Lo scienziato dei dati cerca di fornire i migliori risultati secondo le metriche concordate. Lo scienziato non ha l’ambizione di occuparsi dei dettagli molto banali della supply chain; si prevede che questi elementi siano gestiti da altre persone.
Coinvolgere gli scienziati dei dati è un disastro per queste iniziative perché, non appena gli scienziati dei dati sono coinvolti, la supply chain non è più il focus - gli algoritmi e i modelli lo sono. Non sottovalutare mai il potere di distrazione che l’ultimo modello o algoritmo rappresenta per una persona intelligente e orientata alla tecnologia.
Il secondo ruolo che tende ad aggiungere attrito a un’iniziativa di supply chain è il team di business intelligence (BI). Quando il team di BI fa parte dell’iniziativa, tende ad essere un ostacolo piuttosto che altro, sebbene in misura molto minore rispetto al team di scienze dei dati. Il problema con il BI è principalmente culturale. Il BI fornisce report, non decisioni. Il team di BI è di solito disposto a produrre interminabili muri di metriche come richiesto da ogni singola divisione dell’azienda. Questa non è l’atteggiamento giusto per un’iniziativa quantitativa di supply chain.
Inoltre, l’intelligence aziendale come parte di un software è una classe molto specifica di analisi dei dati orientata intorno a cubi o cubi OLAP che consentono di analizzare la maggior parte dei sistemi in memoria nei sistemi aziendali. Questo design di solito non è adatto per guidare le decisioni della supply chain.
Ora che abbiamo definito l’iniziativa, diamo un’occhiata all’architettura IT di alto livello richiesta dall’iniziativa.
Lo schema sullo schermo illustra una tipica configurazione del flusso di dati per un’iniziativa quantitativa di supply chain. In questa lezione, sto discutendo di un flusso di dati che non supporta requisiti di bassa latenza. Vogliamo essere in grado di completare un ciclo completo in circa un’ora, non un secondo. La maggior parte delle decisioni sulla supply chain, come gli ordini di acquisto, non richiedono una configurazione a bassa latenza. Per ottenere una latenza molto bassa da un’estremità all’altra, è necessario un tipo di architettura diverso, che va oltre lo scopo della lezione di oggi.
I sistemi di transazione rappresentano la fonte primaria dei dati e il punto di partenza del flusso di dati. Questi sistemi includono ERP, WMS e EDI. Si occupano del flusso di merci come acquisti, trasporti, produzione e vendita. Questi sistemi contengono quasi tutti i dati richiesti dalla ricetta numerica di base. Per praticamente qualsiasi azienda di una certa dimensione, questi sistemi o i loro predecessori sono stati in uso per almeno due decenni.
Poiché questi sistemi contengono quasi tutti i dati di cui abbiamo bisogno, sarebbe tentante implementare la ricetta numerica direttamente in questi sistemi. Infatti, perché no? Mettendo la ricetta numerica direttamente nell’ERP, elimineremmo la necessità di passare attraverso l’effort di configurare l’intero flusso di dati. Purtroppo, ciò non funziona a causa del design stesso di quei sistemi transazionali.
Questi sistemi di transazione sono inevitabilmente costruiti con un database transazionale al loro centro. Questo approccio per il design del software aziendale è stato estremamente stabile negli ultimi quattro decenni. Scegli un’azienda a caso e le probabilità sono che ogni singola app aziendale in produzione sia stata implementata su un database transazionale. I database transazionali offrono quattro proprietà chiave conosciute con l’acronimo ACID, che sta per Atomicità, Coerenza, Isolamento e Durabilità. Non entrerò nei dettagli di queste proprietà, ma è sufficiente dire che queste proprietà rendono il database molto adatto per eseguire in modo sicuro e simultaneo molte piccole operazioni di lettura e molte piccole operazioni di scrittura. Si prevede anche che le quantità rispettive di operazioni di lettura e scrittura siano abbastanza bilanciate.
Tuttavia, il prezzo da pagare per queste proprietà ACID molto utili a livello granulare è che il database transazionale è anche molto inefficiente quando si tratta di servire grandi operazioni di lettura. Un’operazione di lettura che copre una porzione considerevole dell’intero database, come regola generale, se i dati vengono serviti attraverso un database che si concentra su una consegna molto granulare di queste proprietà ACID, ci si può aspettare che il costo delle risorse di calcolo sia aumentato di un fattore di 100 rispetto alle architetture che non si concentrano tanto su queste proprietà ACID a livello così granulare. ACID è bello, ma ha un costo molto elevato.
Inoltre, quando qualcuno tenta di leggere una porzione considerevole dell’intero database, è probabile che il database diventi non reattivo per un po’ di tempo poiché dedica la maggior parte delle sue risorse a servire questa grande richiesta. Molte aziende si lamentano che l’intero sistema aziendale è lento e che questi sistemi si bloccano frequentemente per un secondo o più. Di solito, questa scarsa qualità del servizio può essere attribuita a query SQL pesanti che cercano di leggere troppe righe in una volta.
Pertanto, la ricetta numerica di base non può essere consentita di operare nello stesso ambiente dei sistemi transazionali che supportano la produzione. Infatti, le ricette numeriche avranno bisogno di accedere alla maggior parte dei dati ogni volta che vengono eseguite. Pertanto, la ricetta numerica deve essere mantenuta strettamente isolata nel proprio sottosistema, se solo per evitare di degradare ulteriormente le prestazioni di quei sistemi transazionali.
A proposito, anche se da decenni si sa che è un’idea terribile avere un processo intensivo di dati che opera all’interno di un sistema transazionale, questo non impedisce alla maggior parte dei fornitori di sistemi transazionali (ERP, MRP, WMS) di vendere moduli analitici integrati, ad esempio, moduli di ottimizzazione dell’inventario. L’integrazione di questi moduli porta inevitabilmente a problemi di qualità del servizio fornendo capacità deludenti. Tutti questi problemi possono essere ricondotti a questo singolo problema di progettazione: il sistema transazionale e il sistema analitico devono essere mantenuti in rigoroso isolamento.
Il data lake è semplice. È uno specchio dei dati transazionali orientato verso operazioni di lettura molto grandi. Infatti, abbiamo visto che i sistemi transazionali sono ottimizzati per molte piccole operazioni di lettura, non per operazioni molto grandi. Pertanto, al fine di preservare la qualità del servizio del sistema transazionale, il design corretto consiste nel replicare attentamente i dati transazionali in un altro sistema, ovvero il data lake. Questa replica deve essere implementata con cura, precisamente per preservare la qualità del servizio del sistema transazionale, il che significa leggere i dati in modo molto incrementale ed evitare di mettere pressione sul sistema transazionale.
Una volta che i dati transazionali rilevanti sono riflessi nel data lake, il data lake stesso serve tutte le richieste di dati. Un ulteriore vantaggio del data lake è la sua capacità di servire più sistemi analitici. Mentre stiamo discutendo della supply chain qui, se il marketing vuole le proprie analisi, avranno bisogno degli stessi dati transazionali, e lo stesso si può dire per finanza, vendite, ecc. Pertanto, anziché avere ogni singolo dipartimento dell’azienda che implementa il proprio meccanismo di estrazione dati, ha senso consolidare tutte queste estrazioni nello stesso data lake, nello stesso sistema.
A livello tecnico, un data lake può essere implementato con un database relazionale, tipicamente ottimizzato per l’estrazione di big data, adottando una memorizzazione dei dati a colonne. I data lake possono anche essere implementati come repository di file piatti serviti su un sistema di file distribuito. Rispetto a un sistema transazionale, un data lake rinuncia alle proprietà transazionali a grana fine. L’obiettivo è servire una grande quantità di dati nel modo più economico e affidabile possibile, niente di più, niente di meno.
Il data lake deve riflettere i dati transazionali originali, il che significa copiare senza modificare nulla. È importante non preparare i dati nel data lake. Purtroppo, il team IT responsabile della configurazione del data lake può essere tentato di semplificare le cose e rendere più semplice per altri team preparare i dati. Tuttavia, modificare i dati introduce inevitabilmente complicazioni che compromettono le analisi in una fase successiva. Inoltre, attenersi a una rigorosa politica di riflessione riduce notevolmente lo sforzo necessario per il team IT per configurare e mantenere successivamente il data lake.
Nelle aziende in cui è già presente un team di BI, può essere tentatore utilizzare i sistemi BI come data lake. Tuttavia, sconsiglio vivamente di farlo e di non utilizzare mai un’installazione BI come data lake. Infatti, i dati nei sistemi BI (sistemi di business intelligence) sono inevitabilmente già pesantemente trasformati. Sfruttare i dati BI per guidare decisioni automatizzate sulla supply chain è una ricetta per problemi di spazzatura in entrata, spazzatura in uscita. Il data lake deve essere alimentato solo da fonti di dati primarie come ERP, non da fonti di dati secondarie come il sistema BI.
Il sistema analitico è quello che contiene la ricetta numerica principale. È anche il sistema che fornisce tutti i report necessari per strumentalizzare le decisioni stesse. A livello tecnico, il sistema analitico contiene i “pezzi intelligenti”, come gli algoritmi di apprendimento automatico e gli algoritmi di ottimizzazione matematica. Anche se nella pratica, quei pezzi intelligenti non dominano il codice del sistema analitico. Di solito, la preparazione dei dati e l’istruzione dei dati richiedono almeno dieci volte più righe di codice rispetto alle parti che si occupano di apprendimento e ottimizzazione.
Il sistema analitico deve essere disaccoppiato dal data lake perché questi due sistemi sono completamente in contrasto dal punto di vista tecnologico. Come software, il data lake deve essere molto semplice, molto stabile ed estremamente affidabile. Al contrario, ci si aspetta che il sistema analitico sia sofisticato, in costante evoluzione ed estremamente performante in termini di prestazioni della supply chain. A differenza del data lake, che deve garantire un uptime quasi perfetto, il sistema analitico non deve nemmeno essere attivo per la maggior parte del tempo. Ad esempio, se stiamo considerando decisioni di riapprovvigionamento giornaliere, allora il sistema analitico deve essere eseguito e attivo solo una volta al giorno.
Come regola generale, è meglio che il sistema analitico fallisca nella produzione delle decisioni piuttosto che generare decisioni errate e lasciarle fluire nella produzione. Ritardare le decisioni sulla supply chain di alcune ore, come gli ordini di acquisto, è tipicamente molto meno grave che prendere decisioni errate. Poiché il design del sistema analitico tende ad essere fortemente influenzato dai pezzi intelligenti che contiene, non c’è necessariamente molto da dire in generale sul design del sistema analitico. Tuttavia, c’è almeno una proprietà di design chiave che deve essere applicata per l’ecosistema: questo sistema deve essere senza stato.
Il sistema analitico deve evitare di avere uno stato interno nella massima misura possibile. In altre parole, l’intero ecosistema deve partire dai dati come presentati dal data lake e terminare con le decisioni pianificate sulla supply chain generate, insieme ai report di supporto. Quello che spesso accade è che quando c’è un componente all’interno del sistema analitico che è troppo lento, come un algoritmo di apprendimento automatico, è tentatore introdurre uno stato, cioè persistere alcune informazioni dall’esecuzione precedente per velocizzare l’esecuzione successiva. Tuttavia, farlo, fare affidamento su risultati precedentemente calcolati anziché ricalcolare tutto da zero ogni volta, è pericoloso.
Infatti, avere uno stato all’interno del sistema analitico mette a rischio la decisione. Mentre i problemi dei dati inevitabilmente sorgono e vengono risolti a livello di data lake, il sistema analitico potrebbe comunque restituire decisioni che riflettono un problema che è già stato risolto. Ad esempio, se un modello di previsione della domanda viene addestrato su un dataset di vendite corrotto, il modello di previsione rimane corrotto finché non viene addestrato su una versione fresca e corretta del dataset. L’unico modo per evitare che il sistema analitico soffra di echi di problemi dei dati che sono già stati risolti nel data lake è aggiornare tutto ogni volta. Questa è l’essenza dello stato senza stato.
Come regola generale, se una parte del sistema analitico si rivela troppo lenta per essere sostituita quotidianamente, allora questa parte deve essere considerata come affetta da un problema di prestazioni. Le supply chain sono caotiche e ci sarà un giorno in cui accadrà qualcosa - un incendio, un blocco, un attacco informatico - che richiederà un intervento immediato. L’azienda deve essere in grado di aggiornare tutte le sue decisioni sulla supply chain entro un’ora. L’azienda non deve aspettare e rimanere bloccata per 10 ore mentre si svolge la lenta fase di addestramento dell’apprendimento automatico.
Per poter operare in modo affidabile, il sistema analitico deve essere correttamente strumentato. Questo è ciò di cui si occupano il rapporto sulla salute dei dati e gli ispettori dei dati. A proposito, tutti questi elementi sono responsabilità della supply chain; non sono responsabilità dell’IT. Il monitoraggio della salute dei dati rappresenta la prima fase di elaborazione dei dati, prima ancora della preparazione dei dati stessi, e avviene all’interno del sistema analitico. La salute dei dati fa parte dello strumentario della ricetta numerica. Il rapporto sulla salute dei dati indica se è accettabile o meno eseguire la ricetta numerica. Questo rapporto individua anche l’origine del problema dei dati, se presente, al fine di accelerare la risoluzione del problema.
Il monitoraggio della salute dei dati è una pratica presso Lokad. Nel corso dell’ultimo decennio, questa pratica si è rivelata preziosa per evitare situazioni di “garbage in, garbage out” che sembrano essere onnipresenti nel mondo del software aziendale. Infatti, quando un’iniziativa di analisi dei dati fallisce, spesso si incolpa dei dati errati. Tuttavia, è importante notare che di solito non c’è quasi alcuno sforzo di ingegneria per garantire la qualità dei dati in primo luogo. La qualità dei dati non cade dal cielo; richiede sforzi di ingegneria.
Il flusso di dati che è stato presentato finora è piuttosto minimalista. La duplicazione dei dati è semplice come può essere, il che è una buona cosa per quanto riguarda la qualità del software. Tuttavia, nonostante questo minimalismo, ci sono ancora molte componenti in movimento: molte tabelle, molti sistemi, molte persone. Pertanto, ci sono bug ovunque. Questo è un software aziendale e il contrario sarebbe piuttosto sorprendente. Il monitoraggio della salute dei dati è in atto per aiutare il sistema analitico a sopravvivere al caos ambientale.
La salute dei dati non deve essere confusa con la pulizia dei dati. La salute dei dati riguarda solo l’assicurarsi che i dati resi disponibili al sistema analitico siano una rappresentazione fedele dei dati transazionali esistenti nei sistemi di transazione. Non c’è alcun tentativo di correggere i dati; i dati vengono analizzati così come sono.
Presso Lokad, solitamente distinguiamo tra la salute dei dati a basso livello e la salute dei dati ad alto livello. La salute dei dati a basso livello è una dashboard che riunisce tutte le stranezze strutturali e volumetriche dei dati, come problemi evidenti come voci che non sono nemmeno date o numeri ragionevoli, ad esempio, o identificatori orfani che non hanno i loro corrispondenti attesi. Tutti questi problemi possono essere visti e sono effettivamente i più facili. Il problema difficile inizia con le questioni che non possono essere viste perché i dati mancano in primo luogo. Ad esempio, se qualcosa è andato storto con un’estrazione dei dati e i dati di vendita estratti da ieri contengono solo la metà delle righe previste, può davvero mettere a rischio la produzione. I dati incompleti sono particolarmente insidiosi perché di solito non impediscono alla ricetta numerica di generare decisioni, tranne che quelle decisioni saranno spazzatura, poiché i dati di input sono incompleti.
Tecnicamente, presso Lokad, cerchiamo di mantenere il monitoraggio della salute dei dati su una singola dashboard, e questa dashboard è tipicamente destinata al team IT, poiché la maggior parte dei problemi catturati dalla salute dei dati a basso livello tendono ad essere legati al flusso di dati stesso. Idealmente, il team IT dovrebbe essere in grado di capire in un colpo d’occhio se tutto va bene o meno e se non è necessario alcun intervento ulteriore.
Il monitoraggio della salute dei dati ad alto livello considera tutte le stranezze a livello aziendale - elementi che sembrano sbagliati quando osservati da una prospettiva aziendale. La salute dei dati ad alto livello copre elementi come livelli di stock negativi o quantità minime di ordine anormalmente elevate. Copre anche cose come prezzi che non hanno senso perché l’azienda opererebbe in perdita o con margini ridicolmente alti. La salute dei dati ad alto livello cerca di coprire tutti gli elementi in cui un professionista della supply chain guarderebbe i dati e direbbe: “Non può essere corretto; abbiamo un problema”.
A differenza del rapporto sulla salute dei dati a basso livello, il rapporto sulla salute dei dati ad alto livello è principalmente destinato al team della supply chain. Infatti, problemi come quantità minime di ordine anomale saranno percepiti come problemi solo da un professionista che è in qualche modo familiare con l’ambiente aziendale. Lo scopo di questo rapporto è essere in grado di capire in un colpo d’occhio che tutto va bene e che non è necessario alcun intervento ulteriore.
In precedenza, ho detto che il sistema analitico doveva essere senza stato. Beh, si scopre che la salute dei dati è l’eccezione che conferma la regola. Infatti, molti problemi possono essere identificati confrontando gli indicatori odierni con gli stessi indicatori raccolti nei giorni precedenti. Pertanto, il monitoraggio della salute dei dati di solito mantiene uno stato di qualche tipo, che sono fondamentalmente indicatori chiave osservati nei giorni precedenti, in modo da poter identificare gli outlier nello stato attuale dei dati. Tuttavia, poiché la salute dei dati è una questione puramente di monitoraggio, il peggio che può accadere se c’è un problema a livello di data lake che viene risolto, e poi abbiamo echi di problemi passati nello stato della salute dei dati, è una serie di falsi allarmi da quei rapporti. La logica che genera le decisioni della supply chain rimane completamente senza stato; lo stato riguarda solo una piccola parte dello strumento.
Il monitoraggio della salute dei dati, sia a livello basso che alto, è una questione di compromesso tra il rischio di fornire decisioni errate e il rischio di non fornire decisioni tempestive. Quando si considerano grandi supply chain, non è ragionevole aspettarsi che il 100 percento dei dati sia corretto - le voci transazionali errate accadono, anche se sono rare. Pertanto, deve esserci un volume di problemi che dovrebbe essere considerato sufficientemente basso affinché la ricetta numerica possa funzionare. Il compromesso tra questi due rischi - essere ipersensibili ai problemi dei dati o essere troppo tolleranti ai problemi dei dati - dipende molto dalla struttura economica della supply chain.
Presso Lokad, creiamo e ottimizziamo questi rapporti caso per caso per ogni cliente. Invece di inseguire ogni possibile caso di corruzione dei dati, lo scienziato della supply chain, che è responsabile dell’implementazione della salute dei dati a basso e alto livello e degli ispettori dei dati di cui parlerò tra un attimo, cerca di regolare il monitoraggio della salute dei dati in modo da essere sensibile al tipo di problemi che sono effettivamente dannosi e che si verificano effettivamente per la supply chain di interesse.
Nel gergo di Lokad, un ispettore dei dati, o semplicemente un ispettore, è un rapporto che riassume tutti i dati rilevanti relativi a un oggetto di interesse. L’oggetto di interesse dovrebbe essere uno dei cittadini di prima classe dal punto di vista della supply chain - un prodotto, un fornitore, un cliente o un magazzino. Ad esempio, se stiamo considerando un ispettore dei dati per i prodotti, allora per ogni prodotto venduto dall’azienda, dovremmo essere in grado di vedere attraverso l’ispettore su un’unica schermata tutti i dati che sono collegati a questo prodotto. Nell’ispettore dei dati per i prodotti, ci sono effettivamente tante viste quanti sono i prodotti perché quando dico che vediamo tutti i dati, intendo tutti i dati che sono collegati a un codice a barre o a un numero di parte, non a tutti i prodotti in generale.
A differenza dei rapporti sulla salute dei dati a basso e alto livello che sono destinati a essere due dashboard che possono essere ispezionate in un colpo d’occhio, gli ispettori sono implementati per affrontare domande e preoccupazioni che inevitabilmente sorgono durante la progettazione e l’esecuzione della ricetta numerica principale. Infatti, per prendere una decisione sulla supply chain, non è raro consolidare dati da una dozzina di tabelle, che possono provenire da più sistemi transazionali. Poiché i dati sono ovunque, quando una decisione sembra sospetta, di solito è difficile individuare l’origine del problema. Può esserci una disconnessione tra i dati come visti dal sistema analitico e i dati esistenti nel sistema transazionale. Può esserci un algoritmo difettoso che non riesce a catturare un pattern statistico nei dati. Può esserci una percezione errata e la decisione che viene considerata sospetta potrebbe, in realtà, essere corretta. In ogni caso, l’ispettore è destinato a offrire la possibilità di ingrandire l’oggetto di interesse.
Al fine di essere utili, gli ispettori devono riflettere le specificità sia della supply chain che del panorama applicativo. Di conseguenza, la creazione degli ispettori è quasi sempre un esercizio su misura. Tuttavia, una volta completato il lavoro, l’ispettore rappresenta uno dei pilastri dell’strumentazione del sistema analitico stesso.
In conclusione, mentre la maggior parte delle iniziative quantitative sulla supply chain sono destinate a fallire ancor prima del loro avvio, non deve essere necessariamente così. Una scelta accurata dei deliverable, dei tempi, del campo di applicazione e delle regole è necessaria per evitare problemi che inevitabilmente portano a un fallimento di tali iniziative. Purtroppo, tali scelte sono spesso controintuitive, come Lokad ha imparato a sue spese in 14 anni di attività finora.
L’inizio stesso dell’iniziativa deve essere dedicato alla configurazione di un flusso di dati. Un flusso di dati non affidabile è uno dei modi più sicuri per garantire che qualsiasi iniziativa basata sui dati fallisca. La maggior parte delle aziende, persino la maggior parte dei reparti IT, sottovaluta l’importanza di un flusso di dati altamente affidabile che non richieda interventi continui. Sebbene la maggior parte della configurazione del flusso di dati sia di competenza del reparto IT, la supply chain stessa deve essere responsabile dell’strumentazione del sistema analitico che utilizza. Non aspettatevi che l’IT lo faccia per voi; questa responsabilità spetta al team della supply chain. Abbiamo visto due tipi diversi di strumentazione, ovvero i rapporti sulla salute dei dati che adottano una prospettiva aziendale e gli ispettori dei dati, che supportano diagnosi approfondite.
Oggi abbiamo discusso di come avviare un’iniziativa, ma la prossima volta vedremo come concluderla o meglio, sperabilmente, come portarla a compimento. Nella prossima lezione, che si terrà mercoledì 14 settembre, proseguiremo il nostro viaggio e vedremo che tipo di esecuzione è necessaria per creare una ricetta numerica principale e poi portare gradualmente le decisioni che genera in produzione. Avremo anche uno sguardo più approfondito su cosa implica questa nuova modalità di gestione della supply chain per l’operatività quotidiana dei professionisti della supply chain.
Ora, diamo un’occhiata alle domande.
Domanda: Perché esattamente sei mesi rappresentano un limite di tempo dopo il quale un’implementazione non viene eseguita correttamente?
Direi che il problema non è tanto avere sei mesi come limite di tempo. Il problema è che di solito le iniziative sono predisposte per fallire fin dall’inizio. Questo è il problema. Se la vostra iniziativa di ottimizzazione predittiva inizia con la prospettiva che i risultati saranno consegnati in due anni, è quasi garantito che l’iniziativa si dissolverà a un certo punto e non riuscirà a produrre nulla in produzione. Se potessi, preferirei che l’iniziativa avesse successo in tre mesi. Tuttavia, sei mesi rappresentano il periodo minimo, secondo la mia esperienza, per portare un’iniziativa del genere in produzione. Ogni ulteriore ritardo aumenta il rischio di fallimento dell’iniziativa. È molto difficile comprimere ulteriormente questo periodo perché una volta risolti tutti i problemi tecnici, i ritardi rimanenti riflettono il tempo necessario affinché le persone si mettano in moto con l’iniziativa.
Domanda: I professionisti della supply chain potrebbero essere frustrati da un’iniziativa che sostituisce la maggior parte del loro carico di lavoro, come il reparto acquisti, in conflitto con l’automazione delle decisioni. Come consiglieresti di gestire questa situazione?
Questa è una domanda molto importante, che spero verrà affrontata nella prossima lezione. Per oggi, posso dire che credo che la maggior parte di ciò che i professionisti della supply chain stanno facendo nelle catene di approvvigionamento attuali non sia molto gratificante. Nella maggior parte delle aziende, le persone riceveranno un insieme di SKU o numeri di parte e poi cicleranno continuamente attraverso di essi, prendendo tutte le decisioni necessarie. Questo significa che il loro lavoro consiste essenzialmente nel guardare un foglio di calcolo e scorrerlo una volta alla settimana o forse una volta al giorno. Questo non è un lavoro gratificante.
La risposta breve è che l’approccio di Lokad affronta il problema automatizzando tutti gli aspetti noiosi del lavoro, in modo che le persone con una vera competenza nella supply chain possano iniziare a mettere in discussione i fondamenti della supply chain. Ciò consente loro di discutere di più con clienti e fornitori per rendere tutto più efficiente. Si tratta di raccogliere informazioni in modo da poter migliorare la ricetta numerica. Eseguire la ricetta numerica è noioso e ci saranno pochissime persone che rimpiangeranno i vecchi tempi in cui dovevano scorrere fogli di calcolo ogni giorno.
Domanda: Si prevede che i professionisti della supply chain lavorino con rapporti sulla salute dei dati al fine di mettere in discussione le decisioni generate dagli scienziati della supply chain?
Si prevede che i professionisti della supply chain lavorino con ispettori dei dati, non con rapporti sulla salute dei dati. I rapporti sulla salute dei dati sono come una valutazione a livello aziendale che risponde alla domanda se i dati all’ingresso del sistema analitico siano sufficientemente buoni per consentire a una ricetta numerica di operare sul dataset. Il risultato del rapporto sulla salute dei dati è una decisione binaria: dare il via libera all’esecuzione della ricetta numerica o opporsi e dire che c’è un problema da risolvere. Gli ispettori dei dati, di cui si parlerà di più nella prossima lezione, sono il punto di ingresso per i professionisti della supply chain per ottenere informazioni su una proposta decisione della supply chain.
Domanda: È fattibile aggiornare un modello analitico, ad esempio, impostando una politica di inventario su base giornaliera? Il sistema della supply chain non può rispondere ai cambiamenti di politica giornalieri, non genererà solo rumore nel sistema?
Per affrontare la prima parte della domanda, aggiornare un modello analitico su base giornaliera è certamente fattibile. Ad esempio, quando Lokad operava nel 2020 con i lockdown che si verificavano in Europa, avevamo paesi che chiudevano e riaprivano con solo 24 ore di preavviso. Questo ha creato una situazione estremamente caotica che richiedeva costanti revisioni immediate su base giornaliera. Lokad ha operato sotto questa pressione estrema, gestendo lockdown che iniziavano o finivano quotidianamente in tutta Europa per quasi 14 mesi.
Quindi, aggiornare un modello analitico giornalmente è fattibile, ma non necessariamente desiderabile. È vero che i sistemi di supply chain hanno molta inerzia e la prima cosa che una ricetta numerica appropriata deve riconoscere è l’effetto cricchetto della maggior parte delle decisioni. Una volta che hai ordinato la produzione e i materiali grezzi vengono consumati, non puoi annullare la produzione. Devi tenere presente che molte decisioni sono già state prese quando ne vengono prese di nuove. Tuttavia, quando ti rendi conto che la tua supply chain ha bisogno di un cambiamento drastico nel suo corso di azione, non ha senso ritardare questa correzione solo per il gusto di ritardare la decisione. Il momento migliore per implementare il cambiamento è adesso.
Per quanto riguarda l’aspetto del rumore della domanda, dipende dalla corretta progettazione delle ricette numeriche. Ci sono molti progetti errati che sono instabili, in cui piccoli cambiamenti nei dati generano grandi cambiamenti nelle decisioni che rappresentano l’esito della ricetta numerica. Una ricetta numerica non dovrebbe essere instabile ogni volta che si verifica una piccola fluttuazione nella supply chain. Ecco perché Lokad ha adottato una prospettiva probabilistica sulla previsione. Utilizzando una prospettiva probabilistica, i modelli possono essere progettati per essere molto più stabili rispetto ai modelli che cercano di catturare la media e sono instabili ogni volta che si verifica un valore anomalo nella supply chain.
Domanda: Uno dei problemi che affrontiamo nella supply chain con aziende molto grandi è la dipendenza da diversi sistemi di origine. Non è estremamente difficile portare tutti i dati da questi sistemi di origine in un unico sistema unificato?
Sono completamente d’accordo sul fatto che ottenere tutti i dati rappresenti una sfida significativa per molte aziende. Tuttavia, dobbiamo chiederci perché rappresenti una sfida in primo luogo. Come ho già detto, il 99% delle applicazioni aziendali gestite dalle grandi aziende di oggi si basa su database transazionali di mainstream ben progettati. Potrebbero ancora esistere alcune implementazioni COBOL super legacy in esecuzione su archiviazione binaria arcaica, ma questo è raro. La stragrande maggioranza delle applicazioni aziendali, anche quelle implementate negli anni ‘90, operano con un database transazionale di produzione pulito nel backend.
Una volta che si dispone di un backend transazionale, perché dovrebbe essere difficile copiare questi dati in un data lake? La maggior parte delle volte, il problema è che le aziende non cercano solo di copiare i dati, ma cercano di fare molto di più. Cercano di preparare e trasformare i dati, spesso complicando eccessivamente il processo. La maggior parte delle configurazioni di database moderne ha funzionalità di replica dei dati integrate, che consentono di replicare tutte le modifiche da un database transazionale a un database secondario. Questa è una proprietà integrata per probabilmente i primi 20 sistemi transazionali più utilizzati sul mercato.
Le aziende tendono a lottare per consolidare i dati perché cercano di fare troppo e le loro iniziative collassano a causa della loro complessità. Una volta che i dati sono consolidati, le aziende spesso commettono l’errore di pensare che la connessione dei dati debba essere fatta da team IT, BI o di data science. Il punto che voglio fare qui è che la supply chain deve essere responsabile delle proprie ricette numeriche, proprio come marketing, vendite e finanza. Non dovrebbe essere una divisione di supporto trasversale che cerca di farlo per l’azienda. La connessione dei dati provenienti da diversi sistemi richiede tipicamente un’enorme quantità di conoscenze aziendali. Le grandi aziende falliscono spesso perché cercano di far svolgere questo lavoro a un esperto di team IT, BI o di data science quando dovrebbe essere fatto all’interno della divisione di interesse.
Grazie mille per il vostro tempo oggi, per il vostro interesse e per le vostre domande. Ci vediamo la prossima volta dopo l’estate, a settembre.
