Cosa è la Safety I

Ingegneria della Resilienza

Ago 25, 2022 | Resilience Engineering, Risk Management, Safety, Safety I

Perchè è necessario rivedere i criteri con cui si definisce un sistema sicuro

Cosa è la Safety-I

Resilience Engineering, Risk Management, Safety, Safety I

Ingegneria della Resilienza
Ingegneria della resilienza, Resilience Engineering

Written by redazione

La prospettiva tradizionale secondo cui la safety sia definita come assenza di accident ed incident o comunque in un numero il più basso ragionevolmente possibile (ALARP – As Low As Reasonable Possible[1]), prende il nome di Safety I.

 

[1] Il termine ALARP deriva dalla legislazione britannica, in particolare dall’Health and Safety at Work etc. Act 1974, che richiede “Fornitura e manutenzione di impianti e sistemi di lavoro che siano, per quanto ragionevolmente praticabile, sicuri e senza rischi per la salute”. La frase So Far As is Reasonably Practicable (SFARP) in questa e in simili clausole viene interpretata come un requisito per cui i rischi devono essere ridotti a un livello che sia il più basso possibile (ALARP).  Vedi anche https://www.hse.gov.uk/managing/theory/alarpglance.htm

Continue Reading: 12min Read

A supporto di questa teoria, le stesse autorità di controllo e regolamentazione richiedono notifiche e rapporti dettagliati sugli accident e gli incident e talvolta persino sui cosiddetti eventi non intenzionali (si pensi al ruolo dell’autorità Garante per la protezione dei dati personali in relazione ai data breach), così aziende, dipartimenti e le figure impegnate in ruoli organizzativi si dedicano all’analisi degli eventi ad impatto negativo. Ne consegue che si ha una grande quantità di dati e informazioni sugli incidenti ed eventi avversi, popolando database che crescono di anno in anno. Cresce la letteratura a livello internazionale su tali eventi con la stesura di migliaia di articoli, libri e conferenze nazionali e internazionali specializzate. Il risultato finale è un diluvio di informazioni sia su come le cose vanno male sia su cosa si deve fare per evitare che ciò accada. La soluzione generale è nota come “find and fix”: cercare guasti e malfunzionamenti, trovare le cause, quindi eliminare tali cause o introdurre barriere, o entrambi.
La situazione è molto diversa per gli eventi che vanno bene. La regola giornalistica, secondo cui un evento disastroso fa molta più audience di una cosa che va bene e funziona correttamente, trova piena applicazione in questa disciplina. Sono rarissimi i casi di premialità in questo senso e non ci sono requisiti da parte delle autorità per esaminare ciò che funziona bene e quindi poche aziende, uffici e dipartimenti lo fanno.

Possibili eccezioni sono gli audit e i sondaggi, che possono includere un focus sui punti di forza e le recensioni occasionali di “buone notizie” o “buone pratiche”, commissionate da amministratori delegati generalmente per le sole azioni di marketing (soprattutto il social media marketing). Tuttavia, nel complesso, i dati sono difficili da trovare, ci sono pochi modelli, ancora meno metodi e il vocabolario è scarso se messo a confronto con ciò che va storto.
Safety-I promuove una visione bimodale del lavoro e delle attività, secondo la quale esiti accettabili e negativi sono dovuti a differenti modalità di funzionamento. Quando le cose vanno bene è perché il sistema funziona come dovrebbe e perché le persone lavorano come previsto/immaginato; quando le cose vanno male è perché qualcosa non funziona correttamente o non funziona.

Si presume che le due modalità siano nettamente diverse e lo scopo della gestione della sicurezza è naturalmente quello di garantire che il sistema rimanga nella prima modalità e non sconfini mai nella seconda (vedi Figura 1).

Il punto di partenza per la gestione della sicurezza è che qualcosa sia andato storto o che qualcosa sia stato identificato come un rischio. 

Entrambi i casi utilizzano il citato approccio “find and fix“: nel primo caso, trovando le cause e quindi sviluppando una risposta adeguata, e nel secondo, identificando i pericoli al fine di eliminarli o contenerli. Un’altra soluzione consiste nell’impedire una transizione da uno stato “normale” a uno “anormale” o meglio di “malfunzionamento”, indipendentemente dal fatto che ciò sia dovuto a una transizione improvvisa o a una graduale “deriva verso il guasto”. Ciò si ottiene vincolando le prestazioni nello stato “normale”, rafforzando la conformità ed eliminando la variabilità (vedere la figura 2). Un ultimo passaggio consiste nel verificare se il numero di esiti avversi si riduce. Se ciò accade, è la prova che gli sforzi hanno funzionato come previsto.

