WHAT IF: ¿Qué preguntar? Estructura causal o todos hacen preguntas distintas

Si tu WHAT IF termina con cada persona preguntando algo distinto, no estás haciendo análisis de riesgos: estás coleccionando opiniones. La diferencia entre una sesión útil y una sesión decorativa es simple: una estructura causal que ordene qué preguntar, en qué secuencia y con qué criterio verificar. En seguridad de procesos, eso no es un lujo metodológico; es la línea entre detectar una desviación a tiempo o repetir la receta de Texas City 2005.

La pregunta central no es si el equipo tiene intención. La pregunta es si el método produce hallazgos accionables. Y eso importa operativamente porque en planta el tiempo es limitado, los sesgos abundan y las barreras fallan de manera silenciosa. Según OSHA, las instalaciones cubiertas por PSM deben asegurar análisis de riesgos de proceso y su actualización periódica; pero cumplir con el trámite no garantiza que el análisis vea la realidad del sistema. Un WHAT IF sin estructura causal puede dejar fuera el evento top, las causas latentes y la degradación de barreras críticas.

En la práctica, esto se traduce en recomendaciones vagas, acciones que no atacan la causa raíz y una falsa sensación de control. API 754 ya nos recuerda que los indicadores líderes y rezagados tienen que reflejar desempeño real, no solo papel. IEC 61511, por su parte, exige disciplina en el ciclo de vida de la seguridad funcional, porque un SIS no se diseña sobre intuiciones sino sobre escenarios y capas de protección. El problema es que muchas organizaciones siguen usando el WHAT IF como una conversación abierta sin taxonomía causal, sin guía de preguntas y sin criterio de cierre. El resultado es predecible: riesgo invisible, priorización errónea y aprendizaje superficial.

Este artículo te muestra cómo pasar de preguntas sueltas a una estructura causal verificable, cómo distinguir entre preguntas buenas y preguntas decorativas, y cómo convertir el WHAT IF en una herramienta seria de gestión de riesgos. Te lo digo directo: si no controlás la calidad de la pregunta, no controlás la calidad del análisis.

¿Qué es un WHAT IF en gestión de riesgos y por qué se usa mal?

El método What If es una técnica de análisis semiestructurado basada en preguntas hipotéticas del tipo “¿qué pasa si...?” para identificar desviaciones, causas, consecuencias y salvaguardas. Su valor está en la velocidad y en la flexibilidad. Su límite está en la dependencia del criterio del equipo. Por eso funciona bien cuando hay una guía causal clara y falla cuando cada participante improvisa desde su experiencia parcial.

La definición formal lo presenta como una herramienta cualitativa de identificación de peligros. La definición operativa, la que importa en campo, es esta: un What If es útil solo si transforma una duda abierta en una cadena causal verificable. Si no hay cadena causal, lo que obtenés son comentarios dispersos: uno pregunta por corrosión, otro por procedimiento, otro por capacitación, y nadie conecta el desvío con el evento top.

El problema de fondo no es el método en sí. El problema es el uso amateur del método. En muchas plantas, el análisis se convierte en una ronda de opiniones donde domina quien habla más fuerte o conoce más historia del activo. Eso sesga la discusión hacia lo visible, no hacia lo crítico. El CCPS insiste en que la identificación de peligros debe estar alineada con escenarios creíbles y barreras; no con una lluvia de ideas sin gobierno técnico. La disciplina operativa existe justamente para evitar que el análisis dependa del humor del día.

Definición formal vs. definición operativa

¿Por qué los enfoques tradicionales no funcionan?

Porque muchas organizaciones confunden reunión con método. Un análisis serio necesita un criterio de secuencia, un lenguaje común y un cierre verificable. Sin eso, el equipo salta entre causas humanas, fallas mecánicas, fallas de procedimiento y condiciones de diseño sin ordenar el razonamiento. Es como abrir una caja de herramientas y esperar que salga una solución solo por tener herramientas caras.

