BS EN 62740:2015

Root cause analysis (RCA)

INTRODUCCIÓN
El análisis de causa raíz (RCA) se refiere a cualquier proceso sistemático que identifica factores que
contribuyen a un evento particular de interés (evento de enfoque). RCA se realiza con el
entendimiento de que los eventos se abordan mediante la comprensión de las causas
fundamentales, en lugar de los síntomas inmediatamente evidentes. RCA tiene como objetivo
revelar las causas fundamentales para que la probabilidad de que ocurran, o su impacto si
ocurren, pueda cambiarse.

Una distinción importante a hacer es que RCA se usa para analizar un evento de foco que he
ocurrido y por lo tanto analiza el pasado (a posteriori). Sin embargo, el conocimiento de la causa
raíz de eventos pasados puede llevar a acciones que generen mejoras en el futuro.

Esta Norma Internacional pretende reflejar las buenas prácticas actuales en la realización de RCA.
Este estándar es de naturaleza general, por lo que puede brindar orientación en muchas industrias
y situaciones. Es posible que existan estándares específicos de la industria que establezcan
metodologías para aplicaciones particulares. Si estos estándares están en armonía con esta
publicación, los estándares de la industria generalmente serán suficientes.

Esta norma es una norma genérica y no aborda explícitamente la seguridad o la investigación de

accidentes. aunque los métodos descritos en esta norma pueden ser utilizados para este
propósito.

ANÁLISIS DE CAUSA RAÍZ (RCA)

1 Alcance
Esta norma internacional describe los principios básicos del análisis de causa raíz (RCA) y especifica
los pasos que debe incluir un proceso para RCA.
Este estándar identifica una serie de atributos para las técnicas RCA que ayudan con la selección
de una técnica adecuada. Describe cada técnica RCA y sus relativas fortalezas y debilidades.

RCA se utiliza para analizar las causas fundamentales de los eventos con resultados tanto positivos
como negativos, pero se usa más comúnmente para el análisis de fallas e incidentes. Las causas de
tales eventos pueden ser de naturaleza variada, incluidos los procesos y técnicas de diseño,
características organizacionales, aspectos humanos y eventos externos. RCA se puede utilizar para
investigar las causas de las no conformidades en los sistemas de gestión de calidad (y otros) así
como para análisis de fallas, por ejemplo en mantenimiento o pruebas de equipos.

RCA se utiliza para analizar los eventos que han ocurrido, por lo tanto, este estándar solo cubre un
análisis a posteriori. Se reconoce que algunas de las técnicas de RCA con adaptación pueden ser
utilizadas de forma proactiva en el diseño y desarrollo de elementos y para el análisis causal
durante la evaluación del riesgo; sin embargo, este estándar se enfoca en el análisis de eventos
que han ocurrido.

La intención de este estándar es describir un proceso para realizar RCA y explicar las técnicas para
identificar la causa raíz. Estas técnicas no están diseñadas para asignar responsabilidad u
obligación, lo cual está fuera del alcance de esta norma.

2 Referencias normativas
Los siguientes documentos, en su totalidad o en parte, son referenciados normativamente en este
documento y son indispensables para su aplicación. Para las referencias con fecha, sólo se aplica la
edición citada. Para referencias sin fecha, la última edición del documento de referencia
(incluyendo cualquier enmienda) se aplica.

IEC 60050 (todas las partes), Vocabulario electrotécnico internacional

3 Términos, definiciones y abreviaturas

Para los propósitos de este documento, aplican las definiciones dadas en IEC 60050-192, así como
las siguientes.

3.1 Términos y definiciones

3.1.1 Causa

Circunstancia o conjunto de circunstancias que conducen al fracaso o al éxito.

Nota 1: Una causa puede originarse durante la especificación, diseño, fabricación, instalación,
operación o mantenimiento.

[FUENTE: IEC 60050-192:2014, 192-03-11 modificado – adición de las palabras “circunstancia o” y

“o éxito” en el término]

3.1.2 El factor causal

Condición, acción, evento o estado que fue necesario o contribuyó a la ocurrencia del evento.
3.1.3 Factor contribuyente

Condición, acción, evento o estado considerado como secundario, según la ocurrencia del evento.

3.1.4 Evento

Ocurrencia o cambio de un conjunto particular de circunstancias.

Nota 1: Un evento puede ser una o más ocurrencias y puede tener varias causas.

Nota 2: Un evento puede consistir en algo que no sucede.

Nota 3: A veces se puede hacer referencia a un evento como un "incidente" o "accidente".

[FUENTE: Guía ISO 73:2009, 3.5.1.3, modificada – Eliminación de la Nota 4 [1]] 1

3.1.5 Fallo <de un elemento>

Pérdida de la capacidad para desempeñarse según lo requerido.

Nota 1: Una falla de un artículo es un evento que resulta en una falla de ese artículo.

Nota 2: Las calificaciones, como catastrófico, crítico, mayor, menor, marginal e insignificante,
pueden usarse para clasificar las fallas de acuerdo con la gravedad de las consecuencias, la
elección y las definiciones de los criterios de gravedad dependen del campo de aplicación.

Nota 3: Se pueden usar calificadores, como mal uso, mal manejo y debilidad, para categorizar las
fallas, según la causa de la falla.

Nota 4: Este es un fallo de un elemento, no generalmente de comportamiento.

[FUENTE: IEC 60050-192:2014, 192-03-01, modificado – Introducción de la nueva Nota 4]

3.1.6 Mecanismo de falla.

Proceso que conduce al fracaso.

Nota 1: El proceso puede ser físico, químico, lógico, psicológico o una combinación de los mismos.

[FUENTE: IEC 60050-192:2014, 192-03-12, modificado: la palabra "psicológico" se ha adicionado]

3.1.7 Evento de enfoque.

Evento que se pretende explicar causalmente.

3.1.8 Factor causal inmediato

Condición, acción, evento o estado donde no hay otro factor causal entre este factor causal y el
evento de enfoque.
Nota 1: Puede haber más de un factor causal inmediato.

3.1.9 Factor causal necesario <de un evento o estado>

Condición, acción, evento o estado, que resultó en el evento o estado dado, sin el cual el evento
dado o estado no habría ocurrido

3.1.10 Error humano

Discrepancia entre la acción humana realizada u omitida, y la prevista o requerida.

Nota 1: La primera edición de IEC 60050-191:1990 identificó “error” como sinónimo de “error
humano”, pero un error es un tipo de error humano.

Nota 2: El término error humano se aplica a cualquier situación en la que el resultado no sea el
esperado, ya sea que la intención de la persona sea correcta o no.

[FUENTE: IEC 60050-192: 2014 192-03-14, modificado – Omisión del ejemplo, adición de Nota 1 y
2]

3.1.11 Elemento

Tema que se está considerando

Nota 1: El artículo puede ser una parte individual, un componente, un dispositivo, una unidad
funcional, un equipo, un subsistema o un sistema.

Nota 2: El elemento puede consistir en hardware, software, personas o cualquier combinación de

los mismos.

Nota 3: El elemento a menudo se compone de elementos que pueden considerarse

individualmente.

[FUENTE: IEC 60050-192: 2014, 192-01-01, modificado – omisión de referencias internas y Notas 4
y 5]

3.1.12 Causa principal

Factor causal sin predecesor que es relevante para el propósito del análisis.

Nota 1: Un evento de enfoque normalmente tiene más de una causa raíz.

Nota 2: En algunos idiomas, el término causa raíz se refiere a la combinación de factores causales
que no tienen predecesor causal (un conjunto de factores causales).

3.1.13 Análisis de raíz de la causa RCA.

Proceso sistemático para identificar las causas de un evento de enfoque.

Nota 1: IEC 60050-192:2014, definición 192-12-05 proporciona la siguiente definición más
restrictiva “proceso sistemático para identificar la causa de una falla, falla o evento no deseado,
para que pueda ser eliminado por diseño, cambios de proceso o procedimiento”. Esta norma
utiliza una definición ampliada para permitir una mayor aplicabilidad de la proceso.

Nota 2: esta nota se aplica solo al idioma francés.

3.1.14 Interesado.

Persona u organización que puede afectar, ser afectada o percibirse a sí misma como afectada por
una decisión o actividad

[FUENTE: IEC 60300-1:2014, 3.1.15] [2]

3.1.15 Regla de parada

Medios razonados y explícitos de la determinación cuándo un factor causal se define como una
causa raíz.

3.2 Abreviaturas
BGA Matriz de cuadrícula de bolas
CAST Análisis causal usando STAMP
CCT Prueba de integridad causal
TC Prueba contrafactual
CTM Método del árbol de causas de la marca
comunitaria
ECF Eventos y factores causales
EEM Modo de error externo
FTA Análisis de árbol de fallas
GEMS Sistema genérico de modelado de errores
HFACS Esquema de clasificación y análisis del
factor humano
IEM Modo de error interno
MES Secuenciación de eventos multilineales
MORT Control de gestión y árbol de riesgos
PEM Mecanismo de error psicológico
PSF Factores de configuración del rendimiento
RCA Análisis de causa raíz
SOL Seguridad a través del aprendizaje
organizacional
STAMP Sistemas modelo teóricos de accidentes y
procesos
PASO Trazado secuencial de eventos
cronometrados
TRACEr Técnica para el análisis retrospectivo y
predictivo de errores cognitivos
WBA Análisis del porqué-porque
4 RCA: Descripción general
RCA se refiere a cualquier proceso sistemático que identifica la causa o causas que contribuyen a
un evento de enfoque. La causa inmediata u obvia de un evento de foco es a menudo un síntoma
de causas subyacentes y es posible que no identifique verdaderamente la causa raíz o las causas
que deberían identificarse y abordado. RCA proporciona una mayor comprensión acerca de por
qué han ocurrido los eventos. RCA puede identificar lo siguiente:

a) una sola causa raíz;

b) causas raíz múltiples en las que la eliminación de cualquier causa impedirá la ocurrencia del
evento;

c) causas raíz que son factores contribuyentes donde la eliminación cambiará la probabilidad de
que ocurra el evento de enfoque pero puede no prevenirlo directamente;

d) causas fundamentales de los éxitos.

Al abordar la causa raíz o las causas, es posible tomar decisiones con respecto a acciones que
generarán mejores resultados en el futuro; la implementación de acciones apropiadas basadas en
RCA son más efectivos para prevenir eventos iguales o similares con resultados negativos que
ocurren o aumentan la probabilidad de repetir eventos con resultados positivos, en comparación
con solo abordar los síntomas inmediatamente obvios.

RCA se puede aplicar a cualquier evento de enfoque, ya sea éxito o fracaso, por ejemplo:

1) investigación de eventos de enfoque tecnológico, médico y ocupacional;

2) análisis de fallas de los sistemas tecnológicos, para determinar por qué un elemento no se
desempeñó como se requería;

3) análisis de control de calidad y procesos comerciales;

4) análisis de resultados exitosos.

RCA se puede llevar a cabo en varios niveles de descomposición, por ejemplo, de sistema a nivel
de componente o seleccionando diferentes eventos o resultados como punto de partida. El nivel
apropiado para llevar a cabo el análisis dependerá del evento de enfoque.

RCA se usa para analizar eventos de enfoque que realmente han ocurrido y, por lo tanto, es
aplicable durante las fases de prueba y operativas de un proyecto o ciclo de vida del producto. RCA
puede identificar problemas de proceso que incluyen diseño, control de calidad, gestión de
confiabilidad y administración de proyecto.

Los beneficios de realizar RCA incluyen:

• obtener una mayor comprensión de lo que ha sucedido;

• encontrar la fuente de los problemas para que la acción correctiva pueda prevenir eventos
futuros;

• identificar las causas de los eventos con resultados beneficiosos para que puedan repetirse;

• identificar acciones más efectivas para abordar las causas de los eventos de enfoque;

• lograr los objetivos de las investigaciones de eventos focales de manera más efectiva;

• respaldar la trazabilidad entre la evidencia y las conclusiones de la investigación del evento de

enfoque;

• aumentar la consistencia entre las investigaciones de eventos de enfoque similares;

• aumentar la objetividad del análisis de eventos de enfoque.

5 El proceso de RCA.
5.1 Resumen
Para ser efectivo, el RCA debe realizarse sistemáticamente como una investigación, con la causa
raíz y conclusiones respaldadas por evidencia documentada. Para lograr esto, RCA debe incluir los
cinco pasos que se muestran en la Tabla 1 y se ilustran en la Figura 1.

Tabla 1 – Pasos a RCA

Etapa Conceptos y tareas a realizar

Iniciación Con base en el conocimiento disponible sobre el evento de
enfoque, determinar la necesidad de llevar a cabo un RCA y
definir el propósito y alcance
Establecimiento de hechos Recopilar datos y establecer los hechos de lo que sucedió, dónde,
cuándo y por quién
Análisis Usar herramientas y técnicas de RCA para determinar cómo y por
qué ocurrió el evento de enfoque
Validación Distinguir y resolver las diferentes posibilidades de cómo y por
qué el evento de foco
fue causado
Presentación de resultados Presentar los resultados del análisis de eventos focales

RCA es de naturaleza iterativa, especialmente para la recopilación y el análisis de datos, ya que los
datos se recopilan sobre 'qué' sucedió, que luego se analiza para determinar qué otros datos
deben ser recogidos. Una vez recopilados, se lleva a cabo un análisis adicional y se identifican las
lagunas, para lo cual se recopilan más datos. Este proceso se repite hasta que se cumpla el
propósito del análisis sea completado y las causas raíz identificadas. Las salidas del RCA
dependerán de su propósito y alcance.
 Establecer la Qué, Cómo y por qué Causas
necesidad, el dónde, (identificar potenciales
propósito y el cuándo y posibles identificadas y
alcance por quién causas) resueltas

Salidas

Aplicación de
Conocimiento Recopilación de Más datos y
herramientas
actual datos pruebas
específicas

Paso 5: Presentación de
Paso 1: Iniciación Paso 2: Establecimiento de hechos Paso 3: Análisis Paso 4: Validación Resultados

5.2 Iniciación

El primer paso inicia el proceso de RCA al evaluar la necesidad de llevar a cabo RCA. Se define el
propósito y el alcance del análisis, en respuesta al evento de enfoque, y se establece un equipo y
recursos para llevar a cabo la RCA.

Por lo general, existe algún criterio que se utiliza para determinar cuándo se requiere un RCA, que
puede incluir:

• Cualquier evento único con un gran efecto;

• Múltiples eventos indeseables similares;

• Un parámetro que se sale de un nivel de tolerancia definido;

• Fallas o éxitos (cualquiera que sea el nivel de efecto) que involucran elementos críticos del
equipo o actividades.

Al momento de definir el tipo de eventos que requieren la realización de RCA, es importante

considerar que un evento con un gran efecto puede tener causas raíz comunes a eventos con
efectos menores.

Analizar y abordar las causas fundamentales de los eventos con efectos menores puede evitar un
efecto mayor. Ejemplos de eventos en los que se puede requerir RCA incluyen: finalización de un
proyecto (éxitos y fracasos), fracasos que resultan en costos inaceptables, lesiones o fatalidades,
desempeño inaceptable o retrasos, grandes consecuencias contractuales y daños de equipo.

Si se requiere un RCA, se describen los eventos de enfoque que se analizarán y se designa un

equipo apropiado para el análisis. La descripción debe incluir los antecedentes y el contexto en
que ocurrieron los eventos de enfoque. Una buena descripción de un evento de enfoque es breve,
simple y fácil de entender y no debe estar sesgado hacia una solución específica. Esta descripción
se utiliza para identificar a los miembros apropiados del equipo de análisis y determinar por dónde
empezar a recolectar los datos.

El objeto y alcance de la RCA se debe determinar teniendo en cuenta el conocimiento del sistema,
funciones, interfaces, etc. En algunos casos, el propósito del análisis es identificar las causas del
evento de enfoque. En otros, el propósito puede ser más amplio, por ejemplo, para también
identificar asuntos de preocupación fuera de los que condujeron al evento de enfoque.

En general, hay dos tipos diferentes de RCA que tienen objetivos diferentes y no deben estar
mezclados. Estos dos tipos se pueden describir de la siguiente manera:

1) analizar un evento de enfoque usando solo información fáctica verificable;

2) analizar un evento de enfoque para obtener hipótesis de secuencias de eventos y causa.

La primera versión se centra únicamente en los hechos observados. Puede tratarse de un análisis
"per se" según el propósito del estudio y ninguna hipótesis sobre la ocurrencia del evento es
aceptable para este análisis. El segundo puede implementarse cuando no se dispone de suficiente
información fáctica y las hipótesis de causas potenciales son aceptables para el propósito del
análisis.

También se deben identificar las salidas requeridas del RCA. Los ejemplos son los siguientes:

• proporcionar una descripción de cada causa raíz junto con suficiente información de
antecedentes para permitir la identificación de acciones adecuadas;

• recomendar acciones que, tomadas en conjunto, prevengan más eventos similares con
consecuencias adversas y mejorar la probabilidad de éxito;

• identificar, implementar y revisar acciones para abordar las causas fundamentales.

