Cinque segnali che il vostro 8D report è chiuso ma non risolto

“Problema risolto. Caso chiuso. Firmato. Archiviato.”

Nove mesi dopo, lo stesso difetto ritorna.

Aprite l’archivio dietro quel report e gran parte di ciò che trovate sembra concluso. Pochi di quei report lo sono davvero, e i cinque segnali di un report che non funziona non stanno in reparto. Stanno nelle carte, e chi legge può trovarli tutti senza alzarsi dalla scrivania.

Perché non è facoltativo

L’8D non è una generica preferenza per il problem solving strutturato. I requisiti specifici del cliente di Ford per IATF (Customer-Specific Requirements) fissano due scadenze per uno scarto qualità del fornitore: una risposta entro 24 ore, con il contenimento attuato nella stessa finestra, e l’8D completo, con causa radice e piano di azioni correttive, consegnato entro 15 giorni di calendario.

Quelle due scadenze misurano cose diverse. Quella delle 24 ore protegge il cliente oggi. Il report a 15 giorni deve dimostrare che la causa è stata davvero trovata ed eliminata, non solo trattenuta. Un report che non ha mai separato D3 da D5 può rispettare entrambe le scadenze sul calendario e mancare comunque la seconda nella sostanza.

Le carte lo dicono già

Un 8D report serve a dimostrare due cose: che il team ha capito cosa è andato storto e che ha impedito che si ripetesse. La maggior parte dei report dimostra solo la prima, e non sempre.

Cinque verifiche separano un report che è stato chiuso da un report che ha funzionato. Leggetele in ordine, confrontandole con il vostro ultimo 8D chiuso.

Uno: il contenimento travestito da correzione

D3 è il piano di contenimento provvisorio: selezionare i pezzi, aggiungere un controllo, fermare l’emorragia. D5 verifica e sceglie la correzione permanente, quella che elimina la causa. D6 poi la implementa.

Quando D3 e D5 dicono la stessa cosa, la soluzione tampone non è mai diventata una correzione. “Formazione operatore” in D3 e “rifare la formazione agli operatori” in D5 nominano due volte la stessa azione, non due azioni diverse.

Il metodo 8D, che risale al manuale Team Oriented Problem Solving di Ford del 1987, tiene separati questi passi di proposito. Un’azione di contenimento fa guadagnare tempo. Una correzione elimina la causa che ha reso necessario il contenimento. Un report che non sa distinguere le due cose non ha mai verificato davvero se la causa sia stata eliminata.

Due: una descrizione che sta in tre righe

D2 serve a descrivere il problema in termini abbastanza precisi da poterci cercare: cosa, dove, quando, quanto. Una descrizione di meno di tre righe di solito è un sintomo ripetuto, non una descrizione.

Questo segnale merita un caso a sé, non un paragrafo. Due anni per descrivere un solo difetto lo racconta per intero: un difetto che ha richiesto due anni per essere descritto e poche settimane per essere corretto, una volta riprodotto a comando.

Tre: il campo “non è”, lasciato vuoto

Charles Kepner e Benjamin Tregoe hanno costruito un metodo attorno a una domanda che la maggior parte dei report salta: dove il difetto non compare mai. Il loro libro del 1965, The Rational Manager, struttura ogni problema allo stesso modo: indicare dove È, poi indicare dove NON È. La distanza tra le due colonne è l’unico posto in cui può trovarsi una causa radice.

Il VDA, l’associazione tedesca dell’industria automobilistica, raccomanda il metodo È / NON È di Kepner-Tregoe proprio per le fasi D2 e D4 di un 8D report, e lo considera il segno di un’analisi pronta per l’audit. Un report con il campo È compilato e il campo NON È vuoto non ha ristretto niente. Ogni teoria resta possibile.

Quattro: nessuna data di verifica, da nessuna parte

D6 serve a confermare, dopo un intervallo prestabilito, che l’azione correttiva ha davvero fermato il difetto. Un report può introdurre una correzione e non verificare mai se ha funzionato.

Un report chiuso senza data di verifica ha registrato l’intenzione di verificare. Non ha registrato la verifica.

