SCM Quantitativo vs APS Classico

Joannes Vermorel

Mentre le supply chains hanno iniziato precocemente la digitalizzazione già negli anni ‘80 e ‘90 con la gestione elettronica delle scorte e l’EDI (Electronic Data Interchange), molti fornitori di software - e quindi la maggior parte dei loro clienti - sono rimasti progressivamente indietro rispetto ai tempi nei due decenni successivi. Sebbene sia relativamente semplice rinnovare le interfacce utente, per esempio trasformando applicazioni desktop in app web, di solito è molto più impegnativo rivedere le scelte progettuali architetturali di base che supportano un applicativo. La maggior parte di quelle soluzioni non era stata mai progettata per il cloud computing, il machine learning o un’esperienza utente mobile-first — per citarne solo alcuni.

Lokad promuove processi e tecnologie che sfruttano al massimo ciò che il moderno potere computazionale in rete può offrire alle supply chains attraverso migliori ottimizzazioni predittive. Ci riferiamo a questo approccio come la prospettiva del Quantitative Supply Chain. Tuttavia, per i professionisti della supply chain, questo messaggio può risultare alquanto confuso, perché Quantitative Supply Chain non è una variazione sui vecchi metodi di ottimizzazione della supply chain, ma un approccio completamente diverso.

Quindi, diamo uno sguardo più approfondito ai moduli tradizionali, come di solito si trovano nei sistemi APS (Advanced Planning and Scheduling) leader,¹ con un interesse particolare per i riapprovvigionamenti di stock in una rete a due livelli — ad esempio, magazzini e negozi — e confrontiamo questi moduli con il modo in cui Lokad fornisce l’ottimizzazione predittiva. Per brevità, nel seguito, facciamo riferimento in maniera intercambiabile alla quantitative supply chain (la visione) oppure a Lokad (l’implementazione software).

Modulo calendario

Un modulo calendario fornisce meccanismi per perfezionare le situazioni di ordinazione, cioè, decidere quando acquistare, laddove un ciclo di acquisti a ordine fisso è inevitabile.

L’idea stessa che i professionisti della supply chain debbano perfezionare il loro piano di ordinazioni è il modo sbagliato di affrontare il problema. L’ordinazione comporta molteplici tipi di vincoli: calendario, MOQs, budget, ecc. Alcuni vincoli possono essere lassisti, come “nessun programma, ogni giorno va bene tranne il 4 luglio e il 25 dicembre”, oppure rigidi, come “il container deve essere esattamente pieno”. In ogni caso, il sistema dovrebbe cercare - tra tutte le opzioni di ordinazione fattibili - quelle che massimizzano il ROI. Questo processo, l’“ottimizzazione”, deve essere rigorosamente automatizzato. Non c’è motivo di perfezionare manualmente nulla. Solver numerici performanti non erano disponibili regolarmente negli anni ‘80, ma al giorno d’oggi non è più così.

Pertanto, in Lokad raccogliamo tutti i vincoli rilevanti, che sono trattati come dati, ossia il “database” dei piani di ordinazione autorizzati, per poi lanciare i solver numerici adeguati a portare a termine il lavoro.

Vedi anche Umani nella moderna supply chain.

Modulo eventi

Il modulo event gestisce i picchi e le flessioni della domanda dovuti a eventi programmati, come le introduzioni di nuovi prodotti, la pubblicità, le promozioni sui prezzi, il lancio di cataloghi e volantini.

I primi modelli di previsione (ad esempio Holt-Winters), scoperti negli anni ‘50 e ‘60, erano tutti incentrati sulle serie temporali. Di conseguenza, la maggior parte degli APS adottava prospettive incentrate sulle serie temporali. Sfortunatamente, i problemi della supply chain non possono essere facilmente inquadrati nelle serie temporali: stock-out, promozioni, introduzioni e fasi di eliminazione sono fenomeni che non rientrano nel tradizionale quadro matematico associato alle serie temporali. Pertanto, per far fronte ai modelli di previsione basati su serie temporali, che risultano difettosi per design, gli APS ricorrono a “correzioni” manuali da applicare sia ai dati storici — per esempio, attenuando l’effetto delle passate promozioni — sia alle previsioni della domanda, introducendo bias nelle stime future.

