Dalla protezione alla resilienza, Erik Hollnagel - Ingegneria della Resilienza

Dalla protezione alla resilienza

Resilience Engineering, Resilienza

Ingegneria della resilienza, Resilience Engineering

Written by redazione

Il titolo originale dell’articolo è “From protection to resilience: changing views on how to achieve safety”, e lo scriveva Erik Hollangel nell’aprile del 2008.

Hollangel, a pieno titolo tra ifondatori della disciplina della Resilience Engineering, notava che una gestione efficace della sicurezza richiede la capacità di imparare dal passato e di anticipare il futuro. Tuttavia, ciò che possiamo imparare dal passato (ad esempio, le indagini sugli incidenti – accident investigation) e ciò che possiamo immaginare per il futuro (ad esempio, la valutazione del rischio – risk assessment) dipende in modo critico da come lo pensiamo, ovvero dai modelli e dai metodi che abbiamo a nostra disposizione. Le indagini sugli incidenti sono state a lungo dominate dalla ricerca delle cause, sia come cause alla radice (RCA – Root Cause Analysis) che come errori umani. Analogamente, la valutazione del rischio è stata dominata da rappresentazioni statiche come gli alberi degli eventi e dei guasti (ETA event trees analysis e FTA fault trees analysis). In entrambi i casi i modelli e i metodi comunemente usati hanno raggiunto ed evidenziato i loro limiti perché la realtà dei nostri ambienti socio-tecnici auto-creati è diventata troppo complessa.
L’alternativa è capire come la variabilità delle azioni umane sia una risorsa piuttosto che una minaccia e definire la sicurezza (safety) come la resilienza di un sistema, ossia la sua capacità di adattarsi e aggiustarsi, piuttosto che come l’assenza di esiti avversi.

scarica l’originale o vai al sito ResearchGate

Introduzione

Anche nel migliore dei mondi che sia possibile immaginare, il futuro non è completamente prevedibile. È inevitabile che si verifichino eventi per i quali non siamo preparati, alcuni con esiti positivi e altri con esiti negativi. Sebbene ci siano pochissime situazioni in cui le cose vanno male rispetto alle moltissime in cui le cose funzionano come ci si aspetta (1 su 10 mila) e dove i risultati sono quelli previsti – o almeno accettabili date le circostanze – i casi positivi tendono nel complesso a passare inosservati. Quando il risultato di un compito o di un’attività è accettabile, c’è poca motivazione a cercare il motivo per cui è stato così; è semplicemente dato per scontato – e addirittura considerato normale – che le cose vadano bene.

Al contrario, quando qualcosa va storto inizia una caccia incessante alla/e causa/e, al fine di garantire che un tale evento non si ripeta mai più.

A meno che non siamo disposti a trattare le avversità con l’ottimismo panglossiano – ossia un ottimismo innamorato e cieco, in un idillio che rifiuta l’evidenza, trasforma gli effetti in cause, reinventa la storia dal finale, riprende tutti i fili perché nel suo ordito squassato dalla realtà tutto resti così come deve essere – così come unicamente può essere, dobbiamo, ovviamente, trovare un modo per ridurre l’incertezza, soprattutto per quanto riguarda le cose che possono andare storte. Un luogo per farlo è progettare processi, sistemi e organizzazioni in modo tale da eliminare i pericoli o garantire che la probabilità di eventi avversi sia ridotta a un livello accettabile. A tal fine, è necessario che il sistema possa essere descritto in dettaglio e che gli eventi si sviluppino in modo prevedibile. Tuttavia, poiché un numero crescente di sistemi sociotecnici è ingestibile, è in pratica impossibile raggiungere un livello accettabile di sicurezza con sole misure precauzionali, cioè eliminando i pericoli, prevenendo eventi imprevisti o proteggendo da esiti indesiderati. La sicurezza fin dalla progettazione (safety by design, sicurezza analitica) deve quindi essere integrata dalla sicurezza gestionale (safety management, sicurezza operativa).

Come chiarisce l’ingegneria della resilienza, la sicurezza è qualcosa che un sistema fa, piuttosto che qualcosa che un sistema ha
(Hollnagel, Woods & Leveson, 2006).