RCA puede incluir el análisis de sistemas en los que los límites evolucionan continuamente e
interactúan con su entorno; esta interacción puede tomar la forma de información, energía o
transferencia de materiales. Por lo tanto, el alcance debe especificar el límite del análisis (qué está
incluido y lo que está excluido).

El alcance del análisis debe incluir, cuando sea posible, una definición de la "regla de detención", el
cual es el punto en el que se puede definir la acción o la prueba adicional de la causa ya no es
necesaria para el propósito del análisis. Por ejemplo, el último punto donde la acción correctiva
puede identificarse, antes de que los factores que no pueden ser influenciados, p. ej. clima. Sin
embargo, puede ser más apropiado para determinar la regla de parada en los puntos de revisión
que determinan si se requiere más análisis.

RCA puede ser llevado a cabo de manera efectiva por una persona siempre que esa persona tenga
experiencia con la técnica de análisis causal, es un experto en el dominio (o tiene acceso inmediato
a expertos en el dominio) y tiene acceso a todos los datos requeridos. Sin embargo, es más común
realizar RCA como equipo. Los miembros del equipo para el análisis deben seleccionarse en
función de la experiencia específica necesaria para analizar el evento de enfoque. El equipo debe
incluir:

• una persona o personas que entre ellos pueden proporcionar una visión general completa de los
sistemas y conocimiento del programa o proyecto del evento de enfoque;

• un facilitador experto en la técnica del análisis causal, deseablemente capacitado o con

experiencia en la facilitación de la técnica del análisis causal.

Los miembros del equipo pueden cambiar según la actividad que se esté realizando, p. ej. Los
miembros del equipo responsable de la recolección de datos no será necesariamente el mismo
que realice el análisis. Los miembros del equipo pueden incluir ingenieros, técnicos, operadores,
representantes de ventas y gerentes. Se debe considerar el uso de personas externas para
proporcionar una perspectiva independiente y evitar los puntos ciegos que puedan existir en la
organización. Deben incluirse miembros adicionales en el equipo para actividades específicas
durante la investigación para aportar su experiencia al equipo o para aumentar la influencia del
equipo. El papel de estos miembros adicionales del equipo es apoyar la investigación para que no
se detenga por razones de límites técnicos u organizacionales. No es apropiado para las personas
que pueden haber tenido un papel en la causalidad del evento. Su aporte debe recopilarse
durante los dos primeros pasos.

5.3 Establecimiento de hechos

Este paso incluye todas las actividades necesarias para preparar el análisis. Estableciendo los
hechos suele ser la mayor parte de la RCA. Los hechos deben determinarse sobre "lo que" sucedió,

'dónde', 'cuándo' y 'por quién'. Los datos deben recopilarse antes de que se pierdan (por ejemplo,
antes de que se alteren o eliminen las pruebas, o los recuerdos se desvanezcan). En general, los
datos recopilados incluirían:

a) el contexto en el que ocurrió el evento de enfoque;

b) las condiciones antes, durante y después del evento de enfoque;

c) participación del personal, incluidas las acciones realizadas (o no realizadas) y las decisiones
tomadas;

d) datos de contexto sobre el entorno, incluidos datos ambientales;

e) cómo opera la organización, incluidos organigramas, procesos y procedimientos, formación y

habilidades;

f) datos históricos relativos a eventos similares o precursores;

g) desviaciones de lo esperado;
h) interacciones con otros elementos y personal;

i) los equipos involucrados, su estado de funcionamiento y el cumplimiento de los requisitos.

A continuación se enumeran ejemplos de datos que pueden ser relevantes:

1) Inspección de evidencia física como componentes fallidos e informes de fallas. En general, es la

experiencia la que determinará qué evidencia física se requiere. Si hay duda, la evidencia debe
conservarse. También es importante preservar la evidencia.

2) Fotografías y videos tomados por cámaras de monitoreo. Fotografiar la zona de la ocurrencia

desde varias vistas también será útil en la fase de análisis.

3) Datos operativos, registrados por sistemas de monitoreo, sistemas de control, registradores de

alarma y evento, etc. Los registros del operador pueden ser fundamentales para comprender las
condiciones de funcionamiento en el momento de la falla y dado que normalmente tienen fecha
(o reloj), son ideales para generar una cronología de los acontecimientos.

4) Testimonio personal recabado mediante la realización de entrevistas. Las entrevistas deben

concentrarse en recopilación de datos, p. ej. construir una línea de tiempo consistente, etc.;
cualquier discusión prematura de la las causas del fracaso pueden tener un impacto adverso en el
proceso de la entrevista. Las preguntas deben prepararse antes de la entrevista para asegurarse
de obtener toda la información necesaria. Las entrevistas deben llevarse a cabo con aquellas
personas que estén más familiarizadas con el evento de enfoque, sin embargo, considere
entrevistar a otro personal, p. ej. personas que han realizado el trabajo en el pasado. Todas las
entrevistas deben ser documentadas.

5) Evidencia documental de procedimientos relevantes, entorno operativo y normativa ambiente.

Este paso puede incluir un análisis de fallas que examina los componentes defectuosos utilizando
una amplia gama de métodos que incluyen microscopía, espectroscopia y pruebas no destructivas
o modelos en el desarrollo de fallas, como el modelado de incendios o el modelado de choques.

Una vez que se han recopilado todos los datos asociados con el evento de enfoque, los datos
deben revisarse para verificar su corrección e idoneidad, se deben obtener los datos faltantes y
cualquier inconsistencia debe resolverse para garantizar una imagen clara y coherente del evento
de enfoque que se está determinando.

El resultado de este paso es la información y la comprensión, respaldadas por evidencia física y

declaraciones de testigos, en relación con

• lo que sucedió, incluidas las circunstancias que llevaron al evento de enfoque,

• la secuencia de tiempo de los eventos que conducen al evento de enfoque,

• la ubicación del evento de enfoque,

• acciones de personas asociadas con el evento de enfoque,

• cualquier condición necesaria para el evento de enfoque,

• las consecuencias del evento de enfoque

5.4 Análisis
5.4.1 Descripción

Habiendo determinado 'qué' sucedió, 'dónde', 'cuándo' y 'por quién', este paso establece 'cómo' y
'por qué' ocurrió el evento de enfoque. El objetivo de este paso es entender el evento de enfoque
y sus causas al estructurar los datos que se han recopilado en un formulario que permite que las
causas fundamentales se deriven sistemáticamente.

RCA normalmente analiza hechos para identificar las causas que fueron necesarias para que
ocurriera el evento de enfoque, denominados “factores causales necesarios”. Sin embargo, en
algunos casos, por ejemplo cuando no se dispone de suficientes hechos, el análisis puede
proponer una o más hipótesis de causa y también puede identificar los factores contribuyentes y
las condiciones prevalecientes posiblemente asociados con el evento de enfoque, pero no se
puede probar que sean factores causales necesarios.

El análisis implica lo siguiente:

• organizar la evidencia física y las declaraciones de testigos sobre acciones, eventos, condiciones
y resultados;

• buscar cómo y por qué ocurrió el evento de enfoque utilizando los datos recopilados para
justificar conclusiones. Modelos de causalidad, pruebas de laboratorio, listas de verificación y
taxonomías o el análisis estadístico de los datos se puede utilizar para ayudar en este proceso;

• observar más allá de los factores causales inmediatos y por qué ocurrieron. El objetivo es buscar
todos los factores causales que contribuyeron, no solo las causas obvias;

• continuar este proceso hasta que se invoque la regla de detención y se identifiquen las causas
fundamentales. Ahí puede haber múltiples causas fundamentales que pueden ser independientes
o estar correlacionadas. En general, los factores causales pueden involucrar cuestiones técnicas,
aspectos humanos y factores relacionados con el entorno físico o psicosocial en el que se produjo
el evento de enfoque. Todos estos deben tenerse en cuenta al buscar las causas profundas. Las
personas con experiencia en estas áreas deben por lo tanto, participar en el análisis.

Los factores causales deben describirse de forma clara y sin ambigüedades. Donde una acción
humana, omisión o decisión se identifica como un factor causal, la naturaleza del acto o decisión
debe especificarse, p. ej. "el operador apagó el interruptor de alimentación equivocado" y no solo
"error humano ".

El análisis de las causas (dependiendo del propósito y alcance del análisis) puede considerar:
• Cómo ocurrió el evento de enfoque, es decir, el proceso físico, químico, psicológico o lógico que
estuvo involucrado;

• Eventos anteriores o condiciones que fueron necesarias para que ocurriera el evento de
enfoque;

• Las relaciones entre los factores causales, incluida la forma en que se combinaron para causar el
evento de enfoque y cómo una causa raíz conduce al evento de enfoque;

• Influencias organizativas y de gestión y factores humanos que intervinieron en el evento de

enfoque o en los eventos y condiciones que conducen a él;

• Condiciones prevalecientes que pueden haber contribuido a que ocurra el evento pero no
fueron factores causales necesarios;

• Asuntos de preocupación que podrían conducir a otros eventos de enfoque (estos no son
estrictamente causales pero puede ser un resultado del análisis).

Se debe utilizar una técnica de análisis estructurado para realizar el análisis. Existen varias técnicas
formales que van desde las que se basan en una lista de verificación de causas hasta las técnicas
que guian al analista a través de la consideración de las causas y presentan gráficamente los
resultados. Las técnicas varían de simples a complejas y requieren profesionales adecuadamente
capacitados o facilitadores para llevar a cabo el análisis. Algunas técnicas se basan en modelos
particulares de cómo un se produce el evento de enfoque y por lo tanto dan un énfasis particular a
los resultados. Los diferentes modelos se basan en diferentes hipótesis con respecto a la
causalidad, por lo que tienden a conducir al investigador a identificar diferentes factores
contribuyentes.

En algunos casos conviene utilizar más de una técnica o tener en cuenta consideraciones de más
de un modelo para identificar todas las causas fundamentales.

Los modelos de causalidad se describen en el Anexo B y las técnicas de análisis se describen en el

Anexo C. La técnica más apropiada dependerá del evento de enfoque y el propósito y alcance del
análisis (ver Cláusula 6).

El análisis puede indicar que se requieren más datos. Se debe esperar que se requiera de tales
datos a lo largo del análisis para resolver las inconsistencias o completar las lagunas en el análisis.
El análisis debe continuar hasta que se invoque una "regla de interrupción".

5.4.2 El equipo de análisis

Se debe designar un líder para la etapa de análisis, el cual es responsable del siguiente trabajo
preparatorio:
a) obtener copias de las funciones y responsabilidades acordadas del equipo, y el propósito y
alcance del análisis;

b) obtener copias de la descripción del evento de enfoque y los hechos establecidos;

c) decidir la(s) técnica(s) de análisis a utilizar;

d) convertir la descripción del evento de enfoque y los hechos establecidos en un formato

adecuado para su uso en la técnica de análisis seleccionada;

e) desarrollar un plan de análisis;

f) formar el equipo de análisis;

g) facilitar u organizar la capacitación de los miembros del equipo en la técnica de análisis

seleccionada;

h) seleccionar herramientas de software u otras plantillas para usar durante el análisis;

i) disponer que se realice una búsqueda en bases de datos, medios, procesos judiciales, etc. para
identificar eventos de foco de una naturaleza similar, o que pueden haber ocurrido con la misma
tecnología o similar

El líder debe revisar la información disponible para determinar qué técnica(s) de análisis deben
aplicarse y qué habilidades se requieren. Se puede necesitar el asesoramiento de expertos en el
campo de RCA para la selección de la técnica de análisis. El líder también puede requerir un
facilitador experto de RCA para todo o parte del análisis, dependiendo de la complejidad del
evento de enfoque, la complejidad o volumen de evidencia y datos o la técnica de análisis
seleccionada.

El análisis generalmente lo lleva a cabo un equipo, y cada miembro del equipo es elegido por su
experiencia y habilidades. El equipo de análisis debe ser lo más pequeño posible, en consonancia
con la disponibilidad de conocimientos y experiencia técnica y operativa pertinente. En donde se
requieren entradas provenientes de múltiples fuentes, o entidades interesadas, el equipo de
análisis debe contener representantes de cada uno. Es responsabilidad del líder asegurarse de que
las entidades interesadas relevantes estén informadas, de modo que la representación adecuada
de las entidades interesadas esté disponible durante el análisis.

Debe determinarse el rol y las responsabilidades de los miembros del equipo de análisis y también
establecer las metas al inicio del análisis. Se debe desarrollar un programa de reuniones que
refleje los objetivos y metas proporcionados al equipo de análisis. Esto, en última instancia,
permitirá que cualquier recomendación se lleve a cabo de manera oportuna.

El líder debe desarrollar un plan de análisis, que debe contener lo siguiente:

1) descripción del evento de enfoque;

2) funciones y responsabilidades acordadas del equipo, y el propósito y alcance del análisis;

3) una lista de los miembros del equipo y las entidades interesadas a ser representadas;

4) hora, fecha y lugar de las reuniones de análisis;

5) un resumen de los datos disponibles;

6) técnica(s) de análisis a utilizar;

7) programación para capacitar al equipo de análisis en la técnica de análisis seleccionada (si se

requiere);

8) el formato de registro del análisis y los resultados del análisis, incluida la referencia a cualquier
plantilla o herramienta de software a utilizar.

El líder debe disponer de salas adecuadas con ayudas visuales y de registro para la realización
eficiente de las reuniones de análisis. Debe enviarse al equipo de análisis un paquete informativo
que consiste en el análisis del plan y alguna información de referencia esencial previa a la reunión,
para permitirles familiarizarse con la información disponible y la técnica de análisis seleccionada.

El líder debe asegurarse de que exista un sistema de comunicación apropiado para informar y
trasladar los resultados del análisis a los responsables del siguiente paso del proceso RCA (ver 5.5).

5.5 Validación
Se llevan a cabo varias actividades de revisión a lo largo del proceso de RCA para determinar si los
datos recopilados son relevantes y el análisis es representativo de los datos recopilados. Esta
etapa prueba si las causas identificadas en el análisis se pueden corroborar y se pueden intercalar
con el análisis o realizar como una actividad separada. Se puede llevar a cabo una revisión
independiente para evaluar si el análisis está completo y correcto y determinar si se ha cumplido
el propósito del análisis. El método de revisión dependerá de la técnica de análisis utilizada y del
evento de enfoque. En algunos casos se pueden realizar experimentos para repetir la ocurrencia
del evento de enfoque; dónde sea apropiado, deben usarse métodos estadísticos para evaluar el
grado de confirmación de la hipótesis de la causa. Si las causas se validan con la ayuda de la
simulación, se debe tener cuidado para asegurar que la simulación sea representativa.

Durante el análisis puede haber varias hipótesis alternativas de cómo el evento pudo haber
sucedido. Si el objetivo es producir un informe fáctico de las causas, al finalizar el análisis se deben
validar las causas y sólo debe quedar una sola conclusión.

Este paso puede requerir una mayor recopilación de datos para buscar evidencia directa para
apoyar o refutar las causas identificadas. La evidencia puede no estar siempre disponible para
validar completamente todas las posibles causas.
5.6 Presentación de resultados
Los resultados del análisis dependerán del propósito del análisis. Por ejemplo, si el propósito del
análisis es identificar las acciones que, tomadas en conjunto, previenen la ocurrencia posterior de
eventos similares, los resultados del análisis deben identificar acciones correctivas que rompan la
red de causas y evitar que el evento de enfoque vuelva a ocurrir. Si el propósito del análisis es
repetir los éxitos, entonces deben proponerse las acciones que mejoran la probabilidad o las
consecuencias del evento de enfoque. La eficacia de los resultados del análisis depende de la
calidad del análisis.

Se debe desarrollar un formato para presentar los resultados del RCA que resuma el análisis y la
captura de los resultados requeridos del propio análisis, p. ej. acciones recomendadas. Si el
resultado esperado del RCA es producir acciones recomendadas, el resumen debe incluir como
mínimo lo siguiente:

a) una descripción general de cada causa que requiere acción junto con suficiente información de
antecedentes y detalles, para asegurar que la necesidad de abordar cada causa sea entendida y
puedan ser identificadas las acciones a tomar;

b) un conjunto de opciones para tomar acciones de tratamiento y, cuando sea factible, y dentro
del alcance, un resumen de los beneficios y costos de cada uno;

c) acciones recomendadas para abordar cada una de las causas identificadas.

Las acciones correctivas recomendadas deben ser evaluadas por su efectividad y realismo. En
general, las acciones correctivas tienen como objetivo lograr lo siguiente:

• cambiar la probabilidad del evento de enfoque y/o sus consecuencias (es decir, reducir la
probabilidad o consecuencia de eventos indeseables o aumentar la probabilidad o consecuencia
de eventos exitosos);

• no introducir nuevos riesgos inaceptables, p. ej. no debe degradarse la seguridad de otros

sistemas por la acción correctiva propuesta.

Cuando se identifican acciones, estas deben revisarse antes de su implementación para

determinar si no solo han abordado las causas profundas, sino que tampoco han introducido
nuevas consecuencias inesperadas y, por lo tanto, funcionará según lo previsto. También la
recurrencia del mismo evento o uno similar debe monitorearse para evaluar la efectividad de las
acciones tomadas.
6 Selección de técnicas para el análisis de causas
6.1 Generalidades
Se han ideado técnicas formales para ayudar a los analistas a identificar los factores causales y
eventualmente las causas fundamentales. Las técnicas de análisis pueden realizar una o más de las
siguientes funciones:

