Consegne di progetto

Lo scopo di Quantitative Supply Chain è fornire decisioni applicabili – le quantità suggerite per gli ordini di acquisto essendo un esempio archetipico. Di seguito, chiariremo ulteriormente la forma specifica e il meccanismo di erogazione di tali decisioni. Stabilire aspettative chiare per le consegne è un passo importante nel percorso che rappresenta la Quantitative Supply Chain. Inoltre, i risultati numerici ottimizzati non sono l’unico output desiderabile: diversi altri output, in primis il monitoraggio della salute dei dati e i KPI di gestione, dovrebbero essere inclusi nella consegna. In pratica, le consegne di un’iniziativa di Quantitative Supply Chain dipendono dalla flessibilità della soluzione software utilizzata per supportare l’iniziativa stessa. Tuttavia, esse sono definite principalmente dal loro intento, che è agnostico rispetto alla tecnologia impiegata.

Script come consegna

La Quantitative Supply Chain enfatizza pipeline di dati completamente automatizzate data pipelines. Ciò non implica che la configurazione software debba funzionare in modo autonomo. Un alto grado di supervisione ravvicinata è naturalmente auspicabile ogni qualvolta si consideri una supply chain di larga scala. Tuttavia, ci si aspetta che la pipeline di dati sia completamente automatizzata nel senso che nessun passaggio in essa dipenda effettivamente da un’operazione manuale. Infatti, come evidenziato nel manifesto, ogni volta che operazioni manuali vengono coinvolte nel supporto all’elaborazione dei dati della supply chain, la soluzione semplicemente non scala in pratica.

Come conseguenza diretta di questo insight, le consegne di un’iniziativa di Quantitative Supply Chain sono invariabilmente interi pezzi di software. Ciò non implica che ci si aspetti che il team incaricato reimplemeni tutto: una soluzione software dedicata alla Quantitative Supply Chain offre la possibilità di concentrarsi esclusivamente sugli aspetti rilevanti delle sfide della supply chain. Tutte le tecnicismi a basso livello, come l’utilizzo di risorse di calcolo distribuite auto-allocate all’interno di una piattaforma di cloud computing, dovrebbero essere astratti. Il team non necessita di approfondire tali questioni, poiché questi aspetti sono opportunamente gestiti dagli strumenti stessi.

Le consegne si concretizzano come script tipicamente scritti in un linguaggio di programmazione in grado di soddisfare i requisiti della supply chain, pur garantendo un elevato livello di produttività. Il termine “script” viene utilizzato qui anziché “source code”, ma i due termini sono strettamente correlati: uno “script” sottolinea l’idea di un alto grado di astrazione e una focalizzazione sul compito stesso, mentre il “source code” enfatizza una prospettiva a livello inferiore, intesa come una rappresentazione accurata dell’hardware di calcolo. Per la Quantitative Supply Chain, è ovviamente la prospettiva della supply chain a contare 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 ai clienti finali ha spinto molti fornitori di software della supply chain a cercare di emulare questo approccio con una soluzione WYSIWYG per la pianificazione e l’ottimizzazione della supply chain. Tuttavia, la lezione derivante dal quasi sistematico fallimento di questo tipo di interfacce è che le supply chain sono complesse e non possono eludere la necessità di strumenti programmatici. Dalla nostra esperienza, aspettarsi che uno strumento drag-and-drop sia in grado di riflettere adeguatamente le complesse non linearità coinvolte, ad esempio, in MOQ (quantità minime d’ordine) sovrapposte, è al massimo illusorio. È richiesta un’espressività programmatica, 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 praticanti della supply chain si aspetterebbero di vedere come output tangibile dell’iniziativa di Quantitative Supply Chain. Le persone interagiranno con dashboard che contengono KPI consolidati e tabelle riunenti le decisioni suggerite. Tuttavia, tali dashboard sono transitori e usa e getta. Essi si ottengono 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 la vera consegna, con la sua espressione numerica, che è tipicamente ciò che l’utente finale della soluzione può vedere.

Dashboard per la salute dei dati

