Dos años para describir un solo defecto: lo que la llamada a revisión de Toyota enseña sobre la definición del problema
Toyota tardó dos años en acotar un defecto de software y semanas en corregirlo. Qué enseña sobre cómo definir bien el problema con la metodología 8D.
En agosto de 2026, Toyota llamó a revisión a 508.354 Camry Hybrid en Estados Unidos. El defecto se había notificado dos años antes.
El expediente de la llamada a revisión presentado ante el regulador estadounidense cuenta toda la historia, paso a paso. Léalo despacio.
Julio de 2024: primeros avisos de campo. El cuadro de instrumentos se queda en negro al arrancar. Las pruebas en campo no consiguen reproducirlo.
Octubre de 2025: las sospechas recaen en el software. Toyota y su proveedor construyen un equipo de diagnóstico específico.
Finales de 2025: primera reproducción en un banco de pruebas. Abril de 2026: las pruebas de ciclos de encendido y apagado no consiguen provocarlo. Julio de 2026: una prueba con el vehículo completo provoca por fin el fallo.
Dos años hasta poder hacer aparecer el defecto a voluntad. Después, semanas hasta la corrección - una actualización de software del cuadro de instrumentos.
Por qué lo sabemos
Conocemos esta historia solo porque la ley estadounidense lo exige. Según el 49 CFR 573.6, el fabricante debe presentar con cada llamada a revisión una cronología escrita de su investigación.
La UE no tiene un documento equivalente. Safety Gate publica la alerta y el riesgo, no el camino hasta la causa. Este año recoge 278 alertas sobre vehículos de motor, 8 de ellas relacionadas con el software - pero ninguna incluye la cronología de la investigación.
Viniendo de Europa, donde tenemos un formulario para todo, todavía me sorprende.
Para un ingeniero de calidad, esa cronología escrita es un regalo. Muestra adónde se fueron realmente los dos años.
No estuvieron dos años analizando
Aquí viene la parte incómoda. Durante la mayor parte de esos dos años, nadie analizaba la causa raíz. Intentaban responder a una pregunta más básica: ¿dónde aparece el defecto y dónde no aparece nunca?
Fíjese ahora en un patrón que conozco de mi propia práctica.
En el 8D, la descripción del problema es el paso D2. Con demasiada frecuencia se escribe en tres líneas. Entonces el análisis de causa raíz no tiene de dónde agarrarse. Cada reunión produce una teoría nueva, y ninguna se confirma.
Eso no es análisis. Son conjeturas sobre una descripción que no se sostiene.
Un problema bien planteado
Charles Kettering dirigió la investigación de General Motors durante 27 años. Se le atribuye la frase: “Un problema bien planteado está medio resuelto”. Kepner y Tregoe la convirtieron en un método: para cada dimensión del problema, anotar dónde ES y dónde NO ES.
Una descripción completa es un 5W2H rellenado hasta el final - cada línea con dos respuestas:
Qué: lo que falla, en una frase, sin explicación ni culpable. Dónde: dónde aparece y dónde no aparece nunca - en qué máquina sí y en cuál no; en qué turno sí y en cuál no. Cuándo: cuándo empezó - y qué cambió entonces. Quién: a quién afecta - y a quién no. Por qué: por qué parece ocurrir - la sospecha, bien separada de los hechos. Cómo: cómo se manifiesta - y cómo no. Cuánto: piezas, porcentaje, reclamaciones.
La diferencia entre las dos columnas es el único lugar donde puede estar la causa raíz.
Y una prueba honesta le indica que la descripción está terminada: puede reproducir el defecto a voluntad. Una vez superada esa prueba, la corrección de Toyota llevó semanas. Superarla llevó dos años.
Mis propios siete años
Pasé más de diez años en calidad de producción. Un problema me acompañó durante siete de ellos. Lo resolvíamos una y otra vez sin llegar nunca a describirlo hasta el final.
Cuando por fin nos sentamos y escribimos la descripción completa, apareció otra cosa. No era un problema. Eran varios, superpuestos, cada uno con su propia causa.
En los tres meses siguientes encontramos las causas y definimos acciones para cada una por separado.
Una de mis lecciones: si no puede describir un problema hasta el final, probablemente está resolviendo varios problemas a la vez.
No todo problema merece un 8D
Una salvedad. Todo lo anterior se aplica al 8D - el método para reclamaciones de clientes y problemas difíciles. Pasar unos desechos internos o una pequeña desviación por un 8D completo desperdicia una semana de ingeniería. Para eso están los métodos más ligeros: 4-Step para las desviaciones internas, PDCA para la mejora continua, Just-Do-It para lo trivial. En SolveR, 8D, 4-Step y PDCA funcionan sobre la misma base de conocimiento, así que elegir el método más ligero nunca significa perder el registro.
El método adecuado acorta el camino. El equivocado lo alarga.
Hacia dónde va esto
Estoy convencido de que la cantidad de datos en torno a cada problema crecerá varios órdenes de magnitud. Los agentes de IA los recogerán como hoy lo hacen las personas - cada paso anotado, reglas explícitas. El ruido crecerá más deprisa que la señal.
Entonces filtrar se convertirá en el trabajo principal: qué pertenece al problema, qué es ruido, qué interpretación es errónea, qué datos hay que volver a recoger con una muestra mayor. El último paso siempre será humano.
La causa raíz no la encuentra quien analiza más rápido. La encuentra quien sabe hacer aparecer el defecto a voluntad.
Más en galileon.si
Referencias
- NHTSA, Part 573 Safety Recall Report 26V511, 2026-08-06. 508.354 unidades, cronología de la investigación, solución por software.
- 49 CFR § 573.6 - el requisito estadounidense de una cronología escrita de la investigación.
- EU Safety Gate, motor-vehicle alerts - consultado el 2026-08-17. 278 alertas en 2026, 8 relacionadas con el software, ninguna cronología publicada.
- Charles F. Kettering, cita atribuida - “A problem well stated is a problem half solved”.
- Kepner, Tregoe, The Rational Manager, 1965 - la especificación del problema ES / NO ES.