Il Data Extraction Pipeline

Questo documento è destinato come guida per i dipartimenti IT per costruire un pipeline che estrae dati dai sistemi aziendali esistenti e rende questi dati disponibili all’interno della piattaforma di Lokad. La configurazione di un data pipeline è una delle prime fasi di un’iniziativa quantitativa sulla supply chain. Il documento copre l’approccio che Lokad raccomanda, inclusa la portata 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 sulla supply chain come quella che fornisce una ricetta numerica che automatizza decisioni (o almeno raccomandazioni) di fronte a sfide sulla supply chain. Lokad presenta una piattaforma programmabile progettata per la risoluzione di problemi di ottimizzazione predittiva legati alla supply chain.

I problemi tipici includono:

• Decidere le quantità di stock da rifornire
• 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 ad ottimizzare queste decisioni, di solito può ridurre i costi operativi, ridurre i requisiti di capitale circolante e aumentare la qualità del servizio. Al minimo, l’azienda dovrebbe essere in grado di rivedere questa combinazione di costi, denaro e servizio per renderla più allineata alla sua strategia complessiva sulla 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 aziendali rilevanti siano resi disponibili all’interno della piattaforma di Lokad. Ciò porta alle seguenti domande:

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

Anche se i problemi elencati sopra sono vari, i dati di input rilevanti sono molto simili e di solito sono serviti attraverso i dati storici transazionali di base dell’azienda (ad esempio le vendite storiche).

Il dipartimento IT del cliente è di solito responsabile della configurazione e della manutenzione del data extraction pipeline. Nelle sezioni successive, verrà spiegato dettagliatamente cosa è specificamente richiesto al dipartimento IT.

Una volta creato il data extraction pipeline, gli ingegneri del lato Lokad - chiamati Supply Chain Scientists - sono responsabili della configurazione e della manutenzione della ricetta numerica. Questi ingegneri vengono spesso forniti da Lokad come parte di un accordo di servizio “Piattaforma+Esperti”, ma è anche possibile per il cliente internalizzare questa competenza. Tuttavia, anche quando tali ingegneri sono interni, raccomandiamo di collocarli nel dipartimento della supply chain, piuttosto che in quello IT.

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

Prospettiva tecnica ad 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 viene fornito con un filesystem 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 (piuttosto per la fornitura di dashboard per utenti non specialisti). Ci aspettiamo che i dati pertinenti, tipicamente estratti dai sistemi transazionali principali utilizzati dall’azienda, vengano esportati come file flat (più dettagli a riguardo di seguito) e caricati nel filesystem di Lokad.

A meno che non sia diversamente concordato, il dipartimento IT del cliente è responsabile di tutto ciò che riguarda i dati fino al punto in cui i file flat vengono caricati nel filesystem di Lokad. Il design della piattaforma di Lokad è tale da poter gestire parziali fallimenti nell’estrazione dei dati (più dettagli a riguardo di seguito), quindi il dipartimento IT ha una certa libertà in questo senso.

Una volta che i dati sono resi disponibili a Lokad, una serie di script Envision (Envision è il linguaggio di programmazione specifico del dominio sviluppato da Lokad) li elabora e genera le decisioni ottimizzate della 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. Marketing, finanza e team di vendita - per citarne solo tre - sono potenziali beneficiari degli stessi dati storici di vendita che Lokad elabora alla fine. Per questo motivo, Lokad raccomanda di consolidare i dati transazionali in uno strato di servizio dedicato - un “data lake” - 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 è una potenziale architettura che facilita le operazioni per l’azienda. È importante notare che un data lake facilita anche l’emergere di una “pratica dei dati” all’interno di un’azienda - nel caso in cui tale pratica non esista già.

Ambito dei dati pertinenti

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

Come già menzionato, la piattaforma di Lokad è piuttosto flessibile nelle sue capacità di elaborazione, quindi non ci sono requisiti rigidi per quanto riguarda i dati. Molto probabilmente, il cliente non sarà in grado di fornire molti degli elementi di dati elencati di seguito, e Lokad è in grado di operare entro tali limitazioni. Pertanto, l’elenco di seguito cerca di essere il più completo possibile nell’individuare fonti di dati utili, senza richiedere la rigorosa fornitura di ciascuno di essi.

