00:00:00 Capitolo relativo all’implementazione e inquadramento dei professionisti
00:04:35 La semplicità batte la complessità della supply chain tradizionale
00:09:10 Le decisioni non presidiate evitano deviazioni nel flusso di lavoro
00:13:45 La gestione del cambiamento elimina per lo più il lavoro inutile
00:18:20 Le decisioni definitive riducono drasticamente l’implementazione dell’IT
00:22:55 La confusione dei dati aziendali è responsabilità del fornitore
00:27:30 Survival dimostra che i dati sono già sufficienti
00:32:05 Gli Supply Chain Scientists prendono decisioni redditizie
00:36:40 Una mente impedisce ricette numeriche frammentate
00:41:15 La spiegabilità richiede proprietà e white-boxing
00:45:50 Le spiegazioni iniziano quando le decisioni vengono effettivamente visualizzate
00:50:25 Decisioni folli rivelano vincoli e campi mancanti
00:55:00 Le decisioni redditizie possono rompere le vecchie abitudini
00:59:35 Post-dispiegamento significa mantenimento contro la deriva strutturale
01:04:10 Il miglioramento continuo amplia la portata decisionale nel tempo
01:08:45 Nessun valore senza decisioni finali
01:13:20 Dieci settimane dovrebbero mostrare progressi reali
01:17:55 La fiducia richiede mesi; testare prima i problemi più difficili
Riepilogo
Joannes Vermorel e Conor Doherty continuano la discussione capitolo per capitolo su Introduzione alla supply chain. Il capitolo dieci si concentra sull’implementazione: il lavoro pratico volto a portare in produzione le decisioni automatizzate della supply chain, rendendole affidabili e garantendo che rimodellino le operazioni quotidiane anziché rimanere un prototipo.
Riepilogo esteso
Questa discussione sull’implementazione elimina molte delle sciocchezze alla moda nel software aziendale. Il punto centrale non è complicato: lo scopo di un’iniziativa di supply chain non è produrre dashboard, flussi di lavoro, scorecard o altri artefatti decorativi di gestione. Il suo scopo è produrre decisioni migliori. Se un cosiddetto dispiegamento non si conclude con decisioni incustodite, verificabili ed economicamente valide, allora gran parte di ciò che lo precede è, nella migliore delle ipotesi, una cerimonia.
Un errore ricorrente nel settore è la confusione tra complessità e sofisticazione. Molte aziende adottano livelli di segmentazione, sostituzioni, avvisi e flussi di lavoro di approvazione perché queste cose sembrano prudenti. In pratica, spesso creano più codice, più eccezioni, più ambiguità e più opportunità di fallimento. Ciò che appare “più sicuro” diventa più difficile da mantenere, più lento da migliorare e più facile da incolpare tutti e nessuno. Al contrario, un sistema progettato fin dall’inizio per generare decisioni definitive è più difficile in linea di principio ma più semplice nella pratica.
Un altro punto importante riguarda i dati. Alle aziende viene spesso detto che i loro dati sono troppo confusi per supportare l’automazione. Questa scusa sopravvive perché è utile ai fornitori i cui sistemi falliscono. Ma qualsiasi azienda ancora in attività su larga scala possiede già dati sufficientemente validi per gestire la propria supply chain, altrimenti sarebbe fallita molto tempo fa. Il problema non è se i dati sono ordinati. I veri sistemi aziendali non lo sono mai. La questione è se le persone che costruiscono la soluzione siano sufficientemente competenti per affrontare la realtà piuttosto che richiedere un set di dati immaginario.
Il ruolo dello Supply Chain Scientist, come qui descritto, non è quindi ristretto. Non si tratta semplicemente di preparazione dei dati, né di modellazione, né di ottimizzazione isolatamente. È la proprietà dell’intera ricetta numerica, dai dati grezzi alla decisione finale. Suddividere tale responsabilità tra specialisti può sembrare efficiente, ma di solito crea fallimenti. Ciò che serve è una mente che comprenda l’intera catena abbastanza bene da renderla coerente e da spiegarla.
La stessa spiegabilità è qui trattata in modo pratico piuttosto che teatrale. Non spieghi le astrazioni fine a se stesse. Spieghi le decisioni. E la spiegazione deve finalmente incassare in economia: perché questo ordine, perché questo prezzo, perché adesso, perché non più tardi? Se la risposta non può essere espressa in termini di guadagni, perdite, rischi e compromessi, allora la spiegazione è probabilmente ornamentale.
La lezione più ampia è che l’implementazione dovrebbe essere giudicata in base all’ambizione e alla velocità. Punta innanzitutto al problema reale più difficile, non a un semplice problema giocattolo. Chiedi risultati utili in settimane, non vaghe promesse negli anni. Se un fornitore non riesce a dimostrare rapidamente la capacità decisionale, il ritardo non curerà l’incompetenza.
Trascrizione completa
Conor Doherty: Bentornati. Questo è l’episodio 10 di una serie molto speciale in cui Joannes e io prendiamo il suo nuovo libro, Introduzione alla supply chain, e discutiamo le idee capitolo per capitolo. Ora, per questa serie specifica, assumo una postura molto specifica. Come sai, fingo di non essere qualcuno che lavora in Lokad. Non ho mai sentito parlare di supply chain quantitativa. Sicuramente non conosco Joannes e non lavoro con lui da quasi quattro anni.
Faccio finta di essere uno dei circa 10 milioni di praticanti nel mondo che potrebbero vedere questo libro, essere curioso, iniziare a leggere e poi avere domande. Ora, oggi è il capitolo 10. Ciò significa che, ovviamente, ce n’erano nove prima di questo. Ti consiglio vivamente di guardarli prima perché sicuramente le cose di cui abbiamo discusso oggi si baseranno sul materiale trattato negli episodi precedenti.
E con questo, Joannes, cominciamo. Capitolo 10, distribuzione. Ora violerò immediatamente la posizione che ho appena promesso a tutti, e dirò che, sai, Conor, che lavora qui, i capitoli quattro, che tratta di economia, e il capitolo otto, che riguarda le decisioni, sono probabilmente i miei preferiti. Otto è probabilmente quello su cui ricevo più feedback, scusatemi, dalle persone che conoscono Lokad.
Ma se ci penso sinceramente dal punto di vista di un professionista, come qualcuno che legge il libro e i primi capitoli e pensa: “Mi piace davvero questo approccio. Mi piace davvero l’idea di una classificazione finanziaria quantitativa delle decisioni. Sto davvero pensando a qual è il tempo di dimezzamento di una decisione. Quello che faccio ora, apre o chiude le decisioni in seguito?” Ad esempio, sono tutti d’accordo per questo. Avranno una domanda molto semplice, che è: “Che diavolo ti sembra?” Ad esempio, cosa succederebbe se il mio capo mi dicesse: “È un’ottima idea, ma come sarà? Quali sono i ruoli? Cosa ci viene richiesto? Quali sono i dati? Quanto tempo ci vorrà? Quali sono i possibili punti di fallimento?”
Il capitolo 10 è il punto in cui entrerai effettivamente in questo argomento. Quindi, parleremo dei dettagli di questo, ma ad alto livello, per iniziare, secondo te, cosa fa sì che una distribuzione funzioni effettivamente e cosa ne fa fallire catastroficamente?
Joannes Vermorel: Perché per quanto riguarda Lokad, le aziende in cui abbiamo successo sono essenzialmente quelle che ci permettono di portare avanti lo sforzo. E può sembrare sciocco, ma fondamentalmente non ha nulla a che fare con la maturità. Quindi, vedete alcuni discutere con molti direttori della supply chain e dire: “Oh, abbiamo bisogno di un certo grado di maturità”, e qui non sono d’accordo, perché di quale maturità stiamo parlando?
Se per maturità intendi l’adesione alle teorie della supply chain interrotta, allora proseguire su questo percorso non ti aiuterà ad avere effettivamente successo con Lokad, ma anche solo ad avere successo a livello di supply chain. Vedete, la posizione che adotto in questo libro, voglio dire, questo libro è presentato come una nuova introduzione alla supply chain. Quindi non discuto a lungo di tutte le cose che non funzionano, ma puoi leggerle essenzialmente come cose che funzionano, in contrapposizione alla teoria tradizionale della supply chain che è essenzialmente una lunga lista o raccolta di cose che non funzionano nella pratica.
E quindi ci sono tutte quelle cose, come le previsioni dei punti, la microgestione del livello di servizio, un approccio in cui si gestisce la supply chain tramite avvisi ed eccezioni, tutto basato su regole, sostituzioni manuali per tutto, ecc. Ecc. Quindi la conclusione è che, quando Lokad ha successo, sono essenzialmente i luoghi che ci danno semplicemente una solida possibilità di provare qualcosa che è in genere un ordine di grandezza più semplice di ciò che comporta la supply chain classica.
Perché il problema è che, poiché la teoria della supply chain tradizionale è completamente sbagliata, finisce per essere un incubo di complicazioni nella pratica. Vedi, non appena hai effettivamente una teoria corretta, tutto diventa più semplice. Il software è più semplice, i calcoli sono più semplici, la logica è più semplice e il tipo di risultato finale arriva in modo molto più pulito, il che è come le decisioni, decisioni ottimizzate e adeguate al rischio, arrivano in modo molto più pulito alla fine dell’iniziativa.
Quindi, direi, forse se c’è una cosa da imparare, è non perseguire una teoria che alla fine fallirà, indipendentemente da chi è responsabile della sua implementazione. Noi di Lokad cerchiamo di guidare i nostri potenziali clienti e clienti a rimanere davvero concentrati su ciò che funzionerà. Ma alla fine, se ci danno ordini diretti, diventa molto difficile riuscire ad avere successo contro la volontà del cliente.
Conor Doherty: Sai, per proseguire, solo per chiarire, scusami, quando dici “un ordine di grandezza”, stai solo dando dei numeri, ma diciamo un ordine di grandezza più semplice, intendi in termini di distribuzione che è un ordine di grandezza più semplice? O intendi che in termini di risultati finali è molto più semplice da gestire?
Più semplice in termini di tempistica, quanti giorni sono necessari per rendere operativo un sistema? Quante ore-uomo devi investire? Quanta interruzione è necessaria? Voglio dire, ad esempio, un esempio, per favore.
Joannes Vermorel: Se inizi, diciamo, con qualcosa come l’analisi ABC, che ami, o qualsiasi tipo di segmentazione inventata, allora vedrai che non ne avevi bisogno. È come una soluzione pseudo-ovvia a un problema inesistente. Quindi la gente pensa: “Oh sì, dobbiamo affrontare questo problema variando la qualità del servizio o qualcosa del genere, attraverso una segmentazione”. La risposta breve è no, non è necessaria questa segmentazione.
E se siamo costretti a una segmentazione, finiamo per avere così tante righe di codice che saranno: se categoria A, allora questo e questo e questo; se la categoria B, allora questo e questo e questo. Se abbiamo un prodotto che recentemente è passato da B ad A, dobbiamo avere questo, questo e questo. Se recentemente è passato da A a B, allora abbiamo bisogno di qualcosa. Quindi vedete, è solo un’idea che sembra che la teoria dominante abbraccerebbe assolutamente e gradirebbe una segmentazione.
E questa cosa, dal punto di vista del codice, si trasformerà in un labirinto di casi limite, il che significa più righe di codice, più bug, più, direi, decisioni folli che usciranno dalla pipeline di dati alla fine della giornata. E quindi è necessario più tempo affinché le persone possano effettivamente rivedere i numeri. Hai bisogno di più rapporti anche solo per dare un senso ai numeri, ecc. Ecc. Vedete, queste cose si sovrappongono l’una all’altra.
E il genere di cose che fa Lokad può sembrare complicato, come una previsione probabilistica, ma non lo è, perché è un modo per eliminare letteralmente intere classi di problemi ed esprimere, in poche righe di codice, cose che altrimenti richiederebbero migliaia di righe di codice. Questo è il succo. Direi che dobbiamo perseguire ciò che è effettivamente semplice, non ciò che sembra semplice, che in realtà è semplicistico e quindi si riversa in tonnellate di regole e casi limite e, direi, complicazioni a valle.
Conor Doherty: Quindi, per proseguire, e voglio essere molto attento a non unire troppe idee insieme, quindi solo per inquadrarlo un po’ più concretamente, una delle cose di cui parli nel capitolo 10, ancora una volta sto parafrasando, ma questo è molto fedele, sostieni che nel contesto di una distribuzione, concretamente in termini di risultati finali, non stai perseguendo una migliore visibilità. Non stai perseguendo dashboard migliori. Non stai perseguendo previsioni migliori.
Lo scopo di un’implementazione, certamente in una prospettiva di ottimizzazione della supply chain, è quello di produrre decisioni automatiche e verificabili, come ad esempio ordini di acquisto, trasferimenti, pianificazioni o variazioni di prezzo che vengono poi riscritte nei sistemi operativi. SÌ. Questo è più semplice. Questo è il punto che stai sottolineando.
Joannes Vermorel: Ancora una volta, e l’importante è che rimanga incustodito. Quindi, ad esempio, se lo decidi, se dicessi: “Oh, il livello è così alto, incustodito. Vuoi davvero essere in grado di farlo bene così, senza passaggi intermedi, direttamente alle cose buone”. E io dico sì, perché qual è l’alternativa?
L’alternativa è progettare un flusso di lavoro molto complicato in cui le persone possano intervenire, eseguire ogni sorta di override e alla fine generare le allocazioni delle risorse, le decisioni effettive. Quanto compro? Quanto produco? Dove metto le scorte? Sposto il prezzo verso l’alto o verso il basso? Quindi, se decidi di prendere direttamente decisioni inaspettate, ovviamente quello che vuoi è dire: “Okay, non accetterei decisioni inaspettate che sono tutt’altro che eccellenti”. Devono essere, in genere, molto migliori di ciò che le persone potrebbero produrre manualmente.
Dico, va bene, nessun problema. Questo è assolutamente un criterio giusto. E quello che sto dicendo è che questo è l’obiettivo a cui dovremmo mirare fin dal primo giorno. E vedete, se ci provate, dite: “Okay, vogliamo farlo in modo attendibile, con un flusso di lavoro in più fasi” e così via, allora il vostro processo, che avrebbe dovuto essere l’ottimizzazione della supply chain, si trasforma nella progettazione di un flusso di lavoro, e poi diventa, come vedete, semplicemente non è lo stesso oggetto.
E fondamentalmente, invece di dedicare tempo a “Sto progettando un sistema che massimizzi davvero il tasso di rendimento di ogni risorsa allocata attraverso la mia supply chain?” che è il gioco a cui stiamo giocando, si dissolve in qualcosa in cui devi sondare le opinioni di ogni singola persona, e poi devi ottimizzare la produttività perché il flusso di lavoro è “lasciare che le persone intervengano”, quindi consuma tempo.
Quindi ci sono tutti i tipi di compromessi in gioco. Se offri maggiore flessibilità, le persone possono dire: “Oh, allora ho più leve”, ma poi si creano complicazioni perché i tuoi dipendenti potrebbero dedicare troppo tempo al flusso di lavoro. E poi se le decisioni finali si rivelano fasulle, di chi è la colpa? Sfuoca completamente la responsabilità.
Soprattutto se il flusso di lavoro coinvolge una mezza dozzina di persone che eseguono piccoli colpi di scena, in modo incrementale, diventa estremamente difficile individuare chi è la colpa. Quindi è necessario fare un’analisi di causalità su tutti questi dipartimenti. E vedete, è così che abbiamo iniziato con qualcosa che era: “Andiamo direttamente alle decisioni che sono più redditizie”, verso qualcosa in cui siamo stati completamente distratti, dove iniziamo a progettare un flusso di lavoro e interfacce utente e monitorare ciò che le persone stanno facendo e ottimizzare la produttività, ecc.
Vedi, è così che puoi finire con qualcosa che è un ordine di grandezza più lento, più complicato, solo perché in realtà hai fatto alcune cose che inizialmente sembravano più semplici. No, no, non lo è. Quindi, ancora una volta, per noi un vero criterio di successo è essere in grado di andare direttamente con la massimizzazione della redditività, senza deviazioni nei flussi di lavoro, senza deviazioni in artefatti numerici inventati come segmentazioni e quant’altro.
Alla fine, non ti interessa l’ABC. Ciò che ti interessa è: sto effettivamente massimizzando il ritorno sull’investimento? Non importa se divido e taglio i miei SKU attraverso le classi, attraverso questo, attraverso quello o qualsiasi altra cosa. Voglio dire, se quello che vuoi è massimizzare, ancora una volta, il tasso di rendimento con una prospettiva a lungo termine, il che significa che non stai abbracciando una prospettiva a breve termine, direi distruttiva, vuoi valutare la qualità del servizio in quanto conta proteggendo al tempo stesso i tuoi interessi a lungo termine, e tutto ciò sarà nel tasso di rendimento. In caso contrario, è solo che hai un criterio semplicistico che deve essere modificato.
Conor Doherty: Sì. E qualcosa che hai detto lì in particolare, ancora una volta, l’idea di parlare con i professionisti, sia solo in una conferenza, facendo podcast come questo, sia che si tratti di una chiamata di lavoro, qualunque cosa, una delle cose che emergono è la gestione del cambiamento. E qualcosa che hai detto lì, ti ho chiesto, tipo, cosa separa un successo da un fallimento, e tu hai detto, sai, le aziende ti permettono di fare semplicemente le tue cose.
E vorrei aggiungere che accettare il fatto che nella gestione del cambiamento significa che nel titolo ci sarà almeno qualche cambiamento. E il cambiamento sarà che ti allontanerai da ciò che hai appena descritto, la segmentazione, l’override manuale, la supervisione. Devi accettare che stai andando nella direzione dell’automazione, delle decisioni non presidiate.
Joannes Vermorel: E ancora, penso che parte del problema sia che il cambiamento apportato da Lokad è estremamente limitato e per lo più sottrattivo. Vedete, questo è il motivo per cui le persone sono molto, a volte molto, molto confuse. Lokad non richiede la riprogettazione delle aziende dei nostri clienti. Il cambiamento che apportiamo è quasi tutto sottrattivo, rimuovendo cose, e basta.
Quindi non è necessario riprogettare le descrizioni del lavoro di molte persone, riqualificandole. Essenzialmente è così, perché ancora una volta puntiamo a processi decisionali non presidiati, sì, sono concettualmente più semplici a tutti i livelli. Per l’IT è più semplice. È più semplice per gli operatori della filiera. Per il top management è più semplice. In effetti è più semplice per tutti.
Quindi non si tratta tanto di “Oh, abbiamo così tanti cambiamenti, avremo bisogno di imparare così tanto”, piuttosto che disimparare tutte le cose che semplicemente non sono più rilevanti. Vedete, pensatele come quelle vecchie macchine da scrivere, quelle meccaniche. Avevi bisogno di oliarli. Dovevi essere in grado di cambiare il nastro inchiostrato. A volte avevi bisogno di prendere…
Ne avevo uno quando ero giovane. Voglio dire, se volevi usare una macchina da scrivere meccanica a livello professionale, questa cosa richiedeva molta piccola manutenzione. È letteralmente un po’ di roba da orologeria. E se vai su un computer, all’improvviso non c’è più. La tua tastiera funziona e, se la tua tastiera è morta, ne acquisti semplicemente una nuova e il gioco è fatto.
La quantità di conoscenze necessarie per utilizzare una tastiera moderna, rispetto a una macchina da scrivere della vecchia scuola, è molto inferiore. Come vedete, la gestione del cambiamento è molto sottrattiva. Sono tantissime le cose che sono semplicemente scomparse. E questa è forse la parte che potrebbe creare più confusione per i potenziali clienti quando discutiamo con loro. Si aspettano, infatti, molti cambiamenti, nel senso: “Oh, dovremo riqualificare le persone, dobbiamo aggiungere questo e aggiungere quello”, e ce n’è ben poco. È molto, molto poco.
Per l’IT, Lokad rappresenta solo, direi, una piccola frazione dello sforzo richiesto da un sistema classico. Quindi per l’IT è molto meno. Certamente per un pilota, l’attrito è tipicamente molto basso. Si tratta essenzialmente di inviare file grezzi, file flat estratti dal sistema, nessuna pre-elaborazione di sorta, copiare e incollare, semplicemente scaricare e trasferire.
Conor Doherty: Questo è un punto chiave. Siamo spiacenti, in realtà questo è un punto chiave che abbiamo appena sorvolato, ovvero quanto sia basso rispetto a “Abbiamo bisogno di un processo di implementazione di due anni solo per prepararlo”. Non superare di nuovo quel punto.
Joannes Vermorel: Sì. Il motivo è, ancora una volta, che il modo in cui Lokad opera è che vogliamo che questo motore decisionale funzioni senza un flusso di lavoro. Quindi, voglio dire, il flusso di lavoro è super minimalista: dati inseriti, decisioni prese e il gioco è fatto.
E quindi ci sono così tante cose che semplicemente non sono necessarie. Non abbiamo bisogno di risincronizzarci con l’ERP, tonnellate di cose complicate, vedete, perché alla fine ciò che produciamo sono solo decisioni finalizzate che sono molto semplici da reimportare nell’ERP. Se vuoi generare, diciamo, un ordine di acquisto, sono solo il prodotto, la quantità e il fornitore ad essere interessati, e il gioco è fatto. La struttura dei dati, ordine d’acquisto finalizzato, è molto, molto semplice.
Al contrario di se vogliamo, diciamo, gestire molte segmentazioni, risincronizzarle con l’ERP, dare alle persone la possibilità di fare ogni genere di cose in Lokad e poi farlo risincronizzare nell’ERP, questo è il genere di cose che la maggior parte dei miei colleghi offrirebbe. Ed è per questo che l’implementazione richiede un’eternità, perché ancora una volta ci sono così tanti strati di artefatti numerici, cose che sono, direi, cose che non sono reali, che sono proprio come strumenti per arrivare al prodotto finale, che è una decisione.
E a volte anche il classico software di supply chain non arriva nemmeno alla decisione finale, quello che prende davvero tutti i vincoli come il controllo della quantità minima dell’ordine, il controllo della capacità massima del container, il controllo del carico completo del camion, ecc. Quindi molto spesso ci si ritrova con anche molta complessità che emerge dal fatto che, invece di puntare alla decisione completamente finalizzata, ciò che si ottiene dal tipico software di pianificazione avanzata, il classico APS, è qualcosa che è, ancora una volta, un risultato non finale, e quindi hai bisogno di un sacco di tubature in seguito per finalizzare effettivamente le decisioni.
Conor Doherty: Questo è un terreno molto fertile su cui continuare a camminare, credo, perché quando parliamo di coinvolgimento dell’IT, e questo è qualcosa che entrambi sappiamo per aver discusso con molti, molti professionisti a questo punto, una delle cose di cui si preoccuperanno è: “Beh, i miei dati anagrafici non sono abbastanza buoni. La salute dei miei dati è pessima. Joannes, dovresti vedere i miei dati. È un disastro. È indecente. Impraticabile. Non puoi nemmeno usarli.”
Tu, nel capitolo 10, hai chiarito molto chiaramente che questa è una totale sciocchezza.
Joannes Vermorel: Oh sì. Oh sì. La cosa interessante è che, ancora una volta, il mercato dei fornitori di software aziendale per la supply chain, voglio dire, questo mercato è assolutamente terribile e la maggior parte dei fornitori ha tassi di fallimento ben superiori al 90%. No, sembra letteralmente folle. Sono grandi. Sulla carta si suppone che abbiano centinaia di implementazioni di successo. In pratica, sono tutti diversi gradi di fallimento.
E ogni volta che fallisce, e quasi sempre fallisce, daranno la colpa ai dati perché sono un perfetto capro espiatorio. Un capro espiatorio così perfetto, lo sai. È come incolpare il dio del tempo o qualcosa del genere. Dai la colpa a una forza esterna, come se i dati fossero una cosa dell’universo e dobbiamo conviverci. No, no, no.
Quindi la mia opinione è: i dati sono quasi invariabilmente eccellenti per qualsiasi azienda superiore, diciamo, a 50 milioni di dollari. Quasi sempre eccellente. Perché? Perché le aziende che non disponevano di dati eccellenti sono fallite molto tempo fa. È solo darwinismo aziendale. Se non sai cosa stai acquistando, allora non saprai come pagare i tuoi fornitori, e pagherai alcuni fornitori due volte o non li pagherai affatto, e poi smetteranno di essere fornitori, o qualcosa del genere.
Allora non puoi sapere cosa stai comprando? No. Non puoi sapere cosa vendi? No. Perché se non sai cosa vendi, non inseguirai i clienti che si sono dimenticati di pagare, e cose del genere. Quindi le uniche aziende che sono sopravvissute sono quelle che sanno essenzialmente cosa comprano, cosa producono e cosa vendono, in sostanza.
Conor Doherty: Sì. SÌ. Regola fondamentale.
Joannes Vermorel: Sì. E ancora, il darwinismo in azione. Le aziende che non possono farlo sono fallite molto tempo fa, più probabilmente due decenni fa. Quindi le aziende che sono sopravvissute sono quelle in cui questi dati di base sono corretti. Corretti nel senso che riflettono la realtà e sono utilizzabili.
Conor Doherty: Quindi respingi l’argomento del disordine?
Joannes Vermorel: No. Oh sì, esattamente. Voglio dire, poi c’è cosa succede quando fornitori incompetenti, sì, si troveranno ad affrontare questi dati, e quello che si aspettano sono dati che siano perfettamente organizzati in un modo, diciamo, organizzato da una competizione Kaggle. Hai dati super ordinati con le tabelle giuste, con i campi giusti e tutto è ben documentato. Ma ancora una volta, una competizione Kaggle.
Sì, beh, se te lo aspetti come venditore, rimarrai deluso. SÌ. La realtà è che sì, il panorama applicativo è disordinato. Quello che dovrai affrontare è un panorama con una mezza dozzina di sistemi aziendali complessi, ciascun sistema aziendale ha da 1.000 a 10.000 tabelle, ciascuna tabella ha da 10 a 500 campi. E ogni singolo dato, come le vendite, è almeno triplicato. Quindi viene presentato in tre modi diversi in tabelle diverse per ragioni diverse, ed è proprio così.
Quindi ora, per quanto riguarda Lokad, è nostro compito, e direi che lo considero responsabilità di Lokad, semplicemente risolvere la questione. Questa è solo un’aspettativa di base. E quindi per noi non ci aspettiamo altro che un panorama applicativo estremamente disordinato con decenni di materiale sedimentato. Quindi hai, tipo, quattro diversi ERP, uno che era… perché gli ERP non muoiono mai veramente, vanno semplicemente in background, e hai ancora la cosa che è in esecuzione su qualche mainframe, su un AS/400 o qualcosa del genere, che è ancora in esecuzione, e non è mai stata veramente spenta.
E sì, devi affrontare anche questo, così come tutto il resto, ed è perfettamente normale. Quindi, vedete, quando le persone incolpano i dati, per me sono davvero i fornitori a dare la colpa. Per me è quasi sempre una dimostrazione di incompetenza da parte dei venditori. Se un venditore ti dice: “Oh sì, abbiamo fallito perché i dati non sono validi”, intendo dire che scappa. Questo venditore è completamente incompetente. Non sanno nemmeno di essere incompetenti e danno la colpa agli dei del tempo o qualcosa del genere. Semplicemente… dare la colpa ai dati sembra molto più tipico del 21° secolo che dire: “Sì, gli dei non erano con noi in questo, e quindi abbiamo perso questa battaglia”, ma è davvero la stessa cosa.
Conor Doherty: Questo è un punto chiave e voglio approfondirlo, perché devo separare due punti che hai sottolineato, ma voglio solo ribadirli perché sono importanti. Uno, l’affermazione “I miei dati sono disordinati”, è qui. E l’altro è: “I miei dati sono troppo disordinati per poter fare qualcosa di laborioso”. Queste sono due affermazioni separate che stai facendo.
E in realtà, proprio dietro le tue spalle, non so se è visibile sulla telecamera, c’è il tuo primo libro, il manifesto, quello rosso. E in questo fai l’esempio, penso sinceramente che sia negli anni ‘90, forse a pagina 98 o qualcosa del genere, fai l’esempio di, cosa significa la data di vendita? E elenchi da sei a dieci esempi diversi. Ad esempio, se apri i tuoi dati transazionali, potrebbe significare il giorno in cui è entrato nel carrello, il giorno in cui è stato venduto, il giorno in cui è terminato il periodo di restituzione, il giorno in cui è terminata la garanzia, qualunque cosa. Esistono molte interpretazioni diverse di ciò che significa. Questo lo rende disordinato.
Ma come hai detto poco fa, è responsabilità del venditore toglierti questo disordine dalle mani e farne qualcosa di laborioso e produttivo.
Joannes Vermorel: Sì. SÌ. E la chiave, e questo è appropriato per l’implementazione del capitolo, è che vuoi finire con il risultato finale di un’iniziativa, di qualcosa che fornisca decisioni molto fondate, adeguate al rischio e molto redditizie basate su qualunque dato tu abbia. Perché la realtà è che le persone all’interno della tua azienda non hanno accesso a più dati.
Il responsabile della produzione o il responsabile del magazzino o il responsabile degli acquisti, non entrano fisicamente nel magazzino per acquisire maggiori informazioni prima di inserire gli ordini di acquisto o l’ordine di produzione o quant’altro. Fanno tutto dalla loro scrivania e, per la maggior parte, non hanno alcun tipo di accesso privilegiato ad alcun tipo di informazione riservata, tranne quelle che si trovano effettivamente nei sistemi aziendali.
Quindi l’affermazione che sto facendo è che Lokad… perché la tua gente, i tuoi dipendenti, sono già in grado di gestire la tua supply chain, altrimenti, ancora una volta, con il darwinismo in azione, saresti in bancarotta. Quindi, se non sei in bancarotta, alcune persone riescono a far funzionare la tua attività, il che dimostra che i dati in qualche modo sono sufficienti. Il fatto stesso che la vostra azienda non sia ancora in bancarotta dimostra da solo che i dati sono abbastanza buoni.
Ora la domanda è: il fornitore è abbastanza competente da utilizzare i dati così come sono, invece di un pio desiderio? Se il fornitore arriva e dice: “Sì, avremo successo se i tuoi dati sono conformi ai miei standard”, lo standard del fornitore, tu come azienda che gestisce una supply chain non hai alcun controllo sullo standard del fornitore. Ovviamente, questa è una sciocchezza.
Immagina di voler riparare l’impianto idraulico di casa tua e il ragazzo che si presenta dice: “Oh no, sai, non mi piace molto lo stile con cui è stato organizzato l’impianto idraulico. Sembra un po’ complicato. I tubi non sono completamente dritti. No, penso che aspetterò che il tuo impianto idraulico sia davvero all’altezza dei miei standard prima di iniziare a dare un’occhiata.” E la gente direbbe: “No, tu sei l’idraulico. Occupati solo del modo in cui è stato fatto l’impianto idraulico. E sì, se ci sono alcuni tubi che non sono completamente dritti, voglio dire, occupatene. Questo è quello che ci aspettiamo da te.”
Vedete, questo modo di incolpare i dati è assolutamente folle. E per me, ciò che la dice lunga sulla follia di questo mercato è che alcuni venditori riescono abitualmente a farla franca incolpando il cliente per il fallimento con la scusa che si trattava solo di dati. E la cosa più folle è che molto spesso riescono a convincere i clienti stessi che è stata colpa loro.
Conor Doherty: Sai, per me è come, whoa. Non solo il venditore ha fallito, ma è riuscito a convincermi… mi ha fatto credere che fossi io.
Joannes Vermorel: Ok. Sono riusciti a convincere il loro cliente che era colpa loro. Direi che sì, è un talento. In un certo senso è un’arte, ma non esattamente quello che ti aspetteresti da persone che affermano di essere specialisti della supply chain invece di essere specialisti della manipolazione.
Conor Doherty: Bene, questo in realtà imposta il punto successivo, ovvero, ancora una volta, quando diciamo che Lokad prenderà i dati, o chiunque tu selezioni, ma nel nostro caso ovviamente siamo Lokad, prenderemo i tuoi dati e lavoreremo con quelli, ciò che in realtà intendiamo è lo Supply Chain Scientist. E questo in realtà ci porta a un punto centrale qui, che è il ruolo dello Supply Chain Scientist nell’implementazione e nel miglioramento continuo.
Ma certamente nella fase di implementazione, il ruolo dello Supply Chain Scientist è limitato solo all’analisi e al riordino dei dati, come hai appena detto, o è più onnicomprensivo?
Joannes Vermorel: No, perché il fatto è che non puoi sapere se il modo in cui tratti i dati è corretto o meno senza la lente delle decisioni finali. In definitiva, l’unico criterio per sapere se ciò che stai facendo con i dati è corretto o meno è: le tue decisioni sono redditizie o no? Questo è il…
Conor Doherty: In un certo senso, se si fraintendono i dati, ma le decisioni escono bene…
Joannes Vermorel: Allora il tuo malinteso è irrilevante.
Conor Doherty: Già.
Joannes Vermorel: E quindi la gente forse si sorprenderebbe, ad esempio, come puoi fare un errore e non importa? Ancora una volta, è un gioco di scala. Hai migliaia di tavoli. Hai, in totale, decine di migliaia di campi. Sì, ci saranno malintesi. Ci saranno dei problemi. Ci saranno molte cose. Ma ciò che conta è che, alla fine, anche le persone commettono errori. Puoi avere persone che leggono un campo; dovrebbero leggere un altro campo.
È davvero: generi decisioni che hanno lo zero per cento di follia? Quindi non c’è una sola decisione che sia immediatamente falsa.
Conor Doherty: Mhm.
Joannes Vermorel: E poi sono tutti almeno decentemente buoni, sai. E poi, quando si misura la performance economica in media, questa supera davvero lo status quo precedente? Questo è il criterio.
Quindi il fatto che si possa avere un lavoro infinito, direi, per continuare a migliorare la ricetta numerica per renderla molto, molto grande nel tempo è bello, e questa è una continuazione dello sforzo dello Supply Chain Scientist. Ma alla fine, vedete, il contributo dello Supply Chain Scientist dovrebbe essere letto come: riusciamo a far sì che quelle decisioni altamente redditizie vengano generate quotidianamente, senza attenzione? E questo è uno schieramento. Questa è un’iniziativa che arriva al punto in cui ogni giorno prendi le tue decisioni.
Questo è il contributo dello Supply Chain Scientist. E meccanicamente, o scusate, non meccanicamente, meccanicamente parlando, lo Supply Chain Scientist è essenzialmente l’esperto.
Conor Doherty: Penso che sia l’analogia che hai citato prima. È come se l’equipaggio dei box fosse tutto in uno. È l’ingegnere, il data scientist, l’esperto della supply chain che gestirà il tuo account specifico. Ad esempio, stai interagendo con quella persona, la persona che gestisce il tuo account.
Joannes Vermorel: Già. E va un po’ oltre. Quello che sto dicendo è che non dipende nemmeno da Lokad. Se frammenti la responsabilità della ricetta numerica… Quindi qualcuno deve progettare il pezzo di software che prende i tuoi dati grezzi e genera decisioni. Questo è ciò che, quando uso il termine ricetta numerica, è un software che parte dai dati così come si trovano nei sistemi aziendali, ciò che esiste grezzo, e genera alla fine dei conti le vere e proprie decisioni finali.
E quando dico finalizzato, significa che nessuno deve aprire un foglio di calcolo per modificare i numeri verso l’alto o verso il basso solo perché c’è una MOQ che non è stata gestita o altro. Quindi è davvero, davvero definitivo. Bene. L’ordine d’acquisto è esattamente pronto per essere inviato, ad esempio, al fornitore. Va bene.
Quindi, quello che sto dicendo è, ed è così che dovrebbe essere inteso lo Supply Chain Scientist, che deve essere una sola mente a coprire tutto questo. Una mente umana. E questa mente umana è la cosa più importante, perché alla fine vuoi avere qualcosa che sia completamente coerente dall’inizio alla fine.
E vedi, se si frammenta la responsabilità, questo è ciò che Lokad ha imparato 15 anni fa. Se frammenti questo compito in: “Oh, ci sarà una persona incaricata, diciamo, di preparare i dati, e poi un’altra sarà incaricata di fare, diciamo, la modellazione probabilistica, e poi un’altra sarà incaricata di fare l’ottimizzazione per il processo decisionale finale,” questo genere di cose, ti ritroverai con tonnellate di bug ai confini del tuo sistema.
Vedete, avendo diverse persone, stabiliranno naturalmente i confini all’interno di questa ricetta numerica, e quasi tutti i bug saranno concentrati in quei confini. Quindi devi solo avere un modo per rimuovere tutti quei confini in modo che non siano frammentati.
E un altro modo per capirlo è pensarlo come un processo in cui si suddivide il gioco degli scacchi in più fasi. Ad esempio, la prima persona decide una breve lista di pezzi che possono essere spostati, e poi un’altra persona decide qualcos’altro. Se organizzi il processo, alla fine della giornata otterrai una mossa di scacchi migliore? No. Voglio dire, è quasi garantito che se provi a frammentare il modo in cui giochi a scacchi, ti ritroverai con mosse di scacchi sbagliate, mentre, se stai giocando contro qualcuno che è veramente bravo, questa persona avrà semplicemente un enorme vantaggio su di te solo perché è una mente che può dare uno sguardo all’intero tabellone invece di cercare di frammentare l’analisi.
Conor Doherty: Naturalmente. Giusto per sottolineare un punto, o chiarire e, si spera, sottolineare il punto, quando dici che è una mente umana, stai parlando del lato di Lokad. È una mente umana perché ovviamente devi ancora interagire con il cliente.
Joannes Vermorel: Questa relazione non riguarda Lokad. Sai, questa Introduzione alla supply chain non riguarda Lokad. Riguarda cosa funziona e cosa non funziona nella supply chain. Lokad è appena menzionato nelle note a piè di pagina un paio di volte nell’altro libro.
Ciò che sto dicendo, e questa è la lezione più importante, è che se si desidera che qualsiasi iniziativa relativa alla supply chain funzioni davvero, non importa se Lokad è coinvolta. Sto dicendo che ci deve essere un software per generare le tue decisioni. Ci siamo passati. Se non disponi di un software, i tuoi sforzi e i tuoi investimenti non saranno incrementativi. Non puoi migliorarlo perché diventa molto confuso. Se qualcuno se ne va, ancora una volta, è estremamente difficile migliorare sistematicamente qualcosa che viene fatto completamente manualmente.
Ecco perché dico, okay, dobbiamo affrontarlo come un artefatto software, questa ricetta numerica. Va bene. Ora quello che sto dicendo è che ci sarà qualcuno coinvolto nella progettazione e nella manutenzione di questo artefatto numerico. Se Lokad è coinvolto, potrebbe trattarsi di qualcuno di Lokad. Se Lokad non è coinvolto, sarà qualcun altro. Non importa dove.
E finché non avremo livelli di intelligenza artificiale Skynet autonomi e capaci come gli umani, sarà una mente umana. Perché anche se questi agenti sono incredibili, non sono ancora in grado di portare a termine da soli un’impresa così complessa. Quindi per ora significa che ci sarà una persona.
E quello che sto dicendo è che, e questo è un criterio, non importa la dimensione della tua azienda, deve essere una persona. Ciò non significa che non si possano avere tre persone, ma vedete, è molto diverso. Pensaci: vuoi giocare a scacchi con tre persone e potenzialmente avere tre esperti. Tutti gli esperti sono ugualmente capaci, sono tutti in grado di giocare da soli e possono vedere l’intero problema. Non è frammentato. Non è messo in scena.
Quindi, in un certo senso, se hai tre esperti per decidere la mossa, sono completamente ridondanti. E va bene. Quindi vedi, quello che sto dicendo è che dovrebbe essere una mente sola. In pratica, per una grande azienda, si vuole la ridondanza perché non si vuole, se questa persona è malata, non avere alcun ripiego. Lo capisco. Quello che sto dicendo è che se hai più persone, essenzialmente introdurranno ridondanze. Non si tratta di una divisione del lavoro in cui si taglia e si taglia il problema con le persone che ignorano alcuni aspetti del processo.
Fondamentalmente, affinché funzioni, la ricetta numerica deve essere prodotta da qualcuno che comprenda completamente il processo dall’inizio alla fine. Questo è quello che sto dicendo. E se non lo avete, vi imbatterete in problemi estremamente prevedibili che causeranno quasi sistematicamente la rovina di questo tipo di iniziativa.
Conor Doherty: Bene, in termini di problemi prevedibili che annullano l’iniziativa stessa che stai cercando di realizzare, uno dei più grandi è la spiegabilità. E ancora, entrambi abbiamo sentito personalmente molte, molte, molte volte: “Sembra fantastico. Come posso spiegarlo al mio team, che deve interagire con questo sistema di intelligenza che ora sta progettando decisioni automatizzate e non presidiate? Come posso creare fiducia? Come posso creare una spiegabilità per questo? Che aspetto ha?”
Joannes Vermorel: Quindi, per prima cosa, torniamo a questa persona, una mente. Vedete, chi è responsabile della spiegabilità? La risposta è la persona che ha realizzato la ricetta numerica. Non è un’intelligenza artificiale. Non è un sistema. È una persona. Quindi c’è una persona che può spiegare cosa ha fatto. Quindi, se questa persona non è disponibile per una spiegazione, anche in questo caso hai un problema.
Quindi quello che sto dicendo è che torneremo ad avere una distribuzione di successo. È necessario avere qualcuno che si assuma la proprietà della ricetta numerica. Questo è il primo passo. Quindi la spiegabilità inizia con l’avere qualcuno che spieghi. Vedi, questo è il ruolo.
E poi, questa persona è capace di spiegare? Bene, se questa persona ha una comprensione completa dall’inizio alla fine, anche se in pratica può essere una squadra, quindi alcune parti del lavoro potrebbero essere state svolte da altre persone, se questa persona possiede l’intera ricetta numerica, allora sì, questa persona può spiegare.
Ora quello che vuoi è che questa persona crei anche la strumentazione. Fa parte di ciò che chiamiamo white-boxing. Quindi la persona che realizza la ricetta numerica realizzerà anche tutta la strumentazione di white boxing. Si tratta essenzialmente di tutti i tipi di dashboard…
Conor Doherty: Sì, sì, sì.
Joannes Vermorel: …che strumenta la ricetta numerica. L’intento alla base di questa strumentazione è innanzitutto quello di consentire alla persona che realizza la ricetta numerica di convincersi che la ricetta funziona. Vedi, voglio dire, scrivo una ricetta numerica che genera, diciamo, ordini di acquisto. Come faccio a convincermi che quello che ho appena fatto è corretto? Vedi, ho solo messo delle formule.
Conor Doherty: Questa è letteralmente la domanda che ti faccio.
Joannes Vermorel: Sì. E la prima risposta è: devo creare una serie di indicatori, sì, in euro o dollari, che scompongono ciò che farò e mi dicono semplicemente se quello che otterrò… E ci saranno, ancora una volta, molte euristiche in ciò che voglio guardare.
Quindi cercherò… probabilmente ancora una volta, la boxe bianca è un po’ un’arte. Non vuoi guardare solo le medie. Forse vorrai concentrarti sui prodotti che sono altamente irregolari, alcuni che sono altamente stabili, alcuni che sono in crescita, alcuni che hanno avuto lunghi periodi di esaurimento delle scorte, ecc. Voglio dire, tutto questo è il tipo di strumentazione che stai sovrapponendo alla ricetta numerica per convincerti, come Supply Chain Scientist, che sta effettivamente funzionando come previsto.
E poi questa strumentazione è tipicamente un po’ travolgente perché è letteralmente composta da migliaia di numeri. E in genere vorrai, come Supply Chain Scientist, produrre un riassunto che sia molto più conciso, che verrà presentato ai colleghi, o ancora ai clienti, o ad altre persone, per trasmettere il messaggio in modo convincente, ma in modo molto più conciso. E anche questa è responsabilità della stessa persona, la persona incaricata di elaborare la ricetta numerica.
Conor Doherty: Bene, in quella risposta hai spiegato chi, cosa e come. Quindi chi spiega, cosa spiega, come spiega. Ciò che non è stato trattato è quando inizia la spiegazione. E se ho capito bene nel capitolo 10, è durante la fase di doppia esecuzione. È lì che inizi a vedere per la prima volta, ecco come appare il nuovo sistema di intelligenza rispetto al tuo sistema attuale. Quindi, per favore, espandi.
Joannes Vermorel: Quindi il fatto è che nella ricetta numerica ci sono potenzialmente centinaia di passaggi intermedi di calcolo, ma tutti gli artefatti numerici, quelle cose, sono solo mezzi per raggiungere un fine. L’unica cosa che conta è la fine, perché è per questo che sei lì. È, ancora una volta, proprio come quando, se stai giocando a scacchi, l’unica cosa che conta è la mossa che fai. Tutti i tipi di passaggi intermedi che avevi in mente per prendere questa decisione sono, tipo, sì, ok. In definitiva sono irrilevanti per gli osservatori. L’unica cosa che conta davvero è a cosa stai effettivamente giocando. Ciò determinerà l’esito del gioco.
Sì. Quindi quello che sto dicendo è, e stiamo dicendo un po’ la stessa cosa per la ricetta numerica, che la spiegabilità inizia una volta che si hanno decisioni da spiegare. Perché prima di ciò, tutto è abbastanza discutibile. Puoi spiegare perché hai eseguito tutti questi tipi di preelaborazione, perché stai applicando questa euristica qua e là, perché stai scegliendo questo modello probabilistico per il tempo di consegna piuttosto che un altro. Tutti questi sono solo infiniti tecnicismi.
Fondamentalmente l’unica cosa che merita veramente una spiegazione è il finale, le decisioni che suggerisci. Ed è per questo che la spiegazione, il white-boxing, inizierà solitamente solo alla fine del secondo mese, all’inizio del terzo mese. Una volta, in un’iniziativa di supply chain, lo Supply Chain Scientist inizia effettivamente a prendere decisioni quotidiane.
Fino ad allora, si tratta solo di un lavoro per lo più interno a ciò che lo Supply Chain Scientist sta facendo solo per prendere quelle decisioni. Voglio dire, la tempistica è fondamentalmente di due mesi per mettere in funzione una pipeline di dati e fare in modo che lo Supply Chain Scientist si occupi di questo caos di dati, dandogli un senso e quindi scrivendo molto rapidamente la prima ricetta numerica.
I prossimi due mesi riguarderanno rapide iterazioni per sbarazzarsi di tutte le decisioni folli e mettere a punto davvero, con il feedback dei professionisti, tutti i fattori economici. Perché molte cose richiedono una messa a punto, e questo perché quello che vuoi è assicurarti che i tuoi driver economici riflettano l’intento strategico per la supply chain, per l’azienda.
Quindi, ad esempio, cosa significa effettivamente qualità del servizio? Ancora una volta, uno Supply Chain Scientist può aver fatto alcune congetture e formulato ipotesi, ma alla fine sarà necessario discutere con i professionisti reali per assicurarsi che il quadro economico stia davvero catturando gli interessi a lungo termine dell’azienda. E quelle sono decisioni molto banali su cosa significhi effettivamente qualità del servizio, come sono esattamente le strutture, perché la pressione sul capitale circolante, ecc., Ecc.
Quindi un sacco di cose, iterazioni rapide per due mesi, e poi entro la fine del quarto mese sei pronto a lasciare che la ricetta numerica venga eseguita incustodita per due mesi eseguendo una doppia esecuzione.
Conor Doherty: Già.
Joannes Vermorel: In modo che le persone possano davvero… in modo che la ricetta numerica possa guadagnare la fiducia necessaria affinché le persone possano poi decidere che in produzione si affideranno effettivamente a questo software per guidare il flusso.
Conor Doherty: Beh, hai menzionato la follia e in precedenza avevi detto che ciò che stai cercando sono decisioni a zero follia. Ora, durante quella fase di doppia esecuzione, e durante, diciamo, i primi sei mesi di implementazione, ci saranno presumibilmente momenti, sia con Lokad, sia con chiunque sia, in cui si implementa un sistema di intelligenza, ci saranno presumibilmente momenti in cui le persone che stanno osservando, cercando di creare fiducia in questo sistema, potrebbero osservare una decisione e potrebbe essere indistinguibile per loro da un difetto o, “Oh no, è solo una nuova modo di fare le cose.”
Come fai esattamente, se è così radicalmente diverso dal sistema precedente, come ti aspetti che le persone distinguano tra “È una decisione folle” o “No, sembra semplicemente folle, in realtà è la migliore decisione finanziaria che puoi prendere”?
Joannes Vermorel: No, voglio dire, primo, la prima serie di cose che devi sistemare sono cose davvero pazze. Va bene? Quasi invariabilmente è perché c’è un campo che viene interpretato male, perché, ancora una volta, stiamo parlando di migliaia di tabelle. C’è qualcosa in cui pensi di avere unità, ma in realtà non sono unità, sono chilogrammi o altro. Hai delle cose, è completamente spento.
E molto spesso, ad esempio, il primo lotto servirà solo a verificare con un CFO che stiamo vedendo lo stesso margine lordo, lo stesso valore delle azioni. E non è insolito che al primo tentativo si finisca per avere una discrepanza di un fattore due per qualsiasi motivo. Quindi quello è, questo è come il primo strato di follia.
E poi scopri anche tutto lo shadow IT. Ad esempio, suggerisci una quantità di 110 e poi c’è qualcuno che ti dice: “Oh no, no, no. Non te l’ho detto, ma arriva solo in pallet da 100 unità”. Ok, quindi c’è molto moltiplicatore. Non è stato documentato. SÌ. Ok, dobbiamo tenerne conto. E poi ecc. E poi ci sono persone che alzano la mano e dicono: “Oh, ma no, abbiamo avuto queste riduzioni di prezzo da questo fornitore”.
Conor Doherty: Sì.
Joannes Vermorel: Non è registrato nel sistema. Di solito regolavo semplicemente manualmente in un foglio di calcolo. Ok, dobbiamo sistemarlo, ecc., Ecc. Quindi, per me, la maggior parte dei primi cicli di iterazioni sono in realtà tutte queste cose che sono, direi, la follia facile. È qualcosa in cui c’è un malinteso sui dati, c’è un vincolo che non è modellato correttamente, ecc. Ecc.
E poiché ti fissi un obiettivo, ovvero vogliamo avere un processo decisionale autonomo, è più impegnativo. Perché di solito, storicamente, i praticanti dicevano: “Oh, questo numero, sì, va bene, 110, lo arrotonderemo semplicemente manualmente a 100. Per me va bene.” E Lokad va ben oltre e dice: “No, no, no. Se è coinvolto un moltiplicatore molto, allora la ricetta numerica deve, non è facoltativa, deve fare tutto in modo da non aver bisogno di un passaggio correttivo manuale alla fine.” Non è soddisfacente.
Quindi liberarsi della follia significa rimuovere tutta questa roba. E poi sì, più avanti avremo decisioni che non riflettono la pratica storica. E qui avremo il riflesso delle forze economiche. E di solito, se c’è un disaccordo, sarà: “Sei d’accordo sui dollari che stiamo vedendo?” Lokad suggerisce che, poiché quando guardiamo ai dollari coinvolti in termini di costo di esaurimento delle scorte rispetto al costo di scorte in eccesso, questo è l’equilibrio che vediamo.
E qui avremo un’iterazione su quei driver economici per avere un accordo condiviso. E questo sarà il secondo round di cose in cui dovremo prendere decisioni folli, è che in effetti i driver economici che sono molte congetture inizialmente si rivelano errati, e dobbiamo iterare rapidamente per portarli nel campo di ciò che sembra giusto per l’azienda.
E infine, sì, alla fine avremo decisioni che a volte sorprendono i professionisti, ma arrivano abbastanza tardi perché a questo punto qui, ciò che vediamo, e questo è tipicamente ciò che accade con un sistema ben funzionante, è che romperà i vecchi schemi. Ad esempio, supponiamo che gli ordini per un determinato fornitore siano stati effettuati sempre di lunedì, ma non si tratta di un vero e proprio vincolo.
Conor Doherty: Già.
Joannes Vermorel: Il fornitore può prendere ordini quando vogliamo. E a volte ha senso emettere un ordine giovedì e non aspettare il lunedì successivo, solo perché, beh, prima è, meglio è se vediamo che c’è stato un picco inaspettato di domanda. Perché dovresti iniziare aspettando un paio di giorni mentre sai già che devi passare un ordine? Quindi questo romperà alcune abitudini.
Ma anche qui la domanda sarà: è la mossa giusta dal punto di vista del tasso di rendimento? Questa mossa è più redditizia o no? E questa sarà la portata della condotta del cambiamento, vale a dire, beh, se questo è ovviamente qualcosa di più redditizio, anche se non corrisponde al vecchio modello manuale, allora questa dovrebbe essere la decisione, e basta, e non cercare di aggiungere vincoli fittizi per adattarla.
A proposito, questo è qualcosa che accadeva spesso, direi più di dieci anni fa, a Lokad, perché avevamo meno esperienza di quella che abbiamo adesso. E il tipo di problemi che abbiamo avuto è che spesso alcuni dei nostri potenziali clienti finivano per dire: “Oh, vogliamo… quelle decisioni cambiano un po’ troppo rispetto a quelle che avevamo prima. Quindi introdurremo vincoli morbidi, vincoli che non sono reali”.
Ad esempio, un team potrebbe essere abituato ad avere MOQ flessibili anziché MOQ rigidi, quindi quantità di ordine minime irreali. Il fornitore non li ha. Al magazzino non importa. Non vi è alcun vantaggio economico ad essi associato. Ma per il team acquisti si trattava semplicemente di un modo per passare meno ordini di acquisto, per renderli meno frequenti perché avevano una produttività molto bassa, e quindi era un modo per risparmiare tempo.
Ma ancora una volta, una volta entrati nel territorio dei processi decisionali non presidiati, a meno che non ci sia un guadagno economico legato al raggruppamento degli ordini di acquisto, nel qual caso deve riflettersi nella ricetta numerica, allora non ha senso provare a modellare quei MOQ morbidi che sono completamente inventati e vengono fuori dal nulla.
Conor Doherty: Ascoltandolo mi è venuto in mente un aneddoto. Eri tu, molti anni fa, penso che sia stato durante un evento dal vivo un paio di anni fa, hai menzionato, e ancora una volta non dirò chi, ancora una volta era un cliente, e nel settore aerospaziale, questo è quello che diremo, ma dimostra l’idea che una volta installato un sistema di intelligenza e inizi ad adattarti, devi costruire fiducia, ci saranno decisioni opportunistiche e una sorta di capitalismo che emergono che sono al di fuori dei limiti di ciò che prima pensavi fosse possibile.
E da questo punto di vista potrebbe sembrare folle, ma una volta che si analizza effettivamente l’economia, ha senso. E l’esempio che credo tu abbia fornito è stato: lo macellerò, ma molto, molto semplicemente, un’azienda di MRO aveva un PO consigliato e includeva, ad esempio, l’acquisto di un motore completo. Diciamo solo che compra un motore. Acquista il motore di un A380. E questo è stato segnalato come “È pazzesco. Perché mi stai dicendo di comprare un motore completo?”
E la giustificazione era che il sistema di intelligence aveva scoperto che, in realtà, questi aerei nella zona erano stati appena demoliti. Questo motore viene ora venduto con uno sconto del 50%. Compralo, siediti e puoi venderlo con profitto in sei mesi. Quindi la raccomandazione non era di comprare per usare, ma di comprare per vendere, che è ancora una volta molto, molto diverso dal metodo precedente, del tipo: “Compro ciò di cui ho bisogno per soddisfare questo scopo”. Mentre questa è una prospettiva economica molto più onnicomprensiva. Quindi non è solo: “Oh, spuntavo questa casella per raggiungere questo scopo”. Esistono diversi modi per scuoiare un gatto e guadagnare più soldi.
Joannes Vermorel: Sì, esatto. E succede ancora, ad esempio, nel settore dell’aviazione. Gli aerei vengono smantellati.
Conor Doherty: Esattamente.
Joannes Vermorel: E quindi hai opportunità di acquisto, sì, una parte è… di nuovo, dipende dalla tua situazione, ma se sai di essere un’azienda che non è a corto di liquidità, ricca di liquidità, e questo è già qualcosa, e non sei a corto di spazio di archiviazione, e questa cosa sarà necessaria forse tra un anno, e molto probabilmente quando ne avrai bisogno pagherai un prezzo che sarà quasi garantito molto più alto di adesso, sì, dovresti vederlo.
Oppure può essere un rivenditore dove ricevi una promozione da un fornitore e il prodotto non perderà il suo valore troppo velocemente e avrai semplicemente l’opportunità di venderlo con un margine lordo molto più elevato. Quindi sì, questo è il genere di cose in cui… ma ancora una volta, ecco perché la giustificazione e la spiegabilità economica, il modo in cui basiamo la spiegabilità è nell’economia.
Sai, è “Perché lo fai?” La risposta è: guarda la finanza. E se il modello dice che è molto redditizio e ha senso dal punto di vista economico, allora è la decisione giusta, anche se storicamente non era un’abitudine in azienda.
Conor Doherty: Va bene. Ebbene, l’unica cosa di cui non abbiamo ancora parlato è ciò che accade dopo la distribuzione. Quindi diciamo che sei un’azienda, hai sentito tutto questo, è fantastico, vuoi uscire e comprarti un sistema di intelligenza. Dopo la distribuzione, cosa rimane sotto il controllo di un fornitore e cosa mantengo internamente come cliente? Ad esempio, quali parti di questo processo sono totalmente sotto il mio controllo e cosa è esterno a te?
Joannes Vermorel: Penso che, in primo luogo, la grande lezione dell’implementazione sia quale dovrebbe essere il gioco finale. Sai, se vuoi avere successo, dovresti puntare al processo decisionale incustodito.
Conor Doherty: Mhm.
Joannes Vermorel: Se non lo fai, ti costerà 10 volte di più. Sarà 10 volte più lento e non sarà incrementativo, né capitalistico. Non avrai qualcosa che porti davvero la tua azienda alla fase successiva di redditività per quanto riguarda la tua supply chain. Quindi questa è davvero la lezione concisa.
E non importa se un fornitore è coinvolto o meno, se vuoi farlo internamente o no, ecc. Ancora una volta, questo libro non riguarda Lokad. Questo è: cosa significa schierare? Perché vedete, il tipo di anti-modello che vedo in questo settore è che molte persone direbbero: “Oh, abbiamo fatto questa iniziativa sulla supply chain, e questa, e questa, e questa”, e nessuno di loro ha effettivamente raggiunto questa sorta di fase decisionale incustodita.
Quindi ti ritrovi con dashboard lì che vengono ignorati, un gadget qui che viene ignorato, un pezzo di software là che è solo un pozzo di produttività. Non porta letteralmente molto, considerando la quantità di tempo che devi dedicarci, ecc. Ecc. Quindi penso che l’intuizione chiave dell’implementazione sia che devi avere un obiettivo chiaro indipendentemente da chi è responsabile di cosa. Dovrebbe essere quello di ritrovarsi con qualcosa di cui ti puoi fidare, che genera quotidianamente quelle decisioni inaspettate.
E poi quello che sto dicendo è che è un pezzo di software e deve essere mantenuto. Ancora una volta, nessuno evita la deriva.
Conor Doherty: Sì, esatto.
Joannes Vermorel: Solo perché non abbiamo Skynet AI, quindi non aspettarti che un software, non importa quanto genio ci metti, ecc., si adatti ai cambiamenti strutturali nel tuo mercato.
Conor Doherty: Che succede sempre, a dire il vero.
Joannes Vermorel: Sì, non sempre. Ma vedete, perché ci sono classi di cambiamenti che non sono strutturali. Se si tratta solo del rialzo o del ribasso del mercato, allora il modello di previsione, i modelli di apprendimento automatico, si occuperanno proprio di questo. Il problema è cosa succede quando la tua attività diventa diversa, non solo più o meno la stessa perché sei in crescita o in contrazione, ma quando diventi una bestia completamente diversa.
Basti pensare, ad esempio, a un MRO che vendeva ricambi e ora vende tempo di attività per le ore di volo.
Conor Doherty: Sì. È un modello di business completamente diverso.
Joannes Vermorel: Non vendi nemmeno la stessa cosa.
Conor Doherty: Sì. Ci saranno parti di aerei. Ci saranno meccanismi sovrapposti.
Joannes Vermorel: Ma il tuo modello di business è completamente diverso, così come i tuoi incentivi. Il modello economico della tua attività è completamente diverso. E la stessa cosa è accaduta, ad esempio, dieci anni fa, quando molti rivenditori tradizionali si sono orientati prevalentemente all’e-commerce. Quindi, ovviamente, se fossi prevalentemente di mattoni e malta e ora sei prevalentemente di e-commerce, ancora una volta tutti gli incentivi, il tipo di strategia, tutto sta cambiando. E non si tratta solo di più o meno vendite. È una trasformazione. La natura stessa della tua attività sta cambiando.
Quindi, ancora una volta, quello che sto dicendo è che per tutte le variazioni banali, un fornitore che ha un problema e i tempi di consegna diventano più lenti, tutta la variabilità banale dovrebbe essere gestita senza alcuna modifica dalla ricetta numerica. Quello che sto dicendo è che la tua ricetta numerica non sarà in grado da sola di soddisfare il fatto che, ad esempio, stai introducendo un nuovo ERP.
Conor Doherty: Sì. O che stai cambiando, o stai chiudendo i centri di distribuzione, o tutte queste cose.
Joannes Vermorel: Sì, esatto. Voglio dire, cose che sono molto strutturali. Ecco perché è necessario mantenerlo. È perché hai bisogno di qualcuno che presti attenzione e si assicuri che questo software sia allineato con la realtà del tuo mercato, con la realtà della tua azienda e con la realtà del suo panorama applicativo.
Ed è per questo che chiunque sia responsabile, in Lokad lo chiamiamo Supply Chain Scientist, ma chiunque sia responsabile della realizzazione della ricetta numerica deve poi essere responsabile del mantenimento della ricetta numerica. E la realtà è che puoi anche avere questa persona incaricata del miglioramento continuo della ricetta numerica, perché di solito quando si entra in produzione, il lavoro è appena iniziato.
Hai raggiunto un certo livello di performance economica che di solito rappresenta un enorme passo avanti rispetto allo status quo precedente, che era un processo manuale, ma non significa che sei vicino a qualcosa che possa essere considerato ottimale. Significa solo che stai molto meglio, ma puoi continuare a investire in questo asset per migliorarlo nel tempo.
Conor Doherty: Bene, questo, ancora una volta, non voglio andare, non è nel capitolo 10, ma vale la pena metterli insieme, perché questo è il punto centrale del trattamento della supply chain, in questo caso il software della supply chain, la differenza tra capex e opex. Perché quando si investe in un sistema di intelligenza, non c’è, come hai appena detto, un limite massimo a quanto migliore, quanto più performante, quanto più gratificante dal punto di vista finanziario una decisione può effettivamente diventare. Voglio dire, sono sicuro che ci sia solo una certa somma di denaro al mondo, ma realisticamente, non c’è un limite a quanto potrebbe essere buono. Quindi, se investi adeguatamente in questo, sei almeno orientato nella direzione in cui dovresti andare davvero dal punto di vista finanziario.
Joannes Vermorel: Sì. SÌ. E ancora, diventa, in una certa misura, un’impresa imprenditoriale. Devi decidere se vuoi espandere la gamma di opzioni. Dovresti, ad esempio, prendere decisioni in cui puoi iniziare a dire che i MOQ sono dati, ma la fase successiva sarebbe: i MOQ dovrebbero forse essere rinegoziati? C’è un caso? Si possono guadagnare soldi rinegoziando i MOQ con i fornitori?
Su cosa dovrebbe riguardare la negoziazione? Come dovrebbe essere? Possiamo optare per un prezzo unitario leggermente più alto se possiamo abbassare sostanzialmente il MOQ, o dovremmo fare il contrario, ecc. Ecc.? Quindi, vedete, iniziamo con… un’iniziativa di supply chain inizia con un ambito specifico in termini di decisioni, ma poi col tempo può espandersi fino ad avere sempre più decisioni.
Di solito si inizia, direi, con le decisioni fondamentali di base che governano il flusso, ma poi si possono sovrapporre decisioni che modellano anche il flusso, anche se in genere sono inizialmente date per scontate, solo per mantenere l’iniziativa con i piedi per terra e finire con il fornire, ancora una volta, un processo decisionale automatico rapidamente prima di espandersi in sempre più ambiti.
Conor Doherty: Bene, questo in realtà è il mio pensiero conclusivo, ma segue quello che hai appena detto. Ovviamente, l’obiettivo finale è un processo decisionale automatico e automatizzato, orientato al miglioramento finanziario dell’azienda. Grande. Questo è il prodotto finale di una distribuzione e, ancora una volta, viene continuamente migliorato, ecc. Geniale.
Di cui puoi giudicare il ROI, o che almeno puoi osservare. Ciò significa quindi che nei primi due mesi, in cui ti trovi solo nelle fasi di convalida e smistamento dei dati, non c’è alcun reale valore finanziario in questo? Quindi, in sostanza, senza il prodotto finale, i primi passi non hanno alcun valore? Oppure c’è valore in tutta la catena?
Joannes Vermorel: No. Voglio dire, ancora una volta, finché non sei tu a prendere le decisioni finali, non hai idea, nemmeno la più pallida, se sei sulla strada giusta o meno. Vedi, è per questo che dico che se inizi a inseguire artefatti numerici, non lo sai. Può sembrare molto bello, ma la realtà è che non ne hai la più pallida idea.
Vedi, ancora una volta, pensalo come se ti parlassi degli scacchi. Senza suggerire la mossa finale. Se dico… immagina di giocare a scacchi e io faccio un centinaio di affermazioni su come appare, il tipo di cose che sono posizione forte, posizione debole e quant’altro, e alla fine non dico che tipo di mossa dovremmo fare dopo. Voglio dire, qual è il valore di tutta questa guida? Vedi, è…
E c’è il problema: secondo me, molti fornitori di software aziendale utilizzano questa ambiguità per vendere prodotti da decenni. Avranno tutti i tipi di artefatti numerici. “Ti darò una scorecard per i tuoi fornitori, una scorecard per i prodotti, indicatori per questo, per quello, un gemello digitale che simula questo e quello e quello e quello,” cose infinite. E poi nemmeno un impegno verso una decisione finale su cui possiamo concordare: “Questa cosa genererà profitti o perdite?”
E quello che sto dicendo è che questo non è… e questa è una differenza di apprezzamento. Questo non è un obiettivo lontano. Questo è qualcosa che puoi raggiungere, ancora una volta, nell’ambito dell’esperienza di Lokad, da otto a dieci settimane. E ancora, da otto a dieci settimane con una squadra che in genere è piuttosto limitata. Questa non è un’impresa enorme. Questo è…
E per me questo è l’inizio di tutto. L’implementazione non è… per noi, diciamo che la chiusura dell’implementazione avviene quando l’azienda si fida veramente del processo decisionale non presidiato, che è come gli ultimi due mesi del processo. E penso che l’errore, ed è per questo che dico che molte aziende finiscono per distrarsi, è che invece di prendere direttamente decisioni inaspettate, che pensano siano come un obiettivo super maturo e super remoto, inizieranno a inseguire altri obiettivi.
E loro dicono: “Oh no, non possiamo arrivare ad avere un sistema completamente robotizzato in 10 settimane. Penso che dobbiamo prima stabilire un flusso di lavoro, e ci vorranno 20 settimane.” Vedi, quindi stabilisci un passaggio intermedio che è già due volte più grande e due volte più complesso del tuo gioco finale. Ed è per questo che dico che quegli artefatti numerici, quelle idee provenienti dalla teoria tradizionale della supply chain, finiscono per creare così tanta complessità.
Ecco come ti ritrovi con progetti che durano più anni. E dopo diversi anni, non hai ancora qualcosa che si avvicini a un processo non presidiato, o che si avvicini a qualcosa che sarebbe capex, con una risorsa che sia produttiva e dove i tuoi investimenti diventino accretivi. Ecco perché affermo che deve essere messo all’ordine del giorno perché questo è l’obiettivo numero uno. Questo è ciò da cui dovremmo iniziare e poi migliorare.
Conor Doherty: Sono d’accordo. E beh, l’unica cosa che voglio aggiungere è che voglio usare l’analogia, la similitudine, che hai usato più volte, cioè gli scacchi. E poi dirò semplicemente qualcosa, tu dammi i tuoi pensieri conclusivi.
Ma se il risultato finale di uno schieramento è fare le mosse migliori con i pezzi della scacchiera in modo da poter vincere la partita, quello è l’obiettivo finale, quello è il sistema di intelligenza, le decisioni automatizzate. I primi due mesi, l’ordinamento e la convalida dei dati, in cui costruisci lo schema, lo analizzi, comprendi le connessioni, cioè costruisci effettivamente la scacchiera o ti mostri, come minimo: “Ecco la tua scacchiera, ecco il colore dei quadrati, ecco come appaiono i pezzi. Ecco le mosse che puoi effettivamente fare. Ecco come si muove un cavallo. Ecco cosa fa una torre.”
Non ti do le decisioni perché non ci sono ancora. Ma per me c’è un valore evidente nel sapere: “Oh, ecco come appare una scacchiera. Ecco cosa fanno questi pezzi”.
Joannes Vermorel: Sì. SÌ. Ovviamente. Quindi, se parliamo di ridurre i rischi dell’iniziativa, sì, puoi avere un’idea della progressione. Sì. Ma siamo sinceri: la maggior parte delle iniziative software per la supply chain vengono in genere implementate in più anni. La maggior parte dei fornitori di software vende licenze per le quali è necessario avere un impegno minimo di un anno e, molto spesso, un impegno di quattro anni. Ancora una volta, questo è completamente falso.
Quello che sto dicendo è che dovresti girare per qualcosa che sia molto, molto più breve. SÌ. E 10 settimane non sono tante, lo sai. E ancora, se vuoi avere un’idea, questa entità, anche se è una soluzione interna, sta progredendo verso la soluzione, alla quarta settimana puoi semplicemente chiedere alla persona responsabile, ancora una volta, dico una mente, sì, cosa stai facendo? Cosa stai costruendo? Ha senso per te? La spiegazione che viene data è: “Questa cosa mi porterà alla ricetta completa tra sole sei settimane?”
Non penso che ci sia molto lavoro di preparazione, ma nel grande schema del software aziendale, essere in grado di raggiungere un punto in cui si consegna il prodotto finale in circa 10 settimane, in termini di effetto tunnel, non è poi così tanto. In realtà non è poi così tanto. Forse in futuro, con gli agenti di codifica, ridurremo questo tempo alla metà, ma penso che sia ancora molto veloce.
Sì, il problema, vedi, non vedo molto potenziale… possiamo avere il potenziale per portare, diciamo, 10 settimane di effetto tunnel a cinque con molti agenti di codifica, per accelerare davvero questa parte, ma non è proprio qui la sfida. La sfida è, rispetto allo status quo, optare per qualcosa in cui si ottiene un risultato normalmente in 10 settimane, invece di puntare letteralmente a un processo in cui, in base alla progettazione, si sceglie qualcosa che richiederà 100 settimane.
Vedete, molto spesso quando si tratta di distribuzione, ad esempio, una cosa che sento molto spesso è la gente dire: “Oh sì, oh no, non possiamo permetterci di farlo, ottenere risultati in 10 settimane. Dobbiamo iniziare facendo una RFP” e bam, 18 mesi. Ok, quindi ti sei trasformato… avevi qualcosa in cui potevi ottenere risultati in 10 settimane, e ora hai un anno e mezzo solo per la selezione dei fornitori, e questa selezione dei fornitori ti costa molto di più che fare effettivamente le cose.
E poi ti ritrovi con un venditore che chiede letteralmente di volere un impegno per un anno, se non quattro anni. Ok, questo è falso. Questa è anche la lezione dell’implementazione: quali sono le scale delle tempistiche rilevanti.
Quello che sto dicendo è che si può arrivare ad un processo decisionale non presidiato in 10 settimane. Ci vorranno circa sei mesi per fidarti completamente di questa cosa, perché la maggior parte è in realtà il tempo necessario agli esseri umani per fidarsi di un software. Non ha molto a che fare con la tecnologia. Ecco perché anche se domani avremo agenti di codifica che possono portare questo ritardo, diciamo, di 10 settimane per arrivare davvero a una ricetta numerica che funzioni e che non sia del tutto folle, probabilmente domani potremo comprimerla in cinque, siamo pazzi, tre settimane.
Ci vorranno ancora un paio di mesi perché i professionisti, perché il top management, si fidino di questo software e gli permettano di prendere il controllo di una parte importante dell’azienda. Quindi vedi, alla fine, direi che questa non è la vera battaglia. La vera battaglia è… voglio dire, puoi passare qualche settimana qui. Lokad ci sta lavorando, ma richiede molte tecnologie sofisticate e molte pratiche molto raffinate, perché ogni giorno conta. Vuoi essere davvero, davvero veloce.
Ma molto spesso, Lokad, lavoriamo allo sviluppo delle tecnologie in modo da poter dedicare qualche giorno qua e là. Ma quello che vedo è che vedo molte, molte aziende di cui stiamo discutendo, e iniziano perdendo anni interi cercando cose come, sì, in base alla progettazione, dove vanno per una RFI, un boom, otto mesi, poi 12 mesi, e poi scelgono un primo fornitore che ha detto che consegneranno qualcosa in otto mesi, ma in realtà un anno e mezzo dopo non hanno ancora quasi nulla da mostrare, e certamente non è automatizzato, ecc.
Voglio dire, vedi, immagina questo tipo di situazione super frustrante in cui Lokad… stiamo discutendo con un’azienda, e poi seguono un processo, e ci vogliono cinque anni per avviare finalmente il progetto pilota, che viene poi completato in 10 settimane.
Conor Doherty: Già.
Joannes Vermorel: Vedi, molto spesso è questo il tipo di… e quindi questa potrebbe essere una lezione per l’implementazione. Ciò che sto descrivendo è che per implementare un’iniziativa di supply chain, le aziende devono avere ambizioni che devono essere molto più elevate, in un certo senso. Ancora una volta, il processo decisionale non presidiato.
E non vuoi iniziare con una piccola cosa. Vuoi iniziare con il problema più difficile. Ancora una volta, perché? Perché vuoi eliminare le persone incompetenti, sia che si tratti di una soluzione interna o di un fornitore esterno. Vuoi davvero iniziare con qualcosa che sia veramente difficile come un modo per valutare l’effettiva competenza di chiunque ti aspetti che risolva il problema.
Non iniziare con un problema facile, perché altrimenti potresti ritrovarti con un’entità incompetente, che si tratti di una soluzione interna o di un fornitore esterno, che fa semplicemente un lavoro passabile, ma non ti rendi conto che è un vicolo cieco perché hai scelto qualcosa di facile, francese, che ha a che fare con un piccolo set di dati, ecc. No, no. Una volta che entri in un percorso moderno di supply chain, scegli il problema più difficile, il set di dati più grande di cui disponi e vuoi, in 10 settimane, assicurarti veramente che l’entità che ritieni sarà la tua soluzione a lungo termine sia controllata su questa cosa, che tu sappia che funziona.
Se inizi esaminando questa entità su qualcosa che è facile, non sai se questa persona o entità sarà in grado di fare le cose difficili in seguito. Ancora una volta, se il problema difficile durasse circa tre anni, diresti di no, dobbiamo fare qualcosa di piccolo. Ma quello che sto dicendo qui, e anche questo fa parte dello spiegamento, è che non c’è, per quanto ne so, nessun problema nelle supply chain dove, in 10 settimane, non è possibile avere un processo decisionale automatico che dimostri il fatto che sei in grado di farlo, o che dimostri il fatto che sei incompetente. Questo è tutto.
E il fatto è che se il venditore non riesce a farlo in 10 settimane, non sarà in grado di farlo in 100 settimane. Quindi è inutile continuare a investire. Devi ammettere che non ha funzionato. Devi cambiare fornitore, cambiare il metodo, cambiare qualcosa di più fondamentale. Dargli solo tempo non lo taglierà.
Conor Doherty: Va bene. Bene, Joannes, non ho altre domande. Stiamo andando avanti, credo, da circa un’ora e mezza, ma penso che avremo molte informazioni molto pratiche, che ancora una volta consiglio vivamente alle persone di tornare indietro, leggere il capitolo 10. Ci sono molte cose molto utili. Ma grazie mille per il tuo tempo e grazie mille per la visione.
E sì, se hai domande o vuoi parlare personalmente con me e Joannes, puoi contattarci su LinkedIn o inviarci un’e-mail a contact@lokad.com. Conosci la procedura. E con questo ci vediamo la prossima settimana. Torna al lavoro.
