Il metodo dei 5 perché si basa su un principio di interrogazione iterativa attribuito a Sakichi Toyoda, fondatore della Toyota, negli anni ’30. Di fronte a un malfunzionamento, si pone la domanda “perché” in modo successivo per risalire da un sintomo visibile a una causa più profonda. Lo strumento è utilizzato nei processi lean, nella gestione della qualità e in molti contesti industriali o organizzativi.
Il numero cinque è una convenzione, non una regola di analisi
La maggior parte delle presentazioni del metodo dei 5 perché fissa il numero di iterazioni a cinque. Questa convenzione fornisce un riferimento, ma non ha nulla di scientifico. Analisi recenti raccomandano di fermarsi quando la catena raggiunge una causa supportata e controllabile, piuttosto che forzare esattamente cinque domande.
Alcuni problemi si risolvono in tre fasi. Altri ne richiedono di più. Forzare una quinta domanda quando la causa radice è già stata identificata alla terza iterazione produce spesso risposte vaghe o circolari, che non apportano nulla al piano d’azione correttivo.
Al contrario, fermarsi troppo presto perché si è raggiunta una risposta plausibile equivale a trattare un sintomo intermedio. Il criterio di arresto pertinente non è quindi un contatore, ma la natura della causa identificata: è osservabile, verificabile e, soprattutto, il team ha i mezzi per agire su di essa? Se la risposta è sì, la catena può fermarsi. Per scoprire il metodo su Nefa Blog, una guida dettagliata accompagna ogni fase di questa logica iterativa.
Problemi multifattoriali: il limite strutturale del metodo dei 5 perché
Lo strumento funziona bene quando un malfunzionamento segue una catena causale dominante e relativamente lineare. Un difetto di qualità su un pezzo, un guasto della macchina ricorrente, un ritardo nella consegna legato a un fornitore unico: in questi casi, la successione di “perché” progredisce naturalmente verso una causa radice identificabile.
I feedback sul campo divergono su questo punto non appena il problema è il risultato di più fattori combinati. Quando un incidente mescola una lacuna di formazione, una debolezza del controllo e una pressione temporale, una sola catena lineare non basta a mappare le cause.
Si presentano quindi due opzioni:
- Seguire più rami di interrogazione in parallelo, il che trasforma l’esercizio in un albero delle cause e ne complica la lettura collettiva.
- Accoppiare il metodo con un diagramma di Ishikawa o un’analisi per albero dei guasti, che strutturano meglio le interazioni tra fattori tecnici, umani e organizzativi.
- Accettare che lo strumento non è adatto al caso e passare a un metodo di analisi delle cause radice più robusto, come l’analisi Apollo o l’approccio TapRooT.
Utilizzare i 5 perché su un problema multifattoriale senza questa precauzione porta spesso a designare una causa unica dove più condizioni sono convergenti. Il piano d’azione che ne deriva tratta quindi solo una frazione del problema.
Verifica delle risposte: ciò che la catena di perché non prova
Una catena di “perché” produce un racconto causale. Questo racconto può sembrare coerente senza riflettere la realtà. Ogni risposta deve essere confrontata con dati verificabili: registrazioni, misurazioni, osservazioni dirette o interviste corroborate.
Senze questo passaggio di verifica, l’analisi rischia di trasformare un’ipotesi plausibile in una spiegazione accettata per consenso di gruppo. Il bias di conferma gioca un ruolo qui: una volta che un gruppo formula una prima risposta, le iterazioni successive tendono a confermare la direzione presa piuttosto che metterla in discussione.
La causa radice organizzativa piuttosto che l’errore individuale
Un errore comune nell’applicazione della risoluzione dei problemi tramite i 5 perché consiste nel risalire fino a un errore umano e fermarsi lì. “L’operatore non ha seguito la procedura” sembra essere una causa radice. In realtà, un’analisi solida cerca la condizione organizzativa che ha reso possibile l’errore o che non ha permesso di rilevarlo.
Procedura ambigua, assenza di doppio controllo, carico di lavoro eccessivo, difetto di progettazione di un modulo, controllo qualità inefficace: questi elementi sono cause radice su cui un’azienda può agire in modo duraturo. Designare un individuo non risolve il problema, poiché le stesse condizioni produrranno lo stesso errore con un altro operatore.
Condizioni di efficacia in azienda: team, dati e perimetro
Lo strumento trae la sua forza dalla sua apparente semplicità. Questa stessa semplicità diventa un rischio quando l’esercizio è condotto senza un quadro. Tre condizioni determinano la qualità del risultato.
La composizione del team conta tanto quanto il metodo stesso. Le persone presenti devono conoscere il processo interessato per osservazione diretta, non solo tramite organigramma. Un facilitatore che riformula ogni risposta prima di porre il “perché” successivo limita i salti logici e le risposte emotive.
Le risposte devono basarsi su fatti documentati, non su impressioni. Se il team non dispone di dati su una fase del processo, è un segnale: è necessario raccogliere questi dati prima di proseguire con l’analisi, non improvvisare una risposta.
Il perimetro del problema deve essere definito con precisione prima del primo “perché”. Un’affermazione vaga (“la qualità è diminuita”) genera catene causali divergenti e inutilizzabili. Un’affermazione precisa descrive il difetto, la sua localizzazione e la sua frequenza.
Miglioramento continuo e piano d’azione dopo l’analisi
Identificare una causa radice non produce alcun risultato se l’analisi non sfocia in un piano d’azione formalizzato. Ogni causa validata richiede un’azione correttiva con un responsabile, una scadenza e un indicatore di monitoraggio. Senza questa tracciabilità, l’esercizio rimane un laboratorio intellettuale senza impatto sul processo.
In un approccio lean o di miglioramento continuo, i 5 perché si inseriscono in un ciclo più ampio. L’analisi alimenta un PDCA (Plan-Do-Check-Act) o un rapporto 8D a seconda del contesto. Lo strumento non è una fine, ma un punto di ingresso verso soluzioni sostenibili.
I dati disponibili non consentono di concludere che il metodo sia adatto a tutti gli ambienti. Nei sistemi digitali complessi o nelle organizzazioni ad alta interdipendenza, raggiunge rapidamente i suoi limiti di scala. Riconoscerlo come uno strumento tra gli altri, adatto ai problemi con una catena causale dominante, rimane il modo migliore per trarne un reale beneficio.
