Perchè è importante avere uan politica di data Quality per un datawarehouse

 

L'importanza della data quality nella organizzazione della pianificazione strategica di una azienda, è un argomento sul quale non si insiste mai abbastanza. Il Data Warehousing Institute, (TDWI), recentemente, ha stimato che problemi di Data Quality costano alle aziende (dati americani) circa 600 billion $ ogni anno! Eppure ancora le aziende insistono che non possono giustificare un investimento di questo tipo, altri non riconoscono i benefici.

Prendiamo ad esempio un datawarehouse, la sua efficacia ed il senso stesso della sua esistenza è legato alla Data Quality. Il datawarehouse in sè non opera la pulizia ed il trattamento dei dati, così se i dati non vengono puliti in ambito datawarehouse debbono essere puliti in ambito produttivo (cioè negli applicativi ERP o dipartimentali). Ma se i dati non vengono trattati, i report e qualunque altro utilizzo del datawarehouse non potrà che rimanere limitato ed inefficace (se pensiamo ai costi di sviluppo e manutenzione di un datawarehouse, possiamo già cominciare a stimare un costo di mancato utilizzo!)

Problemi di data quality

The July 1, 2002 edition of the USA Today newspaper ran an article entitled, “Spelling Slows War on Terror.” It demonstrates how hazardous data (poor data quality) can hurt an organization. In this case, the organization is the USA, and we are all partners. The article cites confusion over the appropriate spelling of Arab names and links this confusion to the difficulty U.S. intelligence experiences in tracking these suspects. The names of individuals, their aliases, and their alternative spellings are captured by databases from the FBI, CIA, Immigration and Naturalization Service (INS), and other agencies.

Figure 1: Data flow in government agencies.

Figure 1 clearly shows that the data flow between organizations is truly nonexistent. A simple search for names containing, “Gadhafi” returns entirely different responses from each data source.

Why Data Quality Problems Go Unresolved

Problems with data quality are not unique to government; no organization, public or private, is immune to this problem. Excuses for doing nothing about it are plentiful:

1. It costs too much to replace the existing systems with data-sharing capability.

2. We could build interfaces into the existing systems, but no one really understands the existing data architectures of the systems involved.

3. How could we possibly build a parser with the intelligence to perform pattern recognition for resolving aliases, let alone misspellings and misidentifications?

4. There is simply no way of projecting return on investment for an investment such as this.

Quite similarly, the USA Today article cited the following three problems, identified publicly by the FBI and privately by CIA and INS officials:

1. Conflicting methods are used by agencies to translate and spell the same name.

2. Antiquated computer software at some agencies won’t allow searches for approximate spellings of names.

3. Common Arabic names such as Muhammed, Sheik, Atef, Atta, al-Haji, and al-Ghamdi add to the confusion (i.e., multiple people share the same name, such as “John Doe”).

Note the similarity of these two lists.

Fraudulent Data Quality Problems

To further complicate matters, a recent New York Times article published July 10, 2002 confirmed that at least 35 bank accounts had been acquired by the September 11, 2001 highjackers during the prior 18 months. The highjackers used stolen or fraudulent data such as names, addresses and social security numbers.

The Seriousness of Data Quality Problems

It can be argued that, in most cases, the people being tracked are relative unknowns. Unfortunately, the problem is not as uncommon. In fact, a CIA official conducting a search on Libyan leader Moammar Gadhafi found more than 60 alternate spellings of his name. Some of the alternate spellings are listed in Table 1.

Alternate Spellings of Libyan Leader’s Surname

.

1.	Qadhafi
2.	Qaddafi
3.	Qatafi
4.	Quathafi
5.	Kadafi
6.	Kaddafi
7.	Khadaffi
8.	Gadhafi
9.	Gaddafi
10.	Gadafy

.

Table 1: Alternate spellings of Libyan leader’s surname.

In this example, we are talking about someone who is believed to have supported terrorist-related activities and is the leader of an entire country, yet we still cannot properly identify him.

Note that this example was obtained through the sampling of CIA data only-imagine how many more alternate spellings of Gadhafi one would find upon integrating FBI, INS, and other sources. Fortunately, most of us are not trying to save the world, but data quality might save our business!

Data Collection

