Iniziativa della supply chain quantitativa

supply chain quantitativa Ottimizzazione, o in breve supply chain quantitativa, è una prospettiva ampia sulle supply chain che, in poche parole, mira a sfruttare al massimo l’intelligenza umana, potenziata dalle capacità delle moderne risorse di calcolo. Tuttavia, questa prospettiva non è onnicomprensiva. Non pretende di essere la soluzione definitiva alle supply chain challenges, ma di essere un approccio complementare che quasi sempre può essere utilizzato per migliorare la situazione.

L’iniziativa

La supply chain quantitativa aiuta la tua azienda a migliorare la qualità del servizio, a ridurre gli stock in eccesso e gli ammortamenti, a incrementare la produttività, a ridurre i prezzi d’acquisto e i costi operativi … e la lista continua. Le sfide della supply chain variano notevolmente a seconda delle diverse situazioni. La supply chain quantitativa abbraccia questa diversità e si impegna, pur affrontando la complessità risultante. Tuttavia, per gli operatori della supply chain abituati ad approcci più classici per ottimizzare le loro supply chain, la supply chain quantitativa potrebbe risultare un po’ sconcertante.

Di seguito, esaminiamo gli ingredienti necessari per sfruttare al massimo la prospettiva quantitativa sulla supply chain. Analizziamo e chiarifichiamo le ambizioni di un’iniziativa di supply chain quantitativa. Rivediamo i ruoli e le competenze del team incaricato dell’esecuzione dell’iniziativa. Infine, forniamo una breve panoramica della metodologia associata alla supply chain quantitativa.

L’ambizione

Ad eccezione delle aziende molto piccole, una supply chain comporta milioni di decisioni ogni giorno. Per ogni unità in magazzino, ogni giorno, l’azienda decide di mantenerla dove essa è, anziché spostarla altrove. Inoltre, la stessa logica vale per le unità non esistenti che potrebbero essere prodotte o acquistate. Non fare nulla è già una decisione in sé.

La supply chain quantitativa riguarda l’ottimizzazione dei milioni di decisioni che l’azienda deve prendere ogni giorno e, dato che si parla di milioni, se non miliardi di decisioni al giorno, i computer giocano un ruolo centrale in questo compito. Non sorprende, dopotutto, che le supply chain siano state storicamente una delle prime funzioni aziendali, dopo la contabilità, a essere digitalizzate alla fine degli anni ‘70. Eppure, la supply chain quantitativa mira a portare la digitalizzazione un passo avanti.

Qui dobbiamo riconoscere che tentativi mal indirizzati di implementare il “supply chain system of the future” sono stati frequenti negli ultimi due decenni. Troppe volte, tali sistemi non hanno fatto altro che causare il caos nelle supply chain, combinando effetti da scatola nera e automazione fallita, generando così tantissime decisioni errate che i problemi non potevano più essere risolti con l’intervento umano.

In una certa misura, la supply chain quantitativa è nata da quegli errori: invece di fingere che il sistema conosca in qualche modo l’azienda meglio del suo stesso management, bisogna concentrarsi sull’esecuzione degli insight generati dal management, ma con un grado maggiore di affidabilità, chiarezza e agilità. La tecnologia software fatta bene è un abilitante capace, ma, considerando le attuali capacità del software, escludere completamente le persone dalla soluzione non è un’opzione realistica.

Questa ambizione ha una conseguenza immediata: il software che l’azienda utilizza per tenere traccia dei suoi prodotti, materiali e altre risorse non sarà lo stesso del software di cui l’azienda ha bisogno per ottimizzare le sue decisioni. Infatti, sia che si tratti di un ERP, di un WMS, di un MRP o di un OMS, tutto questo software si concentra principalmente sul gestire i processi aziendali e il flusso delle registrazioni dei dati. Non fraintendeteci, ci sono enormi benefici nel semplificare le registrazioni dei dati e nell’automatizzare tutte le attività amministrative. Tuttavia, il nostro punto resta che tali compiti non affrontano minimamente la sfida principale, che è aumentare la capacità della tua azienda di attuare gli insight umani, su una scala compatibile con la tua supply chain.

Poi, non c’è ottimizzazione senza misurazione. Pertanto, la supply chain quantitativa riguarda fortemente le misurazioni - come suggerisce il suo nome. Le decisioni della supply chain - acquistare stock, spostare stock - hanno conseguenze, e la qualità di tali decisioni dovrebbe essere valutata finanziariamente (ad esempio in dollari) con solide prospettive di business. Tuttavia, ottenere metriche buone e solide richiede impegno, un impegno significativo. Uno degli obiettivi della supply chain quantitativa è aiutare l’azienda a stabilire tali metriche, che giocano anche un ruolo critico nelle fasi successive di un progetto, per valutare il ritorno sull’investimento (ROI) dell’iniziativa complessiva della supply chain.

Infine, come già detto, la supply chain quantitativa non è un paradigma che abbraccia tutto. Non ha l’ambizione di risolvere o migliorare tutto nella supply chain dell’azienda. Non sostiene di aiutarti a trovare fornitori fidati o partner logistici affidabili. Non promette di aiutarti a formare team eccellenti e a mantenerne alto il morale. Eppure, grazie al suo focus molto specifico, la supply chain quantitativa è pienamente in grado di fornire risultati tangibili.

I ruoli del progetto

La supply chain quantitativa richiede una sorprendentemente bassa quantità di risorse umane, anche quando si gestiscono supply chain di una certa scala. Tuttavia, tale iniziativa richiede risorse specifiche, di cui tratteremo i dettagli in questa sezione. Ma prima di approfondire i vari ruoli e le loro peculiarità, iniziamo menzionando un principio fondamentale della supply chain quantitativa: l’azienda dovrebbe capitalizzare ogni intervento umano.

Questo principio è in contrasto con quanto avviene in pratica con le soluzioni tradizionali per la supply chain: gli sforzi umani vengono consumati dalla soluzione, non capitalizzati. Per continuare a generare un flusso ininterrotto di decisioni, la soluzione richiede un flusso ininterrotto di immissioni manuali. Tali immissioni possono assumere molte forme: l’adeguamento dei profili stagionali, la gestione delle eccezioni e degli avvisi, la correzione di valori di forecast anomali, ecc.

La supply chain quantitativa cerca di invertire questa prospettiva. Non è solo che il lavoro umano sia costoso, ma il fatto che l’expertise nella supply chain combinata con acuti insight di business è troppo rara e preziosa per essere sprecata in compiti ripetitivi. La causa alla radice dell’intervento manuale andrebbe invece risolta: se i valori di forecast sono errati, non ha senso modificarli, è necessario correggere i dati in ingresso o l’algoritmo di previsione stesso. Correggere i sintomi garantisce di dover affrontare continuamente gli stessi problemi.

La dimensione del team necessario per eseguire un’iniziativa di supply chain quantitativa varia a seconda della scala stessa della supply chain. All’estremità inferiore dello spettro, può essere inferiore a una FTE (dipendente full-time), tipicamente per aziende con un fatturato inferiore a 20 milioni di dollari. All’estremità superiore dello spettro, può coinvolgere una dozzina di persone; ma in questo caso, in genere, sono in gioco inventari per valore di diversi miliardi di dollari.

Il Supply Chain Leader: la supply chain quantitativa rappresenta un cambio di paradigma. Guidare il cambiamento richiede leadership e supporto dal top management. Troppe volte, i leader della supply chain non sentono di avere il tempo per essere direttamente coinvolti in quelle che sono percepite come le “specifiche tecniche” di una soluzione. Eppure, la supply chain quantitativa riguarda l’esecuzione di insight strategici su larga scala. Non condividere gli insight strategici con il team responsabile dell’iniziativa è una ricetta per il fallimento. Al management non ci si aspetta che trovi tutte le metriche e i KPI rilevanti – dato che richiede un grande sforzo metterli insieme – ma ci si aspetta sicuramente che li metta in discussione.

Il Supply Chain Coordinator: mentre l’iniziativa di supply chain quantitativa è concepita per avere un organico molto snello, la maggior parte delle supply chain non lo è, o almeno non così snella. Il mancato coinvolgimento di tutti può portare a confusione e rallentare l’iniziativa. Pertanto, la missione del Coordinator è raccogliere tutto il feedback interno necessario per l’iniziativa e comunicare con tutte le parti coinvolte. Il Coordinator chiarisce i processi e le decisioni che devono essere prese, e raccoglie feedback sulle metriche e sui KPI che saranno utilizzati per ottimizzare tali decisioni. Si assicura inoltre che la soluzione abbracci i flussi di lavoro aziendali così come sono, pur preservando la possibilità di rivedere tali flussi in una fase successiva dell’iniziativa.

Il Data Officer: la supply chain quantitativa dipende in modo critico dai dati, e ogni iniziativa deve avere accesso affidabile ai dati da una prospettiva di elaborazione batch. Infatti, l’iniziativa non si limita a leggere poche righe nel sistema aziendale, ma coinvolge la lettura dell’intera storia delle vendite, dell’intera storia degli acquisti, dell’intero catalogo prodotti, ecc. Il Data Officer è solitamente delegato dal dipartimento IT per supportare l’iniziativa. È responsabile dell’automatizzazione di tutta la logica di estrazione dei dati e di programmare tale logica per estrazioni giornaliere. In pratica, gli sforzi del Data Officer si concentrano principalmente all’inizio dell’iniziativa.

Il Supply Chain Scientist: egli utilizza la tecnologia - di cui parleremo meglio a seguire - per combinare gli insight raccolti dal Coordinator con i dati estratti dal Data Officer, al fine di automatizzare la produzione di decisioni. Lo scientist inizia preparando i dati, un compito sorprendentemente difficile che richiede molto supporto dal Coordinator, il quale dovrà interagire con le numerose persone che hanno prodotto i dati in origine, per chiarire qualsiasi eventuale dubbio. Egli formalizza la strategia in modo che possa essere utilizzata per generare decisioni - ad esempio, le quantità suggerite per il riapprovvigionamento. Infine, il Supply Chain Scientist dota l’intera pipeline di dati di dashboard e KPI per garantire chiarezza, trasparenza e controllo.

Per le aziende di medie dimensioni, far ricoprire la funzione di Coordinator e Data Officer alla stessa persona può essere estremamente efficiente. Ciò richiede una gamma di competenze che non è sempre facile da trovare in un singolo dipendente, tuttavia, se una tale persona esiste nell’organizzazione, tende a essere un valore aggiunto per accelerare l’iniziativa. Poi, per le aziende più grandi, anche se il Coordinator non ha una conoscenza approfondita dei database aziendali all’inizio dell’iniziativa, è un grande vantaggio se il Coordinator è in grado di acquisire un certo livello di familiarità con i database man mano che l’iniziativa procede. Infatti, il panorama IT continua a cambiare, e anticipare come tali cambiamenti impatteranno sull’iniziativa aiuta notevolmente a garantire un’esecuzione fluida e continua.

La tecnologia

Finora, siamo rimasti piuttosto vaghi riguardo alla tecnologia software necessaria per supportare la supply chain quantitativa. Eppure, la supply chain quantitativa dipende in maniera critica dallo stack tecnologico usato per implementarla. Sebbene, concettualmente, ogni pezzo di software potrebbe essere re-implementato da zero, il Supply Chain Scientist richiede un incredibile supporto dal suo stack per essere anche solo ragionevolmente produttivo. Inoltre, certe capacità come la previsione e l’ottimizzazione numerica richiedono significativi sforzi di R&S preliminari che vanno ben oltre quanto il Supply Chain Scientist possa fornire durante l’iniziativa.

Il primo requisito della supply chain quantitativa è una data platform con capacità programmatiche, e, naturalmente, avere accesso a una data platform specificamente progettata per gestire i dati e i problemi della supply chain è sicuramente un vantaggio. Ci riferiamo a una data platform, perché sebbene qualsiasi workstation desktop possa oggi memorizzare diversi terabyte, ciò non significa che tale workstation offra altre proprietà desiderabili per condurre l’iniziativa: affidabilità contro i guasti hardware, tracciabilità di tutti gli accessi, compatibilità con le esportazioni dei dati, ecc. Inoltre, poiché i dataset della supply chain tendono ad essere grandi, la data platform dovrebbe essere più scalabile, ovvero in grado di elaborare grandi quantità di dati in un breve lasso di tempo.

La data platform richiede capacità programmatiche, che si riferiscono alla possibilità di implementare ed eseguire praticamente qualsiasi logica arbitraria di elaborazione dei dati. Tali capacità sono fornite attraverso un linguaggio di programmazione. La programmazione è percepita correttamente come una competenza molto tecnica, e molti fornitori approfittano della paura ispirata dall’idea di dover affrontare una soluzione che richiede “programming” per offrire agli utenti interfacce semplici con pulsanti e menu. Tuttavia, ogni volta che ai team della supply chain vengono negate capacità programmatiche, prevalgono i fogli Excel, proprio perché Excel offre capacità programmatiche con la possibilità di scrivere formule che possono essere arbitrarie e complesse. Lungi dall’essere un gadget, le capacità programmatiche sono un requisito fondamentale.

Infine, vi sono significativi vantaggi nell’avere una piattaforma dati su misura per supply chain. In effetti, la necessità di una piattaforma dati di qualche tipo non è propriamente specifica della supply chain: il trading quantitativo, come svolto da banche e fondi, presenta esigenze analoghe. Tuttavia, le decisioni in ambito supply chain non richiedono latenze inferiori al millisecondo come avviene nel trading ad alta frequenza. La progettazione di una piattaforma dati è una questione di compromessi ingegneristici nonché di un ecosistema software, che inizia con i formati dati supportati. Tali compromessi ingegneristici e l’ecosistema software dovrebbero essere allineati con le stesse sfide della supply chain.

