Deliverabili del progetto

L’obiettivo della Supply Chain Quantitativa è fornire decisioni operative - ad esempio, quantità suggerite per gli ordini di acquisto. Di seguito, chiariremo ulteriormente la forma specifica e il meccanismo di consegna di tali decisioni. Stabilire aspettative chiare per i deliverabili è un passo importante nel percorso che rappresenta la Supply Chain Quantitativa. Inoltre, i risultati numerici ottimizzati non sono l’unico output desiderabile: diversi altri output, in particolare il monitoraggio della salute dei dati e gli indicatori di gestione KPI, dovrebbero essere inclusi nel deliverable. In pratica, i deliverabili di un’iniziativa di Supply Chain Quantitativa dipendono dalla flessibilità della soluzione software utilizzata per supportare l’iniziativa stessa. Tuttavia, sono principalmente definiti dalla loro intenzione, che è agnostica rispetto alla tecnologia utilizzata.

Script come deliverable

La Supply Chain Quantitativa enfatizza i data pipeline completamente automatizzati. Ciò non implica che l’installazione del software debba funzionare in modo autonomo. È naturalmente auspicabile un alto grado di supervisione ravvicinata ogni volta che si considera una supply chain su larga scala. Tuttavia, ci si aspetta che il data pipeline sia completamente automatizzato nel senso che nessun singolo passaggio nel pipeline dipende effettivamente da un’operazione manuale. Infatti, come delineato nel manifesto, quando le operazioni manuali sono coinvolte nel supporto al trattamento dei dati della supply chain, la soluzione semplicemente non scala nella pratica.

Come conseguenza diretta di questa intuizione, i deliverabili di un’iniziativa di Supply Chain Quantitativa sono inevitabilmente interi pezzi di software. Ciò non implica che il team responsabile debba reimplementare tutto: una soluzione software dedicata alla Supply Chain Quantitativa offre la possibilità di concentrarsi esclusivamente sugli aspetti rilevanti delle sfide della supply chain. Tutte le tecniche a basso livello, come il sfruttamento delle risorse di calcolo distribuite allocate automaticamente all’interno di una piattaforma di cloud computing, devono essere astratte. Il team non ha bisogno di approfondire tali questioni, perché si prevede che tali aspetti siano adeguatamente gestiti dallo strumento stesso.

I deliverabili sono materializzati come script scritti tipicamente in un linguaggio di programmazione in grado di soddisfare i requisiti della supply chain, pur offrendo un alto livello di produttività. Il termine “script” viene utilizzato qui invece di “codice sorgente”, ma i due termini sono strettamente correlati: uno “script” sottolinea l’idea di un alto grado di astrazione e di focalizzazione sul compito stesso, mentre un “codice sorgente” enfatizza una prospettiva a un livello inferiore, intesa come una riflessione accurata dell’hardware di calcolo stesso. Per la Supply Chain Quantitativa, è ovviamente la prospettiva della supply chain che conta di più, non l’hardware di calcolo, che è un aspetto tecnico di importanza secondaria.

Negli ultimi dieci anni, il successo delle interfacce utente WYSIWYG (what-you-see-is-what-you-get) per le app destinate agli utenti finali ha spinto molti fornitori di software per la supply chain a cercare di emulare questo approccio con una soluzione WYSIWYG per la pianificazione e l’ottimizzazione della supply chain. Tuttavia, l’insegnamento del fallimento quasi sistematico di questi tipi di interfacce è che le supply chain sono complesse e non possono evitare la necessità di strumenti programmabili. Dalla nostra esperienza, aspettarsi che uno strumento di trascinamento e rilascio sia in grado di riflettere correttamente le complesse non linearità coinvolte, ad esempio, nelle quantità minime di ordinazione (MOQ), è al massimo illusorio. È richiesta un’espressività programmabile perché, altrimenti, la sfida della supply chain non può nemmeno essere espressa all’interno dello strumento.

