Cómo usar alarmas como evidencia para un KPI

Una alarma de turno suele entrar en la conversación cuando el KPI ya ha llamado la atención. Alguien ve una caída de rendimiento, abre el historial y encuentra varios avisos cerca de la misma hora. El salto rápido es decir que esas alarmas explican el resultado. A veces será cierto. Muchas veces no.

Una alarma puede reflejar una condición previa, una consecuencia de la pérdida, un evento que el operador resolvió sin impacto material o un registro tardío que pertenece a otra ventana.

La forma útil de trabajar no es convertir el informe de producción en un panel de gestión de alarmas. Es dar a cada alarma un lugar comprobable dentro de la explicación del KPI: qué activo la emitió, cuándo ocurrió según cada reloj disponible, cuál era el modo de operación, qué ventana del indicador podría afectar y qué efecto se puede medir. Después hay que separar con disciplina lo que el registro demuestra de lo que el equipo aún está investigando.

Esta guía trata las alarmas como contexto para explicar un KPI de producción, disponibilidad, rendimiento o calidad. No diseña prioridades de alarma, no sustituye el análisis SCADA, no decide la clasificación técnica de una condición y no autoriza cerrar una investigación de seguridad. Si la información se usa para seguridad, liberación de producto, cumplimiento, contrato o cierre financiero, deben intervenir los procedimientos y responsables que correspondan.

Empiece por la pregunta del KPI, no por la lista de alarmas

Un histórico con miles de eventos invita a buscar patrones antes de saber qué se intenta explicar. Conviene invertir el orden. Defina primero el KPI, su ventana, la población y la decisión a la que sirve. Por ejemplo: “explicar por qué el rendimiento de L-04 entre las 14:00 y las 21:59 quedó por debajo de una base comparable”. Esa frase deja claro que la pregunta no es cuántas alarmas hubo, sino cuáles pueden ayudar a entender una variación concreta.

ISO 22400-1 describe un marco neutral respecto al sector para definir, componer, intercambiar y usar KPI en la gestión de operaciones de fabricación. La ficha de ISO 22400-1 incluye conceptos y criterios para construir KPI. No establece que una alarma local deba entrar en una fórmula ni decide la lógica de una planta. Su utilidad aquí es recordar que el indicador necesita una definición antes de elegir datos que lo acompañen.

Escriba esa definición de manera que otra persona pueda comprobarla. Incluya numerador y denominador si existen, unidad, zona horaria, instante de corte, activos, producto o familia, condiciones excluidas y versión de cálculo. “OEE del turno” no basta si parte del turno fue prueba, si el cambio de formato se excluye de forma distinta en cada informe o si el tablero mezcla dos líneas.

También declare qué decisión está en juego. Un equipo puede usar la información para priorizar una comprobación de mantenimiento, revisar una restricción de proceso o decidir si el cierre diario debe marcarse como provisional. Esas decisiones requieren evidencia de distinto peso. Un registro preliminar puede bastar para abrir una tarea; no basta por sí solo para atribuir responsabilidad, cambiar una especificación o certificar una condición de seguridad.

La pregunta bien formulada reduce el universo de alarmas. Si el KPI se limita a L-04 y a una orden, una alarma de un equipo auxiliar puede seguir siendo relevante, pero la asociación debe explicarlo. Si no existe una ruta técnica u operativa que conecte ese activo con la línea, la alarma no debería incorporarse solo porque ocurrió a la misma hora.

Distinga alarma, evento operativo, pérdida y KPI

La palabra “alarma” se usa para demasiadas cosas. Puede ser una transición binaria, un mensaje repetido, una condición activa, un reconocimiento, un estado calculado o una notificación humana. Ninguna de esas formas equivale automáticamente a una parada ni a una unidad perdida. Separar las capas evita que un informe convierta un aviso en una conclusión.

Una alarma de atasco, por ejemplo, puede activar un estado de máquina. El evento operativo podría ser “bloqueo en transportador” si una regla confirma duración, activo y modo. El efecto medible podría ser diez minutos de indisponibilidad o una reducción de velocidad durante una ventana. El KPI agrega ese efecto solo si su definición lo contempla. Saltar desde el código de alarma hasta “perdimos diez minutos” borra las comprobaciones intermedias.

La ficha pública de ISO 22400-2 presenta KPI mediante fórmula, elementos, comportamiento temporal, unidad o dimensión y otras características. Esto no resuelve una taxonomía local de alarmas. Sí obliga a preguntar qué elemento del indicador podría cambiar y cómo se mide ese cambio. La respuesta puede ser “ninguno”: una alarma puede ser importante para el equipo técnico y no tener efecto demostrable en el KPI revisado.