Il secondo requisito di Quantitative Supply Chain è un motore di previsione probabilistico. Questo software è responsabile di assegnare una probabilità a ogni possibile futuro. Sebbene questo tipo di previsione sia inizialmente un po’ inquietante perché contraddice l’intuizione di prevedere il futuro, il vero “intoppo” risiede nell’incertezza: il futuro non è certo e una singola previsione è destinata ad essere sbagliata. La prospettiva classica di previsione nega l’incertezza e la variabilità e, di conseguenza, l’azienda si ritrova a lottare con una previsione che doveva essere accurata, ma non lo è. Un motore di previsione probabilistico affronta direttamente questo problema risolvendo la questione con le probabilità.

La previsione probabilistica in supply chain è tipicamente un processo a due fasi che inizia con una previsione del lead time e prosegue con una previsione della domanda. La previsione del lead time è una previsione probabilistica: viene assegnata una probabilità a tutte le possibili durate del lead time, solitamente espresse in giorni. Successivamente, anche la previsione della domanda è probabilistica e viene costruita sulla base della previsione del lead time fornita in input. In questo modo, l’orizzonte da coprire con la previsione della domanda deve corrispondere ai lead time, che sono anch’essi incerti.

Poiché il motore di previsione probabilistico produce insiemi di distribuzioni di probabilità, i suoi output di previsione coinvolgono molti più dati rispetto agli output di un motore di previsione classico. Questo non rappresenta un problema insormontabile in sé, ma per evitare di affrontare troppa frizione durante l’elaborazione di un vasto insieme di probabilità, è richiesta un’elevata collaborazione tra la piattaforma dati e il motore di previsione.

Le fasi del progetto

Quantitative Supply Chain è fortemente ispirata dalla R&S dell’ingegneria del software e dalle migliori pratiche note della data science. La metodologia è altamente iterativa, con scarso rilievo dato alle specificazioni preliminari, e un forte accento sull’agilità e la capacità di recuperare da problemi e/o risultati inaspettati. Di conseguenza, questa metodologia tende a essere percepita come piuttosto sorprendente dalle aziende che non sono profondamente coinvolte nell’industria del software.

La prima fase è la fase di scoping, che definisce quali decisioni in ambito supply chain l’iniziativa intende coprire. Questa fase serve anche a diagnosticare la complessità prevista del processo decisionale e dei dati rilevanti.

La seconda fase è la fase di preparazione dei dati. Essa consiste nell’istituire una configurazione automatizzata che copia tutti i dati rilevanti dai sistemi aziendali su una piattaforma analitica separata. Consiste inoltre nel preparare questi dati per un’analisi quantitativa.

La terza fase è la fase pilota e consiste nell’implementare una logica iniziale di presa di decisione che genera decisioni, ad esempio le quantità di acquisto suggerite, che di per sé superano già i processi precedenti dell’azienda. Si prevede che questa logica sia completamente automatizzata.

La quarta fase è la fase di produzione, che porta l’iniziativa alla velocità di crociera, dove le prestazioni vengono monitorate e mantenute, e dove si raggiunge un consenso sul grado desiderabile di raffinatezza dei modelli della supply chain.

La fase di scoping è la più semplice e identifica le decisioni di routine che l’iniziativa Quantitative Supply Chain intende coprire. Tali decisioni potrebbero coinvolgere molteplici vincoli: MOQ (quantità minime d’ordine), full containers, capacità massima del magazzino, … e questi vincoli dovrebbero essere esaminati attentamente. Successivamente, le decisioni sono anche associate ai driver economici: costi di mantenimento, costo degli stock-out, margine lordo, … e tali fattori economici dovrebbero essere studiati. Infine, i dati storici rilevanti dovrebbero essere identificati, insieme ai sistemi dai quali verranno estratti i dati.

La fase di preparazione dei dati è la fase più difficile; la maggior parte dei fallimenti tende a verificarsi in questa fase. Ottenere accesso ai dati e dar loro un senso è quasi sempre una sfida sottovalutata. I sistemi operativi (es. ERP / MRP / WMS / OMS) sono stati progettati per far funzionare l’azienda, per mantenerla in attività. I dati storici sono un sottoprodotto di tali sistemi, poiché la registrazione dei dati non è stata la ragione per cui questi sistemi sono stati implementati. Pertanto, in questa fase ci si deve aspettare molte difficoltà. Di fronte alle difficoltà, la maggior parte delle aziende ha un riflesso sfortunato: facciamo un passo indietro e scriviamo una specifica completa. Sfortunatamente, una specifica può coprire solo le difficoltà note o previste. Eppure, quasi tutti i principali problemi che si incontrano in questa fase sono elementi che non possono essere pianificati.

In realtà, i problemi tendono a rivelarsi solo quando qualcuno inizia effettivamente a mettere alla prova i dati per generare decisioni basate sui dati. Se le decisioni risultano errate mentre la logica è considerata solida, allora probabilmente c’è un problema con i dati. Le decisioni basate sui dati tendono ad essere piuttosto sensibili alle problematiche dei dati e, pertanto, rappresentano in realtà un ottimo modo per mettere in discussione quanto controllo l’azienda abbia sui propri dati. Inoltre, questo processo sfida i dati in modi che hanno significato per l’azienda. La qualità dei dati e la comprensione degli stessi non sono altro che mezzi per raggiungere un fine: fornire qualcosa di valore per l’azienda. È molto ragionevole concentrare gli sforzi sui problemi dei dati che hanno un impatto significativo sulle decisioni basate sui dati.

La fase pilota è quella che mette alla prova la gestione della supply chain. Abbracciare l’incertezza con previsioni probabilistiche può risultare piuttosto controintuitivo. Allo stesso tempo, molte pratiche tradizionali come previsioni settimanali o mensili, scorte di sicurezza, coperture di stock, avvisi di stock o analisi ABC fanno in realtà più male che bene. Questo non significa che l’iniziativa Quantitative Supply Chain debba andare a briglia sciolta. Infatti, è tutto il contrario, in quanto Quantitative Supply Chain riguarda la performance misurabile. Tuttavia, molte pratiche tradizionali della supply chain hanno la tendenza a inquadrare i problemi in modi contrari alla loro risoluzione. Pertanto, durante la fase pilota, una sfida chiave per la leadership della supply chain è rimanere aperti mentalmente e non reiniettare nell’iniziativa quegli stessi elementi che in un secondo momento genereranno inefficienze. Non si può amare la causa mentre si maledice la conseguenza.

Successivamente, sia il Supply Chain Scientist che la tecnologia sono messi alla prova, dato che la logica deve essere implementata per generare le decisioni in un lasso di tempo relativamente breve. L’obiettivo iniziale è semplicemente generare ciò che i professionisti percepiscono come decisioni ragionevoli, decisioni che non richiedono necessariamente correzioni manuali. Suggeriamo di non sottovalutare quanto sia grande la sfida nel generare decisioni automatizzate “affidabili”. I sistemi tradizionali della supply chain richiedono molte correzioni manuali per funzionare: nuovi prodotti, promozioni, rotture di stock… Quantitative Supply Chain stabilisce una nuova regola: non sono più consentite immissioni manuali per operazioni banali, tutti i fattori devono essere integrati nella logica.