Naturalmente, dal punto di vista dell’utente finale, gli script non sono ciò che i professionisti della supply chain si aspetterebbero di vedere come un risultato tangibile dell’iniziativa di Supply Chain Quantitativa. Le persone interagiranno con dashboard che contengono KPI consolidati e tabelle che raccolgono decisioni suggerite. Tuttavia, queste dashboard sono transitorie e usa e getta. Sono ottenute semplicemente eseguendo nuovamente gli script sui dati rilevanti della supply chain. Sebbene la distinzione sia un po’ sottile, è importante non confondere lo script, che rappresenta il vero deliverable, con la sua espressione numerica, che è tipicamente ciò che un utente finale della soluzione può vedere.

Dashboard sulla salute dei dati

Prima di considerare la fornitura di decisioni ottimizzate per la supply chain, è necessario assicurarsi che i dati elaborati dal sistema che supporta l’iniziativa di Supply Chain Quantitativa siano corretti sia numericamente che semanticamente. Lo scopo delle dashboard di monitoraggio della salute dei dati, o semplicemente dashboard sulla salute dei dati, è garantire un elevato grado di fiducia nella correttezza dei dati, che è naturalmente un requisito essenziale per l’accuratezza di tutti i risultati numerici restituiti dalla soluzione. Queste dashboard assistono anche il team della supply chain nel migliorare la qualità dei dati esistenti.

Gli errori numerici sono semplici: il file CSV esportato dall’ERP indica che il prodotto ABC ha 42 unità in magazzino, mentre la console web dell’ERP riporta solo 13 unità in magazzino. È evidente qui che abbiamo numeri divergenti dove dovrebbero essere gli stessi. Le dashboard sulla salute dei dati affrontano questi problemi relativamente evidenti semplicemente verificando che gli aggregati dei dati rimangano all’interno dei range numerici attesi.

Gli errori semantici sono più sottili e, nella pratica, molto più difficili da individuare. La maggior parte del lavoro svolto durante la preparazione dei dati consiste effettivamente nell’identificare e affrontare tutti gli errori semantici. Ad esempio: il campo stockinv nell’ERP potrebbe essere documentato come il magazzino a disposizione. Pertanto, il team della supply chain assume che questa quantità non possa mai essere negativa, perché ovviamente, se quelle unità sono fisicamente raggiungibili sullo scaffale, deve essere una quantità positiva. Tuttavia, la documentazione dell’ERP potrebbe anche essere leggermente fuorviante, e questa quantità sarebbe stata più appropriatamente chiamata stock disponibile perché ogni volta che si verifica una stock-out e il cliente emette un backorder, la quantità può diventare negativa per riflettere che un certo numero di unità è già dovuto a un cliente. Questo caso illustra un errore semantico: il numero non è sbagliato di per sé - è la comprensione del numero che è approssimativa. Nella pratica, le approssimazioni semantiche possono generare molti comportamenti incoerenti, che a loro volta generano costi di attrito continui all’interno della supply chain.

Le dashboard sulla salute dei dati consolidano i numeri che consentono all’azienda di decidere sul momento se i dati possono essere considerati sufficientemente affidabili o meno. Infatti, poiché la soluzione verrà utilizzata quotidianamente per scopi produttivi, è imperativo che un problema significativo di dati venga identificato attraverso un’ispezione quasi istantanea. In caso contrario, le probabilità sono che la supply chain finirà per operare per giorni, se non settimane, su dati difettosi. A questo proposito, la dashboard sulla salute dei dati è simile a un semaforo: verde si passa, rosso si ferma.

Inoltre, quando si considera una supply chain di dimensioni considerevoli, di solito c’è una quantità irriducibile di dati corrotti o altrimenti errati. Questi dati derivano da inserimenti manuali errati o da casi limite rari nei sistemi aziendali stessi. Nella pratica, per qualsiasi supply chain di dimensioni considerevoli, è irragionevole aspettarsi che i dati della supply chain siano accurati al 100%. Invece, è necessario assicurarsi che i dati siano abbastanza accurati da mantenere i costi di attrito generati da quegli errori quasi trascurabili.

