Errores comunes al programar un HAZOP: diagnóstico antes de la sala de estudio

Los errores comunes al programar un HAZOP casi nunca empiezan frente al pizarrón; empiezan semanas antes, cuando la organización decide que “ya toca hacerlo” pero todavía no define bien el alcance, no ordena la documentación ni confirma quién debe estar en la mesa. Ahí es donde un estudio que debería detectar riesgos críticos termina convertido en una secuencia de reuniones con mucha asistencia y poca calidad técnica.

Esto importa para profesionales HSE de todos los niveles porque la programación de un HAZOP no es un trámite logístico: es una decisión de gestión de riesgo. Si el equipo entra con información incompleta, roles difusos y objetivos ambiguos, el resultado suele ser predecible: hallazgos superficiales, acciones débiles y una falsa sensación de control. En otras palabras, el problema no es solo que el HAZOP salga mal; el problema es que la organización cree que ya hizo “la tarea” cuando en realidad apenas la empezó.

En seguridad de procesos, los eventos severos rara vez nacen de una sola falla técnica. Casi siempre son la suma de degradación organizacional, barreras mal entendidas y decisiones apresuradas. El desastre de Texas City en 2005 dejó 15 personas fallecidas y más de 180 heridas; la investigación de la U.S. Chemical Safety Board evidenció fallas de gestión de seguridad de procesos, incluyendo uso deficiente de información crítica y debilidad en la revisión de peligros. Buncefield, en 2005, mostró que un terminal de tanques puede pasar de “operación normal” a una explosión masiva si la organización sobreestima sus protecciones y subestima el valor de revisar escenarios creíbles. La lección es incómoda pero útil: cuando la preparación es pobre, el HAZOP llega tarde.

Este artículo es fundacional porque no busca enseñarte la técnica paso a paso todavía. Busca que reconozcas síntomas de inmadurez antes de invertir tiempo, reputación y horas-hombre en un estudio que podría nacer condicionado. Si entendés qué significa realmente programar un HAZOP, vas a poder diagnosticar si tu planta está lista para hacerlo bien. Y si no lo está, vas a saber qué corregir antes de sentarte a estudiar desviaciones.

Qué significa realmente programar un HAZOP y por qué no es solo agendar reuniones

Programar un HAZOP significa diseñar las condiciones para que el estudio produzca decisiones útiles, no solamente calendarios llenos. En la práctica, eso implica definir el alcance, seleccionar nodos, reunir la documentación correcta, confirmar competencias del equipo, establecer criterios de severidad y asegurar que el estudio tenga un propósito de negocio y de seguridad de procesos alineado con el riesgo real.

La diferencia parece sutil, pero en campo no lo es. Agendar reuniones responde a una lógica administrativa: encuentro, hora, sala, invitación. Programar un HAZOP responde a una lógica de riesgo: qué proceso, con qué información, con qué expertos, bajo qué supuestos, con qué decisiones esperadas y con qué mecanismo de seguimiento. Cuando se confunden ambas cosas, el HAZOP deja de ser una herramienta de análisis y pasa a ser una ceremonia de cumplimiento.

OSHA PSM 1910.119 exige que el Process Hazard Analysis esté basado en información precisa, procedimientos vigentes y participación de personas con conocimiento del proceso. CCPS insiste en que el éxito del HAZOP depende tanto de la preparación como de la sesión misma. ISO 45001, por su parte, obliga a planificar acciones para abordar riesgos y oportunidades dentro de un sistema de gestión; eso no se logra con una invitación al calendario, sino con un proceso disciplinado de preparación. IEC 61511 también es relevante cuando el estudio toca funciones instrumentadas de seguridad, porque los supuestos de capa de protección, demanda y validación no pueden improvisarse.

En términos simples, programar bien un HAZOP es construir una plataforma de decisión. Eso incluye definir qué documentos son fuente única de verdad, qué brechas se aceptan y cuáles bloquean el estudio, cómo se manejarán los cambios pendientes, quién aprueba el alcance y cómo se cerrarán acciones. Si eso no existe, el estudio se apoya en arena.

Errores comunes al programar un HAZOP: dónde falla la organización

Los errores comunes al programar un HAZOP se repiten en casi cualquier industria: minería, oil & gas, química, alimentos, energía o terminales logísticos. Cambia la escala, pero no la lógica. La raíz suele ser la misma: la organización cree que el estudio empieza en la sala, cuando en realidad empieza en la calidad de su preparación.

1. Error 1: Confundir urgencia con preparación. Se convoca el HAZOP porque “lo pide la auditoría” o porque hay que liberar un proyecto. Consecuencia: se acorta el trabajo previo, el equipo entra con documentos desactualizados y el análisis queda sesgado por premura.
2. Error 2: No congelar el alcance. Si los límites del nodo cambian durante el estudio, el grupo pierde consistencia. Consecuencia: aparecen decisiones contradictorias, duplicación de escenarios y una cantidad de acciones que nadie puede priorizar.
3. Error 3: Armar el equipo por disponibilidad y no por competencia. Un HAZOP sin operación, mantenimiento, instrumentación, proceso y facilitación sólida no ve las mismas fallas que ve un equipo completo. Consecuencia: se subestiman desviaciones de rutina, by-passes, alarmas permanentes y vulnerabilidades humanas.
4. Error 4: Llegar sin paquete documental robusto. P&IDs, filosofía de control, listas de alarmas, inventario de salvaguardas, historial de incidentes, MOC pendientes y datos de diseño deben estar listos. Consecuencia: el equipo rellena vacíos con supuestos; eso no es análisis, es conjetura.
5. Error 5: No definir reglas de decisión y cierre. Si no existe criterio sobre severidad, aceptabilidad, priorización y seguimiento, el estudio produce una montaña de hallazgos sin dueño. Consecuencia: el HAZOP se vuelve un archivo histórico, no un mecanismo de reducción de riesgo.

El problema no es solamente técnico. Es de disciplina operativa. Cuando una planta no puede preparar bien un HAZOP, normalmente tampoco puede gestionar bien otros elementos del sistema: MOC, integridad mecánica, procedimiento operativo o aprendizaje de incidentes. Por eso este diagnóstico importa tanto: el modo en que programás un HAZOP revela el nivel real de madurez de tu organización.

Un HAZOP no debería medir cuánto tiempo pueden sentarse las personas en una sala, sino cuánto sabe la organización sobre su propio proceso antes de analizarlo.

Contexto y marco técnico para evaluar madurez antes del HAZOP

Desde el enfoque de seguridad de procesos, la programación del HAZOP es una etapa de “readiness” o alistamiento. No se trata de completar una checklist administrativa; se trata de verificar si existen las condiciones mínimas para que el estudio sea confiable, trazable y accionable. En términos de PSM, eso incluye información de proceso, procedimientos, entrenamiento, integridad mecánica, investigación de incidentes y gestión del cambio.

La madurez organizacional se puede leer en tres capas. La primera es la capa de información: documentos vigentes y trazables. La segunda es la capa de competencia: personas que entienden el proceso y saben detectar desviaciones reales. La tercera es la capa de gobernanza: criterios claros para decidir qué se acepta, qué se corrige y quién responde. Si una de esas capas falla, el estudio pierde valor.

API 754 ayuda a pensar en indicadores de desempeño de seguridad de procesos, incluyendo indicadores líderes y rezagados. Aunque no fue creado para HAZOP específicamente, su lógica sirve para evaluar preparación: si la organización no tiene datos confiables de acciones abiertas, eventos de proceso, alarmas recurrentes o vencimientos de acciones, difícilmente podrá sostener un HAZOP de alta calidad. CCPS recomienda precisamente usar información histórica y participación multidisciplinaria para evitar el sesgo de “estudio de escritorio”.

IEC 61511 también aporta una advertencia importante: si el HAZOP toca capas instrumentadas de seguridad, no alcanza con decir que “el SIS existe”. Hay que entender demanda, independencia, prueba, bypass y credibilidad de la función. Muchos estudios fallan porque la programación no incluye al especialista correcto, o porque se asume que la salvaguarda existe sin validar su estado real. En la práctica, eso puede convertir una capa de protección en una ilusión documental.

ISO 45001, aunque más amplia, refuerza una idea clave: planificar con contexto. Si la planta está en arranque, parada mayor, transición de contratistas o cambio de tecnología, el momento de ejecutar un HAZOP puede requerir una preparación más rigurosa, no menos. Eso también aplica a terminales con alta rotación, plantas con turnos nocturnos complejos y operaciones con mucha intervención manual.

Análisis profundo con casos: cuando la programación falla antes de empezar

Caso 1: Texas City, 2005 — cuando la organización dejó de ver lo obvio

Situación: Durante el arranque de la unidad de isomerización en la refinería de BP en Texas City, una secuencia de operación inestable llevó a un sobrellenado y una liberación masiva de hidrocarburos. El evento terminó en una explosión y múltiples incendios. Hubo 15 fallecidos, más de 180 lesionados y un impacto económico y reputacional enorme para la empresa y la industria.

Problema: La investigación mostró debilidades estructurales en seguridad de procesos: procedimientos pobres, entrenamiento insuficiente, gestión deficiente de riesgos y uso limitado de información crítica para decidir. Aunque no fue un caso “de HAZOP” en sentido estricto, ilustra el mismo patrón: si la preparación de un análisis de riesgo se hace sin información completa ni cuestionamiento real, el sistema no ve sus propias vulnerabilidades.

Consecuencia: La planta operó durante años con señales de alerta normalizadas. Las decisiones se tomaban sobre supuestos de disponibilidad y estabilidad que no reflejaban la realidad. En otras palabras, la organización había confundido continuidad operativa con control de riesgo.

Lección: Un HAZOP bien programado obliga a reexaminar el proceso, pero solo si llega con datos, competencia y autoridad para decir “esto no está listo”. Si el estudio se programa para cumplir fecha, no para reducir riesgo, el sesgo de confirmación domina la sala. Y cuando eso pasa, el HAZOP deja de ser prevención y se vuelve documentación de la inercia.

Caso 2: Buncefield, 2005 — la falsa certeza de que “eso no puede pasar”

Situación: En el terminal de almacenamiento de Buncefield, Reino Unido, un sobrellenado de tanque de gasolina generó una nube de vapor que explotó. No hubo fatalidades, pero sí más de 40 personas heridas, alrededor de 2.000 evacuados y daños estimados en más de mil millones de libras esterlinas. Fue uno de los accidentes industriales más significativos de Europa.

Problema: El evento expuso una combinación de fallas técnicas y organizacionales: dependencia excesiva de una sola salvaguarda, comprensión incompleta del escenario de sobrellenado y señales de gestión insuficiente del riesgo mayor. En términos de programación de HAZOP, esto se traduce en una pregunta incómoda: ¿estaba el equipo preparado para desafiar sus supuestos o solo para confirmar que el sistema era “seguro en condiciones normales”?

Consecuencia: La organización subestimó la probabilidad de una desviación aparentemente simple. Esa es precisamente la trampa de los HAZOP mal programados: si no se reúnen las disciplinas correctas y no se revisa la realidad operacional, los escenarios más obvios se vuelven invisibles.

Lección: El HAZOP debe empezar con una exploración seria de cómo opera realmente la instalación, no cómo debería operar en los manuales. Si no se incluyen alarmas recurrentes, intervenciones manuales, by-passes temporales, degradación de instrumentos y hábitos del turno, el estudio termina ignorando el sistema socio-técnico que produce el riesgo.

En ambos casos, el aprendizaje es el mismo: el riesgo no aparece porque faltó una reunión. Aparece porque la organización no estaba preparada para preguntarse con honestidad qué podía salir mal. Esa honestidad técnica es la que un buen programa de HAZOP debe instalar antes de empezar.

Diagnóstico: cómo saber si tu organización está lista para un HAZOP formal

Antes de poner fecha, vale la pena mirar señales de alerta. Un buen diagnóstico no busca culpar a nadie; busca entender si el sistema tiene condiciones de lectura técnica. Si varias de estas señales están presentes, el equipo debería frenar, corregir y recién después estudiar.

• Hay P&IDs o diagramas de proceso con revisiones distintas entre áreas.
• El alcance del HAZOP cambia cada vez que alguien pregunta “qué cubre exactamente”.
• Los contratistas, operadores o mantenedores que conocen los desvíos reales no fueron convocados.
• Existen MOC abiertos que afectan el proceso, la instrumentación o los procedimientos.
• Las alarmas de campo, los by-passes o las intervenciones manuales no están documentados.
• No hay criterios claros para priorizar hallazgos ni dueño definido para cerrar acciones.
• El estudio se programa por fecha de auditoría, no por disponibilidad de información.
• El facilitador también tiene responsabilidad directa sobre el diseño, lo que puede sesgar el análisis.

Si sos director, la pregunta clave es si el HAZOP está gobernado como un proceso de negocio o como una actividad administrativa. Si sos mando medio, preguntate si tu equipo tiene insumos reales para identificar escenarios creíbles o solo está “cumpliendo”. Si sos operador, fijate si lo que se discute refleja el turno, el arranque, las maniobras manuales y los desvíos que vos ves todos los días.

Una forma práctica de diagnosticar madurez es revisar cuatro indicadores simples: calidad del paquete documental, estabilidad del alcance, representatividad del equipo y claridad del seguimiento. Si esos cuatro elementos no están, el estudio arranca débil. Y cuando arranca débil, casi siempre termina costoso.

Solución y metodología para preparar un HAZOP con criterio

La solución no es hacer más reuniones; es instalar un método de alistamiento. El objetivo es que el HAZOP llegue a sala con una base de información suficiente para pensar, no para improvisar. Eso se puede lograr con pasos concretos y relativamente simples si la organización acepta que primero hay que preparar, luego estudiar.

El primer paso es definir un gate de madurez. Ese gate responde preguntas objetivas: ¿está congelado el alcance?, ¿están los documentos críticos vigentes?, ¿hay representantes de operación, mantenimiento, ingeniería, instrumentación y HSE?, ¿existen cambios abiertos que alteren la base de diseño?, ¿el facilitador está habilitado y no tiene conflicto de rol? Si la respuesta a dos o más de esas preguntas es “no”, el estudio no debería empezar todavía.

El segundo paso es construir un paquete pre-HAZOP. Ese paquete debe incluir la versión más reciente de P&IDs, PFDs, listas de equipos, filosofía de control, inventario de salvaguardas, información de SIS si aplica, historial de incidentes y casi incidentes, alarmas críticas, registros de MOC y lecciones aprendidas. Si falta algo, se registra como brecha, no como supuesto.

El tercer paso es validar el equipo correcto. No alcanza con invitar gente “que sabe”. Hay que asegurar diversidad funcional y autoridad técnica. En plantas con alta complejidad, también conviene incluir experiencia de turno, alguien de mantenimiento de instrumentación, un representante de proceso y, cuando corresponde, una mirada de confiabilidad o integridad mecánica.

El cuarto paso es acordar reglas de decisión. Qué se considera salvaguarda independiente, cómo se maneja una acción temporal, cuándo un escenario exige rediseño, cómo se prioriza por severidad y probabilidad, y qué evidencia se necesita para cerrar. Sin eso, cada nodo se interpreta distinto y la trazabilidad se pierde.

El quinto paso es incorporar aprendizaje operativo. Ahí es donde el HAZOP deja de ser genérico y se vuelve útil. Los incidentes menores, los desvíos rutinarios, las alarmas de alto nivel, los by-passes y los trabajos de mantenimiento repetidos cuentan una historia que la ingeniería de escritorio muchas veces no ve. El HAZOP bueno escucha esa historia.

Quick wins: congelar alcance, revisar documentos críticos, confirmar participantes y cerrar MOC que afecten el nodo. Cambios estructurales: crear una gobernanza formal del HAZOP, entrenar facilitadores, conectar acciones con el sistema de gestión y usar indicadores de preparación, no solo de cierre. En organizaciones con brechas de madurez, un Diagnóstico Digital puede ayudar a ver dónde están las debilidades en PSM, disciplina operativa y competencias antes de invertir horas de estudio.

Si querés llevar este método al siguiente nivel, el paso a paso completo está desarrollado en Cómo evitar 5 errores al programar un HAZOP paso a paso. Y si además querés profundizar en lectura de madurez y aprendizaje organizacional, te recomiendo Lecciones avanzadas sobre 5 errores en un HAZOP exitoso.

Aplicación práctica en el día a día

En la práctica, la calidad de la programación se gana en pequeñas decisiones diarias. Para HSE, eso significa revisar antes el estado de la documentación, empujar el cierre de brechas y no aceptar como “listo” lo que todavía depende de supuestos. Para supervisión, significa verificar en campo si lo que dice el documento coincide con lo que el turno realmente hace.

Si trabajás en operación, tu aporte no es decorar la reunión; es traer la verdad del terreno. ¿Qué alarmas están silenciadas?, ¿qué valvulería se opera manualmente más de lo que debería?, ¿qué bypass ya dejó de ser temporal?, ¿qué maniobras son normales pero nunca quedaron bien escritas? Ese tipo de información cambia el análisis.

Si estás en gerencia o coordinación, tu decisión más importante es no premiar la velocidad por encima de la calidad. Un HAZOP bien programado puede demorar más al inicio, pero reduce retrabajo, acciones mal planteadas y riesgo residual mal entendido. Eso tiene retorno: menos sorpresas, menos cambios tardíos y mejor priorización de inversiones.

Herramientas útiles para el día a día: checklist de readiness, matriz RACI del estudio, tablero de acciones con vencimiento, lista de MOC abierta, registro de lecciones aprendidas, y una reunión corta previa de alineación con operación, mantenimiento e ingeniería. Si la organización trabaja por turnos, conviene validar que la información de noche, fines de semana y arranques no quede fuera. Ahí suelen esconderse los riesgos más caros.

FAQ breve

¿Programar un HAZOP es lo mismo que convocarlo?

No. Convocar es una actividad logística; programar es diseñar las condiciones técnicas y organizacionales para que el estudio funcione. Si solo hay fecha y sala, pero no hay alcance congelado, documentos vigentes ni equipo competente, todavía no está programado de verdad. El HAZOP necesita preparación, no solo calendario.

¿Cuánto tiempo debería llevar la preparación?

Depende de la complejidad del proceso y de la madurez documental. En unidades sencillas puede requerir pocas semanas; en plantas complejas, con cambios abiertos o documentación inconsistente, puede requerir más tiempo. La clave no es “hacerlo rápido”, sino llegar con suficiente calidad para evitar retrabajo y conclusiones débiles.

¿Qué pasa si faltan P&IDs o información crítica?

Lo correcto es tratarlo como una brecha de preparación y no como un detalle menor. El equipo puede decidir postergar el nodo afectado, limitar el alcance o generar una acción previa de saneamiento documental. Hacer el estudio con información dudosa empuja al grupo a suposiciones y debilita todo el análisis.

¿Quién debería participar en la programación?

Además del facilitador y HSE, deberían participar operación, mantenimiento, ingeniería de proceso, instrumentación cuando aplique y, si el caso lo exige, confiabilidad o integridad mecánica. La regla es simple: quien conoce el proceso real debe estar en la mesa. Si no, el estudio corre el riesgo de ignorar desvíos que solo aparecen en campo.

¿Cómo sé si mi equipo está listo para empezar?

Revisá cuatro señales: documentos críticos vigentes, alcance congelado, equipo competente confirmado y reglas de decisión acordadas. Si esos cuatro puntos están verdes, hay base para arrancar. Si uno o más están en amarillo o rojo, conviene corregir antes de iniciar. Esa pausa suele ahorrar tiempo y calidad a la vez.

¿Un HAZOP puede salir mal aunque el facilitador sea bueno?

Sí. Un facilitador sólido mejora mucho el proceso, pero no puede compensar una mala preparación organizacional. Si la documentación está incompleta, el alcance cambia o faltan especialistas clave, el mejor facilitador solo administrará mejor el problema. Por eso la preparación es un tema de sistema, no de carisma individual.

Cierre

La principal idea de este artículo es simple: la mayoría de los errores comunes al programar un HAZOP no son errores de la sala, sino del sistema que llega a ella. Cuando la organización prepara bien, el estudio encuentra riesgos reales, prioriza mejor y genera acciones útiles. Cuando prepara mal, el HAZOP se vuelve una formalidad costosa.

Si querés transformar el HAZOP en una herramienta de decisión y no en una reunión extensa, primero tenés que diagnosticar madurez. Ese diagnóstico te dice si estás listo para estudiar o si todavía estás acomodando la base documental, la gobernanza y las competencias. Y si detectás brechas, mejor corregirlas antes que inventar certeza.

Este es apenas el primer paso de la serie. En el siguiente artículo vas a ver el método operativo para evitar estos errores paso a paso, y más adelante vamos a profundizar en lecciones avanzadas para llevar el estudio a un nivel realmente sólido. Si ya identificaste que tu organización necesita ordenar la base, te conviene leer después cómo evitar 5 errores al programar un HAZOP paso a paso y luego las lecciones avanzadas sobre 5 errores en un HAZOP exitoso. Ahí empieza la parte más práctica del camino.