ERRORES QUE HACEN FRACASAR LOS PROYECTOS DE MEJORA DEL SISTEMA DE ALARMAS

Este es el quinto artículo de la serie dedicada al problema de las alarmas en la Industria. Llegados a este punto ya hemos puesto el problema de las alarmas en contexto, sabemos cómo deberíamos empezar un proyecto de mejora del Sistema de Alarmas e incluso tenemos algunos consejos para mejorar los KPIs de alarmas, pero de los errores también se aprende -a menudo, más que de los consejos- por eso este quinto artículo tratará sobre errores comunes que pueden desembocar en el fracaso de nuestro proyecto de mejora del Sistema de Alarmas.

Si te has perdido alguno de los anteriores artículos de la serie, aquí los tienes todos:

1. “El problema de las alarmas en la Industria”
2. “¿Por qué es necesario mejorar el funcionamiento de los sistemas de alarmas?”
3. “Primeros pasos en la Gestión de Alarmas. Midiendo el desempeño del Sistema de Alarmas”
4. “Mejorando los KPIs de alarmas de forma rápida y sencilla”

¿Por qué fracasan los proyectos de mejora de los Sistemas de Alarma?

Cada planta es un mundo, pero hay una serie de factores que se repiten en los proyectos de mejora de los Sistemas de Alarmas que terminan abandonados o fallidos. No tienen por qué darse todos simultáneamente para que un proyecto fracase, son los siguientes:

Mala gestión del proyecto

Como cualquier proyecto, uno dedicado a la mejora del Sistema de Alarmas puede fracasar por varios motivos: mala planificación, asignación deficiente de recursos, expectativas poco realistas/demasiado altas, objetivos mal definidos, plazos excesivamente cortos,…

Se plantean como una acción puntual, no como una tarea continua que deba incorporarse a las rutinas de la instalación

En muchas organizaciones, la mejora del Sistema de Alarmas se limita a la resolución de los Malos Actores, pero el Sistema de Alarmas es un ente vivo que debe seguir las modificaciones de la planta, como el resto del ICS. Por lo tanto, una actuación puntual sobre el Sistema de Alarmas tendrá unos resultados de una duración determinada, transcurrido un tiempo, su desempeño se degradará si éste no se monitoriza y se hacen los convenientes ajustes.

Distintas modificaciones a lo largo de la vida útil de la instalación, cambios en las condiciones de operación, desgastes y/o averías en la instrumentación, etc son alteraciones que acumuladas a lo largo del tiempo pueden alejar al Sistema de Alarmas del “punto dulce” de desempeño que se consiguió en un primer momento.

Por eso el estándar ANSI/ISA 18.2, “Management of Alarm Systems for the Process Industries” se basa en el concepto del Ciclo de Vida del Sistema de Alarmas, que veremos en próximos artículos.

No está claro quién es el responsable de la mejora del Sistema de Alarmas

A menudo la Dirección de la Planta hace responsable del Sistema de Alarmas -y de solucionar sus defectos, claro- al Departamento de Instrumentación y Control en exclusiva. A fin de cuentas, es el encargado del mantenimiento del ICS (hardware, software, redes, configuraciones, etc).

Sin embargo, el problema de las alarmas debe resolverse de forma multidisciplinar: el Departamento de Operaciones es quien mejor sabe cómo funciona el proceso que opera, HSE también debe opinar sobre las alarmas, igual que Ingeniería. Instrumentación y Control será el encargado de configurar las alarmas en el ICS, pero según los requerimientos de estos departamentos.

No hay un Documento de Filosofía de Alarmas, o es deficiente

Muchos proyectos de mejora fracasan porque no se entiende la necesidad de disponer de un Documento de Filosofía de Alarmas. Este documento debe recoger las mejores prácticas, los procedimientos de trabajo, las responsabilidades, la gestión de cambios, etc que afectan a las alarmas, por ejemplo, qué es o no una alarma, el porqué de un determinado valor de ajuste, cómo asignarle una determinada severidad, quién y por qué puede deshabilitar una alarma, cómo se definen los KPIs de las alarmas, cuál es el procedimiento a seguir al deshabilitar una alarma, etc.