Event and Fault tree analysis, Ingegneria della resilienza

Safety by design

Il significato di “sicurezza fin dalla progettazione” in questo documento è che tutte le precauzioni possibili o praticabili necessarie per garantire un livello accettabile di sicurezza vengono prese in anticipo. Ciò potrebbe avvenire quando il sistema è concepito o progettato, quando vengono realizzati piani dettagliati per il funzionamento o quando è pronto per il funzionamento. Le parti ingegneristiche del sistema, vale a dire la tecnologia o l’hardware, sono progettate in dettaglio e devono necessariamente essere configurate, gestite e mantenute secondo istruzioni meticolosamente preparate. In tali casi la “safety by design” non è solo un’opzione ma un requisito. Anche così, ci sono dei limiti a ciò che questo può realizzare perché la tecnologia è sempre un mezzo per un fine piuttosto che un fine in sé:

“Chiaramente non tutti gli incidenti possono essere prevenuti con la progettazione. Ci sono alcune conseguenze della tecnologia che non possono essere ragionevolmente previste in fase di progettazione, in particolare nelle nuove tecnologie, utilizzando nuovi materiali e principi scientifici. Tuttavia, una volta che questi hanno portato a incidenti, c’è una chiara responsabilità per i progettisti di prevenirli nei progetti futuri”. Hale, Kirwan, Kjellen (2007, p. 310)

Eppure, anche se la tecnologia è affidabile, e anche se funziona in modo altamente prevedibile, ci sono altri problemi. Ad esempio, i requisiti di sicurezza per la progettazione esecutiva sono stati adeguatamente definiti? I concetti selezionati sono comprovati dal punto di vista della sicurezza? O sarà possibile implementare i requisiti normativi, aziendali e di sicurezza dei clienti entro limiti di costo accettabili?
Sebbene queste domande riguardino questioni che hanno a che fare con l’uso del sistema nel più ampio contesto operativo, sono legittime anche per la “sicurezza fin dalla progettazione”.
Le parti non tecniche del sistema, vale a dire le persone o il liveware, sono molto più difficili da progettare. Infatti, un’organizzazione non può mai essere progettata allo stesso modo di un macchinario, una ragione fondamentale è che i “componenti” per loro natura sono variabili e flessibili, indipendentemente dal fatto che vengano considerati singolarmente o collettivamente. Umani e sociali i sistemi semplicemente non funzionano come le macchine, nonostante i coraggiosi tentativi di farli funzionare attraverso la formazione, l’interaction design e l’automazione. Per le parti non tecniche l’alternativa è focalizzarsi sul funzionamento del sistema, e su come sia possibile mantenere la variabilità entro limiti accettabili, cioè gestendo la sicurezza.

Safety by management

La gestione della sicurezza negli ultimi decenni del 20° secolo è diventata di per sé una questione importante, con una serie di soluzioni commerciali per i sistemi di gestione della sicurezza (SMS) offerti. Potrebbe quindi essere sensato guardare oltre l’uso dell’SMS come frase disinvolta e cercare di capire cosa comporta. Il punto cruciale è qui la definizione di sicurezza, cioè la definizione di cosa si suppone l’SMS debba gestire.

La gestione della sicurezza è, da un punto di vista pratico, una sorta di controllo; infatti, il significato di “gestire” è “esercitare controllo su, dirigere”. La gestione della sicurezza può quindi essere interpretata come il controllo delle funzioni e delle pratiche organizzative che insieme producono sicurezza. Lo scopo di un SMS è garantire che i “processi di sicurezza” dell’organizzazione si sviluppino nella direzione prevista e che non siano interrotti o ostacolati da eventi e condizioni interni o esterni. Questa riformulazione porta a tre domande sussidiarie. La prima è cosa sono realmente i “processi di sicurezza” organizzativi, cioè cosa “produce” sicurezza. Il secondo è come questi processi possono essere controllati nella pratica, cioè come possono essere modificati nella loro “velocità” e “direzione”. E il terzo è come si può misurare l’esito o il risultato, cioè quali sono gli indicatori appropriati di sicurezza.
Per quanto riguarda quest’ultimo, è prassi comune associare la sicurezza all’ “assenza dal rischio inaccettabile”, o come la definisce ICAO (2006):

