Aggiorna tutto ogni giorno

Joannes Vermorel

La pratica di supply chain di Lokad è quella di aggiornare tutte le pipeline di estrazione dati - inclusi i forecast - almeno una volta al giorno, anche quando si tratta di calcoli mensili o trimestrali. Per molti professionisti, questa pratica può sembrare controintuitiva. Perché aggiornare i forecast trimestrali più di una volta al trimestre? Cosa succede alle instabilità numeriche? Cosa succede all’attrito coinvolto? Questo va contro la maggior parte delle pratiche consolidate di supply chain, specialmente quelle delle aziende che hanno un processo di S&OP in atto. Eppure, un decennio di esperienza ci ha insegnato che non attenersi a questa pratica di “aggiornare tutto” è la ricetta per un flusso infinito di problemi di produzione. Al centro, questa problematica deve essere affrontata frontalmente - in modo approfondito - attraverso un design versionato e senza stato del software responsabile dell’ottimizzazione predittiva della supply chain. Questo punto viene ripreso in maggior dettaglio nel seguito, ma iniziamo con uno sguardo più attento al problema stesso.

Nel mondo del software aziendale, i problemi / glitch / bug / issue accadono tutto il tempo. Questo è particolarmente vero per le supply chain, dove il panorama applicativo è inevitabilmente una raccolta casuale di pezzi di software (ERP, EDI, MRP, WMS, OMS, ecommerce, ecc.) messi insieme nel corso di decenni di attività: ogni app è una potenziale fonte di problemi in quanto finisce per interagire con molte altre app¹. Ogni modifica apportata a una di queste app ha la possibilità di rompere qualcos’altro altrove, ovvero non solo rompere l’app stessa. Tutte le aziende non sono uguali quando si tratta della gestione del loro panorama applicativo, tuttavia, oltre i 1000 dipendenti, anche le aziende meglio gestite ricevono più di un “glitch” della supply chain causato dal software al giorno.

Pertanto, le aziende di medie-grandi dimensioni si trovano di fronte a un flusso infinito di problemi software da affrontare. La responsabilità di risolvere tali problemi varia. La responsabilità può spettare al dipartimento IT, a un fornitore esterno, a un team operativo, a un fornitore, ecc. Tuttavia, una volta che uno di questi problemi viene “presumibilmente” risolto, sono necessari da 5 a 10 cicli² per assicurarsi che il problema sia veramente risolto. Infatti, la maggior parte dei problemi sono casi limite, che possono presentarsi o meno in ogni momento. Quindi, mentre un problema può sembrare risolto, perché è scomparso dopo l’applicazione di una correzione di qualche tipo, potrebbe non essere ancora il caso. Le supply chain sono sistemi complessi che coinvolgono molti pezzi interdipendenti, alcuni dei quali non sono nemmeno sotto il pieno controllo dell’azienda (ad esempio l’EDI con i fornitori). Le persone falliscono abitualmente nel fornire soluzioni definitive non perché sono pigre o incompetenti, ma semplicemente a causa dell’irriducibile complessità ambientale.

Di conseguenza, se un flusso di dati viene eseguito giornalmente dopo un incidente di produzione, ci vogliono da 5 a 10 giorni per riportarlo alla stabilità. Se il flusso di dati viene eseguito mensilmente, lo stesso processo di risoluzione richiede da 5 a 10 mesi. È il numero di cicli che conta, non il tempo effettivo. Sono necessari più cicli per valutare positivamente che il caso limite sia stato affrontato. A titolo di prova aneddotica, presso Lokad, abbiamo avuto un bug nella pianificazione dei lavori legato al cambio di ora che ha richiesto due anni per essere risolto, proprio perché le condizioni che scatenavano il problema erano così rare - due volte l’anno per fuso orario. Tuttavia, mentre alcuni problemi - come i cambi di ora - sono intrinsecamente poco frequenti, la maggior parte dei problemi può essere riprodotta “a volontà” semplicemente aumentando la frequenza dei “cicli”.

