00:00:13 Sfide nell’implementazione dei proofs of concept nella supply chain.
00:01:00 Quando i proofs of concept funzionano bene e come la supply chain differisce.
00:02:29 La supply chain come problema aperto e le difficoltà nel misurare il suo successo.
00:03:31 Limitazioni dei proofs of concept nell’industria della supply chain.
00:06:30 Importanza di un approccio olistico e dei tempi di consegna nell’ottimizzazione della supply chain.
00:08:00 Importanza di concentrarsi sugli aspetti immutabili di un’iniziativa.
00:08:54 Difficoltà nel raccogliere dati nei proofs-of-concept.
00:11:55 Problemi nel semplificare un’iniziativa riducendola solo alla previsione.
00:13:54 Le limitazioni delle previsioni su serie temporali.
00:15:17 Esperienze dolorose con i proofs-of-concept e le loro limitazioni.
00:17:36 Alternative ai POCs nella valutazione dei fornitori di software per soluzioni supply chain.
00:20:25 Il futuro dei POCs nell’industria della supply chain e le loro limitazioni.
00:21:31 Importanza di adottare un approccio olistico all’ottimizzazione della supply chain.
00:22:52 Valutare le prestazioni dei fornitori su base settimanale invece di affidarsi ai POCs.
Riassunto
In un’intervista, Joannes Vermorel, fondatore di Lokad, e l’host Kieran Chandler discutono di ottimizzazione della supply chain e delle limitazioni dei proofs of concept (POCs). Vermorel spiega perché Lokad spesso declina le richieste di POC, citando il danno per entrambe le parti. Egli ritiene che i POC funzionino meglio per problemi definiti in modo ristretto, come la scelta di un client di posta elettronica, ma risultino insufficienti in processi complessi e trasformativi come l’ottimizzazione della supply chain. Le supply chains coinvolgono più parti e presentano una sfida distribuita che i POC tendono a semplificare eccessivamente. Consiglia di concentrarsi sugli aspetti stabili e su prospettive olistiche supportate dai dati. Vermorel suggerisce inoltre di valutare regolarmente le prestazioni dei fornitori e di terminare i rapporti che non mostrano progressi soddisfacenti.
Riassunto Esteso
Nel corso dell’intervista, Kieran Chandler, l’host, e Joannes Vermorel, fondatore di Lokad, si impegnano in una discussione dettagliata sui proofs of concept (POCs) nel contesto del software per supply chain e delle loro limitazioni. Vermorel spiega perché Lokad rifiuta frequentemente le richieste di POC da parte di potenziali clienti, citando il potenziale danno sia per l’azienda del cliente che per Lokad.
Vermorel inizia riconoscendo che i POC esistono da due decenni e non sono intrinsecamente dannosi. Funzionano efficacemente quando applicati a un problema definito in modo ristretto. L’archetipo di una situazione in cui un POC sarebbe efficace è la scelta di un client di posta elettronica come Microsoft Outlook o Gmail. Si tratta di un problema standardizzato con una soluzione nota. L’utente ha aspettative chiare e conosce i punti critici. Questo processo non è più trasformativo; comporta semplicemente il passaggio da un client di posta elettronica all’altro.
Tuttavia, la sfida sorge quando i POC vengono applicati all’ottimizzazione della supply chain, che Vermorel definisce come “l’opposto” di un problema definito in maniera ristretta. Egli suggerisce che si tratti di un processo trasformativo per un’azienda, caratterizzandolo come un problema non locale che si estende su più sedi e potenzialmente numerosi paesi. La complessità è amplificata a causa della natura interconnessa della supply chain.
Approfondendo il concetto di “problema aperto”, Vermorel descrive l’ottimizzazione della supply chain come il desiderio di ottimizzare, che richiede intrinsecamente una misurazione. La definizione di una misura significativa in termini monetari richiede un notevole sforzo, e le metriche ottenute sono solo l’inizio. Il percorso prosegue con il perfezionamento della “ricetta numerica” per valutare l’impatto delle azioni sulle operazioni aziendali. Egli offre l’esempio di valutare il costo preciso di ogni stock-out o l’impatto specifico sulla fedeltà del cliente per ogni cliente.
Quando gli viene chiesto se i POC siano inefficaci esclusivamente per la quantitative supply chain o per l’intera industria della supply chain, Vermorel afferma che la maggior parte dei problemi della supply chain sono difficili da inquadrare come POC a causa della loro natura interconnessa. Egli spiega che le supply chains coinvolgono più parti - fornitori, clienti, magazzini di stoccaggio e impianti produttivi. Esse presentano una sfida distribuita, contrariamente a una sfida localizzata, come l’ottimizzazione di un processo produttivo in isolamento. Vermorel sottolinea che le supply chains sono intrinsecamente collegate a fornitori e clienti, il che rende difficile individuare qualcosa che sia allo stesso tempo locale e significativo. Avverte che, pur essendo facile eseguire ottimizzazioni locali nelle supply chains, tali sforzi tendono a comportare soltanto lo spostamento dei problemi. Ad esempio, un notevole sforzo per ottimizzare un prodotto in una determinata sede può inavvertitamente creare problemi altrove nella supply chain.
Vermorel spiega che l’ottimizzazione della supply chain è una sfida per i POC perché tendono a concentrarsi su micro-ottimizzazioni senza considerare il quadro globale. Questo può causare problemi per fornitori e clienti. Inoltre, i lead times complicano ulteriormente il processo poiché è difficile ottimizzare una supply chain in un lasso di tempo inferiore al lead time stesso. Ciò spesso porta i POC a richiedere tempi molto più lunghi del previsto.
Chandler e Vermorel discutono l’importanza di considerare il quadro globale quando si cerca di ottimizzare le supply chain. Essi sottolineano che i POC spesso non tengono conto dei lead times completi necessari per una reale comprensione della supply chain. Vermorel consiglia di adottare un approccio capitalista in ogni fase della metodologia, concentrandosi su ciò che non cambierà indipendentemente dal fornitore o dalla soluzione scelta.
Una delle sfide affrontate durante i POC è la raccolta e la misurazione dei dati. Vermorel crede che non si possa ottimizzare ciò che non viene misurato, quindi la raccolta dei dati dovrebbe essere una priorità. Tuttavia, la realtà rende spesso la raccolta dei dati per i POC più difficile del previsto. Ciò è dovuto alla complessità delle situazioni reali, come reti di vendita al dettaglio con molteplici magazzini, unità produttive e sedi di distribuzione.
Vermorel fornisce un esempio di come la domanda storica possa essere difficile da valutare con precisione. Problemi come gli stockouts, le promozioni e altre anomalie possono distorcere i dati storici degli ordini, rendendo difficile comprendere i veri modelli di domanda. Quando i POC incontrano questi problemi, spesso ricorrono ai classici metodi di forecasting, come le previsioni settimanali di serie temporali. Questo approccio semplifica il problema ma ignora le complessità e le sfumature dell’ottimizzazione della supply chain.
Backtesting, ovvero l’utilizzo di dati storici per testare le previsioni, è un altro strumento utilizzato nell’ottimizzazione della supply chain. Pur funzionando da un punto di vista statistico, Vermorel sostiene che rappresenta solo una frazione del quadro globale nella gestione della supply chain. Ad esempio, i modelli di acquisto possono essere influenzati da fattori quali prezzi negoziati e quantità minime d’ordine (MOQs), che non vengono presi in considerazione nel backtesting.
Vermorel evidenzia che l’ottimizzazione della supply chain non è un problema unidimensionale che può essere risolto concentrandosi esclusivamente sull’accuratezza delle previsioni. Egli sostiene che i processi esistenti devono essere rivisti e adeguati per rendere possibile l’ottimizzazione. Il problema principale nel concentrarsi sulle previsioni è che si trascura il quadro globale e si fa affidamento su un tipo specifico di previsione che potrebbe non essere applicabile a tutte le situazioni.
Vermorel sottolinea che le supply chain sono state digitalizzate per decenni, ma molte aziende continuano a fare affidamento su fogli Excel e ignorano i numeri generati dai vari sistemi. Egli suggerisce che le aziende dovrebbero concentrarsi sui fondamenti, come consolidare i dati in un data lake e creare una documentazione significativa che rifletta la semantica della loro supply chain.
Concentrandosi sugli aspetti stabili di una supply chain, come fornitori, unità produttive, magazzini e canali di distribuzione, le aziende possono creare metriche che riflettano i loro interessi finanziari a lungo termine. Vermorel sottolinea che la sfida principale risiede nel comprendere la semantica dei dati e nell’assicurarsi che i dati giusti siano disponibili per l’ottimizzazione.
Considerando alternative ai POC, Vermorel propone di concentrarsi su ciò che non cambia in una supply chain e di cercare un fornitore in grado di offrire una prospettiva olistica guidata dai dati. Sebbene i POC possano offrire alcune intuizioni, egli avverte di non aspettarsi troppo da esperimenti su piccola scala, poiché i problemi complessi richiedono approcci più approfonditi.
Egli suggerisce inoltre che collaborare con i fornitori non debba essere un impegno a lungo termine. Le aziende possono intraprendere iniziative lean e valutare le prestazioni del fornitore su base settimanale per assicurarsi che si faccia progresso. Se i risultati non sono soddisfacenti, è meglio terminare la relazione in anticipo piuttosto che proseguire con un fornitore subottimale.
Trascrizione completa
Kieran Chandler: Oggi capiremo esattamente perché i POC non funzionano e quali sono le alternative a disposizione di un cliente per scegliere tra la moltitudine di software per supply chain disponibili. Quindi, Joannes, i POC esistono da due decenni, quindi non possono essere tutti negativi. In quali settori funzionano effettivamente?
Joannes Vermorel: I POC funzionano bene quando si ha un problema specifico e ristretto da risolvere, quando non è necessario pensare a possibilità ampie e sconfinanti. Ad esempio, l’archetipo di un ambito in cui un POC funzionerebbe bene sarebbe se ti chiedessi di scegliere il tuo client di posta elettronica, dato che hai usato un client come Microsoft Outlook o Gmail per anni. Quindi, sai cosa aspettarti, conosci i tuoi punti critici. Questo è un problema abbastanza standardizzato con soluzioni altrettanto standardizzate, e potrai fare un confronto molto preciso perché sai esattamente cosa cercare. Per la tua azienda, questo è fondamentalmente qualcosa che non rappresenta una trasformazione; era trasformativo decenni fa, quando le persone iniziarono a usare la posta elettronica, ma a questo punto si tratta semplicemente di passare da un client all’altro. I POC funzionano bene per quei problemi super tattici e ben definiti. La grande sfida è che la supply chain quantitativa è in qualche modo l’opposto. È qualcosa che trasformerà fondamentalmente la tua azienda, ed è fondamentalmente qualcosa di completamente non locale. Non puoi eseguire una supply chain localmente dalla tua scrivania. È perché esiste una rete che si estende su molteplici sedi, potenzialmente in molti paesi, che le cose diventano davvero complicate.
Kieran Chandler: Quindi, cosa caratterizza questo come un problema aperto?
Joannes Vermorel: La supply chain è innanzitutto un’idea che vogliamo ottimizzare e, per ottimizzare, è necessario misurare. Solo il fatto di voler misurare le cose in euro o in dollari richiede uno sforzo considerevole per ottenere una misurazione che abbia effettivamente senso. La metrica, il punto di partenza, è in realtà un percorso per affinare il modo in cui la tua ricetta numerica valuta se stai facendo qualcosa di buono o di cattivo per la tua azienda. Ovviamente, soddisfare i clienti è positivo, avere un’enorme quantità di stock-out è negativo, ma la domanda diventa esattamente: come valutiamo il costo preciso di ogni singolo stock-out, l’impatto preciso sulla fedeltà di ogni cliente?
Kieran Chandler: Quindi, quando dici che i POC fondamentalmente non funzionano, è solo per la supply chain quantitativa che non danno risultati, o vale per l’intera industria della supply chain?
Joannes Vermorel: La maggior parte dei problemi relativi alla supply chain è molto difficile da inquadrare come POC. Per definizione, le supply chain coinvolgono più parti: hai molti fornitori, molti clienti, magazzini e impianti di produzione. È essenzialmente una sfida molto distribuita, in contrasto con qualcosa di estremamente locale, come l’ottimizzazione di un processo produttivo completamente isolato dal resto del mondo. Le supply chain sono interamente connesse ai tuoi fornitori e ai tuoi clienti. Quindi, praticamente per definizione, è difficile trovare qualcosa che sia allo stesso tempo locale e significativo, perché il problema delle supply chain è che è molto facile effettuare un’ottimizzazione locale. Il punto è che, quando lo fai, di solito finisci per spostare semplicemente i problemi. Quindi, sì, hai creato un problema per il tuo fornitore e magari per un paio di clienti facendo ciò. Non hai risolto il quadro globale; hai solo micro-ottimizzato qualcosa a livello locale. Questo rende la supply chain molto impegnativa per i POC in generale. E poi c’è un ulteriore livello di difficoltà nel caso di Lokad. Poiché vogliamo affrontare il futuro e le incertezze, bisogna tenere in considerazione i lead times. Quindi, ogni volta che ci si trova in un settore in cui i lead times richiedono di pianificare ed eseguire le cose pensando a tre mesi in anticipo, significa che, per quanto tu ottimizzi le ricette numeriche per la tua supply chain, una iterazione richiede all’incirca lo stesso tempo del lead time. Ciò significa che non puoi davvero fare nulla in un lasso di tempo inferiore al lead time e, più realisticamente, avrai bisogno di due o tre iterazioni. Quindi, se hai lead times di circa tre mesi, e stiamo parlando di due o tre iterazioni, si tratta di sei o nove mesi. Non è eccessivamente lungo per un software aziendale, ma cominciamo a distaccarci molto da ciò che la gente intende quando pensa a un POC rapido.
Kieran Chandler: Diciamo di approfondire un po’. Quello che stai dicendo è che in un proof of concept si guarda fondamentalmente solo a una visione parziale, e perché una soluzione funzioni davvero e si dimostri efficace, deve considerare l’intero quadro d’insieme. E poi la seconda cosa che hai menzionato riguarda i lead times, e stai dicendo che un proof of concept è normalmente piuttosto breve, dunque non si tengono in conto i lead times completi per ottenere veramente i risultati e comprendere cosa stia accadendo. Per quanto tempo dovresti davvero perseverare con un proof of concept prima di vedere effettivamente dei risultati?
Joannes Vermorelr: Il punto è che se aspetti fino a finalizzare le tue misurazioni ed è assolutamente chiaro che puoi misurare i benefici e codificarli, ci vorrà troppo tempo. È per questo che solitamente suggeriamo di adottare una metodologia che sia altamente capitalistico a ogni passo e guidata dalla visione. Con “capitalistico a ogni passo” intendo che, indipendentemente da come desideri ottimizzare la tua supply chain, ti serviranno dati per eseguire questa ottimizzazione. Il processo richiederà un po’ di tempo, ma è in un certo senso indipendente dal fornitore o dalla soluzione che scegli, anche se decidi di farlo internamente o con una società esterna. Dovrai seguire questo processo. Se riesci a eseguire la tua iniziativa concentrandoti su ciò che non cambierà rispetto al fornitore scelto, se presente, alla fine dell’iniziativa, allora puoi essere altamente capitalistico. Ad esempio, non puoi ottimizzare ciò che non misuri, quindi dovresti iniziare a raccogliere dati per le misurazioni. Questo sforzo probabilmente supererà quello che pensi sia idoneo per un proof of concept.
Kieran Chandler: Probabilmente questo sorprende molti dei nostri spettatori, perché nei proof of concept la raccolta dei dati dovrebbe essere l’aspetto semplice fornito all’inizio del proof of concept. Quindi, perché è così difficile?
Joannes Vermorel: È sempre difficile perché la realtà ha i suoi modi per assicurarsi che i tentativi di proof of concept falliscano nelle maniere più miserabili. Ma, in modo più serio, prendiamo una situazione reale di ciò che sta accadendo. Supponiamo che tu abbia una rete retail che comprenda un paio di magazzini, un paio di unità di produzione, e forse un paio di sedi di distribuzione. Ora avvii la tua iniziativa dove dici.
Kieran Chandler: Parliamo di clienti soddisfatti del modo in cui li servi. Quindi, ti rendi conto che vuoi iniziare il tuo proof of concept, e scopri che ottenere tutti i dati transazionali è più difficile di quanto sembrasse all’inizio. Perché succede ciò?
Joannes Vermorel: Beh, per esempio, potresti dire che gli ordini dei clienti dovrebbero essere facili. Sì e no, perché possono verificarsi molte situazioni strane, come un cliente che ti invia un ordine che non puoi evadere a causa di un esaurimento di stock. Registri diligentemente nel sistema che l’ordine non è stato evaso. Il giorno dopo, il cliente effettua un altro ordine, addirittura più grande. Perché? Perché non hai evaso l’ordine del giorno precedente. Quindi, vuoi riflettere la domanda storica, non solo il flusso grezzo degli ordini storici del cliente che sono stati influenzati per varie ragioni. Ti rendi conto che è più complicato di quanto sembri.
Kieran Chandler: Quindi, cosa succede tipicamente con un’iniziativa di proof of concept quando ti trovi ad affrontare tutti questi problemi?
Joannes Vermorel: Cerchi di trovare modi per semplificare i problemi e inevitabilmente ricadi in un classico proof of concept di previsione, come una previsione settimanale su serie temporali. Pensi in termini di previsione della domanda basata sulla domanda storica, e puoi testarla subito retrospettivamente. Ignori gli esaurimenti di stock, le promozioni e tutti gli altri fattori bizzarri. Il risultato finale è qualcosa che rientra nella definizione di proof of concept, ma facendo ciò, ti allontani completamente dal problema che cercavi di risolvere.
Kieran Chandler: Parliamo un po’ del back testing. Si tratta di analizzare i dati storici, fare previsioni e confrontarli. Perché il back testing non funziona davvero?
Joannes Vermorel: Il back testing funziona dal punto di vista statistico, ma ha dei limiti. Dal punto di vista della supply chain, il back testing è solo un piccolo strumento numerico che rappresenta una frazione dell’intero quadro. Se inizi a pensare all’ottimizzazione dei modelli d’acquisto dei tuoi team, risulta che magari tutte quelle quantità minime d’ordine non sono scritte in pietra. Forse quegli acquisti sporadici sono dovuti al fatto che il tuo team acquisti ha negoziato prezzi bassi, ma con quantità minime d’ordine estremamente elevate. Questo costringe il tuo team a lasciare ulteriori ritardi tra gli ordini di acquisto, il che complica tutto e aumenta i lead times. Quello che sto dicendo è che eseguire un’ottimizzazione non è solo una questione unidimensionale, come diminuire l’errore dal punto di vista dell’accuratezza delle previsioni. Si tratta anche di abbracciare e rivedere tutti i processi esistenti e di adattare ciò che viene fatto, quando possibile, in modo che l’ottimizzazione diventi effettivamente possibile. Inoltre, è necessario pensare a cosa si sta realmente misurando. Il problema è che questi piccoli progetti di proof-of-concept, che inevitabilmente ricadono nei benchmark di accuratezza delle serie temporali, finiscono per avere un errore espresso in percentuale anziché in dollari. Ancora, siamo molto lontani da qualsiasi fondamentale di business. Kieran Chandler: Quindi, il vero problema con le previsioni è che ti stai concentrando solo su quell’aspetto e non stai considerando il quadro più ampio? È un tipo molto specifico di previsione. Raccogliere tutti i dati rilevanti è difficile, per cui puoi essere certo che il tuo proof of concept si tradurrà in una classica previsione su serie temporali con dati settimanali in ingresso e previsioni settimanali in uscita, e questo è tutto. Suppongo che ciò che stiamo descrivendo oggi derivi un po’ dal dolore dell’esperienza, dalle cose che hai provato in passato e dai POC che hai fatto. Allora, quali sono alcuni dei problemi chiave che hai riscontrato quando hai fatto POC?
Joannes Vermorel: La parte peggiore è che a volte riesci a ottenere un completo successo nel POC, e probabilmente è stata quella a ferire di più. Come azienda di software enterprise, non vinci ogni singolo lead che arriva, quindi perdere lead è solo una questione di vita. Quello che fa davvero male è quando vinci il POC perché, sì, nel POC performi al meglio, potenzialmente con un margine enorme, e poi quando cerchi di tradurre questo in una situazione di produzione, le cose esplodono completamente e non soddisfano nessuna delle aspettative del cliente. Ti rendi conto che è perché sei passato da un problema giocattolo a un problema del mondo reale. Forse ciò che avevi fatto per il problema giocattolo funzionava molto bene in questo ambito limitato, con un indicatore ben definito, ma ignorava completamente tutti i fondamentali del business. Quando passi alla situazione di produzione, realizzi che la tua soluzione è ben lontana dall’essere in grado di fornire una risposta.
Kieran Chandler: Guardiamo le cose ora dalla prospettiva di un’azienda. La cosa bella dei POC è che puoi vedere i diversi modi in cui i fornitori di software affrontano un problema e come in realtà reagiscono a determinate sfide. A parte ciò, quali sono le alternative che le aziende possono utilizzare invece di un POC? Cos’altro potrebbero fare per valutare le prestazioni di diverse aziende?
Joannes Vermorel: L’alternativa è concentrarsi sui fondamentali. Ho fatto notare che esiste la sfida del consolidamento dei dati. Il modo moderno di farlo al momento è costruire un data lake. Il passo successivo è fornire una documentazione significativa dal punto di vista della supply chain. Per avere successo, devi concentrarti su ciò che non cambia. La tua supply chain probabilmente non cambierà nelle sue modalità più fondamentali. Avrai comunque fornitori, unità di produzione, magazzini e canali di distribuzione. Ci sono molte cose che ci si aspetta restino relativamente stabili, quindi concentrati su questo. Quando consolidi i dati, consolida anche la documentazione pertinente perché la grande sfida è sempre la semantica dei dati.
Kieran Chandler: Se iniziamo a mettere insieme le cose e a concludere oggi, i POC sono presenti nell’industria della supply chain da decenni ormai. Voglio dire, riesci davvero a immaginare un periodo in cui i POC non esistano affatto?
Joannes Vermorel: Ovviamente, ci saranno ancora giovani che non sanno meglio e chiederanno ancora un POC. Sai, è solo un fatto di vita. E forse avranno ragione, perché, ancora una volta, esistono situazioni, anche nelle supply chain, in cui un POC è davvero la via da seguire. Se hai una nuova stampante barcode che sembra compatibile con il sistema, che dispone delle vecchie stampanti barcode, ma la nuova è semplicemente migliore, più veloce, più economica, più snella, e via dicendo. Questo è un problema in cui puoi acquistare un’altra stampante barcode e provarla nel tuo magazzino preferito. Quindi, ci sono situazioni e problemi nei quali un POC è proprio la soluzione. Tuttavia, quando vuoi pensare a una sfida di ottimizzazione su scala supply chain che adotti davvero una prospettiva olistica, direi di non aspettarti troppo da esperimenti su piccola scala. È solo che, inevitabilmente, ti renderai conto che il problema è complesso, e se non ti impegni abbastanza, fallirai semplicemente perché non hai nemmeno provato a fondo.
Joannes Vermorel: Cosa significano questi dati? Quando abbiamo una data d’ordine, era la data in cui hai prodotto l’ordine da inviare al fornitore, la data in cui l’ordine è stato registrato nel tuo sistema, o la data in cui il tuo fornitore ha confermato di aver ricevuto l’ordine? Ci sono una dozzina di possibilità. La domanda è: dove sono documentate tutte queste informazioni? Se non hai accesso ai dati e alla loro semantica, non c’è speranza di ottimizzare nulla. Ancora, per esempio, quando ho descritto un approccio quantitativo alla supply chain, sì, esiste Lokad come piattaforma di cloud computing per eseguire su scala tutte quelle ricette numeriche. Ma ciò che è altamente capitalistico per il cliente è il consolidamento di tutti i dati rilevanti, la comprensione della semantica della supply chain, la creazione di metriche che riflettano veramente l’interesse finanziario a lungo termine della tua azienda, il che è difficile. Definire i processi che funzionano bene con i vincoli fisici della tua supply chain, e tutto questo è interno ed in larga parte indipendente dal toolkit che usi per eseguire quei calcoli numerici.
Kieran Chandler: Se cominciamo a mettere insieme le cose e a concludere oggi, i POC sono presenti nell’industria della supply chain da decenni ormai. Voglio dire, riesci davvero a immaginare un periodo in cui i POC non esistano affatto?
Joannes Vermorel: Ovviamente, ci saranno sempre dei giovani che non sanno meglio e chiederanno ancora un POC. Sai, è solo un fatto di vita. E forse avranno ragione, perché, ancora una volta, esistono situazioni, anche nelle supply chain, in cui un POC è davvero la via da seguire. Se hai una nuova stampante barcode che sembra compatibile con il sistema, che dispone delle vecchie stampanti barcode, ma la nuova è semplicemente migliore, più veloce, più economica, più snella, e via dicendo. Questo è un problema in cui puoi acquistare un’altra stampante barcode e provarla nel tuo magazzino preferito. Quindi, ci sono situazioni e problemi nei quali un POC è proprio la soluzione. Tuttavia, quando vuoi pensare a una sfida di ottimizzazione su scala supply chain che adotti davvero una prospettiva olistica, direi di non aspettarti troppo da esperimenti su piccola scala. È solo che, inevitabilmente, ti renderai conto che il problema è complesso, e se non ti impegni abbastanza, fallirai semplicemente perché non hai nemmeno provato a fondo.
Kieran Chandler: Quindi, come messaggio chiave finale di oggi, è che i POC possono darti una sorta di intuizione, ma non aspettarti troppo, e in realtà non funzionano nel loro insieme?
Joannes Vermorel: Sì, e l’opposto di un POC non dovrebbe essere un impegno di dieci anni con un fornitore. Voglio dire, è anche un’altra cosa. Non è perché non fai un POC che non puoi dire: “Suppongo che possiamo lavorare con un fornitore. Ci piacerebbe avviare iniziative, sai, in un settore snello, quindi non deve essere necessariamente molto costoso, e poi procederemo con te settimana dopo settimana.” Invece di concentrarci sul fatto che le iniziative dovrebbero essere delimitate in dieci settimane, la questione diventa: la velocità di progresso dell’iniziativa ti soddisfa? Da una settimana all’altra, stai facendo progressi ad un ritmo soddisfacente?
Joannes Vermorel: Se scegli un fornitore e dopo tre settimane ti rendi conto che le cose appaiono ancora molto lente, allora dovresti interrompere, anche in un lasso di tempo più breve di quello tipico di un POC. La questione è più che altro: pensi a dieci anni avanti, ma quella è la tua visione. Ti concentri su un elemento che sarà altamente capitalistico per la tua azienda per il prossimo decennio. Ma quando si tratta di staccare un fornitore enterprise dalla porta perché semplicemente non sta fornendo, si tratta più di una valutazione settimanale in cui riesamini se le cose stanno progredendo e se si sta creando un certo slancio. Stai cercando tutti quei piccoli segnali, con una pianificazione indefinita in mente.
Kieran Chandler: Dovremo lasciarci qui, ma vedremo se abbiamo spaventato tutti.
