Quantitative SCM vs Classic APS

Joannes Vermorel

Mentre le supply chain hanno avuto un inizio precoce nella digitalizzazione 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 - si sono gradualmente arretrati nei due decenni successivi. Mentre è relativamente semplice aggiornare le interfacce utente, ad esempio trasformando le applicazioni desktop in applicazioni web, è solitamente molto più difficile riesaminare le scelte di progettazione architetturale di base che supportano un software. La maggior parte di queste soluzioni non è mai stata progettata per il cloud computing, l’apprendimento automatico o un’esperienza utente mobile-first, per citarne alcuni.

Lokad promuove processi e tecnologie che sfruttano al massimo ciò che la moderna potenza di calcolo in rete può offrire alle supply chain attraverso migliori ottimizzazioni predictive. Ci riferiamo a questo approccio come la prospettiva della Supply Chain Quantitativa. Tuttavia, per i professionisti della supply chain, questo messaggio può essere un po’ confuso, perché la Supply Chain Quantitativa non è una variante dei vecchi metodi di ottimizzazione della supply chain, ma è una bestia completamente diversa.

Pertanto, diamo uno sguardo più da vicino ai moduli tradizionali come di solito si trovano nei sistemi di pianificazione e programmazione avanzata (APS) leader¹, con un interesse particolare per i rifornimenti di magazzino in una rete a 2 livelli - ad esempio magazzini e negozi - e confrontiamo quei moduli con il modo in cui Lokad offre l’ottimizzazione predittiva. Per motivi di concisione, di seguito ci riferiamo in modo interscambiabile alla supply chain quantitativa (la visione) o a Lokad (l’implementazione del software).

Modulo calendario

Un modulo calendario fornisce meccanismi per ottimizzare le situazioni di ordinazione, ovvero decidere quando acquistare, quando un ciclo di acquisto a ordine fisso è inevitabile.

L’idea stessa che i professionisti della supply chain debbano ottimizzare il loro programma di ordinazione è il modo sbagliato di affrontare il problema. L’ordinazione comporta molteplici tipi di vincoli: calendario, quantitativi minimi d’ordine (MOQ), budget, ecc. Alcuni vincoli possono essere flessibili, come “nessun programma, qualsiasi giorno va bene tranne il 4 luglio e il 25 dicembre”, o rigidi, come “il contenitore 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 ottimizzare manualmente nulla. I risolutori numerici performanti non erano disponibili di routine negli anni ‘80, ma oggi non è più così.

Pertanto, presso Lokad, raccogliamo tutti i vincoli rilevanti, che vengono trattati come dati, ovvero il “database” dei programmi di ordinazione autorizzati, e quindi implementiamo i risolutori numerici adeguati per completare il lavoro.

Vedi anche Gli umani nella moderna supply chain.

Modulo eventi

Il modulo eventi gestisce gli aumenti e le diminuzioni della domanda dovuti a eventi pianificati, come l’introduzione di nuovi prodotti, la pubblicità, le promozioni dei prezzi, le cadute di catalogo e i volantini.

I modelli di previsione più antichi (ad esempio, Holt-Winters), scoperti negli anni ‘50 e ‘60, erano tutti incentrati sulle serie temporali. Pertanto, la maggior parte dei sistemi APS ha adottato prospettive centrate sulle serie temporali. Purtroppo, i problemi di supply chain non possono essere facilmente inseriti nelle serie temporali: le rotture di stock, le promozioni, le introduzioni e le eliminazioni sono tutti fenomeni che non si adattano al tradizionale quadro matematico associato alle serie temporali. Pertanto, per far fronte ai modelli di previsione delle serie temporali progettati male, gli APS ricorrono a “correzioni” manuali da applicare sia ai dati storici - ad esempio, lisciando l’aumento delle promozioni passate - sia alle previsioni di domanda - introducendo distorsioni nelle stime future.

