Il Flusso di Estrazione Dati

Questo documento è destinato come guida per i dipartimenti IT per costruire un flusso di estrazione dati che preleva i dati dai sistemi aziendali esistenti e rende questi dati disponibili all’interno della piattaforma di Lokad. La configurazione di un flusso di dati è una delle prime fasi di un’iniziativa quantitativa di ottimizzazione della 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 ottimizzazione della supply chain come una che fornisce una ricetta numerica che automatizza decisioni (o almeno raccomandazioni) di fronte a sfide della supply chain. Lokad offre 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. Almeno, l’azienda dovrebbe essere in grado di rivedere questa combinazione di costi, liquidità e servizio per renderla più allineata alla sua strategia complessiva della 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 devono essere trasferiti a Lokad?
• Quale formato dovrebbe essere utilizzato per i dati?
• Quali modelli di trasferimento dovrebbero essere utilizzati per aggiornare i dati?

Mentre i problemi elencati sopra sono vari, i dati di input rilevanti sono molto simili e di solito vengono gestiti 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 flusso di estrazione dati. Nelle sezioni successive, verrà spiegato in dettaglio cosa è specificamente richiesto dal dipartimento IT.

Una volta creato il flusso di estrazione dati, gli ingegneri di 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, consigliamo di collocarli nel dipartimento della 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 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 è possibile 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 (ulteriori dettagli di seguito) e caricati nel filesystem di Lokad.

Salvo diverso accordo, 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 (ulteriori dettagli 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 consiglia di consolidare i dati transazionali in uno strato di servizio dedicato - un “data lake” - riservato esclusivamente per la fornitura di tali dati a team appropriati e sistemi analitici di terze parti (come la piattaforma di Lokad).

La creazione di un data lake non è un requisito per l’utilizzo di Lokad, ma è una potenziale architettura che facilita le operazioni per l’azienda. Vale la pena 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 rilevanti

La supply chain riguarda l’ottimizzazione delle decisioni relative al flusso di beni fisici (acquisti, trasporti, produzione, vendite, ecc.). Di conseguenza, i dati più rilevanti 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à accennato, la piattaforma di Lokad è abbastanza 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 fornitura rigorosa di ciascuna di esse.

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 per scopi 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 - dal punto di vista della supply chain - sono rilevanti. Anche le relazioni tra i prodotti - come le BOM (bill of materials) - sono rilevanti.

Storico degli ordini di vendita: L’elenco degli ordini di vendita storici del cliente. Questo elenco è importante perché le vendite sono quasi sempre il miglior indicatore 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 verrà approfondita in seguito in modo più dettagliato.) Quando possibile, è (sempre) preferibile fornire le transazioni ordine grezze, anziché aggregati giornalieri/settimanali/mensili. (Questo punto verrà discusso anche in modo più dettagliato di seguito.) Lo storico degli ordini di vendita può includere ordini in sospeso, ordini annullati, 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 indicatore per stimare i tempi di consegna dei fornitori e la loro qualità del servizio. Gli ordini di acquisto in sospeso riflettono la “scorta 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é gli 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 dei beni che avviene all’interno dell’azienda, nonché ci permettono di identificare eventuali colli di bottiglia esistenti 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 di produzione o 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 ricezione) sono rilevanti.

Livelli di stock: L’elenco di tutti gli SKU (stock-keeping unit) del cliente con il loro livello di stock attuale. 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. Possono essere presenti anche date di scadenza. Parte o tutto l’inventario può essere tracciato a livello di numero di serie. Se l’inventario seriale è in uso, l’intero elenco di numeri di serie e le relative posizioni sono rilevanti. 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 durante il servizio dei beni (e eventualmente dei servizi associati). Questo elenco è importante perché la politica di prezzi attuale del cliente potrebbe differire da quella che veniva addebitata in passato. I prezzi più recenti influenzano la domanda futura, ma anche la redditività delle decisioni della supply chain. Possono essere presenti anche promozioni, sconti o opzioni di prezzo. 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 passati 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 funzione un flusso di estrazione dati, tali snapshot possono essere implementati all’interno di Lokad stessa, senza intervento diretto del dipartimento IT del cliente.

Anche se questa lista è già considerevole, per le aziende di solito ci sono fonti di dati più rilevanti di quelle elencate qui. Come regola generale, se un’informazione è utile per la divisione della supply chain, è molto probabile che sia 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 in precedenza non è inteso come un sovraccarico. In pratica, è importante identificare quali tabelle sono necessarie per portare l’iniziativa in produzione, rispetto a quelle che sarebbe bello avere. È anche importante prioritizzare correttamente le estrazioni al fine di consentire agli scienziati della supply chain di passare dalla fase di estrazione dati a quella di ottimizzazione.

Pertanto, come parte della nostra pratica di supply chain, Lokad raccomanda che gli scienziati della supply chain 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 una lista dei desideri a livello elevato per i dati da estrarre. Tuttavia, questo documento non dovrebbe essere frainteso come una specifica per i file generati nella fase di estrazione dati. Gli scienziati della supply chain sono responsabili della preparazione dei dati. È accettabile (e comune) che lo schema dei dati, reso disponibile dal flusso di estrazione dati, differisca 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. Primo, fino a quando nel passato dovrebbe arrivare l’estrazione dei dati? Secondo, qual è la profondità storica minima necessaria affinché l’iniziativa della supply chain abbia successo?

In generale, consigliamo di estrarre l’intera storia disponibile per tutte le tabelle che hanno meno di 1 miliardo di righe. Modificare la storia significa perdere 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 esiste un requisito minimo. Se la storia del sistema è breve (ad esempio, sei mesi), allora determinati 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à di storia disponibile, anche se potrebbe sembrare scarsa al cliente.

Dati mancanti

Mentre i moderni sistemi aziendali sono tipicamente estesi, c’è sempre una grande quantità di dati che sembrano mancare. Quando i dati vengono considerati mancanti, la fattibilità dell’iniziativa quantitativa della supply chain viene messa in discussione. Tuttavia, non importa quanti dati manchino, i dipendenti all’interno dell’organizzazione riescono comunque a prendere le decisioni necessarie per far funzionare la supply chain. 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 di dati finali e non funzionerà a meno che tutti i requisiti non siano soddisfatti.

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

Le quantità minime d’ordine (MOQ), le riduzioni di prezzo 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 sparsi tra fogli di calcolo e e-mail, impedendo qualsiasi analisi strutturata diretta da parte di Lokad. Quando ci si trova di fronte a queste 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 dipartimento IT del cliente per integrare i dati nel/i sistema/i aziendale/i. Inoltre, la ricetta numerica stessa chiarisce quali dati sono veramente importanti e in che misura.

I dati di intelligence competitiva, come i prezzi dei concorrenti, sono una categoria che si ritiene molto utile ma, dalla nostra esperienza, questo non è ovvio. Aneddoticamente, ottenere questo tipo di dati spesso comporta un costo considerevole, 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 extra.

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 i dati sono già persi quando raggiungono la piattaforma di Lokad, non si può fare nulla 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 un proprio livello di complessità oltre alla complessità dei sistemi aziendali stessi. È vero che la ricetta numerica che fornisce l’ottimizzazione desiderata della supply chain non può evitare di affrontare classi di complessità intrinseca. Tuttavia, se questa ricetta numerica deve anche affrontare la complessità accidentale introdotta dalla preparazione dei dati precedente, si trasforma in un problema già difficile in uno irragionevolmente difficile. Le estrazioni transazionali grezze garantiscono che Lokad non si trovi ad affrontare un problema ancora più grande di quello che deve essere risolto.

Dal punto di vista informatico, le estrazioni transazionali grezze sono semplici. Dovrebbero essere utilizzate copie semplici delle tabelle (ad esempio, SELECT * FROM MyTable), che è la forma più semplice di query su un database relazionale. Tali query sono semplici, poiché non sono coinvolte filtri, e performanti, poiché non sono coinvolte join. Tuttavia, le tabelle molto grandi richiedono una certa 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 funzionalità di riflessione integrate. Consigliamo di sfruttare queste funzionalità durante la configurazione del data lake. Inoltre, riflettere i dati è molto più semplice rispetto alla preparazione dei dati, soprattutto dal punto di vista del dipartimento IT, poiché la preparazione dei dati dipende molto 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, 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, ciò crea inevitabilmente problemi irrisolvibili in seguito. Per definizione, gli aspetti transazionali dei dati vengono persi, poiché i dati vengono aggregati in serie temporali giornaliere / settimanali / mensili.

Inoltre, molti complicazioni rilevanti ma difficili da visualizzare, come gli ordini multi-linea, 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 errati

Nell’esperienza di Lokad, i casi di dati errati 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 errati.