Catalogo prodotti: L’elenco dei prodotti (o articoli, parti) che l’azienda acquista, trasforma, assembla e/o vende. Questo elenco è importante perché molte decisioni avvengono a livello di “prodotto”. La gerarchia (ad esempio, categorie, famiglie, sottofamiglie), se presente, è rilevante - sia per scopi di reportistica che analitici. Gli attributi strutturati (ad esempio, colore, dimensione, peso, forma) che qualificano i prodotti sono anche utili. Come regola generale, tutti i dati che descrivono i prodotti - da una prospettiva della supply chain - sono rilevanti. Anche le relazioni tra i prodotti - come le distinte materiali (BOM) - sono rilevanti.

Storico ordini di vendita: L’elenco degli ordini di vendita storici del cliente. Questo elenco è importante perché le vendite sono quasi sempre il miglior proxy che l’azienda ha per stimare la domanda di mercato. Questi dati dovrebbero includere gli importi monetari associati alle transazioni, poiché l’ottimizzazione della supply chain dovrebbe essere effettuata da una prospettiva finanziaria. (Questa prospettiva finanziaria viene approfondita in seguito in maggior dettaglio.) Quando possibile, è (sempre) preferibile fornire transazioni di ordini grezzi, anziché aggregati giornalieri/settimanali/mensili. (Questo punto viene discusso anche in maggior dettaglio di seguito.) Lo storico degli ordini di vendita può includere ordini in sospeso, ordini cancellati, ordini posticipati, ordini modificati, resi, ecc., tutti dati potenzialmente rilevanti. Se i clienti sono identificati in questi dati, diventano rilevanti gli identificatori dei clienti anonimizzati. (I dati personali hanno la propria sezione di seguito.)

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

Ordini di produzione: L’elenco degli ordini di produzione storici del cliente (se applicabile), e gli ordini di produzione in sospeso (ancora da eseguire). Questo elenco è importante perché questi ordini riflettono il flusso di trasformazione delle merci che avviene all’interno dell’azienda, permettendoci anche di identificare i colli di bottiglia che possono esistere nella supply chain. A seconda della situazione, la produzione può avere rese variabili o a volte i lotti possono essere scartati a causa di problemi di qualità. Questi eventi sono rilevanti.

Movimenti di inventario: L’elenco dei movimenti di inventario storici del cliente se sono presenti più sedi. Questo elenco è importante perché fa luce sull’origine delle scorte utilizzate per avviare i processi produttivi o servire i clienti. A seconda della situazione, i lead time di questi movimenti possono essere variabili. In tal caso, i dettagli delle date (data dell’ordine di trasferimento, data di spedizione, data di ricezione) sono rilevanti anche.

Livelli di stock: L’elenco di tutte le SKU (unità di tenuta di magazzino) del cliente con il loro attuale livello di stock. Questo elenco è importante perché caratterizza lo stato attuale della supply chain. A seconda del settore, la rappresentazione dell’inventario può essere più complessa dei semplici livelli di SKU. Le date di scadenza possono anche essere presenti. Alcune o tutte le scorte possono essere tracciate a livello di numero seriale. Se l’inventario seriale è in uso, l’intero elenco dei numeri seriali e le relative posizioni associate sono rilevanti. Più in generale, tutti gli elementi che descrivono lo stato attuale degli asset di inventario detenuti dall’azienda sono rilevanti.

Etichette dei prezzi: L’elenco dei prezzi praticati dal cliente quando fornisce i beni (e eventualmente i servizi associati). Questo elenco è importante perché la politica attuale di pricing del cliente potrebbe differire da quanto addebitato in passato. I prezzi più recenti influenzano la domanda futura, ma anche la redditività delle decisioni della supply chain. Promozioni, sconti sui prezzi o opzioni di pricing potrebbero anche essere presenti. Tutti gli elementi che contribuiscono al calcolo di ciò che viene addebitato ai clienti sono rilevanti.

Gli snapshot dei livelli di stock passati, delle etichette dei prezzi passate e degli ordini di acquisto in sospeso passati sono anche rilevanti per la maggior parte degli scopi della supply chain (tuttavia, questi dati sono raramente disponibili nei sistemi aziendali). Non appena è in atto un sistema di estrazione dati, tali snapshot possono essere implementati all’interno di Lokad stesso - senza intervento diretto del dipartimento IT del cliente.

