La pipeline di estrazione dati

Questo documento è inteso come una guida per i reparti IT per costruire una pipeline che estrae dati dai sistemi aziendali esistenti e rende tali dati disponibili all’interno della piattaforma di Lokad. La configurazione di una pipeline di estrazione dati è una delle fasi iniziali di un’iniziativa quantitativa di supply chain. Il documento copre l’approccio raccomandato da Lokad, compreso l’ambito dei dati da estrarre e rendere disponibili sulla piattaforma di Lokad, il formato dei dati e le strategie di trasferimento dei dati.

Motivazione e contesto

Lokad definisce un’iniziativa quantitativa di supply chain come quella che fornisce una ricetta numerica che automatizza le decisioni (o almeno le raccomandazioni) di fronte alle sfide della supply chain. Lokad presenta una piattaforma programmabile progettata per la risoluzione di problemi di ottimizzazione predittiva relativi alla supply chain.

Tipici problemi includono:

• Decidere le quantità di stock da reintegrare
• Decidere le quantità di stock da produrre
• Decidere se aumentare o diminuire i prezzi
• Decidere se gli stock dovrebbero essere spostati all’interno della rete

Se l’azienda riesce a ottimizzare queste decisioni, di solito può ridurre i costi operativi, diminuire i requisiti di capitale circolante e aumentare la qualità del servizio. Al minimo, l’azienda dovrebbe essere in grado di rivedere questo mix di costi, liquidità e servizio per renderlo più in linea con la sua strategia complessiva di supply chain.

La ricetta numerica, che affronta il problema di interesse, è destinata ad essere implementata all’interno di Lokad. Di conseguenza, la ricetta numerica richiede che i dati rilevanti dell’azienda siano messi a disposizione all’interno della piattaforma di Lokad. Ciò pone le seguenti domande:

• Quali dati dovrebbero essere trasferiti a Lokad?
• Quale formato dovrebbe essere utilizzato per i dati?
• Quali pattern di trasferimento dovrebbero essere utilizzati per aggiornare i dati?

Sebbene i problemi sopra elencati siano vari, i dati di input rilevanti sono molto simili e sono solitamente forniti attraverso i dati storici transazionali core dell’azienda (ad esempio, le vendite storiche).

Il reparto IT del cliente è di solito responsabile della configurazione e della manutenzione della pipeline di estrazione dati. Nelle sezioni seguenti, verrà spiegato in dettaglio ciò che è specificamente richiesto al reparto IT.

Una volta creata la pipeline di estrazione dati, gli ingegneri di Lokad - definiti Supply Chain Scientists - sono responsabili della configurazione e della manutenzione della ricetta numerica. Questi ingegneri sono frequentemente forniti da Lokad nell’ambito di un accordo di servizio “Platform+Experts”, ma è anche possibile che il cliente internalizzi questa competenza. Tuttavia, anche quando tali ingegneri sono interni, consigliamo di collocarli nel reparto supply chain, piuttosto che in quello IT.

Indipendentemente dal fatto che questa parte dell’iniziativa di supply chain sia esternalizzata o meno, la prospettiva delineata in questo documento rimane la stessa.

Prospettiva tecnica di alto livello

Lokad è uno strato analitico che opera sopra i sistemi transazionali esistenti del cliente. In altre parole, Lokad non sostituisce l’ERP; lo integra con capacità di ottimizzazione predittiva che, realisticamente, non possono essere implementate come parte di un sistema transazionale tradizionale.

Ogni account Lokad è dotato di un file system a cui si può accedere tramite i protocolli SFTP e FTPS. È disponibile anche un’interfaccia web, anche se questa interfaccia non è tipicamente destinata al nostro pubblico IT (ma piuttosto alla fornitura di dashboard per utenti non specialisti). Ci aspettiamo che i dati rilevanti, normalmente estratti dai sistemi transazionali core utilizzati dall’azienda, vengano esportati come file flat (di cui si parlerà più in dettaglio qui sotto) e caricati sul file system di Lokad.

Salvo diverso accordo, il reparto IT del cliente è responsabile di tutto ciò che riguarda i dati fino al momento in cui i file flat vengono caricati sul file system di Lokad. Il design della piattaforma di Lokad è tale da poter gestire fallimenti parziali nell’estrazione dei dati (di cui si parlerà più in dettaglio qui sotto), pertanto il reparto IT dispone di una certa flessibilità in questo ambito.

Una volta che i dati sono messi a disposizione di Lokad, una serie di script Envision (Envision è il linguaggio di programmazione specifico per il dominio sviluppato da Lokad) li elaborano e generano le decisioni ottimizzate di supply chain di interesse.

Ci sono diverse applicazioni pratiche di tale estrazione dei dati, molte delle quali vanno oltre l’iniziativa di ottimizzazione della supply chain di Lokad. I team di marketing, finanza e vendite – per citarne solo tre – sono potenziali beneficiari degli stessi dati storici di vendita che Lokad alla fine elabora. Per questo motivo, Lokad raccomanda di consolidare i dati transazionali in uno strato di servizio dedicato – un “data lake” – che sia riservato esclusivamente alla fornitura di tali dati ai team appropriati e ai sistemi analitici di terze parti (come la piattaforma di Lokad).

La creazione di un data lake non è un requisito per utilizzare Lokad, ma è solo un’architettura potenziale che facilita le operazioni per l’azienda. Vale la pena notare che un data lake facilita anche l’emergere di una “data practice” all’interno di un’azienda - qualora tale pratica non esistesse già.