“La sicurezza è lo stato in cui il rischio di danni alle persone o alla proprietà è ridotto e mantenuto a un livello accettabile o al di sotto attraverso un processo continuo di identificazione dei pericoli e gestione dei rischi”.

Definendo la sicurezza in questo modo, uno stato sicuro è definito dall’assenza di qualcosa e le misure o gli indicatori sono quindi, si spera, numeri decrescenti di eventi negativi. La pratica consolidata è cercare di raggiungere questo stato attraverso un approccio tripartito: eliminare i pericoli (in base alla progettazione), prevenire l’avvio di eventi che possono portare a esiti avversi (limitando le operazioni) e proteggere dagli esiti avversi (introducendo barriere) .
Questo approccio alla sicurezza implica una distinzione tra operazioni normali e anormali. Le normali operazioni assicurano che il processo (di sicurezza) vada nella direzione giusta e produca quello che si era pensato dovesse produrre o raggiungere. Le operazioni anomale o fuori dal normale interrompono o disturbano le normali operazioni o le rendono altrimenti inefficaci. La principale motivazione per la gestione della sicurezza, così come è comunemente praticata, è stata quindi quella di impedire che si verificassero tali interruzioni o disturbi.
In questo senso la gestione della sicurezza è stata guidata da ciò che è accaduto in passato, quindi è stata principalmente reattiva.

Teoria W

Un modo per caratterizzare gli approcci consolidati alla sicurezza e alla gestione della sicurezza è quello di proporre due posizioni idealizzate, espresse come due diverse teorie denominate rispettivamente Teoria W e Teoria Z. Secondo la Teoria W, i sistemi socio-tecnici sono sicuri ed efficienti perché:
• Gli impianti sono ben progettati e mantenuti scrupolosamente.
• Le procedure fornite per il funzionamento dei sistemi sono complete e corrette.
• Gli operatori dei sistemi, le persone del cosiddetto “fronte”, la prima linea per intenderci, si comportano come ci si aspetta e come sono stati addestrati.
• I progettisti possono prevedere ogni evenienza e quindi fornire ai sistemi adeguate capacità di risposta.

La teoria W descrive un mondo di sistemi ben progettati, ben collaudati e ben funzionanti. È una caratteristica di tali sistemi che esiste un alto grado di affidabilità delle apparecchiature; che i lavoratori e i dirigenti siano vigili nei test, nelle osservazioni, nell’uso delle procedure e nelle operazioni; che il personale sia ben addestrato; che la direzione sia illuminata e che siano in atto buone procedure operative. La minaccia alle normali prestazioni deriva da diversi tipi di guasti o malfunzionamenti, come guasti attivi e condizioni latenti, guasti delle apparecchiature ed errori umani.

La sicurezza può quindi essere raggiunta limitando variabilità delle prestazioni in vari modi (Figura 1).

Dai presupposti alla base della Teoria W risulta che la variabilità delle prestazioni di qualsiasi tipo dovrebbe essere evitata. I sistemi tecnologici sono progettati per svolgere una o poche funzioni in modo molto efficiente e con variabilità limitata.

Le funzioni che dipendono dagli esseri umani, siano esse come individui, come gruppi o come organizzazioni, sono più versatili ma anche meno uniformi e la variabilità è vista come una minaccia o un disturbo che può sfociare in fallimenti nelle prestazioni.

Si fa quindi tutto il possibile per evitare che ciò accada. Il passaggio da operazioni normali a operazioni anomale può avvenire bruscamente, come quando qualcosa si rompe, o gradualmente sotto forma di deriva o lento disallineamento (Cook & Rasmussen, 2005). La soluzione secondo la Teoria W è quindi quella di vincolare le prestazioni, ad esempio, mediante barriere, interblocchi, regole, procedure, standardizzazione, design dell’interazione, norme, ecc., o anche sostituendo gli esseri umani con la tecnologia, come nell’uso dell’automazione. Ciò è integrato da attività più ampie come la gestione del rischio (che comprende, ad esempio, l’identificazione del pericolo, la valutazione del rischio, l’attenuazione del rischio e la comunicazione del rischio), la segnalazione di pericoli e incidenti, le indagini sulla sicurezza, le analisi e gli studi sulla sicurezza e il monitoraggio delle prestazioni di sicurezza.

