Zwei Jahre für die Beschreibung eines Fehlers: was Toyotas Rückruf über die Problembeschreibung zeigt
Toyota brauchte zwei Jahre, um einen Softwarefehler zu beschreiben. Die Behebung dauerte Wochen. Was das für D2 im 8D-Report bedeutet.
Im August 2026 hat Toyota in den USA 508.354 Camry Hybrid zurückgerufen. Der Fehler war zwei Jahre früher gemeldet worden.
Die Rückrufakte bei der US-Behörde erzählt die ganze Geschichte, Schritt für Schritt. Lesen Sie sie langsam.
Juli 2024: erste Feldmeldungen. Das Kombiinstrument bleibt beim Start dunkel. Im Feldtest lässt sich der Fehler nicht nachstellen.
Oktober 2025: der Verdacht fällt auf die Software. Toyota und der Lieferant bauen eigene Diagnosetechnik auf.
Ende 2025: erste Reproduktion auf dem Prüfstand. April 2026: Ein-Aus-Zyklen lösen ihn nicht aus. Juli 2026: ein Gesamtfahrzeugtest provoziert den Ausfall endlich.
Zwei Jahre bis zu dem Moment, in dem sie den Fehler auf Abruf erzeugen konnten. Dann Wochen bis zur Behebung - ein Software-Update des Kombiinstruments.
Warum wir das überhaupt wissen
Wir kennen diese Geschichte nur, weil das US-Recht sie verlangt. Nach 49 CFR 573.6 muss ein Hersteller zu jedem Rückruf eine schriftliche Chronologie seiner Untersuchung einreichen.
Die EU hat kein vergleichbares Dokument. Safety Gate veröffentlicht die Meldung und das Risiko, nicht den Weg zur Ursache. In diesem Jahr stehen dort 278 Meldungen zu Kraftfahrzeugen, 8 davon nennen Software, eine Untersuchungschronologie steht in keiner.
Als Europäer, der für alles ein Formular kennt, überrascht mich das bis heute.
Für einen Qualitätsingenieur ist diese schriftliche Chronologie ein Geschenk. Sie zeigt, wohin die zwei Jahre tatsächlich gegangen sind.
Sie haben nicht zwei Jahre lang analysiert
Jetzt der unangenehme Teil. Den größten Teil dieser zwei Jahre hat niemand die Grundursache analysiert. Man arbeitete an einer viel einfacheren Frage: Wo tritt der Fehler auf, und wo tritt er nie auf?
Schauen Sie sich jetzt ein Muster an, das ich aus der eigenen Praxis kenne.
Im 8D ist die Problembeschreibung Schritt D2. Zu oft steht sie in drei Zeilen da. Die Ursachenanalyse hat dann nichts, woran sie sich halten kann. Jede Besprechung bringt eine neue Theorie hervor, bestätigt wird keine.
Das ist keine Analyse. Das ist Raten über einer Beschreibung, die nicht trägt.
Ein gut formuliertes Problem
Charles Kettering leitete 27 Jahre lang die Forschung bei General Motors. Ihm wird der Satz zugeschrieben: “Ein gut formuliertes Problem ist ein halb gelöstes Problem.” Kepner und Tregoe haben daraus eine Methode gemacht: Zu jeder Dimension des Problems wird festgehalten, wo es IST und wo es NICHT IST.
Eine vollständige Beschreibung ist 5W2H, bis zum Ende ausgefüllt, jede Zeile mit zwei Antworten:
Was falsch ist - ein Satz, ohne Erklärung, ohne Schuldigen. Wo er auftritt und wo nie - welche Maschine ja, welche nicht; welche Schicht ja, welche nicht. Wann es angefangen hat - und was sich damals geändert hat. Wer betroffen ist - und wer nicht. Warum es scheinbar passiert - Verdacht, klar von der Tatsache getrennt. Wie es sich zeigt - und wie nicht. Wie viele - Stück, Prozent, Reklamationen.
Der Unterschied zwischen beiden Spalten ist der einzige Ort, an dem die Grundursache liegen kann.
Ein ehrlicher Test sagt Ihnen, dass die Beschreibung fertig ist: Sie können den Fehler auf Abruf erzeugen. Toyotas Behebung dauerte Wochen, nachdem dieser Test bestanden war. Bis dahin vergingen zwei Jahre.
Meine eigenen sieben Jahre
Ich habe mehr als zehn Jahre in der Fertigungsqualität gearbeitet. Ein Problem hat mich sieben davon begleitet. Wir haben es immer wieder gelöst, ohne es je zu Ende zu beschreiben.
Als wir uns endlich hingesetzt und die vollständige Beschreibung geschrieben haben, kam etwas anderes zum Vorschein. Es war nicht ein Problem. Es waren mehrere, überlappend, jedes mit eigener Ursache.
In den folgenden drei Monaten haben wir die Ursachen gefunden und für jede einzeln Maßnahmen festgelegt.
Eine meiner Lektionen: Wer ein Problem nicht zu Ende beschreiben kann, löst wahrscheinlich mehrere Probleme auf einmal.
Nicht jedes Problem verdient einen 8D
Eine Einschränkung. Alles bisher Gesagte gilt für den 8D-Report, die Methode für Kundenreklamationen und harte Probleme. Wer internen Ausschuss oder eine kleine Abweichung durch einen vollständigen 8D schickt, verbrennt eine Woche Ingenieurszeit. Dafür gibt es leichtere Methoden: 4-Step für interne Abweichungen, PDCA für kontinuierliche Verbesserung, Just-Do-It für Triviales. In SolveR laufen 8D, 4-Step und PDCA auf derselben Wissensdatenbank, die leichtere Methode kostet also nie den Nachweis.
Die richtige Methode verkürzt den Weg. Die falsche verlängert ihn.
Wohin das führt
Ich bin überzeugt, dass die Datenmenge rund um jedes Problem um Größenordnungen wachsen wird. KI-Agenten werden sie so sammeln, wie es heute Menschen tun, jeder Schritt festgehalten, die Regeln ausgesprochen. Das Rauschen wächst schneller als das Signal.
Dann wird Filtern zur Hauptarbeit: Was gehört zum Problem, was ist Rauschen, welche Deutung ist falsch, welche Daten müssen an einer größeren Stichprobe neu erhoben werden. Der letzte Schritt bleibt immer menschlich.
Die Grundursache findet nicht, wer am schnellsten analysiert. Sie findet, wer den Fehler auf Abruf erzeugen kann.
Mehr auf galileon.si
Quellen
- NHTSA, Part 573 Safety Recall Report 26V511, 06.08.2026. 508.354 Fahrzeuge, Untersuchungschronologie, Software-Abhilfe.
- 49 CFR § 573.6 - die US-Pflicht zu einer schriftlichen Untersuchungschronologie.
- EU Safety Gate, Meldungen zu Kraftfahrzeugen - geprüft am 17.08.2026. 278 Meldungen im Jahr 2026, 8 davon nennen Software, keine veröffentlichte Chronologie.
- Charles F. Kettering, zugeschrieben - “Ein gut formuliertes Problem ist ein halb gelöstes Problem”.
- Kepner, Tregoe, The Rational Manager, 1965 - die Ist/Ist-Nicht-Problemspezifikation.