La tecnica dei 5 perché: Fondamenti, Esempi e Suggerimenti

Quando ti trovi di fronte a un problema persistente o ricorrente cosa fai?

Ci sono 2 soluzioni: cercare di risolvere il problema e andare avanti oppure indagare e analizzare per vedere qual è la vera fonte del problema in modo che non riemerga. 5 Perché, è una tecnica comprovata e ampiamente utilizzata per la ‘Root Cause Analysis’ che aiuta a identificare la causa (o le cause) che contribuiscono al verificarsi del problema.

Questo articolo ti porta attraverso la storia dei 5 Whys, le sue basi ed esempi, la procedura corretta per condurre l’analisi dei 5 Whys e alcuni suggerimenti & best practices sui 5 Whys.

Storia dei 5 Whys

La tecnica dei 5 Whys fu originariamente inventata da Sakichi Toyoda, il fondatore della Toyota Industries Co. Ltd. e padre della rivoluzione industriale giapponese.

Tuttavia, il merito di aver portato le 5 Whys all’implementazione mainstream va a Taiichi Ohno, pioniere del Toyota Production System.

Secondo il sito web della Toyota:

Quando si presentava un problema, Taiichi Ohno incoraggiava il suo staff a esplorare i problemi in prima persona fino a trovare le cause principali. “Osservate il piano di produzione senza preconcetti”, consigliava.

Toyota crede nell’approccio “vai a vedere e chiarisci”. Quando si verifica un problema con una macchina di produzione, la soluzione non si trova guardando qualche dato storico o manuale. Una deduzione viene fatta comprendendo il problema, facendo domande alle persone che lavorano lì, ispezionando e poi prendendo una decisione.

La continua implementazione di pratiche come i 5 Whys ha reso Toyota il più grande produttore di automobili del mondo.

Le basi del 5 Whys

Una delle ragioni principali per cui il 5 Whys è così popolare come tecnica di analisi delle cause è la sua semplicità.

Ogni volta che si verifica un problema, basta chiedere “Perché si è verificato il problema? (almeno) 5 volte alle persone che ci lavorano. Questo è tutto. Non ci sono passi fantasiosi, nessun acronimo e non c’è bisogno di alcuna memorizzazione.

5 Whys funziona sulla premessa che “Ogni problema ha una causa dietro, ma un’analisi superficiale mostrerà solo i sintomi. È necessaria un’indagine persistente per trovare la vera causa (la causa principale) dietro il problema in modo che si possano prendere soluzioni durature e il problema non riemerga.”

Per esempio – Consideriamo che Jack sia malato con la nausea e vada dal dottore aspettandosi di ottenere dei farmaci per trattare la nausea. Tuttavia, la nausea è solo un “sintomo” del problema e trattarlo non significa trattare la vera causa della nausea. Le indagini del medico rivelano che ha anche un mal di stomaco e un’ulteriore diagnosi conferma che Jack soffre ‘effettivamente’ di un’infezione allo stomaco.

Quindi, quello che sembrava essere un problema era solo un ‘sintomo’ di un problema reale e se Jack avesse trattato solo la sua nausea senza andare dal medico, sarebbe riemerso di nuovo. (Un’altra lezione – non cercare di essere un medico quando non lo sei 😉 )

Comprensione dei 5 perché con esempi

Per usare efficacemente i 5 perché, si dovrebbe avere una “visione interrogativa” dei problemi e non prenderli al loro valore nominale.

Esempio 1: Prendiamo un esempio dal settore manifatturiero.

Dichiarazione del problema: Il nastro trasportatore della linea di produzione principale si è fermato

1. Perché il nastro trasportatore si è fermato?
La puleggia principale responsabile della rotazione del nastro non funziona

2. Perché la puleggia principale non gira?
Perché non riceve abbastanza energia dal motore

3. Perché non riceve abbastanza potenza dal motore?
Perché il motore ha smesso di funzionare

4. Perché il motore ha smesso di funzionare?
Gli avvolgimenti del motore si sono bruciati

5. Perché gli avvolgimenti si sono bruciati?
Il motore è stato caricato oltre la sua capacità di potenza

