Rinfrescare tutto ogni giorno

Joannes Vermorel

La supply chain practice di Lokad consiste nel rinfrescare tutte le pipeline di estrazione dati - previsioni incluse - almeno una volta al giorno, anche quando si tratta di calcoli mensili o trimestrali. Per molti operatori, questa pratica può sembrare controintuitiva. Perché rinfrescare le previsioni trimestrali più di una volta per trimestre? Che dire delle instabilità numeriche? Che dire dell’attrito coinvolto? Questo va contro la maggior parte delle consolidate pratiche di supply chain, soprattutto in quelle aziende che dispongono di un processo S&OP in atto. Eppure, un decennio di esperienza ci ha insegnato che non aderire a questa pratica del “rinfrescare tutto” è la ricetta per un flusso ininterrotto di problemi di produzione. In sostanza, questo problema va affrontato frontalmente - in profondità - attraverso un design stateless versionato del software responsabile dell’ottimizzazione predittiva della supply chain.

Nel mondo del enterprise software, i problemi / glitch / bug / issue accadono continuamente. Questo è particolarmente vero per le supply chain, dove il landscape applicativo è invariabilmente una collezione frammentaria di pezzi software (ERP, EDI, MRP, WMS, OMS, ecommerce, ecc.) messa 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 qualsiasi di queste app può rompere qualcosa altrove, ossia non solo rompere l’app stessa. Le aziende non sono tutte uguali per quanto riguarda la gestione del loro landscape applicativo; tuttavia, oltre i 1000 dipendenti, anche le aziende meglio gestite subiscono più di un “glitch” di supply chain guidato dal software al giorno.

Pertanto, le aziende di dimensioni medio-grandi fronteggiano un flusso ininterrotto di problemi software da risolvere. La responsabilità per la risoluzione di tali problemi varia. Può spettare al reparto IT, ad un fornitore terzo, ad un team operativo, ad un fornitore, ecc. Eppure, una volta che uno di questi problemi viene “supposto” risolto, occorrono 5-10 round² per assicurarsi che il problema sia veramente risolto. Infatti, la maggior parte dei problemi sono casi limite, che possono o meno presentarsi in ogni momento. Quindi, mentre un problema può apparire risolto perché è scomparso dopo l’applicazione di una qualche correzione, ciò potrebbe non essere ancora il caso. Le supply chain sono sistemi complessi che coinvolgono molti elementi interdipendenti, alcuni dei quali non sono nemmeno completamente sotto il controllo dell’azienda (ad esempio, l’EDI con i fornitori). Le persone falliscono abitualmente nel fornire correzioni definitive non perché siano pigre o incompetenti, ma semplicemente a causa della complessità ambientale irreducibile.

Di conseguenza, se una pipeline di estrazione dati viene eseguita quotidianamente dopo un incidente di produzione, occorrono 5-10 giorni per riportarla alla stabilità. Se la pipeline viene eseguita mensilmente, lo stesso processo di risoluzione richiede 5-10 mesi. È il numero di round a contare, non il tempo effettivo. Servono più round per verificare positivamente che il caso limite sia stato affrontato. A titolo aneddotico, da Lokad abbiamo avuto un bug nella pianificazione dei job legato al cambio dell’ora che ha impiegato due anni per essere risolto, proprio perché le condizioni innescanti del problema erano così rare - due volte l’anno per fuso orario. Eppure, mentre alcuni problemi - come i cambi d’ora - sono intrinsecamente poco frequenti, la maggior parte dei problemi può essere riprodotta “a volontà” semplicemente aumentando la frequenza dei “round”.

Mettere costantemente alla prova le pipeline di estrazione dati end-to-end è l’unico modo per garantire che i problemi vengano risolti in un arco di tempo ragionevole. Un’esecuzione poco frequente porta invariabilmente a uno stato di rottura predefinito del sistema. Le aziende che gestiscono pipeline di estrazione dati intermittenti - per esempio trimestrali - finiscono inevitabilmente per avere grandi burocrazie che esistono solo per rianimare la pipeline una volta per trimestre. Peggio ancora, il tutto risulta di solito così disfunzionale che la burocrazia finisce per trascorrere la maggior parte del trimestre assicurando il “rinfresco” del trimestre successivo. Al contrario, le pipeline in tempo reale - come quelle che servono le pagine web del sito aziendale - necessitano a malapena dell’intervento di qualcuno per funzionare.

Da Lokad, abbiamo optato per rinfreschi quotidiani (o anche più frequenti) per pura necessità più di un decennio fa. Da allora, non abbiamo ancora identificato nessun altro modo per ottenere un livello di servizio decente da una prospettiva di supply chain. Probabilmente non ce ne sono. L’analisi predittiva è complessa e, pertanto, soggetta a “bug” di ogni genere. I rinfreschi quotidiani garantiscono che i problemi vengano affrontati tempestivamente invece di persistere indefinitamente in un limbo³. In questo senso, le nostre scoperte sono tutt’altro che originali. Netflix ha inaugurato l’intero campo del chaos engineering seguendo simili linee di pensiero: per ingegnerizzare un sistema robusto, è necessario applicare stress; senza stress, la robustezza non si radica nella mentalità ingegneristica. La maggior parte delle aziende software serie - in particolare le GAFAM - ha adottato varianti ancora più stringenti di questo approccio.

Inoltre, i rinfreschi poco frequenti delle pipeline di estrazione dati non solo portano a problemi di produzione da una specifica prospettiva di supply chain, ma evidenziano anche una serie di cattive pratiche e tecnologie inadeguate.

