Antipatterns nella supply chain

Le iniziative della supply chain spesso falliscono. La Quantitative Supply Chain è la nostra risposta per ridurre drasticamente i tassi di fallimento. Tuttavia, poiché la Quantitative Supply Chain si concentra sulle pratiche che sappiamo funzionare, pone poca enfasi su quelle che sappiamo non funzionare. Peggio ancora, risulta che la maggior parte di queste pratiche indesiderate siano le vere cause alla radice degli elevati tassi di fallimento associati ai metodi tradizionali della supply chain.

Di seguito, esaminiamo le pratiche - o pattern - che fanno fallire la maggior parte delle iniziative della supply chain. Questi approfondimenti sono stati conquistati a caro prezzo, poiché per ciascuno di essi non bastava un solo fallimento, ma ne sono stati necessari diversi per comprenderne la causa radice. Ci riferiamo a queste pratiche dannose come supply chain antipatterns. Un antipattern è una “soluzione” che ritorce contro chi l’adotta: si tratta di un approccio comune, che può sembrare una buona idea, eppure, invariabilmente, non riesce a fornire il miglioramento previsto.

Cattiva leadership

Da Lokad, certamente non vogliamo antagonizzare i principali supply chain decision makers, essendo loro i nostri potenziali clienti e clienti attuali. Tuttavia, allo stesso tempo, riteniamo sia nostro dovere rifiutare di concludere un accordo quando la soluzione è destinata a fallire per design. Spesso il problema si riduce a come viene gestita l’iniziativa stessa. Detto ciò, riconosciamo che il supply chain management non è l’unico colpevole. Alcuni fornitori a volte promuovono messaggi sbagliati ai loro clienti e, senza scrupoli, se la cavano benissimo. Le pratiche legacy e le politiche interne possono anche avvelenare la vita quotidiana del supply chain management, che potrebbe essere usato come capro espiatorio quando le cose non vanno come previsto. In questa sezione, elenchiamo gli errori comuni che potrebbero essere evitati attraverso una leadership della supply chain riveduta.

La RFQ dall’inferno

Ci possono essere molti ambiti in cui le RFQ (richieste di offerta) hanno senso. Purtroppo, il software non è uno di questi. Scrivere la specifica di un software è infinitamente più difficile che scrivere il software stesso. L’impresa è scoraggiante. Una volta avviato un processo di RFQ, le aziende riescono a peggiorare la situazione introducendo consulenti, complicando ulteriormente quella che già era una specifica eccessivamente complessa. La RFQ soffoca la maggior parte del pensiero orientato alla risoluzione dei problemi, poiché il processo di RFQ presuppone che il cliente conosca già i dettagli minuti della soluzione desiderata, mentre il “problema” è, per definizione, in gran parte irrisolto al momento in cui la RFQ viene redatta. Inoltre, nella pratica, le RFQ promuovono un processo di selezione del fornitore in maniera conflittuale: i fornitori validi se ne vanno, mentre quelli non validi rimangono. Infine, il settore del software è in continua evoluzione e, quando la vostra azienda avrà terminato il processo di RFQ, il vostro concorrente avrà già lanciato la propria soluzione.

Il POC fragile

Realizzare un POC (proof of concept) è utile se ciò che intendete acquistare è un servizio semplice e quasi standardizzato: come un servizio di stampa per biglietti da visita. Un’iniziativa nella supply chain è complicata per design. La supply chain richiede il coordinamento di più entità. Esistono diversi livelli di dati che dovrebbero essere sfruttati. Ci sono decine di flussi di lavoro da considerare. I POC o i progetti pilota su piccola scala fanno più danni che benefici perché, per loro stessa concezione, trascurano una virtù fondamentale di un’iniziativa di successo nella supply chain: la capacità di operare su larga scala. La maggior parte delle persone è abituata al principio delle economie di scala, tuttavia, quando si tratta di ottimizzazione della supply chain, ci si imbatte principalmente in diseconomie di scala, per cui prendere buone decisioni diventa sempre più difficile man mano che la complessità del problema cresce. Ottenere successo per un piccolo centro di distribuzione non garantisce affatto che la soluzione funzioni altrettanto bene quando si gestiscono decine di centri di distribuzione differenti.

