5 Perché (5 Whys): analisi delle cause radice: template gratuito

Cos'è la tecnica dei 5 Perché?

I 5 Perché (5 Whys) sono una tecnica di analisi delle cause radice. Descrivi un problema, chiedi perché è successo e poi chiedi di nuovo perché per ogni risposta, finché non arrivi a una causa che il team può risolvere. La tecnica nasce dal Toyota Production System e l'esempio dei 5 perché dello stesso Taiichi Ohno parte da una macchina ferma e passa per un fusibile bruciato, un cuscinetto non lubrificato e un albero della pompa usurato, fino alla causa radice: la pompa non aveva un filtro. Questo modello dei 5 perché gestisce l'intera catena in un'unica retrospettiva su TeamRetro. Scrivi la descrizione del problema nella prima colonna e i fatti che conosci già nella seconda. Poi tutti rispondono al primo perché, "Perché è successo?", nella terza colonna. Il team raggruppa le risposte e vota la causa più probabile. Nella fase Discussione apri quella scheda e poni i quattro perché successivi come thread di commenti, in cui ogni risposta replica alla precedente. L'ultima risposta è la tua causa radice: copiala in un'azione con un responsabile e una scadenza. I 5 Perché funzionano meglio quando un problema segue una linea principale di causa ed effetto: un rilascio in ritardo, un incidente che si ripete, un difetto sfuggito ai test. Seguire una sola catena fino in fondo evita che il team si accontenti della prima risposta e sposta la discussione da chi ha sbagliato a cosa, nel processo, ha permesso l'errore. Quando un problema ha molte cause concomitanti, mappale prima e poi applica i 5 Perché a quelle più probabili.

Formato della retrospettiva 5 Perché

Descrizione del problema Cosa è successo esattamente, dove e quando?: Concordate un'unica descrizione del problema prima che qualcuno aggiunga una causa e limitatela a una sola scheda. Rendila specifica: cosa è successo, dove, quando e con quale impatto, senza ipotesi sulla causa. "Il rilascio 4.2 è uscito con due giorni di ritardo" dà al team qualcosa su cui chiedersi perché. "I rilasci sono un caos" no.
Cosa sappiamo Quali fatti e dati descrivono il problema?: Raccogli i fatti prima delle cause: tempistiche, metriche, log, segnalazioni dei clienti e cosa è cambiato di recente. Ogni risposta nella catena dei perché dovrebbe basarsi su qualcosa di presente qui o su qualcosa che il team può verificare. Se manca un fatto, annotalo e trasforma la sua ricerca in un'azione.
Perché è successo? Cosa ha causato direttamente il problema?: Ogni scheda qui è un primo perché, una causa diretta del problema descritto. Limita le risposte a cosa è successo, non a chi. Dopo il raggruppamento, votate la causa che più probabilmente spiega il problema. Nella fase Discussione apri la scheda più votata e poni i quattro perché successivi come thread di commenti, in cui ogni risposta replica alla precedente. Se allo stesso livello due risposte sono entrambe valide, rispondi due volte allo stesso commento e segui ciascun ramo.

Quando utilizzare questa retrospettiva

Un problema continua a ripresentarsi dopo essere stato risolto e vuoi trovare la causa che l'ultima correzione non ha colto.
Dopo un incidente, un difetto sfuggito ai test o una scadenza mancata, quando il team deve capire il perché prima di decidere cosa cambiare.
Un elemento di una retrospettiva ha ricevuto la maggior parte dei voti e merita un'analisi approfondita in una sessione dedicata.
Il problema sembra avere una linea principale di causa ed effetto. Se ha molte cause concomitanti, mappale prima con un diagramma di Ishikawa.

Domande suggerite per rompere il ghiaccio

Qual è una piccola correzione che hai fatto e che ha risolto un problema molto più grande?
Cosa hai capito solo dopo aver chiesto perché più di una volta?

Vuoi un esercizio di riscaldamento che il tuo team possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfoglia i rompighiaccio gratuiti →

Idee e consigli per la tua riunione di retrospettiva

