domingo, 18 de agosto de 2013

De la investigación de accidentes al concepto de accidente organizacional

Un poco de historia.

En sus inicios la actividad aerocomercial no contaba con las regulaciones y tecnologías que hoy están disponibles. Si miramos hacia atrás con anteojos calibrados en 2013 puedo aventurarme a decir que nadie, o muy pocos corajudos, se animarían a tomar el avión como un transporte seguro. Por el contrario, si miramos hacia atrás correctamente, es decir ver el pasado con la tecnología existente en ese momento, el accidente formaba parte de esas limitaciones. Por lo tanto, durante la etapa de desarrollo primigenio,  la probabilidad de que sucedan accidentes la podríamos clasificar como frecuente. 

La reacción lógica fue ¿como podemos prevenirlos? Ahí podemos ubicar un hito dentro de la línea de tiempo de la aviación: el nacimiento de la idea de "PREVAC", Prevención de Accidentes. Acciones reactivas ante un suceso que ya pasó.

Esta actividad se basó en la investigación de accidentes y en propuestas para evitar que el mismo o uno similar volviera a ocurrir. 


¿Esto fue positivo? Obviamente que sí. Fue una herramienta necesaria para el surgimiento de mejoras tecnológicas.
Como consecuencia de las investigaciones de accidentes surgieron nuevas tecnologías, un avance en la industria tan necesario para llegar a estándares de seguridad como los que hoy tenemos.

A nuevos avances tecnológicos le sucedían nuevas regulaciones, mayores exigencias. Los accidentes sufrieron una sensible disminución en su cantidad. Aquellos en que las consecuencias eran de gravedad. La idea de mayor regulación = a menor cantidad de accidentes podemos considerarlo un paradigma de la décadas 50 a la del 60. 

La regulación es necesaria y su cumplimiento debería ser el "deber ser" de toda la actividad y "el ser" del día a día. Es una barrera, una defensa que nos ayuda.  Este paradigma inicial, entonces, queda compuesto de dos premisas: Si el fallo tecnológico no fue la causa del accidente (premisa 1), miremos a la violación de la norma (premisa 2). Alguien con nombre, apellido y número de documento transgredió la normativa vigente, teniendo como resultado final el accidente. El dedo acusador. 

El proceso de investigación se centró en el análisis de defectos de materiales, calidad, y en ver quien o quienes no habían hecho lo que tenían que hacer (errores u omisiones) para detectarlos. El resultado: identificación de culpables. ¿Que falló? ¿a quién se le pasó? ¿que tenía que hacer? ¿que hizo? o ¿que hizo mal? Todas preguntas que buscaban determinar el eslabón defectuoso y una vez detectado cambiarlo.
Luego restaba realizar una recomendación de seguridad que se centraban en lo específico, en lo puntual, y que se había determinado como "la falla" (humana o tecnológica), no tomando en cuenta otras condiciones peligrosas que eran existentes y seguirían siéndolo, porque no tenían relación directa al accidente. De los factores tecnológicos a la individualidad del humano. Todo lo que no era una falla de un componente era una falla humana. Un péndulo que seguía moviéndose de un extremo a otro, esa es la esencia del péndulo al fin. El zoom de la foto estaba al máximo y no dejaba ver todo el paisaje. 

La reflexión esta basada en el cambio de paradigma, en el concepto de seguridad (safety) y no en responsabilidades personales atribuibles al derecho penal, por consiguiente, la búsqueda de culpables la ubico en la ventanilla que pertenece a la justicia. Cabe aclarar que generalmente con la aparición de un culpable o varios culpables tenemos el tema resuelto; pensamiento habitual en determinadas culturas. Mi mamá diría "listo el pollo y pelada la gallina". Sabemos que esto no es así.

Si hablamos de seguridad operacional estamos muy lejos del concepto de culpabilidad como causa final. Hay que dejar en claro la diferencia entre error y violación. En el primero no hay intencionalidad, es involuntario.  En el segundo (violación) si hay voluntad manifiesta de no hacer lo que hay que hacer. 


En los años 70 tecnológicamente se produjo un salto considerable, pero no fue lo único. Ocurrió algo más que el progreso tecnológico, ingresó a escena un nuevo concepto que hasta ese momento no había aparecido como actor dentro de la obra: el concepto de CRM (Crew Resource Managenment), podemos traducirlo como gestión de recursos de tripulación.