Presso Lokad, il nostro approccio consiste nel trattare queste “disturbazioni” come dati storici semplici. Non sapremo mai con certezza cosa sarebbe successo se una promozione passata non fosse stata attivata. L’unica cosa che sappiamo con certezza è la caratteristica della promozione - ovvero le date di inizio e fine, il meccanismo di sconto, la portata, ecc. - e le relative vendite. Pertanto, il modello statistico deve essere progettato frontalmente per elaborare i dati storici così come sono, anziché essere “bloccato” con una prospettiva temporale ristretta.

Lokad raccoglie gli eventi rilevanti e elabora tutti questi dati con modelli statistici orientati a problemi ad alta dimensionalità, che rientrano tipicamente nell’ambito generico degli algoritmi di “machine learning”. L’ultima versione della nostra tecnologia di previsione è incentrata sulla programmazione differenziabile. Tuttavia, è ancora molto un lavoro in corso poiché il campo dell’apprendimento automatico stesso sta evolvendo rapidamente. La necessità di regolare manualmente i risultati delle previsioni dovrebbe essere considerata un difetto del software da correggere, non come un’opportunità per sfruttare i professionisti della supply chain come “coprocessori umani”.

Nella pratica, la maggior parte della sfida consiste nel raccogliere i dati rilevanti su eventi passati e futuri (ad esempio, promozioni pianificate), il che ha poco a che fare con le statistiche. Inoltre, i sistemi analitici, che siano Lokad o un APS, non sono il luogo adatto per eseguire grandi volumi di inserimenti manuali di dati. Questi inserimenti di dati appartengono al campo transazionale, ovvero all’ERP, che raccoglie tutti i fatti[^fatti] sulla supply chain.

Modulo di gestione delle spedizioni urgenti

Un modulo di gestione delle spedizioni urgenti agisce come uno strumento di avviso anticipato e fornisce agli acquirenti una visione aggiornata quotidianamente degli ordini in ritardo e delle spedizioni incomplete.

L’intero approccio delle eccezioni e degli avvisi è una prospettiva piuttosto datata per mitigare i problemi all’interno di sistemi complessi nell’industria del software. Questo approccio è stato ampiamente adottato dai fornitori di software negli anni ‘80 e ‘90, perché le eccezioni e gli avvisi sono facili da implementare su un database SQL. Basta una semplice istruzione SELECT con alcune condizioni WHERE. Tuttavia, nel complesso, questo approccio fa un uso inefficiente della risorsa scarsa che rappresentano i professionisti della supply chain, poiché tende a sovraccaricarli rapidamente, al punto che gli avvisi non sono più “avvisi” e si perde la sensazione di emergenza o di azione da intraprendere.

Lokad favorisce e offre una rigorosa prioritizzazione basata sul ROI degli “elementi” di interesse che vengono presentati ai professionisti della supply chain. Come regola generale, produrre un milione di numeri al giorno è facile, produrre 10 numeri degni di essere letti da un essere umano ogni giorno è difficile. Gli ordini in ritardo non sempre sono importanti: forse i livelli di stock sono comunque alti, o forse è solo un problema ricorrente per questo fornitore che dura da sempre. Le spedizioni incomplete dovrebbero anche essere elaborate automaticamente per correggere di conseguenza i pagamenti ai fornitori, ma non sempre richiedono una risposta immediata. Perché un “elemento” abbia un ROI, l’“elemento” dovrebbe essere azione, e il ROI rappresenta il ROI stimato associato all’azione. Lokad brilla nel fornire prioritizzazioni su misura che sono esattamente adattate alle specificità della supply chain di interesse.

Modulo di negoziazione/acquisto anticipato

I tipi di moduli di negoziazione/acquisto anticipato consentono all’acquirente di inserire i dati dell’accordo nel sistema in anticipo rispetto al periodo dell’accordo. Ciò consente al sistema di acquistare inventario di rifornimento corrispondente alla finestra dell’accordo, calcolare le quantità di acquisto anticipato e determinare quando acquistare tali quantità.

La maggior parte degli APS è stata inizialmente implementata con una prospettiva ingenua in cui il prezzo unitario veniva considerato autosufficiente dal punto di vista dei prezzi per calcolare una quantità di ordine ottimizzata. Tuttavia, la realtà aveva un livello di dettaglio più elevato. I fornitori spesso hanno strutture di prezzi complesse: MOQ, sconti per quantità, sconti su quote trimestrali, offerte temporanee, ecc.

Lokad considera 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à di ordine ottimizzata. Ad esempio, uno sconto temporaneo del fornitore offre un incentivo economico per l’azienda per sovra-stoccare temporaneamente: la quantità di ordine diventa il compromesso numerico tra lo sconto extra (guadagni lineari) e il rischio di sovrastock (costi super-lineari). Forniamo la quantità di ordine che ottimizza direttamente questo compromesso, oltre a tutte le altre forze economiche rilevanti.

Modulo di analisi degli ordini

I moduli di analisi degli ordini identificano potenziali esaurimenti di magazzino. Questi moduli forniscono le informazioni aggiornate necessarie per comprendere lo stato delle scorte per articoli come importazioni o quelli prodotti su misura - articoli con tempi di consegna lunghi per i quali spesso ci sono due, tre o più ordini in sospeso.

Questo è un altro caso di progettazione del software “facilità di implementazione” piuttosto semplicistica. Negli anni ‘80, era difficile eseguire qualsiasi tipo di analisi su scala di rete, quindi la maggior parte dei fornitori di software ha adottato per impostazione predefinita una progettazione del software che imponeva un “isolamento SKU”. Ogni SKU viene elaborato in modo isolato, e gli stimatori statistici calcolati - come la probabilità di esaurimento delle scorte prevista per il prossimo ciclo di ordinazione - sono completamente specifici dell’SKU di interesse.

Presso Lokad, osserviamo che ogni singolo SKU compete con tutti gli altri SKU per il budget dell’azienda. Pertanto, non importa davvero se la probabilità di esaurimento delle scorte di un determinato SKU è alta o bassa. L’unica cosa che conta è se il rendimento per l’ordinazione di più di questo SKU è sufficientemente alto da non essere superato da nessuna opzione alternativa - ad esempio, ordinare di più da un altro SKU - prontamente disponibile per l’azienda. Ad esempio, se l’SKU è associato a un prodotto che ha un costo elevato, un margine molto basso e viene acquistato solo da un singolo grande cliente aziendale, che sta per lasciare secondo il team delle vendite, mantenere il livello di servizio per questo SKU è una sicura ricetta per creare inventario morto.

Presso Lokad, forniamo quantità di ordine prioritizzate che riflettono direttamente l’economia end-to-end della supply chain.

Modulo di trasferimento degli eccessi di magazzino

I moduli di trasferimento degli eccessi di magazzino aiutano gli acquirenti a gestire gli eccessi di magazzino. Consentono agli acquirenti di trasferire l’inventario in eccesso da una posizione all’altra che ha una domanda sufficiente, al fine di evitare di effettuare ulteriori acquisti dal fornitore.

Nella supply chain, è quasi sempre possibile - ma di solito non profittevole - spostare qualcosa dalla posizione A alla posizione B. Pertanto, quando ci si trova di fronte a una rete in cui lo stesso articolo può essere conservato in molte posizioni, è naturale considerare ogni movimento di stock tra due posizioni come una decisione potenziale.

Pertanto, Lokad ha capacità integrate per eseguire l’ottimizzazione a livello di rete di questa natura, fondamentalmente forzando tutte le opzioni disponibili per i movimenti di stock. La parte più impegnativa dell’impresa è riflettere correttamente l’attrito economico associato allo spostamento delle scorte. Infatti, l’attrito di solito non viene correttamente riflettuto 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 inviato, sfruttiamo al massimo la sua capacità disponibile.

Purtroppo, il numero di opzioni cresce molto più velocemente del numero di SKU. Consideriamo una rete che include 2000 articoli conservati in 10 magazzini, il che porta a un totale di 10 x 2000 = 20.000 SKU. Il numero totale di archi da considerare per i movimenti di stock è 10 x (10 - 1)* 2000 = 180.000 archi, un numero molto più grande del numero originale di SKU. Per i lettori che sono familiari con gli algoritmi, si tratta di un caso semplice di complessità quadratica.

Tuttavia, considerando la potenza di elaborazione disponibile oggi, questo caso specifico di complessità quadratica è per lo più irrilevante - a condizione che il software sottostante sia stato progettato correttamente per questo tipo di esplorazione numerica. Infatti, le reti di supply chain raramente superano le 10.000 posizioni, anche quando si considerano le aziende più gigantesche; e alcune euristiche possono essere utilizzate per ridurre drasticamente il numero di archi da esplorare nella pratica, poiché molte coppie di posizioni sono destinate a non avere senso, come il riequilibrio delle scorte tra Parigi e Sydney.

Tuttavia, negli anni ‘80 e ‘90, a causa dell’hardware di elaborazione disponibile all’epoca, i sistemi di pianificazione avanzata (APS) avevano già difficoltà a far fronte al numero di SKU. Naturalmente, in questo contesto, far fronte a problemi di complessità quadratica era semplicemente fuori discussione.

Passando al giorno d’oggi, molti fornitori hanno dovuto introdurre moduli separati per affrontare qualsiasi tipo di problema che comporti un’ottimizzazione a livello di rete. Non c’è una vera motivazione aziendale per avere un modulo separato. Questo stato di cose riflette principalmente che il fornitore originale ha applicato un “riparo provvisorio” al suo prodotto software per far fronte a una classe di problemi che sono in conflitto con le scelte di progettazione fatte due decenni prima.

Al contrario, Lokad ha deciso di affrontare frontalmente questa classe di problemi che sono cittadini di prima classe nel nostro stack software. Naturalmente, la risoluzione effettiva della sfida richiede comunque sforzi nella pratica, perché tutti i costi e i vincoli di trasporto devono essere resi espliciti.

Modulo di pianificazione

I moduli di pianificazione consentono ai team di vendita o ai team di marketing di pianificare preventivamente gli ordini per eventi specifici come promozioni o ordini speciali. I team possono creare un ordine pianificato nel sistema più di un anno prima della data di pianificazione 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 una data di consegna prevista per il 1 marzo, allora questo annuncio è un fatto. Se questo cliente ha l’abitudine di modificare all’ultimo minuto la data di consegna prevista, di solito posticipandola di una settimana, allora questo pattern deve essere preso in considerazione. Tuttavia, questa analisi del pattern rientra nel lato 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, ad esempio una data di arrivo prevista, tende ad essere incerta in qualche misura. Le catene di approvvigionamento richiedono strumenti predittivi versatili ad alta dimensionalità, ed è esattamente per questo motivo che Lokad ha scelto la strada della programmazione differenziabile.

Inoltre, i fatti non devono essere raccolti dal livello di analisi, né da Lokad né dall’APS. Non perché il software non possa farlo. Progettare un software per raccogliere fatti è relativamente semplice, ma perché genera un alto grado di vincolo accidentale del fornitore. Infatti, non appena le voci di dati passano attraverso un sistema aziendale, questo sistema diventa il controllore principale di questi dati.

La nostra esperienza presso Lokad indica che i livelli di analisi obsoleti rimangono frequentemente in uso per un decennio in più rispetto al loro punto di obsolescenza, per nessun altro motivo se non che i dati critici per la missione verrebbero persi se questo sistema venisse spento. Nel frattempo, il fornitore originale del software continua a riscuotere tariffe di manutenzione, il che dà al fornitore un grande incentivo a creare il problema in primo luogo.

Modulo di proiezioni

I moduli di proiezioni 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, al fine di consentire loro di pianificare in modo più accurato le rispettive capacità di approvvigionamento.

Le previsioni isolate sono dannose e non possono più essere considerate una pratica sana nella supply chain. Consulta l’antipattern delle previsioni isolate per ulteriori informazioni. Ciò non significa che Lokad non abbia capacità di previsione, le abbiamo. Tuttavia, sosteniamo che l’approccio classico di previsione delle serie temporali sia semplicemente sbagliato e debba finire. Le serie temporali classiche possono funzionare per prodotti molto voluminosi e molto stabili, ma per tutto il resto - e soprattutto per la domanda erratica o intermittente - la previsione probabilistica è la strada da seguire.

Inoltre, i modelli di previsione storica basati su serie temporali - ad esempio, Holt-Winters o Arima - presentavano gravi limitazioni quando la storia del prodotto era troppo breve, troppo erratico, troppo atipico, troppo a basso volume, … La maggior parte dei fornitori di software ha risposto a questi problemi con due approcci, entrambi disfunzionali a loro modo:

• Coprocessori umani: poiché il modello di previsione finisce spesso per produrre risultati insensati, gli operatori umani - ovvero i pianificatori - vengono utilizzati dal sistema come “coprocessori” per sovrascrivere manualmente le previsioni ogni volta che “i numeri non sembrano giusti”. Purtroppo, il compito è senza fine poiché le previsioni devono essere continuamente aggiornate, costringendo i pianificatori in un ciclo infinito di sovrascritture manuali. Tale compito produce anche effetti collaterali indesiderati, in cui gli operatori umani sono abituati a considerare che le previsioni sono sbagliate e tendono a correggerle anche quando non lo sono, spesso basandosi solo sul proprio istinto.
• Concorrenza dei modelli: poiché ogni modello di previsione basato su serie temporali ha punti di forza e debolezze, una competizione tra molti modelli di previsione - secondo il ragionamento - dovrebbe produrre buoni risultati permettendo al sistema di “scegliere” il miglior modello in ogni situazione. Purtroppo, ciò fallisce per due motivi. In primo luogo, tutti i modelli si basano su un framework di serie temporali e quindi sono tutti soggetti alle stesse limitazioni. In secondo luogo, tutti i modelli sono “classici” e non riescono a fornire le previsioni probabilistiche richieste dalla supply chain.

Inoltre, la previsione non riguarda solo la domanda. Anche i tempi di consegna devono essere previsti. Inoltre, la struttura della supply chain è importante. 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 eccessivi se non invenduti. Una corretta ottimizzazione predittiva della supply chain deve tenere conto di questo rischio. La tecnologia di Lokad è stata progettata di conseguenza.

Sul particolare aspetto della condivisione delle previsioni con i fornitori, sebbene una migliore coordinazione tra acquirenti e fornitori sia sempre preferibile, abbiamo osservato che le coordinazioni basate sulle previsioni di successo tra le aziende sono state poche e distanti tra loro. I fornitori hanno comunque molti clienti[^fornitore]. Pertanto, anche se le previsioni fornite dagli acquirenti locali fossero accurate, il fornitore non ha un modo per conciliare 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 fornite come modulo separato. Lo scopo di un modulo di sicurezza è impedire l’accesso a determinati utenti. Consente anche alla direzione di proteggere le azioni dei componenti e di limitare le visualizzazioni per aree importanti del sistema, come i fattori di controllo aziendale, la manutenzione degli articoli, la manutenzione dei fornitori, gli ordini, le offerte e altri componenti.

Nel gergo informatico, qui stiamo parlando delle preoccupazioni trasversali di autenticazione e autorizzazione.

• L’autenticazione garantisce che gli utenti finali che fanno qualsiasi cosa nel sistema siano davvero la persona che il sistema crede che siano. Qui, Lokad adotta l’approccio moderno secondo cui l’autenticazione deve essere delegata quando possibile. Gli utenti finali non dovrebbero avere un’altra password con cui fare i conti. Invece, Lokad sfrutta SAML come lo standard di fatto del settore per delegare l’autenticazione alla gestione delle identità federate (FIM).
• L’autorizzazione fornisce il controllo dettagliato su chi può fare cosa all’interno del sistema. Qui, Lokad dispone di un esteso sistema di ACL (Access-Control List) canonico, che è anche la pratica de facto dei moderni sistemi aziendali. Lokad dispone anche di alcune capacità di personalizzazione, che integrano l’ACL dal punto di vista dell’esperienza utente.

Lokad attiva tutte le sue funzionalità di sicurezza di default, indipendentemente dal pacchetto originariamente venduto a uno qualsiasi dei nostri clienti. Crediamo che la sicurezza opzionale[^sicurezza] sia una pratica terribile da parte dei fornitori di software. La sicurezza del software è già estremamente difficile; una tale pratica la rende solo peggiore.

Ad essere onesti, l’aspetto dell’ACL è probabilmente la preoccupazione meno impegnativa dell’intera questione della sicurezza del software. Una domanda più interessante è: quanto sicurezza progettuale 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 l’analisi.

Poiché è abbastanza semplice produrre fogli Excel², molti fornitori, inclusa Lokad, offrono funzionalità in questo ambito. Tuttavia, un’analisi più approfondita indica che la maggior parte dei fornitori offre solo funzionalità incomplete. Esaminiamo i punti salienti delle implementazioni buone di esportazione in Excel:

• Storicizzazione completa: il sistema dovrebbe offrire la possibilità di tracciare e scaricare nuovamente ogni singolo foglio Excel esportato. Infatti, di fronte a cifre errate nel foglio di calcolo - un problema che si verificherà (anche solo a causa di dati di input errati) - non avere una tracciabilità completa sul percorso del codice che ha generato questo foglio di calcolo complicherà notevolmente, rallenterà - e talvolta impedirà - qualsiasi tentativo di debug e risoluzione del problema.
• Massimizzazione delle capacità del foglio di calcolo: gli operatori si aspettano di poter generare fogli di calcolo pesanti fino a 1 milione di righe³, che è il limite di Excel stesso. Pertanto, il sistema dovrebbe essere in grado di generare fogli di calcolo pesanti per non ostacolare gli operatori che vogliono semplicemente elaborare i dati con il proprio strumento familiare. Naturalmente, gli operatori si aspettano anche che queste esportazioni pesanti siano veloci.
• Protezione integrata contro gli attacchi ai fogli di calcolo: Excel è un vettore di attacco per le grandi organizzazioni. Purtroppo, la sicurezza dei fogli di calcolo generati dal sistema non può essere un’aggiunta successiva, deve essere una parte integrante del design, praticamente fin dal primo giorno.
• Configurabilità programmabile delle esportazioni: Dovere gestire due software - ovvero APS ed Excel - è già abbastanza complicato per gli operatori della supply chain. La situazione non dovrebbe peggiorare con fogli di calcolo che richiedono sempre un ulteriore elaborazione post-estrazione per diventare utilizzabili. Ciò implica che tutto avvenga prima dell’estrazione, all’interno di APS. Pertanto, APS ha bisogno di capacità programmatiche per preparare correttamente i fogli di calcolo prima dell’esportazione.

Lokad offre tutto quanto sopra, mentre la maggior parte dei nostri concorrenti no. Il diavolo sta nei dettagli.

Conclusioni

Siamo convinti che Lokad sia un software più semplice rispetto alla maggior parte degli APS presenti sul mercato. Tuttavia, la nostra capacità di offrire performance della supply chain attraverso tecnologie predictive è maggiore. Infatti, la maggior parte della complessità di APS è accidentale, derivante da scelte di progettazione del software fatte decenni fa per problemi di software orientati internamente ormai superati. Tuttavia, la maggior parte delle scelte architetturali del software, una volta fatte, non possono essere annullate.