Poka-yoke para el conocimiento: por qué su AMFE sigue vacío
El AMFE no está vacío porque la gente sea perezosa. Está vacío porque poner por escrito lo que uno sabe le cuesta a quien lo escribe.
Hace años, un ingeniero se negó a escribir en el AMFE lo que sabía.
Explicó por qué en voz alta, en plena reunión. Ponerlo por escrito reduciría su propio valor en la empresa.
Su respuesta fue más honesta que el formulario que yo tenía en la mano.
El incentivo que nadie tiene en cuenta
En casi todas las plantas hay una persona a la que llaman cuando se para una máquina concreta. Su conocimiento no está en ningún documento. Todo el mundo lo sabe y nadie lo arregla.
La empresa le recompensa por saber lo que los demás no saben. Después le pide que lo escriba. Le está pidiendo que reduzca el motivo por el que le llaman.
Eliyahu Goldratt resumió el mecanismo en una frase: dígame cómo me mide y le diré cómo me comportaré. A ese ingeniero se le mide por lo que solo él sabe resolver. Se comporta exactamente como se le mide.
La respuesta habitual es un recordatorio, una plantilla o una formación. Las tres suponen que el problema es la atención. No lo es.
Lo que dijo realmente Shingo
Shigeo Shingo trazó una línea que la mayoría de los departamentos de calidad sigue difuminando. Separó el error del defecto. Las personas cometen errores. Un error solo se convierte en defecto cuando nada lo detiene por el camino.
Su conclusión no fue pedir a la gente que tuviera más cuidado. El cuidado no es un control. Diseñó el paso de modo que la acción equivocada no pudiera completarse: un utillaje que solo admite la pieza en una orientación, un útil de montaje que no cierra si falta una arandela.
La idea del poka-yoke es eliminar la dependencia de la atención humana justo en el momento en que es más probable que falle.
Aplique la misma idea a su AMFE. Si el documento solo se rellena cuando alguien se acuerda, se siente generoso y tiene una hora libre, el sistema depende de la atención. No hay control.
Por qué el AMFE en Excel muere dos veces
Un AMFE en una hoja de cálculo falla en dos sitios distintos, y el segundo explica por qué tantos parecen llenos de trabajo y aun así no ayudan a nadie.
Falla en la captura. Escribir en él es un acto aparte, después de terminar el trabajo real. Compite con la siguiente reclamación. No tiene un plazo que nadie haga cumplir. Por eso se rellena de forma desigual, sobre todo por quienes menos tienen que perder.
Falla en la recuperación. Incluso las filas escritas son difíciles de encontrar después. El ingeniero que las necesita seis meses más tarde no sabe que el archivo existe, no puede buscar en sus doce versiones de SharePoint y no sabe cuál era la vigente. Así que el conocimiento está escrito en teoría y perdido en la práctica.
Ese segundo fallo explica por qué “ya lo documentamos todo” y “resolvemos el mismo problema dos veces al año” son verdad a la vez en la misma planta.
Qué tiene que hacer una salvaguarda para el conocimiento
Si la atención no es el control, tienen que cumplirse cuatro condiciones. Ninguna tiene que ver con el software.
La captura tiene que ser un subproducto del trabajo. El conocimiento se registra porque el caso se cerró, no porque alguien lo pidiera después. Si hay un paso aparte, habrá excepciones, y las excepciones se convierten en la norma.
El registro tiene que llevar su fuente. Una causa sin el documento, el lote o la medición que la respaldan es una opinión con formato. El siguiente ingeniero tiene que poder comprobarla, no fiarse de ella.
La recuperación tiene que llegar en el momento de la necesidad. No a petición, no después de una búsqueda. Cuando se describe un problema similar, lo ya aprendido tiene que llegar con él.
Quien escribe no puede pagar por escribir. Esta es la condición que decide si las otras tres llegan a funcionar. Si aportar conocimiento cuesta estatus, el sistema se esquivará por bueno que sea.
Lo que esto produce
Esto es lo que construimos en Galileon. No un lugar donde guardar documentos, ni otro formulario más. Un sistema en el que cada caso cerrado alimenta al siguiente.
Lo que eso produce para el ingeniero, medido en nuestra propia muestra piloto de 10 reclamaciones de clientes con fabricantes eslovenos, de enero a marzo de 2026:
- El paso de las acciones correctivas pasa de tres días de reuniones a unos treinta segundos para una primera propuesta, porque las propuestas salen de acciones que ya funcionaron con causas confirmadas.
- El paso de descripción del problema produce unas tres veces más sugerencias útiles que una plantilla en blanco, porque parte de casos similares en lugar de una página vacía.
- Trazabilidad completa desde la reclamación del cliente hasta la acción preventiva, de modo que la pregunta de auditoría “muéstreme cómo llegó hasta aquí” tiene una respuesta que ya existe.
Lo que el ingeniero no hace: rellenar una base de conocimiento. El registro se escribe porque el caso se cerró.
Lo que sigue siendo del ingeniero
Los agentes recogerán datos como hoy los recogen las personas, y habrá muchos más que ahora. El último paso sigue perteneciendo a una persona.
El criterio que no se desplaza es el pensamiento analítico y crítico, y se manifiesta en cuatro decisiones:
- qué no pertenece a este problema
- qué es ruido y qué es señal
- dónde la interpretación es errónea
- qué datos hay que volver a recoger, con una muestra mayor
Cuantos más datos hay, más valor tiene decidir cuáles hablan realmente del problema.
La línea que vale la pena trazar
Existe una versión de todo esto en la que cada empresa se construye su propia herramienta. Programar ya es barato, así que se construyen cosas que deberían haberse rechazado, y el resultado es un producto con muchas funciones y ningún cariño detrás de ninguna de ellas.
La pregunta que conviene hacerse antes de empezar es qué parte es realmente su terreno y qué parte es mejor dejar a quienes trabajan en ello cada día, tienen muchos más datos y entregarán algo mejor que un MVP interno.
La respuesta le corresponde a usted. Vale la pena darla de forma deliberada y no por inercia.
Más en galileon.si
- 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 - lo que ocurre antes, cuando el problema nunca se describe lo bastante bien como para que el análisis se sostenga.
- Cómo funciona SolveR
- Seguridad de los datos
Referencias
- Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, Productivity Press, 1986. Página de la editorial
- Eliyahu M. Goldratt, sobre medición y comportamiento. Goldratt Consulting