Comprenda cómo aplicar Bow Tie en ingeniería para relacionar amenazas, evento central, consecuencias, barreras preventivas y mitigadoras y factores de degradación.
¡Descúbrelo!
Bow Tie es una técnica de análisis de riesgos que representa, en una única estructura visual, cómo determinadas amenazas pueden conducir a la pérdida de control sobre un peligro y qué consecuencias pueden ocurrir si ese evento crítico se materializa. El método conecta amenazas, evento central, consecuencias y barreras, permitiendo evaluar no solo «cuán crítico» es un riesgo, sino principalmente qué controles deben impedir su ocurrencia y qué controles deben limitar sus efectos.
En proyectos de ingeniería, Bow Tie resulta especialmente útil cuando un riesgo exige claridad sobre barreras técnicas, administrativas y operativas. No sustituye HAZOP, FMEA, FTA, matrices de riesgos ni análisis cuantitativos. Su fortaleza consiste en hacer explícitas la lógica causal y la arquitectura de controles de un escenario crítico, facilitando decisiones de diseño, verificación de salvaguardas, definición de responsabilidades, commissioning y seguimiento del riesgo residual.
Qué es el análisis Bow Tie
El nombre Bow Tie, o «pajarita», proviene de la forma del diagrama. A la izquierda se sitúan las amenazas capaces de conducir al evento crítico; en el centro se encuentra el top event o evento central; y a la derecha aparecen las posibles consecuencias. Entre las amenazas y el evento central se sitúan las barreras preventivas. Entre el evento central y las consecuencias aparecen las barreras mitigadoras.
La lectura correcta del método exige separar conceptos que con frecuencia se mezclan. El peligro es la fuente, situación o condición con potencial de daño. El evento central representa la pérdida de control sobre ese peligro. Las amenazas son condiciones o eventos capaces de provocar esa pérdida de control. Las consecuencias son los efectos plausibles que pueden desarrollarse después del evento central.
Esta distinción evita diagramas vagos. Si en el centro del Bow Tie se coloca algo como «riesgo eléctrico alto» o «fallo grave», el análisis pierde precisión. El evento central debe describir un cambio de estado observable, por ejemplo: pérdida de aislamiento de un circuito energizado, pérdida de la alimentación redundante, sobrepresión de un equipo, pérdida de contención, indisponibilidad de un sistema crítico o liberación no controlada de energía.
Cuando el riesgo depende de múltiples barreras y disciplinas, el valor está en convertir el Bow Tie en gobernanza: escenario, controles, owners, evidencias y riesgo residual deben permanecer conectados con la gestión del proyecto.
Lógica amenaza → evento central → consecuencia
La estructura Bow Tie combina dos preguntas diferentes. En el lado izquierdo, el equipo investiga qué puede provocar la pérdida de control. En el lado derecho, investiga qué puede ocurrir después de que se haya perdido el control. Esta separación es valiosa porque prevención y mitigación no son lo mismo.
Una barrera preventiva busca interrumpir la cadena causal antes del evento central. Una barrera mitigadora actúa después del evento central, reduciendo la probabilidad, severidad o propagación de determinadas consecuencias.
Este encadenamiento mejora la calidad del tratamiento de riesgos porque impide que el equipo confunda una acción preventiva con una respuesta contingente. También ayuda a identificar situaciones en las que existe un gran número de controles a la izquierda, pero casi ninguna capacidad de limitar las consecuencias si la prevención falla — o al contrario.
Qué debe existir en el centro del Bow Tie
El evento central es el punto de articulación del método. No debe ser tan amplio que reúna escenarios sin relación causal, ni tan específico que convierta el diagrama en una secuencia operativa imposible de gestionar.
Un buen evento central describe una pérdida de control relevante sobre un peligro. En sistemas eléctricos, puede ser la energización no intencionada de una parte que debería estar desenergizada. En Data Centers, puede ser la pérdida simultánea de las fuentes que alimentan una determinada carga crítica. En sistemas presurizados, puede ser la pérdida de contención. En infraestructura de telecomunicaciones, puede ser la pérdida de conectividad de un backbone sin una ruta alternativa disponible.
El equipo debe poder responder cuatro preguntas sobre el evento central:
- qué condición previa debe existir para que el escenario sea relevante;
- qué amenazas pueden provocar la pérdida de control;
- qué barreras impiden que cada amenaza llegue al evento central;
- qué consecuencias pueden desarrollarse si ocurre el evento central.
Cuando estas respuestas no están claras, normalmente el problema está en la formulación del escenario y no en la herramienta.
Amenazas: causas que pueden conducir al evento central
Amenaza no es sinónimo de causa raíz. En un Bow Tie, una amenaza es un evento, condición o mecanismo que puede iniciar la secuencia que conduce al evento central. A su vez, una amenaza puede tener causas subyacentes que deban investigarse mediante RCA, 5 Porqués, FTA u otra técnica.
En un escenario de pérdida de alimentación de un sistema crítico, las amenazas pueden incluir fallo de la alimentación normal, fallo de transferencia automática, indisponibilidad del grupo electrógeno, mantenimiento simultáneo de elementos redundantes, error de configuración, actuación indebida de protección o un fallo de causa común que afecte a dos rutas aparentemente independientes.
El valor del Bow Tie aparece cuando el equipo deja de limitarse a enumerar amenazas y pasa a preguntar: ¿qué barrera existe frente a cada una de ellas y cómo sabemos que esa barrera está disponible y es eficaz?
Barreras preventivas
Las barreras preventivas actúan antes del evento central. Reducen la probabilidad de que una amenaza progrese hasta la pérdida de control. En Ingeniería, pueden adoptar distintas formas:
- barreras de diseño: redundancia, segregación física, dimensionamiento, interlocks, protección, fail-safe y selección de materiales;
- barreras instrumentadas: detección, lógica de control, permissives, trips y sistemas de protección;
- barreras físicas: contención, separación, aislamiento y protección mecánica;
- barreras procedimentales: permisos de trabajo, checklists, secuencias operativas, bloqueo y etiquetado;
- barreras organizativas: segregación de funciones, doble verificación, autoridad técnica y niveles de aprobación;
- barreras de assurance: inspección, pruebas, FAT, SAT, commissioning, auditorías y verificación independiente.
Una lista de controles, por sí sola, no demuestra que existan barreras eficaces. El análisis debe verificar si el control es específico para la amenaza, si está implementado, si posee un desempeño adecuado, si es suficientemente independiente de las demás salvaguardas relevantes y si puede probarse o evidenciarse.
Barreras mitigadoras
Las barreras mitigadoras actúan después del evento central. Su objetivo es impedir que la situación evolucione hacia determinadas consecuencias o reducir la magnitud de los efectos.
Entre los ejemplos se incluyen sistemas de detección y alarma, contención secundaria, protección contra incendios, rutas alternativas, parada de emergencia, redundancia de recuperación, procedimientos de respuesta, plan de contingencia, capacidad de aislamiento, inventario estratégico de repuestos y recuperación de datos.
Una barrera mitigadora no debe contabilizarse como prevención si solo actúa después de que el evento central ya haya ocurrido. Esta distinción es especialmente importante en análisis de disponibilidad y continuidad, en los que una arquitectura puede parecer «redundante» pero depender de mecanismos que únicamente reducen el tiempo de recuperación y no la probabilidad de indisponibilidad.
Desempeño de barrera: existencia no es eficacia
Uno de los errores más frecuentes en Bow Tie es considerar que la simple presencia de un control en el diseño significa que la barrera es fiable. En gestión de riesgos, una barrera debe tratarse como una función que necesita estar disponible cuando sea requerida.
Por ello, el análisis debe buscar evidencias de desempeño. Según el caso, puede incluir criterios como:
- función claramente definida;
- requisito de desempeño medible;
- independencia suficiente respecto de fallos de causa común;
- disponibilidad operativa;
- capacidad de prueba;
- mantenimiento e inspección definidos;
- responsable de la integridad de la barrera;
- evidencia de commissioning y aceptación;
- seguimiento de la degradación;
- tratamiento de bypass, inhibición o indisponibilidad temporal.
Este enfoque conecta Bow Tie con gestión de activos, confiabilidad, QA/QC y commissioning. La barrera deja de ser únicamente un rectángulo en el diagrama y pasa a tener requisitos y evidencias asociados.
Las barreras críticas solo son defendibles cuando requisitos, criterios de aceptación, pruebas y evidencias demuestran que la función prevista se implementó realmente y sigue siendo verificable a lo largo del ciclo de vida.
Factores de degradación de las barreras
Una barrera puede existir y aun así fallar cuando sea requerida. Bow Tie puede profundizarse mediante la identificación de factores de degradación, es decir, condiciones que reducen su eficacia.
Imagine una barrera basada en inspección periódica. Su eficacia puede degradarse por un procedimiento inadecuado, frecuencia insuficiente, instrumento sin calibración, equipo sin competencia, registros incompletos o fallo en el tratamiento de las anomalías detectadas. Para cada factor relevante pueden existir controles específicos de degradación.
Este nivel de análisis es útil para diferenciar «barrera diseñada» de «barrera asegurada». En proyectos complejos, muchos riesgos residuales derivan menos de la ausencia de salvaguardas que de la pérdida progresiva de su integridad a lo largo del ciclo de vida.
Cómo construir un Bow Tie paso a paso
La construcción debe comenzar por el escenario, no por la herramienta gráfica.
1. Defina el alcance y los objetivos
Determine qué sistema, fase, proceso o decisión será analizado. Un Bow Tie de construcción puede tener controles distintos de un Bow Tie de operación. También deben estar claros los objetivos afectados: seguridad, disponibilidad, plazo, coste, desempeño, medio ambiente, continuidad o conformidad.
2. Identifique el peligro y formule el evento central
Describa la fuente de riesgo y la pérdida de control que se situará en el centro. Compruebe la formulación preguntando si el evento central ocurre antes de las consecuencias que el equipo pretende analizar.
3. Identifique amenazas plausibles
Enumere mecanismos capaces de conducir al evento central. Evite duplicar la misma amenaza con formulaciones distintas y no transforme controles ausentes en amenazas. «Falta de mantenimiento» puede ser causa de degradación de una barrera, mientras que «fallo del equipo por degradación no detectada» puede ser una amenaza más adecuada para el escenario.
4. Identifique barreras preventivas
Para cada amenaza, determine qué interrumpe realmente la secuencia. Registre controles reales, no intenciones genéricas como «atención del equipo».
5. Identifique consecuencias
Evalúe efectos diferentes. Un mismo evento central puede producir consecuencias de seguridad, indisponibilidad, daños al activo, pérdidas financieras e impacto contractual. Sin embargo, las consecuencias deben seguir siendo causalmente plausibles.
6. Identifique barreras mitigadoras
Asocie controles que actúan después del evento central y antes de cada consecuencia. Compruebe si existe cobertura para las principales rutas de escalada.
7. Analice la degradación y el assurance de las barreras
Determine cómo la organización confirma la integridad de cada barrera y qué factores pueden reducir su eficacia.
8. Defina responsables y acciones
El diagrama debe producir decisiones. Las barreras críticas sin owner, evidencia o plan de verificación deben generar acciones trazables en el registro de riesgos, plan de acción, plan de inspección y pruebas o sistema de gestión correspondiente.
Ejemplo: pérdida de alimentación de una carga crítica
Considere un sistema en el que una determinada carga debe permanecer energizada. El peligro puede ser la dependencia de energía eléctrica para mantener una función esencial. El evento central puede definirse como pérdida de alimentación de la carga crítica más allá del tiempo de autonomía admisible de la etapa inmediatamente disponible.
Entre las amenazas posibles están el fallo del alimentador normal, el fallo del ATS, el fallo de arranque del generador, la indisponibilidad simultánea de fuentes durante mantenimiento y un fallo de causa común asociado a un cuadro compartido.
Las barreras preventivas pueden incluir arquitectura redundante, alimentación mediante rutas independientes, protección selectiva, interlocks, redundancia N+1, mantenimiento basado en condición, ensayos periódicos y control de intervenciones simultáneas.
Después del evento central, las barreras mitigadoras pueden incluir UPS con autonomía disponible, transferencia a una ruta alternativa, shedding controlado, plan de contingencia, recuperación priorizada y procedimientos de operación de emergencia.
Las consecuencias pueden incluir indisponibilidad de sistemas, pérdida de datos, interrupción de procesos, incumplimiento de SLA, daños operativos y necesidad de una parada segura.
El ejemplo muestra por qué Bow Tie no debe tratarse como una «matriz bonita». Obliga al equipo a demostrar cómo se controla cada ruta de riesgo.
Bow Tie vs. matriz de riesgos
La matriz clasifica y prioriza. Bow Tie explica el escenario y sus barreras. Ambas técnicas pueden ser complementarias.
Una matriz puede indicar que la «pérdida de alimentación crítica» presenta un nivel alto. Bow Tie muestra qué amenazas contribuyen a ese evento, qué barreras existen, cuáles pueden fallar y qué consecuencias siguen siendo posibles. Después de definir controles adicionales, el riesgo residual puede reevaluarse en la matriz.
Esta integración mejora la trazabilidad entre clasificación y tratamiento. En lugar de reducir la puntuación simplemente porque «se previeron acciones», el equipo puede indicar qué barreras se implementaron y verificaron efectivamente.
Bow Tie vs. HAZOP
HAZOP es una técnica estructurada para el estudio de desviaciones, tradicionalmente desarrollada por un equipo multidisciplinar mediante palabras guía y documentación sistemática. Bow Tie es una representación orientada a escenarios y barreras.
Un HAZOP puede identificar una desviación relevante, sus causas, consecuencias y salvaguardas. Algunos escenarios críticos identificados pueden desarrollarse después mediante Bow Tie para profundizar la arquitectura de barreras, los factores de degradación, las responsabilidades y el assurance.
No es necesario convertir cada línea de HAZOP en un Bow Tie. El uso debe ser selectivo, priorizando eventos que exijan comunicación clara y gestión continua de controles.
Bow Tie vs. FMEA y FMECA
FMEA parte de modos de fallo de componentes, funciones o procesos y analiza sus efectos y causas. FMECA añade el tratamiento de criticidad. Bow Tie parte de un evento central y organiza amenazas, consecuencias y barreras.
FMEA suele ser eficiente para explorar cómo pueden fallar los elementos. Bow Tie es eficiente para demostrar cómo distintos mecanismos convergen hacia un evento crítico y cómo la organización controla las secuencias antes y después de ese evento.
En sistemas complejos, FMEA puede alimentar amenazas y fallos de barreras de un Bow Tie. La relación inversa también es útil: Bow Tie puede mostrar qué barreras merecen un FMEA más detallado por ser críticas para el control del escenario.
Bow Tie vs. FTA
FTA, o Fault Tree Analysis, utiliza lógica deductiva para descomponer combinaciones de eventos que conducen a un evento superior. Resulta especialmente útil cuando interesa comprender relaciones AND/OR, fallos combinados y, cuando existen datos adecuados, cuantificar probabilidades.
El lado izquierdo de un Bow Tie puede recordar a un árbol causal, pero no sustituye la estructura lógica formal de un FTA. Cuando un evento central depende de combinaciones complejas, FTA puede profundizar la causalidad mientras Bow Tie mantiene la visión de barreras y consecuencias.
Bow Tie vs. plan de contingencia
El plan de contingencia aborda la respuesta organizada ante escenarios previamente analizados. En Bow Tie, diversas medidas de contingencia aparecen en el lado derecho como barreras mitigadoras o mecanismos de recuperación.
La integración es directa: las consecuencias críticas y las condiciones de escalada identificadas en Bow Tie ayudan a definir gatillos, recursos, roles, comunicación y criterios de recuperación del plan de contingencia.
Cómo conectar Bow Tie con el registro de riesgos
Bow Tie no debe existir de forma aislada. Para cada escenario relevante, el registro de riesgos puede almacenar una referencia al diagrama, owner del riesgo, clasificación inherente y residual, barreras críticas, acciones abiertas, plazos, indicadores y evidencias de verificación.
El risk register permanece como instrumento de gobernanza de la cartera de riesgos, mientras Bow Tie profundiza escenarios seleccionados. Esta separación evita convertir el registro de riesgos en un documento excesivamente detallado y, al mismo tiempo, evita que el diagrama quede sin owner o seguimiento.
Bow Tie durante diseño, obra y commissioning
La técnica puede cambiar de enfoque a lo largo del ciclo de vida.
Diseño
Durante el diseño, Bow Tie ayuda a comprobar si los requisitos y las decisiones de arquitectura crean realmente barreras adecuadas. Es útil para debatir redundancia, segregación, interlocks, criterios fail-safe, protección e independencia.
Procurement
En la contratación de equipos y sistemas, las barreras pueden depender de requisitos de desempeño, documentación, pruebas de fábrica, inspección, homologación de proveedores y capacidad de soporte. El diagrama ayuda a mostrar qué requisitos contractuales sustentan controles críticos.
Obra
Durante la implantación, el foco se desplaza hacia barreras temporales y riesgos de transición: energización parcial, trabajos simultáneos, interfaces, bypasses temporales, cambios de campo y condiciones provisionales.
Commissioning
Durante commissioning, Bow Tie puede orientar la verificación de barreras. Interlocks, alarmas, redundancias, failover, protección, lógica de control y procedimientos de respuesta pueden probarse contra los escenarios que justificaron su existencia.
Operación
En operación, el análisis pasa a depender de gestión de integridad, inspección, mantenimiento, alarmas, formación, gestión de cambios y respuesta a anomalías.
Indicadores para barreras críticas
Algunos escenarios exigen que la organización supervise la salud de las barreras. Entre los posibles indicadores se incluyen disponibilidad de sistemas de protección, porcentaje de pruebas ejecutadas dentro de plazo, cantidad de bypasses activos, fallos bajo demanda, pendientes de mantenimiento crítico, inspecciones vencidas, alarmas inhibidas y acciones de riesgo atrasadas.
El objetivo no es crear decenas de indicadores, sino identificar señales que revelen degradación antes de que el riesgo se materialice. Para barreras críticas, un indicador adelantado suele aportar más valor que limitarse a registrar incidentes ocurridos.
Cuando Bow Tie revela dependencias frágiles, barreras sin evidencia o riesgos residuales elevados, la discusión debe salir del diagrama y entrar en la decisión técnica: revisar arquitectura, requisitos, pruebas, responsabilidades o estrategia de tratamiento.
Apoye decisiones críticas con Consultoría Técnica de Ingeniería →
Errores comunes al aplicar Bow Tie
Colocar la consecuencia en el centro
Si el evento central es «incendio con pérdida total», las amenazas y las barreras quedan mezcladas. El centro debe representar la pérdida de control anterior a la consecuencia final.
Tratar procedimientos genéricos como barreras robustas
«Equipo formado» o «seguir el procedimiento» no demuestran, por sí solos, la función, independencia y eficacia de una barrera. Es necesario comprender cómo el control interrumpe la secuencia y cómo se verifica su integridad.
Contar el mismo control varias veces
Una única función dependiente del mismo sensor, lógica, fuente o persona no debe tratarse como varias barreras independientes simplemente porque aparece en documentos diferentes.
Ignorar fallos de causa común
Una redundancia aparente puede compartir alimentación, comunicación, ambiente, software, mantenimiento o procedimiento. Bow Tie debe evidenciar dependencias capaces de degradar varias barreras simultáneamente.
No revisar el diagrama después de los cambios
Los cambios de diseño, proveedor, lógica, operación, procedimiento o arquitectura pueden invalidar premisas. Bow Tie debe acompañar la gestión de cambios y el registro de riesgos.
Cuándo merece la pena utilizar Bow Tie
Bow Tie suele generar más valor cuando el riesgo es suficientemente relevante como para exigir comprensión de las barreras y comunicación entre disciplinas. Es especialmente adecuado para escenarios con múltiples amenazas, consecuencias diferentes, necesidad de demostrar controles y responsabilidad clara sobre las salvaguardas.
Para riesgos simples y de baja exposición, una matriz y un plan de acción pueden ser suficientes. Para escenarios que dependen de combinaciones lógicas complejas o requieren cuantificación, FTA, Event Tree, Monte Carlo u otras técnicas pueden ser más adecuadas.
La selección debe partir de la pregunta de decisión, no de la preferencia por la herramienta.
Consideraciones finales
Bow Tie transforma la discusión sobre riesgo en una discusión de control demostrable. La técnica organiza amenazas, pérdida de control, consecuencias, barreras preventivas y barreras mitigadoras, permitiendo visualizar dónde la arquitectura de protección es sólida, dónde depende de controles frágiles y dónde permanece un riesgo residual relevante.
En Ingeniería, el mayor valor no está en el dibujo en sí, sino en la conexión entre el diagrama y los requisitos, responsables, inspecciones, pruebas, commissioning, mantenimiento y gobernanza. Cuando cada barrera crítica posee función, owner, evidencia y mecanismo de seguimiento, Bow Tie deja de ser solo una representación y pasa a integrar el sistema real de gestión de riesgos.
Referencias técnicas
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 31010:2019 — Risk management — Risk assessment techniques. Geneva: IEC, 2019. Disponible en: https://webstore.iec.ch/en/publication/59809.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018. Disponible en: https://committee.iso.org/sites/tc262/home/projects/published/iso-31000-2018-risk-management.html.
[3] INTERNATIONAL ELECTROTECHNICAL COMMISSION. Dependability standards: risk assessment support. Geneva: IEC TC 56. Disponible en: https://tc56.iec.ch/dependability-standards/.
Preguntas frecuentes
Es una técnica que organiza amenazas, evento central, consecuencias y barreras preventivas y mitigadoras en una estructura visual orientada a escenarios.
La matriz clasifica y prioriza exposiciones; Bow Tie profundiza la lógica causal y muestra qué barreras controlan el escenario antes y después del evento central.
No. HAZOP es una técnica estructurada para el estudio de desviaciones. Bow Tie puede profundizar escenarios críticos identificados mediante HAZOP y hacer explícitas las barreras y los factores de degradación.
Es una pérdida de control relevante sobre un peligro, situada entre las amenazas que pueden provocarla y las consecuencias que pueden desarrollarse después.
La preventiva actúa antes del evento central para impedir su ocurrencia; la mitigadora actúa después del evento central para reducir propagación, severidad o probabilidad de las consecuencias.
Sí. Es útil en diseño, procurement, obra, commissioning y operación cuando riesgos relevantes dependen de barreras técnicas, administrativas u operativas que deben demostrarse y supervisarse.
Materiales técnicos complementarios
Soluciones relacionadas
- Gobernanza de Proyectos, Programas y Portafolios
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
Servicios relacionados
Contenidos principales sobre el tema
- Gestión de riesgos en proyectos de ingeniería
- Matriz de Riesgos en Proyectos de Ingeniería
- Análisis de Riesgos en Proyectos de Ingeniería
- Mitigación de Riesgos en Proyectos de Ingeniería