Pertanto, ci si aspetta che le dashboard sulla salute dei dati raccolgano anche statistiche sugli errori di dati identificati. Queste statistiche sono fondamentali per stabilire che i dati possano essere considerati affidabili. A tal fine, un Supply Chain Scientist viene spesso chiamato a stabilire soglie di allarme ben scelte, tipicamente associate a un arresto completo della soluzione. È necessario fare attenzione nell’individuare le soglie perché, se sono troppo basse, la soluzione non è utilizzabile, in quanto viene interrotta troppo frequentemente per “problemi di dati identificati”; tuttavia, se sono troppo alte, i costi di attrito generati dagli errori di dati possono diventare significativi e compromettere i benefici apportati dall’iniziativa stessa.

Oltre alla segnalazione rosso-verde, le dashboard sulla salute dei dati sono anche destinate a offrire informazioni prioritarie sugli sforzi di miglioramento dei dati. Infatti, molti punti dati potrebbero essere errati ma anche insignificanti. Ad esempio, non importa se il prezzo di acquisto di un prodotto è errato se la domanda di mercato per questo prodotto è scomparsa anni fa, poiché non ci saranno ulteriori ordini di acquisto per questo prodotto.

La Supply Chain Quantitativa sottolinea che la risoluzione dettagliata degli errori di dati, che può comportare una considerevole quantità di lavoro manuale, dovrebbe essere prioritizzata rispetto all’impatto finanziario stimato dell’errore di dati stesso rispetto al costo del lavoro associato alla correzione. Infatti, a seconda della situazione, il costo associato alla correzione di un singolo punto dati difettoso varia enormemente e deve essere preso in considerazione nella prioritizzazione suggerita. Infine, quando il costo delle correzioni viene ritenuto più elevato rispetto ai costi della supply chain generati da quegli errori, il processo di miglioramento dei dati può essere interrotto.

Dashboard decisionali prioritarie

Come abbiamo visto, solo le decisioni sulla supply chain possono essere valutate veramente da un punto di vista quantitativo. Pertanto, non sorprende che uno dei principali risultati operativi di un’iniziativa di Supply Chain Quantitativa siano le dashboard che consolidano le decisioni ottenute come risultato numerico finale dell’intero flusso di dati. Una tale dashboard può essere semplicemente una tabella che elenca per ogni prodotto la quantità esatta in unità da riordinare immediatamente. Se sono presenti MOQ (quantità minima d’ordine) - o qualsiasi altro vincolo di ordinazione alternativo - le quantità suggerite potrebbero essere zero la maggior parte delle volte, fino a quando non vengono raggiunte le soglie appropriate.

Per semplicità, assumiamo qui che questi risultati numerici siano raccolti in una dashboard, che è una forma specifica di interfaccia utente. Tuttavia, la dashboard stessa è solo una delle opzioni, che può essere rilevante o meno. In pratica, ci si aspetta che il software che alimenta l’iniziativa di Supply Chain Quantitativa sia altamente flessibile, ovvero flessibile dal punto di vista programmabile, offrendo molti modi per confezionare quei risultati in vari formati di dati. Ad esempio, i risultati numerici possono essere consolidati all’interno di file di testo piatti, che sono destinati ad essere importati automaticamente nell’ERP primario utilizzato per gestire le risorse dell’azienda.

Mentre il formato delle decisioni dipende molto dal compito della supply chain affrontato, la maggior parte dei compiti richiede di dare priorità a tali decisioni. Ad esempio, l’atto di calcolare le quantità suggerite per un ordine di acquisto può essere scomposto attraverso una lista prioritaria di unità da acquisire. L’unità più redditizia è classificata al primo posto. Poiché le scorte comportano rendimenti decrescenti, la seconda unità acquisita per lo stesso prodotto copre una frazione decrescente della domanda di mercato. Pertanto, la seconda unità per questo stesso prodotto potrebbe non essere la seconda voce nell’elenco complessivo. Invece, l’unità più redditizia può essere associata ad un altro prodotto, ecc. L’elenco prioritario delle unità da acquisire è concettualmente senza fine: è sempre possibile acquistare un’unità in più. Poiché la domanda di mercato è finita, tutte le unità acquistate diventerebbero scorte morte dopo un certo punto. Trasformare questa lista prioritaria nelle quantità finali da acquistare richiede solo l’introduzione di un criterio di arresto e la somma delle quantità per prodotto. In pratica, i vincoli di ordinazione non lineari complicano ulteriormente questo compito, ma, per semplicità, metteremo da parte questi vincoli in questa fase della discussione.

