“El procedimiento era claro.”

Hay una frase que aparece con demasiada facilidad después de un incidente.

«El procedimiento era claro».

Se dice en una investigación. En una reunión de seguridad. En una auditoría.

Y muchas veces es cierto. El procedimiento estaba escrito. La secuencia estaba definida. La responsabilidad estaba asignada. En el papel, no había ninguna duda.

Entonces llega la conclusión más cómoda.

La persona sabía lo que tenía que hacer y simplemente no lo hizo.

Ahí empieza el problema.

Una cosa es leer un procedimiento en un escritorio, sin presión, sin ruido, sabiendo ya cómo termina la historia. Otra muy distinta es estar dentro de la operación mientras esa historia todavía se está escribiendo.

El procedimiento puede ser claro. La situación, no.

Un vuelo a punto de salir. El embarque cerrándose. Equipaje de último momento. Pasajeros que todavía llegan. Operaciones necesita cerrar, rampa espera una confirmación, la tripulación pide los números finales. Alguien reporta una discrepancia. El reloj sigue corriendo.

En medio de todo eso, alguien tiene que decidir.

Después, cuando ya pasó, alguien abre el manual, lee tres líneas y pregunta cómo alguien pudo pasar por alto algo tan claro.

Esas tres líneas no eran todo lo que estaba pasando.

Los procedimientos importan. Sin ellos, una operación compleja sería imposible de sostener. Pero convertirlos en la explicación automática de cualquier desvío es peligroso.

Un procedimiento no siente la presión de una demora. No atiende tres llamadas a la vez. No procesa información contradictoria. No carga con la experiencia previa que moldea una decisión. No teme cómo va a reaccionar un supervisor.

Las personas sí.

Es una distinción que conocemos bien en Factores Humanos: el trabajo imaginado frente al trabajo realizado (Work as Imagined versus Work as Done). El trabajo tal como imaginamos que debería hacerse. Y el trabajo tal como realmente hay que hacerlo para que la operación siga funcionando.

La distancia entre ambos puede ser pequeña.

O puede ser enorme.

«Pero estaba escrito».

Sí, lo estaba. La pregunta es si podía aplicarse como se pretendía, en esas condiciones.

Hay procedimientos demasiado largos. Repartidos en distintos documentos. Escritos para condiciones ideales que la operación real no siempre ofrece. Procedimientos con excepciones que casi nadie recuerda, redactados por personas que nunca tuvieron que ejecutarlos en el terreno.

Y hay algo todavía más incómodo.

Muchas veces la organización ya sabe que el procedimiento no se cumple exactamente como está escrito. Lo sabe porque la operación funcionó durante años a base de pequeños ajustes y atajos que nunca dejaron de funcionar.

Hasta que un día algo sale mal.

Y las mismas adaptaciones que mantenían la operación funcionando el día anterior pasan de pronto a llamarse violación de procedimiento.

Cuando sabemos cómo terminó algo, las decisiones anteriores empiezan a parecer obvias. Si hubo un incidente, vemos señales que supuestamente deberían haberse detectado. Si no se siguió el procedimiento, la decisión correcta parece evidente.

Pero la persona que estaba ahí no tenía esa ventaja.

No conocía el final. Trabajaba con lo que tenía en ese momento.

Es el sesgo retrospectivo. Probablemente uno de los jueces más injustos de la seguridad operacional.

Después de un evento, tendemos a preguntar por qué no se siguió el procedimiento. Es una pregunta legítima. Pero no alcanza.

Una mejor: ¿qué estaba viendo esa persona en ese momento que hizo que la decisión tuviera sentido?

Qué información tenía. Qué le faltaba. Qué presión existía. Qué se consideraba un comportamiento normal dentro de ese equipo.

Porque pocas personas llegan a trabajar con la intención de violar un procedimiento. La mayoría intenta resolver el problema y mantener la operación en marcha.

Hay algo que casi nunca llega a un informe.

La persona que tomó esa decisión probablemente ya había resuelto una situación parecida antes. Muchas veces. Sin que nadie lo notara, porque salió bien.

Esa trayectoria no figura en ningún expediente. No hay registro de las cien veces que alguien improvisó una solución razonable bajo presión y la operación siguió funcionando. Solo queda por escrito la vez que no salió.

Un despachante que ajustó un plan de vuelo al límite del margen legal, sin transgredirlo, y acertó cincuenta veces antes de la única vez que salió distinto.

Nadie audita las cuarenta y nueve que salieron bien.

Eso distorsiona todo. Evaluar una decisión de forma aislada la saca de su contexto real: alguien que pasó años tomando decisiones parecidas, con resultados aceptables, dentro de un sistema que nunca le dijo que lo estaba haciendo mal.

Todo lo contrario. Ese mismo sistema, con su silencio, validó esa forma de trabajar cientos de veces.

Por eso no alcanza con mirar la decisión tomada el día del incidente. Hay que mirar todas las decisiones parecidas que vinieron antes y preguntarse por qué ninguna generó una corrección.

Así se instala un desvío.

Aparece una excepción. Después, un ajuste. Después, alguien encuentra una forma más rápida de hacer algo. Funciona. Un compañero la copia. El supervisor lo sabe. La operación sigue. No pasa nada.

Después de cientos de operaciones exitosas, esa forma de trabajar empieza a sentirse normal.

Hasta que deja de funcionar.

Entonces llega la investigación y alguien pregunta por qué nadie seguía el procedimiento.

Quizás la mejor pregunta sea otra: ¿cómo permitió el sistema que esa forma de trabajar se convirtiera en la manera normal de hacer las cosas?

No alcanza con demostrar que existía una instrucción. No alcanza con señalar la página del manual o la firma en un registro de capacitación. La existencia de un procedimiento no prueba que el sistema estuviera bien diseñado.

A veces prueba lo contrario.

Si varias personas, en distintos turnos, con distintos supervisores, terminan desviándose del mismo procedimiento, probablemente no sea un problema de personas.

Es un problema de diseño.

Solemos esperar que las personas se adapten al procedimiento. Rara vez preguntamos si el procedimiento necesita adaptarse a la realidad.

Habría que observarlo en uso. Conversarlo con quienes realmente lo ejecutan todos los días, no solo con quien lo redactó una vez y nunca volvió a mirarlo. Revisarlo cuando la operación muestra que hay una distancia entre lo escrito y lo posible.

Porque el objetivo de un procedimiento no debería ser proteger a la organización después de un incidente.

Debería ayudar a las personas antes de que ocurra.

«El procedimiento era claro» puede ser cierto en la oficina, en la auditoría, en la investigación, con todo el tiempo del mundo y sin ninguna presión encima.

La verdadera pregunta es si seguía siendo igual de claro dentro de la operación, con el reloj corriendo y las condiciones cambiando.

En la próxima mentira vamos a cuestionar otra frase que aparece cada vez que sobra información:

LIE #13: «More information means better decisions.» («Más información significa mejores decisiones»).

Porque tener más datos disponibles no garantiza que alguien pueda procesarlos a tiempo, bajo presión, con el reloj corriendo. A veces el problema no es la falta de información. Es todo lo que hay que hacer con ella en el momento exacto en que se necesita.

Beyond Human Error sigue creciendo gracias a contenido independiente, experiencia operacional y conversaciones que buscan aportar valor real a la seguridad.

Actualmente estoy abierto a colaborar con organizaciones que trabajan en aviación, Factores Humanos, seguridad operacional, capacitación o toma de decisiones operacionales.

No me interesa sumar publicidad solo por visibilidad. Cualquier colaboración debe ser relevante, creíble y genuinamente útil para una comunidad especializada que sabe distinguir entre promoción y contenido con sustancia.

Si tu organización comparte ese enfoque, hablemos.

#BeyondHumanError