Trampas comunes que deben evitarse
La hoja de ruta que hemos analizado para empezar a trabajar con el proceso de revisión posterior al incidente es útil, como también puede serlo conocer algunos de los obstáculos que podemos encontrar en este periplo.
En esta unidad, se incluye información sobre algunas trampas comunes en las que otros han caído durante el proceso de revisión posterior a un incidente y cómo evitarlas.
Trampa 1: Atribución a un "error humano"
Es posible que recuerde que un "error del piloto" (o "error humano") fue la conclusión a la que llegaron los primeros investigadores en la historia del B-17 con la que arrancamos en la introducción al módulo. Volvamos a esa historia.
En esa introducción, insinuamos que las conclusiones a las que se llegaron podrían no ser lo suficientemente satisfactorias. así lo fueron al menos para Alphonse Chapanis, un psicólogo militar al que las Fuerzas Aéreas de EE. UU. pidieron que investigara estos incidentes. Entre otras cosas, vimos que estos accidentes ocurrían exclusivamente con el B-17 y con un pequeño porcentaje de otros aparatos. Había miles de aviones de transporte C-47 en uso en Europa Occidental al mismo tiempo, y ninguno de ellos había sufrido un incidente de esas características.
Así, entrevistó a varios pilotos y, basándose en lo que estos le dijeron, pasó a estudiar las cabinas de los B-17. En ellas vio que había dos interruptores: el del tren de aterrizaje y el de los alerones. Ambos estaban separados entre sí por algo más de 7 cm en la cabina Su modo de operación era idéntico. Eran bastante fáciles de confundir, y eso es lo que había sucedido en estos incidentes. Cuando un avión acaba de aterrizar, los alerones van a estar desplegados y, antes de aparcar, se repliegan. Así pues, Chapanis probó algo diferente.
Pegó una pequeña rueda de goma en el interruptor del tren de aterrizaje y un "alerón" de pico pronunciado en el interruptor de los alerones, bastante convencido de que los accidentes dejarían de suceder.
Se le conoce como uno de los padres de la ergonomía (el estudio de cómo influyen los factores de diseño en el rendimiento humano) y simplemente observó que el diseño de la cabina podía aumentar las probabilidades de error humano. Este método ha pasado a marcar el diseño de todos los aviones modernos. Ahora, los dos interruptores de los aviones actuales son muy distintos, según lo dispuesto en la ley federal de EE. UU.
¿Por qué estamos contando esta historia?
El ser humano comete errores, Sin embargo, un error humano no es una causa: es un síntoma. Cuando se considera que el error humano es el motivo de un fallo, el incidente se da por resuelto y deja de analizarse.
El diseño del sistema, el contexto de la organización y el contexto personal afectan a cuándo, cómo y en qué medida la gente comete errores. "Error humano" es una etiqueta que nos hace abandonar una investigación justamente en el momento en el que estamos a punto de descubrir algo interesante sobre el sistema.
El problema de llegar a la conclusión de "error humano" en las investigaciones es que se pierde de vista el hecho de que todo aquello que el ser humano hizo tenía sentido en su momento. Los errores, por definición, no son deliberados. No tenemos la intención de cometerlos.
Cuando vemos o escuchamos "error humano", es señal de que debemos ahondar más en el asunto. Si queremos aprender, no debemos dejar de investigar cuando encontramos un error humano, como solemos hacer con frecuencia. Tal y como nos ha enseñado la historia de los B-17, es justo más allá del error humano donde aprenderemos cosas interesantes sobre nuestro sistema.
Trampa 2: razonamiento contrafáctico
El término contrafáctico significa "contrario a los hechos" y el razonamiento contrafáctico hace referencia a contar una historia sobre eventos que no han sucedido con el fin de explicar algo que sí ha sucedido. Esto no tiene mucho sentido, a pesar de que tendemos a hacerlo todo el tiempo.
Las afirmaciones de carácter contrafáctico se pueden identificar por expresiones clave como estas:
- ... podría haberse...
- ... debería haberse...
- ... se hubiera...
- ... no pudo...
- No
- ... si se hubiese...
Estos son algunos ejemplos de afirmaciones contrafácticas relacionadas con las revisiones posteriores al incidente:
"El sistema de supervisión no pudo detectar el problema".
"El ingeniero no comprobó la validez de la configuración antes de establecerla".
"Esto podría haberse detectado en el entorno de valores controlados".
El problema con este tipo de razonamiento en una revisión posterior al incidente es que nos estamos centrando en cosas que no han pasado, en vez de dedicarnos a saber cómo sucedió lo que sucedió. Esta especulación no nos enseña nada.
Trampa 3: lenguaje normativo
El lenguaje normativo implica a menudo que había una línea de actuación "evidentemente correcta" que los operadores deberían haber seguido, y las acciones de esos operadores se juzgan con la ventaja que da hacerlo de manera retrospectiva.
El lenguaje normativo se puede identificar generalmente por expresiones como "inadecuadamente", "sin cuidado", "de forma precipitada", etc.
El pensamiento normativo conduce a juzgar decisiones en función de los resultados. Esta forma de hablar no es lógica, ya que el resultado es la única información que no estaba disponible para quienes tomaron las decisiones y establecieron sus criterios.
El lenguaje normativo también se puede usar en sentido inverso; es decir, podemos elogiar a los operadores por haber actuado "adecuadamente", por ejemplo. Pero, de nuevo, esta opinión se suele dar a menudo contando con la ventaja de poseer una información que antes no se tenía.
El problema del lenguaje normativo es similar al problema del razonamiento contrafáctico: si hacemos juicios de valor después de haber sucedido un hecho usando la información que no estaba disponible para quienes se vieron involucrados en el incidente, nos olvidamos de comprender de qué forma las acciones de los operadores tenían sentido en su momento.
Trampa 4: razonamiento mecanicista
El razonamiento mecanicista hace referencia al concepto según el cual un resultado determinado se puede deducir de una intervención. A veces se denomina síndrome del "niño entrometido" (acuñado por Jessica DeVita), que se basa en una premisa de tipo "Nuestro sistema hubiera funcionado bien... de no haber sido por esos niños entrometidos".
Cuando se usa el razonamiento mecanicista en la revisión posterior a un incidente, se llega a conclusiones a partir de la falacia de que los sistemas con los que (y en los que) trabajamos funcionan correctamente y, solo si esos "niños entrometidos" no hubieran hecho lo que hicieron, el error no se habría producido.
Pero no es así como funcionan los sistemas.
Para ilustrar esto, imaginemos el siguiente escenario: Trabajamos en un servicio de producción. Se nos indica en un momento dado que no podemos tocar ni hacer nada en ese servicio. Todo lo que es exterior a nuestro equipo sigue como antes: los clientes siguen usando el servicio, las dependencias externas siguen cambiando, Internet funciona con normalidad.
Sin embargo, no podemos realizar cambios en el código o en la configuración. ni implementaciones, ni operaciones de plano de control... Nada.
¿Seguirá funcionando el servicio según lo previsto transcurrido un día? ¿Y una semana? ¿Y un mes? ¿Y un año? ¿Durante cuánto tiempo podríamos prever de forma realista que el servicio va a seguir funcionando sin intervención humana? En la gran mayoría de los casos, no duraría tanto.
Esta reflexión nos lleva a una conclusión importante:
La capacidad de adaptación humana es necesaria para mantener los sistemas en funcionamiento.
El único motivo por el que los sistemas siguen funcionando en primer lugar es debido a la acción humana dentro del bucle de control. Los sistemas siguen funcionando solamente gracias a la acción humana y a la capacidad de adaptación a las circunstancias cambiantes.
Por lo tanto, es erróneo concluir que el sistema estaba "básicamente funcionando... de no haber sido por esos niños entrometidos". De hecho, la confiabilidad del servicio no es independiente de los usuarios que trabajan en él. Es más bien un resultado directo del trabajo que los seres humanos llevan a cabo en este cada día.
El problema del razonamiento mecanicista es que nos lleva a creer que encontrar a la persona que ha cometido el error equivale a encontrar el problema, cuando esa misma persona es quien ha estado improvisando y adaptándose para mantener el sistema funcionando durante semanas y meses. Quizás este papel sea lo suficientemente importante como para reflejarlo en nuestra revisión posterior al incidente.
Ahora que ya sabemos algunas cosas que debemos evitar durante una revisión posterior al incidente, podemos pasar a la siguiente unidad, en la que exploraremos algunos procedimientos de utilidad en esas revisiones.