di Gabriele MENEGUZZI
Grandi imprese ricercano flessibilità nei sistemi di risk & compliance management, pretesto o bisogno reale? Soluzioni evolute ed approcci da seguire esistono.
Ho percepito un crescente bisogno, da parte delle aziende, di flessibilità nelle soluzioni di Risk & Compliance Management tanto da chiedermi se la richiesta nasca “solo” dalla classica contrapposizione tra utente e sistema/impresa tipica delle nuove implementazioni di sistemi.
Sappiamo infatti, come spesso, una nuova implementazione rappresenti una opportunità per l’azienda per:
- ottimizzare i processi a livello aziendale,
- standardizzare le attività ed evitare e/o ridurre la gestione delle eccezioni (fonti di inefficienze e rischi), migliorare il controllo dei processi e delle informazioni,
- supportare il cambiamento di comportamenti ed approcci;
e l’utente, spesso viva il cambio delle soluzioni come una ulteriore difficoltà, una riduzione delle possibilità di agire in autonomia e richieda più funzionalità, ottimizzazioni mirate alle attività del proprio ruolo, spesso “usi” la presunta “rigidità” del sistema come alibi per rinviare o rallentare il cambiamento.
Ma non si può certo trascurare che le aree di risk & compliance, hanno oggettivamente in questi ultimi anni, dovuto affrontare sfide nuove e veloci cambiamenti:
Normative e metodologie
In pochi anni si sono registrati progressive evoluzioni dei framework metodologici nonché, soprattutto nei settori più regolamentati, sempre nuove normative e richieste da parte degli organi di vigilanza
Organizzazione
Le aziende si sono gradualmente organizzate creando nuove entità organizzative e comitati, integrando nuove competenze, dovendo valutare il corretto trade-off tra unità organizzative molto centralizzate oppure più distribuite, tra specializzazione ed integrazione dei processi
Cultura aziendale
È cresciuta l’attenzione da parte degli stakeholder verso la “governance” e quindi anche verso i processi di Risk & Compliance, la “maturità” su questi temi è in continua crescita e diffusione ai vari livelli aziendali quindi modelli e processi sono destinati ad evolvere
Processi
I processi sono gradualmente divenuti più “diffusi” rispetto a quelli iniziali “più centralizzati”, si ampliano le risorse e le entità di business coinvolte, cresce la necessità di sviluppare processi di gestione differenziati per ambiti di applicazione, maturità aziendale, complessità del fenomeno
Sistemi
Soluzioni mirate hanno aperto nuove opportunità per gestioni più strutturate ed efficaci delle informazioni, tuttavia, le soluzioni verticali sviluppate per ristretti ambiti hanno generato silos poco integrati ed inefficienti, le soluzioni più integrate di risk & compliance management ovviamente richiedono funzionalità aggiuntive e maggiore capacità di configurazione per rispondere ai requisiti dei diversi ambiti
Se, a questo scenario, aggiungiamo una crescente velocità di cambiamento del contesto, in termini più generali (cioè scenari competitivi, modelli di business, tecnologie, sistemi, competenze…) che moltiplica l’attenzione verso nuovi rischi, allora è evidente che la flessibilità è diventata una esigenza reale e primaria e, di conseguenza, è una componente di effettivo valore nelle soluzioni di risk & compliance management.
Possono sembrare considerazioni scontate, tuttavia, a fronte di tali esigenze, la valutazione e la selezione delle soluzioni nei progetti di risk & compliance, sembrano non recepire opportunamente tale bisogno.
Le aziende impostano spesso il processo combinando principalmente due valutazioni:
- funzionalità e/o componenti attualmente non presenti che, quindi, ci si aspetta pienamente supportate dalla “nuova soluzione”;
- potenzialità della soluzione, spesso valutata sulla base di una sorta di “lista dei desideri”, cioè un elenco interminabile di possibili funzionalità stilato con l’idea, diffusa, che incrementare l’elenco con il maggior numero di funzionalità possibile sia la modalità per ottenere una migliore valutazione.
Gli effetti sono un incremento della complessità delle valutazioni, elevato rischio di differenti interpretazioni di domande e risposte, tempistiche prolungate ma, soprattutto, si rischia di scegliere la soluzione sulla base di funzionalità “potenziali” che non serviranno mai e si perde l’opportunità di effettuare una riflessione più strutturata e profonda sulle dimensioni effettivamente più probabili di evoluzione del modello a cui la soluzione dovrà rispondere (con tempestività sempre crescente).
In altre parole, credo che la flessibilità debba essere progettata, cioè capita alla luce del contesto organizzativo e di business, focalizzata verso le dimensioni effettivamente utili, recepita nei modelli e nella progettazione della soluzione.
Fortunatamente, esistono soluzioni “tecniche”, intendo componenti applicative/funzionalità in grado di supportare la flessibilità di una soluzione, che grandi vendor di tecnologia hanno inserito nelle applicazioni, che rappresentano una risposta preziosa per evolvere le realizzazioni nel tempo.
Ho provato a concettualizzare le principali richieste di flessibilità ricevute, che spesso richiedono funzionalità nelle applicazioni specifiche senza le quali diventa più complesso rispondere ai bisogni dei clienti.
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
La lista non vuole essere esaustiva, ma queste mi sembrano le dimensioni “indispensabili” per supportare la flessibilità di una soluzione di risk & compliance.
Le prime due si riferiscono a quello che io chiamo “motore della soluzione” composto da modello e processi e quindi la capacità della soluzione di modellizzare l’organizzazione e il business in cui l’azienda opera attraverso oggetti e relazionarli con flessibilità, e poi vestire su questi processi operativi/workflow facilmente modificabili e differenziabili per ambito di applicazione, area organizzativa, importanza del fenomeno.
La seconda coppia di dimensioni si riferisce alla gestione dei “dati e informazioni” che sono spesso fonte di richieste di modifiche per poter inserire informazioni aggiuntive e nuove classificazioni per il reporting che altrimenti costringerebbero gli utenti ad “arricchire” le informazioni extra-sistema creando piccoli tool individuali e fuori controllo, ovviamente a questo si devono associare anche funzionalità per l’import-export di dati semi-strutturati, tipici di contesti in evoluzione che non possono sempre attendere lo sviluppo di interfacce articolate.
Le ultime due dimensioni sono legate alla “fruizione ed analisi” in tutte le sue forme (analisi libera, reporting standard, personalizzato o verso enti regolatori/di vigilanza) che costituisce una attività rilevante per più utenti ai vari livelli del processo, ma anche al front-end utente che rappresenta il primo punto di controllo delle attività di processo ma anche il mezzo di navigazione dell’utente nell’applicazione la cui facilità di utilizzo e chiarezza diventano elementi importanti nel roll-out del sistema su platee di utenti significative.
Se alcune funzionalità di sistema costituiscono senza dubbio un elemento “facilitatore” per rispondere ai bisogni di flessibilità credo che queste non siano sufficienti senza un corretto approccio al progetto e un fornitore adeguato.
Non servono metodologie riconosciute es. “agile” ma, secondo me, sono sufficienti alcuni principi che devono guidare l’impostazione del progetto:
- analizzare soluzione e processi «AS IS» in ottica critica, superare eventuali impostazioni nate da vincoli della soluzione precedente (o dalla mancanza di una soluzione mirata ed evoluta);
- definire le linee di possibile sviluppo alla luce del contesto competitivo/del business e dell’organizzazione aziendale al fine di recepire nella progettazione le dimensioni di flessibilità che diventeranno chiave per gli sviluppi futuri;
- impostare il progetto in ottica di partenza rapida e semplice prevedendo un possibile sviluppo successivo (evoluzione/estensione) selezionando i miglioramenti apportabili subito e le possibili estensioni/evoluzioni rinviabili.
Ne emerge che il classico approccio basato su una progettazione approfondita volta a definire nel dettaglio il modello “a tendere” per poi implementarlo “per sempre” risulta superato e rischia di generare vincoli che complicano evoluzioni future, risulta piuttosto necessario impostare con il realizzatore della soluzione un rapporto di partnership di medio periodo piuttosto che di mera fornitura.
Ho percepito spesso un disallineamento tra le tempistiche richieste dall’azienda (sempre più serrate) e quelle previste da molti fornitori, credo in parte derivante dalla sottostima del cliente delle complicazioni implementative, ed in parte da rigidità del fornitore che non facilitano interventi rapidi di miglioramento.
Se si vogliono soluzioni flessibili, credo sia bene selezionare fornitori anch’essi “flessibili”, suggerisco alcune caratteristiche del fornitore più adatto a gestire evoluzioni e miglioramenti delle soluzioni:
- sia in grado di esprimere una “visione”, cioè abbia capacità propositiva per delineare le possibili evoluzioni della soluzione realizzata;
- il “vendor solution” sia solido e innovativo (capace quindi di sviluppare ed evolvere la soluzione nel tempo);
- il realizzatore abbia una conoscenza approfondita della specifica applicazione ed un rapporto stretto con il vendor tecnologico;
- integri competenze applicative e quelle sui processi di risk & compliance per poter recepire velocemente le esigenze e tradurle in proposte realizzative;
- sia abituato a lavorare con team ristretti (rapidità decisionale) e seniority elevata (rapidità progettuale).
Ho notato inoltre una distintiva attitudine e capacità nel gestire nuovi sistemi e relative evoluzioni in risorse abituate a progetti dove è rilevante la componente di “modelling”, meno presenti in figure con maggior esperienza in realizzazioni dove è più presente la componente di “configurazione”, quindi, il background dell’azienda e delle risorse non è indifferente.
Concludendo, una maggiore flessibilità è ottenibile con un approccio integrato soluzione-progetto-competenze dove le funzionalità e le componenti tecniche, nonché le esperienze accumulate, consentono di rispondere con tempi ed efficacia molto maggiori rispetto al passato.
Intervento di Gabriele MENEGUZZI – GRC Practice Leader c/o Stratos Analytics