Si todo esto no se deja documentado, la Gestión de Alarmas dependerá de los criterios particulares de las personas que trabajen en el Sistema de Alarmas en un determinado momento, por lo que será muy difícil -por no decir imposible- que el desempeño obtenido tras la mejora se mantenga a lo largo del tiempo: los involucrados inicialmente son trasladados a otros puestos, nuevos proyectos/modificaciones en la planta vienen con criterios de alarmas diferentes, etc.

En futuros artículos trataremos con más detalle el tema del Documento de Filosofía de Alarmas.

No hacer Benchmarking

En el segundo artículo de esta serie (“¿Por qué es necesario mejorar el funcionamiento de los sistemas de alarmas?”) ya hablábamos sobre la importancia de medir el desempeño de nuestro Sistema de Alarmas, calculando los KPIs de las alarmas y comparándolos con las recomendaciones que daban los estándares.

Procediendo así dispondremos de una valoración objetiva de nuestra situación inicial y cuán lejos estamos de las recomendaciones de los estándares. Es una forma objetiva de cuantificar nuestro problema de las alarmas, mucho mejor que las “sensaciones” o las “impresiones” de los panelistas, que podremos usar, por ejemplo, a la hora de solicitar recursos para el proyecto de mejora del Sistema de Alarmas y que nos resultará imprescindible a lo largo del proceso: monitorizar los KPIs de alarmas y su evolución con respecto a la situación inicial nos permitirá saber si las medidas correctivas que hemos puesto en marcha están dando resultado.

No usar las herramientas adecuadas

Parece que está muy extendida la falsa creencia de que adquiriendo un determinado software se resolverán “mágicamente” todos los problemas con las alarmas, creo que con lo que hemos estado viendo hasta ahora en esta serie de artículos está claro que no es así.

Tampoco es infrecuente que se desprecien las posibilidades que ofrece un software específico de Gestión de Alarmas, y que se pretenda afrontar esta tarea con una simple hoja de cálculo. Sin embargo, la facilidad/dificultad para conectar la hoja de cálculo con el ICS o exportar la información de este, el volumen de información a tratar, etc puede hacer que el equipo a cargo de la mejora del Sistema de Alarmas pase más tiempo extrayendo y tratando datos que analizándolos, proponiendo soluciones y comprobando su efectividad. Esto que resulta cierto cuando la Gestión de Alarmas se limita a evaluar la situación inicial del Sistema de Alarmas, se vuelve una tarea prácticamente inviable si se pretende ir un poco más allá, por ejemplo, si la intención es elaborar informes frecuentes, detectar cambios en las configuraciones, guardar un registro de las configuraciones iniciales, informes de discrepancias, etc.

Lo mejor es utilizar una herramienta software que permita una conexión fácil y estándar con el ICS, que sea independiente de la marca del mismo (por si nuestra planta trabaja con distintos ICS), fácilmente escalable, que calcule automáticamente los KPIs definidos por los estándares y que elabore informes. La solución ideal debería incluir también funciones de Base de Datos Maestros de las Alarmas (valores de ajuste, documentación asociada,etc) y supervisión de cambios, volcado de las configuraciones iniciales, etc.

La herramienta software ideal debería automatizar todo el trabajo mecánico (extraer información, dar formato, calcular KPIs, elaborar informes, detectar/revertir modificaciones, etc) para que el equipo a cargo de la Gestión de Alarmas dedique todos sus esfuerzos a analizar la información, proponer soluciones y comprobar si están dando resultado. Intentar hacer todo esto con herramientas no específicas es comprar papeletas para el fracaso.

Fijarse sólo en los KPIs de las alarmas

Si bien como hemos indicado anteriormente hay que monitorizar la evolución de los KPIs de las alarmas, no debemos olvidar que la mejora del Sistema de Alarmas depende de otros muchos más factores.

Por ejemplo, es necesario saber si la activación de una determinada alarma desencadena alguna respuesta del panelista (como mencionamos en el artículo 3 de esta serie “Primeros pasos en la gestión de alarmas. Midiendo el desempeño del sistema de alarmas”, reconocer/silenciar una alarma no se considera una respuesta válida), ya que en caso negativo esto podría indicar que la alarma analizada no es una verdadera alarma, sino una alarma molesta. El lector atento habrá notado que en el artículo 3 no había ningún KPI de alarmas que midiera este aspecto.