In Lokad, il nostro approccio è trattare tali “disturbi” come semplici dati storici. Non sapremo mai con certezza cosa sarebbe successo se una promozione passata non fosse stata attivata. L’unica cosa di cui siamo certi sono le caratteristiche della promozione — cioè le date di inizio e fine, il meccanismo di sconto, l’ambito, ecc. — e le vendite risultanti. Pertanto, il modello statistico deve essere progettato fin dall’inizio per elaborare i dati storici così come esistono, invece di rimanere “bloccato” in una prospettiva ristretta delle serie temporali.

Lokad raccoglie gli eventi rilevanti ed elabora tutti questi dati con modelli statistici orientati a problemi ad alta dimensionalità, che rientrano tipicamente nell’ombrello generico degli algoritmi di “machine learning”. L’ultima versione della nostra tecnologia di previsione è incentrata sulla differentiable programming. Tuttavia, è ancora un lavoro in corso, poiché anche il campo del machine learning è in rapida evoluzione. La necessità di modificare manualmente i risultati delle previsioni dovrebbe essere trattata come un difetto software da correggere, non come un’opportunità per sfruttare i professionisti della supply chain come “coprocessori umani”.

In pratica, la maggior parte della sfida consiste nel raccogliere i dati rilevanti sia sugli eventi passati sia su quelli futuri (ad es. le promozioni programmate) - il che ha poco a che fare con la statistica. Inoltre, i sistemi analitici, sia che si tratti di Lokad o di un APS, non sono il luogo adatto per effettuare un alto volume di inserimenti manuali di dati. Tali inserimenti appartengono all’ambito transazionale - alias l’ERP - che raccoglie tutti i fatti² relativi alla supply chain.

Modulo di gestione dell’accelerazione degli ordini

Un modulo di order expedite management agisce come uno strumento di allarme precoce e fornisce agli acquirenti una visione aggiornata quotidianamente degli ordini in ritardo e delle spedizioni parziali.

L’approccio basato su eccezioni e allarmi è una prospettiva piuttosto datata per mitigare i problemi all’interno di sistemi complessi nell’industria del software. Questo approccio fu fortemente adottato dai fornitori di software negli anni ‘80 e ‘90, poiché le eccezioni e gli allarmi sono semplici da implementare su un database SQL. Basta una query SELECT con alcune condizioni WHERE. Tuttavia, nel complesso, questo approccio sfrutta in maniera inefficiente la scarsa risorsa rappresentata dai professionisti della supply chain, sovraccaricandoli rapidamente, al punto che gli allarmi non sono più “allarmi” e la percezione dell’urgenza d’azione si perde.

Lokad favorisce e fornisce una rigorosa priorizzazione basata sul ROI degli “item” di interesse che vengono presentati ai professionisti della supply chain. In linea di massima, produrre 1 milione di numeri al giorno è facile, mentre produrre 10 numeri degni di essere letti quotidianamente da un essere umano è difficile. Gli ordini in ritardo non sempre sono rilevanti: forse i livelli di stock sono comunque elevati, oppure si tratta semplicemente di un problema ricorrente per questo fornitore, che persiste da sempre. Le spedizioni parziali dovrebbero essere anch’esse elaborate automaticamente per correggere di conseguenza i pagamenti ai fornitori, ma non sempre richiedono una risposta immediata. Affinché un “item” generi ROI, l’“item” dovrebbe essere attuabile, e il ROI rappresenta il ritorno sull’investimento stimato associato all’azione. Lokad eccelle nel fornire priorizzazioni su misura esattamente adattate alle specificità della supply chain di interesse.

Modulo Deal/Forward Buy

I moduli di tipo deal/forward buy permettono all’acquirente di inserire i dati dell’accordo nel sistema in anticipo rispetto al periodo dell’accordo. Questo consente al sistema di acquistare scorte di riapprovvigionamento in linea con la finestra dell’accordo, di calcolare le quantità per il forward buy e di determinare quando acquistare tali quantità.

La maggior parte degli APS fu inizialmente implementata con una prospettiva ingenua in cui il prezzo unitario veniva considerato sufficiente — dal punto di vista dei prezzi — per calcolare una quantità d’ordine ottimizzata. Tuttavia, la realtà presentava un livello di dettaglio superiore. I fornitori spesso hanno strutture di prezzo complesse: MOQs, scaglioni di prezzo, sconti su quote trimestrali, accordi temporanei, ecc.