La distinción protege también frente a dobles conteos. Una condición activa puede emitir varias transiciones; una interfaz puede reenviar un evento después de una desconexión; un operador puede crear un comentario sobre el mismo hecho. Mantenga cada registro en su capa y use identificadores para enlazarlos. El informe debe poder decir “tres eventos proceden de la misma condición” en lugar de sumar tres pérdidas.

Construya una ventana que una tiempo, activo y contexto

La asociación empieza por el tiempo, pero la hora que aparece en pantalla no siempre es el tiempo del hecho. Un controlador puede registrar una condición a las 15:04:12, un historiador recibirla segundos después y el sistema de informes procesarla al cierre. Guarde, cuando estén disponibles, el timestamp de origen, el de recepción y el de procesamiento. Declare cuál gobierna la relación con el KPI y qué precisión tiene cada uno.

No normalice relojes a mano en una hoja sin conservar el valor recibido. Si la fuente usa UTC y el informe usa hora local, registre la conversión y la zona. Si se conoce una latencia, manténgala como dato. Cuando no se conoce, no invente segundos de precisión para decidir qué evento fue primero. Una línea temporal honesta puede mostrar dos sucesos como simultáneos o de orden incierto.

El activo importa tanto como el reloj. Una alarma debe resolver al menos a una máquina, subsistema, línea o punto de proceso que el análisis pueda reconocer. El nombre visible de una señal no siempre logra esto: “Fallo motor” puede existir en varios equipos. Use un identificador de activo estable y una relación versionada cuando la topología cambia. Si un mismo equipo sirve a dos líneas, el informe necesita una regla para saber cuál estaba afectada durante la ventana.

Después añada el contexto operativo. Orden, producto, receta, estado de producción, modo manual, limpieza, prueba, mantenimiento planificado y relevo pueden cambiar por completo el significado del mismo aviso. Una alarma durante una prueba de ingeniería no se interpreta como una pérdida comercial solo porque cae dentro del turno. Del mismo modo, una señal de equipo auxiliar puede ser relevante si coincide con una orden afectada y existe una conexión documentada.

La publicación de NIST sobre modelado de metadatos para la integración de empresas de fabricación trata el modelado de metadatos para integrar información de fabricación. No valida las asociaciones de una instalación ni dicta una ontología mínima. Para una revisión de KPI, su consecuencia práctica es más modesta: fuente, activo, tiempo, versión y contexto deben ser recuperables, porque sin ellos un evento no puede ser revisado fuera de la pantalla original.

Una ventana de asociación no tiene que ser idéntica a la del KPI. Puede requerir un periodo antes del descenso para capturar el primer síntoma y un periodo posterior para ver recuperación. La regla debe nombrar ese margen. Por ejemplo, “se revisan alarmas de activos vinculados desde quince minutos antes del inicio de la pérdida hasta cinco minutos después de la recuperación”. El margen no convierte los eventos en causa; hace explícito qué se examinó.

Relacione la alarma con un efecto que se pueda medir

El paso central consiste en buscar un efecto observacional, no una explicación elegante. Pregunte qué medida debería cambiar si la alarma tuvo impacto: estado de máquina, contador de ciclos, velocidad real, unidades buenas, scrap, consumo o duración de una parada. Elija una medida que pertenezca a la definición del KPI o que pueda conectarse con ella sin una cadena de supuestos opaca.

Un método sencillo usa cuatro preguntas:

1. ¿La alarma fue registrada antes o durante la variación, según los tiempos conservados?
2. ¿El activo o el flujo al que pertenece puede afectar al KPI definido?
3. ¿Hay un efecto medible en la misma ventana, con una fuente independiente o una regla declarada?
4. ¿Existe una explicación alternativa que los mismos datos no descarten?

La primera pregunta puede descartar una narrativa imposible. Una alarma que aparece después de la recuperación no explica el inicio de una pérdida, aunque puede describir un efecto posterior. La segunda evita que la cercanía temporal suplante la relación de proceso. La tercera obliga a buscar producción, estados o calidad, no solo mensajes. La cuarta mantiene el análisis abierto cuando material, receta, datos tardíos o cambios de modo ofrecen una hipótesis igualmente plausible.

Un ejemplo hipotético ayuda a ver el límite. A las 16:10 aparece una alarma de acumulación en el equipo receptor. Entre 16:11 y 16:19 la velocidad de la línea cae por debajo de su referencia documentada y no se observan unidades confirmadas durante parte de ese intervalo.