Ignorare l’incertezza

Il futuro è incerto, e l’incertezza non si può semplicemente ignorare. Allo stesso modo, l’ottimizzazione numerica della supply chain è un problema difficile che non può essere semplicemente messo da parte. L’ottimizzazione della supply chain richiede previsioni probabilistiche, le quali sono la diretta conseguenza di dover gestire futuri incerti. L’ottimizzazione della supply chain affronta anche comportamenti controintuitivi generati dalle ottimizzazioni numeriche. Alcuni fornitori sfruttano il desiderio di mantenere le cose semplici e facili per vendere una pratica fantasiosa in cui tutti gli ostacoli vengono astratti. Sfortunatamente, quegli ostacoli non sono meri dettagli tecnici: essi definiscono ciò che ha effettivamente la possibilità di funzionare per la vostra supply chain. L’incertezza deve essere abbracciata da una profonda prospettiva numerica. Il management della supply chain deve riconoscere e accettare l’incertezza.

Fidarsi dello stagista

Se migliorare la supply chain è importante per la vostra azienda, allora l’iniziativa richiede il coinvolgimento diretto della direzione. Troppo spesso, le aziende apprezzano l’idea di miglioramento, ma poi affidano il compito a uno o due stagisti. Pur avendo incontrato stagisti molto intelligenti, non abbiamo mai visto un’iniziativa nella supply chain guidata da stagisti ottenere risultati concreti. Non abbiamo nulla contro gli stagisti, vabbè. Possono essere intelligenti, motivati, pensatori fuori dagli schemi; ma sono ben lontani da ciò di cui la vostra azienda ha bisogno per guidare un cambiamento nella propria supply chain. Il coinvolgimento della direzione della supply chain dovrebbe essere scontato, altrimenti i team non eseguiranno. Di solito, i team non hanno molto tempo libero, se mai ne hanno. Se la direzione non chiarisce, con il proprio coinvolgimento diretto, che l’iniziativa corrente è una priorità, allora essa non lo sarà per nessuno, tranne forse per il povero stagista incaricato del progetto.

Morte per pianificazione

Il management cerca rassicurazioni, e quando si tratta di rassicurazioni, nulla appare valido quanto una solida roadmap, con fasi, ruoli e deliverables ben definiti. Tuttavia, se la storia del software ci ha insegnato qualcosa, è che i piani predefiniti di solito non sopravvivono alla prima settimana dell’iniziativa. A volte, non sopravvivono nemmeno al primo giorno. Quando si tratta di ottimizzazione della supply chain, continueranno a verificarsi eventi inattesi, e questa è una prospettiva alquanto spaventosa. Rigidezzare l’iniziativa tramite una pianificazione precisa peggiora solo le cose: l’iniziativa diventa ancora più fragile di fronte a imprevisti. Invece, l’iniziativa dovrebbe essere resa il più resiliente possibile contro l’ignoto. La capacità di riprendersi dai problemi è più importante della capacità di eliminarli in anticipo. Pertanto, il management della supply chain dovrebbe concentrarsi sul rendere l’iniziativa agile piuttosto che ben pianificata.

Separare le previsioni dall’ottimizzazione

La prospettiva tradizionale sull’ottimizzazione della supply chain separa il processo di previsione dal processo decisionale. Pur potendo essere fattibile da un punto di vista puramente tecnico, utilizzando due insiemi distinti di algoritmi, uno per le previsioni e l’altro per l’ottimizzazione, da un punto di vista funzionale il team responsabile delle previsioni deve essere anche quello responsabile dell’ottimizzazione. In effetti, la logica decisionale, o in altre parole l’ottimizzazione, è numericamente molto sensibile alla logica delle previsioni. Isolare le due prospettive è una ricetta per amplificare eventuali difetti già presenti a livello delle previsioni, causando danni alle decisioni risultanti. La logica dell’ottimizzazione dovrebbe invece essere il più possibile cooperativa, dal punto di vista numerico, con i punti di forza e le debolezze della logica delle previsioni.

