Root Cause Analysis in produzione: 5 Whys e diagramma di Ishikawa nella pratica

By Mirko Peters · 2026-11-11

Root cause analysis in produzione, passo dopo passo: quando usare i 5 Whys o un diagramma di Ishikawa (fishbone), come verificare una causa e un esempio svolto di fermo macchina con numeri.

Automatically translated with AI from the original post. Read the English original

La root cause analysis (RCA) individua la causa di fondo di un problema, in modo che la soluzione ne impedisca il ritorno. In produzione gli strumenti più usati sono i 5 Whys e il diagramma di Ishikawa. Questo articolo è pensato per i responsabili di produzione che devono risolvere oggi i problemi di linea e vogliono che restino risolti. Troverai una routine chiara, una guida alla scelta tra i due strumenti, un esempio svolto di fermo macchina con numeri e un elenco di errori comuni.

Punti chiave

• La root cause analysis individua la causa di fondo di un problema, in modo che la soluzione ne impedisca il ripresentarsi invece di trattare un sintomo.
• Usa i 5 Whys per una catena causa-effetto chiara e un diagramma di Ishikawa prima quando più cause possono interagire.
• Ogni perché deve avere una risposta basata su un fatto osservato o su un dato misurato, non su un'ipotesi, e la causa va verificata prima di agire.
• Parti dalle perdite maggiori, usando una vista Pareto, e dai priorità al collo di bottiglia, dove il tempo perso costa all'intera linea.
• Una soluzione è dimostrata solo quando il controllo mostra che il problema non è tornato, quindi eseguila come una piccola prova PDCA.

Che cos'è la root cause analysis in produzione?

iSixSigma descrive la root cause analysis come un modo per individuare la fonte di fondo di un guasto di processo o di prodotto. Consiglia di iniziare da una descrizione fattuale del problema: il prodotto o il processo guasto, le osservazioni, il numero di unità difettose e la descrizione del cliente. Vedi il suo articolo su Ishikawa diagrams and the 5 whys.

Tre termini sono facili da confondere:

• Containment protegge oggi il cliente o la linea, per esempio selezionando i pezzi sospetti. Non elimina la causa.
• Corrective action è la modifica che elimina la causa.
• Root cause è la causa che, una volta eliminata, impedisce il ripresentarsi in condizioni simili.

Se ti limiti al containment, lo stesso difetto o lo stesso fermo tornerà. Se passi direttamente all'azione correttiva senza una causa verificata, rischi di correggere la cosa sbagliata. La RCA si colloca tra le due.

Quando usare i 5 Whys?

Il glossario ASQ descrive i Five Whys come una tecnica che consiste nel chiedere ripetutamente "perché?". Di solito si esegue circa cinque volte, ma sono accettabili anche meno o più domande, e attribuisce a Sakichi Toyoda lo sviluppo del metodo. Le sue regole sono pratiche:

1. Scrivi una descrizione precisa del problema, supportata da dati.
2. Chiedi perché si è verificato il problema e registra la causa osservabile più vicina.
3. Continua a chiedere perché su ogni risposta, restando ancorato ai fatti.
4. Fermati su una causa su cui puoi intervenire per prevenire il ripresentarsi.
5. Verifica la causa di fondo: porta davvero al problema, e eliminarla impedirebbe il problema?
6. Applica una contromisura e conferma con una misurazione di follow-up che il problema non si ripresenti.

La stessa pagina precisa che ogni risposta deve essere "un fatto osservato o un dato misurato, non un'ipotesi". Aggiunge anche che il metodo funziona meglio per catene causali lineari con una sola causa di fondo, e consiglia un diagramma di Ishikawa per i problemi complessi.

Quando è meglio un diagramma di Ishikawa?

Un diagramma di Ishikawa, detto anche a lisca di pesce, è una rappresentazione grafica di ipotesi. L'effetto, come ad esempio «colpi corti sulla pressa 3», si trova in testa, e i rami mostrano le possibili cause. I team raggruppano spesso i rami in macchina, metodo, materiale, persone, misurazione e ambiente. Il diagramma aiuta il team a vedere molte cause possibili contemporaneamente e a concordare quali verificare.

iSixSigma raccomanda un modo chiaro per combinare gli strumenti: prima definisci la descrizione del problema e raccogli i dati, poi costruisci il diagramma a partire da ipotesi che descrivono effetti osservabili, applica i 5 perché ai rami più probabili e tieni traccia di ogni ipotesi con un responsabile e una scadenza. Avverte inoltre che i diagrammi realizzati con il brainstorming includono spesso cause che non contribuiscono al problema, e che categorie vaghe come «illuminazione» raramente indicano un percorso verso il guasto.

Regola pratica: se esiste una sola catena chiara, i 5 perché bastano. Se ci sono più fattori contributivi possibili, oppure un team non è d'accordo, inizia con un fishbone.

Molti problemi di produzione hanno più di una causa radice in gioco. Una breve fermata può dipendere contemporaneamente da un componente usurato, da un controllo mancante e da una lacuna nella formazione. Quando individui la causa radice, chiediti se hai trovato una delle cause radice o tutte. Definire bene il problema è metà della risposta: una descrizione circoscritta, come «fermate alla stazione 3 nel turno di notte», porta a meno cause potenziali di una descrizione generica. Per determinare la causa radice di un difetto ricorrente, confronta le produzioni buone con quelle difettose ed elenca ciò che differisce. Poi implementa le azioni correttive per ogni causa verificata, una alla volta, così da capire quale funziona. È un problem solving semplice: prima i fatti, poi le ipotesi, infine le azioni.