Los factores humanos eran parte de la obra y no un actor de reparto de esos que aparecen al fondo y casi no se los ve. Hasta aquí la formación de un piloto estaba enfocada en los aspectos técnicos fundamentalmente, por lo visto anteriormente esto era algo lógico. Con el CRM su capacitación iría mas allá, no alcanzaba con lo técnico. También influía su relación con sus compañeros de trabajo, con su organización. El CRM aportó la "Cultura de seguridad de la organización". Las interacciones humanas deficientes y la mala gestión de los recursos humanos han sido un factor contribuyente a muchos accidentes e incidentes, gran aporte al concepto de seguridad.
En esencia, CRM es la aplicación práctica de diversos aspectos de los factores humanos, como conocimiento de la situación, la toma de decisiones, gestión de amenazas y errores (TEM), trabajo en equipo y la comunicación entre las diferentes personas que participan en la operación aérea. ¿Quienes son? las tripulaciones de vuelo y de cabina, personal de mantenimiento, controladores aéreos y despachantes.
Los principios CRM integran tanto las habilidades técnicas como las no técnicas. 










Volviendo al CRM. Si el CRM es otro hito en la línea de tiempo.  La instrucción y los talleres de CRM se iniciaron tempranamente. Empresas y grupos de personas que vieron y entendieron que era un camino que había que transitar. Evidentemente estaban acertados. Los resultados positivos surgieron y el CRM se convirtió en algo metódico y hasta obligatoria en los procesos de formación en el ámbito aeronáutico.

El hombre no desarrolla su actividad en una habitación aislada, sino que esta inmerso en una organización. No esta solo, hay un contexto. Este contexto tiene influencia en el accionar humano. En nuestra actividad es el contexto operacional. Había una publicidad de cigarrillos hace muchos años atrás que decía "has recorrido un largo camino muchacha" (los lectores jóvenes no lean la frase, no se pierden nada). Se ha recorrido un largo camino para llegar a la idea de seguridad desde el punto de vista de la organización. La seguridad como sistema, que abarca todos los aspectos humanos y técnicos de una organización. Aparecen las matrices de análisis.

Una matriz, o interfaz de interacción del hombre con el entorno para el análisis la ofreció el modelo SHELL. El ser humano como centro (L), con sus capacidades y limitaciones. Con necesidades físicas y características cognitivas. Una forma particular de procesar la información y  reaccion desde su individualidad humana. Como el ser humano interactúa con otros humanos (La otra "L" L-L), con su entorno. Un ejemplo: los pilotos con los controladores, los controladores con otros controladores, los pilotos con los TCP, etc.

La relación con su soporte físico (L-H) El piloto con las pantallas de su cabina: ¿se ajustan a su capacidad sensorial? El controlador con su pantalla radar, y podríamos seguir dando ejemplos. Este modelo trata de darnos una herramienta, o por lo menos intentarlo, que nos ayude en la búsqueda del error humano. 

¿Es la única matriz? No. Hay otras, por ejemplo la pirámide de Heinrich o el Generic System Error-Modelling (GEMS). Este último se fundamenta en que se pueden producir errores en cada nivel de rendimiento de una persona: Los basados ​​en habilidades (SB): por ejemplo los lapsus, que son por lo general los errores originados en la falta de atención. Los errores basados en reglas (RB): generalmente es el resultado de escoger una regla inapropiada, esto causado por una mala interpretación de la norma, normas deficientes o superposición con otras normas/regulaciones. Los errores basados ​​en el conocimiento (KB): errores debido a una comprensión incompleta / incorrecta de sistema, exceso de confianza, esfuerzo cognitivo, etc.

Otros: el modelo "PEAR": People who do the job (Las personas que hacen el trabajo); Environment in which they work Medio Ambiente en el que trabajan); Actions they perform; ( Las acciones que llevan a cabo) and Resources necessary to complete the job. (Los recursos necesarios para completar el trabajo.)