Lokad tratta tutti questi elementi come dati di input e vincoli di input e sfrutta una risoluzione numerica diretta di un problema vincolato per fornire una quantità d’ordine ottimizzata. Ad esempio, uno sconto temporaneo sull’offerta fornisce un incentivo economico per l’azienda ad accumulare temporaneamente scorte in eccesso: la quantità d’ordine diventa il compromesso numerico tra lo sconto extra (guadagni lineari) e il rischio di overstock (costi super-lineari). Forniamo la quantità d’ordine che ottimizza direttamente questo compromesso, oltre a tutte le altre forze economiche rilevanti.

Modulo di analisi degli ordini

I moduli di order analysis identificano potenziali esaurimenti di stock. Questi moduli forniscono le informazioni aggiornate necessarie per comprendere lo stato delle scorte per articoli come le importazioni o quelli realizzati su ordinazione — articoli a lunga scadenza per i quali spesso ci sono due, tre o più ordini in sospeso.

Questo è un altro caso di progettazione software alquanto semplicistica basata sulla “facilità di implementazione”. Negli anni ‘80, era difficile eseguire analisi a livello di rete, perciò la maggior parte dei fornitori di software adottava, di default, una progettazione che imponeva l’isolamento dello SKU. Ogni SKU viene elaborato in isolamento, e gli stimatori statistici calcolati — come la probabilità di stock-out attesa per il prossimo ciclo di ordinazione — sono completamente specifici per lo SKU in questione.

Da Lokad osserviamo che ogni singolo SKU compete con tutti gli altri SKU per il budget aziendale. Di conseguenza, non importa realmente se la probabilità di stock-out di un determinato SKU sia alta o bassa. L’unica cosa che conta è se il ritorno sull’investimento per ordinare di più questo SKU è sufficientemente elevato da non essere superato da alcuna opzione alternativa — cioè, ordinare di più da un altro SKU — prontamente disponibile per l’azienda. Ad esempio, se lo SKU è associato a un prodotto che ha un costo elevato, un margine molto basso e viene acquistato solo da un unico grande cliente corporate, che secondo il team commerciale sta per abbandonare, mantenere il livello di servizio per questo SKU è una ricetta sicura per creare inventario obsoleto.

In pratica, Lokad fornisce quantità d’ordine prioritarizzate che riflettono direttamente l’economia end-to-end della supply chain.

Modulo di trasferimento dell’overstock

I moduli di overstock transfer aiutano gli acquirenti a gestire l’overstock nei magazzini. Permettono agli acquirenti di trasferire l’inventario in eccesso da una sede all’altra che abbia una domanda sufficiente, per evitare di effettuare ulteriori acquisti dal fornitore.

Nella supply chain, è quasi sempre possibile — ma solitamente non redditizio — spostare qualcosa dalla sede A alla sede B. Pertanto, quando ci si trova di fronte a una rete in cui lo stesso articolo può essere immagazzinato in molteplici località, è del tutto naturale trattare ogni movimento di stock tra due località come una decisione potenziale.

Pertanto, Lokad dispone di capacità integrate per eseguire un’ottimizzazione a livello di rete di questo tipo, provando in maniera esaustiva tutte le opzioni disponibili per i movimenti di stock. La parte più impegnativa dell’operazione consiste nel riflettere appropriatamente la frizione economica associata allo spostamento dello stock. Infatti, la frizione non viene solitamente adeguatamente considerata dai movimenti di stock a livello di SKU. Ad esempio, i costi di trasporto tendono ad essere altamente non lineari: se un camion deve essere spedito, sfruttiamo al massimo la sua capacità disponibile.

Sfortunatamente, il numero di opzioni cresce molto più rapidamente del numero di SKU. Consideriamo una rete che include 2000 articoli immagazzinati in 10 magazzini, per un totale di 10 x 2000 = 20.000 SKU. Il numero totale di edge da considerare per i movimenti di stock è 10 x (10 - 1) * 2000 = 180.000 edge, un numero molto superiore al numero originale di SKU. Per i lettori che hanno dimestichezza con gli algoritmi, si tratta di un caso classico di complessità quadratica.