La priorità delle decisioni è un’operazione molto naturale dal punto di vista della Supply Chain Quantitativa. Poiché ogni decisione è associata a un risultato finanziario espresso in dollari, classificare le decisioni dal più redditizio al meno redditizio è semplice. Pertanto, molti, se non la maggior parte, dei cruscotti che compilano le decisioni suggerite della supply chain possono essere considerati, nella pratica, elenchi prioritari di decisioni. Questi cruscotti contengono elenchi con decisioni altamente redditizie in cima e decisioni molto poco redditizie in fondo. In alternativa, i professionisti della supply chain possono decidere di troncare gli elenchi quando le decisioni non sono redditizie. Tuttavia, spesso ci sono informazioni utili da ottenere ispezionando le decisioni che si trovano appena al di sotto della soglia di redditività, anche se ovviamente l’azienda non è tenuta ad agire su quelle voci non redditizie.

Per fornire questo tipo di cruscotti basati sulle decisioni, la soluzione software che supporta la Supply Chain Quantitativa deve esplorare numericamente una vasta quantità di possibili decisioni. Ad esempio, la soluzione dovrebbe essere in grado di considerare l’impatto finanziario dell’acquisto di ogni singola unità, unità per unità, per ogni singolo prodotto in ogni singola posizione. Non sorprende che questa operazione possa richiedere risorse di calcolo considerevoli. Fortunatamente, oggi l’hardware di calcolo è in grado di gestire anche le supply chain globali più complesse. Presumendo che la soluzione software sottostante sia adeguatamente progettata per la Supply Chain Quantitativa, la scalabilità dell’elaborazione dei dati non dovrebbe essere un problema per i team della supply chain.

Rendere trasparenti i risultati numerici

I sistemi derisoriamente definiti “scatole nere” nella supply chain e in altri settori sono sistemi che generano output che non possono essere spiegati dagli operatori che interagiscono con tali sistemi. Anche la Supply Chain Quantitativa, con il suo specifico focus su un flusso di dati automatizzato, corre il rischio di fornire ciò che i team della supply chain classificherebbero come “scatole nere”. Infatti, le implicazioni finanziarie delle decisioni della supply chain sono molto importanti per un’azienda e, sebbene un sistema più recente possa migliorare la situazione, può anche potenzialmente creare disastri. Sebbene l’automazione sia molto desiderabile, ciò non significa che il team della supply chain non debba avere una comprensione approfondita di ciò che viene fornito dal flusso di dati che supporta l’iniziativa della Supply Chain Quantitativa.

Il termine “rendere trasparente” si riferisce all’effort necessario per rendere la soluzione completamente trasparente a beneficio dei team della supply chain. Questo approccio sottolinea che nessuna tecnologia è trasparente per design. La trasparenza è il risultato finale di uno sforzo specifico, che fa parte dell’iniziativa stessa. Anche una semplice regressione lineare può generare risultati sorprendenti nella pratica. A parte alcuni individui eccezionali, la maggior parte delle persone non ha una comprensione intuitiva di quale dovrebbe essere l’output “previsto” del modello lineare quando sono coinvolti 4 o più dimensioni. Eppure, i problemi della supply chain spesso coinvolgono decine di variabili, se non centinaia. Pertanto, anche i modelli statistici semplicistici sono di fatto scatole nere per i professionisti della supply chain. Naturalmente, quando vengono utilizzati algoritmi di machine learning, come raccomandato dalla Supply Chain Quantitativa, i professionisti rimangono ancora più nel buio.