Whether you’re selling freedom or widgets, whether you service tanks or SUVs, you have been collecting data for a long time. Most of this data has been collected in an operational context, and the operational life span (approximately 90 days) of data is typically far shorter than its analytical life span (endless). This is a lot of data¡ªwith a lot of possibilities for quality issues to arise. Chances are high that you have data quality issues that need to be resolved before you load data into your data warehouse.

Solutions for Data Quality Issues

Fortunately, there are multiple options available for solving data quality problems. We will describe three specific options here:

1. Build an integrated data repository.

2. Build translation and validation rules into the data-collecting application.

3. Defer validation until a later time.

Option 1: Integrated Data Warehouse

The first and most unobtrusive option is to build a data warehouse that integrates the various data sources, as reflected in the center of Figure 2.

Figure 2: Integrated data warehouse.

An agreed-upon method for translating the spellings of names would be universally applied to all data supplied to the Integrated Data Warehouse, regardless of its source. Extensive pattern recognition search capability would be provided to search for similar names that may prove to be aliases in certain cases.

The drawback here is that the timeliness of quality data is delayed. It takes time for each source to collect its data, then submit it to the repository where it can then be integrated. The cost of this integration time frame will be different depending on the industry you are involved in.

Clearly, freedom fighters need high quality data on very short notice. Most of us can probably wait a day or so to find out if John Smith has become our millionth customer, or whatever the inquiry may be.

Option 2: Value Rules

In many cases, we can afford to build our translation and validation rules into the applications that initially collect the data. The obvious benefit of such an approach is the expediency of access to high quality data. In this case, the agreed-upon method for translating data is centrally constructed and shared by each data collection source. These rules are applied at the point of data collection, eliminating the translation step of passing data to the Integrated Data Warehouse.

This approach does not alleviate the need for a data warehouse, and there will still be integration rules to support, but improving the quality of data at the point it is collected considerably increases the likelihood that this data will be used more effectively over a longer period of time.

Option 3: Deferred Validation

Of course, there are circumstances where this level of validation simply cannot be levied at the point of data collection. For example, an online retail organization will not want to turn away orders upon receipt because the address isn’t in the right format. In such circumstances, a set of deferred validation routines may be the best approach. Validation still happens in the systems where the data is initially collected, but does not interfere with the business cycle.

Periodic sampling averts future disasters
The obvious theme of this article is to develop thorough data rules and implement them as close to the point of data collection as feasible to ensure an expected level of data quality. But what happens when a new anomaly crops up? How will we know if it is slowly or quickly becoming a major problem?

There are many examples to follow. Take the EPA, which has installed monitors of various shapes and sizes across the continental U.S. and beyond. The monitors take periodic samples of air and water quality and compare the sample results to previously agreed-upon benchmarks.

This approach proactively alerts the appropriate personnel as to when an issue arises and can assess the acceleration of the problem to indicate how rapidly a response must be facilitated.

We too must identify the data elements that contain the most critical data sources we manage and develop data quality monitors that periodically sample the data and track quality levels.

These monitors are also good indicators of system stability, having been known to identify when a given system component is not functioning properly. For example, I’ve seen environments in retail where the technology was not particularly stable and caused orders to be held in a Pending Status for days. A data quality monitor tracking orders by status would detect this phenomenon early, track its adverse effect, and notify the appropriate personnel when the pre-stated threshold has been reached.

Data quality monitors can also be good business indicators. Being able to publish statistics on the number of unfulfilled orders due to invalid addresses or the point in the checkout process at which most customers cancel orders can indicate places where processes can be improved.

Conclusion

A sound Data Quality Strategy can be developed in a relatively short period of time. However, this is no more than a framework for how the work is to be carried out. Do not be mistaken - commitment to data quality cannot be taken lightly. It is a mode of operation that must be fully supported by business and technology alike.

Obiettivi:

Fra i vari obiettivi che vengono spesso condivisi dai responsabili di call center e di CRM, possiamo citarne due che spesso sono utilizzati come metrica anche per la valutazione delle perfomance complessive del reparto:

- Ridurre il tempo di risposta per una chiamata

- Aumentare la velocità e l'accuratezza del data entry

- Aumentare la soddisfazione del cliente, con la rapidità e l'efficacia della risposta

Fra i fattori che influenzano questo tipo di perfomance, uno fra i più rilevanti è l'applicativo utilizzato, e nell'ambito degli applicativi in uso, di cui esiste una varietà di implementazioni standard o sviluppate ad hoc, la capacità di trattare correttamente e velocemente i dati in modo accurato è sicuramente uno dei tratti distintivi.

Oggi questa capacità è lasciata spesso alle modalità implementative selezionate in fase di analisi, in cui spesso viene dimenticato un aspetto fondamentale che invariabilmente ri-emerge come una miriade di piccoli e grossi problemi quando l'attività del call center è già iniziata. Questo aspetto fondamentale è la Data Quality.

Problemi di Data Quality in ambito call center:

Sono molti i sintomi che indicano che il call center nel suo complesso, non adotta una politica di Data Quality:

- estrazioni complessive delle anagrafiche, riportano ripetizioni, dati incompleti e molti errori di digitazione

- parte, o gran parte, degli indirizzi postali presenti in anagrafica risultano inutilizzabili per la spedizione postale o anche solo la segmentazione territoriale (errori, CAP, Province errate)

- i tempi di data entry di un indirizzo sono alti, e l'operatore sottoposto a pressione, non è in grado di garantirne la qualità (o lascia il cliente in attesa)

- è difficile ottenere un aggancio veloce ed efficace ai dati del cliente che sta chiamando, senza chiedere tutti i suoi dati o perdere molto tempo

- l'operatore non è in grado di riconoscere utenti appartenenti a gruppi famigliari, se cambia il nome fornito dall'utente l'anagrafica non riconosce ad esempio marito-moglie come lo stesso cliente ...

- la reportistica del call center non riesce ad attuare analisi che vadano oltre i parametri basilari del numero di chiamate ricevute od inviate

si tratta di una moltitudine di micro problemi quotidiani, che vengono ripetuti per ogni operatore, per ogni chiamata. La somma di tutto il tempo speso diventa quindi un parametro di spesa rilevante per il reparto.

Politiche di Data Quality in ambito call center:

Applicare la Data Quality nel proprio call center, significa principalmente adottare una metodologia di gestione del dato, che garantisca che:

- tutti i dati necessari allo svolgimento dell'attività del call center siano facilmente ed efficacemente raggiungibili in tempi brevi (dall'operatore, e in definitiva dal cliente)

- tutti i dati inseriti nell'ambito della attività del call center siano "certificati", cioè verificati in fase di inserimento (da parte dell'operatore) ed agganciati ai dati esistenti in modo coerente

.

Poichè ogni call center dispone della propria tecnologia, da Siebel e SAP in giù fino ad applicativi autoprodotti, e passando per sistemi forniti dai vari vendor. La capacità operativa delle aziende sull'applicativo di call center è sempre limitata, da fattori di tempo di costo e di complessità.

Esiste però una dimensione di azione che presenta una drastica riduzione dei problemi, a fronte di uno sforzo minimo. Si tratta della dimensione dei dati, cioè la capacità di agire a livello della anagrafica clienti/chiamate.

.

Strumenti e risoluzione dei problemi di data Quality

.

Ecco quindi come attraverso un utilizzo accorto di specifiche politiche di Data Quality sulla propria anagrafica, la musica può cambiare in modo radicale. Questi strumenti agiscono a livello di Data Management, e possono con prospettive differenti aiutare ad ovviare o forse risolvere i suddetti problemi:

- certficazione del Data Entry (normalizzazione, deduplica, referenziazione): in questo approccio, attraverso la integrazione del proprio applicativo call center nella sua fase di Data Entry, si consente all'operatore di digitare un indirizzo ed anagrafica in tempi brevissimi, con una certificazione dell'input immediata!

- trattamento dati batch (normalizzazione, deduplica e referenziazione): in questo approccio, si trattano i dati della propria anagrafica in separata sede dalla fase di data entry, e si garantisce una elaborazione e certificazione/validazione dei dati a posteriori. (Questo approccio non impatta la fase di data entry)

- customer data integration: in questo approccio, il più completo, viene costruita una anagrafica completa, referenziata e validata di tutti i clienti ed i dati cliente, che consente sia in fase di utilizzo (da parte di degli operatori durante le chiamate), sia in fase di analisi l'accesso veloce, efficace e certificato ai dati

.

.

.

.