Concordate ad alta voce la descrizione del problema prima del brainstorming e aggiungetela come unica scheda in Descrizione del problema. Il modello imposta il brainstorming su Mostra subito le idee, così tutti vedono ogni scheda appena viene aggiunta. Puoi cambiarlo nelle impostazioni della riunione.
Il modello imposta la fase Discussione su Discuti tutto, così la descrizione del problema e i fatti restano sullo schermo accanto alla causa più votata. Puoi cambiarlo nelle impostazioni della riunione.
Sviluppa la catena come thread di commenti sulla causa più votata. Quella scheda è il primo perché. Aggiungi un commento che risponda a "Perché è successo?", rispondi con la risposta successiva e continua così. Le risposte si annidano fino a tre livelli, quindi la scheda, un commento e tre risposte ti danno cinque perché.
Fermati quando arrivi a una causa che il team può cambiare, che servano tre perché o sette. Se te ne serve un sesto, aggiungi un nuovo commento sulla scheda che riprenda dall'ultima risposta.
Fai domande sul processo, non sulla persona. Se una risposta si ferma a "qualcuno ha sbagliato", chiedi perché il processo ha lasciato passare quell'errore.
Trasforma la causa radice in una contromisura. Apri il menu dell'ultima risposta, scegli Copia in azione e assegna all'azione un responsabile e una scadenza. Rivedila nella fase Azioni aperte di una retrospettiva successiva per verificare che la correzione abbia funzionato.

Domande frequenti

Cos'è la tecnica dei 5 Perché di Taiichi Ohno?

È la pratica di chiedere perché più e più volte quando si verifica un problema, per andare oltre il sintomo evidente fino alla causa radice. Fa parte del Toyota Production System, che Taiichi Ohno ha contribuito a creare, e nel suo esempio di una macchina ferma la causa radice, una pompa senza filtro, emerge al quinto perché.

Come si usano i 5 Perché?

Parti da un problema specifico, chiedi perché è successo e poi chiedi perché per ogni risposta finché non arrivi a una causa che puoi risolvere. Un esempio di 5 perché: il rilascio è arrivato in ritardo perché i test sono iniziati il giorno del rilascio, perché l'ultima funzionalità è stata unita quella mattina, perché ha aspettato tre giorni la revisione, perché solo una persona può approvare le modifiche al database, perché nessun altro è stato formato sullo schema. La soluzione è formare un secondo approvatore, non chiedere alle persone di testare più in fretta.

Quali sono le tecniche di analisi delle cause radice?

Le tecniche più comuni sono i 5 Perché, il diagramma di Ishikawa (a spina di pesce), l'analisi di Pareto, l'analisi ad albero dei guasti e l'analisi dei cambiamenti. I 5 Perché seguono una sola catena di causa ed effetto, quindi quando un problema ha diverse cause concomitanti, mappale prima con una Retrospettiva Fishbone (diagramma di Ishikawa) e poi applica i 5 Perché a quelle più probabili.

Come si scrive un'analisi delle cause radice?

Descrivi il problema con dei fatti: cosa è successo, dove, quando e con quale impatto. Risali le cause fino a una causa radice verificando ogni passaggio con delle prove, poi registra le azioni correttive con responsabili, scadenze e il modo in cui verificherai che abbiano funzionato. In questo modello il problema e i fatti sono colonne, il thread di commenti sulla causa principale è la catena dei perché e le azioni sono le azioni correttive.

Qual è il miglior modello per l'analisi delle cause radice?

Dipende dal problema. Un modello dei 5 perché è adatto a un problema con una linea principale di causa ed effetto, mentre un diagramma di Ishikawa è adatto a un problema con molte possibili cause tra persone, processi e strumenti. Entrambi funzionano meglio quando il team li compila insieme, con i fatti sotto gli occhi e un responsabile per ogni correzione.

Cos'è la tecnica dei 5 Perché?

Formato della retrospettiva 5 Perché

Descrizione del problema

Cosa sappiamo

Perché è successo?

Quando utilizzare questa retrospettiva

Domande suggerite per rompere il ghiaccio

Idee e consigli per la tua riunione di retrospettiva

Domande frequenti

Modelli correlati