Siete seduti al volante della vostra automobile, state procedendo lungo una strada diritta in mezzo alla dead valley, al centro del deserto californiano. Non potete rischiare di rimanere a piedi, senza carburante oppure per un guasto al motore.
Il motore di un’automobile è un sistema complesso; per fortuna disponete di un cruscotto davanti a voi che vi permette di avere immediatamente sott’occhio le misure dei parametri rilevanti: velocità, numero di giri, temperatura dell’acqua, livello del carburante e così via. Non c’è bisogno di conoscere tutti i dettagli, quelli sono per i meccanici, ma a voi che governate il mezzo, occorrono solo le variabili significative, a volte neanche una misura esatta ma solo un’ indicazione qualitativa: temperatura dell’acqua bassa, media oppure alta.
Anche un’ azienda è un sistema complesso, di natura diversa certo, ma sarebbe utile disporre di un insieme di parametri rilevanti e di corrispondenti indicatori da esaminare in modo semplice come in un cruscotto di automobile.
Esistono da anni sul mercato prodotti di business intelligence che hanno l’obiettivo di mostrare informazioni rilevanti in modo efficace. Questi prodotti sono utilizzati principalmente per monitorare alcuni parametri di performance come l’andamento delle vendite e dei fatturati.
Indicatori di rischio operativo
Il mondo bancario, dopo l’accordo di Basilea, si trova a dover affrontare e gestire il rischio operativo. La definizione di rischio operativo data ufficialmente è questa: “Il rischio operativo è il rischio di perdite derivanti dalla inadeguatezza o dalla disfunzione di procedure, risorse umane e sistemi interni, oppure da eventi esogeni”. Questo rischio si nasconde in ogni attività e sistema e viene assunto inconsapevolmente solo per il fatto che la banca agisce e opera.
Uno degli strumenti più efficaci per la gestione di questo tipo di rischi è il controllo di alcune variabili finanziarie o operative che informano tempestivamente del verificarsi di fenomeni rischiosi e magari li anticipano. Rimanendo nella metafora dell’automobile, la spia di bassa pressione dell’olio non indica necessariamente un guasto ma sicuramente lo anticipa affinché possiamo porvi rimedio.
Da alcuni anni, chi si occupa di rischio operativo nelle banche è impegnato nella ricerca di queste variabili chiave che vengono chiamate genericamente Key Risk Indicators (KRI). I KRI sono quindi delle variabili misurabili che forniscono una base affidabile per stimare la probabilità o la severità di uno o più eventi di rischio operativo. Possono essere variabili causali specifiche oppure avvisaglie di eventi di qualche tipo oppure ancora misure di perdite operative. Possono essere misure strettamente quantitative, come il turnover rate di un’unità operativa o il numero di errori di riconciliazione, oppure più qualitative come l’adeguatezza dei sistemi o il grado di preparazione del personale. Possono essere perfettamente oggettive come il numero di ore di fermo di un sistema o più soggettive come la complessità di un portafoglio o un derivato.
Impostare un sistema di KRI
Introdurre in banca un sistema di KRI non è semplice. Per individuare le variabili chiave occorre molta esperienza e un’analisi approfondita delle attività della banca. Questo è più vero tanto più si cercano indicatori predittivi, quelli cioè che sono in grado di anticipare l’accadimento di eventi rischiosi.
Esistono delle iniziative intraprese da società specializzate il cui scopo è quello di costruire un modello ed un catalogo di indicatori standard per tutto il mondo bancario. Il lavoro più importante in questa direzione lo ha svolto Risk Management Association (www.rmahq.org) che nel 2003 insieme a RiskBusiness (www.riskbusiness.com) e alcune delle maggiori banche europee ha creato una catalogo di circa 2000 indicatori di rischio.
Una volta individuati gli indicatori bisogna misurare i valori sul campo e poi presentarli in modo efficace. Occorre un sistema di gestione dei KRI che automatizzi il più possibile le operazioni di raccolta dei dati, consenta una gestione e controllo dei dati ed alla fine permetta di costruire delle presentazioni efficaci. Sul mercato esistono molti prodotti di business intelligence che però coprono solo una parte delle esigenze. L’ideale è avere un’ applicazione che integri queste funzionalità in un contesto dedicato alla gestione del rischio. Queste applicazioni sono definite di Governance Risk and Compliance.ù
Figura 1: Monitoraggio del rischio operativo: un sistema di indicatori di rischio prevede come minimo 4 componenti fondamentali
(cliccare sull’immagine per ingrandirla)
Sistema di KRI
Vediamo in maggiore dettaglio quali sono queste funzionalità. Un sistema di indicatori di rischio prevede come minimo 4 componenti fondamentali (come schematizzato nella figura 1).
– Database – Il database è il cuore del sistema di indicatori, contiene tutti i dati raccolti nel tempo, permette al sottosistema di reporting e a quello dei motori di calcolo, di reperire in maniera efficiente i valori per elaborarli mostrarli all’utente. Si può utilizzare a questo scopo un tradizionale database relazionale.
– Repository di indicatori (schede indicatori) – Il repository di indicatori contiene le definizioni di tutti gli indicatori del sistema; le definizioni consistono in una serie di attributi che servono agli altri sottosistemi per validare i valori collezionati nel tempo, a visualizzare indicatori omogenei in base a una classificazione, a calcolare nuovi valori sulla base di formule definite.
Quali sono gli attributi principali di un indicatore? Innanzi tutto il tipo dei valori possibili: se un intero, una percentuale, un importo, un rapporto ed il dominio dei valori. Ad esempio, se si desidera tracciare il numero di fermi macchina di un certo sistema, avremo un valore intero da 0 a un numero prefissato, diversamente se si desidera tracciare il numero di reclami dei clienti rispetto al totale delle pratiche svolte da un’unità operativa, si potrebbe pensare una percentuale con valori reali da 0 a 100.
Proprio come avviene per certi valori dei parametri di un’automobile è utile, per alcuni indicatori, avere un insieme di soglie per determinare una scala qualitativa, ad esempio basso-medio-alto.
Alcune volte è comodo costruire nuovi indicatori basati su altri già esistenti; nell’esempio precedente relativo al numero di reclami, si potrebbe calcolare questo valore partendo da due altri indicatori: il numero totale di pratiche e il numero dei reclami e poi operare una trasformazione sul rapporto tra questi valori per riferirlo a 100. Quando si devono invece sintetizzare delle situazioni, si creano delle aggregazioni di due o più indicatori per formare alcuni indici, proprio come avviene per gli indici di borsa che forniscono una sintesi del mercato sottostante. Ecco che nasce l’esigenza di poter disporre di un modo per definire nuovi indicatori mediante delle formule in un qualche linguaggio che permetta di esprimere costanti, variabili (altri indicatori) operatori e delle funzioni built in per eseguire calcoli più complessi. Gli indicatori devono essere misurati con una certa frequenza, e quest’informazione serve ai sottosistemi di raccolta ed è utile per capire quanto è attuale l’informazione e in un certo senso anche a controllare il sistema di collezione dei valori.
Il numero di indicatori possibili aumenta con la complessità del sistema da monitorare perciò è utile classificarli in base a qualche criterio. Un primo criterio potrebbe essere rappresentato dallo scopo dell’indicatore, ad esempio accanto agli indicatori di rischio potremmo avere anche indicatori di performance. Si potrebbero ulteriormente dividere queste classi e individuare dentro alla classe degli indicatori di rischio, altre sottoclassi in base alla grandezza da controllare, ad esempio: cambiamenti strategici, persone, esposizione, fattori esterni, tecnologia, management, e così via.
Un buon sistema di gestione degli indicatori deve permettere di specificare facilmente tutti questi attributi.
– Motore di calcolo – Il motore di calcolo è necessario per elaborare tutti i valori di indicatori definiti su formule. Non è un problema banale, specialmente quando sono stati definiti indicatori composti con frequenze di campionamento diverse.
Il sottosistema di calcolo si compone di due elementi fondamentali: un linguaggio per specificare i calcoli e un motore per eseguire in modo efficiente questi calcoli. Il linguaggio dev’essere abbastanza espressivo da permettere l’utilizzo di condizioni booleane ed abbastanza potente da fornire almeno le basi per fare della statistica descrittiva. I sistemi più evoluti mettono a disposizione anche operatori fuzzy per esprimere scale qualitative e la possibilità d’interagire con una base dati relazionale.
Il motore di calcolo vero e proprio deve elaborare a volte grandi moli di dati, ad esempio quando si definiscono indicatori composti che hanno una profondità storica significativa.
– Caricamento e validazione – Questa parte si occupa di recuperare i dati dei KRI da diverse fonti. Lo scenario ideale è un sistema di indicatori che si alimenta in modo automatico e trasparente dai diversi sottosistemi della banca. Questo è uno scenario puramente teorico che si scontra con vincoli tecnici e pratici non indifferenti, come la mancanza di standard e la necessità di far colloquiare sistemi basati su tecnologie diverse non sempre aperte, forniti da aziende diverse e con dei costi di personalizzazione alle volte molto elevati.
Le soluzioni
Un buon sistema di gestione di KRI deve quindi fornire il maggior numero possibile di soluzioni per il caricamento dei dati; il minimo indispensabile è rappresentato dalle seguenti:
– Input manuale con form ad hoc – Non tutti i valori possono essere collezionati automaticamente. Un utente può inserire per alcuni indicatori, dei valori manuali. L’applicazione controlla che i valori inseriti siano compatibili con quanto specificato nel repository.
– ETL (Extract, Transformation and Load) – Probabilmente i vari sistemi della banca possono produrre flussi di dati in qualche formato standard: CSV, XML, XLS, ecc. Il sottosistema di acquisizione dati deve poter leggere questi formati ed essere abbastanza flessibile da specificare regole per l’estrazione delle informazioni rilevanti, fornire aree di staging dei dati letti per ulteriori elaborazioni e pulizia, ed infine popolare la base dati.
– Web Service – I web services sono dei sistemi software progettati per supportare l’interoperabilità tra diversi elaboratori sulla medesima rete. Una caratteristica dei web services è quella di offrire una interfaccia software (descritta in un linguaggio automaticamente elaborabile) tramite la quale i diversi sistemi possono interagire con il web service attivando le operazioni descritte nell’interfaccia. Il sottosistema di collezionamento dati dovrebbe fornire dei web services per permettere agli altri sistemi della banca di poter “depositare” i valori nella base dati.
– Possibilità di interrogare basi dati relazionali – Questa funzionalità può essere vista come un caso particolare di ETL. Deve essere possibile reperire valori anche con query su database di sistemi differenti.
– Reporting – Una volta alimentati tutti gli indicatori occorre visualizzarli in maniera efficace e rappresentarli a chi, sulla base di quei dati, deve prendere decisioni. Non è necessario riportare tutti i valori ma solamente quelli significativi per il contesto oppure che hanno superato le soglie di allarme preimpostate. L’architettura della presentazione è molto importante, infatti questo tipo di informazione è veicolato molto bene attraverso la metafora del cruscotto, dove il superamento delle soglie è evidenziato da scale colorate, o dall’accensione di alcune “spie” come nel cruscotto di una automobile quando la pressione dell’olio è insufficiente.
Proprio come avviene per l’automobile, dove la centralina elettronica colleziona più dati rispetto a quelli che vengono mostrati sul cruscotto, così il sistema di reporting dovrebbe essere in grado di sintetizzare le informazioni chiave: più è alto il grado di chi legge i dati, maggiore è il livello di sintesi che dev’essere raggiunto.
Il sistema ideale per veicolare queste informazioni è la intranet aziendale; le pagine di presentazione possono essere personalizzate in base all’utente, che potrà vedere solo i dati che lo riguardano. Esistono sul mercato sistemi di visualizzazione delle informazioni che utilizzano metafore visuali di strumenti analogici come termometri, scale colorate, lancette e altro ancora.
Presentare le informazioni in modo chiaro ed efficace non è un problema banale. Gli errori più comuni sono infatti sovraccaricare il sistema di visualizzazione con informazioni ridondanti o non attinenti; aggiungere “rumore” con dettagli grafici o decorazioni inutili; rendere inefficace la presentazione usando male i colori. Di fatto, scegliere la modalità di rappresentazione errata per quel tipo di informazione.
Esistono dei validi riferimenti teorici a questo riguardo. Una autorità in materia è Edward Tufte, e soprattutto il suo testo The Visual Display of Quantitative Information (Cheshire, CT: Graphics Press, 1983)
Un altro testo dedicato soprattutto al progetto di cruscotti informativi è: Information Dashboard Design di Stephen Few (O’Reilly, 2006)
Conclusioni
Gli indicatori di rischio sono misure di variabili finanziarie o operative che sintetizzano il comportamento di un sistema organizzativo. Un sistema di misura e reporting di queste variabili è uno strumento efficace per la gestione del rischio operativo che sta riscuotendo un ampio consenso tra i Risk Manager.
Impostare un sistema di KRI non è semplice, oltre ad individuare le variabili più efficaci è necessario disporre dei supporti informatici per raccogliere, elaborare e mostrare i valori di queste variabili e suggerire interventi o segnalare situazioni anomale.
Gli Indicatori Chiave di Rischio Operativo sono sicuramente uno degli strumenti più efficaci di reporting direzionale. Spesso i Risk Manager si scontrano con la difficoltà di comunicare all’Alta Direzione le informazioni giuste in modo efficace; con un sistema di Indicatori Chiave e di Indici opportunamente contestualizzati e rappresentati questo compito viene semplificato di parecchio. E la dead valley non fa più paura.
* Ivan Maffioli è partner di Sdg Italia, società specializzata nella gestione dei Rischi Operativi per le banche – www.sdgitaly.it; e-mail: imaffioli@sdgitaly.it