Tuttavia, considerando la potenza di elaborazione disponibile al giorno d’oggi, questo specifico caso di complessità quadratica è per lo più irrilevante — a patto che il software sottostante sia stato progettato correttamente per questo tipo di esplorazione numerica. In effetti, le reti di supply chain raramente superano le 10.000 località, anche nelle aziende più gigantesche; e alcune euristiche possono essere utilizzate per ridurre drasticamente il numero di edge da esplorare nella pratica, dal momento che molte coppie di località risultano del tutto insensate, come il riequilibrio delle scorte tra Parigi e Sydney.

Tuttavia, negli anni ‘80 e ‘90, a causa dell’hardware di calcolo disponibile all’epoca, gli APS facevano già fatica a gestire il numero di SKU. Naturalmente, in questo contesto, affrontare problemi di complessità quadratica era semplicemente fuori discussione.

Avanzando rapidamente fino ai giorni nostri, molti fornitori hanno dovuto introdurre moduli separati per affrontare qualsiasi tipo di problema che implichi un’ottimizzazione a livello di rete. Non esiste una vera motivazione commerciale per avere un modulo separato. Questo stato di cose riflette principalmente il fatto che il fornitore originale ha improvvisato il suo prodotto software per far fronte a una classe di problemi in conflitto con scelte progettuali risalenti a due decenni fa.

Al contrario, Lokad ha deciso di affrontare frontalmente questa classe di problemi, considerati cittadini di prima classe nella nostra pila software. Naturalmente, la risoluzione effettiva della sfida comporta ancora sforzi, poiché tutti i costi di trasporto e i vincoli devono essere resi espliciti.

Modulo di pianificazione

I moduli di planning permettono ai team di vendita o marketing di pre-pianificare ordini per eventi specifici, come promozioni o ordini speciali. I team possono creare un ordine pianificato nel sistema con più di un anno di anticipo rispetto alla data prevista dell’ordine.

L’approccio di Lokad inizia stabilendo una chiara separazione tra fatti e previsioni. Consideriamo una rete di vendita B2B. Se un cliente annuncia il 10 febbraio che ordinerà 1000 unità, con data di consegna prevista per il 1° marzo, allora tale annuncio è un fatto. Se questo cliente ha l’abitudine di rivedere all’ultimo minuto la data di consegna prevista - solitamente posticipandola di 1 settimana - allora questo schema deve essere preso in considerazione. Tuttavia, questa analisi del pattern rientra nella parte delle previsioni del problema.

Lokad affronta questa classe di problemi con una tecnologia che fornisce previsioni probabilistiche generali e non solo previsioni probabilistiche di domanda. Qualsiasi affermazione fatta sul futuro, come ad esempio una data di arrivo prevista, tende ad essere incerta in una certa misura. Le supply chain richiedono strumenti predittivi versatili e ad alta dimensionalità, ed è proprio per questo che Lokad ha intrapreso la strada della programmazione differenziabile.

Inoltre, i fatti non devono essere raccolti dal layer analitico, né da Lokad né dall’APS. Non perché il software non possa farlo. Progettare un software per raccogliere i fatti è relativamente semplice, ma perché ciò genera un alto livello di lock-in accidentale del fornitore. Infatti, non appena i dati entrano in un sistema all’interno dell’azienda, quel sistema diventa il controllore de facto di tali dati.

La nostra esperienza in Lokad indica che i layer analitici obsoleti spesso rimangono in uso fino a un decennio oltre il loro punto di obsolescenza, se non altro perché i dati mission-critical verrebbero persi se tale sistema venisse spento. Nel frattempo, il fornitore originale del software continua a raccogliere le tariffe di manutenzione, il che fornisce al fornitore un grande incentivo a creare il problema sin dall’inizio.

Modulo di proiezione

I moduli di proiezione consentono agli acquirenti di creare report che proiettano la domanda futura e gli acquisti futuri fino a un anno in anticipo. Queste previsioni possono essere condivise con i fornitori, per consentire loro di pianificare in modo più accurato le rispettive capacità di fornitura.

Le previsioni nuda sono dannose e non possono più essere considerate una pratica sana per la supply chain. Consulta il naked forecasts antipattern per maggiori informazioni. Questo non significa che Lokad non abbia capacità di previsione, noi le abbiamo. Tuttavia, sosteniamo che l’approccio classico di previsione basato sulle serie temporali sia semplicemente sbagliato e debba finire. Le serie temporali classiche possono funzionare per prodotti a volumi molto elevati e molto stabili, ma per qualsiasi altra cosa - e soprattutto per una domanda erratica o intermittente - la previsione probabilistica è la strada da percorrere.

Inoltre, i modelli di previsione basati su serie temporali storiche - ad esempio, Holt-Winters o Arima - avevano enormi carenze ogni volta che la storia del prodotto era troppo breve, troppo irregolare, troppo atipica, o a basso volume, … La maggior parte dei fornitori di software ha risposto a questi problemi con due approcci, ugualmente disfunzionali a modo loro:

• Coprocessori umani: poiché il modello di previsione finisce frequentemente per produrre risultati insensati, gli operatori umani - cioè i pianificatori - vengono utilizzati dal sistema come “coprocessori” per sovrascrivere manualmente le previsioni ogni volta che i “numeri non sembrano corretti”. Purtroppo, il compito è infinito poiché le previsioni devono essere continuamente aggiornate, costringendo i pianificatori in un ciclo senza fine di sovrascritture manuali. Tale compito produce anche effetti collaterali indesiderati, in cui gli operatori umani finiscono per ritenere che le previsioni siano sbagliate e tendono a correggerle anche quando non lo sono, spesso basandosi unicamente sull’intuito.
• Competizione tra modelli: dato che ogni modello di previsione basato su serie temporali ha i propri punti di forza e debolezza, una competizione tra molti modelli di previsione - si suppone - dovrebbe dare buoni risultati permettendo al sistema di “scegliere” il modello migliore in ogni singola situazione. Purtroppo, questo fallisce per due motivi. Innanzitutto, tutti i modelli si basano su un framework di serie temporali e quindi sono tutti soggetti alle medesime limitazioni. In secondo luogo, tutti i modelli sono “classici” e non riescono a fornire le previsioni probabilistiche che la supply chain richiede.

Inoltre, la previsione non riguarda solo la domanda. I tempi di consegna devono essere previsti anch’essi. Inoltre, la struttura della supply chain conta. Nel B2B, un flusso costante di vendite può nascondere il fatto che tutti gli ordini provengono dallo stesso cliente. Se questo cliente viene perso, molti articoli diventano immediatamente in eccesso, se non inutilizzabili. Una corretta ottimizzazione predittiva della supply chain deve tenere conto di questo rischio. La tecnologia di Lokad è stata progettata di conseguenza.

Per quanto riguarda la condivisione delle previsioni con i fornitori, sebbene una migliore coordinazione tra acquirenti e fornitori sia sempre auspicabile, abbiamo osservato che le coordinazioni basate sulle previsioni di successo tra aziende sono state poche e sporadiche. I fornitori hanno comunque molti clienti propri ³. Pertanto, anche se le previsioni fornite dagli acquirenti locali fossero accurate, il fornitore non dispone di un modo per riconciliare tutte quelle previsioni disparate: la somma delle previsioni NON è la previsione della somma.

Modulo di sicurezza

Sorprendentemente, per alcuni APS, le funzionalità di sicurezza non sono tutte presenti di default nel sistema, ma sono fornite come modulo separato. Lo scopo di un modulo di sicurezza è impedire l’accesso ad alcuni utenti. Inoltre, permette alla direzione di mettere in sicurezza le azioni sui componenti e di limitare le visualizzazioni in aree importanti del sistema, quali fattori di controllo aziendale, manutenzione degli articoli, manutenzione dei fornitori, ordini, contratti e altri componenti.

Nel gergo informatico, qui si parla delle preoccupazioni trasversali dell’autenticazione e dell’autorizzazione.

