Las fábricas olvidan lo que ya resolvieron
El análisis de causa raíz con IA en fabricación solo compensa si el caso cerrado sigue siendo localizable. Esto es lo que lo decide.
Lo que cambia de verdad el análisis de causa raíz con IA en fabricación
El análisis de causa raíz con IA en fabricación es el uso de un modelo para ayudar a un ingeniero a pasar de un defecto a su causa y a mantener todo el caso en un solo registro. No elige la causa. Acorta las dos partes más lentas del trabajo, la descripción del problema y la búsqueda de lo que ya se ha probado, y decide si el caso terminado se puede volver a usar.
Esa última parte es la que nadie tiene en cuenta al comprar. También es la única cuyo valor se acumula.
Una flota aprende. Una planta archiva.
Hace dos semanas se autorizó la conducción autónoma supervisada en las carreteras eslovenas. Fue el sexto mercado de la Unión Europea en autorizarla.
Ese sistema no llegó ahí por cambiar de nombre, ni porque un modelo fuera más listo que el anterior. Llegó porque la flota devuelve información. Cada kilómetro recorrido se convierte en algo que la siguiente versión puede leer.
Ahora sitúese en una planta y vea cómo el mismo defecto se resuelve por tercera vez.
La ingeniería no es peor. Las personas no son peores. La diferencia está en lo que a cada lado se le permite conservar.
Un sistema de conducción escribe su experiencia en una forma que la siguiente versión puede usar. Calidad escribe su experiencia en un informe. El informe se archiva, se firma y se guarda. El siguiente ingeniero que choca con el mismo muro normalmente no sabe que existe, o no lo encuentra. El aprendizaje se queda con la persona que hizo el trabajo.
El informe se hizo para firmarse
Abra cualquier archivo de 8D y el patrón es el mismo. Los informes están completos. También son ilegibles como datos.
La definición del problema es prosa. Las evidencias están en un anexo. La acción es una frase. El nombre del archivo es un número y una fecha. Nada de eso responde a la pregunta que de verdad hace un ingeniero nuevo, que nunca es “enséñeme el informe 2024-118” sino siempre “¿ha pasado algo parecido antes en esta máquina?”.
No es un fallo de disciplina. El formulario 8D se diseñó para demostrar a un cliente que un problema se había tratado. Nunca se diseñó para que lo leyera el caso siguiente.
Este es el mismo trabajo visto dos veces.
| Un informe archivado | Un registro de caso reutilizable | |
|---|---|---|
| Escrito para | el cliente y la firma | el siguiente ingeniero |
| Definición del problema | prosa, a menudo menos de tres líneas | estructurada, con lo que el problema es y lo que no es |
| Evidencias | anexos junto al archivo | vinculadas a la causa que confirman o descartan |
| Se encuentra por | número de informe y fecha | síntoma, pieza, máquina, paso del proceso |
| Verificación | un campo de fecha, a menudo vacío | un ciclo cerrado, eficaz o no |
| Valor tras el cierre | prueba de que se trató | entrada para el caso siguiente |
La tabla es todo el argumento. Las dos describen las mismas horas de trabajo de las mismas personas. Una de ellas se puede volver a usar.
Lo que medimos
Entre enero y marzo de 2026 tratamos de esta forma diez reclamaciones de clientes con fabricantes eslovenos, medidas en ocho de ellos. En esa muestra, todo lo producido durante la resolución quedó vinculado al caso y siguió siendo localizable después: la definición del problema, las causas descartadas, las evidencias y la verificación.
Fuente: muestra piloto, 10 reclamaciones, fabricantes eslovenos, enero a marzo de 2026, medida en 8 fabricantes.
Es una muestra pequeña y lo decimos. Basta para mostrar el mecanismo, no para prometer una cifra a una planta que nunca hemos visto.
El portátil
Antes de todo esto me senté delante de un portátil que guardaba más de 20 años de trabajo de un ingeniero. Se iba de la empresa en una semana.
Cada problema resuelto y cada prueba fallida estaban en archivos que solo él sabía leer. Nombres de carpetas que tenían sentido para él. Hojas de cálculo sin fila de encabezado. Fotos con los nombres de archivo de la cámara.
Nadie más en aquel edificio habría podido abrirlos y saber qué hacer a continuación. La empresa aún no había perdido ese conocimiento. Nunca lo había tenido.
Una herramienta que lleva a una planta más rápido a la causa y deja el mismo montón de archivos detrás ha movido el problema, no lo ha resuelto.
Qué comprobar el lunes
Saque el último caso que cerró. Después haga tres comprobaciones, en este orden.
Una. Pida a alguien que no trabajó en él que lo encuentre, partiendo del síntoma y de nada más. Dele cinco minutos.
Dos. Lea la D2, la descripción del problema. Si ocupa menos de tres líneas, el caso se cerró con una conjetura que resultó acertada.
Tres. Busque la fecha de verificación. Si el campo está vacío y el informe está cerrado, el ciclo nunca se cerró.
Si el caso no supera ninguna de las tres, la próxima aparición de ese defecto costará lo mismo que la primera. Ese es todo el coste de un registro que no se puede leer.
Más en galileon.si
Referencias
- Slovenia clears Tesla’s FSD driver assistance, publicado el 7 September 2026. AOL, que reproduce a Reuters
- Tesla FSD (Supervised) approved in Slovenia, its sixth EU market, 7 September 2026. We Talk Tesla