El taller Poka-yoke: del error al mecanismo, con su propio equipo

Durante ocho meses, un equipo de bodega envió pallets mal etiquetados a destinos equivocados. Cada vez que ocurría, el supervisor reunía al equipo, repetía la charla de "hay que prestar más atención" y todos volvían a sus puestos con buena voluntad. Tres semanas después, el error volvía a aparecer. Nadie había preguntado nunca, con calma y en detalle, en qué momento exacto del proceso nacía ese error.

Ese es el punto de partida de mi taller Poka-yoke (a prueba de errores): equipos que conocen su proceso a fondo, pero a quienes nunca se les ha guiado para separar con precisión un error de un defecto, y para diseñar un mecanismo en vez de repetir una advertencia.

Cómo se desarrolla el taller

El taller sigue un recorrido deliberado, construido para que el descubrimiento lo haga el propio equipo, no yo:

• Distinguir error de defecto. Con ejemplos reales de su propio proceso, el equipo aprende a separar la condición que antecede al problema (el error) del resultado ya visible (el defecto) — una distinción que rara vez se hace explícita en el trabajo diario.
• Ubicar el punto exacto del error. En vez de discutir el problema en abstracto, el equipo hace un ejercicio de pensamiento creativo combinado con su propia experiencia de proceso para localizar el instante preciso donde nace el error.
• Diseñar el mecanismo, con apoyo de IA. Una vez ubicada la causa, el equipo diseña posibles mecanismos Poka-yoke, y en esta etapa usamos herramientas de inteligencia artificial para explorar variantes técnicas y validar la viabilidad de cada idea.
• Construir y dejar instalado. El objetivo no es una lista de recomendaciones: es un mecanismo real, aplicado a un problema real, que el equipo deja funcionando antes de terminar la sesión.

No se trata de pedirle al equipo que trabaje con más cuidado. Se trata de que, la próxima vez que ocurra el error, no tenga ninguna forma de convertirse en defecto.

Lo que más me sorprende, sesión tras sesión, es el efecto secundario: equipos que llegan escépticos terminan entusiasmados, colaborando de una forma que no se da en una reunión normal. La productividad mejora, sí, pero también el bienestar de las personas al hacer su trabajo — dejan de cargar, mes tras mes, con el mismo problema sin solución. Se convierten, en el proceso, en solucionadores expertos de los problemas de su propio trabajo, y quedan mejor equipados para apoyarse entre ellos de ahí en adelante.

El taller está disponible tanto en modalidad online como presencial, según lo que mejor se adapte a su equipo.

Perspectiva Poka-yoke (Shigeo Shingo)

El taller sigue, de manera bastante literal, la lógica que Shingo describe en su libro: primero separar causas de efectos —error de defecto— y solo después decidir qué tipo de mecanismo corresponde. En el caso de los pallets mal etiquetados, el equipo ubicó el error exacto: la etiqueta se imprimía antes de confirmar qué pallet tenía delante. La solución que diseñaron fue simple: la impresora de etiquetas solo se activa cuando un escaneo confirma que el código del pallet coincide con el pedido correspondiente.

Este mecanismo clasifica como inspección en la fuente porque actúa sobre la causa antes de que exista un pallet mal etiquetado, no después. Es de secuencia porque depende de que un paso obligatorio (el escaneo) ocurra antes que el siguiente (la impresión). Y es de control porque, si el escaneo no coincide, la impresora simplemente no imprime — no hay manera de que el error avance sin ser detenido.

La lección de diseño: cuando un equipo tiene permiso para detenerse en la causa, en vez de apurarse a corregir el resultado, casi siempre encuentra un mecanismo más simple de lo que imaginaba.

Si quiere llevar este taller a su equipo, en modalidad online o presencial, conversemos en Contacto.