Frankensteinizzazione del software

È difficile raggiungere un consenso nelle grandi aziende. Di conseguenza, mentre la maggior parte degli stakeholder coinvolti nella supply chain potrebbe decidere di optare per un fornitore specifico, una minoranza potrebbe rimanere ferma nel sostenere la propria visione, oppure desiderare di optare per alcune caratteristiche di un prodotto differente. Poiché la personalizzazione del software rappresenta un’attività redditizia per i grandi fornitori di software, il fornitore è troppo spesso felice di accontentare, gonfiando così i costi e il valore percepito nel processo. Tuttavia, un buon software richiede anni per essere scritto, e, se realizzato correttamente, il risultato finale rappresenta un compromesso ben ponderato tra obiettivi in conflitto. Il risultato quasi sistematico della sovra-personalizzazione del software nelle grandi aziende è quello di privare il prodotto delle sue proprietà originarie, rendendolo non migliore, ma peggiore, aggiungendo sempre più strati e trasformandolo così in un mostro. Non c’è carenza di fornitori di software. Se la soluzione non si adatta alla vostra azienda, andate avanti e scegliete un altro fornitore. Se nessun fornitore si adatta alla vostra azienda, allora o il vostro business è davvero unico - il che è raro - oppure forse dovreste rivedere i vostri requisiti.

Iniziative basate sulle buzzword

Intorno al 2010, nel settore retail era una moda cercare di sfruttare le previsioni meteorologiche per affinare le previsioni della domanda. Nel 2012, era di moda includere i dati dei social media nella previsione della domanda. Nel 2014, il Big Data dominava, per essere poi sostituito dal machine learning nel 2016. Ogni anno che passa porta con sé una nuova ondata di buzzword. Sebbene non ci sia mai molto danno nel riesaminare un vecchio problema con una nuova prospettiva, anzi, perdere di vista le sfide fondamentali è quasi certo che metta in pericolo qualsiasi iniziativa già intrapresa. Se sembra troppo bello per essere vero, probabilmente lo è.

Cattiva esecuzione IT

L’IT viene troppo spesso incolpata per i fallimenti dei progetti. L’IT è difficile - molto più difficile di quanto la maggior parte delle persone fuori dall’IT immaginino. Eppure, a volte, capita che i team IT, per buone intenzioni, creino così tanta frizione attraverso i loro processi da rallentare l’iniziativa fino al punto che il resto dell’azienda si arrende. I team IT non devono solo accogliere il cambiamento in senso generale, ma anche accettare quel tipo specifico di cambiamento che non comprometta i positivi cambiamenti futuri. Più facile a dirsi che a farsi.

Attenzione ai meccanismi di difesa dell’IT

Poiché i team IT potrebbero essersi sentiti più di una volta il capro espiatorio in passato, quando alcuni progetti aziendali sono falliti, potrebbero aver sviluppato alcuni “meccanismi di difesa”. Uno dei meccanismi di difesa più comuni consiste nel richiedere specifiche scritte dettagliate per ogni nuova iniziativa. Eppure, specificare una soluzione software tende ad essere più difficile che implementarla effettivamente. Di conseguenza, ciò equivale a sostituire un problema complesso con uno ancora più complesso. Altri meccanismi di difesa consistono nell’adottare una linea dura di “requisiti” come: il software debba essere in sede, debba essere compatibile con XYZ, debba avere specifiche funzionalità di sicurezza, e così via. Un buon software richiede anni per essere scritto. Una volta redatta la lunga lista di requisiti, solitamente rimangono solo due tipi di fornitori di software: quelli che non sono compatibili con i vostri requisiti, e quelli che dichiarano falsamente di esserlo.

Sottovalutare l’impegno sui dati

Anche se può sembrare un paradosso, le iniziative della supply chain possono fallire anche perché l’IT è troppo coinvolta nella definizione della soluzione e si assume il compito di preparare i dati. Infatti, poiché l’IT è incredibilmente complessa e può includere individui molto talentuosi, può capitare che alcuni team IT arrivino a credere di conoscere il business meglio del resto dell’azienda. La conseguenza indesiderata principale di questo modo di pensare è una costante sottovalutazione delle sfide legate al trattamento dei dati aziendali. Analizzare i dati in modo significativo non consiste nello spostare megabyte di dati avanti e indietro. Piuttosto, si tratta di stabilire una comprensione sottile di come questi dati riflettano i processi e i flussi di lavoro dell’azienda. Si tratta anche di comprendere le sottili sfumature, i pregiudizi e i limiti dei dati, così come si manifestano nei sistemi aziendali in ogni momento. Affidare la preparazione dei dati ai team IT è una garanzia di ritardi inaspettati, dato che essi si rendono gradualmente conto di quanta profondità mancasse nella loro visione iniziale. Tenendo conto di tutto ciò, l’opzione ragionevole consiste nel delegare questo ruolo fin dall’inizio a qualcuno al di fuori del dipartimento IT.

La tentazione della piattaforma estensibile

Quando si parla di software aziendale, c’è una cosa che i fornitori hanno perfezionato: l’arte di essere una piattaforma “estensibile” che offre molti moduli, i quali rappresentano perlopiù opportunità di upsell. Tuttavia, le piattaforme non interagiscono bene tra loro e, ben presto, si manifestano sovrapposizioni funzionali, cioè due piattaforme che internamente competono per la stessa funzione all’interno della vostra azienda. Due piattaforme sovrapposte rappresentano un incubo IT per qualsiasi azienda e tipicamente portano a meccanismi di sincronizzazione che risultano difficili da impostare e ancora più difficili da mantenere. Pertanto, sebbene possa sembrare allettante optare per una soluzione onnicomprensiva, l’opzione ragionevole risiede quasi sempre nella scelta di applicazioni specifiche, che fanno una cosa sola e la fanno bene. Gestire dozzine di applicazioni specifiche è semplice, mentre gestire due grandi piattaforme - con altrettante ampie sovrapposizioni funzionali - è un incubo.

Estrazioni di dati inaffidabili

I dati sono come sangue per un’iniziativa Quantitative Supply Chain: smettere di pompare e muore. L’iniziativa deve essere alimentata costantemente con dati freschi. Troppo spesso, l’IT ritiene che effettuare un paio di estrazioni di dati una tantum sia sufficiente per far partire le cose. Dopotutto, è probabile che questa iniziativa venga comunque terminata presto - ricordate, la maggior parte delle supply chain initiatives fallisce - e quindi non ha molto senso investire troppo sforzo in questa fase iniziale di estrazione dei dati. Tuttavia, seguendo questa linea di pensiero, l’implementazione di un processo automatizzato per estrazioni di dati affidabili viene ritardata, e di conseguenza diventa una delle cause principali del fallimento dell’iniziativa stessa. In questo caso, l’IT deve essere proattivo e iniziare ad automatizzare le estrazioni dei dati fin dal primo giorno. Inoltre, il team IT ha anche un ruolo di coaching nel convincere il resto dell’azienda che questo sforzo extra è un fattore chiave per il successo dell’iniziativa, e che l’opzione usa e getta per l’estrazione dei dati non condurrà da nessuna parte.

Cattive ricette numeriche

Ottimizzare la supply chain è fondamentalmente un gioco di numeri. Naturalmente, la visione aziendale è importante, la leadership conta, la disciplina è fondamentale, ma la nostra esperienza indica che la maggior parte delle aziende riesce a gestire adeguatamente questi aspetti. Tuttavia, quando si tratta di numeri, sembra che l’intero settore della supply chain sia invaso da cattive ricette numeriche. Non tutti i professionisti della supply chain si rendono conto che tutte le formule e i modelli - qui definiti ricette numeriche - dipendono da assunzioni piuttosto rigide. Se anche una sola di queste assunzioni viene meno, la ricetta numerica crolla. In questa sezione, elenchiamo gli errori più comuni in questo ambito. Per brevità, assumiamo che il lettore sia già familiare con le ricette stesse.

