Esempio di valutazione del rischio secondo ISO 12100 non significa prendere un foglio Excel, aggiungere punteggi, citare due norme e produrre un PDF finale dall’aria autorevole. Il peggior tipo di valutazione del rischio non è quello caotico. È quello che sembra impeccabile. Ha righe ordinate, commenti, riferimenti normativi, caselle compilate e un esito finale che dà al team una sensazione pericolosa: il tema è chiuso. Peccato che ISO 12100 non valuti l’estetica del documento. Valuta se il processo di sicurezza è stato davvero condotto, riesaminato e documentato.
Qui si apre la frattura tra amministrazione e ingegneria. Un foglio può contenere dati. Non per questo contiene logica. Non obbliga a partire dai limiti della macchina. Non costringe a distinguere un compito reale da una descrizione generica. Non ti ferma quando salti dalla presenza di un pericolo direttamente al riparo o alla procedura, ignorando la sequenza richiesta da ISO 12100: progettazione intrinsecamente sicura, misure di protezione tecniche, informazioni per l’uso.
La domanda giusta, quindi, non è se si possa fare una valutazione del rischio in Excel. Certo che si può. La domanda vera è un’altra: quel file riesce a governare un processo che, tra sei mesi, saprai ancora ricostruire, verificare e difendere davanti a un audit, a un cliente o dentro un fascicolo tecnico per la Direttiva 2006/42/CE?
Esempio di valutazione del rischio secondo ISO 12100: quando il foglio Excel inganna
Dire che un foglio Excel non basta non significa demonizzare lo strumento. Come supporto di lavoro va benissimo. Può raccogliere note, aiutare il team, ordinare informazioni. Il problema nasce quando lo si scambia per la documentazione della valutazione del rischio. Non sono la stessa cosa.
ISO 12100 non chiede un file. Chiede una documentazione che renda leggibile il ragionamento tecnico. In pratica, deve essere chiaro non solo che cosa è stato scritto, ma anche perché è stato scritto.
Una documentazione credibile deve mostrare almeno questi elementi:
- quali erano i limiti della macchina;
- quali compiti reali sono stati analizzati;
- quali situazioni pericolose e quali eventi pericolosi sono stati considerati;
- come è stata fatta la stima del rischio iniziale;
- quale misura di protezione è stata scelta e in quale ordine rispetto alla logica di ISO 12100;
- se la misura ha introdotto un rischio secondario;
- come è stato determinato il rischio residuo;
- chi ha preso le decisioni e su quale base.
Questo è il punto che spesso sfugge: un documento serio non è una raccolta di celle compilate. È la registrazione di un processo. Deve consentire, anche a distanza di tempo, di ricostruire i passaggi, seguire le modifiche, verificare la coerenza e capire perché una scelta tecnica è stata ritenuta sufficiente.
Quando questa struttura manca, non hai ancora una documentazione della valutazione del rischio. Hai solo dati di lavoro. Talvolta ordinati. Talvolta persino convincenti a prima vista. Ma sempre dati di lavoro.
Ed è qui che molte valutazioni deragliano. Per comodità si salta direttamente al classico schema pericolo, riparo, istruzioni. Sembra efficiente, ma è una scorciatoia pericolosa. Se non dimostri che hai ragionato prima sulla riduzione del rischio alla fonte, poi sulle misure di protezione, e solo dopo sulle informazioni per l’uso, stai piegando il processo alla forma del documento. E la forma, da sola, non salva nessuno.
Il rischio secondario: il punto in cui molte valutazioni smettono di guardare
Una misura di protezione non chiude il processo. Lo cambia. E ogni volta che cambi il sistema uomo-macchina-processo, devi verificare che cosa hai spostato, non solo che cosa hai ridotto.
Questo è il terreno del rischio secondario. Non è un dettaglio da pedanti. È uno dei test più seri per capire se il team sta facendo vera ingegneria della sicurezza oppure sta semplicemente aggiungendo soluzioni a un elenco di problemi.
Riparo mobile interbloccato: bene per il moto, male per il servizio?
Prendiamo un caso meccanico molto comune. In una stazione automatica c’è il rischio di contatto con un movimento pericoloso durante la rimozione degli inceppamenti. Il team introduce un riparo mobile interbloccato. All’apparenza è una buona scelta: durante il ciclo automatico l’accesso è limitato.
Ma dopo la modifica emerge un’altra realtà. Per pulire o liberare la macchina, l’operatore deve lavorare più in profondità, infilare il braccio in uno spazio stretto, muoversi in postura scomoda e operare attraverso un’apertura di servizio meno favorevole. Il rischio principale è sceso, certo. Però il sistema è diventato peggiore per accessibilità, visibilità ed ergonomia. Se questo non viene rivalutato, la documentazione racconta solo metà della storia.
Funzione di sicurezza corretta, comportamento umano peggiore
Altro esempio, lato automazione. Si aggiungono interblocco, reset manuale e blocco del riavvio automatico dopo l’apertura del riparo. La funzione di sicurezza, sulla carta, è corretta. Il problema nasce quando la nuova sequenza rallenta ogni intervento, spezza il ritmo operativo e aumenta i passaggi necessari per riprendere la produzione.
Se la logica è stata progettata senza guardare al lavoro reale, compare un rischio secondario organizzativo e comportamentale:
- reset eseguito in modo riflesso;
- mancato controllo effettivo della zona prima del riavvio;
- tentativi di bypass delle protezioni;
- pressione a velocizzare l’intervento fuori dalle regole previste.
La funzione non è sbagliata in sé. Sbagliato è introdurla senza verificare come modifica il comportamento delle persone.
Diagnostica guasti elettrica: meno esposizione, più complessità
Passiamo all’elettrico. In un quadro emerge rischio di contatto durante la diagnostica guasti. Il team migliora l’involucro, separa meglio i circuiti, definisce l’isolamento, la verifica di assenza tensione e limita l’accesso a personale autorizzato. Fin qui tutto bene.
Ma la diagnostica diventa più lunga, più sequenziale, più dipendente dall’ordine corretto dei passaggi. A quel punto bisogna fare una domanda scomoda: riducendo il rischio elettrico diretto, abbiamo aumentato il rischio di errore procedurale? Se una procedura diventa troppo fragile, troppo lunga o poco intuitiva, nasce un rischio secondario legato all’organizzazione del lavoro.
Collegamento equipotenziale fatto a metà: la buona intenzione può peggiorare il quadro
Un altro caso tipico è il collegamento equipotenziale applicato solo a una parte della macchina. L’idea sembra virtuosa: migliorare la continuità e abbassare il rischio di scossa. Ma se l’intervento è frammentario e non considera l’intero sistema, puoi creare una situazione peggiore:
- una parte della macchina si ritrova con un riferimento diverso rispetto al resto;
- in guasto o in transitorio aumenta la probabilità di differenze di potenziale;
- chi tocca contemporaneamente due parti del sistema entra in uno scenario più severo di quello iniziale.
Questo è il punto chiave: la misura di protezione non va valutata come gesto isolato. Va valutata per l’effetto complessivo sull’insieme uomo-macchina-energia-processo.
Audit trail e tracciabilità decisionale: non burocrazia, ma memoria tecnica
Molti team trattano l’audit trail, cioè la tracciabilità decisionale, come un optional da software. In realtà è il contrario. È la prova che qualcuno ha ragionato davvero.
Il documento finale mostra il risultato. L’audit trail mostra il percorso. E in una valutazione del rischio il percorso conta quanto il risultato, a volte di più.
Le domande che contano arrivano sempre dopo:
- chi ha cambiato la stima del rischio e quando;
- perché una situazione pericolosa è passata da media a bassa;
- chi ha accettato il rischio iniziale e su quale base;
- perché in un caso sono bastate istruzioni e in un altro è stata necessaria una funzione di sicurezza;
- perché è stato richiesto proprio PL d secondo ISO 13849 e non un altro livello.
Senza tracciabilità decisionale, una modifica può sembrare un ragionamento tecnico quando in realtà è solo un ritocco al risultato finale. È il difetto classico del foglio Excel: conserva bene lo stato finale, conserva male la logica che ci ha portato lì. Una cella si sovrascrive. Un commento si aggiorna. Un valore cambia. Dopo poco non distingui più l’evoluzione dell’analisi dal semplice allineamento del file all’esito desiderato.
Tre esempi chiariscono il problema.
Primo. Una situazione pericolosa era stata stimata come media, poi diventa bassa. Se non sai chi ha modificato l’esito e perché, non puoi capire se la riduzione deriva da una nuova misura di protezione, da una revisione dei parametri o da una chiusura frettolosa.
Secondo. Un rischio viene dichiarato accettabile. Bene. Ma accettabile perché l’esposizione è sporadica, il danno prevedibile è lieve, l’accesso è controllato e il compito è affidato a persone formate? Oppure perché il numero finale era comodo? Senza base decisionale, le due cose appaiono identiche nel documento. Tecnicamente, però, non lo sono affatto.
Terzo. Compare una funzione di sicurezza con requisito PL d. Tutto sembra professionale. Ma se nessuno sa più quale funzione specifica doveva coprire, che cosa controllava, che cosa arrestava e perché il livello richiesto fosse proprio quello, allora quel dato ha perso valore tecnico. È rimasta l’etichetta, non la logica.
Per questo la tracciabilità decisionale non è un abbellimento. È la memoria tecnica del progetto. Se manca, non stai difendendo la valutazione del rischio. Stai difendendo solo l’ultima versione del file.
Esempio di valutazione del rischio secondo ISO 12100: una macchina, sedici situazioni pericolose
Per uscire dalla teoria, prendiamo un caso realistico: una stazione di confezionamento automatizzata con movimenti pericolosi, interventi dell’operatore, rimozione degli inceppamenti, attività di manutenzione, accesso a energia elettrica e pneumatica, e funzioni di sicurezza dipendenti dalla logica di controllo.
Qui la valutazione non si è fermata a due o tre righe generiche sul rischio meccanico. Sono state analizzate sedici situazioni: tredici scenari di compito e tre eventi pericolosi secondo la logica di ISO 12100. In concreto sono stati separati, tra gli altri:
- piccoli interventi durante il funzionamento;
- rimozione degli inceppamenti;
- regolazione dei dispositivi di protezione;
- prove funzionali;
- isolamento delle fonti di energia;
- sostituzione di componenti soggetti a usura;
- diagnostica guasti;
- avviamento inatteso;
- proiezione di oggetti;
- rilascio di energia pneumatica;
- accesso alle parti attive durante determinate operazioni.
Questo livello di dettaglio non è accademia. È ciò che permette di vedere il rischio vero. Una macchina non si valuta in astratto. Si valutano le interazioni tra persona e macchina in compiti specifici, in zone specifiche, con fonti di energia specifiche e in condizioni specifiche di accesso.
Esempio di valutazione del rischio secondo ISO 12100: che cosa ha mostrato davvero
Il caso ha mostrato alcuni punti che si ripetono quasi sempre nelle valutazioni serie.
Primo. Il rischio più pesante non derivava dalla sola presenza del movimento pericoloso, ma dall’accesso a quel movimento durante gli interventi. È una differenza enorme. Se la perdi, progetti protezioni per la macchina in generale e non per il compito reale.
Secondo. Alcuni scenari potevano essere accettati come bassi, ma non per automatismo. Erano difendibili solo perché risultavano chiari la frequenza ridotta, la durata limitata, il contesto controllato e il ruolo dell’utilizzatore. In altre parole, il rischio basso non era un numero comodo. Era un esito giustificato.
Terzo. Gli scenari medi non erano difendibili con la scorciatoia classica del riparo + istruzioni. In diversi casi è stato necessario descrivere la logica della funzione di sicurezza, il blocco del riavvio, il reset manuale, le condizioni di accesso e il rischio residuo. Solo così la scelta tecnica diventava verificabile.
Quarto. La rivalutazione dopo l’introduzione delle misure di protezione è stata essenziale. Prima stima, decisione, riduzione del rischio, verifica del rischio secondario, nuova stima e solo infine valutazione del rischio residuo. È qui che i documenti semplificati di solito si spezzano: mostrano il finale, ma non mostrano il percorso.
Quinto. La tracciabilità decisionale ha reso leggibile chi ha accettato certi scenari e chi invece li ha indirizzati a riduzione del rischio. Questo aspetto conta più di quanto sembri: quando il progetto evolve, le decisioni senza memoria diventano rapidamente indifendibili.
Che cosa rende buona una valutazione del rischio secondo ISO 12100
Una buona valutazione del rischio non inizia compilando un elenco di pericoli. Inizia stabilendo:
- per che cosa la macchina è stata concepita;
- chi la userà e in quali condizioni;
- quali sono i limiti della macchina;
- quali compiti reali verranno eseguiti;
- quali situazioni pericolose e quali eventi pericolosi devono essere considerati;
- quali misure di protezione sono state selezionate e nell’ordine richiesto da ISO 12100;
- se le misure hanno creato un rischio secondario;
- come è stato determinato il rischio residuo.
Se nel documento questi passaggi non si leggono, allora non stai guardando un buon esempio di valutazione del rischio. Stai guardando un allegato ordinato.
Questo non significa che serva per forza uno strumento complesso. Significa però che lo strumento deve sostenere il metodo, non sostituirlo. Un Safety Software può aiutare molto se impone sequenza logica, revisioni, responsabilità e audit trail. Ma anche il miglior sistema non corregge un processo confuso. Digitalizzare il caos non produce sicurezza: produce solo caos ben impaginato.
La regola pratica è semplice. Se non riesci a rispondere con chiarezza a queste domande, la valutazione è debole:
- quale compito stiamo analizzando;
- in quale zona e con quale fonte di pericolo;
- perché la misura di protezione scelta è adeguata;
- che cosa è cambiato dopo la misura;
- se è comparso un rischio secondario;
- perché il rischio residuo è stato ritenuto accettabile;
- chi ha preso la decisione finale.
Alla fine, la differenza vera è tutta qui. Una tabella raccoglie risultati. Una valutazione del rischio ben fatta registra decisioni tecniche. E nel mondo reale, quando qualcosa va storto, nessuno ti chiede se il file era bello. Ti chiedono se il ragionamento era corretto, coerente e dimostrabile.
Se vuoi un criterio semplice per fare autocontrollo, usalo senza sconti: se domani togli il PDF finale e lasci solo il processo, il team saprebbe ancora spiegare perché ogni rischio è stato accettato, ridotto o trasferito a una misura di protezione specifica? Se la risposta è no, il lavoro non è finito. Sembra finito. Che è esattamente il problema.