Prima di considerare la fornitura di decisioni ottimizzate per la supply chain, dobbiamo assicurarci che i dati elaborati dal sistema che supporta l’iniziativa di Quantitative Supply Chain siano corretti sia numericamente che semanticamente. Lo scopo dei dashboard di monitoraggio della salute dei dati, o semplicemente data health dashboards, è garantire un alto grado di fiducia nella correttezza dei dati, requisito essenziale per l’accuratezza di tutti i risultati numerici restituiti dalla soluzione. Questi dashboard assistono inoltre il team della supply chain nel migliorare la qualità dei dati esistenti.

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

Gli errori semantici sono più sottili e, in pratica, molto più difficili da individuare. La maggior parte del lavoro svolto durante la preparazione dei dati consiste nell’identificare e affrontare tutti gli errori semantici. Ad esempio: il campo stockinv nell’ERP potrebbe essere documentato come rappresentante lo stock disponibile. Pertanto, il team della supply chain assume che tale quantità non possa mai essere negativa, perché, ovviamente, se quelle unità sono fisicamente raggiungibili sugli scaffali, devono essere positive. Tuttavia, la documentazione dell’ERP potrebbe risultare leggermente fuorviante, e tale quantità sarebbe stata più appropriatamente definita stock available, poiché ogni volta che si verifica uno 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 in sé non è errato – è la comprensione dello stesso ad essere approssimativa. In pratica, le approssimazioni semantiche possono generare molti comportamenti incoerenti, che a loro volta producono costi di attrito continui all’interno della supply chain.

I dashboard sulla salute dei dati consolidano numeri che consentono all’azienda di decidere sul momento se i dati possano essere considerati sufficientemente affidabili o meno. Infatti, poiché la soluzione verrà utilizzata quotidianamente per scopi produttivi, è imperativo identificare, tramite un’ispezione quasi istantanea, un problema significativo nei dati. In caso contrario, è probabile che la supply chain finisca per operare per giorni, se non settimane, su dati difettosi. A questo proposito, il dashboard sulla salute dei dati è simile a un semaforo: verde si procede, rosso ci si ferma.

Inoltre, considerando una supply chain di dimensioni rilevanti, di solito esiste una quantità irriducibile di dati corrotti o comunque errati. Tali dati sorgono da inserimenti manuali difettosi o da rari casi limite nei sistemi aziendali stessi. In pratica, per qualsiasi supply chain di notevoli dimensioni, è irragionevole aspettarsi che i dati siano al 100% accurati. Invece, dobbiamo assicurarci che i dati siano sufficientemente accurati da mantenere i costi di attrito generati da tali errori quasi trascurabili.

Di conseguenza, ci si aspetta che i dashboard sulla salute dei dati raccolgano anche statistiche sugli errori individuati nei dati. Tali statistiche sono fondamentali per stabilire che i dati possano essere considerati affidabili. A tal fine, un Supply Chain Scientist viene frequentemente chiamato a stabilire soglie di allerta ben definite, tipicamente associate a un arresto totale della soluzione. È necessario prestare attenzione nella definizione di tali soglie perché, se troppo basse, la soluzione diventa inutilizzabile, essendo interrotta troppo frequentemente per “problemi di dati individuati”; tuttavia, se troppo alte, i costi di attrito generati dagli errori nei dati potrebbero diventare significativi e minare i benefici apportati dall’iniziativa stessa.

Oltre al segnalamento rosso-verde, i dashboard sulla salute dei dati sono anche destinati a fornire approfondimenti prioritari sugli sforzi di miglioramento dei dati. Infatti, molti dati potrebbero essere errati ma anche irrilevanti. Ad esempio, non importa se il prezzo di acquisto di un prodotto sia errato se la domanda di mercato per quel prodotto è scomparsa anni fa, poiché non verranno emessi ulteriori ordini di acquisto.

La Quantitative Supply Chain sottolinea che la risoluzione a grana fine degli errori nei dati, che può comportare una notevole quantità di lavoro manuale, dovrebbe essere priorizzata rispetto all’impatto finanziario stimato dell’errore stesso in confronto al costo del lavoro necessario per correggerlo. Infatti, a seconda della situazione, il costo associato alla correzione di un singolo dato errato varia enormemente e deve essere considerato nella prioritizzazione suggerita. Infine, quando il costo delle correzioni è ritenuto superiore ai costi della supply chain generati da tali errori, il processo di miglioramento dei dati può essere interrotto.

Dashboard di decisioni prioritizzate