Sfidare costantemente i flussi di dati end-to-end è l’unico modo per garantire che i problemi vengano risolti entro un periodo di tempo ragionevole. L’esecuzione poco frequente porta inevitabilmente allo stato di rottura come stato predefinito del sistema. Le aziende che utilizzano flussi di dati intermittenti - ad esempio quelli trimestrali - finiscono inevitabilmente con grandi burocrazie che sono lì solo per riportare in vita il flusso di dati una volta al trimestre. Peggio ancora, l’intero sistema di solito è così disfunzionale che la burocrazia finisce per passare la maggior parte del trimestre garantendo il “refresh” del prossimo trimestre. Al contrario, i flussi di dati in tempo reale - come il servizio delle pagine web per il sito web aziendale - hanno bisogno di pochissime persone per continuare a funzionare.

Presso Lokad, abbiamo optato per il refresh giornaliero (o più) per pura necessità più di un decennio fa. Da allora, non abbiamo ancora identificato un altro modo per ottenere una buona qualità del servizio dal punto di vista della supply chain. Probabilmente non ce ne sono. L’analisi predittiva è complessa e, quindi, soggetta a “bug” di ogni tipo. I refresh giornalieri garantiscono che i problemi vengano affrontati prontamente anziché persistere per sempre in uno stato di limbo³. A questo proposito, le nostre scoperte sono ben lungi dall’essere originali. Netflix ha introdotto il campo dell’ingegneria del caos lungo linee di pensiero simili: per progettare un sistema robusto, è necessario applicare stress; senza stress, la robustezza non fa mai parte della mentalità ingegneristica. La maggior parte delle aziende software serie - in particolare le GAFAM - ha adottato approcci ancora più rigorosi.

Inoltre, i refresh poco frequenti dei flussi di dati non solo portano a problemi di produzione, dal punto di vista specifico della supply chain, ma mettono anche in evidenza una serie di cattive pratiche e cattive tecnologie.

Quando le previsioni vengono aggiornate raramente, diventa molto tentante aggiustarle manualmente. Infatti, le previsioni si bloccano per la maggior parte del tempo per design, proprio a causa del refresh poco frequente. Pertanto, semplicemente guardando i dati di ieri, il pianificatore della domanda può migliorare una previsione che è stata prodotta dal sistema tre settimane fa. Tuttavia, questo lavoro del pianificatore della domanda non offre alcun valore aggiunto duraturo per l’azienda: non è accrescitivo. Se le formule numeriche che generano le previsioni sono così scadenti da richiedere modifiche manuali, allora quelle formule numeriche devono essere corrette. Se il fornitore del software non può fornire la correzione, allora l’azienda ha bisogno di un fornitore migliore.

Gli aggiornamenti frequenti delle previsioni esacerbano le instabilità numeriche dei modelli statistici sottostanti, ovvero esegui la previsione due volte e ottieni due risultati distinti. Questo è una cosa positiva⁴. I modelli numerici instabili sono dannosi per la supply chain a causa degli effetti a cricchetto: una volta che un ordine di produzione o un ordine di acquisto viene passato, l’azienda è bloccata con le conseguenze di questo ordine. Se un ordine viene passato, è meglio che ci siano motivi migliori rispetto a una questione di instabilità numerica. Più presto l’azienda elimina le formule numeriche instabili dalla sua pratica di supply chain, meglio è. Tentare di oscurare il problema sottostante riducendo la frequenza dell’aggiornamento delle previsioni è assurdo: l’instabilità numerica non scompare perché l’azienda decide di smettere di guardarla. Se le formule numeriche sono così scadenti da non poter mantenere una forte coerenza⁵ da un giorno all’altro, sono necessarie formule numeriche migliori. Ancora una volta, se un fornitore di software si trova nel mezzo del problema e non può fornire una correzione approfondita, allora l’azienda ha bisogno anche di un fornitore migliore.

