El modelo de sistemas en el Análisis Causa Raíz (RCA, por sus siglas en inglés Root Cause Analysis) es presentado como un marco de causalidad (desde la normativa IEC 62740) que parte de una premisa directa y demostrable según la cual los accidentes o eventos no deseados (como las fallas) surgen por interacciones inadecuadas entre componentes del sistema y no por la falla aislada de una pieza; en lugar del pensamiento lineal que construye cadenas secuenciales de causa y efecto, este enfoque considera la instalación como una red de relaciones dinámicas cuyo comportamiento conjunto puede generar resultados que ninguna parte produciría por separado, y por tanto se muestra necesario en entornos de alta complejidad tecnológica porque permite ver lo que las técnicas convencionales no pueden.

Los sistemas productivos actuales operan con un acoplamiento mucho más estrecho que en décadas anteriores y por tanto un cambio de parámetro en una unidad puede propagarse en efectos en cascada hacia activos aguas abajo; además el operador frente a su pantalla puede no recibir ninguna señal de advertencia porque el software de control fue diseñado para condiciones que ya no aplican, de modo que buscar el componente roto equivale a mirar en el lugar equivocado y el modelo de sistemas exige al equipo investigador plantear otro cuestionamiento centrado en identificar ¿cuáles son las interacciones que el sistema de control no gestionó correctamente?

El análisis comienza por mapear los lazos de control y la retroalimentación entre los distintos niveles de la organización, y ese mapeo nos ayuda a documentar qué información estaba disponible para cada actor, operador, supervisor, gerente y algoritmo automatizado, así como si esa información era suficiente, correcta y procesable; a partir de ese diagnóstico la investigación asciende desde el nivel físico hacia las decisiones organizacionales que configuraron el entorno en el que operaba el personal de primera línea.

El objetivo principal del modelo se basa en su aporte para restructurar el sistema de control para que las restricciones de seguridad se apliquen de forma efectiva en las condiciones reales de operación, y cuando este trabajo se realiza con rigurosidad las acciones correctivas logran abordar de manera simultánea el algoritmo que falló, la interfaz que no alertó al operador y la decisión gerencial que modificó las condiciones de producción sin verificar si el software podía seguir garantizando la seguridad del proceso.

Fundamentos del modelo de sistemas en la industria

La teoría de sistemas surgió para gestionar la complejidad tecnológica posterior a la Segunda Guerra Mundial cuando los modelos lineales demostraron ser insuficientes ante accidentes en los que ningún componente había fallado de forma tradicional, y su premisa central sostiene que los incidentes emergen de un control inadecuado porque la organización no impuso las restricciones de seguridad necesarias sobre el comportamiento de sus elementos durante el diseño, el desarrollo o la operación del sistema.

Desde esa perspectiva la teoría contiene una implicación práctica en donde la causa raíz de una falla puede residir en una decisión tomada meses antes por alguien que nunca estuvo cerca del activo que colapsó.

Por ejemplo; con una política presupuestaria que retrasa la actualización del software de control, un procedimiento de gestión del cambio que no contempla la revisión de algoritmos ante modificaciones de producción o un sistema de incentivos que prioriza el volumen por encima de la seguridad del diseño, y todos estos son factores causales válidos bajo el modelo de sistemas, aunque no aparezcan en una orden de trabajo ni en un espectro de vibración.

De la cadena de eventos a la red de interacciones

El pensamiento lineal parte de la suposición de que hallar la falla más cercana al evento equivale a hallar la causa; sin embargo, el modelo de sistemas rechaza ese supuesto porque en entornos de acoplamiento estrecho la causa próxima y la causa raíz pueden estar separadas por varios niveles jerárquicos y por meses de decisiones organizacionales. De tal modo que, trazar el camino causal exige un marco que permita analizar relaciones dinámicas y no solo cadenas secuenciales, y para ello es necesario mapear flujos de información, lazos de control y puntos de decisión a lo largo de la organización.

En lugar de preguntar qué se rompió conviene formular qué condición del sistema hizo inevitable este resultado; esa reformulación abre el análisis a elementos que suelen quedar fuera de las investigaciones tradicionales. Así, se examina la calidad de la información disponible para el operador, la coherencia entre los parámetros operativos reales y los supuestos del software de control y la presión de producción que empujó al sistema hacia sus límites sin que la cadena de decisión evaluara las consecuencias.

Comportamiento emergente y acoplamiento en equipos industriales

Por el comportamiento emergente nos referimos a aquel fenómeno que ocurre cuando en la interacción de componentes que funcionan adecuadamente según su especificación y producen un resultado que ninguno de ellos generaría por separado.

En el control industrial esto ocurre cuando se modifica una variable del proceso sin verificar si los algoritmos de control están diseñados para las nuevas condiciones. Por lo que, se demuestra que en esos casos la causa no es un fallo independiente sino la interacción entre elementos.

Ese desajuste que va entre la lógica del software y la realidad actualizada del proceso es precisamente lo que el modelo de sistemas busca revelar. No hay un componente roto; existen dos subsistemas, el proceso físico actualizado y el software heredado, que no fueron diseñados para coexistir bajo las nuevas condiciones operativas y cuya interacción produjo un resultado inesperado que ninguno habría generado en aislamiento.

Técnicas derivadas y selección metodológica

El modelo de sistemas no tiene un procedimiento para dibujar diagramas porque actúa como marco conceptual que va orientando al investigador sobre qué tipo de causas buscar antes de elegir la herramienta con la que representarlas; en consecuencia, son las técnicas derivadas de esa visión las que materializan el pensamiento y convierten la investigación en un análisis trazable.

Para elegir la técnica conviene definir primero la naturaleza de la falla. A continuación, técnicas útiles según el caso:

• CAST, va indicada cuando el fallo involucra software, automatización o decisiones gerenciales sin rotura física; examina la estructura de control sociotécnica y qué restricciones de seguridad no se impusieron en cada nivel jerárquico.

• AcciMaps, es útil cuando las decisiones de alto nivel condicionaron la operación; organiza factores en capas desde el equipo físico hasta las políticas corporativas.

• Tripod Beta, resulta apropiada para integrar el análisis de barreras con el componente humano; destaca factores latentes y psicológicos.

• MORT, está pensada para eventos de alta severidad que requieren una revisión exhaustiva del sistema de gestión; ofrece un árbol preconfigurado para guiar la investigación.

• SOL, se encuentra orientada al aprendizaje organizacional más que a la identificación estricta de causas necesarias; sirve para extraer lecciones y mejorar procesos.

Análisis de factores humanos y organizacionales bajo el enfoque sistémico

Para el modelo de sistemas, el error humano no se interpreta como negligencia, puesto que se ve como una desviación predecible e inducida por condiciones organizacionales que hacen razonables ciertas acciones para el actor. Por tanto, la investigación se orienta a comprender el contexto, no a castigar al individuo, guiándose por qué la acción tomada tenía sentido con la información disponible.

Entre las precondiciones a documentar están la fatiga acumulada que es una de las más frecuentes por las jornadas extendidas de trabajo, interfaces que generan alarmas irrelevantes frecuentes y procedimientos que no reflejan el estado actual del activo. Su existencia incrementa la probabilidad de decisiones coherentes con la información imperfecta que recibe el operador.

Al cruzarse estas condiciones previas con un evento desencadenante, el operador actúa de forma errónea porque el diseño del sistema hace probable dicho error. Por tanto, las recomendaciones derivadas deben modificar el entorno y los procesos para reducir esta probabilidad, sin limitarse a sancionar al individuo.

Interfaz entre el operador y el algoritmo de control

La automatización en el pasar del tiempo logro cambiar parte de la naturaleza del error humano en las plantas industriales porque el operador supervisa una representación del proceso en pantalla y ya no interviene directamente en el proceso físico (además que también existen diferentes capas de controles de seguridad para evitar ciertos riesgos en los procesos); esa representación puede ser fiel o contener distorsiones, por ejemplo, las alarmas silenciadas que se consideran ruido, gráficos que omiten la variable de riesgo real o software que procesa datos con supuestos operativos obsoletos.

Cuando el algoritmo nos genera comandos basados en un modelo que no corresponde a la realidad actual, el operador recibe información que refuerza una comprensión incorrecta del estado del sistema y por tanto se configura un modelo mental defectuoso; esto no es un fallo del operador sino el resultado predecible de trabajar con información equivocada, de modo que las intervenciones deben priorizar la corrección de la representación y la actualización del software.

Presiones de producción y la migración hacia el riesgo

Las organizaciones industriales operan bajo presiones financieras que generan una tensión entre mantener los márgenes de seguridad del diseño y cumplir los objetivos de producción, y por tanto el modelo de sistemas reconoce la migración hacia los límites de seguridad como una adaptación progresiva en la que el comportamiento operativo se desplaza hacia condiciones no previstas por los diseñadores.

Esa migración ocurre de forma acumulativa porque cada decisión que es individual parece ser razonable desde su contexto; ahora cuando las decisiones se suceden turno tras turno se construye un entorno que incrementa la probabilidad de un evento grave, y por tanto el análisis debe centrarse en la secuencia de decisiones y en las condiciones organizacionales que las hacen plausibles.

Cursos recomendados

Joaquín Santos Herrera

Confiabilidad humana

Elimar Anauro Rojas

Introducción a la confiabilidad, disponibilidad y mantenibilidad

Andrés González

Mantenimiento Centrado en Confiabilidad (RCM)

Enrique González

Análisis de confiabilidad, disponibilidad y mantenibilidad (RAM)

Confiabilidad humana