Un posible indicador podría ser el ratio alarmas/acciones del operador puede servir para identificar una mala estrategia de alarmas, ya que si consideramos que toda alarma debe implicar una acción por parte del panelista, este ratio debería ser idealmente 1:1 (una alarma→una respuesta), aunque lo habitual es que sea el ratio sea mayor (2:1 o incluso más).

Hay que tener presente que:

• No todas las acciones del panelista se registran en los logs del ICS. Por ejemplo, el cambiar de pantalla para comprobar alguna otra variable de proceso para localizar el problema (troubleshooting), contactar con personal en terreno para que arranque/pare equipos, etc
• Este “nuevo KPI de alarmas” puede verse muy afectado por el grado de automatización de la planta bajo análisis. Por ejemplo, si no hay mucha capacidad de actuación desde panel y se depende de los operadores de terreno para arrancar/parar equipos. Como hemos comentado en el punto anterior, estas actuaciones no quedarían registradas en los logs del ICS.

En cualquier caso, un desequilibrio excesivo entre alarmas/acciones podría indicar un exceso de alarmas que no son tal, de múltiples alarmas que alertan de la misma situación o de alarmas encadenadas.

Otros datos a considerar son los históricos de las variables de procesos, ya que permiten determinar entornos de operación que pueden utilizarse para definir los valores de ajuste de las alarmas (setpoints, histéresis).

Un aspecto adicional de mejora del Sistema de Alarmas relacionado con la configuración de alarmas en el ICS podría ser los textos de servicio (los textos que describen el significado de las alarmas). En general, estos deben ser claros, bien estructurados, simples, consistentes en toda la instalación, fáciles de leer y que “hablen” el idioma del panelista, de manera que no pierda un tiempo precioso en entender de qué alerta la alarma y/o a qué parte del proceso hace referencia.

Por ejemplo, en una planta española vi que en la misma interfaz de operación un puñado de alarmas tenían los textos de servicio en inglés. Esto puede parecer una aberración, pero es que ni cuando se utiliza el idioma propio del lugar donde se ubica la instalación uno se libra de encontrar joyas como alarmas activas con textos tan explicativos como “Fallo general” ¡y con la planta funcionando!

Sobre este punto, recomiendo la lectura de este otro artículo aquí en MyTips.

EL INCENDIO DE LA CATEDRAL DE NOTRE DAME DE PARÍS

Relacionado con la mejora del Sistema de Alarmas, cabría también considerar la optimización de la GUI (Graphic User Interface, los gráficos de operación). La idea sería que el panelista detectara cualquier alteración en la GUI, antes incluso de que se produjera la alarma. La mejora de la GUI se merecería otra serie de artículos, pero por ejemplo, en esta ponencia sobre diseño de GUIs comentaba que el Center for Operator Performance ha calculado que se tarda hasta un 25% más en detectar una alarma en un gráfico de operación cuando el color rojo se utilizaba tanto para alarmas como para otros elementos del gráfico (por ejemplo, estado de motores y válvulas).

Operar una planta con una mala GUI y utilizando sólo las alarmas equivale a conducir un coche con el parabrisas sucio y pretender mantenerse en la carretera gracias a los bocinazos del resto de los conductores y/o las bandas rugosas que alertan de que nos salimos del carril.

En definitiva, no hay que considerar la mejora de los KPIs de alarmas como el objetivo de nuestro proyecto de mejora de las alarmas. Los KPIs de alarmas son unos indicadores que permiten evaluar el desempeño del Sistema de Alarmas, pero la verdadera medida del desempeño de nuestro Sistema de Alarmas es la reducción de paradas imprevistas, accidentes/incidentes de seguridad y/o mediambientales. Si no tenemos esto claro y llevando la situación al extremo,podríamos llegar al absurdo de pensar que un ICS subalarmado es mejor que uno que tenga malos KPIs, aunque todas las alarmas que muestre sean “alarmas de calidad”.

Hay que tener cuidado de no confundir los síntomas (KPIs de Alarmas) con la enfermedad (Mal funcionamiento del Sistema de Alarmas)