Gli aggiornamenti giornalieri di tutti i flussi di dati possono sembrare stravaganti in termini di risorse di calcolo. Tuttavia, considerando l’hardware di calcolo moderno e il software adeguatamente progettato, questo costo è ridotto anche quando si considerano formule sofisticate come la previsione probabilistica⁶. Inoltre, le supply chain affrontano routine condizioni eccezionali che richiedono correzioni immediate su larga scala. Se l’azienda non può aggiornare tutte le sue cifre di supply chain in meno di 60 minuti perché ne ha bisogno, allora le emergenze sono garantite rimanere non affrontate di tanto in tanto, causando il caos sul campo. La regola delle 5-10 iterazioni - precedentemente discussa - si applica ancora: una volta scoperta una correzione, sono necessarie più esecuzioni - eventualmente con impostazioni diverse - per acquisire fiducia che questa correzione di emergenza stia funzionando. Pertanto, se il flusso di dati è troppo costoso per essere eseguito “a volontà”, la produzione verrà utilizzata come campo di prova e caos ne seguirà.

Dal punto di vista della produttività, gli aggiornamenti giornalieri eliminano la tolleranza verso configurazioni errate che continuano a generare risultati errati. Di nuovo, è una cosa positiva. Non c’è motivo di essere tolleranti con una ricetta numerica che continua a generare spazzatura. La pianificazione della domanda non è una sorta di creazione artistica che sfida l’analisi numerica. Le ricette numeriche disfunzionali dovrebbero essere trattate come bug del software e corrette di conseguenza. Tuttavia, per apportare una correzione profonda, spesso è necessario pensare molto di più anziché optare per un override manuale ad hoc. Molte aziende si chiedono perché i loro team di supply chain continuano a tornare alle loro tabelle. Accade spesso che le tabelle siano l’unico luogo in cui le correzioni numeriche - che dovrebbero già far parte dei sistemi - vengono effettivamente implementate, proprio perché iterare rapidamente su una tabella non è un problema (a differenza dell’iterazione sul sistema aziendale sottostante).

Tuttavia, gli aggiornamenti giornalieri (o più frequenti) sono solo un aspetto operativo del problema. In termini di design del software, questo approccio deve essere integrato con un primo ingrediente chiave: statelessness (assenza di stato). Un flusso di dati non dovrebbe utilizzare dati precomputati e iniziare sempre da zero dai dati transazionali grezzi. Infatti, ogni singolo bug o glitch è probabile che corrompa i dati precomputati, trattenendo l’azienda per un periodo di tempo indefinito: la logica può essere corretta ma i dati difettosi rimangono. La soluzione è semplice: il flusso di dati non dovrebbe avere alcuno stato, ovvero nessun dato precomputato di alcun tipo. Iniziare da zero garantisce che tutte le correzioni vengano immediatamente sfruttate al massimo.

A sua volta, versioning (versionamento), un altro principio di design del software e il secondo ingrediente di interesse, integra lo statelessness del sistema: più specificamente, il versioning dei dati. Infatti, se il flusso di dati stesso non ha stato, allora, semplicemente combinando la logica del flusso di dati - che esiste come codice sorgente versionato - e i dati di input dovrebbe essere sufficiente per riprodurre esattamente qualsiasi problema riscontrato durante l’esecuzione del flusso di dati. In altre parole, rende i problemi riproducibili. Tuttavia, per raggiungere questo obiettivo è necessario conservare una copia esatta dei dati così come si trovavano durante l’esecuzione del flusso di dati. In altre parole, i dati dovrebbero essere versionati insieme al codice. Il versionamento dei dati garantisce che le correzioni possano essere testate nelle stesse condizioni esatte che hanno causato il problema iniziale.

Lokad è stato progettato attorno a questi principi. Promuoviamo un aggiornamento giornaliero di tutto l’end-to-end. I nostri flussi di dati sono senza stato e versionati - sia la logica che i dati. E la tua azienda?