Non misurare il rischio, misurare il livello di fragilità

Il rischio non si può misurare (si misurano solo gli impatti dell’incidente). La fragilità è misurabile.

Quando si parla di risk management, spesso si finisce per parlare di calcolo del rischio (e non di riduzione) o più precisamente degli impatti derivanti dall’incorrere in un evento drammatico: la strategia comunemente in uso è quella di cercare nella sequenza di eventi passati lo scenario peggiore e utilizzarlo per calcolare l’impatto di un evento futuro.

Riprendendo quanto detto ne "Il cigno nero", Taleb afferma: “Per come la intendiamo oggi, la gestione del rischio è lo studio di un evento collocabile nel futuro, e solo alcuni economisti e altri folli possono pretendere, in barba all’esperienza, di “misurare” l’incidenza futura di questi eventi rari […] Più è raro l’evento, meno è gestibile e meno sappiamo sulla frequenza con cui accade. Eppure, più l’evento è raro e più questi “scienziati” che si occupano di prevedere si sentono fiduciosi.

Calcolare il rischio di un evento (raro) è quindi una attività piuttosto priva di utilità se lo scopo è creare una organizzazione antifragile. Stipulare una polizza assicurativa, non protegge il sistema dai danni, né lo rende più forte. Fare una assicurazione sulla vita non ci rende immortali, o più longevi. Ci garantisce solo una qualche forma di rimborso in caso di malattia.

Misurare la fragilità del sistema, identificando i punti di rottura, è una attività molto più utile nonché realizzabile.

Proviamo a capire meglio questo punto prendendo in considerazioni tre esempi di fragilità sistemica per capire il nesso (inesistente) fra antifragilità e calcolo del rischio.

Prendiamo il caso di una azienda che produce prodotti software e trasformiamo il calcolo del rischio nella stima dei tempi (o costi) necessari per la realizzazione del prodotto (ovvero calcoliamo il rischio di non rispettare le tempistiche stimate). Proviamo quindi a immaginare alcune situazioni che possono ostacolare il lavoro del team, tanto da rendere molto difficile il rispetto delle scadenze.

Per esempio pensiamo a un team di sviluppo fortemente dipendente da una persona depositaria assoluta della conoscenza del prodotto (il team non è autonomo nel cambiare qualcosa, o peggio ancora se manca il leader non sa cosa fare). Altro caso potrebbe essere quello in cui il team risulti non essere autonomo nella realizzazione del prodotto, dovendo aspettare da altri la produzione di alcune parti (componenti, documentazione, infrastrutture).

Oppure si pensi alla azienda che appalta a un fornitore esterno la realizzazione di alcune parti del proprio prodotto, parti che saranno realizzate da un team esterno, del quale si ignora non solo il risultato finale ma anche la modalità di lavoro. Oppure si pensi infine al caso in cui l’intero team, o parte di esso, sia composto da persone prese in affitto da fornitori esterni (espressione brutta, in inglese suona meno male).

Questi casi hanno in comune un fattore: la dipendenza da elementi esterni al gruppo di lavoro, elementi che possono influire pesantemente non solo sulla qualità finale ma anche sulle tempistiche produttive. In estrema analisi impattano sulla solidità della azienda che potrebbe non superare uno stress derivante da questi fattori: l’azienda che fornisce le persone in affitto, decide di fare turn over, il fornitore esterno fallisce, il team leader si licenzia senza scrivere una riga di documentazione.

Cercare di ridurre i ritardi nella consegna del prodotto aumentando la pressione sul team o ricercando maniacalmente un modo “più preciso” di stimare è del tutto inutile se non si interviene eliminando le debolezze, in questo caso le dipendenze, del sistema.