• L’autenticazione garantisce che gli utenti finali che operano nel sistema siano veramente la persona che il sistema crede siano. Qui, Lokad adotta l’approccio moderno secondo cui l’autenticazione deve essere delegata ogni volta che è possibile. Gli utenti finali non dovrebbero avere un’altra password da gestire. Invece, Lokad sfrutta SAML come standard industriale de facto per delegare l’autenticazione alla gestione federata delle identità (FIM).
• L’autorizzazione offre un controllo dettagliato su chi può fare cosa all’interno del sistema. Qui, Lokad dispone di un ampio sistema canonico di ACL (Access-Control List), che è anche la prassi de facto dei sistemi aziendali moderni. Lokad offre inoltre alcune capacità di personalizzazione, che completano l’ACL dal punto di vista dell’esperienza utente.

Lokad attiva per default tutte le sue funzionalità di sicurezza, indipendentemente dal pacchetto originariamente venduto a uno qualsiasi dei nostri clienti. Riteniamo che la sicurezza opzionale⁴ sia una pratica terribile da parte dei fornitori di software. Mettere in sicurezza il software è già estremamente difficile; tale pratica lo rende solo peggiore.

A dire il vero, l’argomento ACL è probabilmente la preoccupazione meno impegnativa nell’intera questione della sicurezza del software. Una domanda più interessante è: quanta sicurezza per design offre l’architettura stessa del sistema. Tuttavia, rispondere a questa domanda va oltre lo scopo del presente articolo.

Esportazione in Excel

Il modulo di esportazione in Excel fornisce un modo semplice per trasportare i dati per l’uso in altri sistemi o per analisi.

Poiché è relativamente semplice produrre fogli Excel⁵, molti fornitori - incluso Lokad - offrono funzionalità in quest’area. Tuttavia, un’analisi più approfondita indica che la maggior parte dei fornitori consegna capacità poco sviluppate. Esaminiamo i punti salienti delle implementazioni di buone esportazioni in Excel:

• Storico completo: il sistema dovrebbe offrire la possibilità di tracciare e riscaricare ogni singolo foglio Excel mai esportato. Infatti, quando ci si trova di fronte a cifre errate nel foglio di calcolo - un problema che si verificherà (se non altro a causa di input dati errati) - non avere una completa tracciabilità sul percorso di codice che ha generato questo foglio di calcolo complicherà enormemente, rallenterà - e talvolta impedirà - qualsiasi tentativo di debug e correzione del problema.
• Sfruttamento al massimo delle capacità dei fogli di calcolo: i professionisti si aspettano di poter generare fogli di calcolo robusti fino a 1 milione di righe⁶, ossia, in realtà, il limite stesso di Excel. Pertanto, il sistema dovrebbe essere in grado di generare fogli di calcolo pesanti in modo da non intralciare i professionisti che desiderano effettuare autonomamente elaborazioni di dati con uno strumento familiare. Naturalmente, ci si aspetta anche che tali esportazioni massicce siano rapide.
• Protezione integrata contro attacchi ai fogli di calcolo: Excel rappresenta un vettore di attacco pericoloso per le grandi organizzazioni. Purtroppo, mettere in sicurezza i fogli di calcolo generati dal sistema non può essere un ripensamento, ma deve essere parte integrante del design, praticamente sin dal primo giorno.
• Configurabilità programmatica delle esportazioni: dover gestire due software - vale a dire l’APS e Excel - è già sufficientemente complicato per i professionisti della supply chain. La situazione non dovrebbe peggiorare a causa di fogli di calcolo che richiedono sempre una ulteriore elaborazione post-estrazione per diventare utilizzabili. Ciò implica che tutto avvenga prima dell’estrazione, all’interno dell’APS. Di conseguenza, l’APS necessita di capacità programmatiche per preparare adeguatamente i fogli di calcolo prima dell’esportazione.

Lokad offre tutto quanto sopra, mentre la maggior parte dei nostri concorrenti non lo fa. Il diavolo è nei dettagli.

Conclusione

La nostra convinzione è che Lokad sia un software più semplice rispetto alla maggior parte degli APS sul mercato. Tuttavia, la nostra capacità di offrire supply chain performance attraverso tecnologie predittive è maggiore. Infatti, la maggior parte della complessità degli APS è accidentale, derivante da scelte progettuali software fatte decenni fa per problemi di software orientati all’interno, ormai superati. Tuttavia, la maggior parte delle scelte architetturali nel software, una volta fatte, non possono essere annullate.