L’ambito dei dati rilevanti

La supply chain riguarda l’ottimizzazione delle decisioni relative al flusso di beni fisici (acquisto, trasporto, produzione, vendite, ecc.). Di conseguenza, i dati più rilevanti per un’iniziativa di ottimizzazione predittiva sono quasi sempre quei dati che descrivono i flussi che avvengono all’interno dell’azienda. Questi dati si trovano tipicamente nei sistemi aziendali transazionali del cliente.

Come già accennato, la piattaforma di Lokad è abbastanza flessibile nelle sue capacità di elaborazione, pertanto non ci sono requisiti rigidi per quanto riguarda i dati. Molto probabilmente, il cliente non sarà in grado di fornire molti degli elementi di dato elencati di seguito, e Lokad è in grado di operare all’interno di tali limitazioni. Pertanto, la lista sottostante tenta di essere il più completa possibile nell’identificare le fonti di dati utili, senza richiedere la fornitura rigorosa di ciascuna di esse.

Catalogo prodotti: La lista dei prodotti (o articoli, parts) che l’azienda acquista, trasforma, assembla e/o vende. Questa lista è importante perché molte decisioni avvengono a livello di “prodotto”. La gerarchia (ad es. categorie, famiglie, sottofamiglie), se presente, è rilevante – sia per scopi di reportistica che per analisi. Gli attributi strutturati (ad es. colore, taglia, peso, forma) che qualificano i prodotti sono anche utili. Come regola generale, qualsiasi dato che descriva i prodotti – da una prospettiva di supply chain – è rilevante. Anche le relazioni tra prodotti - come le BOM (bills of materials) - sono rilevanti.

Storico degli ordini di vendita: La lista degli ordini di vendita storici del cliente. Questa lista è importante perché le vendite sono quasi sempre il miglior indicatore che l’azienda possiede per stimare la domanda di mercato. Questi dati dovrebbero includere gli importi monetari associati alle transazioni, poiché l’ottimizzazione della supply chain dovrebbe essere eseguita da una prospettiva finanziaria. (Questa prospettiva finanziaria viene esaminata in seguito in maggiore dettaglio.) Quando possibile, è (sempre) preferibile fornire le transazioni d’ordine grezze, anziché gli aggregati giornalieri/settimanali/mensili. (Questo punto viene inoltre discusso in maggior dettaglio qui sotto.) Lo storico degli ordini di vendita può includere ordini arretrati, ordini annullati, ordini posticipati, ordini modificati, resi, ecc., tutti potenzialmente rilevanti. Se i clienti sono identificati in questi dati, gli identificatori anonimi dei clienti diventano rilevanti. (I dati personali hanno una sezione a parte qui sotto.)

Ordini di acquisto: La lista degli ordini di acquisto storici del cliente, nonché degli ordini di acquisto in sospeso (ancora da ricevere). Questa lista è importante perché gli ordini di acquisto sono quasi sempre il miglior indicatore per stimare i tempi di consegna dei fornitori e la qualità del loro servizio. Gli ordini di acquisto in sospeso riflettono lo “stock on order”. Gli ordini di acquisto dovrebbero anche includere gli importi monetari associati alle transazioni. Quando possibile, è (sempre) preferibile fornire lo storico degli ordini grezzi anziché gli aggregati. Lo storico degli ordini di acquisto dovrebbe includere, se disponibili, le date rilevanti: data dell’ordine, data di spedizione, data di consegna, ecc.

Ordini di produzione: La lista degli ordini di produzione storici del cliente (se applicabile), e degli ordini di produzione in sospeso (ancora da eseguire). Questa lista è importante perché tali ordini riflettono il flusso di trasformazione dei beni che avviene all’interno dell’azienda, oltre a permettere di identificare i colli di bottiglia che possono esistere nella supply chain. A seconda della situazione, la produzione può avere rese variabili o talvolta i lotti possono essere scartati a causa di problemi di qualità. Questi eventi sono rilevanti.

Movimenti di inventario: La lista dei movimenti di inventario storici del cliente, se sono presenti più sedi. Questa lista è importante perché fa luce sull’origine dello stock utilizzato sia per avviare i processi di produzione sia per servire i clienti. A seconda della situazione, i tempi di consegna per questi movimenti possono essere variabili. In tal caso, i dettagli delle date (data dell’ordine di trasferimento, data di spedizione, data di ricevimento) sono anch’essi rilevanti.

Livelli di stock: La lista di tutti gli SKU del cliente (unità di mantenimento dello stock) con il loro livello di stock attuale. Questa lista è importante perché caratterizza lo stato attuale della supply chain. A seconda del settore, la rappresentazione dell’inventario può essere più complessa di semplici livelli di SKU. Possono essere presenti anche le date di scadenza. Parte o tutto l’inventario può essere tracciato a livello del numero di serie. Se viene utilizzato l’inventario seriale, l’intera lista dei numeri di serie e delle relative sedi è rilevante. Più in generale, tutti gli elementi che descrivono lo stato attuale delle attività di inventario detenute dall’azienda sono rilevanti.

Etichette di prezzo: La lista dei prezzi applicati dal cliente nella gestione dei beni (e possibilmente dei relativi servizi). Questa lista è importante perché l’attuale politica dei prezzi del cliente può differire da quella applicata in passato. Prezzi più recenti influenzano la domanda futura, ma anche la redditività delle decisioni di supply chain. Possono essere presenti promozioni, sconti o opzioni di prezzo. Tutti gli elementi che contribuiscono al calcolo di ciò che viene addebitato ai clienti sono rilevanti.