• organizar los datos y proporcionar estructura al análisis e identificar dónde se necesario

encontrar más pruebas;

• proporcionar una presentación visual de la evidencia relacionada con el evento de enfoque, por
ejemplo, la secuencia del tiempo de los eventos o cadenas causales;

• realizar análisis estadísticos de los datos, particularmente de múltiples eventos similares, para
identificar factores causales comunes;

• proporcionar orientación para identificar posibles factores causales para una mayor
investigación y comparación con datos (tales métodos incluyen listas de verificación y métodos
basados en modelos de causalidad);

• guiar a los analistas a través de la cadena causal hasta un conjunto de causas fundamentales.

6.2 Selección de técnicas de análisis.

RCA se lleva a cabo en diversos grados de profundidad y puede utilizar uno o varias técnicas de
análisis que van desde lo simple a lo complejo. La profundidad del análisis y la(s) técnica(s)
utilizada(s) debe (n) tener las siguientes características:

• ser justificable y apropiado para el evento de enfoque bajo análisis y el alcance y el propósito del
análisis;

• proporcionar resultados que mejoren la comprensión de las causas fundamentales del evento de
enfoque;

• ser capaz de usarse de una manera que sea rastreable, repetible y verificable.

Las técnicas de análisis a utilizar se seleccionan en base a los factores aplicables tales como

• características de la técnica de análisis,

• características del evento de enfoque, p. ej. La gravedad o la posible gravedad o complejidad,

• características de la organización, p. ej. técnicas o costos aprobados por la industria/sector o una

evaluación de costo-beneficio,

• propósito del análisis, p. ej. Los productos requeridos o las expectativas de las partes
interesadas,
• el modelo o modelos de causalidad más adecuados a los objetivos del análisis.

Los atributos de las técnicas de análisis más utilizadas se describen en el Anexo A. Los criterios
utilizados para caracterizar las técnicas, descritos en el Anexo A, son los siguientes:

• experiencia requerida;

• soporte de herramientas;

• escalabilidad;

• representación gráfica;

• modularidad;

• reproducibilidad;

• verificaciones de plausibilidad;

• rigor intelectual;

• secuencia de tiempo;

• especificidad.

Las descripciones detalladas de las técnicas RCA se describen en el Anexo C, que incluye los
métodos y procesos utilizados para cada técnica junto con sus fortalezas y debilidades.

6.3 Herramientas útiles para ayudar a RCA

Las modernas técnicas de minería de datos permiten la búsqueda de propiedades y condiciones
específicas. El análisis de agrupamiento (clustering) selecciona los datos que están estrechamente
relacionados y, por lo tanto, identifica los datos que se desvían (valores atípicos). El análisis de
conglomerados (cluster) moderno puede detectar datos que están estrechamente relacionados en
una, dos o más dimensiones y, por lo tanto, analizar productos o procesos que están
estrechamente relacionados e identificar puntos divergentes de datos (valores atípicos). En el
Anexo D se proporciona una descripción general de estas técnicas.

Muchos eventos de enfoque y técnicas de análisis involucran factores humanos y varias

taxonomías que han sido desarrollados para ayudar a encontrar las causas profundas donde está
involucrado el comportamiento humano. Dos ejemplos se dan en el Anexo E.
 Anexo A (informativo)

Resumen y criterios de las técnicas de RCA comúnmente utilizadas

A.1 Generalidades
El Anexo A enumera las técnicas de RCA más utilizadas, con una breve descripción, y proporciona
una lista de referencia de criterios que se pueden utilizar para comparar diferentes técnicas de
RCA. la lista no es exhaustiva, pero cubre ejemplos de los diferentes tipos de técnicas utilizadas.

A.2 Técnicas RCA

La Tabla A.1 proporciona una lista y una breve descripción de las técnicas de RCA más utilizadas.

Tabla A.1 – Breve descripción de las técnicas RCA

Descripción de la técnica
Gráficos de eventos y factoresEl análisis ECF identifica la secuencia de tiempo de una serie de
causales (ECF) tareas y/o acciones y las condiciones circundantes que conducen
a un evento de enfoque. Estos se muestran en un diagrama de
causa-efecto
secuenciación de eventos MES y STEP son métodos de recopilación y seguimiento de datos
multilineales (MES) y gráfica para el análisis de eventos de enfoque complejo. Los resultados
de eventos cronometrados se muestran como una matriz de tiempo-actor de eventos
secuencialmente (STEP)
El método del “por qué” El método del “por qué” guía el análisis a través de la cadena
causal preguntando la pregunta “por qué” varias veces.
Método del árbol de causas CTM es una técnica sistemática para analizar y representar
(CTM) gráficamente eventos y condiciones que contribuyeron a un
evento de enfoque. CTM es similar al método 'por qué' en
concepto, pero construye un árbol más complejo y
explícitamente considera causas técnicas, organizacionales,
humanas y ambientales
Análisis porqué-porque (WBA) WBA establece la red de factores causales responsables de un
Why-because evento de enfoque utilizando una comparación de dos factores,
la prueba contrafáctica. La red de factores se muestra en un
gráfico de "por qué-porque"
Método de árbol de fallas y El árbol de fallas o éxitos es una visualización gráfica de
árbol de éxito información para ayudar al usuario a realizar un análisis
deductivo para determinar las rutas críticas hacia el éxito o el
fracaso, que se muestran gráficamente en un diagrama de árbol
lógico
Diagrama Espina de pescado o El diagrama de espina de pescado o de Ishikawa es una técnica
Ishikawa que ayuda a identificar, analizar y presentar las posibles causas
de un evento de foco. La técnica ilustra la relación entre el evento
de enfoque y todos los factores que pueden influir en él
Seguridad a través del SOL es una herramienta de análisis basada en listas de
aprendizaje de la organización verificación, orientada a eventos de enfoque en eventos de
(SOL) centrales eléctricas nucleares. Los resultados están en la forma
visual de un diagrama de tiempo-actor, derivado del método
MES/STEP
Supervisión de la gestión y El gráfico MORT es un árbol de fallas rellenado previamente con
árbol de riesgo (MORT) eventos, generalmente fallas o descuidos, expresados en
términos genéricos. El árbol MORT contiene dos principales
ramas y muchas sub-ramas dando un alto nivel de detalle. Una
rama principal identifica alrededor de 130 factores de control
específicos mientras que la otra rama principal identifica más de
100 factores del sistema de gestión. El gráfico también contiene
otros 30 factores del sistema de información comunes a las dos
ramas principales del árbol
AcciMaps AcciMaps es principalmente una técnica para mostrar los
resultados de un análisis causal. Requiere un modelo organizativo
para separar los factores en capas y obtener factores en las
capas; aplica una versión de la prueba contrafactual (ver WBA) a
determinar las relaciones causales entre los factores
Tripod Beta Tripod Beta es una representación de diagrama de árbol de la red
causal, centrándose en factores humanos y buscando fallas en la
organización que puedan causar errores
Modelo Análisis causal para CAST es una técnica que examina todo el proceso socio-técnico
modelos de sistemas teóricos involucrado en un evento de enfoque. CAST documenta el
de accidentes y proceso proceso dinámico que conduce al enfoque de evento, incluida la
(STAMP) (CAST) estructura de control sociotécnico, así como las limitaciones que
fueron violadas en cada nivel de la estructura de control

A.3 Criterios
La Tabla A.2 proporciona una lista y describe los criterios utilizados para caracterizar las técnicas de
RCA enumeradas en la Tabla A.1. Cada criterio tiene tres niveles indicados por un (+), (o) o un (-),
donde los diferentes niveles indican el rango.

Los atributos para cada técnica RCA que utiliza los criterios de la Tabla A.2 se muestran en la Tabla
A.3.

Tabla A.2 – Resumen de los criterios de la técnica RCA

Criterio Descripción Niveles

Pericia requerida ¿El método está dirigido al • Intuitivo, requiere poca
"usuario sofisticado" (¿requiere formación (+)
el uso de técnicas como el • Se requiere capacitación limitada,
teorema que prueba cuál p. ej. un día (o)
requiere experiencia • Es necesario un esfuerzo de
específica)? Es adecuado para formación considerable, p.ej. una
uso exclusivo de expertos en semana (-)
 Criterio Descripción Niveles
dominios?
Soporte de herramientas ¿Es necesario el soporte de • Se puede aplicar bien sin soporte
herramientas? de herramientas dedicado(+)
• No se requiere soporte de
herramientas, pero por lo general
es necesario para una aplicación
efectiva (o)
• Soporte de herramientas
necesario, se puede aplicar
solo con soporte de herramientas
dedicado (–)
Escalabilidad ¿El método es escalable? • Escalas con la complejidad (+)
¿Puede el método utilizarse de • Escalabilidad limitada,
forma rentable para tareas considerables gastos generales con
sencillas y así como para cada aplicación (o)
eventos de enfoque complejos? • No escalable, tiene que ser
¿Puede aplicarse un aplicado el método completo
subconjunto del método a (-)
pequeños eventos de enfoque o
menos significativos y la
capacidad total aplicada a
eventos de enfoque grandes o
significativos? La cuestión de
escalabilidad pregunta si la
complejidad de
análisis utilizando el método
escalas con el
complejidad del evento de
enfoque
Representación gráfica ¿Cuál es la naturaleza del • Representación gráfica con
método representación gráfica? claridad
El principio motivador es que semántica definida y
una imagen es mejor que mil cognitivamente fácil de
palabras. Es a menudo más entender (+)
comprensible mostrar los • Representación gráfica, pero sin
resultados de un método de semántica (o)
análisis como una imagen, un • Sin representación gráfica
gráfico, u otra forma de definida (–)
ilustración, que como
puramente texto escrito.
Las propiedades deseables de
una representación gráfica
Son:
• mostrar claramente la
semántica de causalidad
(incluyendo la denotación de
factores causales y taxonomía
 Criterio Descripción
de factores),
• ser cognitivamente
(relativamente) fácil de evaluar
por una sola persona,
• idealmente, una
representación gráfica también
podría mostrar la historia del
análisis
Reproducibilidad ¿Son los resultados del método
reproducible? ¿Diferentes
analistas
obtienen resultados similares
para el mismo evento de foco?
Chequeos de ¿Existe una plausibilidad rápida
plausibilidad y razonable sobre los resultados
obtenidos que son
independientes de la
herramienta? que formas hay
de comprobar la "corrección"
de los resultados? Un ejemplo
podrían ser las listas de
verificación
Rigor intelectual ¿Qué tan riguroso es el
método? El rigor tiene dos
aspectos relevantes:
• ¿El método tiene un
significado riguroso, semántica
formal, para la nociones clave
del factor causal y causa raíz?
¿La semántica es fácil de
aplicar?
• ¿Los resultados del método
son susceptibles de verificación
formal (matemático)? ¿En qué
medida es un aplicación del
método por lo que
¿dócil?
Secuencia de tiempo ¿El método contiene una
representación de la secuencia
Niveles
• Los resultados se pueden
reproducir, sólo se observan
diferencias en la representación de
los resultados, redacción, etc.
(+)
• puede reproducirse una cantidad
significativa de los resultados, pero
se pueden observar algunas
diferencias (o)
• Los resultados dependerán de la
experiencia del analista (-)
• Hay verificaciones de
plausibilidad para casi
todos los aspectos (+)
• Hay comprobaciones de
plausibilidad, p. ej. listas de
verificación, pero no
necesariamente cubrir todos los
aspectos (o)
• Sólo existen medios limitados que
soportan las verificaciones de
plausibilidad (–)
• Definido formalmente y puede
ser formalmente
verificado (+)
• Definición semiformal (o)
• Definición informal (–)
• Sí (+)
• Solo indirectamente (o)
 Criterio Descripción
de tiempo de los eventos?
Especificidad La medida en que el método
limita el análisis a los factores
causales necesarios del evento
de enfoque en lugar de explorar
un rango de problemas
generales con el sistema que
existía en el momento del
evento de enfoque y pudo
haber contribuido
Niveles
• No (-)
• El método solo analiza los
factores causales necesarias del
evento de enfoque (+)
• El método se puede utilizar para
analizar factores contribuyentes,
así como
factores causales necesarios del
evento de enfoque(o)
• El método busca problemas en
general si eran o no factores
causales necesarios del evento de
enfoque(–)
 Tabla A.3 – Atributos de las técnicas genéricas de RCA

Pericia requerida Representación Verificaciones Rigor

Soporte de Escalabilida gráfica Reproducibilidad Secuencia de Especificidad
de plausibilidad intelectual
herramienta d tiempo
ECF o o o  o o o + 
MES and STEP – o o   o o  
The ‘Why’
  – o – – – – 
Method
CTM o o +  o o o – 
WBA o  o     o 
Método del árbol
de fallas y del o o o  o o o – o
árbol de éxitos
Diagrama de
espina de   – o – o – – o
pescado o
Ishikawa
SOL o –  o   o  o
MORT  – – o  o o – –
Acci Maps o o o  – o – – o
Tripod Beta –  o  o o o o o
CAST    o o o o  
NOTA: E l c r i t e r i o p ar a c ad a a t r ib ut o s e de sc r i be n e n la T a bl a A. 2.
 Anexo B (informativo) Modelos RCA
B.1 Generalidades
Este anexo describe los modelos RCA más utilizados que brindan diferentes formas de pensar
sobre los eventos de enfoque. Los diferentes modelos se basan en ciertas hipótesis con
respecto al evento de enfoque, p. ej. el análisis de barreras asume que el evento de enfoque
ha ocurrido como resultado de barreras faltantes, fallidas o ineficaces. Por lo tanto, los
diferentes modelos tienden a llevar al investigador a identificar diferentes factores causales.
Los modelos se utilizan para dirigir el pensamiento junto con las técnicas del Anexo C, o
simplemente para identificar un conjunto de factores causales.

B.2 Análisis de barreras

B.2.1 Resumen

El análisis de barreras se basa en la hipótesis de que un evento de enfoque ocurre como

resultado de la interacción de una fuente de daño en un objetivo y que esto puede prevenirse
mediante el uso de barreras. Un evento indeseable ocurre cuando las barreras faltan, fallan o
son ineficaces (consulte la Figura B.1).

Objetivo

Fuente de daño

Barrera Barrera Barrera Barrera Barrera

fallada perdida fallada no perdida
efectiva
Figura B.1 – Barreras rotas, ineficaces y faltantes que causan el evento de enfoque

Haddon [3] consideró eventos de enfoque en los que la fuente del daño es la energía física y
las barreras se relacionan con la forma en que la energía se puede modificar o evitar que incida
sobre el objetivo. El modelo se ha ampliado de varias maneras [4], por ejemplo, las barreras a
menudo se dividen en barreras físicas y barreras administrativas (consulte la Tabla B.1 para ver
algunos ejemplos). Las barreras también se pueden considerar en términos de prevención,
protección y detección (por ejemplo, en el contexto en el que el evento principal es un
incendio, se utilizarían materiales no inflamables, se proporcionarían extintores de incendios y
se instalarían detectores de humo).

El resultado del análisis generalmente incluye una hoja de trabajo de análisis de barreras
(consulte la Tabla B.2), que identifica aquellas barreras que estaban disponibles pero no eran
efectivas o no estaban en su lugar durante la ocurrencia del evento de enfoque.
 Tabla B.1 – Ejemplos de barreras

Barreras físicas o de energía Barreras Administrativas

Funciones de seguridad diseñadas de ingeniería Procedimientos de operación y mantenimiento de
la planta.
Dispositivos de seguridad y alivio Reglamentos, políticas y prácticas
Concesiones de diseño conservador Entrenamiento y educación
Equipo redundante Protección del trabajo
Puertas y válvulas bloqueadas Permisos de trabajo
Dispositivos de protección contra fallas a tierra Personal con habilidades
Blindaje y guardias Métodos de comunicación (comunicación de 3
vías)
Alarmas Prácticas de supervisión
Sistemas automáticos de contención de incendios

Tabla B.2 – Ejemplo de hoja de trabajo de análisis de barreras