Il Supply Chain Coordinator è presente per raccogliere tutti i fattori, i flussi di lavoro e le specificità che dovrebbero essere integrati nella logica decisionale. Successivamente, il Supply Chain Scientist implementa il primo gruppo di KPI associati alle decisioni. Questi KPI sono introdotti per evitare effetti black-box che tendono a insorgere quando vengono utilizzati metodi numerici avanzati. È importante notare che i KPI sono ideati insieme al Supply Chain Leader, il quale garantisce che le misurazioni siano allineate con la strategia aziendale.

La fase di produzione stabilizza l’iniziativa e la porta alla velocità di crociera. Le decisioni generate dalla logica vengono attivamente utilizzate e i relativi risultati vengono monitorati da vicino. In genere, occorrono da qualche settimana a qualche mese per valutare l’impatto di una determinata decisione in ambito supply chain a causa dei lead time coinvolti. Pertanto, il ritmo di cambiamento dell’iniziativa nella fase di produzione è rallentato, in modo da rendere possibili valutazioni affidabili sulle prestazioni delle decisioni automatizzate. L’iniziativa entra in una fase di miglioramento continuo. Pur essendo sempre auspicabili ulteriori miglioramenti, deve essere raggiunto un equilibrio tra i benefici dei possibili perfezionamenti alla logica e la corrispondente complessità di tali perfezionamenti, al fine di mantenere l’intera soluzione gestibile.

Il Supply Chain Coordinator, liberato dai suoi compiti banali di inserimento dati, può ora concentrarsi sui percorsi strategici proposti dalla gestione della supply chain. Di solito, i cambiamenti desiderabili nei processi della supply chain che potrebbero essere stati identificati durante la fase pilota vengono messi in pausa per evitare di interrompere le operazioni cambiando tutto in una volta. Tuttavia, ora che il ritmo di cambiamento della logica decisionale si è rallentato, diventa possibile rivedere i processi in modo incrementale, al fine di sbloccare miglioramenti delle prestazioni che richiedono più che semplici decisioni di routine migliori.

Il Supply Chain Scientist continua a perfezionare la logica ponendo un’enfasi sempre crescente sui KPI e sulla qualità dei dati. È inoltre responsabile della revisione della logica, poiché nel tempo emergono sottili difetti o limitazioni, tipicamente relativi a situazioni poco frequenti. Successivamente, man mano che i processi cambiano, anche la logica decisionale viene rivista, al fine di rimanere pienamente allineata con i flussi di lavoro e la strategia. Inoltre, anche quando i processi interni non cambiano, il panorama IT e aziendale generale continua comunque a mutare: il Supply Chain Scientist deve assicurarsi che la logica decisionale rimanga aggiornata in questo costante stato di flusso.

I deliverable

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

Script come deliverable

Quantitative Supply Chain enfatizza pipeline dati completamente automatizzate. Ciò non implica che la configurazione software debba funzionare in modo autonomo. Un elevato grado di supervisione ravvicinata è naturalmente auspicabile ogni qualvolta si consideri una supply chain su larga scala. Tuttavia, ci si aspetta che la pipeline dati sia completamente automatizzata nel senso che nessun passaggio nella pipeline dipende effettivamente da un’operazione manuale. Infatti, come delineato nel manifesto, ogni qualvolta operazioni manuali siano coinvolte nel supportare l’elaborazione dei dati della supply chain, la soluzione semplicemente non scala in pratica.

Come diretta conseguenza di questa intuizione, i deliverable di un’iniziativa Quantitative Supply Chain sono invariabilmente interi pezzi di software. Ciò non implica che al team responsabile sia richiesto di reimplementare tutto: una soluzione software dedicata a Quantitative Supply Chain offre la possibilità di concentrarsi esclusivamente sugli aspetti rilevanti delle sfide della supply chain. Tutte le tecnicalità a basso livello, come sfruttare le risorse di calcolo distribuite autoallocabili all’interno di una piattaforma di cloud computing, sono destinate ad essere astratte. Il team non necessita di approfondire tali questioni, poiché questi aspetti dovrebbero essere gestiti adeguatamente dagli strumenti stessi.

I deliverable si concretizzano in script tipicamente scritti in un linguaggio di programmazione in grado di soddisfare i requisiti della supply chain, garantendo al contempo un elevato livello di produttività. Il termine “script” è utilizzato qui anziché “codice sorgente”, ma i due termini sono strettamente correlati: uno “script” enfatizza l’idea di un alto livello di astrazione e un focus sul compito stesso, mentre un “codice sorgente” enfatizza una prospettiva a livello inferiore, intesa a essere una rappresentazione accurata dell’hardware di calcolo stesso. Per 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 rivolte ai clienti finali ha portato molti software vendors della supply chain a provare a emulare questo approccio con una soluzione WYSIWYG per la pianificazione e l’ottimizzazione della supply chain. Tuttavia, la lezione del quasi sistematico fallimento di questo tipo di interfacce è che le supply chain sono complesse e non possono eludere la necessità di strumenti programmabili. Dalla nostra esperienza, aspettarsi che un tool drag-and-drop sia in grado di riflettere correttamente le non linearità complesse coinvolte, per esempio, negli MOQ (minimum ordering quantities) sovrapposti, è al massimo illusorio. È necessaria un’espressività programmatica perché, altrimenti, la sfida della supply chain non potrebbe 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 output tangibile dell’iniziativa Quantitative Supply Chain. Le persone interagiranno con dashboard che contengono KPI consolidati e tabelle che raccolgono decisioni suggerite. Tuttavia, questi 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 il vero deliverable, con la sua espressione numerica, che è tipicamente ciò che l’utente finale della soluzione può vedere.

Dashboard sulla 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 Quantitative Supply Chain siano sia numericamente che semanticamente corretti. Lo scopo dei dashboard per il monitoraggio della salute dei dati, o semplicemente dashboard sulla salute dei dati, è garantire un alto grado di fiducia nella correttezza dei dati, che è naturalmente un requisito essenziale per l’accuratezza di tutti i risultati numerici restituiti dalla soluzione. Questi 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 stock, mentre la console web dell’ERP segnala solo 13 unità in stock. È evidente che abbiamo numeri divergenti dove dovrebbero essere uguali. I dashboard sulla salute dei dati affrontano questi problemi relativamente evidenti controllando semplicemente che gli aggregati dei dati rimangano entro i range numerici attesi.

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 effettivamente nell’identificare e correggere tutti gli errori semantici. Ad esempio, il campo stockinv nell’ERP potrebbe essere documentato come lo stock on hand. Pertanto, il team della supply chain presume che questa quantità non possa mai essere negativa, perché, ovviamente, se quelle unità sono a portata fisica sullo scaffale, devono costituire una quantità positiva. Tuttavia, la documentazione dell’ERP potrebbe anche risultare leggermente fuorviante, e questa quantità sarebbe stata più appropriatamente denominata stock available perché, ogni volta che si verifica uno stock-out e il cliente effettua 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 per se – è la comprensione del numero che risulta approssimativa. In pratica, le approssimazioni semantiche possono generare molti comportamenti incoerenti, che a loro volta generano costi di attrito continui all’interno della supply chain.