I livelli di stock nei negozi per le grandi reti di vendita al dettaglio B2C sono quasi sempre imprecisi. Tuttavia, dal punto di vista di Lokad, questa situazione è 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, 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 ciò 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. Pertanto, dal punto di vista della supply chain, consigliamo di considerare i dati personali come un rischio, non come un asset. Sconsigliamo vivamente il trasferimento di dati personali alla piattaforma di Lokad. In pratica, ciò significa filtrare le colonne del database (vedi discussione di seguito) 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 opachi dei clienti sono utili perché consentono a Lokad di identificare modelli legati alla fedeltà del cliente, come l’impatto negativo delle mancanze di stock. 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 delle transazioni.

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. Infatti, 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 stock, Lokad utilizza i dati finanziari del cliente, se disponibili. Logicamente, i costi di supply chain più preoccupanti sono concentrati agli estremi; una domanda inaspettatamente alta genera mancanze di stock; e una domanda inaspettatamente bassa genera svalutazioni dell’inventario. Nel frattempo, l’inventario ruota bene. Pertanto, per ottimizzare realmente le decisioni di inventario, è necessario fare un compromesso finanziario riguardo a questi rischi. Lokad sfrutta i dati finanziari del cliente per calcolare un compromesso adeguato.

Data pipeline vs estrazione one-shot

Una pipeline di estrazione dati aggiorna automaticamente i dati trasferiti a Lokad. Questa configurazione richiede 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 fin dal primo giorno. Tuttavia, le estrazioni one-shot parziali utilizzate per identificare le tabelle rilevanti possono essere utili. Questo punto viene discusso nei passaggi seguenti.

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

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

In secondo luogo, sebbene sia difficile progettare una pipeline dati altamente affidabile, è 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 a livelli di stock aggiornati.

Di solito sono necessarie numerose esecuzioni programmate per perfezionare il processo di estrazione, poiché alcuni problemi si presentano solo in modo intermittente. Il modo più sicuro per risolvere questi problemi è iniziare ad eseguire la pipeline dati il prima possibile, consentendo 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 di supply chain consigliate.

In terzo luogo, dalla nostra esperienza, la causa più frequente di ritardi nelle iniziative quantitative di supply chain è la configurazione tardiva 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 è solo un altro compito con cui devono confrontarsi. Pertanto, è tentatore - per il dipartimento IT - posticipare la parte della pipeline, optando invece per iniziare con una serie di estrazioni one-shot. Sebbene questo approccio sia fattibile, presenta il rischio di introdurre ritardi nell’iniziativa, oltre a impedire a Lokad di identificare intere classi di potenziali problemi il prima possibile (come descritto nel paragrafo precedente).

Frequenza di estrazione dei dati

Raccomandiamo di aggiornare tutte le pipeline di 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, dalla nostra esperienza, gli aggiornamenti frequenti automatizzati 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 giovedì sera tutti i dati storici pertinenti fino alla chiusura dell’attività di 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 della giornata lavorativa successiva.

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

Quando i dati sono troppo grandi per essere ricaricati completamente su Lokad ogni giorno, è necessario 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 corrente. 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. Dalla nostra esperienza, anche i dipartimenti IT eccellenti sperimentano 1-2 fallimenti della pipeline all’anno. Quando il caricamento giornaliero fallisce, l’ultimo giorno di dati viene compromesso. Se ogni caricamento giornaliero copre solo un giorno (senza sovrapposizione tra i caricamenti), Lokad si trova con una cronologia dei dati parzialmente corrotta. Per correggere questa cronologia, dal lato di Lokad, è necessario un secondo intervento manuale da parte del dipartimento IT, oltre a correggere ciò che ha impedito alla pipeline di estrazione dati di funzionare correttamente in primo luogo. Questa “correzione della cronologia 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 influenzati negativamente, poiché alcuni dati recenti si rivelano parzialmente corrotti.

Al contrario, se ogni caricamento giornaliero copre le ultime due settimane lavorative complete, più quella corrente, un’esecuzione giornaliera fallita della pipeline di estrazione dati beneficia di un completo ripristino il giorno successivo. Infatti, poiché la pipeline di estrazione dati fa parte delle operazioni di routine coperte dal dipartimento IT, è probabile che il ripristino dello stato normale delle operazioni avvenga entro un giorno lavorativo. Questo ripristino 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 fornita automaticamente 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 problemi più urgenti. Infatti, la pipeline di estrazione dati fallita potrebbe essere solo un sintomo di un problema più grave che il dipartimento IT prioritizza nella risoluzione. Pertanto, il ripristino potrebbe richiedere alcuni giorni. La regola 2+1 garantisce che fintanto che il dipartimento IT riesce a riparare la pipeline entro due settimane, le operazioni possono riprendere come al solito con il minor impatto possibile sull’iniziativa di ottimizzazione. Tuttavia, se la finestra temporale è troppo lunga, quindi 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 100 MB di dati, suggeriamo di adottare la variante mensile della regola 2+1: la finestra temporale del caricamento giornaliero copre gli ultimi due mesi completi, più quello corrente.

Identificazione delle tabelle e delle colonne rilevanti