Introducción a la confiabilidad, disponibilidad y mantenibilidad

Mantenimiento Centrado en Confiabilidad (RCM)

Evaluación de fallas organizacionales y su origen

Este modelo nos exige evaluar las causas latentes que emergen de los procesos administrativos y que estructuran el trabajo diario, porque políticas de compras orientadas al precio mínimo, procedimientos de gestión del cambio que no revisan algoritmos de control y sistemas de aseguramiento de calidad débiles crean ese tipo de condiciones que permiten que las carencias procedimentales logren persistir sin detección.

El análisis debe escalar desde el piso de la fábrica hasta las oficinas corporativas siguiendo la misma lógica en cada nivel, con interrogantes como: ¿qué restricción de seguridad debía imponerse aquí? ¿Se impuso? Si no, ¿por qué no?

Aplicar esa cadena de preguntas nos ayuda a ver cuándo la causa de un evento no fue únicamente el desgaste de una pieza, sino la ausencia de un mecanismo organizacional que habría detectado el riesgo antes de que se materializara.

Ejemplo práctico de análisis sistémico en planta

Una estación compresora de gas natural clasificada como activo crítico según la norma ISO 14224 sufrió el descontrol térmico de un intercambiador que provocó una pérdida de contención y detuvo la producción por más de 24 horas.

El equipo definió el evento focal como la pérdida de contención por superar 85 °C en el gas de proceso, umbral establecido para proteger los sellos mecánicos aguas abajo. Aunque la restricción de seguridad era conocida en la organización, nadie verificó si el sistema de control seguía siendo capaz de garantizarla bajo las nuevas condiciones de operación, y por tanto la causa raíz se relaciona con la falta de evaluación de la capacidad de control frente a cambios operativos.

Planteamiento de la falla funcional y descarte de hipótesis lineales

Se formularon tres hipótesis lineales: primero que la válvula de control de enfriamiento había sufrido rotura mecánica por fatiga del actuador; luego que un sensor RTD estaba descalibrado y enviaba lecturas erróneas al SCADA; y finalmente que el operador no respondió a las alarmas de temperatura.

Se realizaron las pruebas correspondientes y las tres fueron descartadas: la inspección mecánica confirmó que la válvula estaba intacta, la calibración metrológica certificó que el sensor operaba dentro de tolerancias y la revisión de registros del SCADA junto con las entrevistas al turno mostró que no hubo alarmas de temperatura antes del evento.

El descarte de las tres hipótesis lineales fue lo que abrió el espacio para el análisis sistémico. Si ningún componente falló y el operador no recibió ninguna señal de advertencia, la causa tenía que estar en la interacción entre el sistema de control y las condiciones reales del proceso.

Confirmación de la brecha sistémica

El equipo identificó que el departamento de procesos aumentó el caudal en un 15% por decisión gerencial y que esa decisión se ejecutó sin consultar al departamento de automatización; el software de control heredado no fue actualizado y, al operar con el nuevo caudal, la dinámica de transferencia de calor del intercambiador cambió lo suficiente como para que los comandos de enfriamiento del algoritmo original resultaran insuficientes. En consecuencia el proceso superó el umbral de seguridad de forma progresiva y ninguna alarma se activó porque el software no estaba procesando los nuevos valores de referencia.

La causa raíz fue la ausencia de un procedimiento de gestión del cambio tecnológico que obligara a revisar la lógica de control ante modificaciones de parámetros de producción; por tanto, la restricción de seguridad de no superar 85 °C no se impuso porque nadie evaluó si el algoritmo podía garantizarla bajo las nuevas condiciones.

Las cuatro acciones correctivas que emanaron del análisis atacaron niveles distintos:

• Actualizar el algoritmo del SCADA para el nuevo caudal

• Reprogramar las alarmas del HMI

• Incorporar la auditoría de lógica de software al procedimiento de gestión del cambio

• Capacitar a los operadores en los nuevos límites operativos

Ninguna habría surgido de un análisis que se hubiera detenido en el componente físico.

Conclusión

El modelo de sistemas transforma la forma en que una organización lee sus eventos porque, al considerar los accidentes o eventos como resultado de interacciones disfuncionales dentro de una estructura de control sociotécnica en lugar de atribuirlos a un componente roto o a un operador negligente, desplaza la pregunta de quién falló a cómo las interacciones entre personas, procedimientos y tecnología hicieron posible el incidente; de ese modo se accede a capas latentes que los enfoques lineales no exploran y se generan recomendaciones que modifican los procedimientos de gestión del cambio, reestructuran las interfaces de control y corrigen los incentivos organizacionales que empujaron al sistema hacia sus límites de diseño.

En consecuencia, aplicar este marco obliga a escalar el análisis mucho más allá del componente físico para corregir gobernanza, interfaces y criterios de decisión, de modo que las causas reales queden abordadas y se reduzca la probabilidad de recurrencia.