Anche se questo elenco è già considerevole, quando si tratta di aziende di solito ci sono più fonti di dati rilevanti di quanto elencato qui. Come regola generale, se un’informazione è utile per la divisione della supply chain, è molto probabilmente rilevante per scopi di ottimizzazione predittiva e dovrebbe essere indirizzata a Lokad.

Schema prioritizzato dei dati preparati

L’elenco delle tabelle di dati potenzialmente rilevanti citate sopra non è destinato a sovraccaricare. In pratica, è importante identificare quali tabelle sono necessarie per avviare l’iniziativa alla produzione, rispetto a quelle che sarebbero piacevoli da avere. È anche importante priorizzare correttamente le estrazioni al fine di consentire ai supply chain scientist di passare dalla fase di estrazione dati a quella di ottimizzazione.

Pertanto, come parte della nostra pratica della supply chain, Lokad raccomanda che i supply chain scientist producano uno schema prioritizzato dei dati preparati e condividano questo documento con il dipartimento 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. Questo documento elenca anche le priorità rispettive di tutti i campi richiesti.

Questo schema fornisce un elenco di desideri ad alto livello per i dati da estrarre. Tuttavia, questo documento non dovrebbe essere frainteso come una specifica per i file generati nella fase di estrazione dati. I supply chain scientist sono responsabili della preparazione dei dati. È accettabile (e comune) se lo schema dei dati, reso disponibile dal sistema di estrazione dati, differisce ampiamente dallo schema “idealizzato” associato ai dati preparati. Questo punto viene ripreso in maggior dettaglio nella sezione “Estrazioni transazionali grezze” di seguito.

Profondità storica dei dati

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

In generale, raccomandiamo di estrarre l’intera storia disponibile per tutte le tabelle che hanno meno di 1 miliardo di righe. Modificare la storia si traduce nella perdita di dati che potrebbero essere rilevanti per valutare l’evoluzione a lungo termine della supply chain. I filtri saranno implementati dal lato di Lokad come parte della preparazione dei dati, comunque, quindi trasferire più dati non si traduce necessariamente in più risorse di calcolo per Lokad.

Per quanto riguarda la profondità storica, non c’è un requisito minimo. Se la storia del sistema è breve (ad esempio, sei mesi), allora certi modelli 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 qualsiasi profondità storica disponibile, anche se potrebbe sembrare scarsa al cliente.

Dati mancanti

Mentre i moderni sistemi aziendali sono tipicamente estesi, c’è inevitabilmente molta dati che sembrano mancare. Poiché i dati sono percepiti come mancanti, la fattibilità dell’iniziativa quantitativa della supply chain è messa in discussione. Tuttavia, non importa quanto dati sembrino essere “mancanti”, i dipendenti all’interno dell’organizzazione riescono comunque a prendere le decisioni necessarie affinché la supply chain funzioni. In breve, c’è un modo. 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 software aziendale tradizionale che ha requisiti finali sui dati e non funzionerà a meno che non siano soddisfatti tutti i requisiti.

Nella nostra esperienza, ci sono due ampie classi di dati “mancanti” che dovrebbero essere distinti: in primo luogo, dati che dovrebbero essere integrati nel sistema aziendale; in secondo luogo, dati che si pensa siano molto utili per il sistema analitico (come Lokad).

Le quantità minime d’ordine (MOQs), gli sconti quantitativi e le settimane di chiusura dei fornitori sono dati che spesso mancano nei sistemi aziendali. Tuttavia, questi dati sono preziosi dal punto di vista dell’ottimizzazione della supply chain. Tali dati potrebbero essere dispersi tra fogli di calcolo ed email, impedendo qualsiasi analisi strutturata diretta dal lato di Lokad. Di fronte a queste situazioni, suggeriamo di utilizzare euristiche (da codificare da Lokad) e di utilizzare fogli di calcolo ad hoc (da caricare su Lokad). Una volta che la ricetta numerica diventa operativa, Lokad coinvolgerà il dipartimento IT del cliente per integrare i dati nel/i sistema/i aziendale/i. Inoltre, la ricetta numerica stessa chiarisce quali dati siano veramente importanti e in che misura.

I dati sull’intelligence competitiva, come i prezzi dei concorrenti, sono una categoria ritenuta molto utile ma, nella nostra esperienza, questo non è ovvio. Aneddoticamente, ottenere questo tipo di dati spesso comporta un costo sostanziale, 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. Tutto il lavoro di preparazione dei dati dovrebbe essere delegato alla piattaforma di Lokad, che è stata appositamente progettata per la preparazione dei dati.

Tentare di preparare i dati porta inevitabilmente alla perdita di dati. Se questa perdita è accettabile o meno dipende dalle specifiche decisioni della supply chain di interesse. Se i dati sono già persi quando raggiungono la piattaforma di Lokad, non c’è nulla che si possa fare per recuperare questa perdita. Le estrazioni transazionali grezze garantiscono che l’intera informazione disponibile nei sistemi aziendali diventi accessibile all’interno di Lokad.

Inoltre, la preparazione dei dati introduce il proprio strato di complessità sopra la complessità dei sistemi aziendali stessi. Va bene, la ricetta numerica che fornisce l’ottimizzazione della supply chain desiderata non può evitare di affrontare classi di complessità intrinseca. Tuttavia, se questa ricetta numerica deve anche far fronte alla complessità accidentale introdotta dalla preparazione dei dati precedente, trasforma un problema già difficile in uno irragionevolmente difficile. Le estrazioni transazionali grezze garantiscono che Lokad non finisca per affrontare un problema ancora più grande di quello che deve risolvere.

Dal punto di vista IT, le estrazioni transazionali grezze sono semplici. Dovrebbero essere utilizzate copie di tabelle semplici (ad esempio, SELECT * FROM MyTable), che è la forma più semplice di query su un database relazionale. Tali query sono semplici, poiché non ci sono filtri coinvolti, e performanti, poiché non ci sono join coinvolti. Tabelle molto grandi richiedono comunque un’attenzione dedicata. Questo punto è trattato di seguito.

Se è presente un data lake, allora il data lake dovrebbe riflettere i dati relazionali come si trovano nei sistemi aziendali. Tutti i sistemi di database principali hanno capacità di riflessione integrate. Consigliamo di approfittare di queste capacità durante la configurazione del data lake. Inoltre, riflettere i dati è molto più semplice rispetto alla preparazione dei dati - specialmente dal punto di vista del reparto IT, poiché la preparazione dei dati dipende fortemente dal problema specifico da affrontare.

L’antipattern di estrazione BI

I dati da inviare a Lokad non dovrebbero provenire da una fonte secondaria (ad esempio, un sistema di Business Intelligence (BI)) dove i dati sono già stati ampiamente modificati, di solito a beneficio del consumo diretto da parte dell’utente finale. Anche se l’estrazione dei dati da un sistema BI è più semplice rispetto a un ERP, questo porta inevitabilmente a problemi irrisolvibili in seguito. Per progettazione, gli aspetti transazionali dei dati vengono persi, poiché i dati vengono aggregati in serie temporali giornaliere / settimanali / mensili.

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

Dati non validi

Nell’esperienza di Lokad, i casi di dati non validi sono rari. Al contrario, i sistemi aziendali transazionali (come gli ERP) di solito hanno dati accurati. Gli inserimenti di dati transazionali errati sono rari e di solito si verificano una o due volte ogni 1000 inserimenti. Quando vengono utilizzati codici a barre o dispositivi simili, il tasso di errore è ancora più basso. Il vero problema risiede nel software che fa supposizioni errate sui dati, piuttosto che nei dati stessi che sono cattivi.

I livelli di stock in negozio per grandi reti di vendita al dettaglio B2C sono quasi sempre inaccurati. Tuttavia, dal punto di vista di Lokad, questa situazione è un caso di dati rumorosi, non di dati non validi. 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, abbracciando l’incertezza anziché respingerla.

In definitiva, i sistemi di Lokad sono stati progettati per ricevere dati e consentire al cliente di gestire la propria supply chain senza preoccuparsi di questi problemi. Lokad stabilisce una semantica dei dati per affrontare questi problemi e questo rappresenta la parte più impegnativa della fase di preparazione dei dati.

Dati personali

Un’iniziativa di supply chain quasi mai ha bisogno di dati personali per funzionare. Quindi, dal punto di vista della supply chain, consigliamo di trattare i dati personali come un passivo, non come un’attività. Sconsigliamo vivamente 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 esempio, nome, indirizzo, numero di telefono, email, ecc.).