Le istantanee dei livelli di stock passati, delle etichette di prezzo passate e degli ordini d’acquisto in sospeso passati sono anch’esse rilevanti per la maggior parte degli scopi della supply chain (tuttavia, questi dati sono raramente disponibili nei sistemi aziendali). Appena viene creata una pipeline di estrazione dati, tali istantanee possono essere implementate all’interno di Lokad stesso – senza intervento diretto del reparto IT del cliente.

Anche se questa lista è già consistente, quando si tratta di aziende di solito ci sono più fonti di dati rilevanti di quelle elencate qui. Come regola generale, se un’informazione è utile alla divisione supply chain, è molto probabilmente rilevante per scopi di ottimizzazione predittiva e dovrebbe essere indirizzata a Lokad.

Schema prioritizzato dei dati preparati

La lista delle tabelle di dati potenzialmente rilevanti citate sopra non ha lo scopo di sopraffare. In pratica, è importante identificare quali tabelle sono necessarie per portare l’iniziativa in produzione, invece di essere semplicemente gradite. È anche importante prioritizzare correttamente le estrazioni per permettere ai supply chain scientists di andare oltre la fase di estrazione dei dati e passare a quella di ottimizzazione.

Pertanto, come parte della nostra pratica di supply chain, Lokad raccomanda che i supply chain scientists producano uno schema prioritizzato dei dati preparati e condividano questo documento con il reparto IT del cliente all’inizio dell’iniziativa. Questo documento elenca le tabelle – e i loro campi – che si prevede siano disponibili alla fine del segmento di preparazione dei dati. Inoltre, questo documento elenca le rispettive priorità di tutti i campi richiesti.

Questo schema fornisce una lista dei desideri ad alto livello per i dati da estrarre. Tuttavia, questo documento non deve essere frainteso come una specifica per i file generati nella fase di estrazione dei dati. I supply chain scientists sono responsabili della preparazione dei dati. È accettabile (e comune) che lo schema dei dati, così come reso disponibile dalla pipeline di estrazione dei dati, differisca ampiamente dallo schema “idealizzato” associato ai dati preparati. Questo punto viene esaminato in maggiore dettaglio nella sezione “Raw transactional extracts” qui sotto.

Profondità storica dei dati

Per quanto riguarda la profondità storica dei dati da estrarre, di solito ci sono due preoccupazioni distinte. Innanzitutto, quanto indietro nel passato dovrebbe estendersi l’estrazione dei dati? In secondo luogo, qual è la profondità storica minima necessaria affinché l’iniziativa di supply chain abbia successo?

Generalmente, raccomandiamo di estrarre l’intera storia disponibile per tutte le tabelle che contengono meno di 1 miliardo di righe. Modificare la storia si traduce nel perdere dati che potrebbero essere rilevanti per valutare l’evoluzione a lungo termine della supply chain. I filtri saranno implementati da Lokad come parte della preparazione dei dati, comunque, trasferire più dati non si traduce necessariamente in maggiori risorse di calcolo per Lokad.

Per quanto riguarda la profondità storica, non esiste un requisito minimo. Se la storia del sistema è breve (ad es., sei mesi), allora alcuni schemi statistici, come la stagionalità, non possono essere stimati. Tuttavia, i professionisti della supply chain, che devono prendere le decisioni di interesse, prima dell’iniziativa di Lokad, sono vincolati dalle stesse limitazioni. La ricetta numerica di Lokad sarà implementata in modo da sfruttare qualunque profondità di storia disponibile, anche se potrebbe apparire scarsa al cliente.

Dati mancanti

Sebbene i moderni sistemi aziendali siano solitamente estesi, vi sono invariabilmente molti dati che sembrano mancare. Poiché i dati sono percepiti come mancanti, la validità dell’iniziativa quantitativa della supply chain viene messa in discussione. Tuttavia, nonostante la quantità di dati che risultino essere “mancanti”, i dipendenti dell’organizzazione riescono comunque a prendere le decisioni necessarie per il funzionamento della supply chain. In breve, esiste una via. L’approccio tecnologico di Lokad si basa sul fare il massimo con ciò che è disponibile – proprio come fanno i dipendenti. Questo approccio è l’opposto del tradizionale software aziendale che impone requisiti definitivi sui dati e non opererà a meno che tutti i requisiti non siano soddisfatti.

Nella nostra esperienza, esistono due ampie categorie di dati “mancanti” che andrebbero distinte: in primo luogo, i dati che dovrebbero essere integrati nel sistema aziendale; in secondo luogo, i dati che si ritiene siano estremamente utili per il sistema analitico (come Lokad).

Le Quantità Minime d’Ordine (MOQs), gli scaglioni di prezzo e le settimane di chiusura dei fornitori sono dati che frequentemente mancano dai sistemi aziendali. Tuttavia, tali dati sono preziosi dal punto di vista dell’ottimizzazione della supply chain. Questi dati potrebbero essere dispersi in fogli di calcolo ed email, impedendo un’analisi strutturata diretta lato Lokad. Di fronte a tali situazioni, suggeriamo di utilizzare euristiche (da codificare da Lokad) e fogli di calcolo ad hoc (da caricare su Lokad). Una volta che la ricetta numerica diventa operativa, Lokad coinvolgerà il reparto IT del cliente per integrare i dati nel sistema aziendale. Inoltre, la stessa ricetta numerica chiarisce quali dati sono veramente rilevanti e in che misura.

I dati di intelligence competitiva, come i prezzi dei concorrenti, sono una categoria ritenuta estremamente utile, ma, secondo la nostra esperienza, ciò non è scontato. In via aneddotica, ottenere questo tipo di dati comporta spesso costi notevoli, altrimenti le aziende lo farebbero già. Per questo motivo, fornire tali dati non è un requisito. In ogni caso, la ricetta numerica di Lokad sarà fondamentale per valutare – in un secondo momento – i reali guadagni finanziari associati ai dati aggiuntivi.

Estrazioni transazionali grezze

Raccomandiamo vivamente di preservare la forma originale dei dati. I dati inviati a Lokad dovrebbero essere nient’altro che copie grezze delle tabelle e delle colonne originali, come si trovano nel RDBMS che supporta i sistemi aziendali dell’azienda. Tutta la preparazione dei dati dovrebbe essere delegata alla piattaforma Lokad, che è stata progettata specificamente per la preparazione dei dati.

Tentare di preparare i dati comporta invariabilmente una perdita di dati. Se tale perdita è accettabile o meno dipende dalle specifiche decisioni della supply chain interessate. Se i dati sono già persi al momento in cui raggiungono la piattaforma Lokad, non si può fare nulla per recuperarli. Le estrazioni transazionali grezze garantiscono che l’intero insieme delle informazioni disponibili nei sistemi aziendali diventi accessibile all’interno di Lokad.

Inoltre, la preparazione dei dati introduce un proprio livello di complessità sopra quello già presente nei sistemi aziendali. È vero che la ricetta numerica che garantisce l’ottimizzazione desiderata della supply chain non può evitare di affrontare classi di complessità intrinseche. Tuttavia, se questa ricetta numerica deve anche far fronte alla complessità accidentale introdotta dalla preparazione dei dati, trasforma un problema già difficile in uno insolitamente complesso. Le estrazioni transazionali grezze garantiscono che Lokad non si ritrovi a dover affrontare un problema ancora più grande di quello da risolvere.

Da un punto di vista IT, le estrazioni transazionali grezze sono semplici. È opportuno utilizzare semplici copie delle tabelle (ad esempio, SELECT * FROM MyTable), che rappresentano la forma più basilare di interrogazioni in un database relazionale. Tali interrogazioni sono semplici, in quanto non prevedono filtri, e performanti, poiché non comportano join. Tuttavia, le tabelle di grandi dimensioni richiedono un’attenzione specifica. Questo punto è trattato di seguito.

Se è presente un data lake, allora il data lake dovrebbe rispecchiare i dati relazionali così come si trovano nei sistemi aziendali. Tutti i principali sistemi di database dispongono di capacità di mirroring integrate. Raccomandiamo di sfruttare queste capacità durante l’impostazione del data lake. Inoltre, rispecchiare i dati è molto più semplice che prepararli – soprattutto dal punto di vista del reparto IT, dato che la preparazione dei dati dipende fortemente dal problema specifico da affrontare.

L’antipattern dell’estrazione BI

I dati da inviare a Lokad non dovrebbero provenire da una fonte secondaria (ad esempio, un sistema di Business Intelligence (BI)) in cui i dati sono già stati ampiamente modificati, solitamente per favorire il consumo diretto da parte dell’utente finale. Sebbene estrarre dati da un sistema BI sia più semplice che da un ERP, ciò crea invariabilmente problemi insolubili in seguito. Per definizione, gli aspetti transazionali dei dati vengono persi, in quanto i dati vengono aggregati in serie temporali giornaliere/settimanali/mensili.

Inoltre, molte complicazioni difficili da visualizzare ma rilevanti, come gli ordini a più righe, vengono rimosse dai sistemi di Business Intelligence (quali i cubi BI). Questi dettagli sono preziosi perché riflettono l’essenza delle situazioni della supply chain che devono essere affrontate.

Dati errati

Dall’esperienza di Lokad, i casi di dati errati sono rari. Al contrario, i sistemi aziendali transazionali (come gli ERP) di solito dispongono di dati accurati. Le anomalie nelle voci dei dati transazionali sono rare e tipicamente si verificano una o due volte ogni 1000 voci. Quando si utilizzano codici a barre o dispositivi simili, il tasso d’errore è ancora più basso. Il vero problema risiede nel software che fa ipotesi errate sui dati, anziché nei dati stessi.

Le quantità di stock nei punti vendita per le grandi reti retail B2C sono quasi sempre imprecise. Tuttavia, dal punto di vista di Lokad, questa situazione rappresenta un caso di dati rumorosi, non di dati errati. Se tali livelli di stock vengono (erroneamente) considerati precisi, i risultati saranno insensati. Affrontiamo questa situazione specifica con una visione probabilistica dei livelli di stock, accettando l’incertezza invece di ignorarla.

Infine, i sistemi di Lokad sono stati progettati per ricevere dati e permettere al cliente di gestire la propria supply chain senza doversi preoccupare di tali problematiche. Lokad stabilisce una semantica dei dati per affrontare questi problemi e ciò rappresenta la parte più impegnativa della fase di preparazione dei dati.

Dati personali

Un’iniziativa di supply chain quasi mai necessita di dati personali per operare. Pertanto, dal punto di vista della supply chain, raccomandiamo di trattare i dati personali come una passività, non come un patrimonio. Sconsigliamo fortemente il trasferimento di dati personali alla piattaforma di Lokad. In pratica, ciò significa solitamente filtrare le colonne del database (vedi discussione sotto) che contengono identificatori personali (ad es., nome, indirizzo, numero di telefono, email, ecc.).

Questi identificatori personali possono essere sostituiti da codici anonimi e opachi – se l’informazione è rilevante per la supply chain. Ad esempio, identificatori opachi dei clienti sono utili perché permettono a Lokad di individuare schemi legati alla fedeltà dei clienti – come il negativo impatto degli stock esauriti. A differenza della maggior parte delle tecnologie di previsione, che possono operare solo con una prospettiva di serie temporali, la piattaforma di Lokad può sfruttare dati storici ultra-granulari, fino al livello della transazione.

Se non sei sicuro della posizione di Lokad in merito alle Informazioni di Identificazione Personale (PII), questo argomento è trattato nelle Sezioni 1, 3 e 4 del nostro documento sicurezza.

Dati finanziari

Le somme monetarie relative ai beni acquistati, trasformati e venduti dal cliente sono di primaria importanza per l’ottimizzazione della supply chain che Lokad offre. In effetti, Lokad enfatizza una prospettiva finanziaria sulla supply chain che ottimizza dollari di ritorno piuttosto che percentuali di errore.

A differenza dei fornitori che considerano solo i dati relativi alle quantità di stock, Lokad utilizza i dati finanziari del cliente – se resi disponibili. Logicamente, i costi più angoscianti della supply chain si concentrano agli estremi; una domanda inaspettatamente alta genera stock-out; mentre una domanda inaspettatamente bassa porta a svalutazioni dell’inventario. Nel mezzo, l’inventario ruota regolarmente. Pertanto, per ottimizzare davvero le decisioni relative all’inventario, è necessario effettuare un compromesso finanziario riguardo a tali rischi. Lokad sfrutta i dati finanziari del cliente per calcolare un compromesso adeguato.

Pipeline di dati vs estrazione una tantum

Una pipeline di estrazione dei dati aggiorna automaticamente i dati trasferiti a Lokad. Questa configurazione rappresenta uno sforzo maggiore rispetto a un’estrazione dei dati una tantum. Se possibile, raccomandiamo fortemente di automatizzare l’estrazione dei dati, possibilmente con un approccio graduale se il numero di tabelle rilevanti è elevato. Questa automazione funziona al meglio se implementata fin dal Giorno 1. Tuttavia, estrazioni una tantum parziali, utilizzate per identificare le tabelle rilevanti, possono essere utili. Questo punto è discusso nei passaggi seguenti.

Vi sono tre ragioni principali per supportare un approccio a pipeline di dati.

In primo luogo, dal punto di vista dell’operatore della supply chain, dati vecchi di tre settimane sono storia antica. I risultati ottenuti da dati obsoleti sono irrilevanti per le attuali decisioni sulla supply chain. Un’estrazione una tantum produrrebbe risultati basati su un’unica istantanea della storia aziendale del cliente, generando così risultati di valore limitato. Inoltre, gli operatori della supply chain devono vedere il sistema in azione per acquisire fiducia nella sua capacità di gestire la variabilità quotidiana.

In secondo luogo, sebbene progettare una pipeline di dati altamente affidabile sia difficile, essa è preferibile alle alternative. Una pipeline di dati inaffidabile mette a rischio l’intera iniziativa quantitativa della supply chain, poiché nessuna quantità di analisi può risolvere problemi fondamentali relativi ai dati, come il non avere accesso a livelli di stock aggiornati.

Di solito sono necessarie numerose esecuzioni programmate per perfezionare il processo di estrazione, dato che alcuni problemi si manifestano solo in modo intermittente. Il modo più sicuro per risolvere questi problemi è avviare la pipeline di dati il prima possibile, permettendo così a Lokad di identificare e risolvere eventuali criticità. In particolare, le esecuzioni programmate sono una delle opzioni più sicure per valutare le prestazioni end-to-end dell’intera sequenza di processi, inclusi quelli che portano alla formulazione delle decisioni raccomandate per la supply chain.

In terzo luogo, secondo la nostra esperienza, la causa più frequente dei ritardi nelle iniziative quantitative della supply chain è l’installazione tardiva della pipeline di estrazione dei dati. Riconosciamo che i reparti IT sono spesso sottoposti a una notevole pressione per consegnare numerosi progetti e costruire una pipeline di estrazione dei dati è un ulteriore compito a cui devono far fronte. Pertanto, è allettante – per il reparto IT – rimandare la parte relativa alla pipeline, optando invece per una serie di estrazioni una tantum. Sebbene questo approccio sia valido, esso comporta il rischio di introdurre ritardi nell’iniziativa e di impedire a Lokad di identificare, il prima possibile, intere classi di problemi potenziali (come descritto nel paragrafo precedente).

Frequenza di estrazione dei dati

Raccomandiamo di aggiornare tutte le pipeline di dati – sia i segmenti di estrazione che quelli analitici – almeno una volta al giorno, anche quando si tratta di calcoli mensili o trimestrali. Questo può sembrare controintuitivo, ma, secondo la nostra esperienza, aggiornamenti automatici frequenti sono l’unico modo per ottenere un processo end-to-end altamente affidabile.

Per la maggior parte delle situazioni della supply chain, raccomandiamo una routine di estrazione che fornisca un quadro completo dei dati fino alla chiusura delle attività del giorno corrente (ad es., eseguire l’estrazione giovedì sera di tutti i dati storici pertinenti fino alla chiusura delle attività di giovedì). La pipeline di estrazione viene eseguita alla fine della giornata lavorativa, seguita dall’elaborazione analitica – all’interno della piattaforma Lokad. I risultati aggiornati sono disponibili fin dall’inizio della giornata lavorativa successiva.

Profondità dell’estrazione dei dati: la regola 2+1 per gli incrementi

Quando i dati sono troppo grandi per essere ricaricati integralmente su Lokad ogni giorno, si dovranno utilizzare caricamenti incrementali. Raccomandiamo che tali caricamenti seguano la regola 2+1 per gli incrementi: la finestra temporale del caricamento giornaliero copre le ultime due settimane complete, più quella in corso. Seguire questa regola è importante per garantire l’alta affidabilità della soluzione Lokad.

La pipeline di estrazione dei dati fallirà di tanto in tanto – indipendentemente da Lokad. Nella nostra esperienza, anche reparti IT eccellenti sperimentano 1-2 fallimenti della pipeline all’anno. Quando il caricamento giornaliero fallisce, l’ultimo giorno di dati risulta compromesso. Se ogni caricamento giornaliero copre solo un singolo giorno (senza sovrapposizioni tra i caricamenti), Lokad si ritrova con una storia dei dati parzialmente corrotta. Riparare questa storia, lato Lokad, richiede un secondo intervento manuale da parte del reparto IT, oltre a risolvere ciò che ha impedito alla pipeline di estrazione dei dati di funzionare correttamente in primo luogo. Questa “riparazione della storia dei dati” probabilmente subirà un ritardo di alcuni giorni – poiché si tratta di un’operazione insolita per il reparto IT. Nel frattempo, i risultati restituiti da Lokad sono negativamente influenzati, poiché alcuni dati recenti risultano parzialmente corrotti.

Al contrario, se ogni caricamento giornaliero copre le ultime due settimane lavorative complete, più quella in corso, un’esecuzione fallita della pipeline di estrazione dei dati beneficia di un recupero completo il giorno seguente. Infatti, poiché la pipeline di estrazione fa parte delle operazioni routinarie gestite dal reparto IT, il ripristino dello stato operativo normale dovrebbe avvenire entro un giorno lavorativo. Questo recupero non richiede alcuna interazione specifica tra il reparto IT e il personale di supporto di Lokad o gli utenti finali della soluzione. La correzione dei dati viene automaticamente effettuata tramite le sovrascritture quotidiane che coprono la finestra temporale 2+1.

La regola 2+1 riflette un compromesso basato sull’esperienza di Lokad: più lunga è la finestra temporale, maggiore è la resilienza della pipeline di estrazione dei dati contro problemi transitori. Sebbene si possa sperare che eventuali criticità vengano risolte entro un giorno lavorativo, il reparto IT potrebbe avere questioni più urgenti. In effetti, il fallimento della pipeline potrebbe essere solo il sintomo di un problema più grave che il reparto IT ha deciso di affrontare con priorità. Pertanto, il recupero potrebbe richiedere alcuni giorni. La regola 2+1 garantisce che, fintanto che il reparto IT riesce a sistemare la pipeline entro due settimane, le operazioni possano riprendere normalmente con il minimo impatto possibile sull’iniziativa di ottimizzazione. Tuttavia, se la finestra temporale è troppo lunga, il caricamento incrementale diventa troppo gravoso in termini di risorse computazionali, vanificando il motivo stesso per cui sono stati introdotti i caricamenti incrementali.

Se le ultime tre settimane rappresentano meno di 100MB di dati, suggeriamo di adottare la variante mensile della regola 2+1: la finestra temporale del caricamento giornaliero copre gli ultimi due mesi completi, oltre a quello corrente.

Identificare le tabelle e le colonne rilevanti

La stragrande maggioranza del software aziendale è costruito su database relazionali. Sebbene possano esistere API web, nella nostra esperienza tali API raramente offrono prestazioni soddisfacenti per estrazioni complete della cronologia programmate. Al contrario, interrogare direttamente il database tramite SQL si rivela frequentemente semplice da implementare e abbastanza performante, poiché le query SQL raccomandate da Lokad non richiedono l’esecuzione di join.

Pertanto, una volta che un sistema aziendale (ad es. ERP) è stato ritenuto una fonte di dati rilevante per l’iniziativa, e supponendo che il database relazionale sottostante sia accessibile, occorre identificare l’elenco specifico delle tabelle e delle colonne rilevanti. Molti sistemi aziendali contengono centinaia di tabelle e migliaia di colonne, la maggior parte delle quali irrilevanti per l’iniziativa di supply chain. In linea di massima, un’iniziativa di supply chain raramente necessita di più di una dozzina di tabelle per iniziare e solo qualche dozzina per ottenere un alto grado di copertura dei dati.

Se l’azienda dispone di un esperto che conosce lo schema del database aziendale, sfruttare questa competenza è il modo più semplice per identificare le tabelle rilevanti all’interno del database. Tuttavia, se non vi è alcun esperto, il reverse engineering del database per identificare le aree di interesse può solitamente essere realizzato in una o due settimane (anche in presenza di un sistema abbastanza complesso). Oltre a sfruttare la documentazione tecnica disponibile relativa al sistema di interesse, suggeriamo di iniziare con un’estrazione completa dello schema del database, includendo:

• il nome della tabella
• il nome della colonna
• il tipo di colonna
• la dimensione della tabella

Suggeriamo di raccogliere queste informazioni in un foglio di calcolo. Le tabelle potenziali possono essere identificate dai loro nomi e dalle loro dimensioni. Suggeriamo di iniziare con un’ispezione più approfondita delle tabelle più grandi, poiché è lì che di solito si individuano quelle più rilevanti (per un’iniziativa di supply chain ottimizzata). Per ispezionare una tabella, consigliamo un’ispezione visiva di qualche dozzina di righe di dati. Le osservazioni andranno aggiunte al foglio di calcolo man mano che il lavoro procede.

Diagnosi dello schema PostgreSQL

La query per estrarre tutte le tabelle e le colonne:

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = '‘table_name'’;

Vedi anche https://stackoverflow.com/questions/20194806/how-to-get-a-list-column-names-and-datatypes-of-a-table-in-postgresql

La query per estrarre tutte le dimensioni delle tabelle:

select table_name, pg_relation_size(quote_ident(table_name))
from information_schema.tables
where table_schema = '‘public'’

Vedi anche https://stackoverflow.com/questions/21738408/postgresql-list-and-order-tables-by-size

Il modello di query per estrarre un campione di righe:

select column from table
order by RANDOM()
limit 10000

Vedi anche https://stackoverflow.com/questions/19412/how-to-request-a-random-row-in-sql

Diagnosi dello schema Oracle

La query per estrarre tutte le tabelle e le colonne:

SELECT table_name, column_name, data_type FROM ALL_TAB_COLUMNS

La query per estrarre tutte le dimensioni delle tabelle:

SELECT table_name, num_rows FROM ALL_TABLES

Il modello di query per estrarre un campione di righe:

set colsep ,
set headsep off
set pagesize 0
set trimspool on
spool c:/temp/oracle/output/foo_my_table.csv
SELECT * FROM FOO_MY_TABLE FETCH FIRST 10000 ROWS ONLY;
spool off

Formati di file e trasferimenti

La piattaforma Lokad supporta file di testo semplice, formati flat (tipicamente CSV o TSV) nonché fogli di calcolo Microsoft Excel, sia per operazioni di lettura che di scrittura. La sezione Read and Write Files documenta le capacità di I/O di Lokad. Pur supportando un insieme piuttosto vario di opzioni di formattazione, raccomandiamo quanto segue:

• Plain text viene utilizzato al posto dei fogli di calcolo (vedi discussione sottostante).
• La prima riga contiene le intestazioni delle colonne e corrisponde ai nomi originali delle colonne.
• I nomi delle colonne non contengono spazi o trattini.
• UTF-8 viene utilizzato per la codifica dei caratteri.
• Il punto (.) è il separatore decimale per i numeri frazionari.
• Tutte le date condividono lo stesso formato tra le tabelle.
• Gli importi monetari isolano la valuta in una colonna separata.
• Il nome del file corrisponde al nome originale della tabella.
• /input è la cartella lato Lokad utilizzata, per convenzione, per depositare i file estratti.

Ogni volta che un file flat estratto supera i 100MB, raccomandiamo di comprimere il file utilizzando GZIP.

Per quanto riguarda il trasferimento, raccomandiamo l’utilizzo di SFTP con autenticazione a chiave pubblica.

Tabelle partizionate

Raccomandiamo di partizionare le tabelle che sono troppo grandi per essere ricaricate completamente su Lokad quotidianamente in modo agevole. La partizione consente tipicamente caricamenti incrementali se la partizione rispecchia l’età dei dati. In linea generale, le tabelle che contengono meno di 1 milione di righe solitamente non giustificano l’impegno richiesto per partizionarle.

Quando si partiziona una tabella in una lista di file, il modello di denominazione raccomandato consiste nel raggruppare i file in una sottocartella dedicata all’interno di /input (prendendo il nome della rispettiva tabella) e nel suffissare ogni file con il segmento estratto corrispondente:

/input/mytable/mytable-2022-10-17.csv
/input/mytable/mytable-2022-10-18.csv
/input/mytable/mytable-2022-10-19.csv
/..

Anche se tutte le righe all’interno di un file presentano lo stesso valore “date” (corrispondente a quello indicato nel nome del file), raccomandiamo di mantenere questa colonna “date” come parte del file.

Microsoft Excel

La piattaforma Lokad supporta la lettura dei dati dai fogli di calcolo Microsoft Excel, purché il foglio segua un formato tabellare (la prima riga contiene le intestazioni, seguita da un record per riga). Tuttavia, la pipeline di estrazione dei dati dovrebbe evitare il trasferimento dei fogli di calcolo a Lokad.

I fogli di calcolo sono accettabili se i file vengono caricati manualmente su Lokad, anziché essere trasferiti attraverso la pipeline di estrazione dei dati automatizzata. I caricamenti manuali sono accettabili se:

• I dati non esistono (ancora) nei sistemi aziendali.
• I dati vengono aggiornati molto raramente.

/manual è la cartella lato Lokad utilizzata, per convenzione, per ricevere i file caricati manualmente.

Sovrascrittura dei file

I file all’interno del filesystem di Lokad rappresentano i dati così come percepiti da Lokad. Sovrascrivere i file esistenti è il metodo raccomandato per aggiornare le tabelle estratte che non sono partizionate. Nel caso di una tabella partizionata, l’aspettativa predefinita è che venga creato un nuovo file per ogni periodo (un file al giorno, o alla settimana, o al mese).