Come abbiamo visto, solo le decisioni della supply chain possono essere valutate veramente da una prospettiva quantitativa. Pertanto, non sorprende che uno dei principali deliverable operativi di un’iniziativa di Quantitative Supply Chain siano i dashboard che consolidano le decisioni ottenute come risultato numerico finale dell’intera pipeline dati. Un tale dashboard può essere semplice come una tabella che elenca, per ogni prodotto, la quantità esatta in unità da riordinare immediatamente. Se sono presenti MOQs (quantità minime d’ordine) – o eventuali altre restrizioni d’ordine – le quantità suggerite potrebbero essere per lo più pari a zero, finché non si raggiungono le soglie appropriate.

Per semplicità, assumiamo qui che tali risultati numerici siano raccolti in un dashboard, che rappresenta una forma specifica di interfaccia utente. Tuttavia, il dashboard stesso è solo un’opzione, che può essere rilevante o meno. In pratica, ci si aspetta che il software che alimenta l’iniziativa di Quantitative Supply Chain sia altamente flessibile, cioè programmaticamente flessibile, offrendo molte modalità per confezionare tali risultati in vari formati di dati. Ad esempio, i risultati numerici possono essere consolidati in file di testo flat, destinati ad essere importati automaticamente nell’ERP principale utilizzato per gestire gli asset aziendali.

Mentre il formato delle decisioni dipende fortemente dal compito della supply chain in esame, la maggior parte delle attività richiede di priorizzarle. Ad esempio, il calcolo delle quantità suggerite per un ordine di acquisto può essere scomposto attraverso una lista prioritaria di unità da acquisire. L’unità più redditizia viene classificata per prima. Poiché lo stock presenta ritorni decrescenti, la seconda unità acquistata per lo stesso prodotto soddisfa una frazione decrescente della domanda di mercato. Pertanto, la seconda unità per quel prodotto potrebbe non essere il secondo elemento dell’elenco complessivo. Invece, la seconda unità più redditizia può essere associata a un altro prodotto, e così via. La lista prioritaria delle unità da acquisire è concettualmente infinita: è sempre possibile acquistare un’ulteriore unità. Poiché la domanda di mercato è finita, tutte le unità acquistate diventeranno invendute a 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, le restrizioni d’ordine non lineari complicano ulteriormente questo compito, ma, per semplicità, metteremo da parte tali vincoli in questa fase della discussione.

Dare priorità alle decisioni è un’operazione molto naturale dal punto di vista della Quantitative Supply Chain. Poiché ogni decisione è associata a un esito finanziario espresso in dollari, ordinare le decisioni dalla più redditizia alla meno redditizia è semplice. Pertanto, molti – se non la maggior parte – dei dashboard che compilano le decisioni suggerite per la supply chain possono essere, in pratica, liste prioritarie di decisioni. Questi dashboard contengono elenchi con decisioni altamente redditizie in cima e decisioni molto poco redditizie in fondo. In alternativa, i praticanti della supply chain possono decidere di troncare gli elenchi quando le decisioni risultano non redditizie. Tuttavia, spesso si possono ottenere spunti importanti dall’ispezione di decisioni che cadono appena al di sotto della soglia di redditività, anche se ovviamente non ci si aspetta che l’azienda agisca su quegli elementi non redditizi.

Per fornire questo tipo di dashboard orientati alle decisioni, la soluzione software che supporta la Quantitative Supply Chain deve esplorare numericamente vaste quantità di decisioni possibili. Ad esempio, la soluzione dovrebbe essere in grado di considerare l’impatto finanziario di acquistare ogni singola unità, unità per unità, per ogni prodotto in ogni località. Non sorprende che tale operazione possa richiedere risorse di calcolo sostanziali. Fortunatamente, al giorno d’oggi, l’hardware di calcolo è in grado di gestire anche le più grandi supply chain globali. Presumendo che la soluzione software sottostante sia opportunamente architettata per la Quantitative Supply Chain, la scalabilità dell’elaborazione dei dati non dovrebbe rappresentare un problema per i team della supply chain.

Analisi trasparente dei risultati numerici

I sistemi, derisoriamente definiti come black boxes nella supply chain – e in altri campi – sono quei sistemi che generano output che non possono essere spiegati dai praticanti che interagiscono con essi. La Quantitative Supply Chain, con il suo focus specifico su una pipeline di dati automatizzata, corre il rischio di fornire ciò che i team della supply chain definirebbero “black boxes”. 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, esso può anche potenzialmente creare disastri. Sebbene l’automazione sia altamente auspicabile, ciò non significa che al team della supply chain non si richieda una comprensione approfondita di ciò che viene erogato dalla pipeline di dati che supporta l’iniziativa di Quantitative Supply Chain.

Il termine whiteboxing si riferisce allo sforzo necessario per rendere la soluzione completamente trasparente a beneficio dei team della supply chain. Questo approccio sottolinea che nessuna tecnologia è trasparente per progettazione. La trasparenza è il risultato finale di uno sforzo specifico, che fa parte dell’iniziativa stessa. Anche una semplice regressione lineare può generare risultati sconcertanti nella pratica. Mettendo da parte qualche individuo eccezionale, la maggior parte delle persone non ha una comprensione intuitiva di quale sia l’output “atteso” del modello lineare ogni volta che sono coinvolte 4 dimensioni o più. Eppure, i problemi della supply chain spesso coinvolgono decine, se non centinaia, di variabili. Pertanto, anche modelli statistici semplicistici sono di fatto scatole nere per i professionisti della supply chain. Naturalmente, quando vengono utilizzati algoritmi di machine learning, come raccomandato da Quantitative Supply Chain, essi lasciano i professionisti ancora più all’oscuro.

Mentre l’effetto scatola nera è un problema reale, una soluzione realistica non risiede 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 benefici delle risorse informatiche moderne, le quali possono essere impiegate per affrontare la complessità intrinseca delle supply chain moderne. Semplificare e banalizzare il processo non è la risposta. Il whiteboxing lo è.

Anche le raccomandazioni più complesse per la supply chain possono essere rese in gran parte trasparenti per i professionisti della supply chain, semplicemente decomponendo i calcoli interni con indicatori finanziari ben scelti indicators, che rappresentano i driver economici a supporto della raccomandazione stessa. Ad esempio, invece di mostrare semplicemente una tabella grezza con due colonne, prodotto e quantità, come ordine d’acquisto suggerito, la tabella dovrebbe includere un paio di colonne che facilitino il processo decisionale. Queste colonne aggiuntive possono includere lo stock attuale, la domanda totale nell’ultimo mese, il lead time previsto, il costo finanziario atteso di un esaurimento scorte (se non viene effettuato un ordine), il costo finanziario atteso per un sovraccarico di magazzino (rischio associato all’ordine suggerito), ecc. Le colonne sono studiate per fornire al team della supply chain dei controlli rapidi sulle quantità suggerite. Attraverso queste colonne, il team può rapidamente instaurare fiducia nell’output numerico e individuare alcune delle debolezze di una soluzione che necessita di ulteriori miglioramenti.

Estendere i dashboard a scopo di whiteboxing è in parte un’arte. Generare milioni di numeri è facile, anche con risorse informatiche non superiori a quelle disponibili su uno smartphone. Tuttavia, generare 10 numeri tali da valere la pena di essere esaminati quotidianamente è molto difficile. Pertanto, la sfida fondamentale è identificare una dozzina o meno di KPI che siano sufficienti a fare luce sulle decisioni raccomandate per la supply chain. I buoni KPI richiedono solitamente molto lavoro; non dovrebbero essere definizioni naïve, che di solito fuorviano nella supply chain. Ad esempio, anche una colonna semplice come il “prezzo d’acquisto unitario” può essere altamente fuorviante se il fornitore offre sconti per quantità, rendendo così il prezzo d’acquisto dipendente dalla quantità acquistata.

Dashboard strategici

Pur essendo necessario concentrarsi su decisioni di piccola scala – in quanto è uno dei pochi approcci che si presta a valutazioni quantitative delle prestazioni – la supply chain potrebbe anche dover essere adattata in modi più ampi e dirompenti, per innalzare le prestazioni al livello successivo. Ad esempio, l’acquisto di unità di stock ben selezionate incrementa marginalmente il service level. Tuttavia, a un certo punto, il magazzino si riempie e non è possibile acquistare unità aggiuntive. In questa situazione, si dovrebbe prendere in considerazione un magazzino più grande. Per valutare l’impatto dell’eliminazione di questo vincolo, possiamo rimuovere il limite di capacità del magazzino dai calcoli e valutare il potenziale finanziario complessivo di operare con un magazzino arbitrariamente grande. La direzione della supply chain può quindi monitorare l’indicatore finanziario associato al costo di attrito imposto dalla capacità del magazzino stesso, e stabilire quando è il momento di considerare un aumento della capacità di magazzinaggio.