Questi identificatori personali possono essere sostituiti da identificatori anonimi opachi - se le informazioni sono rilevanti dal punto di vista della supply chain. Ad esempio, gli identificatori clienti opachi sono utili perché consentono a Lokad di identificare modelli legati alla fedeltà del cliente - come l’impatto negativo delle scorte esaurite. 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 sulle Informazioni di Identificazione Personale (PII), questo argomento è affrontato nelle Sezioni 1, 3 e 4 del nostro documento sulla sicurezza.

Dati finanziari

Gli importi monetari per beni acquistati, trasformati e venduti dal cliente sono di primaria importanza per l’ottimizzazione della supply chain fornita da Lokad. In effetti, Lokad enfatizza una prospettiva finanziaria sulla supply chain che ottimizza dollari di ritorno rispetto a percentuali di errore.

A differenza dei fornitori che considerano solo i dati relativi alle quantità di magazzino, Lokad utilizza i dati finanziari del cliente - se resi disponibili. Logicamente, i costi di supply chain più preoccupanti sono concentrati agli estremi; una domanda inaspettatamente alta genera scorte esaurite; e una domanda inaspettatamente bassa genera svalutazioni dell’inventario. Nel frattempo, l’inventario ruota bene. Quindi, per ottimizzare veramente le decisioni sull’inventario, è necessario fare un compromesso finanziario riguardo a questi rischi. Lokad sfrutta i dati finanziari del cliente per calcolare un compromesso adeguato.

Pipeline dati vs estrazione one-shot

Una pipeline di estrazione dati aggiorna automaticamente i dati trasferiti a Lokad. Questa configurazione rappresenta uno sforzo maggiore rispetto a un’estrazione dati one-shot. Se possibile, consigliamo vivamente di automatizzare l’estrazione dei dati, eventualmente con un approccio graduale se il numero di tabelle rilevanti è elevato. Questa automazione funziona meglio se installata dal Giorno 1. Tuttavia, estrazioni parziali one-shot utilizzate per identificare tabelle rilevanti possono essere utili. Questo punto è discusso nei passaggi seguenti.

Ci sono tre motivi principali per sostenere un approccio di pipeline dati.

In primo luogo, dal punto di vista del praticante di supply chain, i dati vecchi di 3 settimane sono storia antica. I risultati ottenuti da dati obsoleti sono irrilevanti per quanto riguarda le decisioni sulla supply chain odierne. Un’estrazione one-shot produrrebbe risultati basati su un singolo istantanea della storia aziendale del cliente. Ciò produrrebbe risultati di valore limitato. Inoltre, i praticanti di supply chain devono vedere il sistema analitico in azione per acquisire fiducia nella sua capacità di gestire la variabilità quotidiana.

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

Di solito sono necessarie numerose esecuzioni programmate per perfezionare il processo di estrazione, poiché alcuni problemi si presentano solo intermittentemente. Il modo più sicuro per risolvere questi problemi è iniziare a eseguire la pipeline dati il prima possibile, consentendo così a Lokad di identificare e risolvere eventuali problemi. In particolare, le esecuzioni programmate sono anche una delle opzioni più sicure per valutare le prestazioni end-to-end dell’intera sequenza di processi, compresi quelli che portano alla fornitura di decisioni sulla supply chain consigliate.

Terzo, nella nostra esperienza, la causa più frequente di ritardi nelle iniziative quantitative di supply chain è il ritardo nella configurazione della pipeline di estrazione dati. Riconosciamo che i dipartimenti IT sono spesso sotto molta pressione per consegnare molti progetti e la costruzione di una pipeline di estrazione dati è un’altra attività con cui devono confrontarsi. Quindi, è allettante - per il dipartimento IT - posticipare la parte della pipeline, optando invece per iniziare con una serie di estrazioni one-shot. Sebbene questo approccio sia valido, presenta il rischio di introdurre ritardi nell’iniziativa, oltre a impedire a Lokad di identificare intere classi di problemi potenziali il prima possibile (come descritto nel paragrafo precedente).

Frequenza di estrazione dei dati

Raccomandiamo di aggiornare tutte le pipeline dei dati - i segmenti di estrazione, così come i segmenti analitici - almeno una volta al giorno, anche quando si tratta di calcoli mensili o trimestrali. Questo potrebbe sembrare controintuitivo, ma, nella nostra esperienza, gli aggiornamenti automatizzati frequenti sono l’unico modo per ottenere un processo end-to-end altamente affidabile.