Resultado no Fuente del daño Barrera(s) que Mecanismo de falla Evaluación de la barrera
deseado (¿qué deberían haber de la barrera (por qué fallaron las
sucedió?) impedido el evento (cómo falló la barrera) barrera(s)
no deseado
Identifique si la
Enumere uno a la Listar todos las bareras barrera estaba
vez, no es necesario físicas y administrativas ausente, era débil
que esté en orden para cada resultado no o ineficaz; y por
secuencial deseado qué

Líquido presurizado Procedimiento de Liberación de Etiquetado poco

presión en sistema claro
equivocado
El Trabajador de apagar la bomba
mantenimiento
aflojó tuercas en la
brida de y liberar
la tubería que presión antes de
comenzar el trabajo
fue presurizada

B.2.2 Fortalezas y limitaciones

Los puntos fuertes del análisis de barrera son los siguientes:

• identifica qué acciones correctivas se requieren para garantizar que se implementen las
barreras adecuadas (número y efectividad).

Las limitaciones del análisis de barrera son las siguientes:

• puede que no reconozca todas las barreras fallidas o faltantes, o el efecto de la tasa o
frecuencia con la que se desafían las barreras;

• aborda los factores causales inmediatos en lugar de las causas fundamentales, es decir,
busca qué barrera falló y cómo, pero no explora el por qué en profundidad.
B.3 Modelo de Reason (modelo de queso suizo)
B.3.1 Resumen

El modelo de Reason [5] se basa en la premisa de que los elementos básicos requeridos de
cualquier sistema productivo son:

• decisiones apropiadas de la planta y la gerencia corporativa,

• actividades de gestión de línea, capacitación en operaciones y mantenimiento, etc.,

• equipos fiables y aptos para su uso,

• mano de obra motivada,

• integración de elementos humanos y mecánicos,

• salvaguardas contra riesgos previsibles.

Inevitablemente, existen debilidades en estos elementos que pueden considerarse fallas

latentes. Si estos se juntan para formar un evento desencadenante, que puede no ser
importante en otras circunstancias, esto da como resultado una falla.

Las debilidades en los elementos del sistema productivo se representan como “agujeros en
rebanadas de queso suizo”. Un evento resultará cuando todas las debilidades individuales se
alineen. El modelo de Reason no es estrictamente un modelo de barrera ya que las capas son
sistemas operativos normales con debilidades en lugar de barreras o controles fallidos.

Se han desarrollado taxonomías de errores humanos basadas en el modelo de Reason para

varias industrias diferentes.

B.3.2 Fortalezas y limitaciones

Los puntos fuertes del modelo de Reason son los siguientes:

 alienta al analista a explorar los factores causales del error del operador y, por lo tanto, los posibles
medios para reducirlo.

Las limitaciones del modelo de Reason son las siguientes:

 análisis superficial de los factores causales técnicos o ambientales que considera los aspectos
técnicos sólo en términos de barreras fallidas;
 asume que el problema central es el error del operador (los errores en otros niveles y las fallas
organizacionales se exploran principalmente en términos de cómo influyen en el error del
operador);
 no proporciona una taxonomía para ayudar con la identificación de motivaciones y precursores
psicológicos del error humano o en la identificación de fallas latentes y, por lo tanto, requiere
experiencia en psicología individual y organizacional para usar correctamente.
B.4 Modelos de sistemas
La teoría de sistemas [6] se desarrolló en las décadas de 1940 y 1950 para manejar el aumento de la
complejidad de los sistemas después de la Segunda Guerra Mundial y para considerar los aspectos
sociales y técnicos de los sistemas como un todo.

En los modelos de sistema, se supone que la interacción humana con la tecnología en estructuras
sociales complejas está influenciada por los objetivos, la política y la cultura de la organización y por
elementos económicos, legales, políticos y ambientales internos y externos. Este sistema está acentuado
por el rápido ritmo del cambio tecnológico, por un entorno cada vez más agresivo y competitivo, y por
factores como las prácticas regulatorias cambiantes y la presión pública. En este contexto, los eventos
de enfoque se deben a múltiples factores y, por lo general, están "en espera de liberación" y no se
deben a ningún acto o evento.

Las fallas surgen debido a las complejas interacciones entre los componentes del sistema que pueden
conducir a la degradación del rendimiento del sistema. Dos o más eventos discretos dentro de los
elementos del sistema pueden interactuar de formas inesperadas, lo cual, los diseñadores no podrían
haber predicho y los operadores no pueden comprender o controlar sin un modelo o prueba
exhaustivos. Los factores que contribuyen al evento de enfoque pueden incluir efectos de decisiones
que son normales en las circunstancias en las que se tomaron, pero que producen un resultado no
deseado.

Los métodos basados en un modelo de sistemas no buscan una cadena causal ni buscan errores
individuales o fallas técnicas, sino que consideran el sistema como un todo, sus interacciones y sus
debilidades. Se pueden reconocer fallas humanas o de hardware individuales, pero la atención se centra
en las interacciones y los problemas sistémicos.

B.5 Modelo de accidentes teóricos de sistemas y procesos (STAMP)

B.5.1 Resumen

STAMP [7] es un modelo de causalidad basado en la teoría de sistemas [6] que amplía el modelo
tradicional (cadenas de eventos de falla directamente relacionados) para incluir, tanto los
contribuyentes técnicos como sociales para enfocar los eventos y sus relaciones. También captura
eventos de enfoque que involucran interacciones entre componentes y procesos del sistema que no
fallan, mecanismos causales indirectos y sistémicos, toma de decisiones complejas de operadores y
gerentes, tecnología avanzada como sistemas digitales y software y fallas en el diseño del sistema.

STAMP asume que los incidentes surgen de interacciones entre humanos, máquinas y el medio
ambiente; trata los sistemas como problemas de control dinámico en los que los controles tienen como
objetivo gestionar las interacciones entre los componentes del sistema y su entorno. El objetivo del
control es hacer cumplir las restricciones sobre el comportamiento de los componentes del sistema, por
ejemplo, las aeronaves en un sistema de control de tráfico aéreo, deben mantener siempre una
distancia mínima de separación. Los eventos de enfoque son el resultado de un control o aplicación
inadecuados de las restricciones en el desarrollo, diseño y operación del sistema. En la pérdida del
transbordador espacial "Challenger", por ejemplo, las juntas “o-ring” no controlaron la liberación de gas
propulsor a través de la junta de campo del transbordador espacial. En STAMP, la causa de un evento de
foco es una estructura de control defectuosa.

STAMP también incorpora el concepto de que los incidentes a menudo surgen de una migración lenta
de todo el sistema hacia un estado de alto riesgo [8] de tal manera que las presiones financieras y de
otro tipo que conducen a un cambio de comportamiento a lo largo del tiempo puedan tenerse en
cuenta en el proceso de análisis causal.

B.5.2 Fortalezas y limitaciones

Los puntos fuertes de STAMP son los siguientes:

 considera el papel de todo el sistema sociotécnico en la causalidad;

 incluye factores indirectos y sistémicos en la explicación causal;
 proporciona un modelo para explicar accidentes en sistemas muy complejos;
 identifica las causas hacia atrás del proceso con el que se desarrolló un sistema.

Las limitaciones de STAMP son las siguientes:

 requiere que los eventos de enfoque se analicen de una manera que a menudo no es familiar para
los ingenieros, por lo tanto, puede llevar más tiempo aprender a analizar eventos de enfoque
utilizando procesos de análisis causal basados en STAMP.
 Anexo C
(informativo)

Descripción detallada de las técnicas RCA

C.1 Generalidades
El Anexo C describe una variedad de técnicas utilizadas durante un RCA. La lista no es exhaustiva, pero
cubre ejemplos de los diferentes tipos de técnicas utilizadas. Muchas de estas técnicas están
respaldadas por herramientas de software. Algunas de las metodologías y herramientas de software
tienen elementos registrados como marcas comerciales, lo que puede afectar el costo de
implementación de la técnica.

Algunas técnicas apuntan a identificar los factores causales, que se puede demostrar, que son
necesarios para que ocurra el evento de enfoque. Otros métodos buscan debilidades generales del
sistema como un todo, que probablemente contribuyeron al evento de enfoque, pero donde el evento
de enfoque podría haber ocurrido en su ausencia. En algunas terminologías, un "factor causal" no puede
describirse así a menos que sea necesario para el evento de enfoque. En este anexo, dichos factores
causales se denominan “factores causales necesarios”. Las debilidades identificadas que pueden haber
desempeñado un papel en el evento de enfoque, pero que pueden no ser necesarias para él, se
denominan "factores contribuyentes".

En general, la identificación de los factores causales necesarios será repetible y se basará en pruebas.
Puede haber un mayor nivel de subjetividad en la identificación de factores contribuyentes y diferentes
técnicas de análisis con un enfoque diferente pueden identificar diferentes factores.

C.2 Gráficos de eventos y factores causales (ECF)

C.2.1 Resumen

La tabla ECF [9] registra eventos en orden cronológico de izquierda a derecha en rectángulos, con
eventos caracterizados por sujetos únicos y verbos activos. Cada evento se deriva estrictamente del
anterior. Las condiciones necesarias para los eventos se muestran en óvalos por encima y por debajo de
la secuencia de eventos (las condiciones son estados o circunstancias en lugar de sucesos). Los eventos
están conectados por líneas sólidas y las condiciones por líneas discontinuas. Los eventos y condiciones
basados en evidencia tienen un contorno sólido, mientras que aquellos que son presuntivos tienen un
contorno discontinuo. Puede haber secuencias de eventos múltiples o ramificadas, cada una con sus
propias condiciones.

La Figura C.1 ilustra un ejemplo de una carta ECF en la que se realizó incorrectamente una actividad de
mantenimiento debido a que el trabajador de mantenimiento se presentó tarde, lo que provocó un
aterrizaje de emergencia realizado por una aeronave.
 La tripulación
Vuelo previsto decide comenzar Temperatura ambiente
para las 09:00 la preparación exterior 15 °C
del vuelo

Vuelo retrasado Aeronave salió

El equipo de inspección no
en espera de del hangar para
prepararse para alcanza la temperatura
inspección ambiente
el vuelo

09:15 01/10/12 09:20 01/10/12

El mantenedor El mantenedor
El El mantenedor Aeronave
El encargado ignora el lleva a cabo la Aeronave
mantenedor recoge el realiza aterrizaje
llega tarde al requisito de tarea de declarada en El motor falla
recibe tareas equipo de emergencia
trabajo inspección del inspección en el servicio
requerido
hangar motor

09:05 01/10/12 09:50 01/10/12 10:30 01/10/12 13:00 01/10/12 13:20 01/10/12

Temperatura
No hay otros ambiente de
mantenedores almacenamiento
disponibles del equipo 25 ºC

Figura C.1 – Ejemplo de un gráfico ECF

C.2.2 Proceso

A continuación, se describe el proceso para desarrollar un gráfico ECF:

a) Identifique el evento de enfoque y regístrelo en un cuadro en el lado derecho.

b) Registre la cadena primaria de eventos que condujo al evento de enfoque donde cada evento en la
cadena es tanto inmediato como necesario para el evento del lado derecho. Por lo tanto, la
consecuencia se registra en el lado derecho de cada evento (factor causal). Además, la
consecuencia de un evento anterior puede ser el factor causal del próximo evento. Los eventos se
muestran en rectángulos vinculados por flechas a la derecha del evento de enfoque.
c) Determinar qué condiciones llevaron a estos eventos. Indique cada uno de ellos en un óvalo sobre
el evento relevante.
d) Agregar cadenas secundarias de eventos que puedan ser relevantes para el evento de enfoque y sus
condiciones.
e) Comprobar la validez de los factores causales mediante la obtención de pruebas que determinen si
las condiciones y hechos son ciertos.
f) Desarrollar el gráfico ECF hasta que se identifique el evento al comienzo de la secuencia y se
agreguen todas las condiciones que puedan verificarse mediante evidencia.

En general, la cronología exacta de los hechos no se conoce al comienzo de la investigación, pero se

vuelve más clara a medida que avanza la investigación. Por lo tanto, se debe utilizar un método que
permita a los investigadores cambiar fácilmente la secuencia de eventos y condiciones, a medida que se
obtiene más información.

C.2.3 Fortalezas y limitaciones

Los puntos fuertes de ECF son los siguientes:

 ayuda a la verificación de cadenas causales y secuencias de eventos;

 proporciona una estructura para recolectar, organizar e integrar evidencia;
 identifica lagunas de información;
 ayuda a la comunicación proporcionando una ayuda visual eficaz que resume la información clave
sobre el evento de enfoque y sus causas.

Las limitaciones de ECF son las siguientes:

 identifica algunos factores causales, pero no necesariamente determina las causas fundamentales;
 puede ser demasiado complicado para problemas simples.

C.3 Secuenciación de eventos multilineales (MES) y trazado de

eventos cronometrados secuencialmente (STEP)

C.3.1 Resumen

MES [10] y STEP [11] son métodos desarrollados para analizar eventos de foco en sistemas complejos,
donde STEP es un sucesor de MES.

Al igual que con los gráficos ECF, MES/STEP concibe un evento de enfoque como el que surge de una
sucesión interrelacionada de eventos con eventos caracterizados por un solo sujeto y un verbo activo.
En MES y STEP, el sujeto se denomina actor (que puede ser un ser humano, una máquina o incluso una
propiedad).

Los eventos se representan como bloques de creación de eventos (BB), que consisten en registros de
datos (parciales o completos) como se describe en la Figura C.2. Estos se organizan durante el análisis en
una matriz de tiempo-actor donde el eje vertical de la matriz representa a los diferentes actores y el eje
horizontal representa el tiempo.

La matriz tiempo-actor también contiene:

 condiciones necesarias para habilitar un evento junto con eventos precursores;

 anotaciones para tareas posteriores en una investigación, como una nota que indica un déficit de
información o una explicación incompleta de un evento.

En la Figura C.3 se da un ejemplo que muestra parte de la representación de un evento de

mantenimiento de un tanque.

FUENTE DE DATOS ELEMENTOS DE CONSTRUCCIÓN DE MES ESTANDARIZADOS

INFORMES DE TESTIGOS CAMBIOS DE
ATRIBUTOS REGISTROS DEL
INSTRUMENTO
PRUEBAS RESIDUOS MOVIMIENTOS
OBSERVACIONES DECLARACIONES
DECISIONES INSTRUCCIONES
LESIONES ESCOMBROS OTROS
ACTOR
ACCIÓN
OBJETO/DESCRIPTOR UBICACIÓN
OBSERVACIONES FUENTE
FECHA/HORA DE INICIO DURACIÓN
FECHA/HORA DE FINALIZACIÓN
ENLACES DESDE/HASTA N/S ESTADO
Persona, objeto o energía que hizo algo
Lo que hizo el actor
Datos adicionales que definen la acción
Ubicación donde comenzó la acción
Para comentarios sobre BB o
investigación Fuente de datos utilizada
en la creación de BB Fecha y hora en
que comenzó la acción
Duración de la acción
Fecha y hora en que finalizó la acción
Enlaces que definen interacciones entre
BBs Estado de validación de entrada
necesaria/suficiente

Figura C.2 – Datos en un bloque de construcción de eventos

C.3.2 Proceso

MES/STEP tiene los siguientes pasos:

a) Reúna información para la serie inicial de bloques de construcción e identifique y rastree la
información faltante.
b) Organice los bloques de construcción iniciales en una matriz de tiempo-actor inicial.
c) Identificar y generar hipótesis para "llenar" los vacíos con eventos (en forma de bloques de
construcción adicionales).
d) Terminar el proceso cuando un analista considere que se dispone de información suficiente en la
matriz tiempo-actor.

C.3.3 Fortalezas y limitaciones

MES/STEP tiene las mismas ventajas y limitaciones que ECF. El formateo de datos es relativamente más
elaborado y existen mecanismos explícitos para determinar y rastrear los datos faltantes e intentos de
determinar esos datos. Algunos de estos mecanismos de “contabilidad” son necesarios para gestionar
investigaciones complejas con múltiples investigadores. La matriz de tiempo-actor también tiene una
notación explícita para registrar el estado de una investigación en curso junto con la adquisición de
datos y las tareas explicativas aún por realizar. Esto significa que una representación visual comprensible
del estado de una investigación está disponible en todos los puntos de una investigación.
 Actores Bloques de construcción del evento

Presión interna La presión interna voló

Presión la cubierta del tanque
sobrecargada
interna hacia arriba y hacia el
norte
Reporte A Pagina Y Reporte A Pagina Z

Técnico de Técnico de
Técnico de Tecnico de mantenimiento Tecnico de
Mantenimiento Mantenimiento mantenimiento
mantenimiento equipo firmado procedió a la ubicación A posicionado en location A
tornillos quitados al
tanque
registro de aislamiento Reporte A Pagina X Inferido del escenario cubrir con la
herramienta C

Reporte A Pagina X

Operador A
accompañado del Operator A positionado
Operator A personal de en location B
mantenimiento para
asistir con la tarea
Reporte A Pagina X Inferido de lesiones

¿Por qué el operador

se puso en riesgo?

05:30:00 05:30:30 05:35:00 05:37:00 05:37:30

Figura C.3 – Ejemplo de matriz tiempo-actor
C.4 El método del “por qué”

C.4.1 Resumen

El método del "por qué" utiliza un proceso de preguntas sencillo para llegar a las causas fundamentales.

El interrogatorio comienza con una declaración de la situación y pregunta por qué ocurrió. La respuesta
a esta pregunta se convierte en una segunda pregunta “por qué” y la respuesta a esta en una tercera
pregunta. El cuestionamiento cesa cuando se alcanza la regla de parada. En general, esto requiere
aproximadamente 5 niveles de preguntas, por lo que el método a veces se conoce como “los 5 por qué”.

Cuando una pregunta de por qué proporciona varios factores causales, se explora cada uno y el método
produce un árbol de por qué.

El método del por qué se usa solo para situaciones simples, pero también es inherente a métodos de
árbol más complejos, como el método del árbol de causas (CTM) (consulte la Cláusula C.5). Puede ser
útil para obtener información de los testigos sobre cómo y por qué ocurrió un evento porque la simple
pregunta "por qué" no hace suposiciones sobre la causa ni guía al testigo.

La figura C.4 ilustra un ejemplo de un compresor que experimentó una parada no programada. En el
ejemplo, el cuarto por qué sugirió una serie de posibles factores causales de la falta de lubricación y se
buscó evidencia para definir cuáles ocurrieron de hecho. Aunque hubo un error humano en el que una
persona no siguió los procedimientos de arranque especificados, la recomendación es mejorar el diseño
para que los motores del compresor y la bomba estén conectados. Un análisis más profundo de por qué
ocurrió el error, en este caso, no es útil.
 Evento de enfoque

El compresor experimenta una apagado no programado

Porqué 1

Apagado por un sistema de control automático

Porqué 2
Rodamiento sobrecalentado

Porqué 3

Falta de lubricación

Porqué 4

Flujo de lubricación Fuga de lubricación Bomba de lubricación Nivel bajo de aceite de

restringido no funciona lubricación

No es causa No es causa

Las hojas de registro La inspección no

mostraban mostró fugas
diferenciales de
presión normales
Porqué 5

No encendido por persona de mantenimiento No encendido automáticamente

Porqué 6 Porqué 6
La persona de mantenimiento sabía pero olvidó Diseñado para tener un Manual de operación
que el compresor en particular necesitaba una separado
activación separada del aceite lubricante

Figura C.4 – Ejemplo de un árbol de por qué

C.4.2 Proceso

El método 'por qué' tiene los siguientes pasos:

 Identifique y registre el evento de enfoque como el comienzo de un diagrama de 'por qué'.

 Preguntar por qué ocurrió el evento de enfoque, buscando sólo los factores causales inmediatos.
 Preguntar “por qué” sucesivamente con respecto a la respuesta anterior. En cada caso, la respuesta
a la pregunta "por qué" debe ser un factor causal inmediato de la respuesta anterior.

La pregunta "por qué" se hace tantas veces como sea necesario para llegar a una causa raíz, que
normalmente son cinco preguntas, pero esto es solo una guía. Cada vez que se hace la pregunta, puede
haber múltiples respuestas y será necesario algún análisis para eliminar aquellas posibles respuestas que
no sean aplicables. Puede ser más efectivo preguntar "¿por qué falló el proceso?" en lugar de
simplemente preguntar "¿por qué?".

Puede ser útil considerar un conjunto de categorías de causas como las del método Ishakawa e
involucrar a un equipo de personas. Esto ayudará a asegurar que los investigadores consideren todas las
áreas relevantes.

C.4.3 Fortalezas y limitaciones

Los puntos fuertes del método "por qué" son los siguientes:

 simple de aplicar por los involucrados en el problema;

 fácil de entender por los demás;
 proceso rápido para lograr resultados para problemas simples;
 no requiere un conocimiento extenso de la persona que hace las preguntas;
 no requiere mucho entrenamiento de la persona que hace las preguntas.

Las limitaciones del método 'por qué' son las siguientes:

 solo apto para situaciones sencillas;

 depende en gran medida del conocimiento y la experiencia de las personas que respondan las
preguntas, ya menudo se requiere experiencia tanto en los modos de falla técnica como en el error
humano para llegar a las causas fundamentales;
 es probable que se pasen por alto las causas fundamentales si están fuera de la base de
conocimientos de los involucrados;
 posible incertidumbre acerca de cuándo se han identificado las causas raíz apropiadas;
 puede desarrollarse hasta el nivel en el que se consideran las razones de las acciones de las
personas, donde la evidencia a menudo no está disponible y, por lo tanto, los resultados no siempre
son repetibles.

C.5 Método del árbol de causas (CTM)

C.5.1 Resumen

CTM [12] es una técnica sistemática para analizar y representar gráficamente los eventos y condiciones
que contribuyeron a un evento de enfoque.

El método examina todos los componentes del sistema asociados con el evento de enfoque. La
investigación comienza por establecer los hechos tangibles, cuidando, en esta fase, de no interpretarlos
ni emitir una opinión sobre ellos.

CTM es similar al método por qué en concepto, pero construye un árbol más complejo y considera
explícitamente los factores causales técnicos, organizacionales, humanos y ambientales. Cada
antecedente (factor causal identificado) se contrasta para comprobar que es un factor causal inmediato
y necesario del anterior, mientras que el método del por qué es menos riguroso. Por lo tanto, CTM es
adecuado para situaciones más complejas.
CTM también es similar a un árbol de fallas, pero, mientras que un árbol de fallas se usa antes de un
evento para explorar todos los posibles factores causales y se especifican relaciones lógicas estrictas
entre las fallas, el árbol de causas incluye solo aquellos factores causales que se aplican a un evento.
evento específico que ya ha ocurrido y no desarrolla las relaciones lógicas en detalle.

Se puede usar un árbol de causas para explorar tanto los éxitos como los fracasos.

El árbol de causas forma una red de las causas que directa o indirectamente han causado el evento de
enfoque, utilizando las tres relaciones lógicas que se muestran en la Figura C.5.

Secuencia: Una causa (Y) tiene un único origen directo (X).

es decir, (X) era necesario y suficiente para que (Y)
ocurriera
X Y

Conjunción: Una causa (Y) tiene varios orígenes directos

(X1) y (X2). Eso significa que cada uno de los orígenes directos
(X1) y (X2) fue necesario para que (Y) ocurra X1
Y

X2
Disyunción o separación: dos o más causas
(Y1;Y2, …) tienen un único e idéntico origen directo (X).
Eso significa que (X) era necesario para (Y1) y (Y2)
Y1
a ser producido.
X

Y2

Figura C.5 – Símbolos y enlaces utilizados en la CTM

La Figura C.6 muestra un árbol de ejemplo, en el que el Sr. L (la víctima) y el Sr. A trabajan de noche,
como excepción, para almacenar un excedente de existencias. De acuerdo con el manual, el Sr. L y el Sr.
A debían cargar la trituradora con "harina", que luego se embolsa y almacena. Normalmente esta
actividad está a cargo de un jefe de equipo cuya presencia no había sido considerada imprescindible por
la dirección para esta noche. Por su propia iniciativa para ahorrar tiempo, el Sr. L tomó una carretilla
elevadora (la llave de encendido había permanecido en el tablero como de costumbre) para guardar las
bolsas. Al final de la tarea, el Sr. L se dispuso a devolver la carretilla elevadora. El Sr. L tomó una curva
pronunciada en reversa, con las horquillas levantadas, y mientras intentaba evitar un agujero en el
suelo, la carretilla elevadora se volcó, aplastando al Sr. L entre el suelo y el montante derecho de
seguridad del camión.
 Un agujero está L conduce
presente en el alrededor del
camino del agujero en el
montacargas suelo

L pone el
montacargas de L está en el
vuelta a donde suelo
estaba

L & A han
terminado de
L gira mientras El montacargas L es expulsado
almacenar las
retrocede se vuelca del montacargas
bolsas (fin del
trabajo)
L queda
L está en el aplastado entre
L pone el camino de las el suelo y el
montacargas a horquillas montante de
distancia derechas del seguridad
montacargas derecho de la
carretilla
L usa el
L & A deciden montacargas
tomar prestado para almacenar
el montacargas las bolsas

L conduce el L da marcha El montante derecho

montacargas atrás con las del montacargas está
solo muy horquillas presente
ocasionalmente levantadas
Figura C.6 – Ejemplo de un árbol de causas
C.5.2 Proceso

CTM tiene los siguientes pasos:

a) Identifique el evento de enfoque a analizar y regístrelo como punto de partida para el árbol.
b) Recopilar y registrar todos los datos pertinentes, incluidas las personas, sus actividades y acciones,
los materiales y equipos y los factores relacionados con el entorno físico y psicosocial.
c) Hacer una lista de los factores causales del evento foco. Estos deben estar respaldados por pruebas
y expresarse con la mayor precisión posible. No se incluyen opiniones y juicios subjetivos. Los
factores causales incluyen aquellos que son inusuales o cambian el curso normal de los eventos y
aquellos que son normales, pero jugaron un papel activo en la ocurrencia del evento.
d) Trabajar hacia atrás, hacia las causas profundas, formulando sistemáticamente las siguientes
preguntas para cada antecedente que se haya recopilado:
1) ¿qué antecedente X ha causado directamente el antecedente Y?;
2) ¿era X en sí mismo necesario para dar lugar a Y?;
3) Si no, ¿cuáles son los otros antecedentes (X1, X2...) que fueron igualmente necesarios para dar
lugar directamente a Y?
e) Muestre estos factores causales necesarios inmediatos en un cuadro vinculado por una flecha al
evento de enfoque. El árbol se puede dibujar horizontal o verticalmente, pero normalmente se
dibuja horizontalmente comenzando desde la derecha, de modo que de izquierda a derecha
corresponde a la cronología de los eventos.
f) Continúe haciendo las mismas preguntas con respecto a cada factor causal necesario encontrado
hasta que el equipo esté de acuerdo en que no tiene valor continuar más.
g) Comprobar la validez del árbol obteniendo pruebas adicionales que determinen si es verdadero.

C.5.3 Fortalezas y limitaciones

Los puntos fuertes de CTM son los siguientes:

 proporciona un método para estructurar la investigación de eventos complejos;

 facilita un formato fácil de leer;
 se puede utilizar para fomentar la participación del grupo;
 identifica áreas para recopilar datos a medida que avanza la investigación;
 se puede utilizar para analizar eventos de éxito o fracaso;
 se puede utilizar para eventos técnicos y no técnicos.

Las limitaciones de la marca comunitaria son las siguientes:

 muchos factores humanos y organizacionales pueden contribuir a que ocurra el evento de enfoque
y, a menudo, es difícil establecer cuáles en un caso particular fueron los factores causales
necesarios;
 no hay orientación sobre cómo buscar factores causales; por lo tanto, se necesita experiencia en
errores humanos y sistemas organizacionales cuando el árbol involucra fallas humanas y
organizacionales, donde la evidencia a menudo es difícil de obtener;
 es difícil de aplicar cuando un evento ocurre como resultado de un cambio de calidad en varias
áreas, donde ningún factor causal único es un factor causal necesario.
C.6 Análisis por qué-porque (WBA)
C.6.1 Resumen

WBA [13] es una técnica causal-analítica para establecer cuáles de una colección dada de eventos y
situaciones son factores causales necesarios. Dados dos eventos o situaciones, A y B digamos, se usa una
condición llamada prueba contrafactual (CT) para establecer si A es un factor causal necesario de B.
Supongamos que se han observado dos eventos o situaciones A y B. El TC pregunta si, de no haber
ocurrido A, tampoco habría ocurrido B. (Dado que A ocurrió, la suposición de que A no ocurrió es
contraria a los hechos, de ahí la palabra “contrafactual”). Al hacer esta pregunta, se supone que todas
las demás condiciones han permanecido iguales. Si la respuesta es sí: B no habría ocurrido, entonces A
es un factor causal necesario de B. Si la respuesta es no: B podría haber ocurrido de todos modos,
incluso si A no hubiera ocurrido (el CT falla), entonces A no es un factor causal necesario de B.

La red de factores causales se muestra como un gráfico Why-because (WBG), una colección de “nodos”,
recuadros, rombos y otras formas, que contienen una breve descripción del hecho, unidos por “aristas”
o flechas, donde el nodo en la cola de una flecha es un factor causal necesario del nodo en su cabeza,
según lo determinado por el CT.

Un WBA es acíclico (no contiene bucles), por lo que generalmente se dibuja con flechas que apuntan
generalmente hacia arriba, como se muestra en la figura C.7, u horizontalmente con flechas que
apuntan generalmente de izquierda a derecha o de derecha a izquierda.

Para determinar si hay suficientes factores causales en la colección de eventos y situaciones

presentadas, se utiliza la prueba de completitud causal (CCT). El CCT se aplica a un evento o situación
dada y su colección de factores causales necesarios según lo determinado por el CT. Si no se pasa el CCT,
entonces la colección de eventos y situaciones debe extenders por otros factores hasta que se supere.
Supongamos que A1, A2,...,An han sido determinados como factores causales necesarios de B por el CT.
Entonces el CCT se considera superado si, de no haber ocurrido B, tampoco hubiera ocurrido uno de A1,
A2,..., An (formalmente, NOT-B es una condición necesaria) factor causal de NOT( A1 AND A2 AND...AND
An) según lo determinado por el CT).

Cuando se ha construido un WBG y se aprueba el CCT para todos los eventos y situaciones en él,
entonces el WBG está completo y se considera que representa una explicación causal suficiente del
evento de enfoque.

La Figura C.7 ilustra un ejemplo de un WBG para un accidente de desbordamiento de pista de aviación
comercial.
 (11) Aeronave choca contra
banco de tierra

(13)Banco de tierra en (12) Aeronaves sobrevuelan la pista

ruta de
desbordamiento

(15)Aproximación no
(16)Construido por la estabilizada (14)Frenado retrasado
autoridad aeroportuaria
para equipos de radio

(18)Acciones de la tripulación (17)Frenado de rueda

retrasado

(20) Hidroplaneo

(19)Retraso en el despliegue de
los frenos de velocidad y los
(25) Bajo peso en cada rueda inversores de empuje
dentada principal
(24)Pista muy mojada

(21)Divergencia entre las

consecuencias del diseño y el
comportamiento esperado por la
(30)Velocidad excesiva tripulación
en el aterrizaje (23)Diseño lógico de los
(27)Estado de la superficie de la (28)Las condiciones (29)Cantidad de agua en la sistemas de frenado (22)Aterrizaje real
pista climáticas superficie de la pista

(26)Comportamiento
esperado por la
tripulación

(34)Acciones de las tripulaciones

ante la expectativa de cizalladura

(31)Formación de (32)Trámites de la (33)Comportamiento “normal”'

tripulaciones en la empresa empresa X esperado por la tripulación
X

Figura C.7 - Ejemplo de WBG

C.6.2 Proceso

WBA tiene los siguientes pasos:

a) Determinar un conjunto de hechos que se consideren relevantes, bajo la guía de una regla de
parada. Esto da una colección inicial C de hechos, divididos en eventos, estados y situaciones.
b) Seleccione el evento de enfoque (llamado en WBA el evento de accidente).
c) Determinar intuitivamente los factores causales necesarios inmediatos del evento foco de entre la
colección C; verificar usando el CT. Muestre los resultados visualmente como un WBG parcial.
d) Determinar intuitivamente los factores causales necesarios de esos factores inmediatos; verificar
usando el CT. Ampliar el GBM con estos factores.
e) Proceda a completar el análisis (para ampliar el GBM) contrastando cada hecho en C con los
factores que ya están en el GBM.
f) Aplicar la CCT para determinar si el GBM está completo o si faltan factores en la colección C.
g) Extender C si es necesario; incorporar los nuevos hechos en el GBM usando el CT. Si la información
disponible es insuficiente, se pueden incluir supuestos, siempre que estén claramente etiquetados
como tales.
h) Terminar cuando el CCT muestre suficientes causales para cada hecho, de conformidad con la regla
de cesación. Si no se dispone de suficientes datos, se deben incluir supuestos para permitir que la
TMC tenga éxito, pero claramente etiquetados como tales.

C.6.3 Fortalezas y limitaciones

Las fortalezas de WBA son las siguientes:

 puede realizarse con un mínimo de capacitación (con el uso de herramientas adecuadas que
brindan ayuda para extraer hechos de descripciones narrativas, un analista inexperto generalmente
puede realizar un WBA de primer paso dentro de dos horas);
 los resultados del análisis son fácilmente comprensibles para terceros;
 la base conceptual requerida para realizar un WBA es limitada (un analista debe ser capaz de aplicar
el CT y luego el CCT);
 cualquier red de fenómenos causalmente relacionados puede ser analizada con un WBA;
 el razonamiento detrás de una WBA puede verificarse formalmente utilizando una lógica formal;
 se puede utilizar junto con otros métodos, p. las que aportan más estructura a la recopilación de
hechos.

Las limitaciones de WBA son las siguientes:

 el método no proporciona orientación sobre la recopilación de hechos a los que se aplican las
pruebas p.ej. no hay una estructuración de los hechos en categorías como técnicas,
procedimentales, factores humanos, organizacionales y legales;
 debido a que los hechos no están estructurados, la WBA proporciona una guía limitada sobre la
acción correctiva en el caso de que sea necesario prevenir la recurrencia.

C.7 Método del árbol de fallas y del árbol de éxitos

C.7.1 Resumen

Un árbol de fallas [14] muestra los factores causales necesarios inmediatos de un evento de enfoque,
sus predecesores causales y las relaciones lógicas entre ellos. El análisis de árbol de fallas (FTA) [15] se
usa normalmente como un método a priori para identificar y analizar posibles modos de falla,
particularmente de equipos. El diagrama de árbol de fallas se puede usar en RCA construyendo un árbol
siguiendo la misma lógica, pero incluyendo en el árbol solo aquellos eventos que realmente ocurrieron.

Las puertas OR pueden usarse durante el análisis para describir factores causales alternativos que deben
evaluarse, pero cuando todos los hechos están claramente establecidos, solo deben permanecer
puertas AND, a menos que el propósito de la investigación sea prevenir otros eventos relacionados. Por
lo tanto, a medida que avanza la investigación, los posibles factores causales que no se ajustan a la
evidencia se descartan gradualmente y se eliminan del árbol. Al cerrar cada rama del árbol, los factores
causales del evento de enfoque se hacen evidentes.

Estrictamente, un árbol de fallas representa eventos binarios donde una declaración es verdadera o
falsa, p. un componente falló o no. En RCA, la estructura del árbol de fallas a menudo se aplica a un
árbol de factores causales donde las reglas lógicas no se obedecen estrictamente y se incluyen cambios
en la calidad, así como eventos binarios.

Se puede aplicar una lógica similar cuando el evento de enfoque es un éxito. En este caso, el árbol se
denomina árbol de éxito.

La Figura C.8 muestra un ejemplo de un árbol de fallas.

Falla la alarma de
incendio
 Falla la señal a las Falla el detector de
Falla la
solenoides humo
campana

Figura C.8 – Ejemplo de árbol de fallas durante el análisis

Sin fuente de Interrupción Pequeña
Falla la Falla la fuente
C.7.2 alimentación
Proceso en el circuito Corto circuito
solenoide
sensibilidad al
fotoeléctrica
humo

El proceso para desarrollar un árbol de errores/éxitos es el siguiente:

a) Defina el evento de enfoque a analizar y regístrelo como punto de partida para el árbol.
b) Establecer los factores causales necesarios inmediatos del evento de enfoque y mostrarlos en un
cuadro vinculado por una flecha al evento de enfoque. El árbol se puede dibujar horizontal o
verticalmente. Estos son los factores causales de primer nivel del evento de enfoque.
c) Establecer las relaciones lógicas entre los factores causales inmediatos utilizando AND y OR Gates.
Falla la batería Fallo de red
Los eventos en las entradas de una puerta AND deben ser necesarios y suficientes para causar el
evento anterior. Las puertas OR pueden usarse durante el análisis para describir factores causales
potenciales que requieren investigación.
d) Examinar cada factor causal para decidir si es una causa raíz o el resultado de factores causales
subyacentes.
e) Validar los posibles factores causales y actualizar el árbol en consecuencia.
f) Continúe descendiendo por el árbol hasta alcanzar la regla de parada.

Cuando se desarrolla el árbol, se considera la posibilidad de factores causales relacionados con las
personas, el equipo y el medio ambiente para cada factor causal en cada nivel. Estos no deben separarse
en la parte superior del árbol.

C.7.3 Fortalezas y limitaciones

Los puntos fuertes del método del árbol de errores/éxitos son los siguientes:

 proporciona un método para dividir el análisis de eventos de enfoque grandes y complejos;

 respaldado por muchos paquetes de software comerciales que ayudan en el desarrollo de la
estructura del árbol de fallas;
 fomenta la participación del grupo;
 utiliza un formato ordenado y fácil de leer;
 identifica áreas para recopilar datos.

Las limitaciones del método del árbol de errores/éxitos son las siguientes:

 requiere un profesional experimentado;

 no tiene un modelo subyacente de causalidad y no brinda orientación sobre cómo buscar factores
causales;
 no representa fácilmente situaciones en las que ocurre un evento como resultado de un cambio
general de calidad que afecta, por ejemplo, el cumplimiento de los procedimientos o las tolerancias
de los componentes físicos.

C.8 Diagrama de espina de pescado o de Ishikawa

C.8.1 Resumen

El diagrama de espina de pescado (Fishbone) o Ishikawa [16] es una técnica que ayuda a identificar,
analizar y presentar las posibles causas de un evento de foco. Se puede utilizar para estructurar una
sesión de lluvia de ideas y para sugerir ideas en las que se pueden buscar más pruebas. La técnica fue
inventada por Kaoru Ishikawa e ilustra gráficamente la relación entre un evento y todos los factores que
influyen en él. Esta técnica también se conoce como "diagrama de espina de pescado" debido a su
apariencia.

La figura C.9 muestra un ejemplo de diagrama de espina de pescado o de Ishikawa.

Metodos Maquinaria

Causa
Reason Reason Causa
Razón Razón Causa

Efecto

Cause Causa Causa

Razón
Causa
Causa Causa Causa

Administración Materiales Mano de

obra

Figura C.9 – Ejemplo de diagrama de espina de pescado

C.8.2 Proceso

El proceso para desarrollar un diagrama de Fishbone o Ishikawa es el siguiente:

a) Identifique el evento de enfoque y regístrelo en el lado derecho y dibuje una línea horizontal desde
él. Esto forma la cabeza y la columna vertebral de un pez.
b) Establecer las principales categorías de causas a considerar y trazar líneas en el lomo para
representar cada categoría. Las categorías comúnmente utilizadas incluyen:

1) 5Ms: métodos, maquinaria, gestión, materiales, mano de obra;

2) 4Ps: lugar, procedimientos, personas, políticas;
3) 4Ss: entorno, proveedores, sistemas, habilidades.

c) Para cada categoría identificar los posibles factores causales del evento foco. Estos se presentan
como líneas más pequeñas que salen de las 'espinas' del pescado. Los niveles cada vez más
detallados de los factores causales se pueden mostrar como sub-ramas que salen de cada línea de
causa. Puede ser necesario dividir el diagrama en diagramas más pequeños si una rama tiene
demasiadas subramas.
d) Analizar el diagrama: El diagrama ahora muestra todos los posibles factores causales del evento de
enfoque. El paso final es investigar los factores causales más probables que comprueban si el
análisis es correcto. El análisis incluye:

1) revisar el "equilibrio" del diagrama, verificando los niveles de detalle comparables para
identificar la necesidad de una mayor identificación de los factores causales;
2) identificar los factores causales que aparecen repetidamente, ya que estos pueden representar
causas fundamentales;
3) evaluar qué se puede medir en cada causa para cuantificar los efectos de los cambios
realizados;
4) destacando los factores causales cuya acción se puede tomar.

C.8.3 Fortalezas y limitaciones

Los puntos fuertes del diagrama Fishbone o Ishikawa son los siguientes:

 fomenta la participación del grupo para identificar las percepciones de las personas sobre los
factores causales;
 busca factores causales en un conjunto de categorías, por lo que identificará una variedad de
factores causales relacionados con factores humanos y organizacionales, así como factores de
hardware y de procedimiento;
 utiliza un formato ordenado y fácil de leer;
 indica posibles factores causales de variación;
 puede usarse para investigaciones simples o como parte de una investigación más compleja.

Las limitaciones del diagrama Fishbone o Ishikawa son las siguientes:

 no existe un modelo subyacente o una teoría de causalidad, por lo que los factores causales
identificados se basan en las percepciones del equipo.

C.9 Seguridad a través del aprendizaje organizacional (SOL)

C.9.1 Resumen

SOL [17] es una técnica de análisis de eventos, que busca debilidades en el complejo sistema socio-
técnico en el que ocurrió el evento. El propósito de SOL es proporcionar un modelo del sistema e
identificar sus debilidades para que pueda mejorarse y prevenir la recurrencia del evento de enfoque. El
énfasis está en el aprendizaje organizacional.

C.9.2 Proceso

SOL tiene los siguientes pasos:

1) Describa la situación usando una matriz de tiempo-actor producida por MES/STEP (ver Cláusula
C.3).
2) Identificar los factores causales (que pueden ser directos o indirectos ver Tabla C.1) para cada
evento en la matriz tiempo-actor, guiados por listas de verificación de preguntas derivadas de la
experiencia e investigación de los autores de SOL. Los factores causales directos son aquellos que
 inmediatamente dieron como resultado el evento de enfoque, los factores causales indirectos
aparecen más abajo en la cadena causal, pero pueden involucrar los mismos problemas.
3) Clasificar los factores causales en tecnología, individuos, grupo de trabajo, organización y ambiente
organizacional.
 Tabla C.1 – Factores causales directos e indirectos

Factores causales directos Factores causales indirectos

Información Información
Comunicación Comunicación
Las condiciones de trabajo Las condiciones de trabajo
desempeño personal desempeño personal
Violaciones Violaciones
Componentes técnicos Planificación
Responsabilidad
Control y supervisión
influencia del grupo
Normas, procedimientos y documentos
Calificaciones
Capacitación
Organización y gestión
Principios de seguridad
Gestión de la calidad
Mantenimiento
Organismos reguladores y consultivos
Influencias medioambientales

C.9.3 Fortalezas y limitaciones

Los puntos fuertes de SOL son los siguientes:

 el formato de lista de verificación permite a los usuarios que no son especialistas en sistemas
organizacionales o psicología organizacional producir análisis útiles;
 el énfasis en los factores causales en lugar de los factores causales necesarios permite tener en
cuenta más factores de los que podría hacer un análisis estrictamente causal y, por lo tanto, ofrece
más posibilidades de identificar posibles mejoras;
 el formato de los bloques de construcción de eventos da menos alcance al juicio de los analistas
individuales y ayuda a dar uniformidad a los análisis SOL;
 la regla de interrupción está definida implícitamente por las preguntas de la lista de verificación:
cuando se han respondido, la información se considera adecuada.

Las limitaciones de SOL son las siguientes:

 no existe una noción específica de lo que es un factor causal más allá de lo que está implícito en las
preguntas de la lista de verificación;
 el nivel de detalle depende de la lista de control predeterminada de preguntas y no de la necesidad
percibida;
 la lista de verificación de preguntas se derivó de la investigación en la industria de la energía nuclear
y puede ser menos adecuada para otras industrias.
C.10 Control de gestión y árbol de riesgos (MORT)

C.10.1 Resumen

MORT [18] se desarrolló por primera vez para analizar las causas fundamentales y los factores causales
de los incidentes en las industrias de energía nuclear y aviación en los EE. UU., pero ahora se ha aplicado
en muchas industrias.

MORT es un árbol rellenado previamente basado en un modelo del sistema de gestión de una
organización, que proporciona una lista de verificación detallada para revisar qué partes de los sistemas
de gestión y control eran menos que adecuadas cuando ocurrió el evento de enfoque. La estructura
básica del árbol se muestra en la Figura C.10.

Pérdida de daños
por accidentes

Omisiones de Riesgos
supervisión aceptados

Factores de Sistema de
control gestión

Y O

Accidente Mejora Evaluación de

Política Implementación
riesgos
Y

Incidente Barreras Gente en canal

de energía
Incidentes Flujo de
anteriores energía
O

Sistemas de Diseño y Disponibilidad Supervisión

Mantenimiento
información planificación operacional

Figura C.10 – Ejemplo de diagrama MORT

MORT asume que una falla ocurre como resultado de descuidos u omisiones en los sistemas de gestión
o en los factores de control específicos que deberían haber evitado que ocurriera el evento de enfoque.

En última instancia, las fallas en cualquiera de las ramas del árbol ocurren porque algo dentro de los
sistemas de administración general (sistemas de información, diseño y planificación, preparación
operativa, mantenimiento o supervisión) no fue adecuado. Cada cuadro en la Figura C.10 se desarrolla
en una estructura de árbol detallada que muestra los factores que podrían haber sido menos que
adecuados.

C.10.2 Proceso

Comience con el evento de enfoque y luego trabaje en el árbol MORT de manera lógica preguntando y
respondiendo a las preguntas previas en el manual MORT. Los símbolos en la tabla MORT están
codificados por colores para indicar:
 no hay problema con un elemento (adecuado);
 el elemento está dando lugar a un problema (menos que adecuado);
 hay necesidad de más investigaciones.

C.10.3 Fortalezas y limitaciones

Los puntos fuertes de MORT son los siguientes:

 proporciona una guía integral para buscar todos los posibles aspectos del sistema que no eran
adecuados en el momento del evento de enfoque;
 se necesita menos experiencia especializada que en algunas técnicas porque se proporciona una
guía detallada sobre los posibles factores causales;
 identifica las debilidades en el sistema que podrían aplicarse en una amplia gama de escenarios de
falla.

Las limitaciones de MORT son las siguientes:

 explora las debilidades del sistema en general que podrían haber jugado un papel en el evento de
enfoque en lugar de buscar factores causales inmediatos o necesarios;
 se hace un gran número de preguntas (alrededor de 1 500), por lo que el método requiere mucho
tiempo y, por lo tanto, es más apropiado para eventos graves;
 a menos que la organización a la que se aplica sea una organización de alta confiabilidad, se
encuentra una gran cantidad de debilidades que dificultan la implementación de cambios;
 tedioso cuando se aprende o aplica el método por primera vez.

C.11 AcciMaps
C.11.1 Resumen

AcciMaps [19] se basa en los conceptos de causalidad publicados por Rasmussen y Svedung [20] y el
modelo de sistemas organizacionales (ver Cláusula B.4).

AcciMaps es una representación gráfica utilizada para estructurar el análisis de un evento de enfoque y
para identificar las interacciones en el sistema sociotécnico en el que ocurrió el evento de enfoque. Es
un método diseñado para revelar las fallas, decisiones y acciones de todo el sistema involucradas en un
evento de enfoque. Estos están dispuestos en capas que representan los diferentes niveles en un
sistema sociotécnico desde el gobierno hasta el equipo y el entorno involucrado. También analiza a los
actores individuales en cada nivel y sus rutinas de toma de decisiones y competencia.

En la Figura C.11 se muestra un ejemplo de AcciMap para una explosión de gas, que muestra los niveles
típicos del sistema. El nivel inferior representa la disposición física de la escena del evento de enfoque
(edificios, equipos, alrededores, etc.). El siguiente nivel es la secuencia de eventos que conducen al
evento de enfoque, incluidas las fallas, las acciones y las decisiones (incluidas las acciones y decisiones
normales) que desempeñaron un papel. Los niveles superiores muestran decisiones y acciones en cada
nivel que influyeron o podrían haber influido en la secuencia de eventos en los niveles inferiores.

C.11.2 Proceso

Un AcciMaps se desarrolla de la siguiente manera:

a) Definir un modelo del sistema con diferentes niveles organizativos.

b) Rellene los niveles (usando recuadros (nodos)) con las decisiones y acciones relevantes al evento de
enfoque, las condiciones que conducen a ellas y sus consecuencias.
c) Dibujar flechas que muestren todos los vínculos e influencias.
d) Se puede agregar un proceso como WBA para determinar cuáles de los problemas identificados
fueron factores causales necesarios del evento de enfoque.
Nivel del sistema

Política y El cambio de gobierno ralentizó la Fuerzas del mercado

presupuesto social legislación sobre riesgos mayores
y gubernamental

Organismos reguladores
y asociaciones No hay regulación para la Acuerdo sindical que da
seguridad de las a las operadoras más
instalaciones en tierra responsabilidad

Administración No hay evaluación de

de la compañía riesgos de cambios en
La auditoría no detectó la organización
Sin identificación y Sistema de gestión de problemas en los
análisis de los integridad de operaciones procedimientos operativos Decisión de centralizar
principales peligros inadecuado o cómo se siguieron Ingeniería, por lo que no
hay ingenieros en el sitio

Dirección
técnica y Las licencias y las Menos Operadores y
Manual de No hay plan de
operativa Trabajo atrasado enfermedades supervisores - Sin función de supervisores conscientes
procedimientos de Problemas de contingencia por
de mantenimiento significaron la en gran parte vigilancia de la de los efectos de
operación de planta comunicación - falla de una
ausencia de varias administrativo planta producción, no sobre la
inadecuado todos los niveles planta
personas clave s no técnicos seguridad

Proceso físico
Escasa comprensión
y actividades
Válvula de control Problema no de las implicaciones
Bomba de de las acciones para
aceite caliente de temperatura diagnosticado
automática fallida correctamente detener la fuga
disparada

Acumulación y El
Flujo de El procedimiento de intercambiador Aceite tibio 3 semanas apagado
desbordamiento de
condensado reinicio manual falló de calor se Fuga de gas reiniciado para por pérdida de
condensado
superior al normal enfrió mucho tratar de suministro
Flujo de aceite reducir la fuga Explosión
frío continuo
2 muertos8
Anular no activado Procedimiento Fractura del heridos
Fragilización
de anulación del acero intercambiador
desconocido de calor

Equipo y entorno
Mezcla de sistema de Algunas condiciones de Solo es La planta que operaba en El cierre de Interconexione
Tecnología de Diseño del posible una los extremos del rango emergencia del s de plantas
control informático funcionamiento de la planta
planta modificada sistema de supervisión significaba muchas diseño antiguo mal
moderno y neumático mostradas por los registradores
para operar más control remota parcial alarmas molestas exacerbó el daño documentadas
original a menudo no funcionan
allá del rango de
diseño
C.11.3 Fortalezas y limitaciones

Los puntos fuertes de AcciMaps son los siguientes:

 como no hay taxonomía ni orientación, AcciMaps tiene el potencial de ser muy completo en la
identificación de factores causales en todos los niveles del sistema;
 los vínculos dentro y entre los niveles ayudan a asegurar que las fallas se consideren en el contexto
de las cosas que las influenciaron;
 el error humano tiene el mismo enfoque que el equipo y los factores organizativos de nivel
superior;
 no se incluyen los factores personales que influyen en las decisiones, particularmente en los niveles
inferiores.

C.11.3 Fortalezas y limitaciones

Las limitaciones de AcciMaps son las siguientes:

 la falta de una taxonomía significa que los factores identificados se basan en la percepción del
equipo;
 el modelo organizativo proviene de fuera del análisis y no existe un criterio que asegure que es
adecuado;
 el resultado del análisis de AcciMaps está ligeramente limitado, por lo que es posible derivar
diferentes AcciMaps para el mismo evento de enfoque;
 sin una taxonomía específica, es difícil agregar múltiples análisis para encontrar factores comunes;
 la generalidad de los factores en los nodos suele ser alta y puede ser muy abstracta. Esto hace que
sea difícil derivar acciones precisas;
 tiene un enfoque analítico débil para las fallas físicas y de equipos;
 no representa los resultados de un análisis causal por sí mismo.

C.12 Trípode Beta

C.12.1 Resumen

Tripod Beta [21] es una metodología de investigación y análisis de incidentes que combina las ideas del
modelo de Reason (consulte la cláusula B.3) y el análisis de barreras (consulte la cláusula B.2), junto con
el sistema de modelado de errores genéricos (GEMS) de Rasmussen y el trípode de Wagenaar. camino
de causalidad. Describe los incidentes en términos de "objetos", p. personas, equipos, etc. que están
siendo modificados por “agentes de cambio”, p. cualquier cosa con el potencial de cambiar un objeto.
También modela 'barreras', mostrándolas, por ejemplo, como efectivas, fallidas o inadecuadas.

Tripod Beta proporciona un formato y reglas para modelar los eventos (evento de enfoque y los eventos
previos y posteriores al evento de enfoque) y vincular cada elemento, trabajando en última instancia
hasta las causas subyacentes. Se han desarrollado varios paquetes de software basados en estas reglas,
pero se pueden usar con o sin software. Las técnicas basadas en software contienen listas de verificación
derivadas de los modelos y del análisis de eventos pasados, principalmente en la industria petrolera
costa afuera.

El núcleo de un análisis de trípode es una representación de diagrama de "árbol" de la red causal

(consulte la Figura C.12) que describe el evento de enfoque como una red de eventos y sus relaciones.
 Causa Condición
subyacente previa

Causa
inmediata

Condición
previa

Agente

Agente-evento

Barrera fallida
Evento

Objeto

Objeto

Barrera fallida

Causa Condición Causa

subyacente previa inmediata

Figura C.12 – Ejemplo de un diagrama de árbol Tripod Beta

C.12.2 Proceso

El proceso para desarrollar el diagrama de árbol Tripod Beta es identificar lo siguiente:

a) El agente (peligro o peligros) que condujo al evento de foco y el objetivo que fue dañado.
b) Controles o barreras, faltantes o fallados, que pudieran haber evitado el evento o protegido el
objetivo.
c) Causas inmediatas - el acto humano, que resultó en la falla de la barrera. Estas son fallas o errores
que tienen un efecto inmediato y ocurren en el punto de contacto entre un ser humano y un
sistema (por ejemplo, presionar un botón incorrecto, ignorar una luz de advertencia).
d) Condiciones previas: precursores psicológicos y situacionales, p. el tipo de falla humana (desliz,
lapso, violación, etc.).
e) Causas subyacentes (fallas latentes) en la organización, es decir, deficiencias en el sistema de
gestión, cultura, etc. Estos pueden clasificarse en "factores de riesgo básicos" predefinidos,
derivados de la lluvia de ideas y la investigación de los resultados de auditorías e investigaciones de
accidentes en la industria petrolera costa afuera.

C.12.3 Fortalezas y limitaciones

Los puntos fuertes de la metodología Tripod son los siguientes:

 proporciona un mapa del evento de enfoque y sus factores causales;

 puede ayudar a dirigir la investigación y definir su alcance;
 define las barreras en el sistema;
 basado en investigaciones científicas que incluyan un modelo de comportamiento humano para
descubrir qué hay detrás del comportamiento observado;
 lleva al investigador a considerar las razones detrás de las causas inmediatas y el error humano;
 El software controlado por menú está disponible.

Las limitaciones de la metodología Tripod son las siguientes:

 puede requerir muchos recursos;

 conduce a causas subyacentes a nivel del sistema que una organización podría no ser capaz de
aceptar;
 el uso de los factores de riesgo básicos para categorizar las causas subyacentes puede ser
demasiado genérico y simplista;
 las conclusiones no conducen a acciones correctivas simples;
 generalmente se requiere una amplia formación.

C.13 Análisis causal usando STAMP (CAST)

C.13.1 Resumen

CAST [7] es una técnica que examina todo el proceso sociotécnico involucrado en un evento focal. CAST
se basa en STAMP (consulte la Cláusula B.5), que se utiliza para guiar el análisis causal. CAST documenta
el proceso dinámico que condujo al evento de enfoque, incluida la estructura de control sociotécnica, así
como las restricciones que se violaron en cada nivel de la estructura de control y por qué. El análisis
genera múltiples vistas del evento de enfoque, según la perspectiva y el nivel desde el que se visualiza el
evento de enfoque.

Para ilustrar CAST, considere un evento de enfoque relacionado con la contaminación de un suministro
público de agua con E. coli en un pequeño pueblo de Canadá. La Figura C.13 muestra la estructura de
control de seguridad para el abastecimiento de agua de la localidad. Hay tres sistemas físicos que se
están controlando: el sistema de pozos, el suministro de agua y la salud pública. Cada componente de la
estructura que controla estos procesos tiene responsabilidades específicas relacionadas con la
seguridad. Por ejemplo, el Ministerio del Medio Ambiente proporciona supervisión y control de los
sistemas de agua locales. Cada componente de la estructura de control recibe retroalimentación sobre
el estado del proceso que está controlando. Una causa común es que el controlador recibe
retroalimentación incorrecta y piensa que el estado del proceso controlado es diferente de lo que es.
Por ejemplo, se recortaron presupuestos y el Ministerio del Interior redujo el número de inspecciones e
inspectores.

La Figura C.14 muestra el análisis del rol del departamento de salud local en el evento de enfoque,
incluidos los roles y responsabilidades, las acciones de control inseguras, el contexto en el que se
proporcionaron las acciones de control inseguras y las fallas en el proceso (control mental) modelo que
contribuyó al comportamiento. La Figura C.15 muestra lo mismo para otro componente de la estructura
de control, la gestión de operaciones del sistema de agua.

En un análisis completo, cada componente de la estructura de control se consideraría con respecto a su

contribución al evento de enfoque. En la mayoría de los eventos de enfoque, se pueden encontrar
contribuciones de cada componente de la estructura de control.
Otras características del análisis (que no se muestran) incluyen el examen de los cambios dinámicos a lo
largo del tiempo en el sistema, que contribuyeron al evento de enfoque y el papel de la comunicación y
coordinación defectuosas.
 Reportes Reportes Informes de hospitales, aportes de la comunidad médica

Informes de inspección
del Ministerio de
Presupuestos, leyes Ministerio de Educación (MOE)
salud Departamento médico de Avisos, advertencias
Política regulatoria Salud pública
salud
Regulaciones

Directrices Solicitudes
Reportes Muestras de
federales de estado
agua e informe
Gobierno Laboratorio de pruebas
del gobierno
Reportes Muestras de agua Contaminantes
Reportes

inspección y otros informes Medición de cloro residual

Presupuestos, leyes
Ministerio del
Política regulatoria medio Certificados de aprobación
ambiente del boletín de cloración Sistema de agua
(MOE)
Certificación del operador
(MOE)
Reportes Operaciones
de la PUC de
Políticas la ciudad Agua
Comisionados de
la Comisión
Ministerio de Municipal de
agricultura, Servicios
Cloración Pozo 7Defecto de Pozo 5Defecto de
alimentos y Públicos (PUC)
asuntos Selección de pozos diseño: sin cloradordiseño: ubicación poco
Presupuestos, leyes rurales profunda
Lecho rocoso
porosoSobrecarga
Vigilancia mínimaLluvias intensas
Solicitudes de
queja por Granja
información

Residentes
de la ciudad

Figura C.13 – Estructura de control para el suministro de agua en un pequeño pueblo de Canadá
 Departamento medico de salud
Requisitos y restricciones de seguridad:
 Proporcionar supervisión de la calidad del agua
potable.
 Seguimiento de los informes de calidad adversa del
agua potable
 Emitir hervir agua y otros avisos si la salud pública
está en riesgo
Contexto en el que se tomó la decisión:
 Informes más recientes sobre la calidad del agua de
más de 2 años
 Enfermedad que surge en comunidades fuera de la
ciudad
 E. coli se propaga más comúnmente a través de la
carne
Acciones de control inadecuadas:
Figura C.14 – Ejemplo de análisis causal CAST para el Departamento de Salud local
Gerencia de operaciones PUC Municipal
Requisitos y restricciones de seguridad:
 Supervisar las operaciones para garantizar que se
lleven a cabo la toma de muestras y la elaboración de
informes.
 Mantenga registros precisos
 Actualizar conocimientos según sea necesario
Contexto en el que se tomó la decisión:
 Quejas de los ciudadanos por el sabor a cloro en el
agua potable
 Las actividades impropias fueron una práctica
establecida durante 20 años.
 Carecían de capacitación y experiencia adecuadas
Acciones de control inadecuadas:
 Inadecuado seguimiento y supervisión de las
operaciones
 Los resultados adversos de las pruebas no se informan
cuando se les pregunta
Figura C.15 – Ejemplo de análisis causal CAST para la gestión de operaciones de servicios públicos
locales
 Aviso retrasado
 El aviso debería haberse difundido más ampliamente
 El inspector de salud pública no dio seguimiento al
informe de inspección de 1998
Defectos del modelo mental:
 Pensé que se estaban recibiendo informes de calidad
del agua adversa
 Desconoce los informes de E. coli vinculados al agua
tratada
 Pensé que el Sr. K estaba diciendo la verdad
 Desconocimiento del mal estado de las operaciones
locales de agua
Coordinación
 Supuso que el ministerio de medio ambiente era
asegurando que se resolvieron los problemas del
informe de inspección
 Problemas descubiertos durante las inspecciones no
rectificados
 Respuesta inadecuada después de los primeros
síntomas en la comunidad
 No mantuvo registros adecuados de capacitación u
operaciones
Defectos del modelo mental:
 Las fuentes supuestas para el sistema de agua eran
generalmente seguras
 Pensé que el agua no tratada era segura para beber
 No entendía los riesgos para la salud que plantea el
agua clorada
 No entendía los riesgos de los contaminantes
bacterianos como E. coli
 No creía que las directrices fueran una alta prioridad
C.13.2 Proceso

CAST tiene los siguientes pasos:

a) Identifique los sistemas involucrados en el evento de enfoque.

b) Identificar las restricciones del sistema asociadas con el evento de enfoque.
c) Documentar la estructura de control existente. Esta estructura incluye las funciones y
responsabilidades de cada componente de la estructura, así como los controles provistos o creados
para ejecutar sus responsabilidades y la retroalimentación relevante (si la hay) proporcionada para
ayudarlos a hacerlo.
d) Determinar los eventos próximos que conducen al evento de enfoque.
e) Analizar el evento foco a nivel del sistema físico. Identifique la contribución de cada uno de los
siguientes a los eventos: controles físicos y operativos, fallas físicas, interacciones disfuncionales,
fallas de comunicación y coordinación, y perturbaciones no controladas. Determinar por qué los
controles físicos establecidos fueron ineficaces.
f) Subiendo los niveles de la estructura de control, determine, como sigue, cómo y por qué cada nivel
superior sucesivo permitió o contribuyó al control inadecuado en el nivel actual.
1) Para cada restricción del sistema, la responsabilidad de hacerla cumplir nunca se asignó a un
componente en la estructura de control o uno o más componentes no ejercieron el control
adecuado para garantizar que las responsabilidades asignadas se hicieran cumplir en los
componentes debajo de ellos.
2) Identificar decisiones inseguras o acciones de control, incluyendo acciones proporcionadas por
software, operadores, administradores, reguladores, etc.
3) Cualquier decisión humana o acción de control defectuosa debe entenderse en términos de la
información disponible para el tomador de decisiones, así como cualquier información que no
estaba disponible, los mecanismos de configuración del comportamiento (el contexto y las
influencias en el proceso de toma de decisiones), el estructuras de valor subyacentes a la
decisión, y cualquier falla en los modelos de proceso (modelos mentales) de quienes toman las
decisiones y por qué existieron esas fallas.
g) Examinar la coordinación y la comunicación generales (incluida la retroalimentación faltante) que
contribuyeron al evento de enfoque.

Aunque el proceso se describe en términos de pasos, no es necesario que sea lineal ni que se complete
un paso antes de iniciar el siguiente.

C.13.3 Fortalezas y limitaciones

Los puntos fuertes de CAST son los siguientes:

 mira hacia atrás en el tiempo para determinar cómo evolucionó el sistema hasta un estado de alto
riesgo;
 identifica los factores sociales y administrativos y no solo las operaciones humanas o las fallas del
sistema técnico;
 No impone ninguna teoría social particular sobre el análisis, cualquier modelo de comportamiento
social podría usarse para generar los resultados del análisis.

Las limitaciones de CAST son las siguientes:

 no es posible presentar gráficamente el análisis, ya que la inclusión de relaciones indirectas entre

factores causales significa que los círculos y flechas (que representan relaciones directas) no son
adecuados para describir todos los factores causales;
 puede requerir más recursos y tiempo para comprender completamente el evento de enfoque que
otros métodos con un enfoque más limitado.
 Anexo D
(informativo)

Herramientas útiles para ayudar al análisis de causa raíz (RCA)

D.1 Generalidades
El Anexo D describe herramientas y técnicas que pueden apoyar la realización de RCA.

D.2 Técnicas de agrupación y minería de datos

D.2.1 Resumen

Las modernas técnicas de minería de datos permiten la búsqueda de propiedades y condiciones

específicas. El análisis de agrupamiento selecciona datos que están estrechamente relacionados y, por lo
tanto, identifica datos que se desvían (valores atípicos). El análisis de conglomerados moderno puede
detectar datos que están estrechamente relacionados en una, dos o más dimensiones y, por lo tanto,
analizar productos o procesos que están estrechamente relacionados e identificar puntos de datos que
se desvían (valores atípicos).

En RCA, la minería de datos y el análisis de agrupamiento pueden brindar pistas valiosas y ayudar a
confirmar o rechazar posibles causas raíz. En algunos casos, p. equipo aeroespacial y médico, es
necesario almacenar los números de lote de los productos terminados y los números de lote de los
componentes asociados y los números de lote de la materia prima. Esta información puede
proporcionar una estructura útil para identificar correlaciones que sugieran posibles relaciones causales.

D.2.2 Ejemplo 1

Una empresa observa un 12 % de fallas en los artículos almacenados. El análisis muestra que una pieza
de plástico está rota. El inicio del patrón de falla del 12 % se identifica como un número de lote y una
fecha de fabricación. Esta fecha se correlaciona con los lotes entregados de las piezas de plástico. No
hay correlación. Tampoco existe correlación con los lotes de materias primas plásticas. Sin embargo,
existe una correlación con los lotes de un resorte que cargan la pieza de plástico. El problema comenzó 3
días después de recibir un nuevo lote de resortes. Se investigan los cambios que se hicieron entre los
dos lotes de resortes. La diferencia es un nuevo tratamiento superficial contra la corrosión. Este proceso
de tratamiento de superficie se investiga y contiene una nota de que este tratamiento puede interferir
con ciertos materiales plásticos. Un análisis más detallado muestra que la protección contra la corrosión
acelera la propagación de grietas en este plástico. El análisis de la ficha técnica del material plástico
muestra una advertencia de sobrecarga local que puede provocar fisuras. La conclusión por tanto es que
se puede formular una hipótesis causal: que una pieza de plástico se sobrecarga continuamente y se
fractura por sobrecarga local, y las fracturas se propagan de forma acelerada por el nuevo tratamiento
anticorrosión de los resortes. Estas grietas luego se propagan de manera acelerada debido al nuevo
tratamiento anticorrosión de los resortes. Un análisis de falla mostró previamente un patrón en la
superficie de la fractura que consta de líneas de propagación de grietas que se originan en los puntos de
contacto con el resorte y una superficie quebradiza de la fractura final. La hipótesis causal-explicativa
puede confirmarse con un nivel de confianza determinado mediante un experimento: colocando una
serie de piezas de plástico con y sin el nuevo tratamiento. Si se observa que las piezas de plástico con el
nuevo tratamiento fallan predominantemente, se puede concluir que la hipótesis causal se confirma con
el grado de confianza apropiado utilizando métodos estándar de inferencia estadística.

D.2.3 Ejemplo 2