In questa logica è chiaro che la percezione di sicurezza viene offerta dalla presenza e dalla quantità di eventi negativi, pertanto, un sistema è considerato non sicuro se si presenta un esito negativo occasionale o se il rischio e considerato inaccettabile, mentre si dice sia sicuro se tali esiti di verificano raramente o per niente, o se il rischio è considerato accettabile.
Questa è, tuttavia, una definizione indiretta perché la sicurezza viene definita dal suo opposto, da ciò che accade quando è assente piuttosto che quando è presente. Una curiosa conseguenza è che analizziamo e cerchiamo di imparare da situazioni in cui, per definizione, c’era una mancanza di sicurezza.

Figura 1 – Safety-I presuppone che le cose che vanno bene e le cose che vanno male accadano in modi diversi – Erik Hollnagel, Robert L Wears, Jeffrey Braithwaite: From Safety-I to Safety-II: A White Paper

Figura 1 – Sicurezza per eliminazione e prevenzione – Erik Hollnagel, Robert L Wears, Jeffrey Braithwaite: From Safety-I to Safety-II: A White Paper

Un’altra curiosa conseguenza è che il livello di sicurezza è inversamente correlato al numero di esiti avversi. Se molte cose vanno storte, si dice che il livello di sicurezza è basso, ma, se poche cose vanno storte, si dice che il livello di sicurezza è alto. In altre parole, più manifestazioni ci sono, meno sicurezza c’è e viceversa. Un perfetto livello di sicurezza significa che non ci sono esiti negativi, quindi niente da misurare.

Questo purtroppo rende molto difficile, se non impossibile, dimostrare che gli sforzi per migliorare la sicurezza hanno funzionato, quindi molto difficile sostenere investimenti in tal senso. È l’annoso problema dei CISO (Chief Information Security Officer) di tutte le aziende, che trovano enormi difficoltà nella richiesta di risorse, siano esse economiche o figure professionali specializzate, per garantire la sicurezza informatica e la stabilità dei sistemi IT aziendali.

Quindi per dare un senso alle manifestazioni si utilizza il credo della causalità, una convinzione predominante a livello globale secondo cui gli esiti avversi (accident e incident), accadano perché qualcosa va storto, quindi, hanno cause che possono essere trovate e trattate. Mentre è ovviamente ragionevole presumere che le conseguenze siano precedute da cause, è un errore presumere che le cause siano banali o che si possano sempre trovare. Il credo della causalità è stato espresso nel corso degli anni da svariati modelli di accident. La versione forte di questo credo è l’assunto sulle cause alla radice, come espresso dalla Root Cause Analysis[2], molto diffusa ancora oggi nella cybersecurity.

Mentre questo tipo di approccio lineare semplice è stato più o meno adeguato per la prima parte del XX secolo, i sistemi socio-tecnici sempre più complicati e intrattabili che si sono sviluppati nella seconda metà, hanno richiesto meccanismi più intricati e più potenti. Oltre al ben noto Swiss Cheese Model, che spiega gli esiti negativi come risultato di una combinazione di fallimenti attivi e condizioni latenti, citiamo TRIPOD (Reason et al., 1989), AcciMap (Rasmussen & Svedung, 2000)[3] e STAMP (Leveson, 2004). Eppure, in tutti i casi il credo della causalità consente all’analista di ragionare a ritroso, dalle conseguenze alle cause sottostanti. Ma come ha osservato Reason (1997), “il pendolo potrebbe essere andato troppo lontano nei nostri attuali tentativi di rintracciare possibili errori e contributi accidentali che sono ampiamente separati sia nel tempo che nel luogo dagli eventi stessi”. La crescente complessità di questi modelli ha portato al pensiero un po’ dispettoso che lo “Swiss Cheese Model abbia superato la data di scadenza” (Reason, Hollnagel & Paries 2006).

Alla base della Safety-I, come abbiamo già osservato, ci sono i bias cognitivi dettati da una visione del mondo di tipo cartesiano-newtoniano. Questa visione implica due importanti presupposti: uno è che i sistemi siano scomponibili nelle loro parti costituenti, l’altro è che i sistemi siano bimodali, cioè le loro parti funzionano correttamente oppure no.

Dalle definizioni fornite al Capitolo 1, sappiamo che possiamo costruire sistemi mettendo insieme elementi e combinando e organizzando accuratamente i loro componenti.

Il primo presupposto è che questo processo possa essere invertito e che possiamo comprendere i sistemi scomponendoli in costituenti significativi. Abbiamo un certo successo con la decomposizione dei sistemi tecnologici per trovare le cause degli incidenti, ad esempio guasti ai dispositivi medici in sala operatoria. Assumiamo inoltre di poter scomporre i “sistemi soft” (le persone nelle organizzazioni) nei loro componenti (dipartimenti, uffici, ruoli, stakeholder, team). E infine assumiamo che lo stesso possa essere fatto per i compiti e per gli eventi, in parte a causa della semplicità della linea temporale (questo evento è accaduto dopo quell’evento, e quindi il primo evento lo ha “causato”). Ma ci sbagliamo in tutti i casi.