Per la maggior parte delle situazioni di supply chain, raccomandiamo una routine di estrazione che fornisca un quadro completo dei dati fino alla chiusura dell’attività del giorno corrente (ad esempio, estrarre il giovedì sera tutti i dati storici pertinenti fino alla chiusura dell’attività del giovedì). La pipeline di estrazione dati viene eseguita alla fine della giornata lavorativa, e l’elaborazione analitica - all’interno della piattaforma Lokad - segue. I risultati freschi sono disponibili fin dall’inizio del giorno lavorativo successivo.

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

Quando i dati sono troppo grandi per essere ricaricati su Lokad per intero ogni giorno, dovrebbero essere utilizzati 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 attuale. Seguire questa regola è importante per garantire l’alta affidabilità della soluzione Lokad.

La pipeline di estrazione dati fallirà di tanto in tanto - indipendentemente da Lokad. Nella nostra esperienza, anche i dipartimenti IT eccellenti subiscono 1-2 fallimenti della pipeline all’anno. Quando il caricamento giornaliero fallisce, l’ultimo giorno di dati è compromesso. Se ogni caricamento giornaliero copre solo un giorno (senza sovrapposizione tra i caricamenti), Lokad si trova con un’intera storia dei dati parzialmente corrotta. Correggere questa storia, dal lato di Lokad, richiede un secondo intervento manuale da parte del dipartimento IT, oltre a correggere qualunque cosa abbia impedito alla pipeline di estrazione dati di funzionare correttamente in primo luogo. Questa “correzione della storia dei dati” è probabile che venga ritardata di alcuni giorni - poiché si tratta di un’operazione insolita per il dipartimento 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 attuale, un’esecuzione giornaliera fallita della pipeline di estrazione dati beneficia di un completo recupero il giorno successivo. Infatti, poiché la pipeline di estrazione dati fa parte delle operazioni di routine coperte dal dipartimento IT, ripristinare lo stato normale delle operazioni è probabile che avvenga entro un giorno lavorativo. Questo recupero non richiede alcuna interazione specifica tra il dipartimento IT e il personale di supporto di Lokad o gli utenti finali della soluzione Lokad. La correzione dei dati viene automaticamente fornita attraverso le sovrascritture che avvengono su base giornaliera coprendo la finestra temporale 2+1.

La regola 2+1 riflette un compromesso basato sull’esperienza di Lokad: più lunga è la finestra temporale, più resiliente diventa la pipeline di estrazione dati contro problemi transitori. Sebbene possiamo sperare che eventuali problemi con la pipeline di estrazione dati possano essere risolti entro un giorno lavorativo, il dipartimento IT potrebbe avere questioni più urgenti. Infatti, il fallimento della pipeline di estrazione dati potrebbe essere solo un sintomo di un problema più grave che il dipartimento IT priorizza risolvere. Pertanto, il recupero potrebbe richiedere alcuni giorni. La regola 2+1 garantisce che finché il dipartimento IT riesce a risolvere la pipeline entro due settimane, le operazioni possono riprendere come al solito con il minor impatto sull’iniziativa di ottimizzazione possibile. Tuttavia, se la finestra temporale è troppo lunga, il caricamento incrementale diventa troppo pesante in termini di risorse di calcolo, 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 le ultime due mesi completi, più quello attuale.

Identificare le tabelle e le colonne rilevanti

La stragrande maggioranza del software aziendale è costruita su database relazionali. Mentre le API web potrebbero esistere, nella nostra esperienza, tali API raramente offrono prestazioni soddisfacenti quando si tratta di estrazioni complete della cronologia programmata. Al contrario, interrogare direttamente il database tramite SQL spesso si dimostra sia semplice da implementare che abbastanza performante, poiché le query SQL consigliate da Lokad non richiedono alcun join da eseguire.

Pertanto, una volta che un sistema aziendale (ad esempio, un ERP) è stato considerato una fonte di dati rilevante per l’iniziativa e assumendo che il database relazionale sottostante possa essere accessibile, è necessario 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 non sono rilevanti per l’iniziativa della supply chain. Come regola generale, un’iniziativa della supply chain raramente ha bisogno di più di una dozzina di tabelle per iniziare e solo alcune dozzine per ottenere un alto grado di copertura dei dati.

