Quando una misura smette di aiutare a decidere

Rischio, KPI e creazione di valore quando il controllo diventa rassicurazione.

Un indicatore è utile quando apre una domanda migliore. Diventa un problema quando continua a rassicurare anche dopo aver smesso di descrivere la realtà.

Nel 2017 ero ancora all’università e sostenevo l’esame per una specializzazione in Security Management.

Andavo di fretta. Ero ambizioso. Vedevo quella figura professionale come importante e desideravo una certificazione che riconoscesse le competenze prima ancora di avere davvero iniziato il percorso che avevo in mente.

Fui bocciato.

La motivazione dell’esaminatore fu che non avevo compreso la matrice impatto/probabilità riferita a ISO 31000. Il punto, per me, era più specifico. Mi stavo interrogando sulla differenza tra valutazioni qualitative e quantitative e, soprattutto, su come si potesse misurare l’impatto. Quel tema non era stato approfondito nel corso; tentai di costruire una risposta mia. Non ricordo più la formulazione esatta. Ricordo che non fu convincente.

La domanda, invece, rimase.

Come si misura l’impatto di un rischio senza ridurre un problema complesso a un numero arbitrario? E quando una misura smette di aiutare chi decide per diventare soltanto una forma di rassicurazione?

La risposta non mi arrivò da una definizione imparata a memoria. Arrivò più tardi, durante un master in Risk Management, guardando un problema reale nel contesto in cui lavoravo.

L’indicatore non era la scoperta

Il problema riguardava i cali di inventario. Per comprenderlo provai a scomporlo: non soltanto l’evento finale, ma il processo che lo produceva, le sue conseguenze e i costi che distribuiva lungo la catena operativa.

Quasi a voler dividere l’atomo, cercavo una misura che non fosse soltanto plausibile, ma utile a discutere il problema con le persone coinvolte.

A un certo punto si accese una lampadina: individuare l’incremento marginale, espresso in euro, sul costo di processo del singolo articolo.

Non era una formula universale per quantificare l’impatto. Non risolveva, da sola, il problema. Rendeva però possibile una cosa essenziale: seguire il fenomeno attraverso conseguenze concrete e scegliere un’unità di misura coerente con quel processo specifico.

L’indicatore non era la scoperta. Era il risultato di un metodo.

Quella distinzione continua a sembrarmi decisiva. Prima di misurare bisogna capire che cosa si sta cercando di rendere visibile: l’obiettivo del processo, l’evento rilevante, il meccanismo con cui produce un effetto, le persone e i sistemi da cui dipende, le conseguenze che vale la pena discutere.

Senza questo lavoro, anche una metrica elegante rischia di essere soltanto un numero ben presentato.

Quando il KPI rassicura

Nello stesso periodo cercavo di ricalcolare alcuni KPI usati per leggere le performance delle security operations.

Dalle mie analisi emergeva che quegli indicatori erano, almeno in parte, fuorvianti rispetto all’andamento reale della funzione. Il processo da cui provenivano era orientato soprattutto alla performance delle operazioni di vendita e distribuzione. Era efficace nel tracciare alcune anomalie di processo, ma non offriva un livello di dettaglio sufficiente per distinguere e comprendere gli eventi più rilevanti dal punto di vista della sicurezza.

Il problema non era che non esistessero dati. Il problema era il rapporto tra i dati disponibili e la domanda a cui avrebbero dovuto rispondere.

Un KPI misura una prestazione rispetto a un obiettivo. Un indicatore di rischio dovrebbe aiutare a intercettare l’esposizione o un cambiamento nelle condizioni che la determinano. Una misura d’impatto prova invece a rendere leggibili le conseguenze di un evento. Una misura di efficacia del controllo verifica se una salvaguardia funziona nel modo previsto.

Queste categorie possono dialogare, ma non sono intercambiabili.

Quando un’unica misura viene usata per rispondere a domande diverse — performance, rischio, impatto e qualità del controllo — tende a perdere precisione. Può restare in vita perché è familiare, disponibile e facile da riportare. Ma la sua esistenza non dimostra che il processo sia sotto controllo.

In quel caso, il sistema avrebbe potuto migliorare se la funzione avesse avuto ownership del dato: competenze di data analysis, tempo dedicato e un mandato chiaro per lavorare insieme a Business Intelligence sulla struttura dell’analisi. Soprattutto, sarebbe stato necessario riconoscere che il tema meritava priorità.