La asociación puede registrarse como “alarma contextual coincidente con reducción de velocidad” si los activos y relojes son coherentes. No debería registrarse como “causa raíz confirmada” sin una comprobación técnica que conecte el mecanismo, por ejemplo una inspección o una prueba posterior.

La investigación de NIST sobre una jerarquía de KPI propone organizar mediciones directas, indicadores básicos y KPI de nivel superior. Una relación entre niveles puede orientar la investigación, pero no convierte automáticamente una correlación en causalidad. Este límite importa con las alarmas: un evento local puede ayudar a leer una medición directa sin explicar, por sí mismo, el resultado agregado.

Cuando el efecto no se puede medir, la salida correcta no es forzar una cifra. Registre la alarma como contexto no cuantificado y declare qué dato falta. Puede ser una resolución insuficiente de estados, una fuente caída, una regla de parada ausente o una diferencia de reloj. Así el siguiente equipo sabe qué mejorar sin heredar una causa inventada.

Declare la regla de asociación y sus exclusiones

El informe debe permitir repetir la asociación. Para cada vínculo material entre alarma y KPI, conserve el identificador de alarma, los activos incluidos, la ventana, el criterio de coincidencia, las fuentes de efecto, la versión de la lógica y el resultado. Si se hizo una corrección manual, conserve autoría, motivo, valor anterior y permiso aplicable. La explicación no tiene que mostrar todos esos campos a dirección, pero debe poder recuperarlos.

Una regla podría decir: “asociar alarmas de los activos L04-* activas durante la ventana de pérdida de velocidad calculada con la versión 7 del KPI; deduplicar transiciones del mismo código en 30 segundos; excluir modo prueba, simulación y mantenimiento planificado cuando el estado esté confirmado”. Esa frase es revisable. “Tomamos las alarmas importantes” no lo es.

Las exclusiones merecen la misma atención que las inclusiones. Puede excluir una señal porque es de prueba, porque está fuera del activo, porque carece de timestamp de origen o porque el evento ya está representado por una condición raíz. Debe contar cuántos eventos se excluyeron y por qué. Una exclusión silenciosa puede cambiar tanto el relato como un dato añadido.

Tampoco conviene fijar un umbral universal de duración. Una alarma de dos segundos puede ser irrelevante en una línea y crítica en otra; la respuesta depende de la dinámica del proceso y del KPI. Declare el umbral local, la evidencia que lo sustenta y los casos en los que no aplica. Si no existe una base defendible, use la alarma para abrir revisión, no para imputar una pérdida calculada.

La guía de NIST para seguridad de tecnología operacional aborda sistemas de tecnología operacional desde una perspectiva de ciberseguridad. No es una norma de cálculo de OEE ni una política de alarmas de proceso. Aun así, recuerda una frontera necesaria: al extraer registros para un informe, proteja el acceso, la integridad y la trazabilidad de las fuentes. Un proceso de análisis que altera o expone información de operación puede crear un riesgo distinto del que pretendía investigar.

Presente niveles de certeza en lugar de una causa única

Una narrativa útil diferencia cuatro estados. El primero es el hecho registrado: “la alarma A estuvo activa entre los tiempos conservados”. El segundo es la asociación observada: “en la misma ventana, la velocidad medida fue inferior a la referencia”. El tercero es la hipótesis: “un bloqueo aguas abajo pudo contribuir a la reducción”. El cuarto es la causa confirmada, que exige un criterio de verificación definido antes de cerrar el caso.

No use la palabra “causa” cuando solo existe coincidencia. Tampoco rebaje un evento confirmado a mera opinión. El detalle en el lenguaje importa porque la decisión posterior puede cambiar: una hipótesis necesita prueba; una asociación repetida puede justificar seguimiento; una causa confirmada puede alimentar una acción correctiva bajo el proceso competente.

Una tabla corta ayuda a mantener esas fronteras durante el cierre:

Una causa no queda confirmada porque una intervención coincida con la recuperación. El proceso puede recuperarse por cambio de orden, fin de una restricción o retorno de un modo. Defina de antemano qué observación distinguiría alternativas. Por ejemplo, repetir una condición comparable después del ajuste, revisar la pieza sustituida o contrastar el patrón en ciclos sin la alarma.

Esta prudencia también protege a las personas. Una caída ocurrida en un turno no demuestra una acción individual. El nombre del relevo sirve para ubicar la ventana y recuperar contexto, no para atribuir conducta. Antes de hablar de desempeño humano, revise producto, material, secuencia, estado del equipo, decisiones heredadas y cobertura del dato. No use un KPI de línea para crear rankings personales sin un propósito, datos y controles explícitos.

