Diseñar el proceso para que un error no avance inadvertido

Poka Yoke designa métodos o dispositivos que previenen un error o lo hacen evidente de inmediato. ASQ incluye ambas posibilidades en su definición de prevención de errores. [1] La diferencia importa: un mecanismo que impide colocar una pieza al revés ofrece una protección distinta de una luz que avisa y espera una respuesta humana.

El punto de partida es un modo de error específico. «Mejorar calidad» resulta demasiado amplio; «evitar que una etiqueta de la orden anterior se adhiera al siguiente producto» permite diseñar y comprobar una solución. Después se identifica cómo ese error se convierte en defecto, cuándo puede detectarse y qué debe ocurrir al detectarlo.

Para la dirección, la decisión no consiste solo en aprobar el precio del dispositivo. Debe considerar cobertura, mantenimiento, posibilidad de anulación, errores que permanecen y respuesta cuando el mecanismo falla. Ningún ejemplo genérico garantiza eficacia en cualquier instalación.

Prevención, detección y advertencia no tienen el mismo alcance

La prevención actúa sobre la posibilidad de equivocarse dentro de un alcance definido. Una geometría incompatible puede impedir cierto montaje incorrecto, aunque no detecte un material equivocado que tenga la misma forma. La detección reconoce una condición incorrecta y necesita una respuesta: detener, rechazar, corregir o solicitar autorización.

Una advertencia visual o sonora depende de que alguien la perciba, comprenda y atienda. Es útil en algunas situaciones, pero puede perder eficacia por ruido, alarmas frecuentes o presión de producción. Un bloqueo también puede fallar si se anula sin control o si verifica el dato equivocado.

Por eso conviene describir cada propuesta con cuatro elementos: error que cubre, mecanismo, respuesta y límites. No llame «a prueba de errores» a un proceso entero cuando solo se ha protegido un paso. Si todavía no se conoce el mecanismo de la falla, utilice primero una investigación como la del diagrama de Ishikawa.

Seis ejemplos ilustrativos con prueba de funcionamiento

Los siguientes diseños son originales e hipotéticos. Sirven para formular requisitos y pruebas, no como instrucciones de modificación técnica de equipos. Las intervenciones físicas o informáticas requieren validación por responsables competentes.

1. Pieza orientada al revés en un montaje

El modo de error es colocar una pieza simétrica en apariencia con orientación incorrecta. Una guía de posicionamiento con geometría diferenciada solo admite la orientación prevista. La prueba incluye piezas conformes, orientaciones incorrectas y variaciones dimensionales aceptables. El límite es el desgaste de la guía o una pieza equivocada que también encaje; ambas condiciones deben evaluarse y mantenerse.

2. Kit entregado con un componente menos

El error consiste en cerrar un kit sin una de sus piezas. Una bandeja con posiciones definidas y una comprobación de presencia antes del cierre puede detectar la omisión. Se ensayan kits completos, faltantes y componentes colocados en posiciones incorrectas. El mecanismo debe distinguir una pieza correcta de un objeto que solo ocupa el hueco; contar presencia no demuestra identidad.

3. Etiqueta perteneciente a otra orden

El error es aplicar una etiqueta válida pero correspondiente a un trabajo diferente. Un cotejo entre el identificador de la orden activa y el de la etiqueta bloquea la confirmación cuando no coinciden. La prueba utiliza orden correcta, anterior, cancelada y etiqueta ilegible. Debe comprobarse qué ocurre si el lector pierde conexión o si un usuario intenta continuar manualmente.

4. Solicitud de servicio sin información imprescindible

El error es enviar una solicitud sin el dato que permite asignar el servicio. Un formulario exige el campo, muestra ejemplos y valida su formato antes de continuar. Se prueban vacío, formato incorrecto y dato formalmente válido pero incoherente. La validación de formato no confirma veracidad; una ruta de excepción permite atender casos legítimos sin incentivar datos inventados para superar el bloqueo.

5. Pago registrado dos veces en un proceso administrativo

El error es tramitar de nuevo una obligación ya registrada. Una comprobación combina proveedor, identificador documental e importe y envía coincidencias a revisión. Se prueban duplicados exactos, diferencias de formato y documentos legítimos con importes iguales. La regla no debe rechazar automáticamente todo importe repetido: necesita criterios, autorización y trazabilidad para no bloquear operaciones válidas.

6. Archivo enviado con una versión desactualizada

El error es adjuntar una versión local antigua a una entrega. El flujo de publicación toma el documento desde un repositorio con versión aprobada y restringe la selección manual en ese paso. Se ensayan cambios de versión, permisos insuficientes y enlaces rotos. El control no garantiza que el contenido aprobado sea correcto; protege la correspondencia entre aprobación y documento enviado.

Comparación de lo que protege y no protege una guía, un cotejo digital y un campo obligatorio.
Ejemplos del artículo. Cada mecanismo necesita pruebas y límites explícitos. Ampliar gráfico ↗

Validar tanto los errores detectados como los casos correctos

Una prueba útil contiene situaciones correctas, errores previstos y condiciones límite. Documente qué debe hacer el mecanismo y qué observó el equipo. Incluya arranque, cambio de referencia, recuperación de energía o conexión y mantenimiento cuando sean relevantes. Las condiciones anormales se prueban de forma controlada, sin exponer personas ni producto comercial a riesgos innecesarios.

Evalúe dos fallas diferentes: dejar pasar un error y bloquear un caso correcto. La primera reduce protección; la segunda puede crear demoras y fomentar anulaciones. Ambas necesitan registro. No basta con comprobar que una alarma se enciende al pulsar un botón si no se verifica el modo de error real.

En un ejemplo ficticio de etiquetas se ensayan 30 casos incorrectos definidos y el sistema bloquea los 30. Esa prueba respalda el funcionamiento en esos casos; no demuestra una tasa universal de detección de 100%. Pueden existir errores no incluidos, desgaste, cambios de configuración o condiciones futuras distintas.

Defina criterios de aceptación antes de conocer resultados. Si el mecanismo deja pasar un caso que debía impedir, no se declara aprobado porque «falló solo una vez». Se investiga, modifica y repite la prueba pertinente. El riesgo determina qué evidencia y revisión técnica se necesitan.

Asignar respuesta, mantenimiento y control de excepciones

Al liberar el mecanismo, indique quién responde a la señal, qué producto o información queda retenido y cómo se autoriza continuar. Una alarma sin responsable solo añade ruido. Un bloqueo sin ruta de resolución puede llevar a soluciones improvisadas.

Defina una comprobación periódica apropiada para el mecanismo y su exposición a cambios. Un tope físico puede desgastarse; una regla digital puede dejar de corresponder con el catálogo. Conserve versiones, modificaciones y evidencia de pruebas. Las anulaciones temporales requieren alcance, motivo, autorización y control alternativo; no deben convertirse en operación habitual invisible.

Los indicadores de calidad pueden mostrar errores detectados, escapes y falsas alarmas. Interprete el aumento de detecciones con cuidado: quizá el mecanismo está haciendo visible un problema antes oculto. Complemente la cifra con oportunidades de error y consecuencias.

Cómo elegir dónde empezar

Priorice modos de error con consecuencias relevantes, recurrencia o dependencia excesiva de memoria y atención. Considere también la facilidad para detectar el problema antes de que avance. Una solución simple bien integrada puede ser más útil que una automatización compleja que nadie mantiene.

Compare costo inicial, mantenimiento, tiempo añadido y controles que podrían retirarse después de validar. No prometa ahorro eliminando inspecciones sin autorización. Integre la intervención en el programa de mejora continua y conserve el vínculo entre modo de error, mecanismo y resultado.

La decisión final debe expresar qué riesgo disminuye y cuál permanece. Esa precisión permite dirigir recursos, revisar cambios y evitar que una etiqueta de «Poka Yoke» produzca una confianza que el diseño todavía no merece.

DE LA LECTURA A LA ACCIÓN

Tu siguiente paso

Usa estos puntos para revisar el tema con tu equipo.

RESUELVE TUS DUDAS

Preguntas frecuentes

¿Una checklist es siempre un Poka Yoke?

No necesariamente. Una lista puede ayudar a recordar pasos, pero sigue dependiendo de su uso y de la atención. Describa la protección concreta que ofrece y compruebe si evita o detecta el error, en lugar de asignarle la etiqueta por su formato.

Fuentes y lecturas de referencia

  1. ASQ · What is Mistake Proofing? ↗