Dopo tanto tempo sono tornato a scrivere su questo blog, perché volevo davvero raccontarti di come ho aiutato un cliente che si occupa di logistica a ridurre l’attività di data-entry sfruttando meglio i propri dati!
Alias: utilizzare al meglio i propri collaboratori ed ottenere meno errori durante la ripetizione dei dati!
La necessità di ridurre il lavoro di data entry.
Spesso i processi all’interno di questo settore sono ancora manuali, in quanto molti piccoli produttori non hanno le forze per adeguarsi alla tecnologia attuale.
Di conseguenza il cliente spesso deve impiegare molte persone per eseguire data entry di informazioni, prenotazioni, ed altro, che arrivano tramite numerosi documenti PDF in una casella di posta da parte dei produttori che vogliono avviare le pratiche di spedizione.
Quindi per ottimizzare i processi, e anche valorizzare il lavoro delle persone, abbiamo deciso di progettare una soluzione software che si adattasse ai sistemi di comunicazione dei piccoli produttori.
L’obiettivo era pertanto ridurre l’attività di data-entry sfruttando meglio i dati che il cliente aveva già a disposizione.
Insieme abbiamo deciso di usare i sistemi OCR per ottenere le informazioni riportate nei documenti e inserirle nel flusso di lavoro già presente.
Ho quindi realizzato un proof of concept utilizzando un’architettura formata dall’esecuzione di processi python su un server linux, database SQL Server 2019 (in quanto già usato in azienda, e di facile integrazione con python), il tutto orchestrato da uno schedulatore Airflow.
Come funziona il processo sviluppato?
Il processo fondamentalmente esegue la scansione periodica di un indirizzo mail al quale arriva la documentazione dei produttori. Di conseguenza scarica i PDF assieme ad una copia del messaggio in un’area di stage sul file system del server linux.
Dopo ciò il processo converte i PDF ad una risoluzione standard, ed utilizza un OCR zonale in cloud per estrarre i dati contenuti in aree specifiche del documento.
Per ogni coppia di produttore e tipo di documento, abbiamo infatti realizzato in partenza una mappatura andando a creare un file XML necessario al servizio OCR.
Tale file di mapping contenente tutte le aree da analizzare formate dalle loro coordinate ed un’etichetta necessaria alla lavorazione successiva per identificare il dato contenuto in un’area.
Il processo poi converte il dato restituito dall’OCR in formato JSON. La struttura è costituita da un array di coppie chiave-valore. La chiave è infatti derivata dall’etichetta assegnata all’area analizzata dall’OCR (restituita poi nella risposta assieme al valore letto), ed il valore è costituito dal risultato della lettura in tale area.
Tra i dettagli nella risposta spesso c’è anche il grado di confidenza della correttezza del risultato.
Di conseguenza il documento JSON così creato viene storicizzato all’interno di una tabella di SQL Server pronto per le lavorazioni successive tramite le funzionalità di manipolazione dei formati JSON.
Perché proprio il formato JSON?
Il passaggio dal formato JSON è necessario perché il dato è in un formato semi-strutturato: la struttura varia in funzione del tipo di documento esaminato (ad esempio la fattura contiene dati diversi dal documento di trasporto, ecc…).
Per ogni digitalizzazione infatti, il processo inserisce un record in una tabella di SQL Server utilizzata per tutti i tipi di documento.
Oltre alle informazioni di contesto come produttore o data, la tabella contiene il JSON del documento stesso ed una chiave utile per capire a quale tipologia di documento si riferiscano i dati inseriti.
Perché non delle semplici tabelle?
Volevamo che il sistema fosse flessibile al punto di non comportare cambiamenti strutturali delle tabelle per far fronte a cambiamenti nelle strutture dati dei documenti.
Se infatti avessimo voluto mantenere una classica struttura tabellare saremmo finiti con l’avere tabelle diverse per tipi di documento diversi proprio perché informazioni tratte da un tipo di documento differiscono radicalmente da quelle di un altro tipo.
Il numero di tabelle sarebbe cresciuto al crescere dei tipi di documento gestiti dal software. Ed un eventuale cambiamento nelle informazioni del documento avrebbe necessariamente richiesto una modifica alla struttura della tabella.
Con il formato JSON invece abbiamo risolto questo inconveniente con enormi vantaggi per mantenibilità applicativa e sviluppi futuri.
E come orchestriamo il tutto?
Il processo descritto viene quindi sviluppato in 3 step:
- scansione mail e download in area di stage,
- preparazione e standardizzazione documenti PDF o immagini
- utilizzo del servizio OCR per lettura dati e persistenza in SQL Server.
Per coordinare questi step abbiamo utilizzato Airflow, uno schedulatore open source scritto in python che permette di definire dei grafi aciclici.
In pratica è possibile modellare un insieme di task e definirne l’ordine e le relazioni.
Ogni task può eseguire diverse azioni tra le quali l’esecuzione di uno script python. Per cui abbiamo realizzato 3 task in sequenza, ciascuno dei quali invoca lo script python per l’esecuzione di uno degli step sopra descritti.
Per ora niente real time o gestione dello stream dei dati: per la mole che abbiamo in carico sarebbe solo una complicazione.
Perché non abbiamo fatto tutto in un unico step?
Per testabilità, per poter parallelizzare un domani il lavoro ed anche perchè un buon processo ETL deve essere ripetibile.
I 3 step infatti trasformano l’intero sistema portandolo ad uno stato finito al termine di ogni lavorazione.
E questo è utile in caso di failure: è possibile continuare il lavoro e ripartire dallo stato precedente. Inoltre è ripetibile.
Sviluppi futuri
Questo era un proof of concept, ma alle porte ci sono ulteriori sviluppi di cui ti parlerò in un altro articolo. Porteremo in ambiente cloud-native l’intero sistema!
Si parlerà di trasferimento degli script python in ambiente server-less. Inoltre utilizzeremo account di archiviazione in cloud per sostituire il file system utilizzato nel prototipo.
Infine, se economicamente sarà un vantaggio, svilupperemo un sistema interno di lettura del documento tramite librerie come Tesseract o similari.
I risultato al momento sono soddisfacenti sopratutto perché il cliente adesso può gestire l’importazione di documenti diversi.
Può inoltre ridurre le attività di data entry da parte del personale limitando possibili errori. Il tutto sfruttando al massimo i propri dati!
Senza dubbio un’attività molto interessante! E spero che anche tu abbia trovato interessante questo articolo!
Nel mio percorso ho raccolto molte informazioni interessanti in merito agli argomenti di cui ti ho parlato in questo articolo. Per questo ho scritto un libro intitolato “Why Your Data Matter”.
Essendo il frutto della mia passione ed esperienza diretta, ho scelto di mettere questo libro gratuitamente a disposizione di tutti gli IT Manager ed i CIO delle aziende che come te vogliono ottenere grandi risultati dalle loro scelte e dal loro lavoro (evitando di trovarsi in situazioni scomode e da risolvere con urgenza).
Ti invito a leggere le prime pagine scaricandole!
Se poi ti piacerà sarò felice di inviartene una copia GRATUITA direttamente nel tuo ufficio.
Clicca qui per scaricare l’estratto del mio libro (se ti piacerà te lo invierò in formato cartaceo!) ==> il mio libro