Non accadde in modo sufficiente.

L’esperienza mi mostrò una misura di controllo non adeguatamente pianificata rispetto al rischio che avrebbe dovuto aiutare a mitigare. Il suo effetto collaterale era più insidioso della semplice inefficienza: nascondeva l’inefficienza dietro un velo di compliance.

Riguardandola oggi, non la leggerei principalmente come una carenza di persone o di conoscenze. La root cause era un problema di governance. L’inefficienza non era stata priorizzata e un KPI ormai poco credibile continuava a esistere perché offriva una rassicurazione di facciata.

Quando una misura non è più credibile ma continua a essere usata perché rassicura, non produce soltanto miopia. Può rendere cieco un intero processo decisionale.

Il costo della cecità

Le conseguenze non apparivano subito come un incidente evidente. Arrivavano sotto forma di immobilità.

Le decisioni venivano congelate. I progetti venivano congelati e poi cancellati. Il dipartimento di sicurezza faticava a dimostrare il ritorno degli investimenti programmati; i risk assessment perdevano credibilità perché non riuscivano a rendere esplicito l’impatto del problema. Nel frattempo, l’organizzazione restava esposta a rischi contro cui aveva comunque scelto di investire.

La catena era semplice:

1. Una misura non idonea
2. Un impatto non dimostrabile
3. Un business case non difendibile
4. Progetti rinviati o cancellati
5. Un’esposizione residua non governata

Questo è il punto in cui rischio e creazione di valore smettono di essere conversazioni separate.

Una scelta di investimento non richiede solo la promessa di un beneficio. Richiede di rendere esplicite le ipotesi che la sostengono, le dipendenze che possono comprometterla e le conseguenze di non agire. Se non riusciamo a descrivere questi elementi in un linguaggio condiviso, il confronto si sposta facilmente su metriche incompatibili, priorità non dichiarate e giustificazioni vaghe.

La decisione non diventa più prudente. Diventa soltanto più facile da evitare.

La capacità che mancava

L’idea che ebbi allora, ma che non riuscii a realizzare, era formare una persona all’interno del team sulle competenze di data analysis e affiancarla al team di Business Intelligence.

L’obiettivo non era produrre più report. Era portare la conoscenza specifica della security dentro il lavoro di ingegnerizzazione del dato: mettere in relazione ciò che accadeva nell’operatività con le tecniche statistiche e con la struttura delle informazioni disponibili.

L’unico risultato fu l’assegnazione di un analista incaricato di raccogliere feedback. Fu una soluzione palliativa: non produsse risultati rilevanti, ma aumentò la reportistica e la confusione.

Mancava una capacità stabile. Mancavano ownership, mandato e priorità condivisa.

È una lezione che vale oltre il caso specifico. I problemi complessi raramente appartengono a una sola funzione. Richiedono linguaggi diversi, ma anche un luogo in cui quei linguaggi possano incontrarsi.

Finance deve poter vedere la relazione tra causa e costo. Operations deve poter verificare se una misura regge nel lavoro reale. Security deve poter descrivere l’evento e l’esposizione che intende ridurre. Business Intelligence deve poter aiutare a costruire un dato affidabile e leggibile.

Senza questa relazione, ciascuno può avere ragione nel proprio perimetro e il sistema, nel suo insieme, può continuare a non decidere.

Come lo affronterei oggi

Oggi partirei dall’analisi finanziaria del processo.

Non per ridurre tutto al denaro, ma per rendere esplicito il costo del problema, il valore degli interventi possibili e le conseguenze delle alternative disponibili. Da lì farei un lavoro di sintesi: tradurre un sistema complesso in una spiegazione semplice abbastanza perché Finance, Operations, Security e Business Intelligence possano vedere la stessa relazione tra causa, costo, controllo e risultato atteso.

Partirei da sei passaggi:

1. Obiettivo — Quale risultato del processo vogliamo proteggere o rendere possibile?
2. Evento — Che cosa può accadere e alterare quel risultato?
3. Meccanismo — In che modo l’evento produce un effetto operativo, economico o reputazionale?
4. Misura — Quale unità rende quell’effetto sufficientemente visibile e discutibile?
5. Opzioni — Quali controlli, investimenti o scelte sono davvero disponibili?
6. Decisione — Chi sceglie, sulla base di quali ipotesi, con quale esposizione residua e con quale momento di revisione?