Come si svolge un'analisi RCA sulla linea?

1. Contieni. Proteggi per prima cosa il cliente e la linea. Metti in quarantena il prodotto sospetto e ripristina una condizione sicura.
2. Scegli il problema. Non analizzare tutto. Usa una vista di Pareto, cioè una classifica delle perdite dalla più grande alla più piccola, e concentrati sulla più grande. Guarda prima di tutto il collo di bottiglia, la fase che limita la produzione. Un minuto perso lì è perso per tutta la linea, mentre un minuto perso su una fase con capacità residua potrebbe non costare nulla.
3. Definiscilo con i dati. Cosa, dove, quando, quanto, rispetto a cosa? Dai un numero al problema.
4. Vai a vedere. Osserva il processo reale al gemba, la parola giapponese che significa «il posto reale», cioè il reparto produttivo. Parla con gli operatori che erano presenti.
5. Individua le cause candidate. Usa i 5 perché o un fishbone con un team interfunzionale: operatore, manutenzione, qualità e un supervisore.
6. Verifica. Testa la causa probabile. Se è reale, eliminandola il risultato dovrebbe cambiare, e reintroducendola il problema dovrebbe ripresentarsi.
7. Agisci e controlla. Esegui la contromisura come una piccola prova e misurane il risultato. Il ciclo PDCA dà forma a questa fase, e un report A3 può documentare l'intera storia su una sola pagina.

Esempio: fermi su una linea

Questo esempio usa numeri ipotetici.

La linea 4 lavora su due turni da 8 ore per 5 giorni, quindi 80 ore pianificate. La settimana scorsa ha perso 14 ore per fermate, cioè 14 ÷ 80 = 17,5%.

Pareto delle fermate:

• Letture errate dei sensori: 6,3 h (45%)
• Superamento del tempo di cambio formato: 4,2 h (30%)
• Attesa del materiale: 2,1 h (15%)
• Altro: 1,4 h (10%)

Le due cause più grandi rappresentano il 75% della perdita. Il team parte dalle letture errate dei sensori.

Cinque perché.

1. Perché la linea si è fermata? Il sensore ha letto in modo errato la posizione del pezzo.
2. Perché? C'era polvere sulla lente del sensore.
3. Perché c'era polvere? Nessuno pulisce la lente durante il turno.
4. Perché no? La pulizia non fa parte del lavoro standard dell'operatore.
5. Perché no? Il lavoro standard è stato scritto prima dell'installazione del sensore.

La causa radice è una lacuna nel lavoro standard, non un sensore difettoso. La contromisura è aggiungere un controllo della lente alla routine di inizio turno e installare una piccola protezione.

Effetto atteso. Se questo elimina l'80% delle fermate dovute ai sensori: 6,3 × 0,8 = 5,04 ore. Il nuovo tempo di fermo è 14 − 5,04 = 8,96 ore, cioè 8,96 ÷ 80 = 11,2%. Il controllo dopo due settimane mostrerà se il risultato reale corrisponde. Se non corrisponde, il team torna al diagramma.

Come fai a essere sicuro che la causa sia quella giusta?

Verifica il risultato prima di investire in una correzione. Due domande semplici aiutano:

• Se la causa che hai individuato fosse diversa, anche il risultato sarebbe stato diverso?
• Se la elimini, è improbabile che lo stesso guasto si ripresenti in condizioni simili?

Raccogli i dati prima e dopo. Una buona RCA si conclude con un risultato misurato e uno standard modificato, ed è così che alimenta il miglioramento continuo, invece di limitarsi a spegnere incendi. Annota anche i fattori contributivi che non hai risolto, come la formazione o gli strumenti, in modo che non vadano persi.

Attenzione all'"errore umano". Raramente è una causa radice. Se un operatore ha commesso un errore, chiediti perché il processo lo ha permesso: l'istruzione era chiara, lo strumento era adeguato, c'era tempo a sufficienza? La risposta si trova quasi sempre nel sistema.

Errori comuni

• Fermarsi al primo perché. La prima risposta è di solito il sintomo.
• Rispondere con opinioni. Ogni perché richiede un fatto osservato o una misurazione.
• Dare la colpa alle persone. La colpa chiude la discussione e nasconde la causa reale.
• Analizzare prima i problemi piccoli. Usa una vista di Pareto e inizia dalla perdita più grande.
• Saltare la verifica. Una causa non verificata porta a una soluzione che non funziona.
• Non modificare lo standard. Se lo standard di lavoro resta invariato, il problema tornerà.

Come il software può aiutare

Una buona analisi richiede buoni dati. Il software può registrare il motivo di ogni fermo nel momento in cui si verifica, generare automaticamente i grafici di Pareto e mostrare se un problema si ripresenta dopo la correzione. Questo fa risparmiare tempo nelle prime fasi della RCA e fornisce al team dei fatti invece di ricordi. Uno strumento non pensa al posto tuo: sei tu che devi andare al gemba e chiedere perché.

Prossimo passo

Prendi la perdita più grande della settimana scorsa sulla tua linea, scrivi una descrizione del problema con un numero ed esegui le 5 perché con gli operatori che erano presenti. Poi verifica la causa con una piccola prova. È questo il modo pratico di applicare l'analisi delle cause radice nella tua produzione.