El "Human Factors Analysis and Classification System" (HFACS) fue desarrollado por los Doctores Scott Shappell y el Dr. Doug Wiegmann. Este modelo fue utilizado originalmente por la Fuerza Aérea de los EE.UU. para investigar y analizar los factores humanos en la aviación. El HFACS se basa en gran medida en el modelo de James Reason. El marco HFACS proporciona una herramienta para ayudar en el proceso de investigación, la capacitación y la prevención. Los investigadores son capaces de identificar sistemáticamente las fallas activas y latentes dentro de una organización, que culminaron en un accidente. El objetivo del HFACS no es determinar faltas, buscar culpables, sino es comprender los factores causales subyacentes que conducen a un accidente.

No me olvide el de James Reason, nombrado en el HFACS, el modelo de Reason es actualmente el que tiene más aceptación dentro de nuestra actividad o por lo menos mejor prensa.

Hay un cambio de óptica "cambia el objeto de examinación lejos de los oscuros lados del mal gobierno corporativo no ético y de la humanidad, y hacia las decisiones ordinarias de personas ordinarias normales bajo la influencia de presiones normales, ordinarias" (Dekker, 10 preguntas sobre el error humano)

¿A que apuntan todos los modelos de análisis? A enseñarnos a buscar peligros latentes. Estos no están a simple vista, sino permanecen jugando con nosotros a las escondidas, hasta que les podamos dar ¡piedra libre! El accidente, por lo tanto, no es el error de una persona en particular o un elemento técnico exclusivamente. Sino que es la falla de nuestras defensas establecidas que deberían haber actuado para que demos "piedra libre" al peligro antes de la "fatalidad". Esta es la novedad. La posibilidad de anticiparnos y actuar proactivamente y no reactivamente (el análisis de accidentes en forma aislada)

Para no extenderme más, con los cambios, progresos y el nacimiento de un nuevo paradigma no podemos seguir hablando de "PREVAC" o simples programas puntuales para evitar accidentes; es un reloj atrasando.

La OACI en el DOC 9859 ha desterrado este concepto:

"Esta segunda edición del Manual de gestión de la seguridad operacional (Doc 9859) sustituye en su totalidad a la primera edición, publicada en 2006. También sustituye al Manual de prevención de accidentes (Doc 9422), que es obsoleto." (DOC 9859, Capítulo 1, 1.5.3)

La investigación de un accidente o incidente es estrictamente necesaria, pero ya no nos podemos quedar con esto solamente. El accidente es el resultado no de una sola circunstancia o hecho puntual, sino que es la consecuencia de condiciones latentes, peligros, que no fueron detectados a tiempo.
Puede parecernos difícil predecir cuándo ocurrirá un error o cuál es la probabilidad de su ocurrencia. Nos resulta, en una primera mirada, complejo elevar a la superficie todos los peligros ocultos en nuestra organización. Pero quizás no es tan difícil anticipar dónde ocurrirán los errores si contamos con datos de seguridad aportados por todo el personal operativo. Con datos podemos gestionar y la gestión es otro tema sobre el que escribiré en algún momento. Les dejo algo que escuche hace poco: "Actividad no es gestión" Podemos tener mucha actividad en una organización pero eso no significa que estemos gestionando algo.

Sistemas aparentemente seguros pueden desviarse y fallar, de hecho lo hacen. Si comprendemos los cambios, le agregamos el concepto de sistema, espolvoreamos la idea de que no hay que encontrar culpables, si se comprende el concepto de gestión y lo unimos con sistema nos queda "sistema de gestión" y ahí estamos más cerca de ver nuestra organización como "un sistema de gestión de la seguridad operacional". El accidente va a ocurrir, tratemos de que suceda lo más lejos posible en el tiempo.

La yapa 

Para utilizar como disparador en una reunión de seguridad operacional.

Fuente: EUROCONTROL


Roberto Julio Gómez


1 comentario:

  1. Lic. Gustavo Rodríguez14 de agosto de 2013, 11:35

    Muy bueno lo expuesto por Ud, Sr. Gomez, siempre estamos
    aprendiendo algo nuevo sobre la cotidianidad del
    contexto aeronáutico.

    Interesante la idea que recorre su escrito sobre el objetivo
    del HFACS, que no es determinar faltas, ni buscar culpables,
    sino de comprender los factores causales
    subyacentes que terminan en accidente.

    Saludos y buena jornada aeronáutica!!!

    ResponderEliminar