I dashboard sulla salute dei dati consolidano numeri che permettono all’azienda di decidere sul momento se i dati possano essere ritenuti sufficientemente affidabili. Infatti, poiché la soluzione verrà utilizzata quotidianamente per scopi produttivi, è imperativo che un problema significativo nei dati venga identificato tramite un’ispezione quasi istantanea. In caso contrario, è probabile che la supply chain operi per giorni, se non settimane, basandosi su dati difettosi. In questo senso, il dashboard sulla salute dei dati è simile a un semaforo: verde, si passa; rosso, ci si ferma.

Inoltre, quando si considera una supply chain di dimensioni considerevoli, solitamente esiste una quantità irriducibile di dati corrotti o comunque errati. Questi dati sorgono a causa di immissioni manuali difettose o per casi limite nei sistemi aziendali stessi. In pratica, per una qualsiasi supply chain di grandi dimensioni, è irragionevole aspettarsi che i dati della supply chain siano accurati al 100%. Invece, dobbiamo assicurarci che i dati siano abbastanza accurati da mantenere i costi di attrito generati da tali errori quasi trascurabili.

Pertanto, ci si aspetta anche che i dashboard sulla salute dei dati raccolgano statistiche sugli errori identificati nei dati. Queste statistiche sono fondamentali per stabilire che i dati possano essere considerati affidabili. A tal fine, un Supply Chain Scientist è frequentemente chiamato a stabilire soglie di allarme ben scelte, tipicamente associate a un arresto totale della soluzione. Occorre prestare attenzione nel definire tali soglie, perché se sono troppo basse, la soluzione diventa inutilizzabile, essendo interrotta troppo frequentemente per “problemi di dati identificati”; tuttavia, se sono troppo alte, i costi di attrito generati dagli errori nei dati possono diventare significativi e compromettere i benefici apportati dall’iniziativa stessa.

Oltre alla segnalazione a semaforo rosso-verde, i dashboard sulla salute dei dati sono anche destinati a offrire approfondimenti prioritizzati sugli sforzi di miglioramento dei dati. Infatti, molti punti 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 effettuati ulteriori ordini di acquisto per esso.

La Quantitative Supply Chain sottolinea che la risoluzione a grana fine degli errori nei dati, che può richiedere un considerevole lavoro manuale, deve essere messa in ordine di priorità in base all’impatto finanziario stimato dell’errore stesso rispetto al costo del lavoro associato alla correzione. Infatti, a seconda della situazione, il costo associato alla correzione di un singolo dato errato varia enormemente e deve essere preso in considerazione 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 delle decisioni priorizzate

Come abbiamo visto, solo le decisioni della supply chain possono essere valutate veramente da un punto di vista quantitativo. Non sorprende quindi che l’unico deliverable operativo chiave di un’iniziativa Quantitative Supply Chain siano i dashboard che consolidano le decisioni ottenute come risultato numerico finale dell’intero flusso di 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 qualsiasi altra restrizione d’ordine – allora le quantità suggerite potrebbero essere zero per la maggior parte del tempo, finché non vengono raggiunte 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 una delle opzioni, che potrebbe essere o meno rilevante. In pratica, ci si aspetta che il software che alimenta l’iniziativa Quantitative Supply Chain sia altamente flessibile, ossia programmabilmente flessibile, offrendo molti modi 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 nel principale ERP utilizzato per gestire gli asset aziendali.

Seppure il formato delle decisioni dipenda fortemente dal compito della supply chain affrontato, la maggior parte delle attività richiede la priorizzazione di tali decisioni. Ad esempio, l’atto di calcolare le quantità suggerite per un ordine di acquisto può essere scomposto in una lista priorizzata delle unità da acquisire. L’unità più redditizia viene classificata per prima. Poiché lo stock presenta rendimenti decrescenti, la seconda unità acquistata per lo stesso prodotto soddisfa una quota decrescente della domanda di mercato. Pertanto, la seconda unità per questo stesso prodotto potrebbe non essere la seconda voce nella lista complessiva. Invece, la seconda unità più redditizia può essere associata a un altro prodotto, e così via. La lista priorizzata delle unità da acquisire è concettualmente infinita: è sempre possibile acquistare un’ulteriore unità. Poiché la domanda di mercato è finita, tutte le unità acquistate diventeranno stock invenduto dopo un certo punto. Trasformare questa lista di priorità nelle quantità finali per l’acquisto richiede solo l’introduzione di un criterio di arresto e la somma delle quantità per prodotto. In pratica, le restrizioni non lineari nell’ordine complicano ulteriormente questo compito, ma, per semplicità, metteremo da parte tali restrizioni in questa fase della discussione.

Prioritizzare le 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. Di conseguenza, ci si può aspettare che molti, se non la maggior parte, dei dashboard che compilano le decisioni suggerite per la supply chain siano, in pratica, liste priorizzate di decisioni. Questi dashboard contengono liste con decisioni altamente redditizie elencate in cima e decisioni molto poco redditizie elencate in fondo. In alternativa, i professionisti della supply chain possono decidere di troncare le liste quando le decisioni non sono redditizie. Tuttavia, spesso si possono ricavare spunti esaminando decisioni che si trovano appena sotto la soglia di redditività – anche se è ovvio che l’azienda non si aspetta di agire su quelle voci non redditizie.

Per offrire questo tipo di dashboard orientati alle decisioni, la soluzione software che supporta la Quantitative Supply Chain deve esplorare numericamente vasti insiemi di decisioni possibili. 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 località. Non sorprende che questa operazione possa richiedere risorse di calcolo sostanziali. Fortunatamente, al giorno d’oggi, l’hardware di calcolo è in grado di gestire anche le supply chain globali più grandi. Supponendo che la soluzione software sottostante sia opportunamente architettata per la Quantitative Supply Chain, la scalabilità dell’elaborazione dei dati dovrebbe rappresentare un aspetto trascurabile per i team della supply chain.

Whiteboxing dei risultati numerici

I sistemi derisoriamente definiti black boxes nella supply chain, e in altri campi, sono sistemi che generano output che non possono essere spiegati dai professionisti che vi interagiscono. La Quantitative Supply Chain, con il suo specifico focus su una pipeline dati automatizzata, affronta anche il rischio di fornire ciò che i team della supply chain classificherebbero come “black boxes”. Infatti, le implicazioni finanziarie delle decisioni della supply chain sono molto importanti per un’azienda e, sebbene un sistema più moderno possa migliorare la situazione, esso può potenzialmente creare anche disastri. Pur essendo l’automazione altamente desiderabile, ciò non significa che al team della supply chain non sia richiesto di avere una comprensione approfondita di ciò che viene fornito dalla pipeline dati che supporta l’iniziativa 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 design. La trasparenza è il risultato finale di un impegno specifico, che fa parte dell’iniziativa stessa. Anche una semplice regressione lineare può generare risultati sconcertanti in pratica. Ad eccezione di pochi individui eccezionali, la maggior parte delle persone non ha una comprensione intuitiva di quale dovrebbe essere l’output “atteso” del modello lineare ogni volta che sono coinvolte 4 o più dimensioni. Tuttavia, i problemi della supply chain spesso coinvolgono dozzine, se non centinaia, di variabili. Pertanto, anche i modelli statistici più semplicistici sono de facto black boxes per i professionisti della supply chain. Naturalmente, quando vengono utilizzati algoritmi di machine learning, come raccomandato dalla Quantitative Supply Chain, essi lasciano i professionisti ancora più all’oscuro.

Sebbene l’effetto black box sia 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, capaci di affrontare la complessità grezza delle supply chain moderne. Semplificare e banalizzare il processo non è la risposta. La soluzione è il whiteboxing.

Anche le raccomandazioni per la supply chain più complesse possono essere rese in larga misura trasparenti per i professionisti della supply chain, semplicemente scomponendo i calcoli interni con indicatori finanziari ben scelti, che rappresentano i driver economici a supporto della raccomandazione stessa. Ad esempio, invece di mostrare semplicemente una tabella nuda con due colonne – prodotto e quantità – come ordine di acquisto suggerito, la tabella dovrebbe includere alcune colonne aggiuntive che facilitino il processo decisionale. Queste colonne extra possono includere lo stock attuale, la domanda totale dell’ultimo mese, il lead time atteso, il costo finanziario previsto per uno stock out (se non viene effettuato alcun ordine), il costo finanziario previsto per un overstock (rischio associato all’ordine suggerito), ecc. Le colonne sono studiate per fornire al team della supply chain rapide verifiche di coerenza sulle quantità suggerite. Attraverso esse, il team può rapidamente stabilire fiducia nell’output numerico e identificare alcune delle debolezze di una soluzione che necessita di ulteriori miglioramenti.

Estendere i dashboard per scopi di whiteboxing è in parte un’arte. Generare milioni di numeri è facile, anche avendo a disposizione non più risorse di calcolo di quelle disponibili su uno smartphone. Tuttavia, generare 10 numeri degni di essere esaminati quotidianamente è molto difficile. Pertanto, la sfida principale è identificare una dozzina o meno di KPI sufficienti per fare luce sulle decisioni consigliate per la supply chain. Buoni KPI tipicamente richiedono molto lavoro; non dovrebbero essere definizioni ingenuamente semplici, che solitamente risultano fuorvianti nella supply chain. Ad esempio, anche una colonna semplice come il “unit purchase price” può essere altamente fuorviante se il fornitore offre sconti per l’acquisto in volume, rendendo il prezzo di acquisto dipendente dalla quantità acquistata.

Dashboard strategici

Mentre l’attenzione sulle decisioni su piccola scala è necessaria - essendo uno dei pochi approcci che si presta a valutazioni quantitative delle performance - supply chain potrebbe dover essere rivista in maniera più ampia e dirompente, per portare le performance al livello successivo. Ad esempio, l’acquisto di ulteriori unità di scorte ben selezionate aumenta marginalmente il livello di servizio. Tuttavia, a un certo punto, il magazzino è pieno e non è possibile acquistare ulteriori unità. In questa situazione, si dovrebbe considerare un magazzino più grande. Per valutare l’impatto della rimozione di questa limitazione, possiamo eliminare il vincolo di capacità del magazzino dai calcoli e valutare il potenziale finanziario complessivo dell’operare con un magazzino arbitrariamente grande. 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 un aumento della capacità di stoccaggio.

Tipicamente, le supply chain operano basandosi su numerosi vincoli che non possono essere rivisti quotidianamente. Tali vincoli possono includere il capitale circolante, la capacità di magazzino, i ritardi nei trasporti, la produttività della produzione, ecc. Ogni vincolo è associato a un costo opportunità implicito per la supply chain, che di solito si traduce in più scorte, più ritardi o maggiori stock-out. Il costo opportunità può essere valutato attraverso i guadagni in performance che si otterrebbero eliminando o allentando il vincolo stesso. Sebbene alcune di queste simulazioni possano rivelarsi difficili da implementare, frequentemente non sono più complicate dell’ottimizzazione delle decisioni di routine, cioè stabilire le quantità degli ordini di acquisto.

La Quantitative Supply Chain sottolinea che i costi opportunità associati a tali vincoli dovrebbero far parte della pipeline di dati di produzione e, tipicamente, dovrebbero essere materializzati attraverso cruscotti dedicati, specificamente pensati per aiutare la gestione della supply chain a decidere quando è il momento di apportare cambiamenti più significativi alla loro supply chain. Questi tipi di cruscotti sono chiamati cruscotti strategici. Questo approccio differisce 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 cruscotti strategici vengono aggiornati quotidianamente, o più frequentemente se necessario, proprio come il resto della pipeline di dati. Non è necessario fare uno sforzo dell’ultimo minuto, perché sono aggiornati e pronti a capitalizzare gli spunti ottenuti da un’iniziativa di lunga durata.

I cruscotti strategici supportano il processo decisionale della gestione della supply chain. Poiché fanno parte della pipeline di dati, ogni volta che il mercato inizia a evolvere a un ritmo più rapido del solito, i KPI rimangono aggiornati sulla situazione attuale dell’azienda. Questo approccio evita i tradizionali inciampi associati alle indagini ad hoc che inesorabilmente ritardano ulteriormente problemi già in ritardo. Questo approccio riduce anche in larga misura il problema alternativo, ovvero decisioni strategiche affrettate che si rivelano non redditizie - una condizione deplorevole che avrebbe potuto essere anticipata fin dall’inizio.

Cruscotti ispettivi

Le supply chain sono sia complesse che erratiche. Queste proprietà rendono il debug della pipeline di dati un compito estremamente impegnativo. Eppure, questa pipeline di dati è il midollo della Quantitative Supply Chain. Errori nel processamento dei dati, o bug, possono verificarsi in qualsiasi punto della pipeline. Ancora peggio, il tipo di problema più frequente non è la formula incorretta, ma l’ambiguità semantica. Ad esempio, all’inizio della pipeline, la variabile stockinv potrebbe riferirsi alle scorte disponibili (dove valori negativi sono possibili) mentre successivamente la stessa variabile viene usata con l’interpretazione di scorte in magazzino (dove ci si aspetta valori positivi). L’interpretazione ambigua della variabile stockinv può generare una vasta gamma di comportamenti errati, che vanno dai crash del sistema - che sono ovvi, e quindi solo moderatamente dannosi - a una corruzione silenziosa e pervasiva delle decisioni della supply chain.

