di Gabriele MENEGUZZI
Come ottenerla? Quali componenti e funzionalità si rilevano preziose?
Ho già parlato in precedenti articoli dell’importanza crescente della flessibilità per le soluzioni di Risk & Compliance Management ed introdotto quelle che, concettualizzando le richieste ricevute, mi sembrano le dimensioni “indispensabili” per supportare la flessibilità di una soluzione di risk & compliance:
Dimensioni della Flessibilità
A. Flessibilità nella modellazione
B. Flessibilità di processo/workflow
C. Flessibilità nei dati associati agli oggetti
D. Flessibilità per import/export dati semi-strutturati
E. Flessibilità del front-end utente
F. Flessibilità nell’analisi e reporting
Ho maturato infatti la convinzione che le demo di prodotto tendano a mostrare la “facciata” della soluzione privilegiando gli aspetti più scenografici e, volendo spesso sottolineare la semplicità di utilizzo, nascondano il back-side delle soluzioni dove si possono celare complicazioni in termini di manutenzione ed evoluzione del sistema o, dal verso opposto, funzionalità facilitanti e preziose in ottica di flessibilità futura della soluzione.
È quindi interessante declinare meglio il significato di queste dimensioni di flessibilità e per ciascuna evidenziare, a scopo esemplificativo, come un primario vendor che si è trovato negli anni ad implementare soluzioni di risk & compliance in diversi ambiti e settori, ha “risolto” i bisogni più diffusi “integrando le risposte sviluppate” nella propria soluzione.
A. Flessibilità nella modellazione
Nella fase di impostazione del framework di rischi e controlli, ma anche nelle successive evoluzioni, è spesso richiesta flessibilità nell’associazione dei rischi alle diverse entità o a diversi livelli delle entità (ad esempio associare un rischio al livello di processo o livello di sotto-processo), nelle relazioni tra i singoli rischi e i controlli/azioni di mitigazione… inoltre è indispensabile completare il modello poiché la declinazione dei rischi dai processi, tipica del Operation Risk Management, non è sufficiente per supportare i restanti ambiti di risk & compliance.
La risposta del vendor integra due aspetti, un contributo più di “modello” ed un altro più informatico riferito alle relazioni tra gli oggetti:
- Concettualizzare una «logica comune» e modellizzare ambiti differenti
La scelta per rispondere alle esigenze è stata di introdurre una logica comune e condivisa tra tutti gli ambiti, che come primo step, ha la modellizzazione dell’azienda/business per declinare da questa il framework di rischi ed associare a questi controlli/azioni di mitigazione ed infine prevedere eventuali test e piani di test per supportare il monitoraggio.
Esempio: Modello logico ri-organizzato dei dati della soluzione GRC di IBM
Il primo step è poi differenziato per ambiti di applicazione quindi ai processi-sotto processi tipici del rischio operativo, si aggiungono altre entità, come Sistemi, HW, SW, Progetti, competenze critiche…. se pensiamo ad ambiti più ICT, oppure conti-sottoconti contabili se pensiamo ai rischi nelle rendicontazioni finanziarie, oppure fornitori/impegni/contratti se pensiamo al rischio fornitori/terze parti ed ovviamente requisiti (o obbligazioni) derivanti da procedure interne (policy) e da mandati/sotto mandati di normative e regolamenti se pensiamo alle aree di compliance…. Ed altri oggetti possono essere integrati con sviluppi custom facilitati.
- Predisporre un modello con «oggetti» relazionabili con flessibilità
Ulteriore supporto alla modellazione è costituito dalla possibilità di creare relazioni n:n tra i diversi oggetti, quindi in grado di supportare sia relazioni 1:1 (ad esempio, 1 processo associato a 1 rischio, a cui è associato 1 controllo), ma anche 1:n (un processo sono associati più rischi, ad 1 rischio più controlli di mitigazione) oppure n:1 (un rischio è associato a più processi, una azione di controllo è in grado di mitigare più rischi). Tale scelta si contrappone a logiche di sistemi che tendono a vincolare le relazioni tra le diverse entità del modello secondo logiche prestabilite.
B. Flessibilità di processo/workflow
L’esigenza di variare i processi/workflow di sistema deriva da cambiamenti organizzativi (siano essi di natura ordinaria o straordinaria) oppure necessità di evolvere i processi inizialmente implementati crescendo la maturità e le competenze aziendali.
Allargando i confini della soluzione crescono le esigenze di differenziare i processi per entità del fenomeno (logica tipo “gate”) in modo da focalizzare le attività dove si presentano più criticità, mentre in grandi gruppi esiste anche la necessità di differenziare i processi per entità organizzative diverse (strutture principali complesse vs aziende semplici/residuali).
La soluzione “tecnica”, come già avvenuto in altri ambiti, è stata quella di integrare nella soluzione un motore di workflow che consente con modalità grafica di costruire e modificare flussi operativi e relativa generazione delle attività, notifica, verifiche e convalide, ed eventuali cambi di viste in fasi diverse del processo.
Esempio: Rappresentazione grafica workflow embedded nella soluzione GRC di IBM
Ovviamente le interfacce utente sono progettate affinché le variazioni dei processi non impattino sul front-end, a differenza di soluzione dove work-flow e front-end utente sono strettamente vincolati rendendo complessa ogni modifica /differenziazione.
C. Flessibilità nei dati associati agli oggetti
Aggiungere informazioni prima non previste è un’esigenza frequente, oppure inserire nuove categorie/attributi per la classificazione ai fini del reporting, poterle integrare facilmente nella soluzione evita gestioni extra-sistema fuori controllo.
La soluzione è stata quella di consentire inserimento di nuovi campi negli «Object Model» con facilità attraverso percorso intuitivo e senza dover scrivere codice, ma soprattutto fornire funzionalità “visuali” tipo drag&drop per aggiornare le viste degli oggetti (schede) selezionando i campi da aggiungere e rendere visibili agli utenti. Il passo successivo è garantire, con procedura automatizzata, la disponibilità delle nuove classificazioni/informazioni nel reporting.
D. Flessibilità per import/export dati semi-strutturati
Non solo nella fase di inizializzazione della soluzione ma anche “a regime” nasce di frequente la necessità di importare un numero significativo di dati o per caricamenti una-tamtum oppure in attesa di realizzare interfacce automatizzate. Viceversa, è risultata spesso indispensabile la possibilità di esportare dati elementari per importarli in altri sistemi o effettuare verifiche massive.
Per rispondere a questa esigenza IBM ha integrato nella soluzione un tool denominato FastMap che consente l’import/export dai dati attraverso excel, attivabile ovviamente solo per utenti autorizzati, ma applicabile a tutti gli oggetti che consente sia il caricamento di nuovi dati sia modifiche (o popolamento) di singoli campi su più record, tutto con massimo controllo e tracciatura delle modifiche effettuate.
E. Flessibilità del front-end utente
Sovente utenti con identico ruolo ma operanti in ambiti diversi, hanno priorità di monitoraggio orientato a differenti fenomeni e numeriche, inoltre in diversi momenti della vita aziendale e/o in fasi differenti della maturità nei processi di Risk & Compliance Management cambia il focus e le priorità dei controlli, front-end standardizzati per ruolo non sono in grado di rispondere a queste esigenze di personalizzazione e modifica nel tempo.
La soluzione offerta consiste nel rendere autonomo e libero l’utente nella personalizzazione del Dashboard che rappresenta non solo una modalità di visualizzazione delle informazioni chiave ma, essendo «attivo» supporta l’utente nella navigazione consentendogli di raggiungere le informazioni critiche con un solo click direttamente dai grafici.
F. Flessibilità nell’analisi e reporting
Sono ormai numerosi gli ambiti e le applicazioni che hanno evidenziato lo stesso fenomeno: per quanto sia ampio il set di report standard predisposto, nascono sempre necessità di nuovi report, oltre a varie viste/aggregazioni degli stessi report per i diversi livelli organizzativi, a questo si aggiunge la necessità frequente di arricchire/rielaborare il report con calcoli aggiuntivi e colonne personalizzate…
La soluzione, come spesso avviene in questi casi, è stata quella di integrare nella soluzione un tool di business intelligence con tutte le funzionalità tipiche dei sistemi di B.I. e Reporting come l’analisi libera multidimensionale, reporting std e self-service, realizzazione di dashboard evoluti e “stories”.
Risulta evidente come le funzionalità evidenziate costituiscono una leva di flessibilità importante per rispondere a nuove esigenze, senza di queste si è obbligati a costosi sviluppi custom (con i relativi problemi di aggiornamento e manutenzione) o ad improvvisare integrazioni con tool che compensino le funzionalità mancanti.
La mia percezione è che tool verticalizzati, nati in ambiti e contesti limitati, abbiano investito molto per rispondere al meglio ad esigenze mirate guidando i clienti attraverso specifici “modelli di funzionamento”, mentre applicazioni che prima hanno iniziato ad ampliare le funzionalità in ottica GRC abbiano investito di più in flessibilità per rispondere ad esigenze e processi dei diversi ambiti del Risk & Compliance Management e per sviluppare elementi logici ed informazioni comuni e condivisibili.
Intervento di Gabriele MENEGUZZI – GRC Practice Leader c/o Stratos Analytics
