Dwa lata na opisanie jednej wady: czego akcja przywoławcza Toyoty uczy o definiowaniu problemu
Toyota potrzebowała dwóch lat, by uchwycić jedną wadę oprogramowania, i tygodni, by ją usunąć. Metoda 8D: jak dobrze zdefiniować problem.
W sierpniu 2026 roku Toyota objęła akcją przywoławczą 508 354 egzemplarze modelu Camry Hybrid w USA. Wadę zgłoszono dwa lata wcześniej.
Dokumentacja akcji złożona u amerykańskiego regulatora opowiada całą historię, krok po kroku. Warto przeczytać ją powoli.
Lipiec 2024: pierwsze zgłoszenia z rynku. Zestaw wskaźników pozostaje ciemny przy uruchomieniu. Testy w terenie nie pozwalają tego odtworzyć.
Październik 2025: podejrzenie pada na oprogramowanie. Toyota i jej dostawca budują dedykowany sprzęt diagnostyczny.
Koniec 2025: pierwsze odtworzenie na stanowisku badawczym. Kwiecień 2026: testy cykli włączania i wyłączania nie wywołują usterki. Lipiec 2026: test na kompletnym pojeździe wreszcie wywołuje awarię.
Dwa lata do chwili, w której dało się wywołać wadę na żądanie. Potem tygodnie do naprawy - aktualizacja oprogramowania zestawu wskaźników.
Skąd w ogóle to wiemy
Znamy tę historię tylko dlatego, że wymaga tego prawo USA. Zgodnie z 49 CFR 573.6 producent musi przy każdej akcji przywoławczej złożyć pisemną chronologię swojego dochodzenia.
UE nie ma odpowiednika takiego dokumentu. Safety Gate publikuje ostrzeżenie i ryzyko, ale nie drogę do przyczyny. W tym roku odnotowuje 278 ostrzeżeń dotyczących pojazdów silnikowych, w 8 z nich mowa o oprogramowaniu - ale w żadnym nie ma chronologii dochodzenia.
Pochodzę z Europy, gdzie na wszystko jest formularz, i wciąż mnie to zaskakuje.
Dla inżyniera jakości taka pisemna chronologia to prezent. Pokazuje, gdzie naprawdę podziały się te dwa lata.
Przez dwa lata nie analizowano
Oto niewygodna część. Przez większość tych dwóch lat nikt nie analizował przyczyny źródłowej. Próbowano odpowiedzieć na bardziej podstawowe pytanie: gdzie wada występuje, a gdzie nie występuje nigdy?
A teraz wzorzec, który znam z własnej praktyki.
W 8D opis problemu to krok D2. Zbyt często spisuje się go w trzech linijkach. Wtedy analiza przyczyn źródłowych nie ma się czego uchwycić. Każde spotkanie przynosi nową teorię i żadna nie zostaje potwierdzona.
To nie jest analiza. To zgadywanie oparte na opisie, który się nie trzyma.
Dobrze postawiony problem
Charles Kettering przez 27 lat kierował badaniami w General Motors. Przypisuje mu się zdanie: “Dobrze postawiony problem jest w połowie rozwiązany.” Kepner i Tregoe zrobili z tego metodę: dla każdego wymiaru problemu zapisać, gdzie JEST, a gdzie NIE JEST.
Kompletny opis to 5W2H wypełnione do końca - każda linijka z dwiema odpowiedziami:
Co: co jest nie tak, w jednym zdaniu, bez wyjaśnień, bez winnego. Gdzie: gdzie występuje, a gdzie nigdy - na której maszynie tak, na której nie; na której zmianie tak, na której nie. Kiedy: kiedy się zaczęło - i co się wtedy zmieniło. Kto: kogo dotyczy - i kogo nie. Dlaczego: dlaczego wydaje się występować - podejrzenie, wyraźnie oddzielone od faktów. Jak: jak się objawia - i jak się nie objawia. Ile: sztuki, procent, reklamacje.
Różnica między tymi dwiema kolumnami to jedyne miejsce, w którym może kryć się przyczyna źródłowa.
Jeden uczciwy test mówi, że opis jest gotowy: potrafią Państwo wywołać wadę na żądanie. Po zaliczeniu tego testu naprawa Toyoty zajęła tygodnie. Zaliczenie go zajęło dwa lata.
Moje własne siedem lat
Spędziłem ponad dziesięć lat w jakości w produkcji. Jeden problem towarzyszył mi przez siedem z nich. Rozwiązywaliśmy go raz za razem, nigdy nie opisując go do końca.
Kiedy w końcu usiedliśmy i spisaliśmy pełny opis, wyszło na jaw coś innego. To nie był jeden problem. Było ich kilka, nakładały się na siebie, a każdy miał własną przyczynę.
W ciągu kolejnych trzech miesięcy znaleźliśmy przyczyny i zdefiniowaliśmy działania dla każdej z nich osobno.
Jedna z moich lekcji: jeśli nie potrafią Państwo opisać problemu do końca, prawdopodobnie rozwiązują Państwo kilka problemów naraz.
Nie każdy problem zasługuje na 8D
Jedno zastrzeżenie. Wszystko powyżej dotyczy 8D - metody dla reklamacji klientów i trudnych problemów. Przepuszczanie wewnętrznych braków albo drobnego odchylenia przez pełne 8D marnuje tydzień pracy inżynierskiej. Od tego są lżejsze metody: 4-Step dla odchyleń wewnętrznych, PDCA dla ciągłego doskonalenia, Just-Do-It dla spraw banalnych. W SolveR 8D, 4-Step i PDCA działają na tej samej bazie wiedzy, więc wybór lżejszej metody nigdy nie oznacza utraty zapisu.
Właściwa metoda skraca drogę. Niewłaściwa ją wydłuża.
Dokąd to zmierza
Jestem przekonany, że ilość danych wokół każdego problemu wzrośnie o rzędy wielkości. Agenci AI będą je zbierać tak, jak dziś robią to ludzie - każdy krok zapisany, reguły jawne. Szum będzie rósł szybciej niż sygnał.
Wtedy filtrowanie stanie się główną pracą: co należy do problemu, co jest szumem, która interpretacja jest błędna, które dane trzeba zebrać ponownie na większej próbie. Ostatni krok zawsze będzie należał do człowieka.
Przyczyny źródłowej nie znajduje ten, kto analizuje najszybciej. Znajduje ją ten, kto potrafi wywołać wadę na żądanie.
Więcej na galileon.si
Źródła
- NHTSA, Part 573 Safety Recall Report 26V511, 2026-08-06. 508 354 sztuki, chronologia dochodzenia, naprawa przez oprogramowanie.
- 49 CFR § 573.6 - amerykański wymóg pisemnej chronologii dochodzenia.
- EU Safety Gate, motor-vehicle alerts - sprawdzono 2026-08-17. 278 ostrzeżeń w 2026 roku, 8 dotyczących oprogramowania, bez opublikowanej chronologii.
- Charles F. Kettering, przypisywane - “A problem well stated is a problem half solved”.
- Kepner, Tregoe, The Rational Manager, 1965 - specyfikacja problemu JEST / NIE JEST.