Una volta che tutti i file da creare (o sovrascrivere) sono stati trasferiti su Lokad, raccomandiamo di creare (o aggiornare) un file denominato /input/end-of-transfer.csv che contenga:

• una singola colonna denominata LastTransfer
• una singola riga di dati (due righe se si conta l’intestazione) con un timestamp del trasferimento più recente

Questo file può essere utilizzato per attivare una sequenza di progetti che elabora i dati appena aggiornati.

Salute dei dati

La pipeline di estrazione dei dati deve operare in maniera affidabile. La stessa piattaforma Lokad può essere utilizzata per monitorare l’output della pipeline e valutare l’integrità, la completezza e la freschezza dei dati estratti. Pertanto, come primissimo passo all’interno di Lokad, raccomandiamo l’implementazione di dashboard per la salute dei dati. Tali dashboard sono destinate al reparto IT (pur non essendo loro responsabilità esclusiva) e hanno lo scopo collettivo di evidenziare eventuali problematiche relative ai dati, accelerando la loro risoluzione da parte del reparto IT. Questa implementazione, come il resto della ricetta numerica che guida l’iniziativa di supply chain ottimizzata, è prevista per essere realizzata da un supply chain expert, possibilmente dal team di Lokad (nel caso di un abbonamento Platform+Experts).

Specifica dell’estrazione dei dati

Una volta che la pipeline di estrazione dei dati sarà stata stabilizzata, raccomandiamo di produrre una specifica per l’estrazione dei dati. Tale documento dovrebbe elencare tutti i file previsti e le rispettive colonne, nonché il calendario per l’estrazione dei dati. Si prevede che la stabilizzazione della pipeline avvenga entro sei mesi dal kickoff dell’iniziativa. Il documento dovrà essere concordato congiuntamente dal reparto IT e dal reparto supply chain, contenendo nel dettaglio le clausole dei dati che il reparto IT si impegna a rendere disponibili, in modo tempestivo, alla piattaforma Lokad.

Il formato dei dati potrà essere revisionato in un secondo momento, ma ci si aspetta che il reparto IT notifichi il reparto supply chain prima di apportare qualsiasi modifica al formato dei dati o al relativo calendario. In generale, una volta che la specifica è stata concordata, le operazioni di supply chain dovranno fare affidamento, per scopi produttivi, sull’integrità dell’estrazione dei dati. Pertanto, in caso di modifiche, il reparto supply chain dovrà aspettarsi un ragionevole “periodo di grazia” sufficiente ad aggiornare la logica all’interno di Lokad (per adeguarsi al formato dei dati revisionato).

Poiché produrre una specifica dettagliata richiede un notevole impegno in termini di tempo e risorse, raccomandiamo di posticipare la sua redazione fino a quando la pipeline non sarà stabilizzata. Nella nostra esperienza, durante i primi mesi la pipeline — sia nella fase di estrazione che in quella analitica — subisce una rapida evoluzione, rendendo obsoleti i tentativi iniziali di produrre una specifica.

Feedback loop

Le decisioni di supply chain (ad es., i riapprovvigionamenti di inventario) generate all’interno della piattaforma Lokad possono essere esportate come file flat per essere reintegrate nei sistemi aziendali. Questo meccanismo è definito come il feedback loop. La nostra esperienza indica che il feedback loop difficilmente verrà implementato entro quattro mesi dal kickoff dell’iniziativa. La fiducia nella ricetta numerica necessaria per permettere anche ad una parte di supply chain di operare in modalità autopilota è sostanziale, e tale grado di fiducia può richiedere diversi mesi per maturare. Pertanto, il feedback loop non rappresenta una preoccupazione nelle fasi iniziali dell’iniziativa.

Nella nostra esperienza, l’implementazione del feedback loop rappresenta una sfida molto minore rispetto a quella della pipeline di estrazione dei dati. Ad esempio, le cifre prodotte all’interno di Lokad dovrebbero essere autorevoli e definitive; se vi fossero ulteriori regole da applicare per trasformare tali cifre in numeri azionabili (ad es., MOQs applicati), la ricetta numerica risulterebbe incompleta e richiederebbe correzioni sul Lato Lokad. D’altra parte, la piattaforma Lokad ha la capacità di elaborare e produrre qualsiasi forma di dato purché sia ragionevolmente tabellare. Pertanto, la semplicità del feedback loop è concepita per riflettere la semplicità delle decisioni di supply chain.

Tuttavia, raccomandiamo che alla piattaforma Lokad non venga concesso accesso diretto ai sistemi aziendali del cliente. Invece, i file dovrebbero essere resi disponibili in modo tempestivo all’interno del filesystem di Lokad. Il reparto IT rimane responsabile dell’importazione di tali dati nei sistemi aziendali, garantendo così che una potenziale violazione della sicurezza dell’account Lokad non possa essere utilizzata per accedere ad altri sistemi aziendali. Inoltre, ciò offre la possibilità di posticipare l’operazione di feedback qualora entrasse in conflitto con un’altra operazione eseguita dal reparto IT sui sistemi aziendali.

Dato che il feedback loop implica, per definizione, dati relativi alle operazioni reali di supply chain, raccomandiamo di produrre una specifica dedicata a questo processo. Tale specifica rispecchia quella per l’estrazione dei dati, ma con i dati trasferiti nella direzione opposta. Ci si aspetta altresì che questo documento sia concordato congiuntamente dal reparto IT e dal reparto supply chain.