Due anni per descrivere un solo difetto: cosa insegna il richiamo Toyota sulla definizione del problema
Toyota ha impiegato due anni per circoscrivere un difetto software e poche settimane per correggerlo. Cosa insegna sulla definizione del problema nel metodo 8D.
Ad agosto 2026 Toyota ha richiamato 508.354 Camry Hybrid negli Stati Uniti. Il difetto era stato segnalato due anni prima.
Il fascicolo del richiamo depositato presso l’autorità statunitense racconta tutta la storia, passo dopo passo. Leggetelo con calma.
Luglio 2024: prime segnalazioni dal campo. Il quadro strumenti resta nero all’avvio. Le prove sul campo non riescono a riprodurlo.
Ottobre 2025: i sospetti cadono sul software. Toyota e il suo fornitore costruiscono un’apparecchiatura di diagnosi dedicata.
Fine 2025: prima riproduzione su un banco prova. Aprile 2026: le prove a cicli di accensione e spegnimento non riescono a innescarlo. Luglio 2026: una prova sul veicolo completo provoca finalmente il guasto.
Due anni prima di poter riprodurre il difetto a comando. Poi settimane fino alla correzione - un aggiornamento software del quadro strumenti.
Perché lo sappiamo
Conosciamo questa storia solo perché la legge statunitense lo impone. In base al 49 CFR 573.6, il costruttore deve presentare con ogni richiamo una cronologia scritta della propria indagine.
L’UE non ha un documento equivalente. Safety Gate pubblica l’allerta e il rischio, non il percorso verso la causa. Quest’anno elenca 278 allerte sui veicoli a motore, 8 delle quali riguardano il software - ma nessuna contiene la cronologia dell’indagine.
Venendo dall’Europa, dove abbiamo un modulo per tutto, la cosa mi sorprende ancora.
Per un ingegnere qualità quella cronologia scritta è un regalo. Mostra dove sono finiti davvero i due anni.
Non hanno analizzato per due anni
Ecco la parte scomoda. Per gran parte di quei due anni nessuno analizzava la causa radice. Cercavano di rispondere a una domanda più elementare: dove compare il difetto, e dove non compare mai?
Guardate ora uno schema che conosco dalla mia esperienza.
Nell’8D la descrizione del problema è il passo D2. Troppo spesso viene scritta in tre righe. A quel punto l’analisi delle cause radice non ha niente a cui aggrapparsi. Ogni riunione produce una nuova teoria, e nessuna viene confermata.
Questa non è analisi. Sono congetture su una descrizione che non regge.
Un problema ben posto
Charles Kettering ha diretto la ricerca di General Motors per 27 anni. Gli si attribuisce la frase: “Un problema ben posto è un problema risolto a metà.” Kepner e Tregoe ne hanno fatto un metodo: per ogni dimensione del problema, registrare dove È e dove NON È.
Una descrizione completa è un 5W2H compilato fino in fondo - ogni riga con due risposte:
Cosa: cosa non va, in una frase, senza spiegazioni, senza colpevole. Dove: dove compare e dove non compare mai - su quale macchina sì, su quale no; in quale turno sì, in quale no. Quando: quando è iniziato - e cosa è cambiato in quel momento. Chi: chi è coinvolto - e chi no. Perché: perché sembra succedere - il sospetto, ben separato dai fatti. Come: come si manifesta - e come no. Quanti: pezzi, percentuale, reclami.
La differenza tra le due colonne è l’unico posto in cui può trovarsi la causa radice.
E un test onesto vi dice che la descrizione è finita: riuscite a riprodurre il difetto a comando. Una volta superato quel test, la correzione di Toyota ha richiesto settimane. Superarlo ha richiesto due anni.
I miei sette anni
Ho passato più di dieci anni nella qualità in produzione. Un problema mi ha seguito per sette di questi. Continuavamo a risolverlo senza mai descriverlo fino in fondo.
Quando finalmente ci siamo seduti a scrivere la descrizione completa, è emerso qualcos’altro. Non era un problema solo. Erano diversi, sovrapposti, ciascuno con la propria causa.
Nei tre mesi successivi abbiamo trovato le cause e definito le azioni per ciascuna, separatamente.
Una delle mie lezioni: se non riuscite a descrivere un problema fino in fondo, probabilmente state risolvendo più problemi contemporaneamente.
Non tutti i problemi meritano un 8D
Una precisazione. Tutto quanto detto sopra vale per l’8D - il metodo per i reclami cliente e i problemi difficili. Far passare uno scarto interno o una piccola deviazione da un 8D completo spreca una settimana di ingegneria. A questo servono i metodi più leggeri: 4-Step per le deviazioni interne, PDCA per il miglioramento continuo, Just-Do-It per le banalità. In SolveR, 8D, 4-Step e PDCA lavorano sulla stessa base di conoscenza, quindi scegliere il metodo più leggero non significa mai perdere la traccia.
Il metodo giusto accorcia la strada. Quello sbagliato la allunga.
Dove porta tutto questo
Sono convinto che la quantità di dati attorno a ogni problema crescerà di ordini di grandezza. Gli agenti AI li raccoglieranno come fanno oggi le persone - ogni passo annotato, regole esplicite. Il rumore crescerà più in fretta del segnale.
A quel punto filtrare diventerà il lavoro principale: cosa appartiene al problema, cosa è rumore, quale interpretazione è sbagliata, quali dati vanno raccolti di nuovo su un campione più ampio. L’ultimo passo sarà sempre umano.
La causa radice non la trova chi analizza più in fretta. La trova chi sa riprodurre il difetto a comando.
Altro su galileon.si
Fonti
- NHTSA, Part 573 Safety Recall Report 26V511, 2026-08-06. 508.354 unità, cronologia dell’indagine, rimedio software.
- 49 CFR § 573.6 - l’obbligo statunitense di una cronologia scritta dell’indagine.
- EU Safety Gate, motor-vehicle alerts - consultato il 2026-08-17. 278 allerte nel 2026, 8 relative al software, nessuna cronologia pubblicata.
- Charles F. Kettering, citazione attribuita - “A problem well stated is a problem half solved”.
- Kepner, Tregoe, The Rational Manager, 1965 - la specifica del problema È / NON È.