Sebbene l’effetto della scatola nera sia un problema reale, una soluzione realistica non consiste nel semplificare l’elaborazione dei dati in calcoli immediatamente intuitivi per la mente umana. Questo approccio è una ricetta per un’estrema inefficienza, che demolisce completamente tutti i vantaggi delle moderne risorse di calcolo, che possono essere utilizzate per affrontare la complessità delle moderne supply chain. Semplificare il processo non è la risposta. La soluzione è rendere trasparente.

Anche le raccomandazioni più complesse della supply chain possono essere rese in gran parte trasparenti per i professionisti della supply chain, semplicemente scomponendo i calcoli interni con indicatori finanziari ben scelti, che rappresentano i driver economici che supportano la raccomandazione stessa. Ad esempio, invece di visualizzare semplicemente una tabella con due colonne prodotto e quantità come ordine di acquisto suggerito, la tabella dovrebbe includere un paio di colonne che aiutano la presa di decisioni. Queste colonne extra possono includere la scorta attuale, la domanda totale dell’ultimo mese, il tempo di consegna previsto, il costo finanziario previsto della mancanza di scorte (se non viene effettuato alcun ordine), il costo finanziario previsto dell’eccesso di scorte (rischio associato all’ordine suggerito), ecc. Le colonne sono progettate per fornire al team della supply chain rapidi controlli di coerenza delle quantità suggerite. Attraverso le colonne, il team può rapidamente instaurare fiducia nell’output numerico e identificare anche alcune delle debolezze di una soluzione che necessita di ulteriori miglioramenti.

Estendere i cruscotti per scopi di whiteboxing è in parte un’arte. Generare milioni di numeri è facile, anche avendo accesso a risorse di calcolo non superiori a quelle disponibili su uno smartphone. Tuttavia, generare 10 numeri degni di essere osservati su base giornaliera è molto difficile. Pertanto, la sfida principale è identificare una dozzina o meno di KPI che siano sufficienti per fare luce sulle decisioni raccomandate della supply chain. I buoni KPI richiedono tipicamente molto lavoro; non dovrebbero essere definizioni naive, che di solito sono fuorvianti nella supply chain. Ad esempio, anche una colonna semplice come il “prezzo unitario di acquisto” può essere molto fuorviante se il fornitore offre sconti sul volume, rendendo così il prezzo di acquisto dipendente dalla quantità acquistata.

Cruscotti strategici

Sebbene il focus sulle decisioni a piccola scala sia necessario - poiché è uno dei pochi approcci che si presta a valutazioni quantitative delle prestazioni - la supply chain potrebbe anche dover essere adeguata in modi più grandi e disruptivi, per aumentare le prestazioni al livello successivo. Ad esempio, l’acquisto di un maggior numero di unità di stock ben scelte aumenta marginalmente il livello di servizio. Tuttavia, ad un certo punto, il magazzino è pieno e non è possibile acquistare ulteriori unità. In questa situazione, dovrebbe essere presa in considerazione l’opzione di un magazzino più grande. Per valutare l’impatto di questa limitazione, possiamo rimuovere il vincolo di capacità del magazzino dai calcoli e valutare il vantaggio finanziario complessivo di operare con un magazzino arbitrario e di grandi dimensioni. La gestione della supply chain può quindi tenere d’occhio l’indicatore finanziario associato al costo di attrito imposto dalla capacità del magazzino stesso e decidere quando è il momento di considerare l’aumento della capacità di stoccaggio.

Tipicamente, le supply chain operano sulla base di numerosi vincoli che non possono essere rivisti su base giornaliera. Questi vincoli possono includere il capitale circolante, la capacità di stoccaggio, i ritardi nel trasporto, la capacità di produzione, ecc. Ogni vincolo è associato a un costo opportunità implicito per la supply chain, che di solito si traduce in più stock, più ritardi o più mancanze di stock. Il costo opportunità può essere valutato attraverso i guadagni di prestazioni che si otterrebbero rimuovendo o indebolendo il vincolo stesso. Sebbene alcune di queste simulazioni possano rivelarsi difficili da implementare, spesso non sono più difficili dell’ottimizzazione delle decisioni di routine, ovvero stabilire le quantità degli ordini di acquisto.