Prepare un resumen que sirva para decidir

Dirección no necesita una descarga completa de alarmas. Necesita saber qué ocurrió, qué parte del KPI está afectada, cuánta confianza merece la explicación y qué se hará después. Un resumen puede seguir cinco bloques: definición del KPI, ventana y activos, hechos relevantes, efecto medido, limitaciones y siguiente comprobación.

Un ejemplo de redacción responsable sería: “Durante la ventana definida para la orden X, el rendimiento fue inferior a la base comparable. El historial muestra una alarma de bloqueo del activo Y y una reducción de velocidad en una ventana coincidente. La asociación es consistente con una posible restricción aguas abajo, pero no confirma el mecanismo. Falta validar la sincronización de la fuente y revisar la condición física del equipo antes del siguiente cierre.”

El ejemplo evita porcentajes porque una guía general no debe inventar valores de una planta.

Incluya también qué no puede afirmarse. Si la alarma llegó sin tiempo de origen, si dos activos comparten identificador o si faltan estados de máquina, dígalo. Una cifra provisional puede seguir siendo útil para priorizar una revisión, siempre que no se presente como cierre definitivo. Ocultar incertidumbre para lograr una explicación limpia suele reaparecer como discusión en el siguiente informe.

Para preparar la síntesis del cierre, consulte cómo preparar un informe de producción para dirección. Si el problema es que el KPI carece de contexto de parada, continúe con cómo revisar un KPI sin contexto de parada. Ambas páginas parten de evidencia operacional; ninguna sustituye la investigación técnica del sistema de alarmas.

Lista de comprobación antes de publicar la explicación

Antes de presentar una alarma como evidencia de un KPI, revise estas preguntas:

• ¿El KPI tiene fórmula, ventana, zona horaria y versión identificadas?
• ¿La alarma conserva fuente, activo, tiempo de origen y estado original?
• ¿La relación entre activo y proceso es explícita para esa orden o modo?
• ¿Se han conservado los tiempos de recepción y procesamiento cuando alteran la secuencia?
• ¿La alarma se vincula a un efecto medible, no solo a una historia plausible?
• ¿La regla de asociación declara deduplicación, umbrales, exclusiones y versión?
• ¿Las hipótesis alternativas siguen visibles cuando la evidencia no las descarta?
• ¿Las limitaciones están escritas y la siguiente comprobación tiene responsable?

La lista no pretende elevar la burocracia del turno. Evita que el equipo tenga que reconstruir meses después por qué una alarma entró en un informe. Empiece con un conjunto pequeño de activos y un KPI que ya se revisa. Cuando la relación sea recuperable y útil, amplíe con cuidado. Más eventos no producen una explicación mejor si faltan tiempo, contexto y un efecto observable.

Preguntas frecuentes

¿Una alarma demuestra por qué cayó un KPI?

No. Demuestra que una condición fue detectada o registrada dentro del alcance de ese sistema. Para explicar un KPI hay que comprobar la secuencia, el activo afectado, la ventana, el efecto medible y un mecanismo verificable. La alarma puede ser evidencia a favor de una hipótesis o una señal sin relación con el resultado.

¿Qué campos necesito para relacionar una alarma con un KPI?

Como mínimo, identificador de alarma, fuente, activo, timestamp de origen, timestamp de recepción si existe, estado o transición, severidad local, ventana de asociación, regla de cálculo y versión del KPI. Añada orden, producto o modo de operación cuando condicionen la interpretación.

¿Debo sumar todas las alarmas de un turno?

No necesariamente. Un recuento puede describir carga de alarmas, pero no mide automáticamente tiempo perdido ni producción no realizada. Primero defina qué pregunta responde el recuento, cómo se deduplican repeticiones y qué alarmas quedan fuera por estar en prueba, mantenimiento o fuera de la ventana.

¿Qué hago si la alarma llegó tarde al sistema de informes?

Conserve el tiempo de origen y el de recepción. La asociación debe indicar cuál usa y por qué. Si no puede establecerse la secuencia con suficiente precisión, marque la relación como incierta en vez de colocar el evento en una ventana por conveniencia.

¿Una alarma crítica de seguridad puede tratarse como un dato de rendimiento?

No como sustituto del proceso de seguridad. Puede formar parte del contexto de un análisis operativo, pero toda condición de seguridad, calidad regulada o cumplimiento debe seguir sus procedimientos, responsables y requisitos de escalado propios.