Questo non elimina il dissenso, e non dovrebbe farlo. Una decisione seria può restare controversa anche quando i dati sono buoni.

Può però rendere il dissenso più utile: meno fondato su numeri che rispondono a domande diverse, più concentrato su ciò che è realmente in gioco. Se i presupposti sono trasparenti e il ragionamento è condiviso, la decisione non diventa automatica. Diventa però più difficile evitarla senza assumersene apertamente la responsabilità.

Il rischio come architettura della decisione

Il risk management non è una funzione che arriva dopo le decisioni per registrare ciò che può andare storto.

Può essere un’architettura della decisione: la controparte necessaria di ogni piano finanziario, investimento o ambizione di crescita.

Il financial planning disegna come creare e allocare valore. Il rischio mette alla prova quell’ambizione: interroga le ipotesi, rende visibili le dipendenze, misura le conseguenze e chiarisce quali condizioni devono esistere perché il valore promesso possa reggere nel tempo.

Questo non è retorica e non è una pietra filosofale. Richiede metodo, competenze adeguate e organizzazioni disposte a fare il lavoro necessario. Richiede di accettare che un controllo esista per aiutare una decisione, non per rendere più ordinata una presentazione. Richiede di cambiare una metrica quando i fatti dimostrano che non aiuta più a vedere.

Senza metodo, competenze e volontà organizzativa, il rischio resta una tabella.

Con questi elementi, può diventare parte della disciplina con cui un’impresa sceglie dove investire, cosa proteggere, quali opportunità perseguire e quali vulnerabilità accettare consapevolmente.

Una nota per il me del 2017

A quella versione di me, impaziente di ottenere una certificazione prima di avere davvero iniziato, direi che ha fatto bene a porsi quella domanda.

Non perché una domanda irrisolta sia di per sé un merito. Ma perché alcune domande chiedono tempo, esperienza e contesti reali prima di poter ricevere una risposta utile.

C’è ancora molto lavoro davanti. Ci saranno sempre piani incompleti, dati imperfetti, priorità in conflitto e condizioni che cambiano mentre proviamo a decidere.

Prepararsi non significa aspettare passivamente il momento giusto per partire. Significa capire che cosa serve per partire, senza confondere la preparazione con l’illusione del controllo.

Nel quinto libro dell’Odissea, Odisseo lascia l’isola di Calipso su una zattera costruita con le proprie mani. Non parte su una nave invulnerabile: lavora i tronchi, li congiunge, costruisce un ponte, un albero, una vela e un timone. Fa quanto può con ciò che ha, per il mare che deve attraversare.¹

Poi arriva la tempesta. Il mare non rispetta il piano e la zattera non basta a evitare il naufragio. Ma senza quel lavoro di preparazione non ci sarebbe stata nemmeno una rotta da correggere, né una possibilità concreta di cercare l’altra sponda.

La preparazione non serve a evitare il mare. Serve a non arrivarci impreparati.

Nota editoriale

Questo articolo propone una riflessione basata su esperienza professionale, studio e osservazione. I riferimenti a contesti di lavoro sono intenzionalmente generalizzati per proteggere persone, organizzazioni e informazioni riservate. L’attenzione è rivolta a cause, meccanismi, decisioni e insegnamenti trasferibili, non a casi identificabili.

Il testo è stato sviluppato attraverso un’intervista guidata e un processo di revisione assistito da strumenti di intelligenza artificiale. Idee, opinioni, esempi, scelte editoriali e responsabilità delle affermazioni restano dell’autore. L’uso dell’AI nel lavoro di ricerca e scrittura sarà approfondito in un articolo successivo dedicato all’AI Act.

Questo contenuto non costituisce consulenza legale, finanziaria, tecnologica o di risk management. Ogni decisione richiede un’analisi proporzionata al contesto, alle responsabilità applicabili e alle informazioni disponibili.

Fonti e riferimenti

Per continuare la conversazione

Quale misura, nel tuo contesto, sembra rassicurante ma non aiuta davvero a decidere?

Puoi rispondere, contraddire questa tesi o condividere l’articolo con chi lavora ogni giorno nel punto in cui un piano incontra la realtà.