Un’architettura dati coerente e non ridondante è indispensabile per il buon funzionamento delle attività operative e di analisi. Il database unico, secondo Gartner, non è un obiettivo perseguibile, ma è possibile creare modelli “federati” con vari livelli di flessibilità.
Le informazioni sui clienti, è risaputo, costituiscono uno dei mattoni fondamentali per la costruzione di un sistema di Customer relationship management. Per la precisione, secondo Gartner si tratta di uno degli otto elementi fondanti (affiancato, tra gli altri, dalla costruzione di una precisa strategia, dall’ottimizzazione dei processi e, ovviamente, dalla tecnologia).
Un’azione di Crm che voglia avere successo si basa, secondo la definizione dell’analista, sulla "circolazione sanguigna" costituita dalla produzione, dal mantenimento e dalla diffusione delle informazioni, che alimentano, in modo integrato, tanto i sistemi di Crm operativo quanto quelli analitici. Per funzionare bene, tale flusso deve essere progettato e governato rigidamente, altrimenti si va incontro a inconvenienti seri, tra i quali, solo per citarne un paio, l’indisponibilità dell’informazione necessaria in fase operativa e i costi dovuti al mantenimento e alla duplicazione (spesso inutile) dei dati. In ultima analisi, non gestendo correttamente il mattone dell’informazione risulta impossibile stabilire un Roi per un progetto di Crm.
La percezione più immediata dei danni provocati dalla mancanza di una strategia dell’informazione corretta è presto detta: secondo un’indagine condotta lo scorso anno da Pwc su 600 aziende del mondo anglosassone (Regno Unito, Australia e Stati Uniti), nel 75% dei casi le informazioni di cattiva qualità hanno avuto un impattato finanziario negativo sul business (per i costi dovuti alla riconciliazione dei dati o, addirittura, per questioni cruciali come errori nella fatturazione).
Eppure, nonostante questo dato di fatto, spesso si continua a considerare la gestione del dato come un "dovere" frustrante, invece che un’arma di business competitiva e, nella maggior parte dei casi, le azioni sono "tattiche", focalizzate su necessità di data quality che sorgono in quel momento.
Questo approccio, ovviamente, non è sufficiente. La qualità dei dati utilizzata dai sistemi di Crm operativo (quindi inseriti e utilizzati da vendite marketing e assistenza) decade rapidamente: quando informazioni non corrette vengono inserite nell’applicazione di Crm, esse sono subito trasmesse al datawarehouse, generando un declino di qualità che si propaga, per esempio, alle applicazioni di Business intelligence che guidano scelte strategiche.
Un giusto approccio, metodologico e tecnologico, dovrebbe portare a ottenere dati "puliti" (privi di errori), coerenti (basta guardare lo stato delle anagrafiche nei diversi sistemi per rendersi conto di quanta strada c’è da percorrere), il più possibile ricchi e, ovviamente, anche aggiornati in tempo reale. A queste esigenze è legata la cosiddetta "vista unica" del cliente attraverso i vari canali di interazione.
Anche se la soluzione ideale, dal punto di vista architetturale e di management, può sembrare quella del singolo database integrato, non bisogna dimenticare che si tratta di una strada non percorribile per la maggior parte delle grandi aziende, caratterizzate da un portfolio applicativo variegato (ma anche da differenti linee di business e distribuzione geografica), con i relativi database associati. Gartner sottolinea che, in fondo, è necessario scegliere se mantenere o meno il "controllo" dell’architettura dati e del data model che sottintende alle applicazioni di Crm operativo.
Le alternative possibili
Molti scelgono di adottare il data model fisico offerto con le suite dei vendor di Crm (tra i quali l’analista annovera Oracle, PeopleSoft, Sap e Siebel). In questo caso, è necessario "riempire" il nuovo sistema e integrarlo a livello di processi con gli altri sistemi, possibilmente in modo bidirezionale e in tempo reale, utilizzando tecnologie di application integration. Ma sorge anche il problema della duplicazione che la struttura del nuovo strato applicativo impone su molti elementi relativi ai dati e alle funzionalità stesse dei sistemi esistenti.
L’alternativa, che consente di mantenere il controllo dell’architettura dati di Crm ma che, comunque, porta con sé i suoi nodi da sciogliere ed è perseguibile solo da parte delle realtà dotate delle necessarie risorse, consiste nella creazione di un data model virtuale, su cui insiste l’applicazione di Crm, e nella mappatura delle nuove applicazioni all’interno dei database esistenti. Questo approccio, tra gli altri, caratterizza le implementazioni di E.piphany e Chordiant.
Ovviamente, come tutte le categorizzazioni, anche questa è schematica, e nella realtà esistono soluzioni ibride che prevedono, per esempio, la creazione di un database fisico per le applicazioni di Crm operativo ma integrato, a livello di application server, con il customer database master esistente.