Se l’azienda ha accesso a 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 c’è un esperto, l’ingegnerizzazione inversa del database per identificare le aree di interesse può essere tipicamente fatta in una settimana o due (anche in presenza di un sistema piuttosto complesso). Oltre a sfruttare qualsiasi documentazione tecnica accessibile 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 all’interno di un foglio di calcolo. Le tabelle potenziali possono essere identificate dai loro nomi e dimensioni. Suggeriamo di iniziare con un’ispezione più ravvicinata delle tabelle più grandi, poiché è lì che di solito si possono scoprire le più rilevanti (per un’iniziativa ottimizzata della supply chain). Per ispezionare una tabella, suggeriamo un’ispezione visiva di alcune dozzine di righe di dati. Le osservazioni dovrebbero essere 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 file e trasferimenti

La piattaforma Lokad supporta formati file di testo semplici, formati file flat (tipicamente formati CSV o TSV) così come fogli di calcolo Microsoft Excel, sia per operazioni di lettura che di scrittura. La sezione Leggi e Scrivi File documenta le capacità di I/O di Lokad. Sebbene Lokad supporti un insieme piuttosto diversificato di opzioni di formattazione, raccomandiamo quanto segue:

• Testo semplice è utilizzato al posto dei fogli di calcolo (vedi discussione qui sotto).
• La prima riga contiene gli header delle colonne e corrisponde ai nomi originali delle colonne.
• I nomi delle colonne non contengono spazi bianchi o trattini.
• Viene utilizzato UTF-8 per la codifica dei caratteri.
• Il punto (.) è il separatore decimale per i numeri frazionari.
• Tutte le date condividono lo stesso formato tra le tabelle.
• Le cifre monetarie 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.

Quando un file flat estratto è più grande di 100MB, raccomandiamo di comprimere il file utilizzando GZIP.

Per quanto riguarda i trasferimenti, raccomandiamo di utilizzare SFTP con autenticazione a chiave pubblica.

Tabelle partizionate

Raccomandiamo di partizionare le tabelle troppo grandi per essere comodamente ricaricate su Lokad per intero su base giornaliera. La partizione di solito consente caricamenti incrementali se la partizione riflette l’età dei dati. Come regola generale, le tabelle con meno di 1 milione di righe di solito non valgono lo sforzo necessario per partizionarle.

Quando si partiziona una tabella in un elenco di file, il modello di denominazione file consigliato consiste nel raccogliere i file in una sottocartella dedicata all’interno di /input (chiamata come la tabella rispettiva), e nel suffisso di ciascun 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 hanno lo stesso valore “data” (corrispondente a quello trovato nel nome del file), raccomandiamo di mantenere questa colonna “data” come parte del file.

Microsoft Excel

La piattaforma Lokad supporta la lettura dei dati da fogli Microsoft Excel, purché il foglio segua un formato tabellare (la prima riga contiene gli header, quindi un record per riga). Tuttavia, il flusso di estrazione dati dovrebbe evitare il trasferimento dei fogli a Lokad.

I fogli sono accettabili se i file vengono caricati manualmente su Lokad, anziché essere trasferiti attraverso il flusso di estrazione dati automatizzato. 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 file caricati manualmente.

Sovrascrittura dei file

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

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