La maggior parte dei software aziendali è costruita su database relazionali. Sebbene possano esistere API web, nella nostra esperienza, tali API raramente offrono prestazioni soddisfacenti quando si tratta di estrazioni complete della cronologia pianificate. Al contrario, interrogare direttamente il database tramite SQL si dimostra spesso 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 sia possibile accedere al database relazionale sottostante, è 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 elevato 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, è comunque possibile eseguire l’ingegnerizzazione inversa del database per identificare le aree di interesse in una o due settimane (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, che include:

• 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ù approfondita delle tabelle più grandi, poiché è lì che di solito è possibile scoprire quelle 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 si procede con il lavoro.

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 formati di file di testo semplici (tipicamente formati CSV o TSV) così come fogli di calcolo Microsoft Excel, sia per operazioni di lettura che di scrittura. La sezione Lettura e scrittura di file documenta le capacità di I/O di Lokad. Sebbene Lokad supporti una vasta gamma di opzioni di formattazione, raccomandiamo quanto segue:

• Testo semplice viene utilizzato al posto dei fogli di calcolo (vedi discussione di seguito).
• 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.
• Punto (.) è il separatore decimale per i numeri frazionari.
• Le date condividono lo stesso formato tra le tabelle.
• Le somme di denaro 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 piatto estratto supera i 100 MB, raccomandiamo di comprimere il file utilizzando GZIP.

Per quanto riguarda il trasferimento, raccomandiamo di utilizzare SFTP con autenticazione a chiave pubblica.

Tabelle partizionate

Raccomandiamo di partizionare le tabelle troppo grandi per essere comodamente ricaricate su Lokad in modo completo su base giornaliera. La partizione consente tipicamente caricamenti incrementali se la partizione riflette l’età dei dati. Come regola generale, le tabelle che hanno 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 dei file consigliato consiste nel raccogliere i file in una sottocartella dedicata all’interno di /input (chiamata come la tabella corrispondente) 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 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 di Lokad supporta la lettura dei dati dai fogli di calcolo di Microsoft Excel, purché il foglio di calcolo segua un formato tabellare (la prima riga contiene gli header, quindi un record per riga). Tuttavia, il flusso di estrazione dei dati dovrebbe evitare di trasferire i fogli di calcolo su Lokad.

I fogli di calcolo sono accettabili se i file vengono caricati manualmente su Lokad, anziché essere trasferiti tramite 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 i file caricati manualmente.

Sovrascrittura dei file

I file all’interno del filesystem di 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 è che venga creato un nuovo file per ogni periodo (un file al giorno, 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 chiamato /input/end-of-transfer.csv che contiene:

• una singola colonna chiamata 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 avviare una sequenza di progetti che elabora i dati appena aggiornati.

Salute dei dati

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

Specifica dell’estrazione dei dati

Una volta che il flusso di estrazione dei dati è stato stabilizzato, raccomandiamo di produrre una specifica per l’estrazione dei dati. Questo documento dovrebbe elencare tutti i file previsti e le loro colonne, nonché il programma per l’estrazione dei dati. La stabilizzazione del flusso di 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 di rendere disponibili, tempestivamente, dal dipartimento IT alla piattaforma di Lokad.

Il formato dei dati può essere ancora rivisto in un secondo momento, ma ci si aspetta che il dipartimento IT informi 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 aspetta che le operazioni della supply chain si basino sull’integrità dell’estrazione dei dati per scopi produttivi. Pertanto, in caso di eventuali cambiamenti, il dipartimento di supply chain dovrebbe aspettarsi un “periodo di tolleranza” ragionevole che sia sufficiente per aggiornare la logica all’interno di Lokad (per adattarsi al formato dei 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 di dati non è stabilizzato. Sulla base della nostra esperienza, durante i primi mesi, il flusso di dati - sia l’estrazione dei dati che i segmenti 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 sulla supply chain (ad esempio, il rifornimento di inventario) generate all’interno della piattaforma di Lokad possono essere esportate come file piatti per essere reintegrate 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 una parte della supply chain di funzionare in modalità automatica è considerevole, e questo grado di fiducia può richiedere diversi mesi per essere sviluppato. Pertanto, il ciclo di feedback non è una preoccupazione all’inizio dell’iniziativa.

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

Tuttavia, raccomandiamo che alla piattaforma di Lokad non venga fornito un accesso diretto ai sistemi aziendali del cliente. Invece, i file dovrebbero essere resi disponibili tempestivamente all’interno del sistema di 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 di 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 effettuata da IT sui sistemi aziendali.

Dato che il ciclo di feedback comporta, per definizione, dati relativi alle operazioni di supply chain del mondo reale, raccomandiamo di produrre una specifica dedicata a questo processo. Questa specifica riflette quella dell’estrazione dei 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.