Analisi ABC

L’approccio ABC all’inventario è stato ideato in un’epoca in cui i computer non erano un’opzione per guidare la supply chain. Il principale vantaggio della analisi ABC è che mantiene l’analisi così semplice da poter essere eseguita a mano. Tuttavia, considerando la capacità di elaborazione sconcertante dei computer moderni, utilizzare l’analisi ABC non ha più senso al giorno d’oggi. Non vi sono benefici nel raggruppare migliaia di SKU in 3 o 4 classi arbitrarie. Esiste un continuum completo tra il prodotto più venduto e la lunga coda. La logica che ottimizza la supply chain dovrebbe abbracciare questo continuum, invece di negare che esso esista in primo luogo. In pratica, osserviamo anche che gli effetti negativi dell’analisi ABC sono aggravati dai cambiamenti di mercato che portano a instabilità tra le classi, con prodotti che cambiano categoria nel tempo.

Scorta di sicurezza

Non esiste una cosa come la “scorta di sicurezza” nel tuo magazzino. La scorta di sicurezza è un concetto fittizio che divide le scorte disponibili in due categorie: la scorta operativa e la scorta di sicurezza. Da una prospettiva storica, la scorta di sicurezza è stata introdotta come un modo semplicistico per far fronte alla domanda variabile e ai tempi di consegna variabili lead time. La scorta di sicurezza è modellata sulla base delle distribuzioni normali - anche dette gaussiane. Tuttavia, anche un rapido esame di praticamente qualsiasi dataset della supply chain mostra chiaramente che né la domanda né i tempi di consegna sono distribuiti normalmente. Negli inizi degli anni ‘80, quando i computer erano ancora molto lenti, le distribuzioni normali potevano essere un valido compromesso tra complessità e accuratezza, ma oggi non ha senso aggrapparsi a qualcosa che era stato concepito come un “trucco” per far fronte alle limitazioni dei primi computer.

Correzioni manuali delle previsioni

Alcuni professionisti potrebbero vantarsi di essere in grado di “battere il sistema” e generare numeri di previsioni migliori rispetto a quelli che il sistema può produrre. Se questo è effettivamente il caso, il sistema dovrebbe essere considerato disfunzionale e corretto di conseguenza, sfruttando tipicamente l’esperienza e le intuizioni del professionista. Ottimizzare una supply chain di rilevante portata comporta la generazione di migliaia, se non milioni, di previsioni al giorno. Affidarsi all’inserimento manuale dei dati da parte dei team della supply chain per far fronte alle carenze del sistema non dovrebbe nemmeno essere considerato un’opzione valida per l’azienda. Considerando i progressi nella statistica negli ultimi 20 anni, non c’è alcun motivo per pensare che, forniti gli stessi input, un sistema automatico non possa superare un essere umano che, realisticamente parlando, non avrà più di pochi secondi da dedicare a ogni numero da produrre. Se l’essere umano avesse giorni a disposizione per ogni decisione che l’azienda deve prendere, la situazione sarebbe radicalmente diversa. Tuttavia, la stragrande maggioranza delle decisioni che la supply chain deve prendere quotidianamente non rientra in questa categoria.

Monitoraggio degli avvisi e delle cattive previsioni