Poiché le supply chain sono quasi sempre costituite da un mix unico di soluzioni software implementate nel corso degli anni, non c’è speranza di accedere a una soluzione software “proven”, priva di bug. In effetti, la maggior parte dei problemi nasce ai confini del sistema, quando si riconciliano dati provenienti da sistemi differenti, o anche semplicemente riconciliare dati provenienti da moduli differenti all’interno dello stesso sistema. Pertanto, non importa quanto la soluzione software possa essere comprovata, 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 un’ispezione minuziosa dei dataset della supply chain. Tuttavia, tali cruscotti non sono semplici drill-down per ispezionare le tabelle dei dati in input. Un drill-down di questo tipo, o approcci simili slice-and-dice sui dati, perderebbero di vista il punto. Le supply chain riguardano 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 mancare di 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 associate al loro prodotto. Quando i risultati numerici sembrano strani, quei cruscotti ispettivi sono l’opzione ideale per il Supply Chain Scientist per effettuare una rapida indagine campione sui dati.

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 un’unica vista. Quando le merci scorrono attraverso molti luoghi, come accade ad esempio nelle supply chain aerospaziali, il cruscotto ispettivo tenta solitamente di ricostruire i percorsi delle merci, che potrebbero aver transitato non solo attraverso molteplici località fisiche, ma anche attraverso differenti sistemi. Raccogliendo tutti questi dati in un unico posto, diventa possibile per il Supply Chain Scientist valutare se i dati abbiano senso: è possibile identificare da dove provengono le merci spedite? I movimenti delle scorte sono allineati con le politiche ufficiali della supply chain, ecc.? Il cruscotto ispettivo è uno strumento di “debug” in quanto è progettato per riunire i dati strettamente correlati, non dal punto di vista IT, ma dal punto di vista della supply chain.

I cruscotti ispettivi sono la controparte a basso livello del cruscotto della salute dei dati. Essi si concentrano su dati completamente disaggregati, mentre i cruscotti sulla salute dei dati assumono solitamente un approccio più globale sui dati. Inoltre, i cruscotti ispettivi sono tipicamente parte integrante dell’iniziativa di whiteboxing. Di fronte a ciò che sembra essere una raccomandazione enigmatica, i professionisti della supply chain devono esaminare da vicino un SKU o un prodotto, per capire se la decisione raccomandata sia ragionevole o meno. Il cruscotto ispettivo è tipicamente adattato per questo preciso scopo, includendo molti risultati intermedi che contribuiscono al calcolo della raccomandazione finale.

Valutare il successo

Potrebbe sembrare un paradosso, ma mentre la Quantitative Supply Chain pone una notevole enfasi sui metodi numerici e sulle misurazioni, la nostra esperienza ci dice che le metriche tendono a dirci troppo poco, e spesso troppo tardi, sul fatto che un’iniziativa sia sulla buona strada. Quasi tutte le metriche possono essere manipolate e ciò di solito avviene a spese della sostenibilità dell’approccio scelto. Pertanto, la Quantitative Supply Chain cerca miglioramenti evidenti: se i miglioramenti sono così sottili da richiedere misurazioni avanzate per essere rilevati, allora probabilmente l’iniziativa non è valsa lo sforzo e dovrebbe essere considerata un fallimento. Al contrario, se i miglioramenti sono evidenti e consistenti su molte metriche, e l’intera supply chain appare più agile e reattiva che mai, allora l’iniziativa ha molto probabilmente avuto successo.

Le metriche possono essere manipolate

C’è una ragione per cui gli ingegneri vengono raramente valutati in base alle metriche: sono semplicemente troppo bravi a manipolare le metriche, cioè a sfruttarle per i propri interessi piuttosto che per servire gli interessi dell’azienda. Le supply chain sono complesse e quasi tutte le metriche semplici possono essere sfruttate, in modi che potrebbero essere fortemente dannosi per l’azienda. Potrebbe sembrare che questo problema sia solo una questione di chiudere le falle presenti nelle metriche. Tuttavia, la nostra esperienza indica che c’è sempre un’altra falla da scoprire.

Una storia di reverse engineering delle metriche

Prendiamo, ad esempio, un e-commerce fittizio. La direzione decide che i livelli di servizio devono essere migliorati e quindi il livello di servizio diventa la metrica di punta. Il team della supply chain inizia a lavorare in base a questa metrica, e propone una soluzione che consiste nell’aumentare enormemente i livelli di scorte, incorrendo così in costi elevatissimi per l’azienda.

Di conseguenza, la direzione cambia le regole, viene definita la quantità massima di scorte, e il team deve operare entro questo limite. Il team rivede le proprie cifre, e si rende conto che il modo più semplice per abbassare i livelli di scorte è segnalare grandi quantità di scorte come “dead”, il che innesca promozioni aggressive. I livelli di scorte sono effettivamente ridotti, ma anche i margini lordi vengono significativamente diminuiti nel processo.

Ancora una volta, il problema non passa inosservato, e le regole vengono cambiate ancora. Viene introdotto un nuovo limite sulla quantità di scorte che possono finire per essere segnalate come “dead”. L’implementazione di questa nuova regola richiede molto impegno perché la supply chain si trova improvvisamente a dover gestire scorte “old” che dovranno essere scontate pesantemente. Per far fronte a questa nuova regola, il team aumenta la quota di trasporto aereo rispetto a quello marittimo. I tempi di consegna vengono ridotti, le scorte diminuiscono, ma i costi operativi aumentano rapidamente.

Per far fronte ai costi operativi che stanno sfuggendo al controllo, la direzione cambia le regole ancora una volta, imponendo un limite superiore alla percentuale di merci che possono essere trasportate per via aerea. Ancora una volta, la nuova regola causa notevoli disagi, poiché innesca una serie di stock-out che sarebbero potuti essere evitati utilizzando il trasporto aereo. Di fronte all’obbligo di operare sotto vincoli sempre più stringenti, il team inizia a rinunciare a sfruttare le riduzioni di prezzo offerte dai fornitori. L’acquisto di quantità minori è anche un modo per ridurre i tempi di consegna. Tuttavia, ancora una volta, i margini lordi vengono ridotti nel processo.

Rimettere in carreggiata i prezzi di acquisto si rivela essere un obiettivo molto più sfuggente per la direzione. Nessuna regola semplice può far fronte a questa sfida, e invece vengono introdotti una miriade di obiettivi di prezzo per ogni sottocategoria di prodotto. Molti obiettivi si rivelano irrealistici e conducono a errori. In definitiva, il quadro della supply chain diventa sempre meno chiaro. Sotto pressione da molteplici fronti, il team della supply chain inizia a modificare una caratteristica oscura del processo di demand planning: la lista di sostituzione dei prodotti.

