L’operatore di telefonia fissa ha utilizzato la soluzione di Teradata per migliorare la gestione del cliente. Il progetto, realizzato per aree tematiche in tre diverse fasi, è stato sviluppato con il contributo di applicativi Clarify, Hummingbird e Business Objects
Nata nel ’95 da un accordo strategico tra British Telecom e Banca
Nazionale del Lavoro, nel 2000 Albacom ha fatturato 677 miliardi di lire,
offrendo servizi di comunicazione indirizzati alle aziende, per l’esattezza a
oltre 95mila clienti. Avendo a che fare con questi numeri, la gestione
dell’utente rappresenta una delle aree più critiche dell’attività della società
di telefonia fissa e richiede un impianto strutturale fatto ad hoc. La società
ha quindi deciso di implementare un sistema di data warehousing per ottenere la
centralizzazione di tutti i dati, compresi i servizi, la fatturazione e così
via.
Nel marzo dello scorso anno, è stata avviata l’implementazione
della soluzione di Teradata, conclusosi a fine anno e seguita da alcuni
ritocchi per ampliare le funzionalità già utilizzate, introducendone di
nuove. Al progetto sono state dedicate a tempo pieno quattro persone di
Albacom ma il gruppo di lavoro era misto e comprendeva anche tecnici e
consulenti di Teradata/Ncr e del system integrator Cap Gemini Ernst &
Young.
L’applicativo cardine della customer care e
delivery è una soluzione Clarify mentre l’ambiente di supporto alla gestione dei
dati e dei servizi relativi al cliente è piuttosto eterogeneo e comprende anche
soluzioni di Oracle, Siebel e altri vendor. «La scelta di utilizzare un
sistema di data warehousing piuttosto corposo – ha sottolineato Cristina
Bertolo, responsabile dei progetti e delle soluzioni di data warehousing presso
Albacom – è stata, quindi, in qualche modo forzata
».
Le fasi programmate
Il progetto ha vissuto tre
distinti step. La prima fase, di business discovery, è stata condotta
attraverso interviste agli utenti. Nel corso di questa tranche, sono state
definite le aree di interesse e le necessità aziendali sulle quali
approfondire l’analisi. Per quanto attiene la parte potenzialmente di
competenza dell’area data warehouse, si è proceduto con un’operazione di
data discovery.
Evidenziatasi una specifica esigenza, si è proceduto alla
verifica dell’esistenza, all’interno del patrimonio informativo aziendale,
della disponibilità dei dati necessari a soddisfare le richieste
manifestate dagli utenti. A seguito di questo studio è nato un elenco di
gap, ovvero di esigenze che, al momento dell’analisi, non potevano essere
convogliate all’interno del progetto. L’attività di data discovery si è
rivelata portante e di peso significativo per quanto riguarda la conduzione
del progetto in quanto l’ambiente applicativo di riferimento era piuttosto eterogeneo e
l’obiettivo ambizioso. «Si è deciso di procedere
alla costruzione di un corporate data warehouse
–
ha precisato Bertolo -, anziché
affrontare specifiche aree tematiche verticali in termini di data mart. Si
è, quindi, resa necessaria la verifica di tutto il patrimonio informativo
aziendale e l’eventuale esistenza di correlazioni. Lo scopo era di dare una
visibilità complessiva alla posizione del cliente, indipendentemente
dal sistema sul quale risiedevano i dati specifici». Per avere un’idea della
complessità dell’ambiente di riferimento, basti pensare che esiste,un
sistema a supporto del processo di fatturazione in base agli ordini
(invoice-to-order) all’interno del quale vengono convogliate tutte le
informazioni di processo relative a quest’area. Accanto a ciò, coesiste un
sistema di delivery che raccoglie le informazioni relative alla
configurazione e definizione del servizio erogato al cliente. Quest’ultima
funzionalità si riallaccia, poi, al sistema di fatturazione vero e
proprio. «Il tentativo – ha
sottolineato Bertolo – è stato quello di
recuperare tutti i dati relativi al cliente, disponibili all’interno dei
vari sistemi, per uniformare le informazioni e ottenere una visione integrata e completa della posizione
raggiunta
».
L’implementazione
A
seguito della fase di data discovery è partita l’implementazione vera e
propria, divisa per aree progettuali tematiche. Il primo step ha consentito
di organizzare la gestione del traffico, ovvero il flusso di dati relativo a
clienti, ordini e access method.
Quest’ultimo è l’elemento che permette ad
Albacom di ricondurre il traffico al singolo cliente, sito o servizio.
Sostanzialmente, nella maggioranza dei casi, tale elemento coincide con le
Cli (le linee telefoniche), in altri casi si tratta di numerazioni non
geografiche come i numeri verdi. I dati di traffico sono caricati su base
giornaliera, entro la mezzanotte, e sono disponibili già il mattino
successivo, classificati sulla base di dimensioni significative quali il
cliente, i prefissi chiamanti o chiamati, la fatturabilità o meno del
servizio. La seconda parte, vale a dire il cuore del corporate data
warehouse, ha permesso di razionalizzare il flusso dei dati relativi a
valorizzazione di fatture, crediti complessivi, scoperti, verifica dei
crediti in scadenza e dell’anzianità degli stessi. Su questa base
informativa sono state sviluppate applicazioni di front end specifiche per
l’analisi del traffico, del fatturato o dell’ordinato.
L’architettura
Il database utilizzato è una
macchina Unix System 5 con architettura Ncr Mpp (Massive Parallel
Processing) che permette ai diversi nodi, collegati tra loro, di funzionare
come un solo server ed eseguire i processi in parallelo. Il motore
relazionale è stato fornito da Teradata e ha una potenza di elaborazione
pari a 1 Tb di dati. In abbinamento alla soluzione della controllata di Ncr
sono stati utilizzati alcuni application server. Su uno è stato installato
il prodotto di Etl (Genio di Hummingbird), con cui si gestisce
l’estrazione dati dai sistemi sorgenti, la loro trasformazione, la
pulizia e il caricamento nel database di destinazione (target). Per il
front end, invece, è stato utilizzato un application server dedicato alle
soluzioni di Business Objects, disponibili in azienda sia in modalità
client-server che Web. Di recente è stato anche implementato un altro
strumento, sempre di Business Objects (Set Analyzer) per la parte di
segmentazione dichiarativa dei clienti. I volumi giornalieri elaborati sono
più o meno dell’ordine dei 10 milioni di record, cifre relative al processo
standard di caricamento dei dati di traffico e suddivise tra fatturazione e
report di interconnessione. A ciò si aggiungono i processi di
riconciliazione col billing.
«Ci riteniamo abbastanza soddisfatti di questo periodo
iniziale
– ha concluso Bertolo -, anche se tale tipo di
progetto non si esaurisce con la prima implementazione. Le future evoluzioni
saranno indirizzate a completare alcune aree tematiche come, ad esempio, le
modalità di accesso dei clienti alla rete. Abbiamo, poi, la necessità di
mantenerci allineati con i sistemi sorgenti. Nel corso degli ultimi mesi,
infatti, abbiamo subìto evoluzioni architetturali rilevanti e, di
conseguenza, dobbiamo adeguare il data warehouse. A breve, ad esempio,
partiremo con un’analisi dell’opportunità di implementare una soluzione di
misurazione dei Kbi, Key business indicator».