Sicurezza per sistemi sottospecificati

La teoria W corrisponde a sistemi in cui i principi di funzionamento sono chiari e in cui vi è una buona prevedibilità.

Questo non era un presupposto irragionevole all’epoca in cui furono sviluppati i metodi attualmente stabiliti, all’incirca tra il 1965 e il 1985, ma è molto meno ragionevole oggi. Ci sono due ragioni principali per questo, in primo luogo che tutti i sistemi di interesse sono più o meno intrattabili, e in secondo luogo che la variabilità delle prestazioni è inevitabile.
Figura 1. Sicurezza secondo la Teoria W

Sistemi intrattabili

Affinché un sistema sia trattabile, devono essere soddisfatte quattro condizioni:

  1. che i principi di funzionamento siano noti,
  2. che una descrizione non contenga troppi dettagli,
  3. che una descrizione possa essere fatta in tempi relativamente brevi e
  4. che il sistema non cambi durante la creazione della descrizione.

L’ultima condizione è la più importante, ed è in qualche modo una sintesi delle tre precedenti.

La teoria W richiede chiaramente che i sistemi siano trattabili. Molti degli attuali sistemi di maggior interesse per la sicurezza industriale sono purtroppo intrattabili piuttosto che trattabili. Ciò significa che i principi di funzionamento sono noti solo in parte, che la descrizione è elaborata e contiene molti dettagli, che richiede molto tempo per essere fatta, e che il sistema quindi cambia mentre viene fatta la descrizione. Di conseguenza sarà impossibile fornire una descrizione completa o una specifica del sistema. I sistemi intrattabili sono sottospecificati, nel senso che i dettagli possono mancare o non essere disponibili (ad esempio, Clarke, 2000). Ma se un sistema è sottospecificato chiaramente non è possibile fornire procedure o istruzioni precise. Le persone che lavorano nel sistema, siano esse in prima linea o nelle retrovie, devono quindi essere in grado di applicare le prescrizioni e le procedure disponibili a condizioni e situazioni diverse da quanto ipotizzato e potenzialmente sempre diverse. In altre parole, è necessario che le persone siano in grado di variare o adattare ciò che fanno per garantire che il sistema funzioni come richiesto e raggiunga i suoi obiettivi operativi.

La variabilità delle prestazioni – che si chiami improvvisazione, adattamento, compromesso tra efficienza e completezza, decisioni sacrificali o creatività – è necessaria, quindi da considerare una risorsa piuttosto che una minaccia.

L’inevitabilità della variabilità delle prestazioni

Mentre le macchine e gli artefatti tecnologici sono progettati, costruiti e mantenuti in modo da poter produrre prestazioni quasi costanti – almeno fino a quando non si guastano e devono essere sostituiti – lo stesso non può valere per gli esseri umani e per le organizzazioni. Ci sono molte ragioni per cui le prestazioni umane non possono mai essere costanti o simili a quelle di una macchina. Una ragione è che le funzioni fisiologiche (muscoli, cellule nervose, organi sensoriali, ecc.) sono soggette a fatica, saturazione e accomodamento e richiedono regolarmente un periodo di riposo o ricostituzione. Anche molte funzioni psicologiche di base, come l’attenzione o la vigilanza, sono limitate per quanto tempo possono essere mantenute a un livello costante. Una seconda ragione è che gli esseri umani sembrano avere una tendenza innata a variare ciò che fanno, spesso per evitare la monotonia o per trovare un modo più semplice per portare a termine un compito. È questa ingegnosità e creatività che è al centro dell’adattabilità e della capacità di superare i vincoli e le sottospecificazioni. Una terza ragione è la variabilità indotta socialmente, ad esempio nel senso che gli altri avranno aspettative – o anche norme informali – su quanto e quanto poco sforzo sia accettabile in una data situazione. Una diversa fonte di variabilità è la cultura organizzativa, in particolare la cultura della sicurezza. Un quarto motivo è che le prestazioni dipendono dallo stato dell’organizzazione e dell’ambiente, che possono variare in termini di richieste di lavoro, risorse disponibili, ecc. Un quinto e ultimo motivo è la variabilità dovuta alle condizioni ambientali di lavoro, ad esempio temperatura, clima , umidità, rumore, ecc.