• una singola colonna chiamata UltimoTrasferimento
• una singola riga di dati (due righe contando 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

Il flusso di estrazione dati deve funzionare in modo affidabile. La piattaforma Lokad stessa può essere utilizzata per strumentalizzare l’output del flusso di estrazione dati e valutare l’integrità, completezza e freschezza dei dati estratti. Quindi, come primo passo del flusso all’interno di Lokad, raccomandiamo di implementare dashboard sulla salute dei dati. Questi dashboard sono destinati al dipartimento IT (anche se non ci si aspetta che se ne occupino). Lo scopo collettivo dei dashboard è quello di delineare eventuali problemi di dati e accelerare la risoluzione finale da parte del dipartimento IT. Questa implementazione, come il resto della ricetta numerica che guida l’iniziativa di ottimizzazione della supply chain, dovrebbe essere eseguita da un esperto di supply chain, eventualmente dal team Lokad (nel caso di un abbonamento Platform+Experts).

Specifica dell’estrazione dati

Una volta che il flusso di estrazione dati è stato stabilizzato, raccomandiamo di produrre una specifica per l’estrazione dati. Questo documento dovrebbe elencare tutti i file previsti e le loro colonne, nonché il programma per l’estrazione dati. La stabilizzazione del flusso dati è prevista entro sei mesi dall’avvio dell’iniziativa. Questo documento dovrebbe essere concordato congiuntamente dal dipartimento IT e dal dipartimento di supply chain. Questo documento contiene i dettagli dei dati che si prevede siano resi disponibili, in modo tempestivo, dal dipartimento IT alla piattaforma Lokad.

Il formato dei dati può ancora essere rivisto in un secondo momento, ma ci si aspetta che il dipartimento IT notifichi il dipartimento di supply chain prima di apportare qualsiasi modifica al formato dei dati o al programma associato. In generale, una volta che la specifica è stata concordata, ci si dovrebbe aspettare che le operazioni della supply chain si basino, per fini produttivi, sull’integrità dell’estrazione dati. Pertanto, in caso di eventuali cambiamenti, il dipartimento di supply chain dovrebbe aspettarsi un “periodo di grazia” ragionevole sufficiente per aggiornare la logica all’interno di Lokad (per adattarsi al formato dati rivisto).

Poiché la produzione di una specifica dettagliata richiede tempo ed impegno significativi, raccomandiamo di posticipare la produzione di questo documento fino a quando il flusso dati non è stabilizzato. Nella nostra esperienza, durante i primi mesi, il flusso - sia i segmenti di estrazione dati che analitici - subisce un’evoluzione rapida. Questa rapida evoluzione è probabile che renda obsoleti i primi tentativi di produrre una tale specifica.

Ciclo di feedback

Le decisioni della supply chain (ad esempio, i rifornimenti di magazzino) generate all’interno della piattaforma Lokad possono essere esportate come file piatti per essere reintegrati nei sistemi aziendali. Questo meccanismo è chiamato ciclo di feedback. La nostra esperienza indica che il ciclo di feedback è improbabile che venga implementato entro quattro mesi dall’avvio dell’iniziativa. La fiducia nella ricetta numerica necessaria per consentire anche a una parte della supply chain di funzionare in modalità automatica è sostanziale, e questo grado di fiducia può richiedere diversi mesi per essere coltivato. Pertanto, il ciclo di feedback non è una preoccupazione all’inizio dell’iniziativa.

Nella nostra esperienza, la configurazione del ciclo di feedback è una sfida molto più piccola rispetto alla configurazione del flusso di estrazione dati. Ad esempio, le cifre, come prodotte all’interno di Lokad, sono previste come autorevoli e definitive; se ci sono ulteriori regole da applicare per trasformare quelle cifre in numeri operativi (ad esempio, MOQ applicati), allora la ricetta numerica è incompleta e necessita di correzioni dal lato Lokad. D’altra parte, la piattaforma di Lokad ha la capacità di elaborare e produrre qualsiasi forma di dati purché sia ragionevolmente tabellare. Pertanto, la semplicità del ciclo di feedback è progettata per riflettere la semplicità delle decisioni della supply chain. Ad esempio, potrebbero esserci dozzine di vincoli che definiscono se un determinato ordine di acquisto è valido o meno, ma il contenuto dell’ordine di acquisto finale è un elenco diretto di quantità associate ai numeri di parte.

Tuttavia, raccomandiamo che alla piattaforma Lokad non venga dato accesso diretto ai sistemi aziendali del cliente. Invece, i file dovrebbero essere resi disponibili in modo tempestivo all’interno del sistema file di Lokad. Il dipartimento IT rimane responsabile dell’importazione di questi dati nei sistemi aziendali. Ciò garantisce che una potenziale violazione della sicurezza dell’account Lokad non possa essere utilizzata per accedere ad altri sistemi all’interno dell’azienda. Inoltre, ciò fornisce la possibilità di posticipare questa operazione di feedback se entra in conflitto con un’altra operazione svolta dall’IT sui sistemi aziendali.

Dato che il ciclo di feedback comporta, per definizione, dati relativi alle operazioni della supply chain del mondo reale, raccomandiamo di produrre una specifica dedicata a questo processo. Questa specifica riflette quella di estrazione dati, ma con i dati che vengono trasferiti nella direzione opposta. Anche questo documento dovrebbe essere concordato congiuntamente dai dipartimenti IT e di supply chain.