Se observan varios fallos de soldadura en el campo. Las semanas de fabricación de los productos fallidos
se trazan en tiempo de calendario. Se observa que las fechas de fabricación de los productos con fallas
de soldadura se agrupan en determinadas semanas. Se puede formular una hipótesis causal sobre la
base de la observación inicial, que luego se confirma con un cierto grado de confianza utilizando
inferencia estadística estándar sobre los datos de control del proceso de fabricación, lo que indica que el
proceso de soldadura en estas semanas probablemente no se realizó bajo el control adecuado. La
conclusión es, con un alto nivel de confianza, que una causa raíz de las fallas de soldadura es un control
insuficiente del proceso de soldadura.

D.2.4 Ejemplo 3

Un componente se prueba en una placa de prueba torciendo la placa. El número de giros hasta la falla
se representa en un diagrama de Weibull (ver IEC 61649 [22]). El análisis identifica una población "débil"
y una "fuerte" (ver IEC 61163-1 [23]). Se analiza un componente de la población débil y un componente
de la población fuerte mediante la sección transversal de las bolas de soldadura de matriz de rejilla de
microesferas (BGA). Se observa que el componente de la población débil tiene un gran número de
huecos grandes en las bolas de soldadura, mientras que las bolas de soldadura de la población fuerte no
tienen o tienen pocos huecos pequeños. Se concluye que se formula una hipótesis causal raíz, que los
vacíos en las bolas de soldadura del micro BGA son una causa raíz de los eventos incidentes. La hipótesis
de causa raíz se confirma mediante la recopilación de datos sobre el uso operativo y la observación a
través del análisis de los datos de que la reducción de los vacíos se correlaciona con el uso exitoso del
componente.
 Anexo E
(informativo)

Análisis del desempeño humano

E.1 Generalidades
Las personas de cualquier nivel en una organización toman decisiones o realizan u omiten acciones que
pueden desempeñar un papel en los eventos que conducen a un evento de enfoque. El desempeño
humano puede estar por encima o por debajo de las expectativas y el impacto puede ser positivo o
negativo. Las decisiones pueden ser correctas en las circunstancias en las que se tomaron, pero resultan
tener resultados no deseados.

Las personas pueden cometer errores, estar equivocadas o mal informadas, estar motivadas de manera
inapropiada, pueden estar tratando de desempeñarse correctamente o pueden violar las reglas a
sabiendas. El análisis de los aspectos humanos de la causalidad es complejo y generalmente requiere
experiencia especializada si se requiere ir más allá de identificar qué ocurrió para buscar por qué y, por
lo tanto, hacer recomendaciones.

E.2 Análisis del fracaso humano

El análisis de las fallas humanas comienza con la identificación del modo de error. Esta es la
manifestación externa del error, es decir, lo que se observa que se hizo (o no se hizo). Ejemplos de
modos de error son los siguientes:

 omitido;
 demasiado temprano;
 demasiado tarde;
 demasiado;
 demasiado poco;
 dirección incorrecta;
 objeto incorrecto;
 acción incorrecta;
 secuencia incorrecta.

Luego, hay una serie de taxonomías diferentes para categorizar y analizar las causas de estos errores.
Difieren en el número y tipos de clasificaciones que consideran y en los modelos de comportamiento
humano en los que se basan las taxonomías y en los que se pone más énfasis. Generalmente se
consideran los siguientes:

a) El modo de error interno y el mecanismo de error. Esta es la razón detrás del error en términos
psicológicos significativos, p. para un modo de error de "tomó un giro equivocado en el automóvil",
el modo de error interno y el mecanismo pueden ser una decisión incorrecta debido a la intrusión
del hábito.
b) Problemas inherentes a la tarea, p. objetivos en conflicto, problemas de planificación, limitaciones,
demandas cognitivas, etc.
c) Factores de configuración del rendimiento (PSF). Estas son las condiciones del entorno técnico u
organizacional o interno de una persona que afectan qué tan bien se realizará una tarea (ver IEC
62508 [24]).
Algunos modelos también incluyen un análisis del flujo de información y retroalimentación sin el cual es
poco probable que se hagan juicios correctos. La importancia de estos métodos es que primero
identifican el mecanismo del error psicológico antes de identificar por qué se cometió el error. Por
ejemplo, si el mecanismo de error no se debe a la falta de conocimientos o habilidades, es poco
probable que la capacitación adicional sea útil. Si se toma la decisión de violar un procedimiento,
entonces se deben investigar las razones por las que esto ocurrió en lugar de suponer que una mayor
supervisión es la solución.

Dos ejemplos de métodos que se pueden utilizar para analizar las causas del fracaso humano que
ilustran estos principios son:

 Técnica de análisis retrospectivo y predictivo de errores cognitivos (TRACEr);

 Esquema de clasificación y análisis de factores humanos (HFACS).

E.3 Técnica de análisis retrospectivo y predictivo de errores

cognitivos (TRACEr)

E.3.1 Resumen
TRACEr [25] fue desarrollado para su uso en el control del tráfico aéreo. TRACEr, tiene ocho módulos
como se muestra en la Figura E.1, que se pueden dividir en las siguientes tres categorías:

 el contexto en el que ocurrió el error, es decir, la naturaleza de la tarea, el entorno y las PSF;
 la producción del error, es decir, los modos de error externo (EEM), los modos de error interno
(IEM), los mecanismos de error psicológico (PEM) y la información en la que los individuos basan sus
acciones;
 la detección y corrección del error.

Los módulos de producción de errores se basan en los procesos cognitivos involucrados cuando una
persona percibe que algo debe hacerse y toma medidas, p. percepción, memoria, toma de decisiones y
acción (ver Figura E.2).
 ¿Qué tarea falló? P.ej. Error de monitoreo del radar

Error de tarea

¿Cómo se recuperó el error?P.ej.

Modificación de planos

Corrección

EEM

¿Qué sucedió?P.ej. ¿Cómo se detectó el error?P.ej.

Acción omitida Retroalimentación de resultados

Información Detección PSF

¿Qué detectó tarde el controlador? P.ej. Nivel de vuelo ¿Qué otros

factores
contribuyeron a
IEM los errores o la
recuperación?
¿Qué función perceptiva falló y de qué manera falló? P.ej. Complejidad
P.ej. Detección visual tardía. del tráfico

PEM

¿Cómo ocurrió el error?P.ej. tunelización perceptiva

Dominios cognitivos

Figura E.1 – Ejemplo de un modelo TRACEr [25]

Relevant
Cognitive domain Cognitive function keywords Example IEM

Detection None, late, Late detection

Vision incorrect
Perception Identification None, late, Misidentification
incorrect
Hearing Recognition/comparison None, late, Hearback error
incorrect

Recall perceptual information None, incorrect Forget temporary

information
Previous action None, incorrect Forget previous
Memory actions
Immediate/current action None, incorrect Forget to perform
action
Prospective memory None, incorrect Prospective
memory failure
Stored information (procedural and None, incorrect Mis-recall stored
declarative knowledge) information
Judgement, Judgement Incorrect Misprojection
planning and
decision-making None, too little,
Planning Underplan
incorrect
None, late, incorrect
Decision making Incorrect decision

Early, late, long, short

Timing Action too early
 Relevant
Cognitive domain Cognitive function keywords Example IEM

Action Too much, too

Positioning error,
Execution Positioning little, incorrect,
overshoot
wrong direction
Selection Incorrect Typing error
None, unclear, Unclear information
Communication incorrect transmitted

Figura E.2 – Generación de modos de error interno

E.3.2 Proceso

Un modelo TRACEr se crea siguiendo los siguientes pasos:

a) Analizar la tarea que se está realizando e identificar cualquier factor ambiental o situacional que
pueda afectar el desempeño humano (PSF), que incluye la complejidad de la tarea, el conocimiento
y la experiencia de la persona, el medio ambiente, etc.
b) Identificar los EEM, que se clasifican en términos de selección y calidad, tiempo y secuencia, y
comunicación (ver Tabla E.1).
c) Identificar los IEM, que describen qué función cognitiva falló y de qué manera, cuya taxonomía se
muestra en la Figura E.2.
d) Identificar los problemas de información asociados con el IEM, es decir, qué información se percibió
mal, se olvidó, se juzgó mal o se comunicó mal.
e) Identifique los PEM, que son los sesgos cognitivos que se sabe que afectan el desempeño dentro de
cada dominio cognitivo (consulte la Tabla E.2).
f) Revisar el proceso de detección de errores, que es cómo la persona se dio cuenta del error, qué
medio le informó del error y qué factores externos mejoraron o degradaron la detección.
g) Considere la corrección, es decir, qué se hizo para corregir el error, si otros factores internos o
externos mejoraron o degradaron la corrección del error.

Tabla E.1 – Modos de error externo

Selection and quality Timing and sequence Communication

Omission Action too long Unclear information transmitted
Action too little Action too short Unclear information received
Action too much Action too early Information not sought/obtained
Action in wrong direction Action too late Information not transmitted
Right action on wrong object Action repeated Information not recorded
Wrong action on right object Mis-ordering Incomplete information transmitted
Wrong action on wrong object Incomplete information received
Extraneous act Incomplete information recorded
Incorrect information recorded

Tabla E.2 – Mecanismos de error psicológico

Perception Memory Decision making Action

Expectation bias Similarity interference Incorrect knowledge Manual variability
 Perception Memory
Spatial confusion Memory capacity
overload
Perceptual confusion
Negative transfer
Perceptual discrimination failure
Mis-learning
Perceptual tunnelling Insufficient learning
Stimulus overload Infrequency bias (memory
failure due to knowledge not
Vigilance failure being used
Distraction sufficiently frequently)
Memory block
Distraction/
preoccupation
Decision making Action
Lack of knowledge Spatial confusion
Failure to consider side effects Habit intrusion
Integration failure Perceptual confusion
Mis-articulation
Misunderstanding
Environmental intrusion
Cognitive fixation
Other slip
False assumption
Distraction preoccupation
Prioritization failure
Risk negation or
tolerance
Risk recognition failure
Decision freeze

E.4 Esquema de clasificación y análisis de factores humanos (HFACS)

E.4.1 Resumen

HFACS [26] fue desarrollado por científicos del comportamiento en la Marina de los Estados Unidos y
analiza las causas del error humano según el modelo de Reason (consulte la Cláusula B.3). Hay cuatro
niveles de consideración basados en el modelo de Reason de rebanadas de queso suizo:

 influencias organizacionales;
 supervisión;
 condiciones previas para actos inseguros;
 actos inseguros.

Algunas aplicaciones agregan un quinto nivel por encima de las influencias organizacionales relacionadas
con la legislación y el gobierno.

E.4.2 Proceso

Cada nivel se subdivide en categorías; se dan ejemplos de posibles factores causales dentro de la
categoría. Diferentes aplicaciones usan las mismas categorías (que se muestran en los recuadros a
continuación) pero puede tener diferentes ejemplos según la industria y puede proporcionar algunos
ejemplos o una lista de verificación más detallada. En las Figuras E.3 a E.6 se muestran ejemplos de los
cuatro niveles.

La consideración de la causa comienza con el Nivel 1 para que los precursores del acto en cuestión
tengan en cuenta el tipo de error involucrado y luego continúa hacia arriba a través de los niveles
buscando las debilidades que contribuyeron al evento de enfoque.
 Actos inseguros

Errores Violaciones

Errores de decisiónAcciones de los Rutina(habitual tolerado por la gerencia)

operadores que proceden según lo previsto
pero resultan inadecuadas para lograr el
resultado requerido, p.ej. - siguió un
procedimiento inapropiado- capacidad ExcepcionalSalida aislada de la autoridad –no
excedida tolerado

Errores basados ​en habilidades, p.ej.-

paso omitido- operación inadvertida de
los controles- no priorizar la atención-
mala técnica

Errores de percepción, p.ej.- decisión tomada con

base en información errónea-
distancia/ángulos/velocidad mal calculados-
desorientación espacial- ilusión visual

Figura E.3 – Nivel 1: Actos inseguros

Condiciones previas

Factores Condiciones de los Factores personales

ambientales operadores

Entorno físico, p.ej.- clima- Estado fisiológico, p.ej.- Preparación del personal
calor- iluminación- ruido enfermedad- fatiga- (actividades fuera de servicio
intoxicación que afectan el desempeño)

Gestión de recursos de
Estado psicológico, p.ej.- personal, p.ej.-
estrés- motivación- prisa- comunicación-
Entorno tecnológico, p.ej.-
atención canalizada- planificación- trabajo en
diseño de equipos- pantallas y
exceso de confianza equipo
controles- interfaz hombre-
computadora- diseño de tareas - pérdida de conciencia
situacional

Limitaciones físicas y mentales, p.ej.-

tiempo de reacción insuficiente-
limitación visual- limitación de la
memoria a corto plazo- más allá del
nivel de habilidad

Figura E.4 – Nivel 2: Condiciones previas

 Supervisión

Operaciones No poder Violación en la

Supervisión corregir el supervisión
inapropiadas
inadecuada problema
planeadas

p.ej. no pudo p.ej.- tiempo insuficiente p.ej. no pudo p.ej.- documentación inadecuada- no hizo
proporcionar- permitido- oportunidades corregir- error en cumplir las reglas y normas- toma de
liderazgo- supervisión- insuficientes para descansar- el documento- riesgos innecesarios autorizados
incentivos- guía- procedimiento inapropiado- violación
capacitación control de riesgo inadecuado

Figura E.5 – Nivel 3: Problemas de Supervisión

Influencias organizacionales

Administración Ambiente Procesos

de recursos organizacional organizacionales

HR. - selección - Políticas Operaciones - incentivos -

niveles de empleo - presiones - procesos de
capacitación evaluación - horarios
Estructura - cadena de
mando - comunicación -
responsabilidad formal

Presupuesto - Procedimientos -
reducción de costo estándares -
Cultura - normas y reglas - documentación -
Equipo - Apta para el valores y creencias instrucciones
propósito

Vigilancia

Figura E.6 – Nivel 4: Problemas organizacionales

 Bibliografía

[1] ISO Guide 73: 2009, Risk management – Vocabulary

[2] IEC 60300-1, Dependability management – Part 1: Guidance for management and application

[3] HADDON, W Jr., Energy Damage and the Ten Counter-Measure Strategies, The Journal of the
Human Factors and Ergonomics Society, 1973

[4] HOLLNAGEL, E., Barriers and Accident Prevention, Ashgate Publishing Limited, 2004

[5] REASON, J., Human Error, Cambridge University Press, 1990

[6] CHECKLAND, P., Systems Thinking, Systems Practice: Includes A 30-Year Retrospective, Wiley
Pages: 416, 1999

[7] LEVESON, N., Engineering a Safer World, MIT Press, 2012

[8] RASMUSSEN, J., Risk Management in a Dynamic Society: A Modelling Problem,

Safety Science Volume 27, Issue 2-3, Pages: 183-213, 1997

[9] Technical Research and Analysis Center: Events and Causal Factors Analysis, SCIE-

DOE-01-TRAC-14-95, 1995

[10] BENNER, L. Jr., Accident Investigations: Multilinear Event Sequencing Methods,

Journal of Safety Research 7, 67-73, 1975

[11] HENDRICK, K. and BENNER, L. Jr., Investigating Accidents with STEP, Marcel Dekker Inc, 1986

[12] MONTEAU, M., Analysis and reporting: accident investigation, Encyclopaedia of

Occupational Health and Safety, 57-22:26, ISBN 1:92-2-1-103290-6, 1982
[13] SANDERS, J., Introduction to Why-Because Analysis, 2012

[14] US Nuclear Regulatory Commission: NUREG 0492, Fault Tree Handbook, January, 1981

[15] IEC 61025, Fault tree analysis (FTA)

[16] ISHIKAWA, K., Guide to Quality Control, Asia Productivity Organization, 1986

[17] FAHLBRUCH, B. and SCHÖBEL, M., SOL – Safety through organizational learning: A method for
event analysis. Safety Science, Volume 49, Pages 27–31, 2011

[18] JOHNSON, W. and DEKKER, M.,:MORT Safety Assurance Systems, 1980

[19] SVEDUNG, J. and RASMUSSEN, J.,:Graphic representation of Accident Scenarios: Mapping

System Structure and the Causation of Accidents, Safety Science, Volume 40, Pages 397-417, 2002

[20] SVEDUNG, J. and RASMUSSEN, J., Risk Management in a Dynamic Society: A Modelling Problem,
Safety Science, Volume 27, Pages 183-213, 1997

[21] Energy Institute, Tripod Beta: Guidance on the use of Tripod Beta in the investigation and
analysis of incidents, accidents and business losses, 2013 http:www.tripodfoundation.com

[22] IEC 61649, Weibull analysis

[23] IEC 61163-1, Reliability stress screening – Part 1: Repairable assemblies manufactured in
lots

[24] IEC 62508:2010, Guidance on human aspects of dependability

[25] SHORROCK, S. and KIRWAN, B., Development and application of a human error identification
tool for air traffic control, Applied Ergonomics, Volume 33, Pages 319– 336, 2002
[26] SHAPPELL, S. and WIEGMANN, D., Applying Reason: The Human Factors Analysis and
Classification System (HFACS), Human Factors and Aerospace Safety, Volume 1,

Pages 59-86 , 2001

[27] ISO/IEC 31010:2009, Risk management – Risk assessment techniques

[28] ISO 31000: 2009, Risk management – Principles and guidelines