Le previsioni classiche enfatizzano un unico futuro - cioè previsioni mirate alla media o alla mediana - come se quell’unico futuro dovesse realizzarsi con una probabilità significativa. Eppure, il futuro è incerto e le previsioni sono al massimo approssimative. In certe situazioni, le previsioni classiche sono semplicemente errate. Spesso, l’azienda sostiene costi imponenti a causa di tali ampi errori di previsione. Di conseguenza, vengono implementati degli avvisi per monitorare tali errori elevati. Tuttavia, il principale responsabile non sono le previsioni stesse, ma la prospettiva classica che enfatizza un unico futuro, mentre tutti i futuri sono possibili, sebbene non in egual misura. Dal punto di vista delle previsioni probabilistiche, gli errori sono per lo più noti in anticipo e vengono rappresentati come distribuzioni di probabilità, che si estendono finemente su un ampio intervallo di valori possibili. Le previsioni probabilistiche enfatizzano un approccio per cui l’azienda ridurrà proattivamente il rischio nelle attività della supply chain quando si affronta un grado maggiore di incertezza. Al contrario, impostare degli avvisi sulle previsioni classiche è il sintomo di un approccio intrinsecamente difettoso, poiché nega l’incertezza.

Riparare i dati storici con il nastro adesivo

Quando nei dati storici vengono individuati bias, come l’esaurimento delle scorte o le promozioni, è allettante in qualche modo “correggere” tali bias modificando i dati storici, in modo che questi riflettano meglio come sarebbe stata la storia senza il bias. Ci riferiamo a questo processo come il “duct taping” dei dati storici. L’idea fondamentale alla base del duct taping è che tutti i modelli di previsione sono concepiti come varianti della media mobile. Se tutto ciò che hai sono medie mobili, allora è necessario adeguare i dati storici per tener conto di queste medie. Tuttavia, il duct taping non è la soluzione. In realtà, la soluzione risiede nell’espandere l’orizzonte e cercare modelli di previsione migliori che non siano tanto disfunzionali quanto la media mobile. Modelli statistici migliori dovrebbero essere usati per gestire con successo dati storici “arricchiti”, in cui gli stessi bias sono trattati come input. Anche se tali modelli statistici potrebbero non essere stati disponibili decenni fa, oggi non è affatto così.

I tempi di consegna come cittadini di seconda classe

Per ragioni che non ci sono del tutto chiare, i tempi di consegna sono troppo spesso considerati come una semplice voce d’inserimento dati piuttosto che come qualcosa che necessita di una propria previsione. I tempi di consegna futuri sono incerti, e quasi sempre il modo migliore per stimarli con affidabilità è utilizzare quelli osservati in passato. Pertanto, i tempi di consegna richiedono una loro previsione. Inoltre, le implicazioni sulla supply chain di una corretta stima dei tempi di consegna sono molto maggiori di quanto molti professionisti si rendano conto: le quantità di scorte detenute servono proprio a coprire la domanda per un dato tempo di consegna. Modificando i tempi di consegna cambiano anche le quantità in magazzino. Di conseguenza, alle previsioni sui tempi di consegna non si può relegare il ruolo di cittadini di seconda classe nei tuoi sforzi per la supply chain. Quasi tutti i piani per la supply chain pongono l’accento sulla necessità di previsioni di domanda precise, ma la nostra esperienza indica che, in pratica, previsioni precise sui tempi di consegna sono altrettanto importanti.

Pseudo-scienza

La pseudo-scienza possiede tutte le caratteristiche della scienza: appare razionale, si presenta con numeri, si dice provata e persone altamente istruite ne difendono il caso. Tuttavia, la pseudo-scienza non supera la prova di ottenere risultati replicabili. Di solito, non è nemmeno necessario un setup sperimentale per rilevare la pseudo-scienza, e i materiali pseudo-scientifici iniziano a crollare sotto il rigore di una revisione paritaria imparziale. Le supply chain sono costose da gestire e complesse da comprendere. Questi due attributi da soli spiegano perché le metodologie per la supply chain siano particolarmente difficili da sfidare: non solo le sperimentazioni comportano un enorme rischio, ma è anche difficile valutare correttamente ciò che contribuisce realmente a un miglioramento percepito.

Casi aziendali fantasiosi