La variabilità delle prestazioni è per questi motivi inevitabile, sia a livello del singolo individuo che dell’organizzazione. Questo fortunatamente non è uno svantaggio poiché la variabilità delle prestazioni è necessaria per superare la sottospecificazione dei grandi sistemi socio-tecnici. Ma è un problema se i modelli e i metodi di sicurezza non riescono a riconoscerlo.

Teoria Z

Poiché la maggior parte dei sistemi di interesse oggi sono intrattabili, è impossibile fornirne una descrizione completa o specificare cosa dovrebbe fare un operatore anche per molte situazioni che si verificano normalmente. Ciò è riconosciuto dalla Teoria Z, secondo la quale i sistemi socio-tecnici sono sicuri ed efficienti per i seguenti motivi:

• Gli esseri umani imparano a superare le inevitabili carenze, come i difetti di progettazione e i difetti funzionali.
• Gli esseri umani possono adattare le proprie prestazioni per soddisfare le effettive esigenze di una situazione specifica.
• Gli esseri umani possono interpretare le procedure e applicarle per adattarsi alle condizioni reali.
• Gli esseri umani possono rilevare quando qualcosa fallisce o va storto, e in molti casi possono anche correggerlo.

Nella Teoria Z, la variabilità delle prestazioni è sia normale che necessaria ed è la fonte di esiti positivi e negativi – successi e fallimenti – allo stesso modo. Di conseguenza, i guasti non possono essere prevenuti eliminando la variabilità delle prestazioni, ovvero la sicurezza non può essere gestita da vincoli.

La soluzione è invece identificare le situazioni in cui la normale variabilità delle prestazioni può combinarsi per creare effetti indesiderati e monitorare continuamente il funzionamento del sistema per intervenire e “smorzare” (dampen) la variabilità delle prestazioni che rischia di andare fuori controllo, cfr. Figura 2. Al contrario, la variabilità delle prestazioni dovrebbe essere accentuata o amplificata quando può portare a risultati positivi.
Quindi, piuttosto che cercare modi in cui qualcosa può fallire o funzionare male, dovremmo cercare di comprendere le caratteristiche della normale variabilità delle prestazioni, e in particolare come i fattori interni ed esterni possano influenzare la dimensione e la natura della variabilità.

Safety by management: ingegneria della resilienza

La differenza tra Teoria W e Teoria Z corrisponde alla differenza tra un approccio reattivo e uno proattivo alla gestione della sicurezza. Se la variabilità delle prestazioni è normale e necessaria, la sicurezza deve essere raggiunta gestendo la variabilità delle prestazioni piuttosto che limitandola. Ciò è coerente con l’ingegneria della resilienza, che si basa sui seguenti principi (Hollnagel, Woods, & Levson, 2006).

  • Le condizioni di performance sono sempre sottostimate, come sostenuto in precedenza, e gli individui e le organizzazioni devono quindi adeguare le proprie performance alle condizioni attuali. Poiché le risorse e il tempo sono limitati, tali aggiustamenti saranno inevitabilmente approssimativi.
  • Per i sistemi trattabili, la maggior parte degli eventi avversi può essere attribuita a guasti o malfunzionamenti dei componenti e alle normali funzioni del sistema. Non è così per la maggior parte degli eventi avversi nei sistemi intrattabili. Sono invece meglio compresi come il risultato di combinazioni inaspettate della normale variabilità delle prestazioni o come il contrario degli adattamenti necessari per far fronte alla complessità del mondo reale.
  • Una gestione efficace della sicurezza non può basarsi sul senno di poi, né fare affidamento sulla tabulazione degli errori e sul calcolo delle probabilità di guasto. La gestione della sicurezza non può essere solo reattiva, ma deve anche essere proattiva. L’ingegneria della resilienza cerca modi per migliorare la capacità delle organizzazioni di creare processi robusti ma flessibili, di monitorare e rivedere i modelli di rischio e di utilizzare le risorse in modo proattivo di fronte a interruzioni o pressioni produttive ed economiche in corso.

