00:00:00 Introduzione alle complessità della programmazione
00:02:30 Interdipendenza e sfide del livello di servizio in aerospazio
00:06:14 Discussione sul Bill of Materials e sul Bill of Resources
00:13:15 Sfide quotidiane della programmazione e limitazioni umane
00:20:45 Introduzione agli algoritmi per una programmazione efficiente
00:28:30 Misure di emergenza e prezzi AOG in aerospazio
00:36:02 Prospettiva matematica sugli impatti della programmazione
00:43:47 Complessità e vincoli nella programmazione delle attività
00:50:17 Sfruttare la potenza computazionale per l’ottimizzazione della programmazione
00:57:39 Critica alle limitazioni del FIFO nel contesto MRO
01:04:15 Processo decisionale e automazione nella supply chain
Sommario
In una recente intervista, Conor Doherty, Direttore della Comunicazione di Lokad, e Simon Schalit, COO, hanno discusso del grande successo di Lokad nell’ottimizzazione della programmazione per l’aerospazio, in particolare nella produzione di aeromobili e nelle operazioni di MRO. Hanno evidenziato la complessità di coordinare numerose parti interdipendenti, competenze e attrezzature, che i metodi tradizionali faticano a gestire. L’approccio di Lokad passa da una Bill of Materials (BOM) a una Bill of Resources (BOR), considerando tutte le risorse necessarie e la loro variabilità. Utilizzando algoritmi computazionali, Lokad può generare rapidamente soluzioni pratiche, minimizzando il rischio finanziario e i tempi di inattività. Questa integrazione di automazione e intuizioni strategiche umane è cruciale per una programmazione efficiente ed efficace in ambienti complessi.
Sommario Esteso
In una recente intervista presso Lokad, Conor Doherty, Direttore della Comunicazione, si è seduto con Simon Schalit, COO e Head of Supply Chain Science, per approfondire le complessità dell’ottimizzazione della programmazione, in particolare nel settore aerospaziale. La conversazione ha messo in luce un significativo progresso raggiunto da Lokad in questo ambito, che ha profonde implicazioni per la produzione di aeromobili e le operazioni di Manutenzione, Riparazione e Revisione (MRO).
Conor ha iniziato introducendo il contesto, sottolineando la natura intricata della programmazione nelle industrie manifatturiere e di riparazione. Ha fatto notare che gestire una vasta rete di parti, strumenti e personale, che può cambiare in modo imprevedibile, è una sfida formidabile. Simon Schalit ha poi approfondito questa complessità utilizzando l’esempio dell’aeronautica, dove il compito di produrre o riparare qualcosa di altrettanto complesso come un motore per aeromobili comporta il coordinamento di numerose parti, competenze e attrezzature. Ha ribadito che, a differenza di altri segmenti della supply chain in cui le decisioni possono essere prese in modo indipendente, in MRO e nella produzione, specialmente in aeronautica, ogni elemento è interdipendente. La mancanza anche di una singola parte su cento può arrestare l’intero processo, rendendo inutili le altre 99 parti.
Simon ha spiegato che questa interdipendenza richiede un passaggio dalla tradizionale prospettiva della Bill of Materials (BOM) a un approccio più completo della Bill of Resources (BOR). Mentre una BOM elenca le parti necessarie per un compito, una BOR include tutte le risorse necessarie—parti, competenze e attrezzature. Questa visione olistica è fondamentale perché tiene conto della disponibilità e della variabilità di ciascuna risorsa. Ad esempio, le parti possono essere soggette alla variabilità del lead time, le competenze dipendono dalla disponibilità del personale, e le attrezzature potrebbero essere in uso o in riparazione.
Conor e Simon hanno discusso le implicazioni pratiche di questo approccio. In un contesto MRO tradizionale, la pianificazione quotidiana spesso prevede l’aggiustamento manuale dei programmi in base alla disponibilità di parti e personale. Questo metodo, sebbene comune, è inefficiente e soggetto ad errori a causa dei limiti della mente umana nel gestire variabili complesse e interdipendenti. Simon ha sottolineato che anche piccoli cambiamenti in un programma possono avere conseguenze a catena e imprevedibili, rendendo difficile ottenere un piano ottimale.
La conversazione si è quindi spostata sul ruolo degli algoritmi computazionali nell’affrontare queste sfide. Simon ha spiegato che l’algoritmo di Lokad può generare rapidamente una soluzione sufficientemente buona considerando lo stato attuale di tutte le risorse. Questa capacità è vitale nell’industria aeronautica, dove ogni minuto di inattività è costoso. La forza dell’algoritmo risiede nella sua capacità di simulare vari “what if” scenarios, aiutando le aziende a comprendere le implicazioni finanziarie di diverse decisioni e misure d’emergenza.
Conor ha sottolineato che l’obiettivo non è trovare una soluzione perfetta, ma una pratica che minimizzi il rischio finanziario e rifletta lo stato attuale delle risorse. Simon ha concordato, osservando che la capacità di generare rapidamente una nuova sequenza di eventi basata sulle risorse disponibili è cruciale per minimizzare l’impatto finanziario.
La discussione ha toccato anche le limitazioni delle euristiche tradizionali come il FIFO (First In, First Out). Pur essendo semplice e veloce, il FIFO non tiene conto della diversa importanza finanziaria e strategica dei vari compiti. Simon ha sostenuto che è necessario un approccio più sfumato, che consideri il contesto specifico e i vincoli di ciascun compito, per una programmazione efficace.
In conclusione, Simon e Conor hanno sottolineato l’importanza di integrare strumenti computazionali con intuizioni strategiche umane. Sebbene gli esseri umani eccellano nella pianificazione strategica, non sono attrezzati per gestire le complessità granulari della programmazione in operazioni su larga scala. Sfruttando gli algoritmi, le aziende possono prendere decisioni di programmazione più efficienti e finanziariamente solide.
Simon ha concluso affermando che il futuro del decision-making della supply chain risiede nell’automazione, in particolare in ambienti complessi come l’aerospazio. Ha sottolineato che l’approccio di Lokad combina la potenza computazionale necessaria per un decision-making a livelli granulari con la supervisione strategica fornita da esperti umani, offrendo una soluzione robusta alle sfide dell’ottimizzazione della programmazione nelle industrie della produzione e della riparazione.
Trascrizione Completa
Conor Doherty: Benvenuti a Lokad. La programmazione è uno dei concetti più complicati nelle industrie manifatturiere e di riparazione. Questo perché bisogna gestire un’enorme rete di parti, strumenti e persone, e tale rete può cambiare in un attimo.
L’ospite di oggi, Simon Schalit, è COO e Head of Supply Chain Science di Lokad, ed è venuto in studio per discutere di come il suo team abbia affrontato questo problema. Ora, lui e io abbiamo parlato principalmente della programmazione nell’aerospazio, ma tutto ciò di cui abbiamo discusso oggi si applica altrettanto a qualsiasi industria manifatturiera. Come sempre, se vi piace ciò che sentite, mettete mi piace a questo video, iscrivetevi al canale YouTube e seguiteci su LinkedIn. Detto ciò, vi presento la conversazione di oggi con Simon Schalit.
Conor Doherty: Il tema di oggi è stato l’ottimizzazione della programmazione e il lavoro approfondito svolto dal team di supply chain science sul raggiungimento di un progresso in questo campo. Quindi, prima di entrare nel dettaglio, dal tuo punto di vista, e puoi prendere l’aerospazio come esempio concreto per le persone, qual è esattamente il problema della programmazione che il nostro team di ingegneri, il nostro team di supply chain scientists, sta cercando di risolvere? Qual è il problema?
Simon Schalit: Ok, prendiamo ad esempio l’aeronautica, MRO o la produzione. Quando si cerca di produrre o riparare qualcosa della portata di un aereo o di una grande parte di un aereo, diciamo un motore, ad esempio, ci si trova di fronte a qualcosa di incredibilmente complesso. Complesso, ovviamente, da un punto di vista ingegneristico, ma anche per il semplice fatto che bisogna mettere insieme il numero schiacciante di parti, competenze e attrezzature necessarie per eseguire il compito assegnato, sia esso la produzione o la riparazione.
In molti segmenti della supply chain, quando si prendono decisioni, si potrebbe sostenere che le decisioni possano essere considerate indipendenti senza che questo modo di pensare causi troppi danni. Ad esempio, se decido di acquistare l’articolo A e l’articolo A è esaurito, sarò comunque in grado di vendere l’articolo B o l’articolo C. Ci potrebbero essere delle conseguenze, ma in generale è così. Quindi pensare in modo indipendente non è troppo dannoso.
Quando si tratta di MRO o produzione, specialmente nell’ambiente aeronautico, ciò diventa completamente falso. Se vuoi riparare, diciamo, un motore e hai bisogno di 100 parti per poter riparare quel motore, avere 99 di quelle parti e mancarne una non ti porterà più avanti di non averle affatto.
Conor Doherty: Cosa intendi?
Simon Schalit: Perché il motore non può ancora—l’aereo non può ancora volare anche se ti manca solo una di quelle parti. Anche se ne hai 99, l’aereo non può volare. Quindi ti trovi di fronte a un problema in cui non dovresti cercare di avere ogni parte singolarmente; devi avere tutte le parti e, in effetti, tutte le risorse disponibili nel posto giusto e al momento giusto. Altrimenti, semplicemente non puoi fare nulla.
And in effetti, questo cambia completamente il problema. Perché anche se dicessi, “Ok, ho un 99% di service level,” cosa che la maggior parte delle persone in molte aziende definirebbe come un buon, elevato service level, se consideri il 99% di service level in modo indipendente, è piuttosto alto. Ma se dici, “Ok, ho bisogno di 100 parti, e per ciascuna di queste 100 parti avrò un service level del 99% individualmente”, quindi una possibilità del 99% su 100 che siano presenti nel momento in cui mi aspetto, in effetti, se si considerassero queste probabilità come indipendenti, il service level combinato di questo caso molto semplice sarebbe in realtà estremamente basso. Sarebbe inferiore al 40%.
Ciò significa che anche con un service level del 99%, se hai bisogno che 100 parti o risorse diverse siano disponibili, la possibilità di non riuscire a effettuare la riparazione o la fase di produzione non è affatto un caso fortuito; diventa la norma. Ha una probabilità superiore al 50% di verificarsi. Questo ti colloca in un mondo estremamente diverso dal consueto processo decisionale della supply chain. Ti mette in un mondo in cui, anche con service levels molto elevati, l’insorgere di problemi è la regola e non l’eccezione. Quindi devi costruire le tue supply chain e il tuo processo decisionale della supply chain in modo da essere resiliente a questo fenomeno. Quindi si tratta di un argomento completamente diverso.
Conor Doherty: Ok, grazie. E hai menzionato alcuni termini, e vorrei chiarirli un po’, perché hai parlato di parti e poi hai iniziato a parlare di risorse. Suppongo che non li stessi usando come sinonimi; stavi tracciando una distinzione. Potresti fornire un po’ più di chiarezza? Quando parli di risorse, non ti riferisci esclusivamente alle parti fisiche. Ancora, se stiamo parlando di riparare un motore o un APU, ci sono parti fisiche coinvolte nel processo, sì. Ma quando parli di risorse, di cosa stai parlando?
Simon Schalit: Beh, quando si parla di riparare o produrre qualcosa, si fa riferimento al concetto di bill of material. Una bill of material è fondamentalmente l’elenco delle parti che devi assemblare per completare qualcosa—un aereo, un motore, qualsiasi cosa. Il problema è che questo è solo una parte del problema. Avrai bisogno di altri tipi di risorse per poter effettivamente portare a termine il compito.
Principalmente, quelle risorse saranno competenze che provengono dalle persone e attrezzature che non si consumano necessariamente ma che si utilizzano. E molto spesso, possono essere piuttosto costose, e non ne hai un numero infinito, come ad esempio un banco di prova, se parliamo di aeronautica. Quindi non basta avere tutte le parti disponibili. Devi assicurarti di avere l’attrezzatura—banco di prova, gru, qualsiasi altra cosa—e il personale per operare e assemblare le parti in modo sicuro e tecnicamente valido.
Quindi, quando parliamo del problema di quelle bill of materials e di come vengono utilizzate, preferiamo riferirci al concetto di bill of resources, che è più accurato nel senso che abbraccia il problema nella sua interezza anziché solo i materiali.
Conor Doherty: Ok, ora che hai reintrodotto il termine bill of materials, di cui presumo chiunque stia guardando questo probabilmente sia a conoscenza, la prospettiva della bill of resources—puoi contrapporre concretamente i due concetti? Per esempio, prendi una decisione, delinea una decisione per, diciamo, un MRO utilizzando un aereo per semplificare, ed spiega come una prospettiva BOM si manifesterebbe in tempo reale rispetto a una più sofisticata prospettiva della bill of resources.
Simon Schalit: Ok, per favore. Quindi, di solito, l’attività MRO o di produzione segue diverse fasi che devono avvenire in un determinato ordine. Alcune cose devono essere fatte prima, altre dopo. Ma ogni fase può essere definita con la propria bill of resources, ovvero l’elenco delle parti necessarie per effettuare quel particolare step di riparazione, l’elenco delle competenze—not people, perché potresti avere persone diverse con competenze differenti—l’elenco delle competenze necessarie per eseguire il compito, e l’elenco delle attrezzature.
Le parti solitamente saranno consumate nel senso che verranno montate. Le competenze non saranno consumate allo stesso modo, nel senso che le persone le possiedono comunque, ma saranno consumate in termini di tempo per un certo periodo. Lo stesso vale per l’attrezzatura. Tutti e tre questi elementi—parti, competenze e attrezzature—presentano il loro insieme di variabilità.
Le variabilità per le parti solitamente riguardano se esse siano disponibili in magazzino o meno, una modalità semplice di dirlo. Dietro questo si cela il concetto di variabilità dei tempi di consegna, soprattutto, e naturalmente, se l’ordine viene effettuato al momento giusto o meno, ma di solito si parla principalmente di variabilità dei tempi di consegna.
La variabilità legata all’abilità deriva dal fatto che la persona sia presente e disponibile, ma soprattutto presente per svolgere il compito. Quindi comporta tutte le variabilità intrinseche agli esseri umani in generale, come ad esempio se la persona è malata, se la pianificazione è stata eseguita correttamente, se la persona possiede la competenza valida da un punto di vista legale, ecc. E in realtà, questo tipo di variabilità è ancora più difficile da comprendere e controllare rispetto al tempo di consegna, perché non puoi costringere qualcuno a non ammalarsi. Se la persona è malata, lo è.
E naturalmente, c’è la disponibilità dell’attrezzatura, che viene utilizzata per un determinato periodo di tempo, ma che ovviamente ha minori probabilità di ammalarsi. L’equivalente sarebbe che essa sia guasta, in riparazione, o forse ancora impegnata in un altro motore o aeromobile in riparazione e non ancora liberata da quel compito specifico. Quindi, direi che sono tre, e ciascuna viene con le proprie variabilità, ed è proprio questo che rende il problema difficile.
Conor Doherty: Bene, a proposito, prendiamo un esempio concreto e, ancora una volta, possiamo confrontare come un tradizionale MRO con una prospettiva di bill of materials e, diciamo, magari uno dei nostri clienti con una prospettiva di bill of resources, affronterebbe uno scenario. Stiamo cercando di riparare, credo sia un A380. Penso sia un A380. Lunedì mattina, dobbiamo riparare il motore A. Arriviamo e hai una prospettiva BOM. Quindi, ancora una volta, una prospettiva BOM fisica e deterministica. So quante parti servono—100 parti per riparare quel motore. Arrivi lunedì mattina, abbiamo tutte le parti. Simon e Connor sono assenti. Ad esempio, Simon sta insegnando qualcosa, mentre Connor si è fatto male alla schiena sollevando qualcosa di pesante, quindi non sono disponibili.
Quindi hai tutte le parti, per quella parte dell’equazione sei fortunato. Hai tutte le 100 parti. Hai in realtà anche tutti gli strumenti—magari servono 20 strumenti, diciamo 20. Quindi hai 100 parti, hai i 20 strumenti, ma ti mancano le competenze critiche. E non tutte le competenze, ma solo quella di Simon per fissare una certa parte, per la quale serve una licenza, e quella di Connor per supervisionare. Cosa succede allora in termini di decisioni se adotti una prospettiva di bill of resources?
Simon Schalit: Non è il fatto di avere la bill of resources a fare la differenza principale. La bill of resources ti permetterà di combinare le diverse incertezze che esistono nei tre segmenti che ho appena descritto e comprendere quanto sia probabile che si verifichi un incidente come quello da te descritto. Devi organizzarti in modo da poter far fronte a questo tipo di problema.
Ma prendiamo il tuo esempio. Supponiamo di avere tutte le parti, tutta l’attrezzatura, ma le persone non ci sono, il che è in realtà abbastanza frequente per molte ragioni. Attualmente, il modo in cui la gente affronta la situazione è che ogni mattina nell’officina, supponiamo di parlare di un grande laboratorio che si occupa di riparazioni, ogni mattina e forse anche due volte al giorno, i responsabili delle diverse linee di riparazione si riuniscono per cercare di ricostruire il programma della giornata.
Vedranno cosa manca, che siano parti o persone, e diranno: “Va bene, il piano che avevamo per oggi è sparito. Non esiste più. Quindi, qual è il minimo di cambiamenti che possiamo apportare, dato che siamo solo esseri umani e non abbiamo molto tempo? Qual è il minimo di modifiche che possiamo fare al programma affinché sia realizzabile e non si discosti troppo dall’obiettivo previsto per la giornata?”
Il problema è che questa logica, questo tipo di approccio a minimo impegno, non funziona davvero bene. È ciò che la gente fa perché non ha necessariamente altro a disposizione, ma non funziona molto bene per una ragione molto semplice.
Modificare leggermente il piano deriva dall’idea che in una situazione semplice quei cambiamenti minimi avranno conseguenze minime, perché esiste una sorta di continuità o linearità tra la quantità di conseguenze e la quantità di cambiamenti apportati. C’è questa sorta di presupposto: quindi si fanno cambiamenti minimi perché non sono troppo complessi e si spera che non abbiano molte conseguenze.
Il problema sorge quando si parla di programmazione, cioè di riorganizzare potenzialmente decine, se non centinaia, di diverse attività, ognuna con i propri vincoli e la propria variabilità associata. Quindi, l’idea che ci sia un legame tra la portata del cambiamento e l’entità dell’impatto è, diciamo, in qualche modo illusoria, purtroppo.
Tuttavia, la mente umana è limitata perché non riesce nemmeno a stimare l’impatto generale, per cui cercherà di limitarsi a cambiamenti minimi sperando che l’impatto sia ridotto. Ma l’unica cosa di cui si può essere assolutamente certi è che, anche se il piano iniziale era buono o addirittura vicino a quello ottimale, nel momento in cui apporti modifiche non hai alcuna garanzia che il nuovo piano sia anche lontanamente vicino a un nuovo piano ottimale. È semplicemente un piano che funziona.
Conor Doherty: Lasciami cercare di riassumertelo e correggimi se ho frainteso, perché è un punto davvero interessante. Prima ho parlato di Simon e Connor che erano assenti e che si rendeva necessario lavorare sul motore A. Supponiamo che Joannis, con penna e carta o con un foglio Excel, dica: “Beh, Max, il nostro ingegnere che è anche il nostro videomaker dietro le quinte, in realtà possiede le stesse competenze di Simon e Connor. Lo tolgo da quello che doveva fare. Sì, può lavorare sul motore A. Problema risolto.” Quindi, sposto una sola persona, semplice.
Ma è possibile che fare ciò introduca conseguenze sproporzionate? Perché, con lo stesso tempo che Max impiega a lavorare sul motore A, potrebbe aver svolto le attività 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 sui motori B, C, D, E e F, e queste, in combinazione, generano un ritorno finanziario maggiore rispetto al lavorare solo sul motore A, per esempio?
Simon Schalit: Sì, l’esempio è assolutamente corretto. Ciò che le persone devono tenere a mente è che tali compiti devono essere eseguiti in un certo ordine. Quindi, se un compito non viene svolto, il problema non è solo che quel compito non sia stato eseguito, ma che tutto ciò che avevi pianificato, che doveva accadere successivamente alla conclusione del compito A, non potrà verificarsi.
Quindi, se togli qualcuno da un’altra attività e gli dici: “Fai il compito A,” potrai eseguire anche i compiti B, C e D. Ma il problema è che quella persona doveva fare qualcos’altro, che non verrà fatto e che comporterà conseguenze a catena. Si ha una sorta di effetto farfalla, e ciò che è molto difficile per un essere umano è stabilire quale effetto farfalla abbia il maggiore impatto finanziario e quale opzione scegliere. È davvero difficile, anche in un ambiente molto piccolo e non così complesso. Se lo porti alla scala di una grande attività MRO, pensare di poter fare qualcosa che sia vicino all’ottimale è semplicemente ridicolo.
Conor Doherty: Voglio essere molto attento a come veniamo percepiti qui, perché il messaggio non è che le persone siano stupide. La mia esperienza, avendo partecipato a conferenze MRO, è che ci troviamo di fronte a persone molto intelligenti e di grande talento. È semplicemente irragionevole aspettarsi che un ingegnere molto intelligente o un intero gruppo di persone altrettanto brillanti riesca a rielaborare una sequenza di eventi incredibilmente intricata, in cui ogni fase ha impatti finanziari, più volte al giorno, ogni singolo giorno, per un’azienda aeronautica multimiliardaria. Questa è un’ipotesi irragionevole. La tua proposta, invece, non è quella di fare ciò, ma di fare qualcos’altro?
Simon Schalit: Sì, hai ragione. Va detto che la gente ha fatto così per una valida ragione. Innanzitutto, perché non c’era alternativa, e anche perché si basavano sull’assunzione che, sì, ovviamente, i problemi capitano. Ci sono situazioni in cui bisogna riorganizzare tutto, ma non succede troppo spesso. Per il resto della supply chain in generale, sì, non succede molto spesso. Ma in questo contesto particolare, accade ogni giorno. Questo è il problema. Per questo motivo gli esseri umani saranno sopraffatti, non perché siano incompetenti o stupidi, ma semplicemente perché non sono predisposti a gestire questo problema.
Quindi, come proponiamo di fare diversamente è, ovviamente, far sì che una macchina, un computer, lo faccia, cioè tramite un algoritmo. Non è una novità. Questo tipo di problema organizzativo è stato affrontato dai computer da tempo, soprattutto con l’aumento della potenza computazionale nelle ultime decadi. Il problema qui è che ti trovi in un contesto incredibilmente complesso, come ho detto, con una sequenza di eventi molto intricata. Ogni evento viene accompagnato da una complessa bill of resources, dipendenze e incertezze.
I metodi tradizionali per affrontare questo problema di solito non funzionano in modo soddisfacente e, ancor più importante, non sono abbastanza veloci. Ed è qui che risiede il problema. Se chiedi a un computer di risolvere un problema del genere e se costruisci un algoritmo sufficientemente buono, probabilmente otterrai una buona soluzione se dedichi abbastanza tempo e potenza computazionale a quel problema specifico. Sarà difficile; molte soluzioni non arrivano nemmeno a questo punto, ma si può farcela.
Il problema è che la situazione è lunedì mattina. L’officina deve iniziare a lavorare, se non lo sta già, perché è, immaginiamo, lunedì mattina. Devono riorganizzare tutto perché mancano certe parti e mancano certe persone. Non hai a disposizione alcune ore per risolvere il problema; hai solo pochi minuti perché devi darti da fare. Ogni minuto conta, e in aeronautica ogni minuto è costoso. Quindi devi risolvere il problema in pochi secondi o, al massimo, in pochi minuti, ed è una questione molto urgente.
Ed è qui che diventa davvero difficile. Quindi, ciò che abbiamo sviluppato è un algoritmo che ci permetterà di risolvere il problema in modo sufficientemente buono. È impossibile dimostrare che la tua soluzione sarà ottimale, ma almeno sarà una soluzione molto valida rispetto ad altre che potresti trovare, e potrai provare che, parlando in termini finanziari, otterrai una soluzione molto buona in pochi minuti. I nostri clienti solitamente possono essere piuttosto esigenti sul numero di minuti a disposizione per risolvere il problema.
L’idea alla base di tutto ciò, non entrerò nei dettagli della matematica e dei computer, ma riguarda l’utilizzo della capacità computazionale e il fatto che ciò che stai cercando non è la soluzione in sé, ma come strutturare il risolutore che sarà in grado di risolvere il problema in pochi minuti. In realtà, si tratta di una sorta di meta-problema. Sarebbe molto interessante discuterne per ore, ma ora non abbiamo quel tempo. Il punto cruciale è che non vuoi trovare la soluzione; vuoi trovare il risolutore che troverà la soluzione basandosi sulla soluzione ideale precedente che hai avuto il tempo di calcolare durante la notte o quando avevi più tempo.
Conor Doherty: Dal punto di vista del cliente, vogliono la soluzione, vogliono che la nuova sequenza venga generata il più rapidamente possibile. Voglio solo approfondire un punto che hai sollevato, perché, dal punto di vista della gestione delle aspettative in questa conversazione, non stiamo dicendo che avrai sempre, in sei minuti, credo, o in tre-sei minuti, la possibilità di rigenerare un enorme programma di operazioni per, diciamo, riparare un motore, per riflettere il nuovo stato della bill of resources.
In termini di gestione delle aspettative su cosa significhi, non stai dicendo che questa sia perfetta, che se avessi riflettuto per 10 anni non ne avresti trovata una migliore. È semplicemente che questa è una buona soluzione che riflette ciò che è disponibile adesso e gestisce il rischio finanziario.
Simon Schalit: Sì.
Conor Doherty: Eseguire questa nuova sequenza di eventi con queste risorse disponibili si traduce in un risultato finanziario specifico.
Simon Schalit: Sì, esatto, è proprio quello che facciamo e ciò che anche tu desideri, perché è qualcosa di necessario. Non vuoi solo rigenerare un programma, ma vuoi anche dare ai tuoi clienti la possibilità di modificare la realtà in un certo modo. È ciò che si definirebbe uno scenario “what if”.
Per esempio, se una persona è assente oggi, saremo in ritardo. Posso trovare una buona soluzione, ma la buona soluzione trovata lascia comunque una persona in meno, quindi non sarà migliore di quella che avevo con quella persona in più. Tutto risulterà leggermente in ritardo. Quindi, voglio dare al mio cliente la possibilità di generare uno scenario in cui lui dice: “Va bene, oggi mi è mancata una persona. Devo recuperare il tempo perso. Forse potrei aggiungere qualcuno al mio programma regolare domani oppure aprire per un giorno aggiuntivo in cui l’officina avrebbe dovuto essere chiusa.” Voglio sapere cosa succederebbe, quanto tempo guadagnerei se, per esempio, aprissi un sabato, dove normalmente l’officina potrebbe essere chiusa.
Quindi, vuoi che lo strumento sia in grado, ovviamente, di simulare ciò che sta realmente accadendo, perché probabilmente è ciò che farai oggi, ma vuoi anche che il cliente possa simulare uno scenario “what if” in cui integra le misure d’emergenza che potrebbe adottare subito. Ma è importante che comprenda quali sarebbero le conseguenze di queste misure d’emergenza, perché esse si chiamano così per una ragione. Non ricorri a questo tipo di soluzioni per la tua attività regolare, perché costano denaro. Di solito hanno un costo elevato. Ecco perché non le usi regolarmente.
Conor Doherty: Ad esempio, come i prezzi AOG per reperire parti all’ultimo momento.
Simon Schalit: Esattamente, è come se ti mancasse una parte e questo causasse un arresto del lavoro, il prezzo che saresti disposto a pagare per quella parte in particolare può essere alle stelle. È qualcosa che, ovviamente, è vero nell’industria aeronautica ed è ben noto anche nell’industria automobilistica, per esempio. Sono pronti a spedire parti mancanti a un prezzo astronomico.
Conor Doherty: Perché il costo finanziario di non spedire affatto è ancora maggiore.
Simon Schalit: Esatto. Quindi, quello che vuoi fare è dare al cliente una stima del guadagno in modo che possa tenerlo in considerazione quando valuta il costo di quella misura d’emergenza e prendere una decisione informata su se ricorrere a quella misura d’emergenza abbia effettivamente senso dal punto di vista finanziario. Devono saperlo per prendere la decisione e documentarla per difenderla all’interno dell’azienda. Perché quando ricorri a misure d’emergenza costose, dovrai rendere conto di ciò al tuo capo o all’azienda in generale.
Conor Doherty: Ancora, voglio essere molto attento al linguaggio qui. Hai menzionato scenari d’emergenza “what if”, ma in precedenza nella conversazione hai parlato della percezione delle emergenze e di come essa sia in qualche modo distorta. La comprensione da parte delle persone di ciò che costituisce un’emergenza è forse un po’ ingenua. Quindi, potresti spiegarli separatamente?
Quando parliamo di produrre o riparare un APU o di fabbricare un APU, parliamo di un gran numero di parti, molti strumenti e tante persone. Se si tratta di fabbricare un intero aereo, ancor di più—mezzo milione di parti, centinaia di strumenti, forse centinaia di ingegneri e tecnici. Quindi, quando parliamo di emergenze, come nel caso in cui manchi un elemento della distinta delle risorse, dato l’entità delle risorse di cui si parla, è “emergenza” il termine corretto per indicare qualcosa che accade sicuramente abbastanza frequentemente o che è almeno molto probabile?
Simon Schalit: Sì, beh, c’è una cosa che dobbiamo comprendere. Se parliamo di aeronautica, l’aeronautica è per sua natura o per progetto un’industria molto avversa al rischio per ottimi motivi. Il problema è che, nella supply chain, ogni decisione che prendi, senza eccezione, è una scommessa. Scommetti che il futuro non sarà troppo diverso da quello che ti aspetti. Piazzi le tue scommesse basandoti su questa ipotesi.
Questa scommessa può essere rischiosa o meno, e potremmo entrare in questa metafora della scommessa in cui vuoi agire più come il casinò piuttosto che come il giocatore. Ma in sostanza, la parte importante è che, per quanto riguarda la programmazione, nel contesto di cui parlavamo, la scommessa che stai piazzando sul futuro è estremamente complessa. L’idea che il futuro si disponga esattamente come te lo aspettavi o come era stato pianificato non è realistica. Non succederà come lo pianifichi.
Conor Doherty: Scusami per l’interruzione, ma solo perché è un punto valido. Quando dici, per esempio, per riparare un motore, ho bisogno di 100 parti. Lunedì mattina ho bisogno di 100 parti, ho bisogno di 10 strumenti e ho bisogno di cinque ingegneri. Questo è il futuro per cui sto pianificando. Quanto è probabile? Per favore, prosegui da qui.
Simon Schalit: Sì, pianificherai tutte le tue risorse basandoti sull’ipotesi che quelle risorse saranno presenti. Hai pianificato una sequenza di eventi che in teoria dovrebbe verificarsi. Ma dato il mero numero, questa sorta di maledizione della dimensionalità, non accadrà. Abbiamo preso l’esempio delle 100 parti con un livello di servizio del 99%. Vedi già che la probabilità che tutto sia effettivamente presente, nel posto giusto e al momento giusto simultaneamente, è inferiore al 40%. Quindi, non avverrà.
Il problema è che, poiché le aziende sono avverse al rischio, il riflesso che hanno è dire: “Ok, se un livello di servizio del 99% non è abbastanza alto, aumenterò ancora.” Quando si parla di parti, quello che si intende con un livello di servizio del 99% è che effettuerai ordini affinché le parti arrivino prima, ancora prima, giusto per compensare la variabilità nei tempi di consegna—il tempo che impiega effettivamente l’arrivo delle parti. Perché quella è l’incertezza principale che riguardano le parti.
Quindi, aumenterai sempre di più il margine di sicurezza fino a passare dal 99% al 99,9% di livello di servizio. Tuttavia, se hai bisogno di 100 parti o di più di 100 parti, l’importo di denaro necessario per raggiungere un livello di servizio combinato soddisfacente è semplicemente qualcosa che non puoi permetterti. Quindi, l’approccio tradizionale di dire, “Spingerò il livello di servizio al punto in cui mi sentirò a mio agio e che garantirà l’attuazione del piano che ho elaborato,” non è necessariamente un modo valido di operare.
Ovviamente, avrai bisogno di livelli di servizio elevati perché si tratta di aeronautica. Ma ciò di cui avrai bisogno è un modo per modificare il tuo piano nel modo più efficiente ed economicamente vantaggioso che garantisca che il nuovo piano da elaborare al volo sia il migliore che tu possa ideare sulla base delle informazioni a tua disposizione. In effetti, questo fa una differenza enorme rispetto al semplice sperare che le cose vadano secondo i piani e al fatto che ogni mattina persone senza gli strumenti corretti cerchino di elaborare un nuovo piano.
Conor Doherty: Quindi, ancora una volta, per riassumere, l’argomento che stai facendo è che, se lo consideri—e non entreremo troppo nei dettagli matematici—da una prospettiva puramente matematica, quando tracci o semplicemente elenchi tutte le parti fisiche di cui hai bisogno, tutti gli strumenti fisici necessari, e poi tutte le competenze astratte o il personale necessario a completare una sequenza di azioni, e poi prendi in considerazione anche che nessuna di queste cose accade in isolamento. Voglio dire, non ripari un motore e poi queste persone vanno a casa. Lavorano su qualcos’altro. C’è un’interconnessione in tutte queste sequenze.
Quindi, quando arrivi lunedì mattina, matematicamente parlando, la probabilità che qualcosa manchi è molto, molto più alta di quanto le persone si rendano conto o vogliano ammettere. Le conseguenze finanziarie di ciò, come letteralmente ogni singolo secondo che passi cercando di capire cosa fare dopo, dove andare, chi è presente, cosa è disponibile, ecc., lavorando, inviando fogli Excel—tutto ciò ha conseguenze finanziarie immediate e significative. Ho capito correttamente?
Simon Schalit: Corretto, e aggiungerei anche che è il tempo perso a riorganizzare il piano e il tempo perso seguendo un nuovo piano che è tutt’altro che ottimale. Di solito, questa seconda parte non è così dolorosa perché è un po’ più difficile da quantificare, ma è in realtà molto, molto costosa. Devi immaginare che, nel caso delle attività di MRO o di produzione aeronautica, ogni minuto conta, perché ogni minuto rappresenta un segmento o una frazione di un ulteriore aereo che potrebbe uscire e volare, sia che si tratti di un nuovo aereo sia che generi denaro. Quindi, anche un piccolo aumento nell’efficienza della tua capacità di elaborare nuovi piani al volo può avere un impatto tremendo dal punto di vista finanziario.
Conor Doherty: Mi viene in mente anche, e lo hai appena detto, ho preso appunti. Abbiamo parlato in gran parte delle implicazioni dirette, come il fatto immediato che se manca una persona, quella parte del motore non viene riparata. Ma indirettamente, c’è l’effetto a catena non solo sugli altri processi, perché nella realtà, queste cose non avvengono in vuoto. Passi da un processo all’altro, o una parte viene poi integrata in un’altra. I sottoassiemi della BOM completano le parti più grandi. Ma ci sono anche obblighi contrattuali da considerare. Voglio dire, se non riesci a rimettere un aereo in circolazione, a seconda se sei un MRO, ciò comporta conseguenze finanziarie.
Quindi, c’è quello diretto, c’è quello indiretto, ma ancora una volta, il punto chiave è che ci sono centinaia se non migliaia di decisioni che concorrono a un programma ottimale o molto buono, e ciascuna di queste decisioni ha un impatto finanziario. E quando vanno male perché qualcosa manca, ed è apparentemente molto probabile, anche se non accade domani, è comunque probabile che accada il giorno dopo o il giorno seguente. Ciò comporta dei costi finanziari.
Simon Schalit: Sì, e in realtà, per essere molto pratici, nella vita quotidiana ciò che ho osservato in quelle aziende è che l’esercizio di elaborare un nuovo piano è così dispendioso in termini di tempo e così difficile che l’officina si concentra solo sul problema noto al momento. Non hanno tempo per nient’altro. Quindi, il giorno successivo esistono nuovi problemi, come vecchi problemi che non sono ancora stati risolti, uniti a nuovi problemi.
Ma se osservi i dettagli dei nuovi problemi, metà di essi avresti potuto conoscerli il giorno prima. Avrebbero potuto essere previsti. Ma in pratica, ciò che abbiamo osservato è che le persone sono così concentrate sul problema da risolvere oggi da non avere necessariamente il tempo o la capacità intellettuale per anticipare i problemi dei giorni successivi, il che può far crescere i problemi col tempo e solitamente porta a ritardi accumulati nelle attività MRO o di produzione. E, ovviamente, alle violazioni degli obblighi contrattuali.
Conor Doherty: Ancora, questo è un punto davvero valido, perché, proprio come i processi non avvengono in isolamento, le esternalità o semplicemente le conseguenze delle azioni non si manifestano in un vuoto. Quindi, ancora una volta, l’accumulo dell’arretrato e, per estensione, l’accumulo dell’impatto finanziario continua in background, che tu sia disposto o meno ad ammetterlo, a pensarci o ad agire in merito. Oppure, anche se agisci e pensi, “Ho risolto quel problema”, in background, dato che c’è una variabile che hai trascurato, perché, ancora, sono umano, tu sei umano, siamo umani, il registro, il conto, il contatore sta ancora girando in background. Potresti non accorgerti nemmeno che sta accadendo.
Okay, bene, andiamo avanti un po’, perché in termini dei dettagli dell’ottimizzazione della programmazione, come la vediamo noi, abbiamo parlato degli aspetti dell’inventario delle parti e degli strumenti. Quando parliamo delle competenze, stai semplicemente—lascia che riformuli la domanda—le decisioni, così come le presentiamo ai clienti, consistono semplicemente, per esempio, nel prendere quella parte, quello strumento, e mandare Simon là a lavorare su quel motore, oppure c’è una sfumatura in più?
Simon Schalit: Beh, sarà un po’ più sfumato nel senso che di solito comporta una serie intera di complessità. Fondamentalmente, l’output apparirebbe come un insieme di allocazioni consigliate per materiali, parti e attrezzature nell’ambito di una pianificazione. Questa parte deve essere assegnata a quell’aereo o a quel motore. Questa attrezzatura particolare deve essere utilizzata da quell’aereo o da quel motore durante questo intervallo di tempo. E poi questa persona in particolare, che possiede questa specifica competenza, deve essere assegnata a quel motore o a quell’aereo per questo periodo. Il sistema deve garantire che non vengano violati nessuno dei vincoli stabiliti per ciascuna delle attività che intendiamo pianificare.
In termini di complessità, se parli di parti, di solito è abbastanza semplice. La parte viene assegnata a un’attività perché fa parte della distinta dei materiali, e va bene così. Ovviamente, è necessario avere le parti, cosa non sempre garantita. Di solito, puoi sostituirle ogni volta che è possibile, ma decidi quando allocarle e cerchi di farlo al minuto ultimo per evitare riallocazioni. Ma quella è la parte semplice. Stranamente, è quella su cui le persone si concentrano di più, perché è quella sulla quale solitamente ritengono di avere maggior controllo.
Ma per l’allocazione di personale e attrezzature, di solito esse si integrano, diventando un po’ più complesse, soprattutto perché ci sono attività che richiedono non solo una competenza o le competenze di una sola persona, ma magari competenze differenti da persone diverse contemporaneamente, sia per motivi tecnici che per ragioni di sicurezza. Ad esempio, far funzionare una gru mentre si sposta un motore al centro dell’officina richiede almeno due persone, solo per motivi di sicurezza. Una che sa operare la gru e l’altra che è lì semplicemente per assicurarsi che non si stia facendo nulla di sbagliato e che il percorso sia libero. Al minimo, è così che avviene.
Quindi, non puoi considerare tutte quelle risorse, soprattutto quelle qualificate, come entità completamente indipendenti. Sarebbe troppo facile. Più spesso, devi considerarle come soggette a vincoli, dove devono essere disponibili nello stesso luogo, allo stesso tempo, per lo stesso compito. E hai la possibilità che le attività possano essere svolte da una, due, tre, quattro persone contemporaneamente, oppure non contemporaneamente, in sequenza o non in sequenza. Una vasta gamma di combinazioni in cui l’algoritmo deve semplicemente trovare la migliore soluzione valida, considerando che mentre utilizzi quelle competenze, esse non sono impiegate altrove.
Questo rende il problema piuttosto difficile. Per eseguire il compito A, se hai bisogno di due persone, esse devono essere disponibili ad un certo orario. Quindi, qualunque cosa stessero facendo, devono terminare approssimativamente nello stesso momento, affinché entrambe siano disponibili per passare a quel compito specifico. E questo non è affatto banale, perché più spesso una di esse aspetta che l’altra finisca, e ciò costa molto. Quindi, vuoi evitare ciò il più possibile. Ogni minuto conta. Quelle competenze valgono un sacco di denaro.
Conor Doherty: Okay, e ancora, per chi ascolta potrebbe sembrare magia. Ne sono consapevole, perché quello che sembri dire è che ora Lokad si concentra sulla programmazione. Abbiamo già discusso dell’inventario, abbiamo altri materiali in merito. Possiamo dirti: prendi questo, assicurati che quella parte e quello strumento siano in quel luogo a quell’ora, e che Simon vada lì e lavori per questo intervallo di tempo, iniziando a quest’ora e terminando a quest’altra. È questo che stai dicendo?
Simon Schalit: Sì, è praticamente quanto stiamo dicendo. Ma in realtà, se consideri il problema nel suo insieme, ci sono, direi, due elementi che, separatamente, potrebbero essere considerati tali e che non sono facili e, anzi, sono quasi impossibili da eseguire correttamente da un essere umano senza l’ausilio del computer. C’è la parte delle scommesse, ovvero capire le conseguenze delle tue scommesse, e c’è la parte della disposizione, della riorganizzazione, della pianificazione.
Sul versante delle scommesse, si tratta di comprendere la strategia e rendere le questioni legate al denaro. Un’immagine molto semplice che ho usato poco fa: gli esseri umani, quando devono piazzare quelle scommesse, si affidano alla propria conoscenza, al proprio intuito. In sostanza, agiranno come un giocatore in un casinò, con tutti i pregiudizi ed le emozioni che questo comporta. Se di recente hanno avuto un problema con una parte che ha causato un grande disservizio, è probabile che si trovino a sovraacquistare, a comprare in eccesso, a mettere un buffer molto ampio su quella parte perché sono stati “bruciati” da quella specifica esperienza. Questo è un pregiudizio.
La macchina, se calibrata correttamente, seguirà una strategia esattamente come il casinò. Stessa scommessa, stesso gioco. Chi segue una strategia vince; è il casinò. Chi non segue una strategia, o almeno non una strategia documentata e coerente, è il giocatore, è l’essere umano. Nel nostro caso, il casinò vince. Il casinò vince sempre. Non è magia. È capire che esiste, anche se difficile da calcolare, una strategia ottimale, e che non si vuole deviare da questa strategia ottimale.
Quindi, in questa parte particolare, non è magia. Si tratta di assicurarsi di estrarre dalle menti delle persone, da coloro che sono veramente bravi in questo settore, le idee strategiche chiave e tradurle in una strategia all’interno del computer. È quello che fa un supply chain scientist. Non è magia. È un processo coerente di costruzione della strategia.
La riorganizzazione, non è magia. Ancora una volta, si tratta di una combinazione di potenza computazionale e alcuni trucchi matematici. La potenza computazionale è accessibile alla maggior parte delle persone, soprattutto se si utilizza il cloud computing come noi facciamo. Ma non siamo gli unici; sicuramente, non lo siamo. Molte persone hanno accesso a una potenza computazionale ancora maggiore, molto più di quanto ne abbiamo noi. Ma usata correttamente, puoi risolvere quel problema insieme a qualche trucco.
Tuttavia, quei trucchi non sono puramente matematici. Sono una combinazione di aspetti matematici fondamentali, ma applicati in un modo che tiene conto della forma reale del problema. Sì, potresti inserirlo in un risolutore generale molto ampio, lasciarlo funzionare per ore, e sperare di ottenere una buona soluzione alla fine. Probabilmente, non funzionerà, o anche se funziona, ci vorrà molto troppo tempo. Quello che desideri è assicurarti che l’approccio matematico sia adattato al tipo di vincoli, al tipo di struttura specifica per quel particolare genere di problema.
Conor Doherty: Beh, quello che volevo approfondire è un punto chiave, che ancora una volta si collega a un messaggio più ampio che ritengo debba essere sottolineato su ciò che Lokad cerca di fare. Hai detto che potresti avere, per così dire, un operatore presso l’azienda cliente che ovviamente ha una grande capacità d’analisi. L’obiettivo è ottenere quell’informazione e integrarla nella strategia, diciamo nel processo decisionale, che è l’algoritmo che produce le decisioni.
Il motivo di ciò è che, certo, penso che tu sia d’accordo, e correggimi se sbaglio, su una singola scelta o decisione, una persona veramente abile potrebbe essere buona o addirittura migliore di un algoritmo, di un processo decisionale automatizzato. Tuttavia, quando parliamo della scala di complessità nel riparare un intero aereo o una flotta di aerei, possibilmente centinaia di migliaia di pezzi, centinaia di strumenti, centinaia di persone, l’idea che una persona possa prendere tutte quelle decisioni su larga scala meglio di un processo decisionale automatizzato è semplicemente irragionevole. Questo è l’aggettivo che uso: irragionevole.
Simon Schalit: Una persona o addirittura un team.
Conor Doherty: Un team, esattamente.
Simon Schalit: La mente umana non è fatta per questo. E colgo l’occasione per affrontare una sorta di dualità tra computer e umano. Se dovessi usare la parola d’ordine AI, è semplicemente uno strumento. È uno strumento, nient’altro. La vera sfida quando costruiamo quegli algoritmi è estrarre la conoscenza dalla mente umana. Quello che mi piace dire è che la mente umana è estremamente abile nella strategia, ma a livello tattico, a un livello più granulare, si perde.
Si perde a causa del semplice numero delle cose, e si perde perché oltre un certo numero di variabili, specialmente se non sono continue, non lineari, potresti essere il miglior matematico del mondo, ma non risolverai tutto questo mentalmente. Non è possibile. Non è una questione di chi sei; gli umani semplicemente non riescono a farlo. È oltre ciò che puoi fare senza lo strumento. Ma gli umani sono incredibilmente bravi a strategizzare a un livello superiore, comprendendo le conseguenze finanziarie delle cose.
In definitiva, sono loro a decidere in quale direzione l’azienda debba andare, quanto sia importante per l’azienda essere in grado di servire i propri clienti in un certo modo con una certa affidabilità rispetto al costo. Hanno un’idea di quali siano quei numeri. Il problema è che non sanno di avere un’idea. Hanno delle sensazioni istintive, e quelle sensazioni li hanno portati a dire: “Voglio alti livelli di servizio.” Se dovessi chiedere loro perché desiderano alti livelli di servizio, risponderanno che è importante.
Una delle cose principali che un supply chain scientist deve fare è far loro spiegare perché è importante. Se è importante, significa che ritieni che il costo dell’esaurimento scorte sia elevato. Andiamo oltre. Cosa significa, elevato in termini di dollari, di euro, dal punto di vista finanziario? Una volta estratta quella conoscenza, puoi utilizzarla per implementare la strategia, la strategia ottimale di cui parlavo, ottimizzata nel senso che prenderà la decisione ottimale considerando le informazioni strategiche che le sono state fornite.
In questo caso, produrrà la sequenza di azioni e l’allocazione delle risorse che è più adatta a raggiungere gli obiettivi indicati a livello strategico. È ciò che fa il computer. Non inventa nulla. Non rende gli umani inutili, ma farà ciò che la mente umana non può fare.
Conor Doherty: Transizione perfetta. Quindi, a proposito, in passato ho partecipato a conferenze e fiere MRO. Uno dei modelli che usiamo per i nostri poster in uno stand è una mano appena sopra un cestino della carta, un cesto, e che vi lascia cadere pezzi di carta accartocciata. Su questi fogli compaiono certi termini, e li adattiamo a seconda che si tratti di un evento retail o aerospaziale. In questo evento, abbiamo avuto FIFO e Min-Max, Safety Stock sui pezzi di carta che cadevano nel cestino. È una cosa provocatoria.
Ovviamente, la gente si avvicina, e se la capiscono, commenta. Ma funziona anche perché se in realtà non si sa che siamo in qualche modo critici rispetto a questi concetti, ci si avvicina e dice: “Oh, hey, sono interessato a questo. Puoi dirci di più?”
Simon Schalit: Sì.
Conor Doherty: Ora, il fatto è che a molta gente piace davvero FIFO. È quello di cui abbiamo sentito parlare di più. Quando parli, hai menzionato in precedenza l’avere soluzioni in emergenza che funzionano velocemente. È estremamente importante lavorare in fretta. Quindi, la domanda, se dovessi rappresentare qualcuno che semplicemente non è d’accordo con te, potrebbe dire: “Beh, ho già un euristico. Ho già un risolutore generale per il processo decisionale, un risolutore molto semplice che funziona super veloce in tempo reale, ed è FIFO, first in, first out.” Cosa risponderesti a ciò?
Simon Schalit: Beh, FIFO è sicuramente un algoritmo che esiste da molto tempo. È, infatti, direi, il nostro più grande concorrente sul mercato. Il problema con FIFO è che, sì, funziona super velocemente, e sì, è molto facile da comprendere per le persone perché, voglio dire, first in, first out, cosa c’è di più semplice? Inoltre, il vantaggio è che sembra avere senso. Se qualcosa è arrivato per primo, vuoi gestirlo per primo perché probabilmente è quello che ha maggiori probabilità di essere in ritardo se, considerando tutto, tutto è uguale e dovrebbe richiedere lo stesso tempo.
Tuttavia, come per molti concetti datati nella supply chain, non necessariamente cattivi, solo un po’ superati, si basa su alcune supposizioni. La prima supposizione è che ti trovi in un ambiente semplice. Cosa intendo con ciò? Se lavori utilizzando FIFO, è first in, first out. La supposizione è che ogni motore, ogni aereo su cui lavori, se parliamo ancora di aeronautica, sia perfettamente intercambiabile. Nel senso che sono finanziariamente gli stessi dal punto di vista dell’azienda, dal punto di vista della strategia, sono semplicemente gli stessi. Dal punto di vista della gestione del rischio, sono tutti uguali. Essere in ritardo su uno o sull’altro è esattamente la stessa cosa.
È vero nella realtà? Assolutamente no. Hai clienti diversi, hai diversi tipi di aerei, quindi non sarà la stessa cosa. Un giorno di ritardo su uno di essi non è la stessa cosa di un giorno di ritardo su un altro. Ma anche se lo fosse, immaginiamo un mondo perfetto in cui si effettua assistenza a un solo tipo di aereo con un solo cliente.
Il problema è che gli sforzi che dovrai mettere per risolvere il problema che affronti su un aereo o un motore non sono necessariamente gli stessi e probabilmente non corrispondono agli sforzi necessari per risolvere il problema su un altro. Anche se i motori sono gli stessi, il listino riparazioni, le cose che devi fare su quei motori, non sono gli stessi. Anche se lo fossero, le parti rotte in quei due non sono esattamente identiche. Questa è parte dell’incertezza che hai quando apri un motore. Scopri cosa è rotto, cosa è corroso.
Conor Doherty: Non sapevo che ci sarebbe stato.
Simon Schalit: Esattamente. Quindi dire, “Oh, mi concentrerò sul motore A perché è arrivato prima di quello B,” non ha davvero senso. Probabilmente, anche se dedicassi tutto il tuo impegno al motore A, ci vorrebbe molto tempo per risolvere effettivamente il problema. Mentre, forse, sul motore B, potresti risolverlo molto rapidamente.
Sì, potresti dire, “Sto ancora facendo progressi sul motore A,” ma se finisci il motore B, esce dal tuo laboratorio. Quindi hai spazio perché arrivi un altro motore, hai spazio perché questo motore venga ispezionato e per sapere in anticipo cosa ti servirà per esso. Hai assistito uno dei tuoi clienti, quindi potenzialmente otterrai dei soldi per quello prima, il che ti aiuterà a finanziare il resto delle tue operazioni.
Quindi avrai conseguenze legate all’ordine in cui fai le cose. Ogni minuto investito nelle diverse attività non ha lo stesso valore perché non genera le stesse conseguenze. Non sblocca lo stesso potenziale.
FIFO è completamente indifferente a tutto ciò. FIFO è una visione semplicistica delle tue catene di riparazione o di produzione. Non fraintendermi, non è male. Tra tutte le soluzioni che potresti usare senza gli strumenti appropriati, probabilmente è la migliore o almeno una delle migliori. Ma se ci pensi, non vuoi semplificare eccessivamente il problema, specialmente considerando le conseguenze finanziarie in gioco.
Conor Doherty: Certamente. E ancora, abbiamo preso un esempio deliberatamente banale solo per illustrare il punto. Ma ovviamente, non si tratta solo di due processi. Riparare il motore A e riparare il motore B sono due calendari o sequenze separate. Di solito ce ne sono molti di più. Quindi devi tabulare nella tua testa o con un foglio Excel o semplicemente usando il risolutore. Devi tener conto di molto di più. E il punto è che i costi sono non lineari. Non sono necessariamente gli stessi, e devi esserne consapevole o avere qualcosa che ti dia un’idea delle implicazioni finanziarie del lavorare su questo rispetto a quello.
Simon Schalit: E, ovviamente, c’è il semplice problema di allocazione in cui hai il motore A e il motore B, e entrambi hanno bisogno della stessa parte. Se il motore A è più vecchio, per impostazione predefinita, assegneresti la parte al motore A. Ma se per qualche motivo il motore A ha bisogno di cinque parti diverse che mancano, mentre il motore B ha bisogno solo di quella parte, c’è un ottimo motivo per cui la parte dovrebbe andare al motore B. Perché è l’unica cosa che manca. Può andare, mentre la parte unica che hai, se la metti sul motore A, non serve a nulla perché mancano ancora altre quattro parti. FIFO è indifferente a ciò.
Conor Doherty: Beh, ancora una volta, e voglio sottolineare rapidamente un punto che è stato fatto in precedenza. Quando possibile, penso che sia importante segnalare le nostre posizioni. E sicuramente non l’ho mai detto pubblicamente o privatamente: applicare FIFO non è stupido o ingenuo o qualcosa del genere. In molti casi, ancora una volta, è la mente umana ad affrontare il problema e spesso utilizzando i migliori strumenti disponibili. In assenza di strumenti indubbiamente superiori, le persone tendono a optare per ciò che è almeno comprensibile e che a prima vista sembra funzionare.
La mia comprensione, basata su questa lunga conversazione, è che la diagnosi del valore di base è spesso molto limitata in termini di portata finanziaria. Ciò che intendo è: “Oh beh, il motore è fuori, quello è valore finanziario che è stato aggiunto, o valore è stato aggiunto, ed è fatta quella cosa.” E una intuizione chiave che sembri spiegare oggi è che esistono sia considerazioni finanziarie dirette che indirette maggiori che, ad essere onesti, la mente umana è semplicemente cieca per natura. Hai parlato della natura del design. Per natura, semplicemente non può comprendere su larga scala le spesso non linearità e le conseguenze finanziarie esterne del processo decisionale. Il che ci riporta all’uso dell’automazione, all’utilizzo di un supply chain scientist capace di estrarre queste informazioni e convertirle in un motore decisionale ripetibile.
Simon Schalit: Sì, beh, la nostra posizione su questo è abbastanza chiara. Il futuro del processo decisionale nella supply chain riguarda tutta l’automazione. E più i contesti sono complessi, più diventa importante. Per noi, è semplicemente la direzione verso cui stiamo andando.
Conor Doherty: Per concludere, per le persone che stanno ascoltando e hanno sentito delle affermazioni incredibili, incredibilmente precise e con conseguenze su ciò che è possibile fare, a qualcuno che ancora pensa, “Simon, quello che stai descrivendo è inverosimile, è magico, è impossibile,” qual è la tua risposta di 30 secondi a questo come pensiero conclusivo?
Simon Schalit: Beh, è già in atto. È qualcosa che sta accadendo da qualche anno, ed è la direzione verso cui la supply chain in generale si sta muovendo. Automazione su scala e automazione a livelli sempre più bassi di granularità. Perché? Perché abbiamo la potenza computazionale e, grazie a supply chain scientists, il concetto e il ruolo dei supply chain scientists. Abbiamo la capacità di portare i dati e le informazioni necessarie, informazioni strategiche e finanziarie, all’algoritmo, al computer, affinché la strategia applicata su larga scala sia quella progettata dagli umani e possa essere ottimizzata verso quell’obiettivo.
Conor Doherty: Hai anche menzionato prima, in risposta a una domanda molto simile, in effetti, non ricordo più qual’era il contesto, ma hai detto che su questo argomento l’incredulità delle persone o il non credere che sia possibile è sorprendente, considerando che questo è effettivamente ciò che le persone stanno cercando di fare in tempo reale. Quindi ogni persona, ancora una volta, un decisore chiave, un interlocutore chiave, in una mattina di lunedì deve rivedere il programma perché Simon e Conor sono assenti. Quello che stanno facendo in tempo reale è ciò che stiamo descrivendo usando un computer, usando algoritmi. Sono sostanzialmente lo stesso processo. Stai cercando una soluzione ottimizzata. Quindi non è magia, è solo l’intervento tecnologico su quel processo.
Simon Schalit: Sì, lo stanno facendo a mano. Lo stanno facendo in modo molto doloroso, per così dire. Doloroso per loro e, in una certa misura, doloroso per l’azienda, perché non riescono ad arrivare a una soluzione ottimizzata, non per mancanza di abilità, ma per mancanza di strumenti. E quindi ciò che stiamo portando è lo strumento necessario per sostituire effettivamente l’elemento umano carente a un livello granulare e mantenere l’elemento umano ideale, ovvero il livello strategico. Quindi combiniamo il livello granulare del computer e il livello strategico dell’umano.
Conor Doherty: Simon, ti ringrazio molto per il tuo tempo. Non ho ulteriori domande. È stato un piacere.
Simon Schalit: Anche per me. Grazie ancora per il tuo tempo e grazie a tutti per aver guardato.