Además, hay una trampa cognitiva: la gente tiende a hablar de lo que conoce mejor. Mantenimiento habla de equipos, operación habla de rutina, ingeniería habla de diseño, y HSE habla de cumplimiento. Pero el riesgo real está en la interacción. En Piper Alpha 1988 no falló una sola cosa; falló un sistema de permisos, comunicación, aislamiento, conocimiento y barreras. En Texas City 2005 no fue “error humano” a secas; fue una acumulación de desviaciones, alarmas ignoradas, instrumentos mal comprendidos y una cultura que normalizó la desviación. Un WHAT IF útil tiene que obligar a mirar esa cadena, no un solo punto.

Cómo evolucionó el pensamiento en la industria

La industria pasó de checklists genéricas a métodos más estructurados: HAZOP, FMEA, BowTie, LOPA y técnicas de análisis causal. El What If quedó como una opción liviana para cambios menores, equipos simples o etapas tempranas. Pero en muchas organizaciones se lo usa por conveniencia para todo, incluyendo modificaciones complejas. Ahí se rompe.

La evolución correcta es esta: primero identificar el activo o cambio, después definir el nivel de profundidad necesario y finalmente escoger la herramienta. Si el cambio impacta inventario, energía, toxicidad o secuencias de control, el análisis no puede ser una charla informal. OSHA PSM 1910.119 exige gestión del cambio, integridad mecánica, entrenamiento y análisis de peligros apropiado. ISO 45001 pide control operacional y mejora continua. IEC 61511 exige rigor cuando hay funciones instrumentadas de seguridad. Todo apunta a lo mismo: si el escenario es complejo, la pregunta también debe serlo.

¿Qué pregunta una buena estructura causal en un What If?

Una buena estructura causal pregunta en cuatro niveles: desviación, mecanismo causal, consecuencia y barrera. Si falta cualquiera de estos, el análisis queda incompleto. La clave es que la pregunta no sea solo hipotética sino trazable. Por ejemplo, “¿Qué pasa si se abre la válvula equivocada?” es útil solo si sigue con “¿qué condiciones lo hacen posible?”, “¿qué flujo o energía liberás?”, “¿qué falla o daño produce?” y “¿qué barreras lo previenen o mitigan?”.

Ese orden evita que cada participante haga preguntas distintas. También reduce la discusión circular. En vez de debatir si el operador estaba distraído, el equipo analiza qué señal, estándar de trabajo, codificación, interfaz, permiso o verificación falló. Eso no elimina el factor humano; lo ubica en su contexto sistémico.

La pregunta correcta no busca culpables. Busca entender por qué el sistema permitió que una desviación se transformara en daño.

Tabla comparativa: What If improvisado vs. What If estructurado

Análisis profundo con casos: dónde se rompe el método y cómo se corrige

Caso 1: Refinería, cambio de alineación y preguntas sin secuencia

En una refinería de la costa del Golfo, durante la preparación para una transferencia de producto caliente, el equipo hizo un What If sobre la nueva configuración de válvulas después de un mantenimiento. El activo era una línea de 8 pulgadas, temperatura normal de operación 135 °C, presión de 6,5 bar, con riesgo de sobrepresión por bloqueo y vapor atrapado. El equipo reunió a operación, mantenimiento e inspección, pero no usó guía causal. Resultado: cada uno preguntó algo distinto.

Operación se enfocó en “¿y si el operador se equivoca?”. Mantenimiento preguntó “¿y si la válvula no cierra?”. Inspección preguntó por corrosión. Nadie conectó que la secuencia de cambio, el etiquetado de la línea temporal y la ausencia de verificación independiente podían llevar a una apertura cruzada entre producto caliente y drenaje. El evento no ocurrió ese día, pero sí dos meses después: ingreso no intencional de hidrocarburo a un punto no previsto, derrame menor de unos 80 litros, paro de 3 horas y limpieza, costo estimado interno superior a 18.000 dólares, sin lesión pero con exposición seria al potencial de ignición.

La lección fue brutalmente simple: el análisis no había construido el escenario. Había coleccionado temores. Al rearmarlo con estructura causal, surgieron seis preguntas estándar: ¿qué desviación inicial se introduce?, ¿qué condición permite la desviación?, ¿qué energía o material se libera?, ¿cuál es el evento top?, ¿qué barreras lo previenen?, ¿qué barreras mitigan? En dos sesiones posteriores aparecieron hallazgos que antes no estaban: señalización ambigua, ausencia de doble verificación en un cambio temporal y una práctica local de “dejar la válvula casi abierta para ahorrar tiempo”. Ese último punto no era mala fe; era normalización de la desviación.

Caso 2: Mantenimiento, permiso de trabajo y datos cuantitativos

En una planta química con 420 trabajadores contratistas durante el pico de parada anual, se evaluó un What If sobre ingreso a equipo para cambio de empaque en una bomba centrífuga con fluido inflamable. El problema no era técnico solamente; era de coordinación. En el año previo se registraron 17 desviaciones en permisos de trabajo, 9 por aislamiento incompleto y 5 por verificación insuficiente de energía cero. El equipo quería responder si “había capacitación suficiente”, pero esa pregunta no ayudaba a controlar el riesgo. Lo que hacía falta era una estructura causal sobre liberación de energía residual, aislamiento, bloqueo-etiquetado y verificación de atmósfera.

Al usar preguntas estructuradas, se identificó que el plano de aislamiento no distinguía claramente entre válvulas de bloqueo y válvulas de proceso con fuga histórica. Además, el checklist de arranque se firmaba por turno, no por actividad. En una muestra de 30 permisos auditados, solo 19 tenían evidencia completa de prueba de cero energía. Eso es un 63%. Para una tarea con potencial de liberación de hidrocarburos, ese nivel de cumplimiento no es aceptable aunque “nadie se haya accidentado”.

La consecuencia potencial incluía incendio, exposición a vapores y atrapamiento mecánico. La acción que resultó del análisis no fue “reentrenar a todos”. Fue mucho más concreta: rediseñar el aislamiento con identificación visual, exigir verificación independiente antes de intervenir, y establecer un punto de hold para revisar el permiso entre operación y mantenimiento. En 60 días bajaron a cero las desviaciones críticas reportadas en ese paquete de trabajo y la auditoría interna mostró 94% de permisos con evidencia completa. Eso sí es un indicador líder real.

Caso 3: Organización que lo hizo bien

Una empresa de tratamiento de gas en América Latina implementó una estructura causal para What If en cambios menores de proceso y encontró un patrón repetido: los equipos proponían preguntas distintas según su área. Ingeniería preguntaba por diseño, operación por secuencia, mantenimiento por repuestos y HSE por cumplimiento. En vez de prohibir esa diversidad, la organización la ordenó. Adoptó una plantilla de cinco pasos: desviación, causa iniciadora, condición contribuyente, consecuencia y barrera.

El resultado fue medible. En seis meses, el tiempo promedio de cierre de recomendaciones pasó de 47 días a 28 días, no porque trabajaran más rápido sino porque las acciones eran más precisas. Además, el porcentaje de recomendaciones rechazadas por “no aplica” cayó de 22% a 8%. Eso indica mejor calidad en el análisis, no solo mayor velocidad. También se redujeron las repeticiones de hallazgos entre sesiones, porque el equipo dejó de preguntar lo obvio y empezó a preguntar lo causalmente relevante.

Cuando el método ordena la conversación, la experiencia del equipo deja de competir y empieza a sumar.

Ese es el punto que muchas organizaciones no ven: una estructura causal no limita la participación; la hace productiva. Permite que la voz de operación, mantenimiento e ingeniería converjan sobre el mismo escenario. Eso mejora la calidad técnica y también la legitimidad interna del resultado.

¿Qué dicen los estándares y por qué te deberían importar?

Los estándares no sustituyen el juicio técnico, pero sí marcan el piso mínimo de disciplina. OSHA 1910.119 exige análisis de peligros de proceso, integridad mecánica, procedimientos, capacitación y gestión del cambio. No dice “hagan reuniones”. Dice que el sistema debe identificar, evaluar y controlar peligros asociados a sustancias altamente peligrosas. IEC 61511 estructura el ciclo de vida de seguridad funcional para SIS, desde la especificación de requisitos hasta la verificación, operación y modificación. Eso implica escenarios, capas y desempeño verificable.

ISO 45001 pide identificación de peligros, evaluación de riesgos y determinación de controles, con mejora continua y participación de los trabajadores. API 754 ofrece una lógica de indicadores de seguridad de procesos para mirar desempeño real más allá de la simple ausencia de accidentes. Y las guías CCPS insisten en identificar escenarios creíbles y robustecer barreras. El mensaje es consistente: el control efectivo del riesgo depende de la calidad del análisis, no de la cantidad de formularios.

Lo que estos estándares implican para un What If

• OSHA PSM: el análisis debe ser apropiado para el proceso y el cambio, no genérico.
• IEC 61511: si hay funciones instrumentadas de seguridad, el escenario debe estar claramente definido.
• ISO 45001: los controles deben ser operacionales, no declarativos.
• API 754: medir sin entender escenarios lleva a indicadores decorativos.
• CCPS: la calidad del análisis depende de la disciplina metodológica y la verificación de barreras.

Diagnóstico: ¿cómo saber si tu organización tiene este problema?

Hay señales que no mienten. Si en tu planta un What If termina con 30 preguntas y ninguna conclusión clara, ya tenés el síntoma. Si las preguntas cambian según quién dirige la reunión, también. Si las recomendaciones son “reforzar capacitación”, “revisar procedimiento” o “sensibilizar al personal” sin especificar causa, barrera y verificación, estás ante un análisis débil. Y si nadie puede demostrar qué escenario quedó cubierto y cuál no, entonces no hay trazabilidad técnica.

Señales de alerta

• Las sesiones duran mucho, pero generan pocas acciones específicas.
• Se confunde brainstorming con análisis causal.
• Las preguntas dependen del estilo del facilitador.
• No se documenta la cadena desviación-causa-consecuencia-barrera.
• Las recomendaciones se repiten en distintos cambios.
• Los operadores sienten que “ya saben cómo se hace” y no verifican nada.
• El cierre del análisis se basa en consenso, no en evidencia.

Preguntas de autoevaluación

1. ¿Mis equipos usan la misma secuencia de preguntas o cada uno improvisa?
2. ¿Puedo explicar por qué un escenario quedó cubierto y otro no?
3. ¿Las acciones se vinculan a una causa específica o son genéricas?
4. ¿Tengo evidencia de que las barreras críticas realmente funcionan?
5. ¿La participación de operación, mantenimiento e ingeniería converge o compite?

Tabla de madurez

Metodología: cómo estructurar un What If causal y verificable

Te propongo un método simple, pero serio. No es teoría bonita; es ejecución disciplinada. El objetivo es que cualquier equipo pueda usarlo y llegar a resultados consistentes. Si el análisis cambia mucho según quién lo facilite, el problema no es la gente: es el método.

Paso 1: Definí el alcance y el evento top

Qué hacer: describí el activo, el cambio, la tarea y el evento no deseado máximo razonable. Cómo verificar: el equipo debe poder repetir el alcance en una frase. Error común: empezar con preguntas antes de definir el escenario.

Paso 2: Ordená las preguntas en cadena causal

Qué hacer: usá la secuencia desviación → causa iniciadora → condición contribuyente → consecuencia → barrera. Cómo verificar: cada pregunta debe llevar a una respuesta observable o comprobable. Error común: saltar directamente a “capacitación” o “procedimiento”.

Paso 3: Identificá barreras existentes y su desempeño

Qué hacer: registrá prevención, detección y mitigación. Cómo verificar: cada barrera debe tener dueño, frecuencia de prueba y criterio de fallo. Error común: listar controles que nadie prueba.

Paso 4: Priorizá por credibilidad y severidad

Qué hacer: clasificá escenarios por frecuencia razonable y consecuencia. Cómo verificar: la priorización debe ser consistente entre sesiones. Error común: dejar que el miedo o la jerarquía definan la prioridad.

Paso 5: Cerrá con acciones verificables

Qué hacer: convertí cada hallazgo en una acción con responsable, plazo y evidencia esperada. Cómo verificar: que la acción reduzca exposición, probabilidad o severidad. Error común: usar acciones blandas que no cambian el sistema.

Quick wins y cambios estructurales

• En 30 días: usar una plantilla única, capacitar facilitadores y eliminar preguntas redundantes.
• En 60 días: vincular el What If con MOC y permisos de trabajo.
• En 6-12 meses: integrar la estructura causal con BowTie, indicadores API 754 y verificación de barreras críticas.

Si el cambio no mejora la trazabilidad del riesgo, no es mejora: es decoración metodológica.

¿Cómo implementarlo en el turno, en la planta y en la organización?

La implementación no se hace en PowerPoint. Se hace en turno, con supervisores, operadores y mantenimiento usando herramientas simples. La clave es bajar la estructura causal al trabajo real. Un buen formato debe caber en una hoja o en una pantalla de tablet, con campos para desviación, causa, consecuencia, barrera, evidencia y acción.

Herramientas necesarias

• Plantilla estándar de What If causal.
• Checklist de verificación de barreras.
• Matriz de criticidad de escenarios.
• Registro de acciones con responsable y fecha.
• Lecciones aprendidas vinculadas a cambios previos.

Roles y responsabilidades

• Facilitador: mantiene la secuencia y evita digresiones.
• Operación: valida cómo se ejecuta realmente la tarea.
• Mantenimiento: aporta condición mecánica, aislamiento y degradación.
• Ingeniería: verifica diseño, interlocks y filosofía de control.
• HSE/PSM: asegura trazabilidad, cierre y gobernanza.

Indicadores de seguimiento

• Porcentaje de análisis con cadena causal completa.
• Porcentaje de barreras con dueño y prueba definida.
• Tasa de recomendaciones repetidas.
• Tiempo de cierre de acciones críticas.
• Porcentaje de sesiones con facilitador competente.

Cómo manejar la resistencia al cambio

La resistencia aparece cuando el equipo siente que le agregás burocracia. La respuesta no es insistir con discurso; es mostrar que el método ahorra tiempo y evita retrabajo. Cuando una organización ve que baja el porcentaje de acciones rechazadas y sube la calidad de los escenarios, la resistencia cae sola. También ayuda comparar sesiones antiguas y nuevas con casos concretos. La evidencia convence más que la consigna.

Preguntas frecuentes sobre WHAT IF y estructura causal

Muchos profesionales buscan respuestas rápidas a dudas muy concretas. Acá van las más comunes, con enfoque práctico y técnico.

¿Cuándo conviene usar What If y no HAZOP?

Conviene usar What If cuando el cambio o proceso es relativamente simple, el objetivo es identificar desviaciones plausibles y se dispone de un equipo multidisciplinario que puede seguir una estructura causal. HAZOP suele ser mejor cuando hay complejidad alta, múltiples nodos, interacciones de proceso y necesidad de mayor exhaustividad. En otras palabras: si el escenario tiene muchas variables acopladas, What If puede quedarse corto. Si lo usás, hacelo con disciplina y no como charla libre.

¿Qué preguntas debe incluir un What If bien hecho?

Debe incluir preguntas sobre desviación inicial, causa que la habilita, condición contribuyente, consecuencia y barrera. Por ejemplo: “¿Qué pasa si la válvula queda en posición intermedia?”, “¿qué hace posible ese error?”, “¿qué energía o material se libera?”, “¿qué daño genera?” y “¿qué control lo previene o mitiga?”. Esa secuencia obliga a pensar causalmente y evita que el equipo se disperse en opiniones no conectadas.

¿Cómo saber si una recomendación de What If es buena?

Una buena recomendación reduce la exposición al escenario identificado, mejora una barrera específica y puede verificarse con evidencia. Si la recomendación dice “capacitar al personal” sin especificar qué conducta, en qué paso y con qué criterio de éxito, es débil. En cambio, “instalar bloqueo físico y verificación independiente antes de abrir la línea” es concreta, medible y conectada con la causa del riesgo.

¿Se puede usar What If para gestión del cambio?

Sí, y de hecho debería integrarse con MOC cuando el cambio es menor o intermedio y no justifica una técnica más pesada. Pero el peligro es usarlo como trámite. En gestión del cambio, la estructura causal es clave para entender qué nueva desviación puede introducir el cambio y qué barreras se degradan. Sin esa lógica, el MOC queda administrativo. Con esa lógica, se vuelve preventivo.

¿Qué error más común cometen los facilitadores?

El error más común es aceptar preguntas sueltas sin volver al evento top. Otro error es dejar que la reunión se convierta en un intercambio de historias pasadas. Eso puede aportar contexto, pero no reemplaza el análisis. El facilitador debe cuidar la secuencia, pedir evidencia cuando corresponda y cerrar cada escenario con barreras y acciones verificables. Si no controla eso, el método pierde valor técnico.

Cierre: por qué la calidad de la pregunta define la calidad del riesgo

La seguridad industrial viene madurando desde la era del cumplimiento hacia la era de la verificación. Ya no alcanza con decir que se hizo un análisis; hay que demostrar que el análisis vio lo importante. En ese contexto, el WHAT IF sigue siendo útil, pero solo si deja de ser una conversación abierta y se convierte en una estructura causal disciplinada. La pregunta no es si el equipo participó. La pregunta es si el equipo entendió el sistema.

Los incidentes mayores de la industria nos enseñan lo mismo una y otra vez: el daño no aparece de la nada. Se construye por capas de debilidad, normalización de desvíos, barreras no verificadas y decisiones sin trazabilidad. Por eso el método importa tanto como el contenido. Si cada uno pregunta algo distinto, el análisis se vuelve ruido. Si todos usan la misma lógica causal, aparece el riesgo real.

Resumen ejecutivo:

• Un What If útil necesita estructura causal, no lluvia de ideas.
• La secuencia desviación-causa-consecuencia-barrera mejora la trazabilidad y la calidad de las acciones.
• OSHA PSM, IEC 61511, ISO 45001, API 754 y CCPS apuntan a controles verificables, no a formalidades.
• La madurez se mide por evidencia, no por cantidad de reuniones.

Este análisis forma parte del trabajo de WFS Academy sobre gestión de riesgos, disciplina operativa y competencias técnicas. Si tu organización todavía mide calidad por asistencia a la reunión, la pregunta incómoda es esta: ¿están analizando riesgos o solo completando un ritual?

Y ahí está la verdadera provocación: ¿cuánto riesgo sigue vivo en tu planta porque la pregunta se hizo mal?

En paralelo, te puede servir profundizar con gestión avanzada de P&ID en PSM, porque una buena estructura causal depende muchas veces de leer bien el proceso, y también con modelo BowTie paso a paso para traducir escenarios en barreras críticas verificables.

Si querés seguir construyendo esta capacidad en serio, el siguiente paso lógico es pasar de la teoría a la práctica con diagnósticos, facilitación experta y material técnico de referencia.