6. Perché il motore è stato sovraccaricato?
Anche se c’erano delle specifiche sulla frequenza di carico consentita ogni ora, non c’erano istruzioni sul peso massimo del carico.

Cause: Così vedete, abbiamo avuto bisogno di 6 perché per decifrare finalmente che il peso del carico sul motore era superiore alla sua capacità e ora dobbiamo sostituire il motore con uno più potente o limitare il peso massimo di carico consentito sul nastro trasportatore alla volta.

Esempio 2: Ecco un altro esempio del nostro settore Information Technology (IT).

Dichiarazione del problema: Durante il tempo di User Acceptance Testing (UAT) un problema viene osservato dal cliente

1. Perché il problema è stato riscontrato dal cliente?
Secondo il Technical Lead, il team di testing non ha riportato alcun problema di questo tipo al team di sviluppo

2. Perché il team di testing non è stato in grado di catturare il problema
Il team di testing ha eseguito solo il sanity testing e non il completo regression testing

3. Perché il team di test ha eseguito solo il sanity testing?
Perché non hanno avuto abbastanza tempo per eseguire un test funzionale completo dell’applicazione

4. Perché non c’era abbastanza tempo per un test funzionale completo?
Perché la build è arrivata solo un giorno prima delle scadenze UAT e il test funzionale completo richiede almeno 3 giorni.

5. Perché la build è stata data solo un giorno prima dell’UAT?
Perché il team di sviluppo ha impiegato più del tempo stimato per risolvere alcuni bug.

In questo esempio, vediamo che ci sono 2 cause principali piuttosto che una:

Prima causa principale: I membri del team non sono in grado di dare stime corrette intorno alle loro funzionalità e c’è bisogno di formazione sulle tecniche di stima e la loro implementazione.

Seconda causa: C’è un problema con la gestione del progetto, perché idealmente, un blocco del codice dovrebbe avvenire almeno 4 giorni prima dell’UAT, ma qui il team stava lavorando per risolvere i bug fino all’ultimo giorno.

Procedura per condurre l’analisi dei 5 Whys

Seguono i passi chiave nel processo generale di condurre un’analisi approfondita dei 5 Whys:

Step 1 – Riunire i membri del team interessati

Quando ci si trova di fronte ad un problema, il primo passo logico è quello di raccogliere i membri del team interessati. Queste sono le persone che lavorano sull’attrezzatura, sul processo o sul progetto che sta affrontando il problema e che hanno incontrato il problema in prima persona.

Nel nostro esempio di produzione di cui sopra, l’operatore del nastro trasportatore, l’ingegnere di supporto, il responsabile del turno e l’elettricista dovrebbero essere i membri rilevanti.

Similmente, nell’esempio IT di cui sopra, il business analyst, il responsabile tecnico, il responsabile dei test e gli sviluppatori che lavorano sulle correzioni dovrebbero essere i membri rilevanti.

La logica dietro la raccolta di ogni membro rilevante è quella di ottenere un punto di vista diverso del problema in questione. Ogni membro ha il suo modo di vedere il problema e ascoltare i resoconti di tutte le persone associate al problema dà una visione a 360 gradi – qualcosa di molto importante quando si cerca la causa principale.

Un “moderatore” o “facilitatore” della riunione può anche essere nominato per raccogliere e analizzare tutti i risultati nel caso di un grande team.

Step 2 – Definire il problema

Una volta che il team è disponibile, è il momento di definire il problema effettivo. La portata del problema non dovrebbe essere troppo grande o si potrebbe finire per avere un sacco di cause alla radice e non dovrebbe essere troppo stretta, perché si potrebbe finire per trattare un altro sintomo.

L’enunciato del problema dovrebbe essere equilibrato e breve, pur dando una chiara spiegazione del problema da affrontare.

Prendendo l’esempio del nastro trasportatore di cui sopra, non si dovrebbe prendere “il ritardo nella lavorazione delle merci” come dichiarazione del problema perché sarebbe troppo ampio e anche non si dovrebbe prendere “il guasto del motore” come scopo perché sarebbe troppo stretto.

Mentre si definisce il problema si può chiedere ai singoli membri di definire ciò che sentono come il problema e fare una lista delle loro risposte. Queste risposte possono poi essere discusse per raggiungere un consenso sulla dichiarazione del problema.