Tratar todos los datos de las alarmas de la misma manera

Las alarmas realmente molestas para el panelista son las alarmas audibles, pero muchos ICS siguen registrando en sus logs alarmas que no suenan en panel. Si no tenemos esto en cuenta, probablemente tendremos peores KPIs de alarmas y veamos el problema mucho más grave de lo que es en realidad.

¡OJO! No estoy diciendo que porque una alarma no suene, no sea un problema. De hecho, podría tratarse de un problema aún más grave, por ejemplo, una alarma que se silenció temporalmente y que se ha quedado así por olvido. Pero también podría ser una alarma que no era tal y que se ha “resuelto” silenciándola eternamente en lugar de eliminarla del ICS. Ambas situaciones deben analizarse y actuar en consecuencia para resolverlas.

No considerar necesaria la formación a los usuarios

Dejar a los usuarios (los panelistas) frente a un Sistema de Alarmas modificado sin la suficiente formación no es la forma más correcta de proceder.

Aunque los cambios se hayan implementado pensando en mejorar las condiciones de trabajo del panelista, es necesario que éste conozca qué se ha hecho en el Sistema de Alarmas y cómo repercutirá en su trabajo. Si no, como mínimo mostrará sus reticencias o directamente se opondrá al nuevo sistema, tal vez porque al recibir menos alarmas considere que está perdiendo información sobre el proceso.

Tampoco hay que olvidar que sin la correcta formación es muy probable que no se aprovechen al máximo las capacidades del nuevo sistema, con lo que los resultados de nuestro proyecto de mejora podrían ser menores a los esperados. Por otra parte, tratar de supervisar el funcionamiento de una planta industrial leyendo al mismo tiempo el manual del Sistema de Alarmas no es la forma más eficiente de operar.

Es necesaria cierta labor didáctica, ya que los panelistas pueden seguir queriendo trabajar como antes, como el ejemplo que comentaba en anteriores artículos sobre la insistencia de alarmar la situación “motor parado”, aunque fuese una situación normal del proceso.

En algunas plantas en las que he trabajado, los operadores, abrumados con pantallas de resumen de alarmas repletas de alarmas rancias habían aprendido a filtrar las alarmas por tiempo, de manera que sólo mostraban las alarmas de las últimas 12h o las correspondientes a su turno de trabajo. Sin embargo, no comunicaban esta incidencia, por lo que las alarmas rancias no eran resueltas y algunas de ellas permanecían en el sistema por meses. Algo similar ocurría con la funcionalidad del silenciado temporal de alarmas (Alarm Shelving). Algunas alarmas especialmente molestas se “shelveaban” (expresión utilizada en el panel) y cuando transcurría el tiempo máximo se volvían a “shelvear”, sin que se solucionara la causa de la alarma.En ambos casos, los operadores habían encontrado una solución válida para sus problemas, sin ser conscientes de lo que esto implicaba para el desempeño del Sistema de Alarmas.

Pretender ahorrar no involucrando a toda la gente necesaria

Una fase importante de cualquier proyecto de mejora de un Sistema de Alarmas es la de Racionalización. En futuros artículos la trataremos con más detalle dentro del Ciclo de Vida de la Gestión de Alarmas que define el estándar ISA 18.2, pero por el momento podemos definirla como el proceso que permite obtener alarmas “de calidad” (con las características que vimos en el segundo artículo de la serie), aunque erróneamente muchos piensan que es la etapa que elimina alarmas del sistema.

Se trata de una tarea que puede requerir bastante tiempo, que necesita de la participación de bastante personal de distintos departamentos y que por lo tanto “resulta cara”.

En las sesiones debe haber lógicamente personal de operaciones, especialmente panelistas que son los que conocen la operativa y los problemas de las alarmas, mucho mejor que los ingenieros de proceso, que a menudo son los únicos que participan en representación del personal de operaciones. También personal a cargo del mantenimiento de la instrumentación, del ICS, ingenieros de proceso, técnicos de HSE, expertos en Seguridad Funcional, etc.

Para abaratar el coste de las sesiones de racionalización, más que reducir el número de participantes, puede ser mucho más útil reducir en lo posible la duración de las sesiones:

• Asegurándose antes de las sesiones de que el equipo a cargo de la racionalización dispone de toda la información que pueda necesitar (P&ID, Filosofía de Alarmas, manuales de operación, configuraciones del ICS, análisis HAZOP y /o LOPA, etc).
• Evitando que las sesiones de racionalización se vean interrumpidas por la operativa habitual de la planta. Para ello puede ser interesante que se celebren fuera de la instalación.
• Contando con un facilitador habituado al procedimiento, de manera que el desarrollo del mismo sea más ágil.

No hacer racionalización de alarmas durante la investigación de incidentes y/o análisis HAZOP

Los análisis HAZOP y LOPA son responsables de incorporar a los sistemas multitud de alarmas como medida preventiva adicional ante incidentes/accidentes como problemas de seguridad, riesgos de pérdida de producción o incidentes medioambientales. En estos análisis suelen estudiarse las causas que puedan originar el incidente/accidente y sus consecuencias, dando como resultado la creación de una nueva alarma con la que se pretende reducir el riesgo.

Sin embargo, no basta con indicar que se requiere una alarma adicional, es necesario definirla completamente para que sea una alarma “de calidad”: acción correctiva a ejecutar, tiempo de respuesta disponible, severidad de la alarma, valor de ajuste, etc.

A menudo se observa además cierta “ligereza” a la hora de incorporar en los sistemas nuevas alarmas para reducir así los requisitos de las funciones instrumentadas de seguridad (SIF, interlocks, enclavamientos). Al depender de una acción humana, no es fácil asignar a una alarma un factor de reducción del riesgo (Risk Reduction Factor, RRF): ¿qué panelista reaccionará a la alarma? Es de suponer que dentro de la plantilla habrá operadores con distintos niveles de experiencia, pero, aunque todos los panelistas sean igual de experimentados ¿podemos asegurar que el panelista estará al 100% de sus capacidades siempre que se produzca la alarma? Una mala noche de sueño, problemas personales, los inicios de una enfermedad, el momento del turno en el que se produce la alarma, pueden influir en su respuesta ¿Será esa alarma la única alarma a la que tenga que responder, o se producirá en medio de una avalancha de otras muchas alarmas?…

Por todas estas dudas, es difícil asignar un RRF a una alarma . Algunos especialistas optan por la opción más conservadora (RRF=1, no hay reducción del riesgo), mientras que otros, más optimistas afirman que puede otorgarse un RRF>=10. Como según los estándares, la actuación del panelista no puede ser la última línea de defensa ante un accidente, lo habitual es trabajar con un SIS (Safety Instrumented System, Sistema Instrumentado de Seguridad) o un ESD (Emergency Shutdown System, Sistema de Parada de Emergencia), pero como muestra la siguiente figura, la definición de SIS/ESD se ve afectada por el RRF que asignemos a las alarmas.

No quiero complicar en exceso este apartado con aspectos más propios de la Seguridad Funcional, pero me gustaría que el lector tuviese claro por qué es difícil asignar un RRF a una alarma y que en un panel que ya esté habitualmente sobrecargado de alarmas la precaución nos debería hacer pensar que su RRF=1.

Si ya es difícil evaluar el RRF de una alarma, cuando ésta forma parte de un Sistema de Alarmas defectuoso, la tarea se vuelve un acto de fe. No podemos afirmar con seguridad que la alarma cumplirá su cometido, por muy alta que sea la severidad que le asignemos

La solución es modificar los procedimientos de HAZOPs y LOPAs, de manera que cualquier alarma que se haya considerado necesario incluir en el sistema como resultado de estos análisis ya sea una alarma “de calidad”, es decir, que ya haya sido racionalizada.

Apostar por técnicas de alarmado dinámico demasiado pronto

Los avances en las técnicas de Alarmado Dinámico han hecho que en muchas instalaciones se piense que la solución al problema de las alarmas es simplemente tecnológica: un software que estudia los datos de alarmas de la planta “aprende” que puede suprimir/silenciar ciertas alarmas (por ejemplo, porque son alarmas parlanchinas, porque se produce simultáneamente con otra alarma, etc) sin necesidad de averiguar las causas y poner en marcha acciones correctivas.

