Il metodo dei 5 perché si basa su un postulato semplice: ogni sintomo nasconde una causa, e ogni causa ne nasconde un’altra. L’interrogazione iterativa consente di risalire la catena fino a un leva d’azione concreta. Osserviamo che la maggior parte dei fallimenti di applicazione non deriva dal metodo stesso, ma da una cattiva qualificazione del problema iniziale e da un’interruzione prematura dell’analisi.
Bias di selezione nella catena causale dei 5 perché
Il punto debole strutturale del metodo è raramente affrontato nelle guide pratiche: due team competenti possono produrre catene causali diverse a partire dallo stesso incidente. Ogni “perché” apre a diverse risposte plausibili, e la scelta del ramo seguito dipende dall’esperienza, dalle ipotesi implicite e dai dati disponibili al momento dell’analisi.
Questo bias di selezione ha una conseguenza diretta. L’azione correttiva messa in atto corregge una causa reale, ma non necessariamente la causa che ha il maggiore impatto sulla ricorrenza del problema. Raccomandiamo di documentare sistematicamente la prova associata a ogni risposta: dato di produzione, osservazione sul campo, registrazione qualità. Una risposta non supportata da un fatto verificabile deve essere segnalata come ipotesi e trattata come tale.
Per i problemi con catena causale unica e tracciabile, il metodo funziona in modo straordinario. Al contrario, quando più guasti devono combinarsi per produrre l’incidente, l’analisi lineare diventa insufficiente. Il diagramma di Ishikawa o l’albero dei guasti consentono quindi di mappare le interazioni tra fattori latenti.
Una guida completa che dettaglia il metodo dei 5 perché su Nefa Blog descrive i passaggi di applicazione sequenziale e le condizioni di successo per un’analisi rigorosa.
Criteri di arresto dell’analisi: quando superare o accorciare le 5 iterazioni
Il numero cinque non è una regola metodologica rigorosa. L’analisi si ferma quando la causa identificata è controllabile e collegata a un’azione correttiva verificabile, che si tratti di tre, cinque o più domande. Imporsi esattamente cinque iterazioni porta a due derive opposte: fermarsi troppo presto su un sintomo intermedio, o forzare una sesta domanda che non produce alcuna informazione utilizzabile.
Il criterio di arresto operativo si basa su tre condizioni cumulative:
- La causa identificata è sotto il controllo diretto del team o del processo interessato (possiamo agire su di essa senza escalation gerarchica esterna).
- Una prova fattuale (misura, registrazione, osservazione) conferma il legame tra questa causa e l’effetto osservato.
- L’azione correttiva prevista può essere testata e la sua efficacia verificata entro un termine ragionevole.
Se la risposta all’ultimo “perché” è “errore umano”, l’analisi non è conclusa. Concludere sull’errore umano è un segnale di arresto prematuro. Il passo successivo consiste nell’identificare le condizioni del sistema che hanno reso possibile questo errore: progettazione dell’interfaccia, carico di lavoro, assenza di controllo, procedura inadeguata o supervisione carente.
Verifica dell’azione correttiva dopo l’analisi dei 5 perché
Identificare una causa radice non dimostra che la soluzione funzioni. Osserviamo regolarmente team che chiudono la loro analisi non appena formulano il piano d’azione, senza un ciclo di verifica. Il metodo perde così la sua finalità: prevenire la ricorrenza.
Ogni azione correttiva deve essere oggetto di un monitoraggio strutturato. La verifica si concentra su due dimensioni: l’azione è stata implementata secondo quanto previsto, e l’effetto indesiderato è scomparso o significativamente diminuito entro un termine definito in anticipo.
Il classico tranello è misurare lo sforzo (formazione fornita, procedura aggiornata) piuttosto che il risultato (scomparsa o riduzione dell’incidente). Un indicatore di risultato deve essere definito prima dell’implementazione dell’azione correttiva, non dopo.
Formalizzazione minima per tracciare l’analisi
Una tabella semplice è sufficiente per ogni iterazione:
| Livello | Domanda posta | Risposta fattuale | Prova associata |
|---|---|---|---|
| Perché 1 | Perché si è verificato l’incidente? | Risposta documentata | Fonte del dato |
| Perché 2 | Perché esiste questa causa? | Risposta documentata | Fonte del dato |
| Perché N | Iterazione fino a causa controllabile | Risposta documentata | Fonte del dato |
La colonna “prova associata” è la più trascurata e la più utile. Essa costringe il team a distinguere un fatto verificato da un’ipotesi. Senze prova documentata, la risposta rimane un’ipotesi, non una causa validata.
Limiti strutturali e complementarità con altri strumenti di analisi
Il metodo dei 5 perché eccelle in un ambito preciso: un problema osservabile, una catena causale dominante, un team che conosce il processo. Al di fuori di questo contesto, produce risultati parziali.
Le situazioni in cui raccomandiamo di combinare o sostituire l’approccio:
- Problemi a cause multiple indipendenti: il diagramma di Ishikawa consente di strutturare le famiglie di cause prima di avviare un 5 perché su ogni ramo pertinente.
- Guasti sistemici che coinvolgono interazioni tra sottosistemi: l’albero dei guasti modella le combinazioni di fattori necessarie per la manifestazione dell’incidente.
- Incidenti con forte componente organizzativa: l’analisi deve esplorare le condizioni sistemiche (progettazione, supervisione, risorse) piuttosto che la sola sequenza tecnica.
L’errore frequente consiste nell’applicare i 5 perché per default, indipendentemente dal tipo di problema. La scelta dello strumento di analisi dovrebbe dipendere dalla struttura causale presunta, non dalla facilità di implementazione.
La risoluzione dei problemi guadagna in affidabilità quando il team padroneggia più metodi e sa arbitrare tra di essi a seconda del contesto. I 5 perché rimangono un primo riflesso pertinente per gli incidenti comuni a catena causale semplice, a condizione di rispettare la rigorosità della prova a ogni iterazione e di non confondere mai l’identificazione di una causa con la conferma del suo trattamento.
