Cuando todo genera una alarma, al operador le resulta cada vez más difícil reconocer lo que realmente requiere su atención.
Tiempo de lectura: 8 minutos
Introducción
En numerosos Centros de Control, las alarmas forman parte permanente del paisaje operacional.
Aparecen todos los días.
Se repiten.
Permanecen activas durante horas, días o semanas.
Algunas son reconocidas casi automáticamente.
Otras informan condiciones conocidas, estados esperados o eventos que no requieren ninguna intervención.
Con el tiempo, los operadores aprenden cuáles deben atender, cuáles pueden esperar y cuáles forman parte del ruido habitual del sistema.
Esa adaptación puede permitir que la operación continúe, pero también puede esconder un deterioro importante:
El sistema deja de orientar la atención del operador y comienza a competir por ella.
Una alarma debería comunicar una condición anormal que requiere conocimiento oportuno y una respuesta operacional definida.
Cuando no existe una acción esperada, la señal puede ser información útil, un evento para registro o una indicación de estado. Pero no necesariamente debería tratarse como alarma.
La diferencia no es semántica.
Es operacional.
¿Qué debería hacer una alarma?
Una alarma útil debería ayudar al operador a responder cinco preguntas:
- ¿Qué condición anormal ocurrió?
- ¿Por qué esa condición importa?
- ¿Qué acción debe ejecutar el operador?
- ¿Cuánto tiempo tiene para actuar?
- ¿Qué consecuencia podría ocurrir si no actúa?
Cuando estas preguntas no tienen respuestas claras, la alarma difícilmente puede orientar una decisión consistente.
Puede llamar la atención.
Puede generar un sonido.
Puede aparecer en una lista.
Pero eso no significa que esté ayudando a operar.
El principio de accionabilidad
El principio central es simple:
Una alarma debe requerir una acción operacional definida.
Esa acción no siempre implica ejecutar una maniobra.
También puede consistir en:
-
- Verificar una condición.
-
- Confirmar información en otra fuente.
-
- Contactar a personal de terreno.
-
- Informar a otra organización.
-
- Aplicar un procedimiento.
-
- Incrementar temporalmente la supervisión de una variable o condición, conforme a criterios previamente definidos.
-
- Prepararse para una posible contingencia.
-
- Registrar y comunicar una decisión cuando ello forme parte de la respuesta operacional requerida.
-
- Escalar una situación.
Lo importante es que exista una respuesta esperada, comprensible y proporcional al riesgo.
Si el operador no debe hacer nada, conviene revisar si la señal debería ser:
-
- Un evento.
-
- Una indicación de estado.
-
- Una notificación informativa.
-
- Un registro para análisis posterior.
-
- Una condición visible en una pantalla, pero sin tratamiento de alarma.
No toda información presentada al operador cumple los criterios de una alarma. ISA-18.2 distingue entre alarma, alerta y evento. Adicionalmente, una organización puede definir en su filosofía otros mecanismos de presentación o registro — por ejemplo, indicaciones de estado, mensajes informativos o registros para análisis — siempre que estén claramente diferenciados y no compitan innecesariamente por la atención del operador.
Por qué existen alarmas sin acción definida
La mayoría no fue creada con la intención de generar ruido.
Suelen acumularse gradualmente como resultado de decisiones tomadas en distintos momentos y por diferentes áreas.
Algunas causas frecuentes
Configuración por defecto
El sistema o equipo fue entregado con una gran cantidad de señales configuradas como alarmas, sin una revisión operacional suficiente.
Enfoque conservador
Ante la duda, se decide alarmar una condición con la idea de que entregar más información siempre será más seguro.
Cambios acumulativos
Se incorporan nuevas instalaciones, equipos, protecciones o automatismos, pero no se revisa el efecto total sobre el sistema de alarmas.
Falta de participación de operaciones
La señal es definida desde una perspectiva técnica sin validar qué debería hacer el operador cuando aparezca.
Ausencia de gobernanza
No existe un proceso claro para crear, modificar, priorizar, retirar o revisar alarmas.
Uso de alarmas como registro
Se utilizan alarmas para conservar evidencia de eventos que podrían registrarse mediante otros mecanismos.
Problemas conocidos que no se corrigen
Una condición repetitiva permanece activa porque su solución requiere coordinación, recursos o intervención de otra área.
El resultado es una base de alarmas que crece con el tiempo, pero rara vez disminuye.
El costo operacional de una alarma inútil
Una alarma individual puede parecer inofensiva.
El problema aparece cuando cientos o miles de señales compiten por la atención del operador.
1. Aumenta la carga cognitiva
Cada alarma debe ser observada, interpretada, reconocida o descartada.
Incluso cuando el operador sabe que no requiere acción, debe consumir parte de su atención para determinarlo.
2. Reduce la visibilidad de las alarmas importantes
Las alarmas críticas pueden aparecer mezcladas con señales repetitivas, permanentes o poco relevantes.
El riesgo no es solamente que el operador no vea una alarma.
También puede verla demasiado tarde.
3. Favorece el reconocimiento automático
Cuando muchas alarmas no aportan información útil, reconocerlas puede convertirse en una actividad rutinaria.
El operador deja de analizarlas individualmente y comienza a gestionar volumen.
4. Deteriora la confianza del operador
Si el sistema alerta constantemente sobre condiciones que no requieren respuesta, el operador aprende que la alarma no siempre significa urgencia ni acción.
Con el tiempo, se debilita la relación entre alarma y respuesta.
5. Oculta problemas persistentes
Las alarmas permanentes pueden llegar a normalizarse.
Lo que inicialmente era una desviación termina siendo percibido como parte habitual de la operación.
6. Aumenta el riesgo durante contingencias
En condiciones normales, un operador experimentado puede filtrar mentalmente el ruido.
Durante una contingencia, esa misma cantidad de información puede dificultar la identificación de:
-
- La causa inicial.
-
- Las consecuencias.
-
- La secuencia del evento.
-
- Las acciones prioritarias.
-
- El estado real del sistema.
La diferencia entre alarma, alerta, evento e indicación
No toda señal debe recibir el mismo tratamiento.
Alarma
Comunica una condición anormal que requiere conocimiento oportuno y una acción operacional definida.
Alerta o advertencia
Indica una condición que merece atención, conocimiento o seguimiento, pero que puede no requerir una intervención inmediata.
Evento
Registra que algo ocurrió o cambio de estado y permite reconstruir posteriormente una secuencia.
Indicación de estado
Muestra la condición actual de un equipo, proceso o instalación.
Información para análisis
Se conserva para estudios, mantenimiento, ingeniería, confiabilidad o análisis posterior, sin interrumpir necesariamente al operador.
Clasificar correctamente la información permite proteger la atención humana como un recurso operacional crítico.
Cinco preguntas para revisar una alarma
Antes de mantener una señal como alarma, conviene responder:
1. ¿La condición es realmente anormal?
Una condición esperada durante una maniobra, mantenimiento o modo particular de operación no siempre debería generar una alarma activa.
2. ¿El operador necesita conocerla inmediatamente?
Información útil para análisis posterior puede no requerir atención en tiempo real.
3. ¿Existe una acción concreta?
Debe ser posible describir qué se espera del operador.
Expresiones como “estar atento” o “tener conocimiento” pueden ser insuficientes si no se traducen en una respuesta observable.
4. ¿Existe tiempo para actuar?
Una señal que aparece después de que la consecuencia ya ocurrió puede ser útil para diagnóstico, pero no necesariamente como alarma de respuesta.
5. ¿La acción puede reducir el riesgo o la consecuencia?
La intervención esperada debería contribuir a controlar, mitigar, verificar o escalar la situación.
Si todas estas respuestas no están claras, la señal debería revisarse.
Ejemplo práctico
Señal
“Falla de comunicación de medidor secundario.”
Preguntas
¿Qué ocurrió?
Se perdió comunicación con un medidor utilizado para registro o respaldo.
¿Por qué importa?
Podría afectar la disponibilidad de datos para análisis posterior, pero no necesariamente la supervisión ni la operación inmediata.
¿Qué debe hacer el operador?
Si no existe ninguna acción durante el turno, la señal podría no requerir tratamiento como alarma operacional.
¿Quién debería actuar?
Podría corresponder a mantenimiento, telecomunicaciones o medición.
¿Cuánto tiempo existe para responder?
Posiblemente horas o días, dependiendo de la redundancia y del impacto.
Posible conclusión
La condición puede ser importante para la organización, pero no necesariamente debe interrumpir al operador del Centro de Control.
Podría gestionarse mediante:
-
- Aviso de mantenimiento.
-
- Orden de trabajo.
-
- Reporte de disponibilidad.
-
- Evento para seguimiento.
-
- Alerta diferida.
La relevancia técnica no convierte automáticamente una señal en alarma operacional.
Este ejemplo es ilustrativo. La decisión depende de la función del medidor, la redundancia disponible, las consecuencias de la pérdida de información, el tiempo de respuesta y la filosofía de alarmas de la organización.
Las señales más frecuentes de baja accionabilidad
Mensajes ambiguos
El texto no permite comprender qué ocurrió o qué equipo está afectado.
Alarmas duplicadas
La misma condición genera múltiples señales con mensajes diferentes.
Alarmas consecuenciales
Alarmas que aparecen como consecuencia secundaria de un mismo evento iniciador.
Alarmas permanentes
Se mantienen activas durante largos períodos sin que exista una respuesta operacional pendiente.
Alarmas recurrentes
Aparecen y desaparecen repetidamente sin generar una acción efectiva.
Alarmas informativas
Comunican estados o eventos normales que no necesitan intervención.
Prioridades infladas
Demasiadas alarmas son clasificadas como críticas o altas, reduciendo la capacidad de diferenciarlas.
Alarmas sin responsable
No está claro si la acción corresponde a operaciones, mantenimiento, ingeniería u otra área.
Alarmas sin respuesta documentada
Los operadores dependen de experiencia personal o conocimiento informal.
El papel de Operaciones
La racionalización de alarmas no debería desarrollarse únicamente desde ingeniería, automatización o proveedores tecnológicos.
Operaciones aporta información que difícilmente puede obtenerse desde la configuración del sistema:
-
- Qué hace realmente el operador.
-
- Qué alarmas utiliza.
-
- Cuáles ignora.
-
- Cuáles generan confusión.
-
- Qué señales aparecen juntas.
-
- Qué información falta.
-
- Qué respuesta resulta viable bajo presión.
-
- Qué diferencias existen entre el procedimiento y la práctica real.
La experiencia del operador es indispensable.
Sin embargo, tampoco debería ser la única fuente de decisión.
Una revisión robusta combina:
-
- Conocimiento operacional.
-
- Diseño del proceso.
-
- Riesgo y consecuencias.
-
- Automatización y control.
-
- Mantenimiento.
-
- Seguridad.
-
- Procedimientos.
-
- Datos históricos.
Racionalizar no significa eliminar indiscriminadamente
El objetivo no es reducir alarmas para alcanzar una cifra arbitraria.
Tampoco ocultar condiciones que resultan incómodas.
La racionalización debe documentar, como mínimo, los atributos requeridos por la filosofía y por ISA-18.2: tipo, prioridad, clase, setpoint o condición lógica, acción del operador y consecuencia de no actuar.
También debería considerar el tiempo máximo disponible para responder, la causa probable, el fundamento del setpoint, el método mediante el cual fue identificada y la necesidad de técnicas avanzadas.
Según las características del sistema y la filosofía de la organización, pueden agregarse otros elementos como el mensaje de alarma, responsables, relaciones con otras señales, condiciones de retorno o reglas de supresión.
Dependiendo del resultado de la revisión y de los mecanismos disponibles en la organización, una recomendación podría ser:
-
- Mantenerla.
-
- Modificarla.
-
- Cambiar su prioridad.
-
- Mejorar su texto.
-
- Agregar una respuesta operacional.
-
- Convertirla en evento.
-
- Tratarla como indicación.
-
- Eliminar una duplicidad.
-
- Corregir su lógica.
-
- Derivarla a otro flujo de gestión.
REXOS puede evaluar, facilitar y recomendar estas decisiones, pero cualquier modificación en sistemas productivos debe permanecer bajo el control, autorización y responsabilidad de la organización propietaria.
Autoevaluación rápida
Responda Sí, Parcialmente o No.
Accionabilidad
□ Cada alarma relevante tiene una acción operacional definida.
□ Los operadores conocen la respuesta esperada.
□ La acción puede ejecutarse dentro del tiempo disponible.
Claridad
□ Los mensajes permiten identificar claramente equipo y condición.
□ La nomenclatura coincide con la utilizada en procedimientos y pantallas.
□ No existen alarmas con textos ambiguos o excesivamente técnicos.
Priorización
□ Las prioridades reflejan consecuencias y urgencia.
□ Las alarmas de máxima prioridad son realmente excepcionales.
□ Dos condiciones equivalentes reciben prioridades consistentes.
Desempeño
□ Las alarmas recurrentes se revisan periódicamente.
□ Las alarmas permanentes tienen responsable y plan de tratamiento.
□ Los floods son identificados y analizados.
Gobernanza
□ Existe un proceso para crear o modificar alarmas.
□ Se incorpora a Operaciones las decisiones.
□ Los cambios quedan documentados.
La pregunta REXOS
Si una alarma aparece y ningún operador puede explicar con claridad qué debe hacer, cuánto tiempo tiene y qué consecuencia está tratando de evitar, ¿debería seguir siendo una alarma?
Responder esta pregunta para las señales más frecuentes puede revelar oportunidades de mejora importantes sin necesidad de reemplazar el sistema de control.
¿Cómo puede ayudar REXOS?
REXOS ayuda a organizaciones de infraestructura crítica a identificar dónde la gestión de alarmas está afectando la conciencia situacional, la carga operacional y la capacidad de respuesta del Centro de Control.
Nuestro enfoque es independiente, basado en evidencia y centrado en la operación.
Diagnóstico Focalizado de Gestión de Alarmas
Puede incluir:
-
- Revisión de registros disponibles.
-
- Análisis de alarmas recurrentes.
-
- Identificación de floods.
-
- Revisión de alarmas permanentes.
-
- Evaluación preliminar de accionabilidad.
-
- Revisión de prioridades.
-
- Entrevistas con operadores.
-
- Identificación de quick wins.
-
- Matriz de brechas y riesgos.
-
- Hoja de ruta priorizada.
Posibles entregables
-
- Resumen Del Desempeño del Sistema De Alarmas.
-
- Top 10 Alarmas Recurrentes.
-
- Flood Overview.
-
- Resumen de Alarmas Permanentes.
-
- Matriz de Brechas y Riesgos.
-
- Quick Wins.
-
- Hoja de Ruta.
-
- One Page Resultados.
-
- Presentación Ejecutiva de Hallazgos.
REXOS no certifica sistemas, no realiza auditorías regulatorias ni implementa cambios directamente en SCADA, DCS u otras plataformas productivas. Su función es evaluar, facilitar el análisis y entregar recomendaciones independientes para que la organización tome decisiones informadas.
Sobre REXOS
REXOS – Resiliencia y Excelencia Operacional
Ayudamos a organizaciones de infraestructura crítica a reducir el riesgo operacional, fortalecer su resiliencia y mejorar la calidad de sus decisiones.
Mensaje final
Una alarma no es útil porque aparezca en una pantalla.
Es útil cuando permite que el operador:
-
- Comprenda una condición.
-
- Evalúe su importancia.
-
- Ejecute una respuesta.
-
- Actúe dentro del tiempo disponible.
-
- Reduzca una consecuencia.
La verdadera mejora no consiste únicamente en tener menos alarmas.
Consiste en asegurar que cada alarma que permanezca tenga una razón operacional clara para existir.
Menos ruido. Más claridad. Mejores decisiones.
Autor: Robert Serrada – Director General REXOS