Le soluzioni per la supply chain non sono certamente l’unico ambito del software aziendale in cui i fornitori fanno affermazioni audaci, ma come recita il vecchio adagio: se sembra troppo bello per essere vero, probabilmente lo è. Noi abbiamo osservato che praticamente ogni gennaio, al NRF trade show di New York – una delle più grandi fiere del retail al mondo, operativa da oltre un secolo – spesso appare un grande fornitore che afferma con audacia che i livelli di inventario possono ora essere dimezzati grazie alla sua nuova soluzione. Se anche solo un decimo di queste affermazioni fosse vera, l’intero settore avrebbe raggiunto livelli di scorte quasi perfetti già un decennio fa. Esistono così tanti modi per manipolare i numeri dei casi aziendali che la maggior parte dei fornitori in realtà non sta mentendo. Il caso più comune è che l’azienda pubblicizzata come il “caso esemplare” per la soluzione possedesse una supply chain enormemente disfunzionale fin dall’inizio, e perciò erano possibili miglioramenti altrettanto massicci, una volta che le cose fossero tornate alla normalità un anno dopo.

Fidarsi del team Sales per le previsioni

Rimane un mistero se le persone che incaricano il loro team Sales di produrre previsioni di domanda accurate abbiano mai lavorato realmente con un vero team di vendita. Nel migliore dei casi, questi numeri possono essere visti come una sincera congettura, ma molto spesso sono semplicemente inventati dal team Sales per trarre vantaggio da qualsivoglia incentivo finanziario a loro assegnato. Ciò ha dato origine alla pratica diffusa nota come “sandbagging”, in cui tutti fissano i propri obiettivi il più bassi possibile per poi superarli successivamente. Inoltre, in seguito, abbiamo team della supply chain che spesso fingono di prestare attenzione a tali cifre, mentre le operazioni reali rimangono completamente separate dagli input forniti dalle Sales. Ignorare le cifre suggerite dal team Sales è l’unica opzione ragionevole, poiché la supply chain smetterebbe di funzionare del tutto se dovesse operare basandosi su numeri così scadenti.

Soluzioni comprovate

Cercare una soluzione comprovata che sia riuscita a produrre benefici tangibili per un’azienda molto simile alla tua potrebbe sembrare un’idea molto razionale. Da un punto di vista aneddotico, è esattamente ciò che fece Nokia, e innumerevoli altre aziende, fino a scomparire. La maggior parte delle grandi aziende non agisce così rapidamente quando si tratta di scegliere una soluzione complessa. Il processo di selezione del fornitore può facilmente richiedere fino a 1 anno. Successivamente, raggiungere la velocità di crociera con la soluzione scelta potrebbe richiedere un ulteriore anno. Monitorare e accrescere la fiducia nei risultati può richiedere ancora 1 o 2 anni; specialmente per quelle supply chain in cui non tutte le soluzioni sono sostenibili, e dove la supply chain potrebbe rapidamente tornare allo stato di prestazione precedente, una volta che il fornitore non è più costantemente presente in loco per perfezionare la soluzione. Dopo di ciò, potrebbe volerci un altro anno prima che il fornitore della soluzione arrivi nella tua azienda con questa prova duramente conquistata. Il difetto fatale in questa linea di pensiero è che la tua azienda può permettersi di arrivare al party con 5 anni di ritardo. Quando si parla di software, 5 anni sono un tempo molto lungo. In realtà, la maggior parte dei software è considerata obsoleta entro il quinto anno; perché la tua soluzione per la supply chain dovrebbe essere diversa?

Cattive metriche, cattivi benchmark

La Quantitative Supply Chain si basa su numeri di cui ci si può fidare. Di conseguenza, tendiamo ad affidarci fortemente a metriche e benchmark. Tuttavia, osserviamo che, nella supply chain, la stragrande maggioranza dei benchmark e delle metriche è così mal concepita da essere generalmente considerata pseudo-scienza. Buone metriche per la supply chain richiedono un notevole impegno. Buoni benchmark per la supply chain richiedono uno sforzo quasi smisurato. Troppo spesso, metriche e benchmark vengono semplificati eccessivamente per il bene della facilità, a discapito della reale rilevanza per l’azienda. In linea di massima, se gestire un benchmark non sembra un compito incredibilmente difficile per i tuoi team della supply chain, allora è probabile che la sfida sia ampiamente sottovalutata.