Si presume inoltre, che i “componenti” di un sistema possano trovarsi in una delle due modalità, funzionando correttamente o no (malfunzionamento), eventualmente impreziosita dall’inclusione di varie modalità di funzionamento degradate. I componenti del sistema sono generalmente progettati o ingegnerizzati per fornire una funzione specifica e, quando ciò non accade, si dice che si siano guastati, abbiano funzionato male o si siano deteriorati. Mentre questo ragionamento è valido per i sistemi tecnologici e le loro componenti, non è valido per i sistemi socio-tecnici, e sicuramente non per le componenti umane e organizzative, in una misura tale per cui è addirittura privo di senso utilizzarlo. Sebbene i due presupposti (scomponibilità e bimodalità) rendano conveniente cercare le cause e rispondere aggiustandole, portano anche a descrizioni e scenari di sistema con trattabilità e specificità illusorie e quantificazione con precisione illusoria. Sono quindi insufficienti come base per la gestione della sicurezza nel mondo di oggi.

[2] La root cause analysis (RCA) è una tecnica di indagine che viene applicata ad eventi di particolare impatto, in particolare incidenti, ed è finalizzata ad esaminare quanto accaduto ricercandone le cause. Rispetto alle indagini di tipo tradizionale, l’obiettivo è quindi focalizzato non tanto sulla ricerca delle responsabilità (chi è stato), quanto sulla identificazione degli interventi di miglioramento (in modo da evitare il ripetersi dell’accaduto).

[3] Gli incidenti sono il risultato della combinazione di atti pericolosi e inneschi locali, derivanti da situazioni specifiche che penetrano nelle difese disponibili. I tipi di guasto generale sono alla base di entrambi, consentendo il verificarsi di atti non sicuri e il verificarsi di fattori scatenanti pericolosi. Vedi anche https://www.researchgate.net/publication/243786904_Tripod_Delta_Proactive_Approach_to_Enhanced_Safety

Il metodo AcciMap è stato sviluppato come componente del Risk Management Framework (RMF) e può essere utilizzato come tecnica standalone a parte e come parte della più ampia metodologia RMF costituita dall’uso di ActorMaps e Conflict Maps (Rasmussen & Svedung 2000). Il metodo Acci-Map consente agli analisti di mappare graficamente le relazioni causali che portano a un evento avverso attraverso ciascuno dei livelli in un sistema sociotecnico (Branford 2011).

https://www.researchgate.net/publication/329695352_Comparing_HFACS_and_AcciMaps_in_a_health_informatics_case_study-the_analysis_of_a_medication_dosing_error

Cosa si intende
per Safety-II e perchè
é importante conoscerla

In innumerevoli situazioni, dalla quotidianità ospedaliera al lavoro nei cantieri edili, gli operatori agiscono in sicurezza perché sono in grado di adattare il proprio lavoro in modo adeguato rispetto alle condizioni presenti. Nei sistemi trattabili e ben progettati (come l’aviazione, l’industria mineraria e manifatturiera, ma anche la produzione farmaceutica), la necessità di adeguamenti è ridotta proprio a causa della maturità del settore. In molti casi c’è anche la possibilità di rinviare o ritardare le operazioni quando le circostanze diventano sfavorevoli, come nei casi in cui i voli vengono cancellati a causa del tempo, oppure l’intero sistema può spegnersi, come è successo in occasione dell’11 settembre 2001 e quando il vulcano islandese Eyjafjällajökull è eruttato nell’aprile/maggio 2010.

Credit rai.it

Invece di guardare solo ai pochi casi in cui le cose vanno male, dovremmo guardare ai molti casi in cui le cose vanno per il verso giusto e cercare di capire come e perché ciò avvenga.

La soluzione proposta dalla Safety-II a tutto questo è sorprendentemente semplice: invece di guardare solo ai pochi casi in cui le cose vanno male, dovremmo guardare ai molti casi in cui le cose vanno per il verso giusto e cercare di capire come e perché ciò avvenga. Dobbiamo riconoscere che le cose vanno bene perché i medici sono in grado di adattare il loro lavoro alle condizioni piuttosto che perché funzionano come immaginato. L’ingegneria della resilienza riconosce che i risultati accettabili e gli esiti negativi hanno una base comune, vale a dire gli aggiustamenti quotidiani delle prestazioni. Continua a leggere…

Related Articles

Related