Sin embargo, antes de poner en marcha acciones de Alarmado Dinámico sería conveniente acometer la Racionalización de las Alarmas y resolver las alarmas molestas. Como resultado de la racionalización, muchas de las alarmas puede que resulten innecesarias (por ejemplo, porque avisan de la misma situación anómala que otras alarmas), otras alarmas resultarán ser “avisos”, etc. Incluso es posible que durante la racionalización algunas alarmas sean ya identificadas como candidatas sobre las que aplicar técnicas de Alarmado Dinámico (por ejemplo, valores de ajuste dependiendo del modo de funcionamiento de la planta).

En cualquier caso, lo recomendable es aplicar el Alarmado Dinámico sobre alarmas ya racionalizadas y no sobre la totalidad de las alarmas. De no proceder así, es posible que el Alarmado Dinámico “oculte” otros problemas o bien que su funcionamiento sea “demasiado oscuro”, haciendo difícil el comprender cómo funciona, dificultando su mantenimiento y enmascarando cómo se relaciona con el resto de configuraciones del ICS.

Deficiente comunicación de resultados/transferencia de información (falta de rendición de cuentas, falta de transparencia)

Es aconsejable que el Documento de Filosofía de Alarmas contenga la definición de las distintas tareas a ejecutar sobre el Sistema de Alarmas, quiénes son los responsables de cada una de ellas y los resultados que cada parte debe ofrecer al resto para evaluar/auditar su trabajo. Debe hacerse de forma ágil y sencilla, de manera que sea comprensible y fácilmente aplicable en el día a día de la operativa de la planta y que no se vuelva una carga burocrática extra; esta es la mejor manera de asegurar que los resultados obtenidos con el proyecto de mejora del Sistema de Alarmas se mantendrán en el tiempo.

Conclusiones

• Un mal Sistema de Alarmas supone un importante riesgo para la Seguridad, la Salud y el Medioambiente, además de afectar negativamente a los resultados económicos de la planta.
• No puede plantearse la Gestión de las Alarmas como una tarea puntual. Seguir el Ciclo de Vida de la Gestión de Alarmas es la mejor garantía de que el desempeño del Sistema de Alarmas se mantendrá en el tiempo.
• Los proyectos de mejora de los Sistemas de Alarmas tienen los mismos problemas que otro tipo de proyectos y otros que les son específicos. Evitar estos errores aumenta las posibilidades de éxito.
• Resulta indispensable vigilar el desempeño del Sistema de Alarmas, para comprobar si las medidas correctivas surten efectos y si el sistema sigue funcionando en las mejores condiciones.
• Quizás el error más frecuente en la Gestión de Alarmas sea el querer afrontar la tarea sin tener antes un buen Documento de Filosofía de Alarmas. Este documento debe recoger metodologías de trabajo, indicadores de desempeño, roles y responsabilidades, etc. Si la metodología no está convenientemente documentada, dependerá de las personas implicadas y cualquier modificación en los equipos de trabajo relacionados con la Gestión de Alarmas afectará al desempeño del sistema, haciendo imposible conseguir la repetibilidad de los resultados y que estos se mantengan en el tiempo.
• Las herramientas software son una gran ayuda para la Gestión de Alarmas, pero por sí solas no son la solución. Es necesario implicar a múltiples departamentos de la organización.
• La mejora de los KPIs de alarma no debe cegarnos. Estos no dejan de ser números, la verdadera medida de que estamos mejorando el desempeño de nuestro Sistema de Alarmas es la reducción de paradas imprevistas, accidentes/incidentes de seguridad y/o medioambientales y hay mucho donde trabajar sobre las alarmas y sin embargo, no inciden en los KPIs.
• Una garantía de éxito de un programa de mejora de la Gestión de Alarmas es conseguir que las tareas asociadas a las alarmas se vean como otra de las tareas habituales en la rutina operacional de la planta.

Como siempre, agradezco el tiempo dedicado a la lectura de este artículo y os invito a enriquecerlo con vuestros comentarios sobre vuestras experiencias en el tema, buenas prácticas en vuestros centros de trabajo, enlaces de interés, etc.