La Supply Chain Quantitativa sottolinea che i costi opportunità associati a questi vincoli dovrebbero far parte del flusso di dati di produzione e, tipicamente, dovrebbero essere materializzati con cruscotti dedicati, specificamente intesi ad aiutare la gestione della supply chain a decidere quando è il momento di apportare cambiamenti più grandi alla loro supply chain. Questi tipi di cruscotti sono definiti cruscotti strategici. Questo approccio differisce dalla pratica tradizionale della supply chain che enfatizza iniziative ad hoc quando si sente che la supply chain sta per raggiungere un limite operativo. Infatti, i KPI forniti dai cruscotti strategici vengono aggiornati su base giornaliera, o più frequentemente se necessario, proprio come il resto del flusso di dati. Non è necessario fare un ultimo sforzo disperato all’ultimo minuto, perché sono aggiornati e pronti a sfruttare le intuizioni acquisite da un’iniziativa a lunga durata.

I cruscotti strategici supportano il processo decisionale della gestione della supply chain. Poiché fanno parte del flusso di dati, quando il mercato inizia a evolversi più velocemente del solito, i KPI rimangono aggiornati sulla situazione attuale dell’azienda. Questo approccio evita le tradizionali insidie associate alle indagini ad hoc che inevitabilmente aggiungono ulteriori ritardi a problemi già in ritardo. Questo approccio mitiga anche in larga misura il problema alternativo, ovvero decisioni strategiche affrettate che si rivelano non redditizie - una condizione deplorevole che avrebbe potuto essere prevista fin dall’inizio.

Cruscotti ispettivi

Le supply chain sono complesse e erratiche. Queste proprietà rendono il debug del flusso di dati un compito estremamente difficile. Eppure, questo flusso di dati è il midollo spinale dell’iniziativa di Supply Chain Quantitativa. Gli errori di elaborazione dei dati, o bug, possono verificarsi ovunque nel flusso di dati. Peggio ancora, il tipo di problema più frequente non è la formula errata, ma l’ambiguità semantica. Ad esempio, all’inizio del flusso di dati, la variabile stockinv potrebbe riferirsi allo stock disponibile (dove sono possibili valori negativi), mentre in seguito, la stessa variabile viene utilizzata con un’interpretazione di stock in magazzino (dove ci si aspetta che i valori siano positivi). L’interpretazione ambigua della variabile stockinv può generare una vasta gamma di comportamenti errati, che vanno da crash di sistema - che sono ovvi, quindi solo moderatamente dannosi - a una corruzione silenziosa e diffusa delle decisioni della supply chain.

Poiché le supply chain sono quasi sempre composte da una combinazione unica di soluzioni software implementate nel corso degli anni, non c’è speranza di ottenere accesso a una soluzione software “provata” priva di bug. Infatti, la maggior parte dei problemi si verifica ai confini del sistema, quando si conciliano dati provenienti da diversi sistemi, o addirittura solo dati provenienti da diversi moduli all’interno dello stesso sistema. Pertanto, non importa quanto sia provata la soluzione software, gli strumenti devono essere in grado di supportare agevolmente il processo di debug, poiché questo tipo di problemi è destinato a verificarsi.

Lo scopo dei cruscotti ispettivi è fornire viste dettagliate per una minuziosa ispezione dei dataset della supply chain. Tuttavia, questi cruscotti non sono semplici drill-down per ispezionare le tabelle dei dati di input. Un tale approccio di drill-down, o approcci simili di taglia e cuci sui dati, mancherebbe il punto. Le supply chain riguardano tutti i flussi: flusso di materiali, flusso di pagamenti, ecc. Alcuni dei problemi più gravi dei dati si verificano quando la continuità del flusso viene “logicamente” persa. Ad esempio, quando si spostano merci dal magazzino A al magazzino B, il database del magazzino B potrebbe non avere alcune voci di prodotto, generando così sottili corruzioni dei dati, poiché le unità provenienti dal magazzino A vengono ricevute nel magazzino B senza essere correttamente collegate al loro prodotto. Quando i risultati numerici sembrano strani, questi cruscotti ispettivi sono l’opzione preferita per il Supply Chain Scientist per effettuare un’indagine rapida sui dati di esempio.