Cinque: una causa radice, tre numeri di report

D7 serve a impedire che una causa nota si ripresenti altrove nello stabilimento. Funziona solo se qualcuno confronta i nuovi report con quelli vecchi.

Quando la stessa causa radice compare sotto tre numeri di report diversi, D7 ha fallito prima ancora di cominciare: nessuno ha messo i report uno accanto all’altro. TapRooT, una metodologia di analisi delle cause radice usata in tutta l’industria pesante, traccia qui una linea precisa. “Formazione insufficiente” è un fattore causale, il punto in cui un processo ha lasciato passare un errore, non una causa radice, il motivo per cui il processo ha permesso che quella falla esistesse. Un report che si ferma al fattore causale si chiude. La falla che ha lasciato passare l’errore resta aperta per il report successivo.

Perché i report passano e i difetti restano

James Reason, dell’Università di Manchester, pubblicò il modello del formaggio svizzero nel 1990. Ogni strato di un sistema di sicurezza ha dei buchi. Quasi sempre i buchi stanno in punti diversi su strati diversi, e non passa niente. Un guasto si verifica quando i buchi si allineano.

Un archivio 8D funziona allo stesso modo. Ogni report cattura il proprio buco. Nessuno mette i report a confronto. Il modulo è stato pensato per essere firmato, non per intercettare un difetto che torna attraverso una falla che cinque report diversi avevano già descritto, ciascuno per conto suo.

Una perdita su cui ho lavorato una volta era aperta da quindici anni. Quando finalmente abbiamo scritto cosa fosse davvero, il problema intero, ogni fase del processo che toccava, la correzione ha richiesto quattro giorni e il problema è stato risolto per sempre. Le carte non erano mai state la parte difficile. Scrivere una descrizione precisa del problema, sì.

Non tutti i problemi meritano un 8D

L’8D è fatto per i reclami cliente e per i problemi abbastanza gravi da giustificare un’indagine completa in team. Far passare una deviazione interna o uno scarto minore per tutte e otto le discipline costa una settimana di ingegneria per un problema che richiedeva un pomeriggio.

4-Step copre le deviazioni interne. PDCA copre il miglioramento continuo. Just-Do-It copre tutto ciò che è abbastanza banale da sistemare a vista. Il metodo dovrebbe accorciare la strada verso la correzione. Il metodo sbagliato la allunga soltanto.

Cosa chiude davvero un report

Un 8D firmato dimostra che le carte sono state compilate. Un difetto che non torna mai dimostra che la correzione ha funzionato. Solo una delle due affermazioni merita la parola “chiuso”.

Tirate fuori il vostro ultimo 8D chiuso. Verificate i cinque segnali, in ordine. La maggior parte dei report ne fallisce almeno uno.

Altro su galileon.si

• Due anni per descrivere un solo difetto: cosa insegna il richiamo Toyota sulla definizione del problema - il caso completo dietro il segnale due, in cui la descrizione del problema è stata l’intero costo dei due anni.
• Come funziona SolveR
• Trattamento dei dati

Fonti

• AllAboutLean, “The History of the 8D Problem Solving Process”, consultato il 1. 9. 2026 - origine dell’8D nel manuale Team Oriented Problem Solving (TOPS) di Ford del 1987.
• Ford, IATF Customer-Specific Requirements, sezione 10.2.2, consultato il 1. 9. 2026 - risposta e contenimento entro 24 ore, 15 giorni di calendario per l’8D completo con causa radice e piano di azioni correttive/preventive.
• Charles H. Kepner, Benjamin B. Tregoe, The Rational Manager, 1965 - origine della specifica del problema È / NON È.
• Kepner-Tregoe, “8D Problem Solving: VDA recommends Kepner-Tregoe IS and IS NOT”, consultato il 1. 9. 2026.
• James Reason, “Human Error: Models and Management,” Philosophical Transactions of the Royal Society of London, Series B, vol. 327, 1990, pp. 475-484 - origine del modello del formaggio svizzero.
• TapRooT, “What Is a Causal Factor?”, consultato il 1. 9. 2026.