Tipicamente, le supply chain operano basandosi su numerosi vincoli che non possono essere rivisti quotidianamente. Questi vincoli possono includere il capitale circolante, la capacità di magazzinaggio, i ritardi nei trasporti, il throughput produttivo, ecc. Ogni vincolo è associato a un costo opportunità implicito per la supply chain, che tipicamente si traduce in maggior stock, maggiori ritardi o esaurimenti delle scorte. Il costo opportunità può essere valutato attraverso i miglioramenti delle prestazioni che si otterrebbero eliminando o indebolendo il vincolo stesso. Sebbene alcune di queste simulazioni possano rivelarsi difficili da implementare, spesso non sono più complesse dell’ottimizzazione delle decisioni di routine, cioè stabilire le quantità dell’ordine d’acquisto.

Il Quantitative Supply Chain sottolinea che i costi opportunità associati a questi vincoli dovrebbero far parte del flusso di produzione dei dati e, tipicamente, dovrebbero essere concretizzati in dashboard dedicate, specificamente intese ad aiutare la direzione della supply chain a decidere quando è il momento di apportare cambiamenti maggiori. Questi tipi di dashboard sono chiamati dashboard strategici. Questo approccio si differenzia dalla pratica tradizionale della supply chain, che enfatizza iniziative ad hoc quando si percepisce che la supply chain sta per raggiungere un limite operativo. Infatti, i KPI forniti dai dashboard strategici vengono aggiornati quotidianamente, o più frequentemente se necessario, proprio come il resto del flusso dei dati. Non è necessario fare uno sforzo all’ultimo minuto, perché sono aggiornati e pronti a capitalizzare le intuizioni ottenute da un’iniziativa di lunga durata.

I dashboard strategici supportano il processo decisionale della direzione della supply chain. Poiché fanno parte del flusso dei dati, ogniqualvolta il mercato inizia ad evolversi a un ritmo più veloce del solito, i KPI rimangono aggiornati sulla situazione attuale dell’azienda. Questo approccio evita le insidie tradizionali associate alle indagini ad hoc che inesorabilmente aggiungono ulteriori ritardi a problemi già in sospeso. Inoltre, mitiga in gran parte il problema alternativo, ovvero decisioni strategiche affrettate che si rivelano non redditizie – una condizione spiacevole che avrebbe potuto essere prevista fin dall’inizio.

Dashboard ispettivi

Le supply chain sono sia complesse che erratiche. Queste caratteristiche rendono il debug del flusso dei dati un compito estremamente impegnativo. Eppure, questo flusso dei dati è la spina dorsale dell’iniziativa Quantitative Supply Chain. Errori nell’elaborazione dei dati, oppure bug, possono verificarsi ovunque all’interno del flusso dei dati. Peggio ancora, il tipo di problema più frequente non è la formula errata, ma l’ambiguità semantica. Ad esempio, all’inizio del flusso, la variabile stockinv potrebbe riferirsi allo stock disponibile (dove sono possibili valori negativi), mentre più avanti la stessa variabile viene utilizzata con un’interpretazione di stock in magazzino (dove i valori sono attesi in positivo). L’interpretazione ambigua della variabile stockinv può generare una vasta gamma di comportamenti errati, che spaziano dai crash di sistema – evidenti e quindi solo moderatamente dannosi – a una corruzione silente e pervasiva delle decisioni della supply chain.

Dato che le supply chain sono quasi sempre costruite a partire da un mix unico di soluzioni software implementate nel corso degli anni, non c’è speranza di accedere a una soluzione software “collaudata” priva di bug. Infatti, la maggior parte dei problemi sorge alle interfacce di sistema, quando si riconciliano dati provenienti da sistemi differenti, o anche semplicemente da moduli differenti all’interno dello stesso sistema. Pertanto, per quanto collaudata la soluzione software possa essere, gli strumenti devono essere in grado di supportare agevolmente il processo di debug, poiché questo tipo di problemi è inevitabile.

Lo scopo dei dashboard ispettivi è fornire viste dettagliate per un’ispezione minuziosa dei dataset della supply chain. Eppure, questi dashboard non sono semplici drill-down per ispezionare le tabelle dei dati di input. Tali drill-down, o approcci simili di slice-and-dice sui dati, perderebbero il punto. Le supply chain riguardano i flussi: flusso di materiali, flusso di pagamenti, ecc. Alcuni dei problemi più gravi relativi ai dati si verificano quando la continuità del flusso viene “logicamente” interrotta. Ad esempio, quando si spostano merci dal magazzino A al magazzino B, il database del magazzino B potrebbe non contenere alcune voci di prodotto, generando sottili corruzioni dei dati, in quanto le unità provenienti dal magazzino A vengono ricevute nel magazzino B senza essere correttamente associate al loro prodotto. Quando i risultati numerici appaiono strani, quei dashboard ispettivi sono l’opzione ideale per il Supply Chain Scientist per effettuare una rapida indagine campionaria dei dati.

In pratica, un dashboard ispettivo fornisce un punto d’ingresso a basso livello, come un codice prodotto o un SKU, e consolida tutti i dati associati a questo punto d’ingresso in una vista unica. Quando le merci scorrono attraverso molteplici località, come accade ad esempio nelle supply chain aerospaziali, il dashboard ispettivo normalmente tenta di ricostruire i percorsi delle merci, che potrebbero aver transitato non solo attraverso più località fisiche, ma anche tramite diversi sistemi. Raccolgendo tutti questi dati in un unico luogo, diventa possibile per il Supply Chain Scientist verificare se i dati hanno senso: è possibile identificare da dove provengono le merci spedite? I movimenti di stock sono in linea con le politiche ufficiali della supply chain, ecc.? Il dashboard ispettivo è uno strumento di “debug” in quanto è progettato per riunire i dati strettamente correlati, non da un punto di vista IT, ma da quello 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 nell’Europa continentale che nell’Asia meridionale. Poiché la sicurezza degli aeromobili è un requisito assoluto per operare, l’azienda conservava registrazioni impeccabili dei movimenti di stock per tutte le sue parti. Eppure, utilizzando un dashboard ispettivo di nuova ideazione, il team di Lokad si è reso conto che alcune parti si muovevano dall’Asia all’Europa, e viceversa, presumibilmente in soli 2 o 3 minuti. Poiché le parti degli aeromobili venivano trasportate tramite aereo, il tempo di trasporto sarebbe dovuto essere almeno di una decina d’ore – certamente non minuti. Abbiamo immediatamente sospettato un problema di fuso orario o un altro difetto legato all’orario del computer, ma i record temporali si sono dimostrati impeccabili. Successivamente, indagando ulteriormente sui dati, è emerso che le parti teletrasportate venivano effettivamente utilizzate e montate sugli aeromobili nel luogo di atterraggio, una scoperta ancor più sconcertante. Lasciando che fossero i team della supply chain a esaminare personalmente i dashboard ispettivi, il mistero è stato finalmente svelato. Le parti teletrasportate erano ruote per aeromobili composte da due mezze ruote più un pneumatico. La ruota poteva essere smontata separando le due mezze ruote e il pneumatico. Nel caso più estremo, se le due mezze ruote e il pneumatico venivano rimossi, non rimaneva nulla fisicamente. Pertanto, la ruota completamente smontata poteva essere rimontata liberamente ovunque, ignorando completamente la sua posizione originaria.

I dashboard ispettivi sono il corrispettivo a basso livello del dashboard sulla salute dei dati. Essi si concentrano sui dati completamente disaggregati, mentre i dashboard sulla salute dei dati generalmente assumono un approccio più macro. Inoltre, i dashboard ispettivi sono tipicamente parte integrante dello sforzo di whiteboxing. Di fronte a quella che sembra essere una raccomandazione sconcertante, i professionisti della supply chain devono esaminare da vicino uno SKU o un prodotto, per capire se la decisione raccomandata sia ragionevole o meno. Il dashboard ispettivo è solitamente adattato proprio a questo scopo, includendo numerosi risultati intermedi che contribuiscono al calcolo della raccomandazione finale.