Quando le previsioni vengono rinfrescate poco frequentemente, diventa molto allettante modificarle manualmente. In effetti, le previsioni si bloccano per la maggior parte del tempo per design, proprio a causa del rinfresco poco frequente. Così, osservando semplicemente i dati di ieri, il Supply Chain Scientist può migliorare una previsione che il sistema aveva prodotto tre settimane fa. Eppure, questo intervento del Supply Chain Scientist non apporta alcun valore aggiunto duraturo per l’azienda: non è accrescente. Se le ricette numeriche che generano le previsioni sono così scadenti da richiedere correzioni manuali, allora quelle ricette numeriche devono essere corrette. Se il fornitore software non riesce a fornire la soluzione, allora l’azienda ha bisogno di un fornitore migliore.

I rinfreschi frequenti delle previsioni aggravano le instabilità numeriche dei modelli statistici sottostanti, ossia eseguire la previsione due volte e ottenere due risultati distinti. Questo è un bene⁴. I modelli numerici instabili sono dannosi per la supply chain a causa degli effetti a molla: una volta che un ordine di produzione o un ordine d’acquisto viene passato, l’azienda resta vincolata alle conseguenze di quell’ordine. Se un ordine viene passato, deve essere per motivi migliori che per una questione di instabilità numerica. Prima l’azienda eliminerà le ricette numeriche instabili dalla sua pratica di supply chain, meglio è. Tentare di oscurare il problema sottostante riducendo la frequenza del rinfresco delle previsioni è insensato: l’instabilità numerica non scompare perché l’azienda decide di smettere di occuparsene. Se le ricette numeriche sono così scadenti da non riuscire a mantenere una forte consistenza⁵ da un giorno all’altro, sono necessarie ricette numeriche migliori. Ancora, se un fornitore software si trova al centro del problema e non riesce a fornire una correzione profonda, allora anche l’azienda ha bisogno di un fornitore migliore.

I rinfreschi quotidiani di tutte le pipeline di estrazione dati possono sembrare eccessivi in termini di risorse informatiche. Tuttavia, considerando l’hardware moderno e un software ben progettato, questo costo è ridotto anche quando si considerano ricette sofisticate come la previsione probabilistica⁶. Inoltre, le supply chain si trovano regolarmente ad affrontare condizioni eccezionali che richiedono correzioni immediate su larga scala. Se l’azienda non riesce a rinfrescare tutte le sue cifre di supply chain in meno di 60 minuti quando necessario, allora è garantito che le emergenze rimarranno, di tanto in tanto, non affrontate, causando scompiglio sul campo. La regola dei 5-10 round - discussa in precedenza - si applica ancora: una volta individuata una correzione, occorrono più esecuzioni - possibilmente con impostazioni diverse - per avere la certezza che questa correzione d’emergenza funzioni. Così, se la pipeline di estrazione dati è troppo costosa da eseguire “a volontà”, la produzione verrà usata come campo di prova e il caos ne seguirà.

Da un punto di vista della produttività, i rinfreschi quotidiani eliminano la tolleranza verso configurazioni errate che continuano a generare risultati inutili. Ancora, è una cosa buona. Non c’è motivo di tollerare una ricetta numerica che continua a generare sprechi. La pianificazione della domanda non è una forma d’arte che sfida l’analisi numerica. Le ricette numeriche disfunzionali dovrebbero essere trattate come bug software e corrette di conseguenza. Tuttavia, fornire una correzione profonda richiede frequentemente molto più riflessione che ricorrere ad una sovrascrittura manuale ad hoc. La maggior parte delle aziende si chiede perché i loro team di supply chain continuino a ricorrere ai loro fogli di calcolo. Si scopre che, frequentemente, i fogli di calcolo sono l’unico luogo in cui le correzioni numeriche - che già dovrebbero far parte dei sistemi - vengono implementate, proprio perché iterare rapidamente in un foglio di calcolo non è un problema (a differenza dell’iterare sul sistema enterprise sottostante).

Tuttavia, i rinfreschi quotidiani (o più frequenti) sono solo un aspetto operativo del problema. Dal punto di vista della progettazione software, questo approccio deve essere integrato con un primo ingrediente chiave: la statelessness. Una pipeline di estrazione dati non dovrebbe utilizzare dati pre-calcolati, ma partire da zero dai dati transazionali grezzi ogni volta. Infatti, ogni bug o glitch è suscettibile di corrompere i dati pre-calcolati, rallentando l’azienda per un periodo di tempo indefinito: la logica potrebbe essere corretta, ma i dati errati rimangono. La soluzione è semplice: la pipeline di estrazione dati non dovrebbe avere alcuno stato, ossia nessun dato pre-calcolato di alcun tipo. Iniziare da zero garantisce che tutte le correzioni vengano applicate immediatamente nella massima misura possibile.

A sua volta, il versioning, un altro principio di progettazione software e il secondo ingrediente di interesse, integra la statelessness del sistema: più specificamente, il versioning dei dati. Infatti, se la pipeline di estrazione dati stessa non ha stato, allora, combinando semplicemente la logica della pipeline - che esiste come codice sorgente versionato - e i dati in ingresso, dovrebbe essere sufficiente per riprodurre esattamente ogni problema riscontrato durante l’esecuzione della pipeline. In altre parole, rende i problemi riproducibili. Tuttavia, per ottenere ciò è necessario conservare una copia esatta dei dati così come erano al momento dell’esecuzione della pipeline. In altre parole, i dati dovrebbero essere versionati insieme al codice. Il versioning dei dati garantisce che le correzioni possano essere testate nelle stesse condizioni esatte che hanno innescato il problema.

Lokad è stato progettato attorno a questi principi. Promuoviamo un rinfresco end-to-end quotidiano di tutto. Le nostre pipeline di estrazione dati sono stateless e versionate - sia la logica che i dati. E la tua azienda?