Dve leti za opis ene napake: kaj Toyotin odpoklic pove o opisu problema
Toyota je dve leti iskala opis ene programske napake. Popravek je bil nato stvar tednov. Kaj to pomeni za D2 v 8D.
Avgusta 2026 je Toyota v ZDA odpoklicala 508.354 hibridnih Camryjev. Napaka je bila prijavljena dve leti prej.
Poročilo o odpoklicu pri ameriškem regulatorju pove celo zgodbo, korak za korakom. Preberite ga počasi.
Julij 2024: prve prijave s terena. Instrumentna plošča ob zagonu ostane prazna. Na terenu napake ne znajo ponoviti.
Oktober 2025: sum pade na programsko opremo. Toyota in dobavitelj postavita namensko diagnostično opremo.
Konec 2025: prva ponovitev na preizkusni mizi. April 2026: preizkus s cikli vklopa in izklopa je ne sproži. Julij 2026: preizkus na celem vozilu jo končno izzove.
Dve leti do trenutka, ko so napako znali priklicati na zahtevo. Potem tedni do popravka - posodobitev programske opreme v instrumentni plošči.
Zakaj to sploh vemo
To zgodbo poznamo samo zato, ker jo zahteva ameriška zakonodaja. Po 49 CFR 573.6 mora proizvajalec ob vsakem odpoklicu oddati pisno kronologijo svoje preiskave.
EU nima enakovrednega dokumenta. Safety Gate objavi obvestilo in tveganje, ne pa poti do vzroka. Letos je v njem 278 obvestil za motorna vozila, 8 jih imenuje programsko opremo, časovnice preiskave ni v nobenem.
Ker prihajam iz Evrope, kjer imamo obrazec za vse, me to še vedno preseneča.
Za inženirja kakovosti je ta pisna kronologija darilo. Pokaže, kam sta dve leti dejansko šli.
Dve leti niso analizirali
Zdaj neprijeten del. Večino teh dveh let temeljnega vzroka ni analiziral nihče. Odgovarjali so na bolj osnovno vprašanje: kje se napaka pojavi in kje se nikoli ne pojavi?
Poglejte zdaj vzorec, ki ga poznam iz svoje prakse.
V 8D je opis problema korak D2. Prepogosto ga napišemo v treh vrsticah. Analiza temeljnih vzrokov se potem nima na kaj opreti. Vsak sestanek rodi novo teorijo in nobene ne potrdimo.
To ni analiza. To je ugibanje nad opisom, ki ne drži.
Dobro zastavljen problem
Charles Kettering je 27 let vodil raziskave pri General Motorsu. Pripisujejo mu stavek: “Dobro zastavljen problem je napol rešen problem.” Kepner in Tregoe sta iz tega naredila metodo: za vsako razsežnost problema zapiši, kje ta JE in kje NI.
Popoln opis je 5W2H, izpolnjen do konca, vsaka vrstica z dvema odgovoroma:
Kaj je narobe - en stavek, brez razlage, brez krivca. Kje se pojavi in kje se nikoli ne - kateri stroj da, kateri ne; katera izmena da, katera ne. Kdaj se je začelo - in kaj se je takrat spremenilo. Koga zadeva - in koga ne. Zakaj se domnevno dogaja - sum, jasno ločen od dejstva. Kako se kaže - in kako se ne. Koliko - kosov, odstotkov, reklamacij.
Razlika med stolpcema je edino mesto, kjer lahko živi temeljni vzrok.
En pošten test pove, da je opis končan: napako znate priklicati na zahtevo. Toyoti je popravek vzel tedne, ko je ta test opravila. Do testa je potrebovala dve leti.
Mojih sedem let
V proizvodni kakovosti sem preživel več kot deset let. En problem me je spremljal sedem od njih. Reševali smo ga, ne da bi ga kdaj opisali do konca.
Ko smo končno sedli in napisali cel opis, se je pokazalo nekaj drugega. Ni bil en problem. Bilo jih je več, prekrivali so se, vsak s svojim vzrokom.
V naslednjih treh mesecih smo za vsakega posebej našli vzrok in določili ukrepe.
Ena mojih lekcij: če problema ne znaš opisati do konca, verjetno rešuješ več problemov hkrati.
Vsak problem ne zasluži 8D
Ena omejitev. Vse zgoraj velja za 8D, metodo za reklamacije kupcev in za trde probleme. Če skozi cel 8D pelješ interni izmet ali majhno odstopanje, zapraviš teden inženirskega časa. Za to so lažje metode: 4-Step za interna odstopanja, PDCA za nenehne izboljšave, Just-Do-It za trivialno. V SolveR 8D, 4-Step in PDCA tečejo nad isto bazo znanja, zato izbira lažje metode nikoli ne pomeni izgube zapisa.
Prava metoda pot skrajša. Napačna jo podaljša.
Kam gre to naprej
Prepričan sem, da bo količina podatkov okoli vsakega problema zrasla za red velikosti. Zbirali jih bodo agenti umetne inteligence, tako kot jih danes zbirajo ljudje, vsak korak zapisan, pravila izrecna. Šum bo rasel hitreje od signala.
Takrat postane glavno delo filtriranje: kaj sodi k problemu, kaj je šum, katera razlaga je napačna, katere podatke je treba zbrati znova na večjem vzorcu. Zadnji korak bo vedno človeški.
Temeljnega vzroka ne najde tisti, ki analizira najhitreje. Najde ga tisti, ki zna napako priklicati na zahtevo.
Več na galileon.si
Viri
- NHTSA, Part 573 Safety Recall Report 26V511, 6. 8. 2026. 508.354 vozil, kronologija preiskave, programski popravek.
- 49 CFR § 573.6 - ameriška zahteva po pisni kronologiji preiskave.
- EU Safety Gate, obvestila za motorna vozila - preverjeno 17. 8. 2026. 278 obvestil v letu 2026, 8 jih imenuje programsko opremo, kronologija ni objavljena.
- Charles F. Kettering, pripisano - “Dobro zastavljen problem je napol rešen problem”.
- Kepner, Tregoe, The Rational Manager, 1965 - specifikacija problema Je / Ni.