Infatti, la direzione si rese conto fin dall’inizio del processo che alcuni stock-out non erano affatto così impattanti come altri, perché alcuni dei prodotti mancanti avevano molteplici sostituti quasi perfetti. Di conseguenza, tutti concordarono sul fatto che gli stock-out su quei prodotti potessero essere in larga misura scontati nel calcolo del livello di servizio complessivo. Tuttavia, il team della supply chain, che ora opera sotto una pressione enorme, sta iniziando ad espandere lo scopo di questa lista di uno o due gradini oltre il suo intento originale: prodotti che non sono così simili vengono elencati come sostituti quasi perfetti. Le metriche del livello di servizio migliorano, ma il business no.

La trappola del successo

Le metriche possono essere manipolate e, se ai team vengono forniti incentivi tossici, è molto probabile che le metriche vengano utilizzate in modo fuorviante. Tuttavia, la situazione non è affatto così grave come potrebbe sembrare. Infatti, la nostra esperienza indica che, ad eccezione di culture aziendali veramente disfunzionali, in genere i dipendenti non tendono a sabotare il loro lavoro. Al contrario, abbiamo osservato che la maggior parte dei dipendenti è orgogliosa di fare la cosa giusta, anche se ciò significa che le politiche aziendali devono essere un po’ ampliate.

Pertanto, invece di togliere libertà al team incaricato di implementare la strategia di ottimizzazione della supply chain, è importante incoraggiare il team a elaborare un insieme di metriche che faccia luce sull’iniziativa complessiva della supply chain. Il ruolo della direzione non è quello di far rispettare regole basate su tali metriche, bensì di mettere in discussione il pensiero strategico che sta alla base di queste metriche. Spesso, l’obiettivo immediato non dovrebbe nemmeno essere migliorare i valori delle metriche, ma migliorare la definizione stessa delle metriche.

In realtà, non tutte le metriche hanno lo stesso valore per un’azienda. Di solito occorre un notevole impegno per creare metriche che offrano una prospettiva significativa sul business. Questo lavoro richiede non solo una buona comprensione della strategia aziendale, ma anche una conoscenza approfondita dei dati sottostanti, che comportano una miriade di artefatti e altre stranezze numeriche. Pertanto, le metriche dovrebbero soprattutto essere considerate come un lavoro in corso.

Abbiamo constatato che un forte indicatore di successo in qualsiasi progetto di supply chain è la qualità delle metriche che vengono stabilite durante l’iniziativa. Eppure, è un po’ un paradosso, perché non esiste una metrica ragionevole in grado di valutare effettivamente la rilevanza di quelle metriche. Ecco alcuni elementi che possono aiutare a valutare la qualità delle metriche:

• Esiste un consenso tra i diversi team di supply chain sul fatto che le metriche catturino l’essenza del business? Oppure che le prospettive aziendali implicitamente promosse dalle metriche non siano né miope né disorientate?
• Le metriche presentano una vera profondità quando si tratta di riconciliare i numeri con i driver economici? La semplicità è auspicabile, ma non a scapito di una visione distorta del quadro generale.
• Gli artefatti dei dati sono adeguatamente gestiti? Di solito, ci sono decine di sottili “insidie” che devono essere affrontate durante l’elaborazione dei dati estratti dai sistemi aziendali. La nostra esperienza ci insegna a essere sospettosi quando i dati grezzi sembrano essere sufficienti, poiché questo di solito significa che i problemi non sono nemmeno stati identificati come tali.
• Le decisioni generate dalle metriche scelte hanno senso? Se una decisione, altrimenti in linea con le metriche, non sembra sensata, allora probabilmente non lo è; e il problema risiede frequentemente nella metrica stessa.

In molti modi, creare metriche efficaci è come orientare la gravità verso l’abisso del successo: a meno che qualcosa non intervenga, il corso naturale delle azioni è quello di rotolare lungo la pendenza verso il fondo, che coincide esattamente con il luogo in cui risiede il successo. Conoscere l’esatta profondità del fondo non è nemmeno strettamente necessario, purché ogni passo verso il fondo migliori le cose per l’azienda.

Decisioni sensate portano a una migliore performance

In supply chain, anche le metriche migliori presentano un grosso svantaggio: i numeri di solito arrivano in ritardo. I tempi di consegna potrebbero essere lunghi e le decisioni prese oggi potrebbero non avere un impatto visibile per settimane, se non mesi. Inoltre, la Quantitative Supply Chain, che pone un’enfasi significativa sui miglioramenti iterativi e incrementali, complica ulteriormente la questione. Eppure, utilizzare metodi non incrementali sarebbe ancora peggiore, sebbene per altre ragioni. Pertanto, le metriche non possono essere gli unici segnali usati per valutare se l’iniziativa è sulla buona strada.

Generare decisioni sensate è un segnale semplice, ma sottovalutato, di prestazioni superiori. Infatti, a meno che la tua azienda non stia già andando egregiamente bene con la sua supply chain, è molto probabile che i sistemi continuino a produrre decisioni “insane” che vengono rilevate e corrette manualmente dai team di supply chain. Lo scopo di tutti gli “allarmi”, o di meccanismi reattivi simili, è proprio quello di mitigare i problemi in corso attraverso continui sforzi correttivi manuali.

Portare l’iniziativa Quantitative Supply Chain a un punto in cui tutte le decisioni - generate in modo completamente robotizzato - siano considerate sensate o sicure è un traguardo ben più grande di quanto la maggior parte dei professionisti si renda conto. L’enfasi sulle decisioni “robotizzate” è importante: per giocare secondo le regole, non dovrebbe essere necessario alcun intervento umano. Quindi, per “sensate” intendiamo decisioni che continuano a sembrare corrette per i professionisti anche dopo aver speso alcune ore ad indagare il caso; cosa che naturalmente non può essere fatta regolarmente, a causa dell’enorme quantità di decisioni simili da prendere ogni giorno.

La nostra esperienza indica che ogni volta che le decisioni automatizzate sono considerate affidabili, le prestazioni si materializzano in seguito quando tali decisioni vengono effettivamente messe alla prova nell’essere utilizzate “in production”. Infatti, il test della “sanity” è un test molto rigoroso per la logica decisionale. A meno che la tua azienda non stia già sfruttando qualcosa di molto simile a Quantitative Supply Chain, è molto probabile che i sistemi esistenti in uso non siano minimamente in grado di superare questo test. Di conseguenza, errori non rilevati vengono commessi continuamente, e l’azienda finisce per pagare molto per questo flusso continuo di problemi.

Quindi, da un punto di vista operativo, non appena le decisioni di supply chain diventano automatizzate, i team di supply chain sono liberati dal dover alimentare il proprio sistema con un flusso infinito di inserimenti manuali. Questi guadagni in produttività possono essere reinvestiti dove conta davvero: per affinare i dettagli della strategia di supply chain stessa, o per monitorare più da vicino i fornitori al fine di affrontare i problemi di supply chain che originano dalla loro parte. L’incremento delle prestazioni, ottenuto attraverso una pura ottimizzazione quantitativa della supply chain, è intensificato dai guadagni ottenuti dai team di supply chain che finalmente possono trovare il tempo per migliorare i processi e i flussi di lavoro.