Un sistema resiliente è definito dalla sua capacità di regolare il proprio funzionamento prima, durante o in seguito a cambiamenti e disturbi in modo da poter continuare a funzionare anche dopo un grave incidente o in presenza di stress continuo. Un sistema resiliente accetta un costante senso di disagio e rimane sensibile alla possibilità di fallimento (Hollnagel, Nemeth & Dekker, 2008). La qualità della resilienza può essere definita più precisamente indicando quattro qualità o abilità essenziali che un sistema o un’organizzazione deve avere, cfr. Figura 3.

  • Un sistema resiliente deve essere in grado di rispondere alle minacce regolari e irregolari in modo robusto, ma flessibile. Non è sufficiente avere a portata di mano una serie di risposte già pronte, poiché le situazioni reali spesso non corrispondono alle situazioni previste – le uniche eccezioni possibili sono il normale funzionamento di routine.
    Figura 2: Sicurezza secondo la Teoria Z
    L’organizzazione deve essere in grado di applicare la risposta preparata in modo tale che corrisponda alle condizioni attuali sia in termini di bisogni che in termini di risorse. In termini dei tre tipi di minacce proposte da Westrum (2006) – minacce regolari, minacce irregolari ed eventi senza precedenti -, questa è la capacità di affrontare minacce regolari. Le risposte consentono l’organizzazione per far fronte alla realtà.
  • Un sistema resiliente deve essere in grado di monitorare in modo flessibile ciò che sta accadendo, comprese le proprie prestazioni. La flessibilità significa che le basi per il monitoraggio devono essere valutate di volta in volta, per evitare di rimanere intrappolati nella routine e nelle abitudini. Il monitoraggio consente al sistema di far fronte a ciò che è, o potrebbe diventare, critico nel breve termine.
  • Un sistema resiliente deve essere in grado di anticipare interruzioni, pressioni e le loro conseguenze. Ciò significa la capacità di guardare oltre la situazione attuale e il prossimo futuro, e di considerare ciò che potrebbe accadere nel medio-lungo termine. In termini dei tre tipi di minacce proposte da Westrum (op. cit.), questa è la capacità di affrontare le minacce irregolari, possibilmente anche gli eventi senza precedenti. L’anticipazione consente al sistema di far fronte al potenziale.
  • Infine, un sistema resiliente deve essere in grado di imparare dall’esperienza. Sembra piuttosto semplice, ma una soluzione concreta richiede di considerare da quali dati imparare, quando imparare e come l’apprendimento dovrebbe manifestarsi nell’organizzazione – come modifiche alle procedure, modifiche ai ruoli e alle funzioni o modifiche all’organizzazione stessa . L’apprendimento consente all’organizzazione di far fronte ai fatti.

Conclusioni

Una gestione efficace della sicurezza richiede la capacità di imparare dal passato e di anticipare il futuro. Tuttavia, ciò che possiamo imparare dal passato (ad esempio, le indagini sugli incidenti) e ciò che possiamo immaginare per il futuro (ad esempio, la valutazione del rischio) dipende in modo critico da come lo pensiamo e dai modelli e dai metodi che abbiamo a nostra disposizione. Le indagini sugli incidenti sono state a lungo dominate dalla ricerca delle cause, sia come cause alla radice che come errori umani. Analogamente, la valutazione del rischio è stata dominata da rappresentazioni di combinazioni lineari di un piccolo numero di eventi, come gli alberi degli eventi e dei guasti. In entrambi i casi il presupposto di base è che i sistemi – e gli eventi – siano trattabili.

Ha senso che i modelli e il metodo siano più o meno adeguati per l’esempio tipico di problemi al momento in cui sono stati sviluppati. In effetti, ci sarebbero pochi motivi per sviluppare un metodo più complesso o più potente di quanto richiesto, anche perché sarebbe difficile immaginare cosa dovrebbe comprendere. Nuovi modelli e metodi vengono sviluppati perché modelli e metodi esistenti prima o poi incontrano problemi per i quali sono inefficienti o inadeguati. Questo, a sua volta, accade perché i sistemi socio-tecnici in cui si verificano gli incidenti continuano a svilupparsi e a diventare più complessi e più strettamente interconnessi (accoppiati). Il risultato inevitabile è che qualsiasi metodo dopo un po’ diventa poco potente perché la natura dei problemi cambia, anche se potrebbe essere stato perfettamente adeguato per i problemi per i quali è stato sviluppato inizialmente.