In pratica, un cruscotto ispettivo fornisce un punto di ingresso a basso livello come un codice prodotto o un SKU, e consolida tutti i dati associati a questo punto di ingresso in una singola vista. Quando le merci fluiscono attraverso molte posizioni, come accade ad esempio nelle supply chain aerospaziali, il cruscotto ispettivo cerca di ricostruire le traiettorie delle merci, che possono essere transitate non solo attraverso molte posizioni fisiche, ma anche attraverso molti sistemi. Raccogliendo tutti questi dati in un unico luogo, diventa possibile per il Supply Chain Scientist valutare se i dati hanno senso: è possibile identificare da dove provengono le merci che vengono spedite? Gli spostamenti di magazzino sono allineati alle politiche ufficiali della supply chain, ecc.? Il cruscotto ispettivo è uno strumento di “debugging” poiché è progettato per riunire i dati che sono strettamente correlati, non dal punto di vista IT, ma dal punto di vista della supply chain.

Uno dei problemi più bizzarri che Lokad ha affrontato durante l’analisi dei dataset della supply chain è stato il caso delle parti teletrasportate. L’azienda - in questo caso una compagnia aerea - aveva parti di aeromobili stoccate sia in Europa continentale che nell’Asia meridionale. Poiché la sicurezza degli aeromobili è un requisito assoluto per operare, l’azienda teneva impeccabili registri degli spostamenti di magazzino per tutte le sue parti. Tuttavia, utilizzando un cruscotto ispettivo appena ideato, il team di Lokad si è reso conto che alcune parti si spostavano dall’Asia all’Europa e viceversa, presumibilmente in soli 2 o 3 minuti. Poiché le parti degli aeromobili venivano trasportate in aereo, ci si sarebbe aspettati che il tempo di trasporto fosse di almeno una dozzina di ore - certamente non di minuti. Abbiamo immediatamente sospettato un problema di fuso orario o di altro problema di tempo del computer, ma i registri del tempo si sono rivelati impeccabili. Poi, approfondendo ulteriormente i dati, è emerso che le parti che erano state teletrasportate venivano effettivamente utilizzate e montate sugli aeromobili nella loro posizione di atterraggio, una scoperta ancora più sconcertante. Lasciando che i team della supply chain guardassero da soli i cruscotti ispettivi, il mistero è stato finalmente svelato. Le parti teletrasportate erano ruote degli aeromobili composte da due mezze ruote più un pneumatico. La ruota poteva essere smontata smontando le due mezze ruote e il pneumatico. Nel caso più estremo, se le due mezze ruote e gli pneumatici venivano rimossi, non restava nulla fisicamente. Pertanto, la ruota completamente smontata poteva essere liberamente rimontata ovunque, ignorando completamente la sua posizione originale.

I cruscotti ispettivi sono il controparte a basso livello del cruscotto di controllo dei dati. Si concentrano sui dati completamente disaggregati, mentre i cruscotti di controllo dei dati di solito assumono una posizione più alta sul livello dei dati. Inoltre, i cruscotti ispettivi sono tipicamente parte integrante dello sforzo di whiteboxing. Quando si affronta ciò che sembra essere una raccomandazione enigmatica, i professionisti della supply chain devono esaminare da vicino un SKU o un prodotto, al fine di capire se la decisione raccomandata è ragionevole o meno. Il cruscotto ispettivo è tipicamente adattato a questo scopo specifico, includendo molti risultati intermedi che contribuiscono al calcolo della raccomandazione finale.