Nel 1910, per iniziativa di un gruppo di commercianti ed imprenditori agrari emiliani, nasce la Banca Agricola Commerciale di Reggio Emilia. Solo nel 1983, con l’acquisizione della Banca Bellinzaghi di Milano, evento che dopo oltre settant’anni di sviluppo in ambito locale ne segna la prima crescita al di fuori dell’area emiliana, l’istituto diventa Credito Emiliano, nome con il quale si avvia a compiere il secolo di vita. Oggi, con un’espansione avvenuta sia con l’apertura di nuove filiali sia attraverso l’acquisizione di piccole e medie banche locali, il Credito Emiliano, o più in breve Credem , è un gruppo di dimensione nazionale che conta (dati 1° trimestre 2008) oltre 5.300 dipendenti e più di 840 promotori che agiscono in 505 filiali e in un centinaio di centri e “credempoint” dedicati ai servizi finanziari. Questi ultimi rappresentano una componente importante della strategia di business del gruppo (che dal 1997 è ammesso al listino ufficiale della Borsa Valori di Milano) e costituiscono, nell’insieme, un’offerta globale articolata in diverse società-prodotto specializzate nel soddisfare i bisogni di una clientela avente diversi e molteplici livelli di complessità ed esigenze. Si va infatti dalla consulenza finanziaria e di gestione patrimoniale per privati e istituzioni (con Banca Euromobiliare ed altre società specializzate), all’investment banking (con Abaxbank); dal finanziamento agli investimenti (Credemleasing), al factoring (Credemfactor); dalle assicurazioni e fondi pensione (Credemvita), alla cartolarizzazione crediti (con Ariosto, società controllata al 70%).
Tenere sotto controllo le attività
Dalla necessità di tenere sotto controllo tutte queste attività, i cui livelli di rischio dipendono da una infinità di fattori diversi, nasce, detto in estrema sintesi, il grande progetto di analisi a supporto dei controlli interni che è oggetto di questo nostro “caso utente”. Come infatti
specificano Fabrizio Iotti (nella foto a sinistra), responsabile dell’area Business intelligence e Reporting del Sistema Informativo di Credem e Stefano Orsini (nella foto in basso a destra) , responsabile del progetto BIAudi (Business Intelligence per l’Auditing) che 
abbiamo congiuntamente intervistato, “occorreva razionalizzare le numerose e varie estrazioni dati che venivano eseguite in funzione di controllo dei vari aspetti, sia normativi che operativi, riguardanti in pratica tutta l’attività dell’Istituto”. Obiettivi principali del progetto erano due: il primo era rendere autonomi i singoli auditor nelle loro richieste dati, evitando loro la necessità di rivolgersi continuamente ai tecnici del servizio It del gruppo per modifiche e integrazioni a fronte di ogni nuovo tema che dovesse essere monitorato; in secondo luogo si voleva creare un insieme di “indicatori di anomalia” periodici, standardizzati, condivisi, confrontabili e dunque leggibili per tutti, la cui valorizzazione avrebbe costituito la base della valutazione sintetica del rischio di un particolare processo o di una particolare unità organizzativa.
Ovviamente, sin dall’inizio il progetto è stato concepito come una serie di step successivi, per affrontare una alla volta le macroaree di riferimento della funzione Auditing: Finanza, Crediti, Incassi e Pagamenti. La prima area analizzata è stata quella del mondo della fornitura dei servizi finanziari, cogliendo l’occasione dell’introduzione della normativa europea Mifid e cercando quindi di impostare, già sul nuovo framework tecnologico, il corposo elenco di controlli utili a verificarne la corretta e tempestiva applicazione.
“Per raggiungere questi obiettivi – proseguono gli intervistati – si doveva ricercare una soluzione che fosse il più possibile scalabile, che garantisse rapidità nell’integrazione di nuove subject area o di ulteriori dati di dettaglio e che offrisse strumenti di interrogazione user friendly che potessero essere utilizzati anche da non tecnici”. Va detto che già dal 2001 il Gruppo Credem si era dotato di un Enterprise Datawarehouse che, con vari datamart tematici, mappava i principali elementi dell’attività aziendale. Lo strumento di analisi, poi diffusosi rapidamente in azienda, era Business Objects: naturale dunque la scelta, per il progetto BIAudi, di proseguire, almeno per il front end utente, sulla stessa strada.
“Per ciò che concerne il Dbms, all’atto dell’integrazione e ristrutturazione del Data warehouse per il progetto BIAudi si pose invece la domanda di quale tecnologia garantisse gli obiettivi di scalabilità, rapidità di integrazione, livello prestazionale e disponibilità richiesti, anche in vista di una prevedibile crescita significativa dei volumi caricati e trattati”. La scelta fu di abbandonare la precedente architettura, basata su Db2/390 e SqlServer, per passare alla tecnologia Teradata leader nelle architetture a supporto del Datawarehousing, specie nei sistemi di considerevoli dimensioni, e che era già presente in azienda in seguito alla costruzione, nel 2004, di un nuovo Data warehouse per il sistema di Crm del gruppo. “Ciò ha comportato – aggiungono gli intervistati – un cambio di filosofia e un non trascurabile sforzo di conversione delle basi dati, poiché Teradata adotta un modello di riferimento strutturale completamente “normalizzato”, diverso dal nostro precedente”. Nel passare all’EDW basato su Teradata si sono anche adottati i tool relativi, tra cui Data Stage di Ibm (ex Ascential) per il processo di Etl.
L’esecuzione del progetto, seguita da un team composto da senior auditor, analisti del servizio It e consulenti Teradata, ha seguito per ognuna delle aree coinvolte (Finanza, Crediti, Incassi e Pagamenti) uno schema che prevedeva sette fasi: individuazione degli indicatori di anomalia (e quindi le loro modalità di calcolo) e degli approfondimenti da compiere a fronte di un potenziale problema rilevato; individuazione delle informazioni necessarie allo scopo già presenti sul ‘vecchio’ DW (al fine di riutilizzare i programmi alimentanti); individuazione delle basi dati sorgenti per le nuove informazioni richieste e scelta delle logiche, delle modalità e delle tempistiche di caricamento; test di verifica della qualità e completezza dei dati sorgente prima dell’Etl (fase questa importantissima e delicata); migrazione dei vecchi dati e loro ristrutturazione dal sistema Db2 a Teradata; realizzazione degli Etl di caricamento e creazione dei cosiddetti ‘universi’ in Business Objects, ovvero la mappatura logica dei dati secondo le diverse esigenze che guidano le query degli utenti finali; realizzazione degli indicatori tramite report Business Objects e loro valorizzazione periodica per ogni filiale.
Il successo della collaborazione
In quest’ultima fase occorre scegliere, per ciascuna misura, la soglia di riferimento (medie aritmetiche, valori fissi o altro), i coefficienti di scostamento rispetto alla soglia, e il peso da attribuire alla potenziale anomalia rilevata. L’insieme degli indicatori così valutati e pesati concorre a formare un indice di rischio per ciascun processo o unità organizzativa, con un’applicazione che offre una visualizzazione semplice e intuitiva della classifica di rischio, permettendo le valutazioni di merito.
“Nelle fasi realizzative – aggiungono gli intervistati – non abbiamo registrato particolari problemi grazie all’organizzazione del progetto e all’efficace collaborazione tra la funzione utente, i Sistemi Informativi e il fornitore esterno incaricato della realizzazione, cioè Teradata. Resta l’attenzione sul tema della Data Quality: è infatti requisito primario per una funzione di controllo, che fonda le sue ricerche anche sulle ‘eccezioni’, avere informazioni di dettaglio qualitativamente ineccepibili. Nel nostro caso, disponendo di un Data warehouse costantemente presidiato da una funzione di data government e stewardship istituzionale e non abbassando mai la guardia su questi temi dobbiamo dire che non abbiamo incontrato problemi”.
Le prossime fasi
Anche se le principali aree dell’attività bancaria sono oggi coperte, il progetto è tuttora in essere perché mancano ancora alcune aree minori che devono rientrare nello stesso ambito per arrivare a quella standardizzazione degli strumenti e delle basi dati di cui si è detto all’inizio. Inoltre, l’avere un Data warehouse di gruppo dotato di informazioni di massimo dettaglio fa sì che il sistema sia usato da molte altre funzioni, come ad esempio dai Back Office. Il riutilizzo degli output del progetto è quindi già in atto, “con un successo – osservano gli intervistati – che, talvolta, va addirittura a scapito delle prestazioni, fronte sul quale l’It sta concentrando le attenzioni con iniziative specifiche”.
Certamente, l’obiettivo primario d’individuare le aree, le unità operative e i processi più a rischio è stato centrato, consentendo alla funzione di Auditing di concentrarsi dove sono più evidenti i segnali di allarme e dunque indirizzare con più efficacia l’attività di controllo in loco. Il sistema non è ancora a pieno regime, necessitando giocoforza di una taratura che va effettuata anche alla luce dei risultati ottenuti, “che, secondo le prime evidenze, ci soddisfano, andando nella direzione di una più tempestiva individuazione e correzione di situazioni patologiche e di una conseguente riduzione del rischio di frode”. Naturalmente, gli indicatori ed il loro “peso” vanno tenuti costantemente aggiornati, dovendo seguire, per mantenere la propria efficacia, le variazioni del business, l’introduzione di nuovi prodotti e l’entrata in vigore di nuove normative. “Anche i monitoraggi indispensabili alla compliance normativa – concludono gli intervistati – sono resi più tempestivi dall’autonomia degli auditor e consentono loro di approfondire facilmente, con funzioni di ‘drill down’, le situazioni meritevoli adeguandosi in modo autonomo e flessibile alla congenita mutevolezza dei campi di analisi”.