Fase 3 – Chiedere perché?

Questa fase richiede che tu chieda ai membri del tuo team perché la dichiarazione del problema si è verificata e annoti le loro risposte.

Poi, domanda “perché” le loro risposte si sono verificate.

Ripetutamente. Almeno altre 4 volte.

Ad ogni passo la risposta dovrebbe essere annotata e dovrebbe costituire la base del prossimo ‘Perché’. Dal momento che la tecnica dei 5 perché dipende dalla relazione ‘causa-effetto’, è imperativo assicurarsi che la risposta ad ogni ‘Perché’ sia una risposta logica che sia sostenuta da una prova.

Se vi state chiedendo perché dobbiamo ripetere il processo di chiedere Perché almeno 5 volte, ecco la risposta – Chiedere un perché una o due volte equivale a grattare appena la superficie del problema e trattare i sintomi iniziali con il problema che riaffiora prima. Cercare diligentemente di sondare la ragione dietro ogni risposta vi farà superare qualsiasi ipotesi o speculazione intorno al problema e vi indirizzerà verso il problema reale.

Il ‘moderatore’ o ‘facilitatore’ dovrebbe fare attenzione a non andare in base alle risposte emotive dei partecipanti ma concentrarsi sulle risposte che sono supportate dai fatti.

Per esempio, nell’esempio IT di cui sopra, andando solo sulla parola del leader tecnico sembrava che il team di test fosse in completa colpa per non essere in grado di trovare il bug. Tuttavia, ulteriori indagini portano alla luce il problema reale con la gestione del progetto e le abilità di stima del team.

Una volta che la causa principale effettiva è scoperta, allora dovrebbe essere discussa separatamente per trovare le azioni correttive e le contromisure per assicurare che il problema sia finalmente affrontato e non si ripeta.

Svantaggi della tecnica dei 5 perché

  • Incoraggia la risoluzione collaborativa dei problemi
  • Inculca i sentimenti di apertura all’interno del team in quanto viene considerata la prospettiva di ogni singolo membro
  • Semplice, semplice, facile da seguire senza richiedere alcuna analisi statistica o strumenti aggiuntivi
  • Aiuta a raggiungere un consenso amichevole sulle aree con problemi piuttosto che trovare colpe o incolpare individui

Limitazioni della tecnica dei 5 Whys

  • 5 Whys è una tecnica che richiede tempotecnica che richiede tempo e implica un sondaggio profondo e una valutazione approfondita di tutti i fatti
  • I 5 Whys non possono essere fatti in modo isolato e hanno bisogno della disponibilità dei membri del team associati
  • A volte non è possibile isolare una singola causa alla radice attraverso questa tecnica
  • I facilitatori dovrebbero essere abbastanza esperti da essere in grado di porre la “giusta” domanda sul perché
  • Il successo di questa tecnica dipende dai suoi partecipanti.Se le persone rilevanti non sono disponibili, il gruppo rimanente potrebbe non essere in grado di trovare la risposta corretta alla domanda sul perché.

Tecnica dei 5 Whys – Suggerimenti e Best Practices

  1. Non fare mai la root cause da solo perché indipendentemente non sarai mai in grado di raggiungere il nocciolo del problema
  2. Assicurati che ci sia un consenso dei membri del team durante la redazione della dichiarazione del problema
  3. Non fermarti solo ai 5 Whys e prova a vedere se il problema può ancora essere scomposto. Problemi più complessi potrebbero richiedere ulteriori indagini.
  4. La tecnica dovrebbe essere usata anche insieme ad altre tecniche dove i risultati dei 5 Whys possono essere convalidati da dati quantitativi
  5. È il processo che dovrebbe essere valutato e non le persone. Andate oltre gli errori delle persone e vedrete i difetti del processo (esaminate l’esempio IT sopra)

Wind-Up

5 Whys è una tecnica semplice per l’analisi delle cause alla radice che è elementare ma immensamente efficace. Se fatta con il giusto gruppo di partecipanti, porterà alla scoperta di processi e procedure difettose e aiuterà ad affrontare le cause effettive piuttosto che solo i sintomi.

Ricorda – “Le persone non falliscono, i processi sì”

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *