Sí que hay referencia, y llevar el número a la reunión es exactamente el movimiento correcto.
El valor que se cita habitualmente es el de la EEMUA 191: unas 150 alarmas por operador y día (en torno a seis por hora) como frontera de lo manejable en régimen normal, con el objetivo "muy probablemente aceptable" más cerca de una alarma cada diez minutos, y un límite de unas diez alarmas en los diez minutos siguientes a un disparo.
Usa esos números como termómetro, no como objetivo de diseño. Si estás en 2.000 al día el problema no es que sobren 1.850, es que nadie ha decidido nunca para qué sirve una alarma en esa planta.
Por dónde empezar, en este orden:
1. Exporta la lista y calcula la tasa por operador y día. Sin eso no hay conversación.
2. Saca los diez peores actores por número de activaciones. En casi todas las plantas un puñado de tags genera una parte enorme del total. Arreglar diez cambia el día a día más que cualquier rediseño.
3. A esos diez, aplícales banda muerta y retardo a la conexión. Solo con eso se suele cortar más de la mitad del ruido, y no cuesta más que tiempo de revisión.
4. Después, para cada alarma que quede, rellena tres columnas: consecuencia, acción del operador y tiempo para responder. Lo que quede con la columna de acción en blanco no es una alarma: es un evento, una tendencia o un aviso de mantenimiento.
Lo que sobrevive a ese filtro suele ser lo bastante pequeño como para representarlo con honestidad en la pantalla.
El detalle, con el ciclo de vida ISA-18.2 y cómo pintar la prioridad sin romper la paleta tranquila:
https://hmilibrary.com/es/learn/alarm-management.html
El valor que se cita habitualmente es el de la EEMUA 191: unas 150 alarmas por operador y día (en torno a seis por hora) como frontera de lo manejable en régimen normal, con el objetivo "muy probablemente aceptable" más cerca de una alarma cada diez minutos, y un límite de unas diez alarmas en los diez minutos siguientes a un disparo.
Usa esos números como termómetro, no como objetivo de diseño. Si estás en 2.000 al día el problema no es que sobren 1.850, es que nadie ha decidido nunca para qué sirve una alarma en esa planta.
Por dónde empezar, en este orden:
1. Exporta la lista y calcula la tasa por operador y día. Sin eso no hay conversación.
2. Saca los diez peores actores por número de activaciones. En casi todas las plantas un puñado de tags genera una parte enorme del total. Arreglar diez cambia el día a día más que cualquier rediseño.
3. A esos diez, aplícales banda muerta y retardo a la conexión. Solo con eso se suele cortar más de la mitad del ruido, y no cuesta más que tiempo de revisión.
4. Después, para cada alarma que quede, rellena tres columnas: consecuencia, acción del operador y tiempo para responder. Lo que quede con la columna de acción en blanco no es una alarma: es un evento, una tendencia o un aviso de mantenimiento.
Lo que sobrevive a ese filtro suele ser lo bastante pequeño como para representarlo con honestidad en la pantalla.
El detalle, con el ciclo de vida ISA-18.2 y cómo pintar la prioridad sin romper la paleta tranquila:
https://hmilibrary.com/es/learn/alarm-management.html