I rischi che dominano nei sistemi odierni hanno un’eziologia diversa rispetto ai rischi che dominavano anche uno o due decenni fa. Questo ha due ramificazioni importanti. Il primo è che è più difficile comprendere i rischi attuali, almeno fino a quando non si è verificato un incidente. È più difficile comprendere i “meccanismi”, perché i rischi possono derivare da interazioni non lineari tra la normale variabilità delle prestazioni, nonché dalle conseguenze di guasti e malfunzionamenti. E per questo è ancora più difficile pensare a modi per ridurre o eliminare i rischi, quindi gestire la sicurezza.

La seconda conseguenza è che molti dei metodi consolidati di valutazione del rischio e di indagine sugli incidenti sono inadeguati per sistemi strettamente accoppiati e intrattabili. Questo dilemma è stato chiarito quando Perrow (1984) ha proposto che gli incidenti potessero essere visti come normali, in contrasto con i metodi di valutazione del rischio e di indagine sugli incidenti che si concentrano naturalmente su ciò che è anormale o disfunzionale. La lezione da trarre da ciò è che dobbiamo continuare a valutare criticamente i metodi a nostra disposizione. Il fatto che un metodo abbia funzionato in passato non garantisce che funzionerà anche in futuro. Infatti, nel momento in cui un metodo viene adottato come standard, è quasi certo che sia obsoleto. I modi in cui si sviluppano i sistemi socio-tecnici significano che i rischi possono emergere in modi diversi e che quindi i metodi esistenti prima o poi dovranno essere integrati con più approcci potenti.

Quali saranno, nessuno può dirlo con certezza.

Il modello non-lineare o modello sistemico

Le performance di un sistema complesso sono sempre variabili, sia per la variabilità dell’ambiente/contesto (variabilità esogena) che per la variabilità dei sottosistemi che lo costituiscono (variabilità endogena).

La variabilità endogena è in larga parte attribuibile alle persone che operano all’interno del sistema, siano esse singoli o gruppi. Ciò non significa che le performance umane siano sbagliate o cariche di errori a priori, anzi, la variabilità delle performance è necessaria se incontra un sistema cognitivo congiunto, dove il sistema uomo-macchina o più correttamente sistema socio-tecnico riesce a far fronte con successo alla complessità del mondo reale.

Ingegneria della resilienza, il modello non lineare o sistemico

Linearità semplice o il Five Domino Model

Il five domino model o modello della linearità semplice è stato pubblicato da Heinrich per la prima volta nel 1931 su “Industrial Accident Prevention: a scientific approch”.

Con questo studio Heinrich ha sviluppato un modello di causalità sequenziale, secondo cui l’incidente è il risultato di una propagazione lineare di una catena di cause ed effetti. Con questo primo modello che ha impegnato Heinrich per quasi 30 anni, si è avuta una prima formulazione completa della teoria della sicurezza, basata su 10 assiomi per la sicurezza industriale.

Il primo assioma recita:

“Il verificarsi di un infortunio deriva invariabilmente da una sequenza completa di fattori, l’ultimo dei quali è l’incidente stesso. L’incidente a sua volta è invariabilmente causato o consentito direttamente dall’azione pericolosa di una persona e/o da un pericolo meccanico o fisico.”

Linearità complessa o Swiss Cheese

Il modello di linearità complessa, conosciuto come modello di Reason o del formaggio svizzero (Swiss Cheese Model – SCM), è stato presentato per la prima volta nel 1990 da James T. Reason. Secondo questo modello gli incidenti sono visti come il risultato di interrelazioni tra atti non sicuri compiuti da operatori e condizioni latenti, rappresentate da difese e protezioni deboli, che si presentano in real time, ossia in sequenza temporale utile affinchè le condizioni “negative” (minacce e vulnerabilità) abbiano ad incontrarsi causando l’incidente. 

Related Articles

Related