La migrazione di anagrafiche clienti è un’operazione sempre più frequente in ambito aziendale. Essa diventa necessaria ad esempio in caso di migrazione di sistemi operativi, di scambio dati fra sistemi diversi come il CRM verso il datawarehouse, o nell’ambito della acquisizione di aziende il che richiede il trasferimento dei clienti dal sistema acquisito al sistema corrente.
Questa operazione presenta delle criticità tipiche specialmente se l’anagrafica risulta essere abbastanza numerosa (cioè al di sopra dei 100.000 record). Una delle difficoltà che più frequentemente si incontra è la differenza di struttura dati fra il database sorgente ed il database target.
Le anagrafiche clienti rappresentano dati semi strutturati, come nomi, cognomi, ragioni sociali e indirizzi. Specialmente l’indirizzo è spesso rappresentato in grande libertà e la struttura selezionata da ogni singolo sistema è diversa dalle altre.
I sistemi informativi più moderni tendono ad avere requisiti più stringenti e rappresentano l’indirizzo in modo più dettagliato. Ecco alcuni esempi:
| DB SORGENTE | DB DESTINAZIONE | |
|---|---|---|
| INDIRIZZO | Il campo LOCALITÀ è rappresentato con un unico valore. Per esempio: INDIRIZZO: “VIA CAPRERA, 3/A” | Il campo INDIRIZZO è rappresentato in più campi separati. Per esempio: INDIRIZZO: “VIA CAPRERA” NUMERO CIVICO: “3/A” oppure: DUG: “VIA” TOPONIMO: “CAPRERA CIVICO: “3” INT: “A” |
| LOCALITÀ | Il campo LOCALITÀ, o comune, è unico e contiene il COMUNE, la FRAZIONE o entrambi: Per esempio: LOCALITÀ: “PARONA VERONA” | Il campo LOCALITÀ distingue il COMUNE e l’eventuale FRAZIONE o LOCALITÀ di dettaglio. Per esempio: COMUNE: “VERONA” FRAZIONE: “PARONA” |
| COORDINATE GEOGRAFICHE | Il sistema sorgente è privo di riferimenti geografici. | Il sistema Target utilizza le coordinate geografiche. |
| CODICI TERRITORIALI | Il sistema target potrebbe richiedere codici non presenti i input, come: CODICE ISTAT CODICE CATASTALE CODICE REMI | |
| CODICE STRADA O LOCALITÀ | Il sistema SORGENTE contiene dati testuali “liberi” non uniformati: Ad esempio: LOCALITÀ: “DESENZANO S GARDA” LOCALITÀ: “DESENZANO DEL GARDA” LOCALITÀ: “DESENZANO S GARDA” LOCALITÀ: “DESENZ. SUL G.” | Il sistema target potrebbe avere uno stradario di riferimento, in cui ogni elemento è codificato anche numericamente. Per evitare dizioni difformi della stessa località: ES: LOCALITÀ: “DESENZANO DEL GARDA” CODLOC: 12668 |
La produzione dunque dei dati necessari al sistema target può presentare delle complessità che rientrano i alcune tipologie:
Affrontare manualmente e senza un approccio questo tipo di trasformazione può rivelarsi oneroso e soprattutto essere destinata a notevoli problematiche che emergono ad una ad una durante il processo, o purtroppo come spesso avviene anche alla fine dell’operazione, quando è troppo tardi per porre rimedio.
Inoltre nel contesto di anagrafiche numerose, il numero di micro situazioni da risolvere va moltiplicato per il numero di record, il che porta ad una quantità di lavoro difficile o impossibile da portare a termine nei tempi previsti.
La normalizzazione è un’operazione che si applica ai dati semi-strutturati come quelli che compongono le anagrafiche: nomi, ragioni sociali o indirizzi.
La operazione di normalizzazione ha lo scopo di acquisire in input un’informazione data in modo libero (cioè potenzialmente contenente errori, informazioni mancanti, abbreviazioni o informazioni ridondanti) e di scontrarla (cioè verificarla) con un database di riferimento.
A seguito di tale operazione ogni elemento fornito in input viene riferito ad un elemento presente nel database di riferimento e viene di conseguenza geocodificato (se parliamo di indirizzi, ovvero ad ogni elemento viene associato un valore unico di testo ed un codice), oppure scartato.
I vantaggi di questa operazione, quando applicata agli indirizzi sono:
In conclusione sottoponendo una qualunque anagrafica ad una operazione di normalizzazione se ne ottiene una versione verificata ed arricchita, con i seguenti vantaggi:
