Sistemas Andon: señal, responsable y respuesta en una línea

Sistemas Andon: señal, responsable y respuesta en una línea

Un sistema Andon no es solo una torre luminosa. Es una cadena local: alguien detecta una condición, emite una señal, una persona o función la recibe y se acuerda qué respuesta corresponde. El registro debe permitir revisar después qué ocurrió. Toyota muestra una versión concreta de esa cadena en su recorrido virtual de planta: el operario pulsa un botón, se enciende el tablero Andon para avisar al líder y el trabajo no se reanuda hasta resolver el problema.

WERMA describe, por su parte, una solución comercial AndonLIGHT con una torre de señalización. Ninguna de esas fuentes establece un diseño obligatorio o un tiempo universal de respuesta. (Toyota, Production System Virtual Plant Tour; WERMA, AndonLIGHT)

La página se centra en el sistema instalado: qué señal se emite, a quién llega, qué información conserva y cómo se confirma la respuesta. No sustituye una alarma de seguridad, un sistema de emergencia, una evaluación de riesgos ni el MES. Las fuentes elegidas describen un ejemplo de producción de Toyota y un producto de proveedor; no son una norma de seguridad ni un plano para cualquier planta.

Señal no equivale a respuesta

Una luz encendida solo informa de un estado si las personas que la usan conocen su significado. Si el equipo no sabe quién recibe el aviso, si el receptor no tiene una ruta para llegar al puesto o si nadie confirma qué pasó, el color no resuelve el problema.

La palabra «Andon» puede abarcar desde una señal visual hasta un circuito de aviso más amplio; al diseñar una instalación concreta, conviene describir las partes y responsabilidades en vez de confiar en el nombre.

En el ejemplo Toyota, la fuente explica una secuencia específica: un trabajador identifica un problema, pulsa un botón, un tablero informa al líder y la producción no se reanuda hasta que el problema se resuelve. Es una descripción del recorrido de Toyota, no una instrucción de que toda línea deba detenerse de la misma manera.

El centro debe decidir qué condiciones activan su señal, qué función responde y qué autoridad decide una reanudación. (Toyota, etapa “Stopping Production When an Issue Occurs”)

WERMA presenta otra perspectiva: su AndonLIGHT como producto que permite llamar a la acción con una torre de señalización y varias posibilidades de estado. La ficha habla de hasta ocho estados en esa solución. Ese número describe el producto de WERMA; no define cuántos estados necesita una planta ni qué color corresponde a una condición particular. (WERMA, AndonLIGHT)

Por tanto, una descripción útil separa tres capas:

• Qué ocurrió: la persona que detectó una anomalía o una necesidad de ayuda.
• Qué comunica el sistema: la señal y el contexto que viajan al receptor.
• Qué decisión se tomó: valoración, actuación o escalado según el proceso local.

Una luz puede mostrar que se activó una llamada. No prueba que alguien la haya recibido, que la condición se haya resuelto o que sea seguro continuar. Esas conclusiones requieren registros y decisiones propias del centro.

Define el propósito antes de elegir la torre

Antes de comprar o configurar equipos, describe para qué se usará el sistema y qué queda fuera. Puede servir para pedir ayuda ante una incidencia de proceso, informar de una necesidad de material o mostrar el estado de una respuesta. En cambio, si se pretende proteger a personas ante un peligro, el sistema debe formar parte de la solución de seguridad que haya determinado la organización.

Una torre de producción no debe presentarse como sustituto de un sistema de alarma, parada de emergencia o aviso regulado.

La matriz siguiente es un instrumento de diseño editorial. No viene de Toyota ni de WERMA y debe validarse con las funciones responsables:

Este nivel de definición evita dos errores comunes. El primero es instalar una señal antes de decidir qué acción sigue. El segundo es adoptar la configuración que trae un proveedor como si fuera una regla de producción. El diseño puede usar una torre, una pantalla o una señal distinta, pero el propósito y las responsabilidades deberían ser comprensibles incluso cuando el dispositivo no está a la vista.

Receptores y cobertura

El sistema requiere una respuesta humana o funcional. «Avisar al líder» es claro en la descripción Toyota, pero cada centro puede tener otros roles. Antes de activar una llamada, identifica quién la recibe durante los distintos turnos, descansos o ventanas sin producción. Si un puesto cubre varias líneas, decide cómo se distingue cada ubicación para que no se responda a la llamada equivocada.

La cobertura debe tratarse como una propiedad del proceso, no como una característica automática de la torre. Una lámpara puede ser visible desde una zona y quedar tapada desde otra. Una señal sonora puede no oírse en un área ruidosa o ser inaudible para una persona que usa protección auditiva. Una notificación de software puede llegar a una cuenta que nadie revisa en ese turno.

Las pruebas de visibilidad y recepción deben hacerse en las condiciones reales del centro, con las personas que van a usarlo.

Si el receptor cambia según el tipo de solicitud, la interfaz debe ayudar a distinguirlo. Una petición de apoyo de proceso puede dirigirse a un líder local; una incidencia técnica puede requerir otro canal. Esta página no define el organigrama ni la ruta de escalado de una fábrica. La organización debe asignar cada solicitud a un responsable que tenga competencia y capacidad para decidir, y mantener un respaldo cuando ese rol no esté disponible.

El cierre también tiene dueño. El sistema puede mostrar que la señal se activó y que alguien la reconoció, pero no necesariamente que el problema se resolvió. Si la línea tiene estados de llamada, recepción, atención y cierre, cada uno debe tener un significado local claro. No uses el mismo estado para «recibido», «en curso» y «resuelto» si quienes consultan el tablero necesitan distinguirlos.

Estados legibles, no colores por costumbre

La ficha de AndonLIGHT menciona la activación de un máximo de ocho estados diferentes. Ese máximo comercial puede ser útil cuando la planta necesita diferenciar varios tipos de llamada, pero más estados no garantizan una mejor respuesta. Si el personal no recuerda su significado, la señal pierde valor. Cada estado debería tener una palabra o etiqueta de apoyo, una definición y una acción esperada. Los colores pueden acompañar esa etiqueta, no ser la única explicación.

La misma convención debe mantenerse en interfaces distintas. Si una pantalla usa «ayuda», una torre muestra un color y una aplicación usa otro nombre, el equipo puede interpretar cada canal como una situación diferente. Mantén un diccionario sencillo de estados, sus activadores y quién puede cerrarlos. Es una recomendación de diseño, no una especificación publicada por WERMA.

No presentes los colores como universales. Una organización puede tener una convención existente o necesidades de accesibilidad que cambien la combinación adecuada. El significado se debe validar con operadores, mantenimiento, seguridad y cualquier otra función responsable. La señal debe poder distinguirse en el entorno real y no depender exclusivamente de la percepción del color.

También conviene evitar estados que parezcan indicar una causa no confirmada. «Fallo de sensor» es una conclusión técnica; «solicitud de ayuda en puesto P-4» describe una llamada. Si el equipo solo conoce el segundo dato, el estado no debería etiquetarlo como avería. El diagnóstico puede añadirse después, con su propia fuente y responsabilidad.

Información que acompaña a la señal

Una llamada es más fácil de atender si localiza el punto y delimita lo que se solicita. Como propuesta local, el mensaje puede contener la línea o estación, la referencia del equipo, una categoría de ayuda y una frase breve de contexto. Si existe una orden, registro o procedimiento relacionado, incluir su identificador puede evitar que la persona entrante reconstruya el historial desde cero.

No es necesario llenar la señal con una descripción larga. Lo importante es que el receptor sepa dónde ir o qué registro consultar, y que no confunda una observación con una instrucción para intervenir. «La pieza no llega al siguiente puesto; solicitar apoyo» es una descripción de contexto. «Ajustar el sensor» sería una acción técnica que solo debería aparecer si alguien competente la ha definido y autorizado.

El texto de la llamada no debería incluir datos sensibles que no hagan falta para responder. Si el sistema conserva nombres, imágenes o información de personas, aplica las reglas internas de privacidad y acceso. El objetivo de este ejemplo es rastrear la respuesta del proceso, no vigilar a quien pidió ayuda.

Cuando hay una señal repetida, conserva cada activación o una referencia a su historial. Agrupar eventos puede facilitar el análisis, pero no borres la secuencia temporal si puede cambiar la interpretación. A la vez, el tablero no debe convertirse en un archivo de diagnóstico automático. La causa y la acción se confirman fuera de la señal, mediante el proceso que corresponda.

Flujo de respuesta propuesto

La siguiente secuencia es una forma editorial de ordenar el diseño local. No describe el software de Toyota ni impone un SLA:

1. Una persona reconoce una condición o necesita ayuda dentro de las reglas del puesto.
2. Activa la señal definida para esa situación.
3. El sistema muestra la ubicación y tipo de solicitud al receptor acordado.
4. El receptor confirma que recibió el aviso y se acerca o deriva según su función.
5. La persona competente valora qué respuesta procede y documenta si hace falta otra función.
6. La señal se cierra cuando se cumple el criterio local de cierre, no simplemente porque haya transcurrido tiempo.
7. El registro conserva la condición comunicada, quién recibió el aviso y la decisión que se tomó.

El criterio de cierre merece atención. Si solo se apaga una torre, el siguiente turno no sabe si se resolvió la anomalía, si se canceló la solicitud o si hubo un fallo de comunicación. Define qué significa «cerrado» y quién puede hacerlo. Cuando el problema queda pendiente, usa un estado diferente o enlaza la llamada con el registro abierto que continuará su seguimiento.

No asignamos minutos de respuesta en esta guía porque ninguna de las fuentes lo establece para la planta del lector. El centro puede necesitar metas internas, pero debe definir su origen, el horario al que aplican y la ruta en caso de incumplimiento. Un plazo sacado de una ficha comercial o de la descripción Toyota sería una extrapolación sin respaldo.

Ejemplo hipotético de una llamada

Imaginemos una celda que usa una señal para pedir apoyo cuando un puesto no puede continuar dentro del proceso aprobado. El operador activa la categoría «apoyo de proceso» y el mensaje identifica la celda, el puesto y lo que observa. La torre muestra la llamada y el líder la recibe. El estado cambia a «atendida» cuando el receptor confirma que conoce el aviso; eso no significa que el problema esté resuelto.

El líder revisa la situación conforme a la función que tiene asignada. Si el asunto necesita a mantenimiento, lo deriva por el canal local y enlaza la solicitud con el registro correspondiente. El tablero continúa mostrando que hay una acción pendiente hasta que la persona responsable aplique el criterio de cierre del centro. Si se determina que el puesto puede continuar, esa decisión se registra por la vía aprobada; la página no prescribe quién tiene esa autoridad.

En otro caso, la señal se activa por error o ya no hace falta. La persona con permiso de cierre registra que la solicitud se canceló y por qué. El sistema no debe convertir la cancelación en «anomalía resuelta» si nadie verificó el equipo. Las dos situaciones se parecen desde lejos porque la torre se apaga, pero dejan conclusiones distintas para el siguiente turno.

Este ejemplo no representa Toyota, WERMA ni una celda real. Sirve para mostrar la diferencia entre una alerta visual, su recepción y la resolución que queda documentada. La configuración concreta debe probarse y aprobarse en el entorno de la organización.

Pruebas y fallos de comunicación

Antes de poner en uso un sistema, comprueba que la señal llega al receptor previsto desde cada ubicación que cubre. Verifica qué ocurre cuando cambia el turno, cuando el receptor no está disponible o cuando el mensaje incluye una ubicación ambigua. Si existe una alternativa manual, comprueba que quienes la usan la conocen y que el registro conserva que se activó. Estas son preguntas de puesta en marcha propuestas, no pasos documentados por las dos fuentes.

También conviene probar fallos plausibles: un canal sin conexión, una torre apagada, una llamada duplicada o una señal que sigue encendida después de cerrar el registro. La respuesta a cada caso depende de la arquitectura local y de su función. Si el sistema Andon forma parte de un proceso de emergencia o seguridad, no basta con esta lista: se debe integrar en la evaluación y las validaciones competentes.

La revisión posterior puede comparar activaciones con respuestas, cancelaciones y llamadas pendientes. Los conteos necesitan una definición. Por ejemplo, «llamadas atendidas» debe explicar si se cuentan por señal, por incidencia o por caso; una incidencia puede generar varias activaciones. Sin esa regla, una tendencia mensual puede cambiar solo porque el sistema empezó a registrar de otro modo.

Una repetición no demuestra por sí sola que el operario, la máquina o el estándar sean la causa. Puede reflejar que más personas están usando el canal, una modificación del flujo, un tipo distinto de producto o una cobertura insuficiente. Conserva las condiciones del caso antes de comparar. Si se va a cambiar la arquitectura, valida el cambio con los usuarios y el proceso de seguridad, no solo con el recuento del tablero.

Límites de Toyota y WERMA

Toyota muestra una experiencia de su sistema de producción y describe el botón de llamada, el tablero y la respuesta del líder. Esa narración no establece una arquitectura universal, un SLA ni un mandato de detener todas las líneas ante cualquier aviso. WERMA describe una solución de proveedor y hasta ocho estados en AndonLIGHT; eso no prueba que ocho sea el número óptimo para otra planta ni que sus estados representen las convenciones de otra empresa.

Ninguna fuente define una alarma de seguridad, reemplaza un MES o asigna responsabilidades legales. Por eso, el sistema de esta página se limita a señalización y respuesta de producción. Si el lector necesita diseñar un control de riesgo, debe recurrir a las fuentes normativas y profesionales correspondientes a su instalación.

Preguntas frecuentes

¿Qué elementos forman un sistema Andon instalado?

Como propuesta local, debe definirse la señal, el receptor, la respuesta y el registro de cierre. Toyota describe esa cadena en su propio ejemplo; no es una arquitectura obligatoria para cualquier planta.

¿Andon detiene siempre la producción?

El recorrido virtual de Toyota explica que en ese ejemplo el trabajo no se reanuda hasta resolver el problema. Esa descripción no es una regla universal para todos los sistemas Andon.

¿Cuántos estados puede mostrar una torre Andon?

WERMA indica hasta ocho estados para su producto AndonLIGHT. Es una característica comercial de esa solución, no una especificación general para todas las plantas.

¿Quién debe recibir la señal?

El centro debe identificar el rol que responde y qué ocurre si no está disponible. Las fuentes ilustran una posibilidad, pero no fijan un SLA ni un organigrama universal.

¿Andon sustituye una alarma de seguridad o el MES?

No debe describirse así. Toyota presenta un ejemplo de producción y WERMA una ficha de producto; ninguna fuente convierte Andon en alarma de seguridad ni en sustituto del MES.