Une en 62740 Español

norma UNE-EN 62740
española
Diciembre 2015
TÍTULO Análisis de causa raíz (RCA)
Root cause analysis (RCA).
Analyse de cause initiale (RCA).
CORRESPONDENCIA Esta norma es la versión oficial, en español, de la Norma Europea EN 62740:2015, que
a su vez adopta la Norma Internacional IEC 62740:2015.
OBSERVACIONES
ANTECEDENTES Esta norma ha sido elaborada por el comité técnico AEN/CTN 200 Normas básicas
eléctricas cuya Secretaría desempeña AENOR.
Editada e impresa por AENOR LAS OBSERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A:
Depósito legal: M 40071:2015
74 Páginas
 AENOR 2015 Génova, 6 [email protected] Tel.: 902 102 201

Reproducción prohibida 28004 MADRID-España www.aenor.es Fax: 913 104 032
Este documento ha sido adquirido por INSTITUTO TECNOLOGICO DE COSTA RICA a través de la suscripción a AENORmás.
Para uso en red interna se requiere de autorización previa de AENOR.
NORMA EUROPEA
EUROPEAN STANDARD EN 62740
NORME EUROPÉENNE
EUROPÄISCHE NORM Abril 2015
ICS 03.120.01
Versión en español
Análisis de causa raíz (RCA)

(IEC 62740:2015)
Root cause analysis (RCA). Analyse de cause initiale (RCA). Ursachenanalyse.

(IEC 62740:2015). (IEC 62740:2015). (IEC 62740:2015).
Esta norma europea ha sido aprobada por CENELEC el 2015-03-20. Los miembros de CENELEC están sometidos al
Reglamento Interior de CEN/CENELEC que define las condiciones dentro de las cuales debe adoptarse, sin
modificación, la norma europea como norma nacional.
Las correspondientes listas actualizadas y las referencias bibliográficas relativas a estas normas nacionales, pueden
obtenerse en la Secretaría Central de CENELEC, o a través de sus miembros.
Esta norma europea existe en tres versiones oficiales (alemán, francés e inglés). Una versión en otra lengua realizada
bajo la responsabilidad de un miembro de CENELEC en su idioma nacional, y notificada a la Secretaría Central, tiene
el mismo rango que aquéllas.
Los miembros de CENELEC son los comités electrotécnicos nacionales de normalización de los países siguientes:
Alemania, Antigua República Yugoslava de Macedonia, Austria, Bélgica, Bulgaria, Chipre, Croacia, Dinamarca,
Eslovaquia, Eslovenia, España, Estonia, Finlandia, Francia, Grecia, Hungría, Irlanda, Islandia, Italia, Letonia, Lituania,
Luxemburgo, Malta, Noruega, Países Bajos, Polonia, Portugal, Reino Unido, República Checa, Rumanía, Suecia, Suiza
y Turquía.
CENELEC
COMITÉ EUROPEO DE NORMALIZACIÓN ELECTROTÉCNICA
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
SECRETARÍA CENTRAL: Avenue Marnix, 17-1000 Bruxelles
 2015 CENELEC. Derechos de reproducción reservados a los Miembros de CENELEC.
EN 62740:2015 -4-
Prólogo europeo
El texto del documento 56/1590/FDIS, futura edición 1 de la Norma IEC 62740, preparado por el Comité
Técnico TC 56, Confiabilidad, de IEC, fue sometido a voto paralelo IEC-CENELEC y fue aprobado por
CENELEC como Norma EN 62740:2015.
Se fijaron las siguientes fechas:
 Fecha límite en la que la norma europea debe adoptarse a nivel

nacional por publicación de una norma nacional idéntica o por
ratificación (dop) 2015-12-20
 Fecha límite en la que deben retirarse las normas nacionales

divergentes con esta norma (dow) 2018-03-20
Se llama la atención sobre la posibilidad de que algunos de los elementos de este documento estén sujetos
a derechos de patente. CEN y CENELEC no son responsables de la identificación de dichos derechos de
patente.
Declaración
El texto de la Norma IEC 62740:2015 fue aprobado por CENELEC como norma europea sin ninguna
modificación.
En la versión oficial, para la bibliografía, debe añadirse la siguiente nota para la norma indicada*:
IEC 60300-1 NOTA Armonizada como Norma EN 60300-1.

IEC 61025 NOTA Armonizada como Norma EN 61025.
IEC 61649 NOTA Armonizada como Norma EN 61649.
IEC 61163-1 NOTA Armonizada como Norma EN 61163-1.
IEC 62508:2010 NOTA Armonizada como Norma EN 62508:2010 (sin ninguna modificación).
ISO/IEC 31010:2009 NOTA Armonizada como Norma EN 31010:2010 (sin ninguna modificación).
* Introducida en la norma indicándose con una línea vertical en el margen izquierdo del texto.
-5- EN 62740:2015
Índice
Prólogo...................................................................................................................................................... 8
Introducción ........................................................................................................................................... 10
1 Objeto y campo de aplicación .............................................................................................. 11
2 Normas para consulta .......................................................................................................... 11
3 Términos, definiciones y abreviaturas ................................................................................ 11

3.1 Términos y definiciones ........................................................................................................ 11
3.2 Abreviaturas ......................................................................................................................... 13
4 RCA – Visión general ........................................................................................................... 14
5 El proceso del RCA............................................................................................................... 15

5.1 Visión general........................................................................................................................ 15
5.2 Inicio ...................................................................................................................................... 16
5.3 Establecimiento de los hechos .............................................................................................. 17
5.4 Análisis .................................................................................................................................. 19
5.4.1 Descripción ............................................................................................................................ 19
5.4.2 El equipo de análisis ............................................................................................................. 20
5.5 Validación.............................................................................................................................. 21
5.6 Presentación de los resultados ............................................................................................. 22
6 Selección de las técnicas para el análisis de las causas ...................................................... 22

6.1 Generalidades ....................................................................................................................... 22
6.2 Selección de las técnicas de análisis ..................................................................................... 23
6.3 Herramientas útiles para ayudar a realizar un RCA ........................................................ 24
Anexo A (Informativo) Resumen y criterios de técnicas RCA comúnmente usadas .................. 25

A.1 Generalidades ....................................................................................................................... 25
A.2 Técnicas RCA........................................................................................................................ 25
A.3 Criterios ................................................................................................................................. 26
Anexo B (Informativo) Modelos RCA ............................................................................................ 30

B.1 Generalidades ....................................................................................................................... 30
B.2 Análisis de Barreras ............................................................................................................. 30
B.2.1 Descripción general .............................................................................................................. 30
B.2.2 Fortalezas y limitaciones ...................................................................................................... 31
B.3 Modelo de Reason (modelo de queso suizo) ........................................................................ 31
B.4 Modelos de sistemas.............................................................................................................. 32
B.5 Modelo y procesos de accidente teórico de sistemas (STAMP)......................................... 33
Anexo C (Informativo) Descripción detallada de las técnicas de RCA........................................ 34

C.1 Generalidades ....................................................................................................................... 34
C.2 Gráficos de eventos y factores causales (ECF) ................................................................... 34
C.2.1 Información general ............................................................................................................. 34
C.2.2 Proceso ................................................................................................................................... 35
C.2.3 Fortalezas y limitaciones ...................................................................................................... 35
EN 62740:2015 -6-
C.3 Secuenciación de eventos multilineales (MES) y trazado de eventos sucesivos

(STEP) ................................................................................................................................... 36
C.3.2 Proceso ................................................................................................................................... 37
C.4 El método "por qué" ............................................................................................................ 39
C.4.2 Proceso ................................................................................................................................... 40
C.5 Método del árbol de causas (CTM) ..................................................................................... 40
C.5.2 Proceso ................................................................................................................................... 43
C.6 Análisis Por qué-porque (WBA).......................................................................................... 44
C.6.2 Proceso ................................................................................................................................... 46
C.7 Método de árbol de fallos y de éxito .................................................................................... 47
C.7.2 Proceso ................................................................................................................................... 48
C.8 Diagrama de espina de pescado o Ishikawa ....................................................................... 48
C.8.2 Proceso ................................................................................................................................... 49
C.9 Seguridad a través del aprendizaje organizativo (SOL) ................................................... 50
C.9.2 Proceso ................................................................................................................................... 50
C.10 Árbol de supervisión de la gestión y de los riesgos (MORT) ............................................ 52
C.10.2 Proceso ................................................................................................................................... 52
C.11 AcciMaps ............................................................................................................................... 53
C.11.2 Proceso ................................................................................................................................... 53
C.12 Tripod Beta ........................................................................................................................... 55
C.12.2 Proceso ................................................................................................................................... 56
C.13 Análisis causal utilizando STAMP (CAST) ........................................................................ 57
C.13.2 Proceso ................................................................................................................................... 61
Anexo D (Informativo) Herramientas útiles para facilitar un análisis de causa raíz (RCA) ..... 62
D.1 Generalidades ....................................................................................................................... 62
D.2 Técnicas de minería de datos y de análisis tipológico ........................................................ 62
D.2.1 Información general ............................................................................................................. 62
D.2.2 Ejemplo 1 ............................................................................................................................... 62
D.2.3 Ejemplo 2 ............................................................................................................................... 63
D.2.4 Ejemplo 3 ............................................................................................................................... 63
Anexo E (Informativo) Análisis de rendimiento humano ............................................................. 64

E.1 Generalidades ....................................................................................................................... 64
E.2 Análisis del fallo humano ..................................................................................................... 64
-7- EN 62740:2015
E.3 Técnica para el análisis retrospectivo y predictivo de errores cognitivos

(TRACEr) .............................................................................................................................. 65
E.3.1 Visión general........................................................................................................................ 65
E.3.2 Proceso ................................................................................................................................... 67
E.4 Análisis del factor humano y esquema de clasificación (HFACS) .................................... 68
E.4.1 Visión general........................................................................................................................ 68
E.4.2 Proceso ................................................................................................................................... 69
Bibliografía............................................................................................................................................. 72
Figura 1 – Proceso del RCA.................................................................................................................. 16

Figura B.1 – Barreras rotas, ineficaces o desaparecidas que causan el evento foco ........................ 30
Figura C.1 – Ejemplo de un diagrama de ECF ................................................................................... 35
Figura C.2 – Datos de un bloque de construcción de eventos ............................................................ 36
Figura C.3 – Ejemplo de matriz tiempo-actor .................................................................................... 38
Figura C.4 – Ejemplo de árbol de porqués .......................................................................................... 39
Figura C.5 – Símbolos y enlaces usados en CTM ............................................................................... 41
Figura C.6 – Ejemplo de árbol causal .................................................................................................. 42
Figura C.7 – Ejemplo de WBG............................................................................................................. 45
Figura C.8 – Ejemplo de árbol de fallos durante el análisis .............................................................. 47
Figura C.9 – Ejemplo de diagrama de espina de pescado .................................................................. 49
Figura C.10 – Ejemplo de diagrama MORT ....................................................................................... 52
Figura C.11 – Ejemplo de un AcciMap ............................................................................................... 54
Figura C.12 – Ejemplo de diagrama árbol Tripod Beta .................................................................... 56
Figura C.13 – Estructura de control para el suministro de agua en una pequeña ciudad de
Canadá.................................................................................................................................................... 59
Figura C.14 – Ejemplo de análisis causal CAST para el departamento local de salud ................... 60
Figura C.15 – Ejemplo de análisis causal CAST para la gestión de operaciones del servicio
público local ........................................................................................................................................... 60
Figura E.1 – Ejemplo de modelo TRACEr [25] .................................................................................. 66
Figura E.2 – Generación de modos de error internos ........................................................................ 67
Figura E.3 – Nivel 1: actos no seguros ................................................................................................. 69
Figura E.4 – Nivel 2: Condiciones previas ........................................................................................... 70
Figura E.5 – Nivel 3: Cuestiones de supervisión ................................................................................. 70
Figura E.6 – Nivel 4: Cuestiones organizativas ................................................................................... 71
Tabla 1 – Pasos del RCA ....................................................................................................................... 15

Tabla A.1 – Breve descripción de técnicas RCA ................................................................................. 25
Tabla A.2 – Resumen de los criterios de las técnicas RCA ................................................................ 26
Tabla A.3 – Atributos de las técnicas RCA genéricas ........................................................................ 29
Tabla B.1 – Ejemplos de barreras ........................................................................................................ 31
Tabla B.2 – Ejemplo de hoja de trabajo de análisis de barreras ....................................................... 31
Tabla C.1 – Factores causales directos e indirectos ............................................................................ 51
Tabla E.1 – Modos de error externos................................................................................................... 68
Tabla E.2 – Mecanismos psicológicos de error ................................................................................... 68
EN 62740:2015 -8-
COMISIÓN ELECTROTÉCNICA INTERNACIONAL
______________

______________
Prólogo
1) IEC (Comisión Electrotécnica Internacional) es una organización mundial para la normalización, que comprende todos los
comités electrotécnicos nacionales (Comités Nacionales de IEC). El objetivo de IEC es promover la cooperación internacional
sobre todas las cuestiones relativas a la normalización en los campos eléctrico y electrónico. Para este fin y también para otras
actividades, IEC publica Normas Internacionales, Especificaciones Técnicas, Informes Técnicos, Especificaciones Disponibles
al Público (PAS) y Guías (de aquí en adelante "Publicaciones IEC"). Su elaboración se confía a los comités técnicos; cualquier
Comité Nacional de IEC que esté interesado en el tema objeto de la norma puede participar en su elaboración. Organizaciones
internacionales gubernamentales y no gubernamentales relacionadas con IEC también participan en la elaboración. IEC
colabora estrechamente con la Organización Internacional de Normalización (ISO), de acuerdo con las condiciones
determinadas por acuerdo entre ambas.
2) Las decisiones formales o acuerdos de IEC sobre materias técnicas, expresan en la medida de lo posible, un consenso
internacional de opinión sobre los temas relativos a cada comité técnico en los que existe representación de todos los Comités
Nacionales interesados.
3) Los documentos producidos tienen la forma de recomendaciones para uso internacional y se aceptan en este sentido por los
Comités Nacionales mientras se hacen todos los esfuerzos razonables para asegurar que el contenido técnico de las
publicaciones IEC es preciso, IEC no puede ser responsable de la manera en que se usan o de cualquier mal interpretación por
parte del usuario.
4) Con el fin de promover la unificación internacional, los Comités Nacionales de IEC se comprometen a aplicar de forma
transparente las Publicaciones IEC, en la medida de lo posible en sus publicaciones nacionales y regionales. Cualquier
divergencia entre la Publicación IEC y la correspondiente publicación nacional o regional debe indicarse de forma clara en esta
última.
5) IEC no establece ningún procedimiento de marcado para indicar su aprobación y no se le puede hacer responsable de cualquier
equipo declarado conforme con una de sus publicaciones.
6) Todos los usuarios deberían asegurarse de que tienen la última edición de esta publicación.
7) No se debe adjudicar responsabilidad a IEC o sus directores, empleados, auxiliares o agentes, incluyendo expertos individuales
y miembros de sus comités técnicos y comités nacionales de IEC por cualquier daño personal, daño a la propiedad u otro daño
de cualquier naturaleza, directo o indirecto, o por costes (incluyendo costes legales) y gastos derivados de la publicación, uso o
confianza de esta publicación IEC o cualquier otra publicación IEC.
8) Se debe prestar atención a las normas para consulta citadas en esta publicación. La utilización de las publicaciones referenciadas es
indispensable para la correcta aplicación de esta publicación.
9) Se debe prestar atención a la posibilidad de que algunos de los elementos de esta Publicación IEC puedan ser objeto de
derechos de patente. No se podrá hacer responsable a IEC de identificar alguno o todos esos derechos de patente.
La Norma IEC 62740 ha sido elaborada por el comité técnico 56 de IEC: Confiabilidad.
El texto de esta norma se basa en los documentos siguientes:
FDIS Informe de voto

56/1590/FDIS 56/1608/RVD
El informe de voto indicado en la tabla anterior ofrece toda la información sobre la votación para la
aprobación de esta norma.
-9- EN 62740:2015
Esta norma ha sido elaborada de acuerdo con las Directivas ISO/IEC, Parte 2.
El comité ha decidido que el contenido de esta norma (la norma base y sus modificaciones) permanezca
vigente hasta la fecha de mantenimiento indicada en la página web de IEC "http://webstore.iec.ch" en los
datos relativos a la norma específica. En esa fecha, la norma será
– confirmada;
– anulada;
– reemplazada por una edición revisada; o
– modificada.
EN 62740:2015 - 10 -
Introducción
El análisis de causa raíz (RCA, Root cause analysis) se refiere a cualquier proceso sistemático que identifique factores
que contribuyen a un evento de interés particular (evento foco). El RCA se realiza entendiendo que los eventos se tratan
entendiendo las causa raíz, más que mediante los síntomas obvios inmediatos. El RCA tiene por objetivo revelar las
causas raíz para poder cambiar la probabilidad de ocurrencia o el impacto si ello ocurre.
Una importante distinción a realizar es que el RCA se utiliza para analizar un evento foco que ha ocurrido y por tanto
analiza el pasado (a posteriori). No obstante, el conocimiento de la causa raíz de eventos pasados puede conducir a
acciones que generen mejoras en el futuro.
Esta norma internacional pretende reflejar las buenas prácticas actuales al realizar un RCA. Esta norma es de naturaleza
general, y puede proporcionar una guía para muchas industrias y situaciones. Pueden existir normas específicas
industriales que establezcan metodologías preferibles para aplicaciones concretas. Si estas normas están en armonía con
esta publicación, las normas industriales serán, por lo general, suficientes.
Esta norma es general y no está orientada a la seguridad o a la investigación de accidentes, aunque los métodos aquí
descritos podrían usarse para este propósito.
- 11 - EN 62740:2015
1 Objeto y campo de aplicación

Esta norma internacional describe los principios básicos del análisis de causa raíz (RCA) y especifica los pasos que
debería incluir un proceso para un RCA.
Esta norma identifica un número de atributos para técnicas RCA que ayudan a seleccionar una técnica apropiada. Se
describe cada técnica RCA con sus debilidades y fortalezas relativas.
El RCA se utiliza para analizar las causas raíz de eventos foco con salidas tanto positivas como negativas, pero se
utiliza más habitualmente para el análisis de fallos e incidentes. Las causas de estos eventos pueden tener distinta
naturaleza, incluido procesos de diseño y técnicas, características organizativas, aspectos humanos y eventos externos.
El RCA se puede usar para investigar las causas de no conformidades en sistemas de gestión de calidad (y otros) así
como para el análisis de fallos, por ejemplo en mantenimiento o ensayos de equipos.
El RCA se usa para analizar los eventos foco que han ocurrido, por tanto, esta norma sólo cubre análisis a posteriori. Se
reconoce que alguna de las técnicas de RCA se puede usar proactivamente en el diseño y desarrollo de elementos y en
el análisis de las causas durante la evaluación de riesgos; no obstante, esta norma se centra en el análisis de eventos que
han ocurrido.
La intención de esta norma es describir un proceso para realizar un RCA y explicar las técnicas para identificar las
causas raíz. Estas técnicas no se han diseñado para asignar responsabilidades u obligaciones, lo cual está fuera del
alcance de esta norma.
2 Normas para consulta

Los documentos indicados a continuación, en su totalidad o en parte, son normas para consulta indispensables para la
aplicación de este documento. Para las referencias con fecha, solo se aplica la edición citada. Para las referencias sin
fecha se aplica la última edición (incluyendo cualquier modificación de ésta).
IEC 60050 (todas las partes), Vocabulario Electrotécnico Internacional.
3 Términos, definiciones y abreviaturas

Para los fines de este documento, se aplican los términos y definiciones incluidos en la Norma IEC 60050-192 además
de los siguientes:
3.1 Términos y definiciones

3.1.1 causa:
Circunstancia o conjunto de circunstancias que conducen a un fallo o a un suceso.
NOTA 1 Una causa se puede originar durante la especificación, diseño, producció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 suceso" en el
término]
3.1.2 factor causal:

Condición, acción, evento o estado que fue necesario o contribuyó a la ocurrencia del evento foco.
EN 62740:2015 - 12 -
3.1.3 factor contributivo:

Condición, acción, evento o estado considerado como secundario, de acuerdo a la ocurrencia del evento foco.
3.1.4 evento:
Ocurrencia o cambio de un conjunto de circunstancias particular.
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 ha ocurrido.
NOTA 3 Un evento se puede referir a veces como un "incidente" o "accidente".
[FUENTE: Guía ISO 73:2009, 3.5.1.3, modificado – supresión de la nota 4[1]1)]
3.1.5 fallo <de un elemento>:

Pérdida de capacidad para funcionar de la forma requerida.
NOTA 1 Un fallo de un elemento es un evento que produce una avería de ese elemento.
NOTA 2 Se pueden usar calificadores, como catastrófico, crítico, principal, menor, marginal o insignificante, para categorizar fallos de acuerdo con
la severidad de las consecuencias, la elección y definición de los criterios de severidad dependerán del campo de aplicación.
NOTA 3 Se pueden usar calificadores, como mal uso, mala manipulación y debilidad, para categorizar fallos de acuerdo a la causa de fallo.
NOTA 4 Esto es un fallo de un elemento y no de su comportamiento que sería más general.
[FUENTE: IEC 60050-192:2014, 192-03-01 modificado – introducción de la nueva nota 4]
3.1.6 mecanismo del fallo:

Proceso que conduce a un fallo.
NOTA 1 El proceso puede ser físico, químico, lógico, psicológico o una combinación de ellos.
[FUENTE: IEC 60050-192:2014, 192-03-12 modificado – se ha añadido la palabra "psicológico"]
3.1.7 evento foco:

Evento que se plantea para explicarse desde un punto de vista causal.
3.1.8 factor causal inmediato:

Condición, acción, evento o estado donde no hay otro factor causal entre éste y el evento foco.
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 resulta en el estado o evento dado, sin el cual el evento o estado no podría
haber ocurrido.
3.1.10 factor humano:

Discrepancia entre la acción humana hecha u omitida y la pretendida o requerida.
NOTA 1 la primera edición de la IEC 60050-191:1990 identifica "equivocación" como sinónimo de "error humano", pero un "error" es un tipo de
error humano.
NOTA 2 El término error humano aplica a cualquier situación donde la salida no es la prevista tanto si la intención de la persona fue correcta o no.
[FUENTE: IEC 60050-192:2014, 192-03-14 modificado – omisión del ejemplo y adición de las notas 1 y 2]
1) Las cifras entre corchetes se refieren a la Bibliografía.
- 13 - EN 62740:2015
3.1.11 elemento:
Sujeto considerado.
NOTA 1 El elemento puede ser una parte individual, componente, dispositivo, unidad funcional, equipo, subsistema o sistema.
NOTA 2 El artículo puede ser hardware, software, personal o una combinación de los anteriores.
NOTA 3 El elemento se compone a menudo de elementos que se pueden considerar individualmente.
[FUENTE: IEC 60050-192:2014, 192-01-01 modificado – omisión de referencias internas y de las notas 4 y 5]
3.1.12 causa raíz:

Factor causal sin predecesor que es relevante para el propósito del análisis.
NOTA 1 Un evento foco 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 una causa predecesora (un
conjunto acotado de factores causales).
3.1.13 análisis de causa raíz, RCA:

Proceso sistemático para identificar las causas de un evento foco.
NOTA 1 IEC 600050-192:2014, definición 192-12-05 proporciona las siguientes definiciones más restrictivas "proceso sistemático para identificar
la causa de una avería, fallo o evento no deseado que se puede eliminar mediante cambios en el diseño, proceso o procedimiento". Esta
norma usa una definición extendida para permitir una aplicabilidad más amplia del proceso.
NOTA 2 La abreviatura RCA es la traducción del inglés "root cause analysis".
3.1.14 parte interesada:

Persona u organización que puede afectar, ser afectado por, o percibir que son afectados por una decisión o actividad.
[FUENTE: IEC 61300-1:2014, 3.1.15] [2]
3.1.15 regla de parada:

Medio razonado o explícito de determinar cuándo un factor causal se define como una causa raíz.
3.2 Abreviaturas
BGA Encapsulado con terminales en matriz de puntos de soldadura (Ball grid array)
CAST Análisis causal usando STAMP (Causal analysis using STAMP)
CCT Ensayo de integridad causal (Causal completeness test)
CT Contraste de hipótesis (Counterfactual test)
CTM Método del árbol de causas (Causes tree method)
ECF Eventos y factores causales (Events and causal factors)
MEE Modo de error externo
AAF Análisis por árbol de fallos
GEMS Sistema de modelado de error genérico (Generic error modelling system)
HFACS Análisis de factor humano y esquema de clasificación (Human factor analysis and classification scheme)
MEI Modo de error interno
MES Secuenciación de eventos multilineales (Multilinear events sequencing)
MORT Supervisión de la gestión y árbol de riesgos (Management oversight and risk tree)
EN 62740:2015 - 14 -
MEP Mecanismo de error psicológico

FMR Factores de modelización del rendimiento
RCA Análisis de causa raíz (Root cause analysis)
SOL Seguridad a través del aprendizaje organizacional (Safety through organizational learning)
STAMP Modelo y procesos de accidente teórico de sistemas (Systems theoretic accident model and processes)
STEP Trazado de eventos secuenciales (Sequentially timed events plotting)
Técnica para el análisis retrospectivo y predictivo de errores cognitivos (Technique for retrospective and
TRACEr
predictive analysis of cognitive errors)
WBA Análisis Por qué-porque (Why-because analysis)
4 RCA – Visión general

El RCA se refiere a cualquier proceso sistemático que identifica la causa o causas que contribuyen a un evento foco. La
causa inmediata u obvia de un evento foco es a menudo un síntoma de causas subyacentes y puede no identificar
realmente la causa o causas raíz que se deberían identificar y tratar. El RCA proporciona un mayor entendimiento
acerca de por qué ha sucedido un evento. El RCA puede identificar lo siguiente:
a) una única causa raíz;
b) múltiples causas raíz en las cuales la eliminación de cualquier causa hará que el evento foco no ocurra;
c) causas raíz que son factores contribuyentes cuya eliminación modificará la probabilidad de ocurrencia del evento
foco pero que no lo previenen directamente;
d) causas raíz de sucesos.
Al considerar la causa o causas raíz, es posible tomar decisiones sobre las acciones que generarán mejores resultados en
el futuro; la implementación de acciones apropiadas basadas en RCA es más eficaz en la prevención de eventos iguales
o similares que sucedan con resultados negativos o en el incremento de la probabilidad de repetir eventos con resultados
positivos, en comparación con sólo abordar los síntomas inmediatamente obvios.
El RCA se puede aplicar a cualquier evento foco ya produzca éxito o fallo, por ejemplo:
1) investigación de eventos tecnológicos, médicos u ocupacionales;
2) análisis de fallos de sistemas tecnológicos, para determinar por qué un sistema no pudo desempeñar su función
cómo y cuándo se requirió;
3) análisis de procesos de control de calidad y de negocio;
4) análisis de salidas exitosas.
El RCA se puede llevar a cabo a varios niveles de descomposición, por ejemplo, desde nivel de sistema a nivel de
componente o seleccionando diferentes eventos o salidas como punto de partida. El nivel apropiado sobre el que llevar a
cabo el análisis dependerá del evento foco.
El RCA se utiliza para analizar eventos foco que ya han ocurrido realmente y por tanto es aplicable durante las fases de
ensayos y operación del ciclo de vida de un proyecto o producto. El RCA puede identificar problemas de proceso,
incluido diseño, control de calidad, gestión de confiabilidad y gestión de proyectos.
- 15 - EN 62740:2015
Los beneficios de llevar a cabo un RCA incluyen:
• obtener una mejor comprensión de lo que ha ocurrido;
• encontrar la fuente de problemas y por tanto las acciones correctoras que pueden evitar futuros eventos;
• identificar las causas de eventos con salidas beneficiosas y así poder repetirlas;
• identificar acciones más efectivas para tratar las causas de los eventos foco;
• conseguir los objetivos de las investigaciones de los eventos foco de manera más efectiva;
• dar soporte a la trazabilidad entre las evidencias de investigación de eventos foco y sus conclusiones;
• aumentar la consistencia entre investigaciones de eventos foco similares;
• aumentar la objetividad de los análisis de eventos foco.
5 El proceso del RCA
5.1 Visión general

Para ser efectivo, el RCA se debe realizar sistemáticamente como una investigación, con causas raíz y conclusiones
respaldadas por evidencias documentales. Para lograr esto, el RCA debería incluir los cinco pasos que se muestran en la
tabla 1 y se ilustran en la figura 1.
Tabla 1 – Pasos del RCA
Paso Concepto y tareas a realizar

Iniciación Basándose en el conocimiento disponible sobre el evento foco, se determina la necesidad
de llevar a cabo un RCA y definir su propósito y alcance
Establecimiento de los Se recopilan datos y establecen los hechos de lo que pasó, dónde, cuándo y por quién
hechos
Análisis Se utilizan herramientas y técnicas del RCA para determinar cómo y por qué se produjo el
evento foco
Validación Se distingue y resuelven las distintas posibilidades en cuanto a cómo y por qué se causó el
evento foco
Presentación de resultados Se presentan los resultados del análisis del evento de foco
El RCA es iterativo por naturaleza, especialmente en la toma y el análisis, de datos, en el sentido de que los datos se
recogen desde el "qué" ha pasado, después se analizan para determinar qué otros datos se necesita tomar. Una vez
recogidos, se continúa con el análisis y se identifican las diferencias para las cuales se toman más datos. Este proceso se
repite hasta que se cumple el objetivo del análisis y de identifican las causas raíz. Las salidas del RCA dependerán de su
propósito y alcance.
EN 62740:2015 - 16 -
Figura 1 – Proceso del RCA
5.2 Inicio
El primer paso inicia el proceso del RCA evaluando la necesidad de llevarlo a cabo. Se define el propósito y alcance del
análisis, en respuesta al evento foco y se establece un equipo y recursos para realizarlo.
Normalmente existen algunos criterios que se utilizan para determinar cuándo se requiere un RCA, que pueden incluir:
• cualquier evento simple con un efecto grande;
• múltiples eventos similares no deseados;
• un parámetro que se sale de un nivel de tolerancia definido;
• fallos o éxitos (cualquiera que sea el nivel del efecto) que implican a elementos críticos de los equipos o de las
actividades.
Cuando se define el tipo de eventos que requieren la realización de un RCA, es importante considerar que un evento con
un efecto grande puede tener causas raíz comunes con eventos con efectos menores. Analizar y tratar causas raíz para
eventos con efectos menores puede evitar que suceda un evento con efecto grande. Ejemplos de eventos que podrían
requerir un RCA incluyen: terminación de un proyecto (éxitos y fracasos), fallos que resulten en costes inaceptables,
lesión o muerte, funcionamientos o retrasos inaceptables, grandes consecuencias contractuales y avería de equipos.
Si se requiere un RCA, se describe el evento (o eventos) foco a analizar y se designa un equipo apropiado para el
análisis. La descripción debería incluir los antecedentes y contexto en el que el evento(s) foco ha ocurrido. Una buena
descripción de un evento foco, es simple y fácil de entender y no debería estar sesgada hacia una solución específica.
Esta descripción se utiliza para identificar los miembros del equipo de análisis apropiados y determinar dónde comenzar
a tomar datos.
El propósito y alcance del RCA se debería determinar teniendo en cuenta el conocimiento del sistema, las funciones,
interfaces, etc. En algunos casos, el propósito del análisis es identificar las causas del evento foco. En otros, el propósito
podría ser más amplio, por ejemplo, identificar también aspectos de interés fuera de aquellos que llevaron al evento
foco.
En general existen dos tipos de RCA con distintos objetivos y no se deberían mezclar. Estos dos tipos se pueden
describir como sigue:
1) análisis de un evento foco usando únicamente información verificable basada en hechos;
2) análisis de un evento foco para obtener hipótesis de secuencias de eventos y causas.
- 17 - EN 62740:2015
La primera versión se centra únicamente en hechos observados. Podría ser un análisis "per se" de acuerdo con el
propósito del estudio y no se aceptan hipótesis sobre la ocurrencia del evento. La segunda se puede implementar cuando
no se disponga de suficiente información basada en hechos y se aceptan hipótesis de causas potenciales.
Se deben también identificar las salidas requeridas del RCA. Algunos ejemplos son los siguientes:
• proporcionar una descripción de cada causa raíz junto con suficiente información de base para permitir la
identificación de acciones adecuadas;
• recomendar acciones que, en conjunto, eviten la ocurrencia de nuevos eventos similares con consecuencias adversas
y mejoren la probabilidad de éxito;
• identificar, implementar y revisar acciones para tratar las causas raíz.
El 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 la información, energía, o transferencia de material. Por lo tanto, el
ámbito de aplicación debería especificar el límite del análisis (lo que se incluye y lo que se excluye).
El alcance del análisis debería, cuando sea posible, incluir una definición de la "regla de parada", que es el punto en el
que, para el propósito del análisis, se puede definir una acción o ya no son necesarias pruebas adicionales de la causa.
Por ejemplo, el último punto en el que la acción correctora se puede identificar, antes de factores que no se pueden
influenciar, por ejemplo, el clima. Sin embargo, puede ser más apropiado determinar la regla de parada en los puntos de
revisión que determinarán si se requiere un mayor análisis.
El RCA puede llevarse a cabo eficazmente por una sola persona, siempre que tenga experiencia con la técnica de
análisis causal, sea un experto en ese campo (o tenga acceso inmediato a expertos en el campo) y tenga acceso a todos
los datos requeridos. Sin embargo, es más común llevar a cabo el RCA como un equipo. Los miembros del equipo de
análisis se deberían seleccionar en base a la experiencia específica necesaria para analizar el evento foco. El equipo
debería incluir:
• una persona o personas que entre ellos puedan proporcionar una visión completa del sistema y un conocimiento del
programa o proyecto y del evento foco;
• un facilitador experto en la técnica de análisis causal, preferentemente formado o con experiencia en la facilitación
de la técnica de análisis causal.
Los miembros del equipo pueden cambiar dependiendo de la actividad que se lleve a cabo, por ejemplo, los miembros
del equipo responsable de la recolección de datos no serán necesariamente los mismos que realizan el análisis. Los
miembros del equipo pueden incluir ingenieros, técnicos, operadores, representantes de ventas y gerentes. Debería
considerarse la participación de partes externas para proporcionar una perspectiva independiente y evitar los puntos
ciegos que pudieran existir en la organización. Se deberían incluir otros miembros del equipo para actividades
específicas durante la investigación ya sea para aportar su experiencia o para aumentar la influencia del equipo. El papel
de estos miembros adicionales es apoyar la investigación de modo que no se detenga por razones técnicas o de límites
organizativos. No es apropiado que sean parte del equipo las personas que puedan haber tenido un papel en la causa del
evento foco. Sus observaciones deberían recogerse durante los dos primeros pasos.
5.3 Establecimiento de los hechos

Este paso incluye todas las actividades necesarias para preparar el análisis. El establecimiento de los hechos es
generalmente la parte mayor del RCA. Los hechos deberían determinarse sobre "qué" sucedió, "dónde", "cuándo" y
"por quién".
Los datos se deberían recoger antes de que se pierdan (por ejemplo, antes de que las evidencias se alteren o se eliminen,
o los recuerdos se desvanezcan). En general, los datos recogidos incluirían:
EN 62740:2015 - 18 -
a) El contexto en que se produjo el evento foco.
b) Las condiciones antes, durante y después del evento foco.
c) El personal involucrado incluidas las acciones adoptadas (o no tomadas) y las decisiones tomadas.
d) Datos de contexto sobre el entorno, incluidos los datos del medio ambiente.
e) Cómo opera la organización incluyendo organigramas, procesos y procedimientos, formación y habilidades.
f) Datos históricos relacionados con eventos similares o precedentes.
g) Las desviaciones respecto a lo esperado.
h) Las interacciones con otros elementos y personal.
i) Equipos involucrados, su estado operativo y el cumplimiento de los requisitos.
A continuación se enumeran ejemplos de datos que pueden ser pertinentes:
1) La inspección de las evidencias físicas, tales como componentes fallados e informes de fallos. Generalmente, la
experiencia determinará qué evidencia física se requiere. En caso de duda, la evidencia debería mantenerse.
También es importante preservar la evidencia.
2) Fotografías y videos tomados por cámaras de vigilancia. Fotografiar el área de la ocurrencia desde varios puntos de
vista también será útil en la fase de análisis.
3) Los datos operativos, registrados por los sistemas de monitorización, sistemas de control, alarmas y registros de
eventos etc. Los registros de los operadores pueden ser fundamentales para la comprensión de las condiciones de
funcionamiento en el momento del fallo y ya que normalmente se fechan (o cronometran), son ideales para la
generación de un cronograma de eventos.
4) Los testimonios personales recogidos por la realización de entrevistas. Las entrevistas deberían concentrarse en la
recopilación de datos, por ejemplo, la construcción de una línea de tiempo coherente etc. Cualquier discusión
prematura de las causas del fallo puede afectar negativamente al proceso de entrevista. Las preguntas deberían estar
preparadas antes de la entrevista para asegurar que se obtiene toda la información necesaria. Las entrevistas deberían
realizarse con las personas que están más familiarizadas con el evento foco, sin embargo, hay que tener en cuenta
entrevistar otro personal, por ejemplo, las personas que hayan realizado el trabajo en el pasado. Todas las entrevistas
deberían documentarse.
5) La evidencia documental de los procedimientos pertinentes, el entorno operativo y entorno regulador.
Este paso puede incluir análisis de fallos que examinen los componentes fallados utilizando una amplia gama de
métodos que incluyen la microscopía, espectroscopia y ensayos no destructivos o modelos sobre el desarrollo de fallos
tales como la modelización de incendios o roturas.
Una vez que todos los datos asociados con el evento foco se han recogido, los datos se deberían revisar en cuanto a
corrección e idoneidad, se deberían obtener los datos que faltan y se debería resolver cualquier inconsistencia para
garantizar que se ha establecido una imagen clara y consistente del evento foco
El resultado de este paso es la información y la comprensión, apoyado por la evidencia física y declaraciones de
testigos, que se refiera a:
• lo que pasó incluyendo las circunstancias que conducen al evento foco;
• la secuencia temporal de los eventos que conducen al evento foco;
- 19 - EN 62740:2015
• la ubicación del evento foco;
• acciones de las personas asociadas con el evento foco;
• cualquier condición necesaria para el evento foco;
• las consecuencias del evento foco.
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é" se
produjo el evento foco. El objetivo de este paso es entender el evento foco y sus causas estructurando los datos que se
han recogido en un formulario que permita deducir sistemáticamente las causas raíz.
El RCA normalmente analiza los hechos para determinar las causas que fueron necesarias para que el evento foco se
produjera, denominados "factores causales necesarios". Sin embargo, en algunos casos, por ejemplo cuando no hay
hechos suficientes disponibles, el análisis podrá proponer una o varias hipótesis para la causa y también puede
identificar los factores contribuyentes y las condiciones predominantes que posiblemente se asocien al evento foco, pero
que no se puede demostrar que sean factores causales necesarios.
El análisis involucra lo siguiente:
• la organización de las evidencias físicas y testimonios en relación con acciones, eventos, condiciones y resultados;
• la búsqueda de cómo y por qué se produjo el evento foco utilizando los datos recogidos para justificar las
conclusiones. Para ayudar en este proceso se pueden utilizar modelos de causalidad, ensayos de laboratorio, listas de
verificación y taxonomías o análisis estadístico de los datos;
• mirar más allá de los factores causales inmediatos para definir por qué se produjeron. El objetivo es buscar todos los
factores causales que contribuyen, no sólo las causas obvias;
• continuar con este proceso hasta que se invoque la regla de parada y se identifiquen las causas raíz. Puede haber
múltiples causas raíz que pueden ser independientes o correlacionados.
En general, los factores causales pueden involucrar cuestiones técnicas, factores humanos y factores relativos al entorno
físico o psicosocial en el que se produjo el evento foco. En la búsqueda de las causas raíz se debería considerar todo lo
anterior. Las personas con experiencia en estas áreas deberían por lo tanto, participar en el análisis.
Los factores causales se deberían describir de forma clara y sin ambigüedades. Cuando se identifica una acción, omisión
o decisión humana como un factor causal, se debería especificar la naturaleza del acto o decisión, por ejemplo, "el
operador apaga el interruptor de alimentación equivocado" y no sólo "error humano".
El análisis de las causas (en función de la finalidad y el alcance del análisis) puede considerar:
• cómo se produjo el evento foco, es decir, el proceso físico, químico, psicológico o lógico implicado;
• eventos precedentes o condiciones que eran necesarias para que el evento foco se produjera;
• relaciones entre los factores causales, incluyendo la forma en que se combinaron para causar el foco evento y cómo
una causa raíz conduce al evento foco;
• influencias organizativas y de gestión y factores humanos que participaron en el evento foco o en los eventos y las
condiciones que condujeron a él;
EN 62740:2015 - 20 -
• condiciones predominantes, que pueden haber contribuido a que el evento ocurriera, pero que no son factores
causales necesarios;
• motivos de preocupación que podrían llevar a otros eventos foco (estos no son estrictamente factores causales, pero
puede ser un resultado del análisis).
Se debería utilizar una técnica de análisis estructurado para realizar el análisis. Existen varias técnicas formales que van
desde aquellas que se basan en una lista de comprobación de las causas a técnicas que guían al analista a través de la
consideración de las causas y presentan los resultados gráficamente. Las técnicas van desde simples a complejas y
requieren profesionales debidamente cualificados o facilitadores para llevar a cabo el análisis. Algunas técnicas se
basan en modelos particulares de cómo se produce un evento foco y por lo tanto dan un énfasis especial a los resultados.
Los diferentes modelos se basan en distintas hipótesis con respecto a la causalidad, por lo tanto, tienden a dirigir al
investigador a identificar diferentes factores contribuyentes.
En algunos casos es apropiado utilizar más de una técnica o tener en cuenta consideraciones de más de un modelo para
identificar todas las causas raíz.
En el anexo B se describen los modelos de causalidad y en el anexo C se describen las técnicas de análisis. La técnica
más adecuada dependerá del evento foco y del propósito y alcance del análisis (véase el capítulo 6).
El análisis puede indicar que se necesitan más datos. Se debería esperar que a lo largo del análisis se produzcan
solicitudes de datos para resolver inconsistencias o completar la falta de datos en el análisis. El análisis debería
continuar hasta que se llame a una "regla de parada".
5.4.2 El equipo de análisis

Se debería designar un líder para la etapa de análisis, que es responsable del siguiente trabajo preparatorio:
a) Obtener copias de los roles y responsabilidades acordadas del equipo, y del propósito y alcance del análisis.
b) Obtener copias de la descripción del evento foco y de los hechos establecidos.
c) Decidir la(s) técnica(s) de análisis que se utilizará(n).
d) Convertir la descripción del evento foco 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) Dar formación al equipo de análisis.
g) Facilitar u organizar la formación de los miembros del equipo en la técnica de análisis seleccionada.
h) Seleccionar las herramientas software u otras plantillas para su uso durante el análisis.
i) Organizar búsquedas de bases de datos, medios, procedimientos legales, etc. para identificar eventos foco de
naturaleza similar, o que pudieron haber ocurrido con la misma tecnología o similar.
El líder debería revisar la información disponible para determinar qué técnica(s) de análisis debería aplicarse y qué
habilidades se requieren. Puede ser necesario obtener asesoramiento de expertos en RCA respecto a la selección de la
técnica de análisis. El líder también puede requerir un facilitador RCA para todo o parte del análisis, dependiendo de la
complejidad del evento foco, de la complejidad o volumen de las evidencias y de los datos o la técnica de análisis
seleccionada.
- 21 - EN 62740:2015
El análisis se lleva a cabo normalmente por un equipo, con cada miembro elegido por su experiencia y habilidades. El
equipo de análisis debe ser tan pequeño como sea posible, coherente con la experiencia y habilidades técnicas y
operativas pertinentes disponibles. Cuando se requieran entradas de varios terceros, partes interesadas o entidades, el
equipo de análisis debería contener representantes de cada una de ellas. Es responsabilidad del líder asegurar que se
informa a las partes interesadas pertinentes, por lo que deben estar disponibles representantes adecuados de los mismos
durante el análisis.
Al comienzo del análisis debería determinarse el papel y las responsabilidades de los miembros del equipo de análisis y
establecerse los hitos. Debería desarrollarse un programa de reuniones que refleje los objetivos e hitos previstos para el
equipo de análisis. Esto, en última instancia, permitirá que las recomendaciones se lleven a cabo en el momento
oportuno.
El líder debería desarrollar un plan de análisis, que debería contener lo siguiente:
1) descripción del evento foco;
2) funciones y responsabilidades acordadas del equipo y el propósito y el alcance del análisis;
3) una lista de los miembros del equipo y las partes 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 que se utilizarán;
7) disposiciones para la formación del equipo de análisis en la técnica de análisis seleccionada (si se requiere);
8) forma de registro del análisis y de sus resultados, incluyendo referencias a cualquier plantilla o herramientas de
software a utilizar.
El líder debería encargarse de que las salas de reunión tengan las instalaciones adecuadas, con equipos audiovisuales y
de grabación para la buena marcha de las reuniones de análisis. Antes de la primera reunión, se debería enviar al equipo
de análisis, un lote de documentos informativos que incluya el plan de análisis y cualquier lectura esencial o referencia
previas a la reunión para que puedan familiarizarse con la información disponible y la técnica de análisis seleccionada.
El líder debería asegurar que se ha establecido un sistema de comunicación adecuado para informar y transmitir los
resultados del análisis a los responsables de la siguiente etapa del proceso RCA (véase 5.5).
5.5 Validación
A lo largo del proceso de RCA se llevan a cabo una serie de actividades de revisión para determinar si los datos
recogidos son pertinentes y el análisis es representativo de los datos recogidos. Este paso comprueba si pueden
confirmarse las causas identificadas en el análisis y si se pueden insertar en el análisis realizado o ser objeto de una
actividad independiente.
Se puede llevar a cabo una revisión independiente para evaluar si el análisis es completo y correcto y para determinar si
el propósito del análisis se ha cumplido. El método de revisión dependerá de la técnica de análisis utilizada y del evento
foco. En algunos casos pueden llevarse a cabo experimentos para repetir la ocurrencia del evento foco. Cuando sea
apropiado, deberían utilizarse métodos estadísticos para evaluar el grado de confirmación de la hipótesis de la causa. Si
las causas se validan mediante simulación, se debería asegurar que la simulación es representativa.
Durante el análisis puede haber varias hipótesis alternativas de cómo podría haber sucedido el evento. Si el objetivo es
conseguir un informe factual de las causas, después de la finalización del análisis, deberían validarse las causas y sólo
debería permanecer una única conclusión.
EN 62740:2015 - 22 -
Este paso puede requerir la recopilación de más datos para buscar evidencia directa que apoye o refute las causas
identificadas. Puede que no se disponga siempre de evidencia para validar plenamente todas las causas potenciales.
5.6 Presentación de los resultados

Los resultados del análisis dependerán de su finalidad. Por ejemplo, si el propósito del análisis es identificar las
acciones que, en su conjunto, impidan más ocurrencias de eventos similares, los resultados del análisis deberían
identificar las acciones correctoras que rompan la red de causas e impidan que el evento foco se vuelva a producir. Si el
propósito del análisis es repetir éxitos, entonces se deberían proponer las acciones que mejoren la probabilidad o las
consecuencias del evento foco. La eficacia de los resultados del análisis depende de su calidad.
Debería desarrollarse un formato acordado para la presentación de los resultados del RCA que resuma el análisis y
capture los resultados requeridos del mismo, por ejemplo, acciones recomendadas. Si el resultado esperado del RCA es
producir acciones recomendadas, el resumen debería incluir, como mínimo, lo siguiente:
a) una descripción general de cada causa que requiera acción junto con información suficiente de contexto y de detalle,
para asegurar que cada causa se entiende y que se pueden identificar las acciones a realizar;
b) un conjunto de opciones para las acciones de tratamiento y, cuando sea posible, y dentro del ámbito de aplicación,
un resumen de los beneficios y coste de cada una;
c) acciones recomendadas para tratar cada una de las causas identificadas.
Se deberían evaluar las acciones correctoras recomendadas desde el punto de vista de su eficacia y realismo. En general,
las acciones correctoras pretenden alcanzar los siguientes objetivos:
• cambiar la probabilidad del evento foco o sus consecuencias (es decir, reducir la probabilidad o la consecuencia de
eventos no deseados o aumentar la probabilidad o consecuencia eventos de éxito);
• no introducir nuevos riesgos inaceptables, por ejemplo, la seguridad de otros sistemas no debe degradarse por la
acción correctora propuesta.
Cuando se identifican acciones, deberían revisarse antes de su aplicación para determinar que no sólo se han tratado las
causas raíz, sino también que no se introducen nuevas consecuencias inesperadas y que, por tanto, funcionarán según lo
previsto. También debería controlarse la reaparición del mismo evento o uno similar con el fin de evaluar la eficacia de
las acciones adoptadas.
6 Selección de las técnicas para el análisis de las causas
6.1 Generalidades
Se han ideado técnicas formales para ayudar a los analistas a identificar los factores causales y, eventualmente, la causa
raíz. Las técnicas de análisis pueden realizar una o más de las siguientes funciones:
• organizar los datos y proporcionar una estructura para el análisis e identificar dónde es necesario más evidencia;
• proporcionar una representación visual de las evidencias relacionadas con el evento foco, por ejemplo la secuencia
temporal de eventos o cadenas causales;
• realizar un análisis estadístico de los datos, sobre todo a partir de múltiples eventos similares, para identificar
factores causales comunes;
• proporcionar orientación para identificar posibles factores causales para posterior investigación y comparación con
los datos (tales métodos incluyen listas de comprobación y métodos basados en modelos de causalidad);
• orientar a los analistas a través de la cadena causal hacia un conjunto de causas raíz.
- 23 - EN 62740:2015
6.2 Selección de las técnicas de análisis

El RCA se lleva a cabo en diversos grados de profundidad y puede utilizar una o varias técnicas de análisis que van
desde simples a complejas. La profundidad del análisis y la(s) técnica(s) utilizada(s) deberían tener las siguientes
características:
• ser justificable y apropiada para el evento foco bajo análisis y el alcance y propósito del análisis;
• proporcionar resultados que mejoren la comprensión de las causas raíz del evento foco;
• poder utilizarse de una manera trazable, repetible y verificable.
Las técnicas de análisis que se utilizarán se seleccionan teniendo en cuenta factores aplicables tales como:
• características de la técnica de análisis;
• características del evento foco, por ejemplo, severidad o severidad potencial o complejidad;
• características de la organización, por ejemplo, técnicas aprobadas en la industria o sector o evaluación de coste-
beneficio;
• propósito del análisis, por ejemplo, salidas requeridas o expectativas de las partes interesadas;
• el modelo o modelos de causalidad más adecuados para los objetivos del análisis.
Los atributos de las técnicas de análisis más utilizados se describen en el anexo A. Los criterios utilizados para
caracterizar las técnicas que se describen en el anexo A, son los siguientes:
• experiencia requerida;
• soporte de herramientas;
• escalabilidad;
• representación gráfica;
• modularidad;
• reproductibilidad;
• controles de verosimilitud;
• rigor intelectual;
• secuencia temporal;
• especificidad.
Las descripciones detalladas de las técnicas de RCA se recogen en el anexo C, que incluye los métodos y
procedimientos utilizados para cada técnica, junto con sus fortalezas y debilidades.
EN 62740:2015 - 24 -
6.3 Herramientas útiles para ayudar a realizar un RCA

Las técnicas modernas de minería de datos permiten una búsqueda de propiedades y condiciones específicas. La
agrupación de análisis selecciona datos que están estrechamente relacionados, y con ello identifica los datos que se
desvían (valores atípicos). El análisis moderno de grupo puede detectar datos que están estrechamente relacionados en
una, dos o más dimensiones y con ello analizar los productos o procesos que están estrechamente relacionados e
identificar datos que se desvían (valores atípicos). En el anexo D se proporciona una visión general de estas técnicas.
Muchos eventos foco y técnicas de análisis implican factores humanos y se han desarrollado varias taxonomías para
ayudar en la búsqueda de las causas raíz en los que interviene el comportamiento humano. En el anexo E se dan dos
ejemplos.
- 25 - EN 62740:2015
Anexo A (Informativo)
Resumen y criterios de técnicas RCA comúnmente usadas
A.1 Generalidades
En el anexo A se enumeran las técnicas RCA más utilizadas, con una breve descripción, y proporciona una lista de
referencia de los criterios que pueden utilizarse para comparar diferentes técnicas de RCA. La lista no es completa 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 RCA más comúnmente utilizadas.
Tabla A.1 – Breve descripción de técnicas RCA
Técnica Descripción
Gráficos de eventos y factores El análisis ECF identifica la secuencia temporal de una serie de tareas o acciones y
causales (ECF) las condiciones del entorno que conducen a un evento de foco. Estos se muestran en
un diagrama de causa-efecto
Secuenciación de eventos MES y STEP son los métodos de recopilación de datos y seguimiento para el análisis
multilineales (MES) y trazado de eventos foco complejos. Los resultados se muestran como una matriz de eventos
de eventos secuenciales (STEP) de actores temporales
El método "por qué" El método "por qué" guía el análisis a través de la cadena causal haciendo la
pregunta por qué un número de veces
Método del árbol de causas El CTM es una técnica sistemática para analizar y representar gráficamente los
(CTM) eventos y condiciones que contribuyeron a un evento de foco. El CTM es similar al
método "por qué" en el concepto, pero construye un árbol más complejo y considera
explícitamente causas técnicas, organizativas, humanas y ambientales
Análisis ¿Por qué?-porque El WBA establece la red de factores causales responsable de un evento principal
(WBA) mediante la comparación de dos factores, las pruebas de contraste de hipótesis. La
red de factores se muestra en un gráfico "¿por qué? - porque"
Método de árbol de fallo y Árbol de fallo o éxito es una representación gráfica de información para ayudar al
árbol éxito usuario a realizar un análisis deductivo que determine caminos críticos de éxito o
fracaso, que se muestran gráficamente en un diagrama lógico en forma de árbol
Diagrama de espina de pescado El diagrama de espina de pescado o Ishikawa es una técnica que ayuda a identificar,
o Ishikawa analizar y presentar las posibles causas de un evento foco. La técnica ilustra la
relación entre el evento foco y todos los factores que pueden influir en él
Seguridad a través del SOL es una herramienta de análisis guiada por listas de verificación, orientada a
aprendizaje organizativo (SOL) eventos foco en centrales nucleares. Los resultados se presentan visualmente
mediante un diagrama tiempo-actor, derivado del método MES/STEP
EN 62740:2015 - 26 -
Técnica Descripción
Árbol de supervisión de la El gráfico MORT es un árbol de fallos pre-poblado con eventos, por lo general
gestión y de riesgos (MORT) averías o descuidos, expresados en términos genéricos. El árbol MORT contiene dos
ramas principales y muchas sub-ramas que proporcionan un alto nivel de detalle.
Una rama principal identifica unos 130 factores específicos de control, mientras que
la otra rama principal identifica más de 100 factores del sistema de gestión. El
gráfico contiene también unos 30 factores del sistema de gestión adicionales
comunes a las dos ramas principales del árbol
AcciMaps AcciMaps es principalmente una técnica para la visualización de los resultados de un
análisis causal. Requiere un modelo organizativo que separe factores en capas y
obtenga factores en las capas; aplica una versión de la prueba de contraste de
hipótesis (véase WBA) para determinar las relaciones causales entre factores
TripodBeta TrípodBeta es una representación en diagrama de árbol de la red causal, centrándose
en factores humanos y en la búsqueda de fallos en la organización que pueden causar
errores humanos
Análisis causal para modelos y CAST es una técnica que examina el proceso socio-técnico completo involucrado en
procesos de accidentes teóricos un evento de foco. CAST documenta el proceso dinámico que lleva al evento foco
de sistemas (STAMP) (CAST) incluyendo la estructura de control técnico-social, 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 RCA incluidas en la
tabla A.1. Cada criterio tiene tres niveles indicados por un (+), (o) o un (–), donde los diferentes niveles indican el
intervalo.
Los atributos para cada técnica RCA utilizando los criterios y tabla A.2 se muestran en tabla A.3.
Tabla A.2 – Resumen de los criterios de las técnicas RCA
Criterio Descripción Niveles

Experiencia ¿Está el método dirigido a los "usuarios • Intuitivo, requiere poca formación (+)
requerida sofisticados " (requiere el uso de técnicas que • Requiere formación limitada, por ejemplo,
requieran una experiencia especial tales como un día (o)
demostración de teoremas)? ¿Es apropiado para • Considerable esfuerzo de formación
el uso únicamente por expertos en el dominio? necesario, por ejemplo una semana (–)
Soporte de ¿Es necesario soporte de herramientas? • Se puede aplicar correctamente sin soporte
herramientas de herramientas (+)
• No se requiere soporte de herramientas
específicas, pero es necesario, en general,
para la aplicación efectiva (o)
• Se necesita soporte de herramientas y solo
puede aplicarse con soporte de herramientas
específicas
- 27 - EN 62740:2015

Escalabilidad ¿El método es escalable? ¿Se puede utilizar el • Escala bien con la complejidad (+)
método de forma económicamente rentable para • Escalabilidad limitada, sobrecarga
eventos foco simples y complejos? ¿Se puede considerable con cada aplicación (o)
aplicar un subconjunto del método a eventos • No es escalable, se tiene que aplicar el
foco pequeños o menos significativos y con toda método completo (–)
su capacidad a los grandes o significativos? La
pregunta de la escalabilidad es si la complejidad
del análisis utilizando el método se escala con la
complejidad del evento foco.
Representación ¿Cuál es la naturaleza del método de • Representación gráfica con semántica
gráfica representación gráfica? claramente definida y cognitivamente fácil
de entender (+)
El principio motivador es que una imagen vale • Representación gráfica, pero sin semántica
más que mil palabras. A menudo es más (o)
comprensible mostrar los resultados de un • No se define ninguna representación gráfica
método de análisis mediante una imagen, un (–)
gráfico, o cualquier otra forma de ilustración,
que simplemente como texto escrito.
Las propiedades deseables de una representación

gráfica son:
• Mostrar claramente la semántica de la
causalidad (incluyendo denotación de
factores causales, y la taxonomía de los
factores).
• Ser cognitivamente (relativamente)
evaluados fácilmente por una sola persona.
• Idealmente, una representación gráfica
también podría mostrar la historia del
análisis.
Reproductibilidad ¿Los resultados del método son reproductibles? • Los resultados se pueden reproducir, sólo se
¿Diferentes analistas obtendrían resultados observan diferencias en la representación de
similares para el mismo evento enfoque? los resultados, redacción etc.(+)
• Una cantidad significativa de los resultados
se puede reproducir, pero se observan
algunas diferencias (o)
• Los resultados dependerán de la experiencia
del analista (–)
Comprobaciones ¿Hay verificaciones de verosimilitud rápidas y • Existen pruebas de verosimilitud para casi
de verosimilitud razonables sobre los resultados obtenidos, que todos los aspectos (+)
son independientes de la herramienta? ¿Qué • Existen comprobaciones de verosimilitud,
formas hay de comprobar la "corrección" de los por ejemplo listas de verificación, pero no
resultados? Un ejemplo serían las listas de cubren necesariamente todos los aspectos (o)
verificación • Existen solamente medios limitados que
apoyan las comprobaciones de verosimilitud
(–)
EN 62740:2015 - 28 -

Rigor intelectual ¿Cómo de riguroso es el método? El rigor tiene • Definido formalmente y puede ser verificado
dos aspectos relevantes: formalmente (+)
• ¿El método tiene un significado riguroso y • Definición semi-formal (o)
semántica formal, para las nociones clave del • Definición informal (–)
factor causal y la causa raíz? ¿Es la
semántica fácil de aplicar?
• ¿Los resultados del método son susceptibles
de verificación formal (matemática)? ¿Hasta
qué punto es manejable una aplicación del
método?
Secuencia ¿El método contiene una representación • Si (+)
temporal de la secuencia temporal de los • Sólo indirectamente (o)
acontecimientos? • No (–)
Especificidad La medida en que el método limita el análisis a • El método sólo analiza los agentes causales
los factores causales necesarios del evento de necesarios del evento foco (+)
foco en lugar de explorar una serie de problemas • El método puede utilizarse para analizar
generales con el sistema que existían en el factores que contribuyen, así como factores
momento del evento foco y que pueden haber causales necesarios del evento foco (o)
contribuido • El método busca problemas en general sean
o no factores causales necesarios del evento
foco (–)
Tabla A.3 – Atributos de las técnicas RCA genéricas
Experiencia Soporte de Representación Comprobación Rigor Secuencia

Escalabilidad Reproductibilidad Especificidad
requerida herramientas gráfica de verosimilitud intelectual temporal
ECF o o o + o o o + +
MES y STEP – o o + + o o + +
Método "por
+ + – o – – – – +
qué"
CTM o o + + o o o – +
WBA o + o + + + + o +
Método de
árbol de fallo y o o o + o o o – o
árbol éxito
Diagrama de
espina de
+ + – o – o – – o
pescado o
- 29 -
Ishikawa
SOL o – + o + + o + o
MORT + – – o + o o – –
AcciMaps o o o + – o – – o
Tripod Beta – + o + o o o o o
CAST + + + o o o o + +
NOTA Los criterios para cada atributo se describen en la tabla A.2.
EN 62740:2015
EN 62740:2015 - 30 -
Anexo B (Informativo)
Modelos RCA
B.1 Generalidades
En este anexo se describen los modelos RCA más utilizados que proporcionan diferentes formas de pensar en eventos
foco. Los diferentes modelos se basan en ciertas hipótesis con respecto al evento foco, por ejemplo, el análisis de
barreras supone que el evento foco se ha producido como resultado de falta, fallo o ineficacia de barreras. Por lo tanto,
los diferentes modelos tienden a dirigir al investigador para identificar diferentes factores causales. Los modelos se
utilizan para pensar en conjunción 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 Descripción general
El análisis de barreras se basa en la hipótesis de que un evento foco se produce como resultado de la interacción de una
fuente de daño sobre un objetivo y que esto se puede evitar mediante el uso de barreras [3]. Un evento no deseado se
produce cuando las barreras han desaparecidos, han fallado o son ineficaces (véase la figura B.1).
Figura B.1 – Barreras rotas, ineficaces o desaparecidas que causan el evento foco
Haddon [3] consideró eventos foco donde la fuente de daño es la energía física y las barreras se refieren a cómo se
puede modificar o impedir que la energía incida en el objetivo. El modelo se ha extendido de varias maneras [4], por
ejemplo las barreras se dividen a menudo en barreras físicas y barreras administrativas (véanse algunos ejemplos en la
tabla B.1). Las barreras, se puede considerar también en términos de prevención, protección y detección (por ejemplo en
el contexto en el que el evento foco es un incendio, se referirían a la utilización de materiales no inflamables,
proporcionar extintores y la instalación de detectores de humo).
La salida del análisis incluye generalmente una hoja de cálculo de análisis de barreras (véase la tabla B.2), que
identifica las barreras que, o bien estaban disponibles pero resultaron ser ineficaces o no estaban en su lugar durante la
ocurrencia del evento foco.
- 31 - EN 62740:2015
Tabla B.1 – Ejemplos de barreras
Barreras físicas o de energía Barreras administrativas

Características técnicas de seguridad Procedimientos de operación y mantenimiento de plantas
Dispositivos de seguridad y de socorro Reglamentos, políticas y prácticas
Concesiones de diseño conservadoras Formación y educación
Equipos redundantes Protección laboral
Puertas y válvulas bloqueadas Permiso de trabajo
Dispositivos de protección de fallo a tierra Personal cualificado
Blindaje y guardas Métodos de comunicación (comunicación tridireccional)
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
Salida no deseada Fuente del daño Barrera que debería Mecanismo de fallo Valoración de la
(¿Qué pasó?) haber impedido el de la barrera (¿cómo barrera (¿por qué ha
evento no deseado falló la barrera?) fallado la barrera?)
Se lista una cada vez, no Se listan todas la Identificar si la barrera
es necesario que estén barreras físicas y está desaparecida, era
en orden secuencial administrativas para débil o inefectiva y por
cada salida no deseada qué
Un trabajador de Líquido Procedimiento para Presión liberada en el Etiquetado poco claro
mantenimiento aflojó presurizado desactivar la bomba y sistema equivocado
las tuercas de la brida de liberar presión antes
la tubería presurizada de comenzar el trabajo
B.2.2 Fortalezas y limitaciones

Los puntos fuertes del análisis de barreras son los siguientes:
• identifica qué acciones correctoras se requieren para asegurar que las barreras adecuadas (número y efectividad)
están en su lugar.
Las limitaciones del análisis de barrera son las siguientes:
• pueden no reconocerse todas las barreras fallidas o desaparecidas, o el efecto de la tasa o frecuencia con que esas
barreras son solicitadas;
• se tratan factores causales inmediatos en lugar de causas de raíz, es decir, se busca qué barrera ha fallado y cómo,
pero no se explora en profundidad el por qué.
B.3 Modelo de Reason (modelo de queso suizo)

El modelo de Reason [5] se basa en la premisa de que los elementos básicos necesarios en cualquier sistema productivo
son:
EN 62740:2015 - 32 -
• las decisiones apropiadas de la dirección corporativa y de la planta;
• las actividades de gestión de la línea, la formación de operación y mantenimiento, etc.;
• equipos fiables y aptos para el uso;
• personal motivado;
• integración de los elementos humanos y mecánicos;
• protección contra riesgos previsibles.
Hay inevitablemente debilidades en estos elementos que se pueden considerar como fallos latentes. Si se unen para
formar un evento de activación, que puede ser poco importante en otras circunstancias, se traduce en un fallo.
Las deficiencias en los elementos del sistema productivo se representan como agujeros en rebanadas de queso suizo. Se
producirá un evento cuando todas las debilidades individuales se alinean. El modelo de Reason no es estrictamente un
modelo de barreras ya que las capas son sistemas operativos normales con debilidades en lugar de barreras o controles
fallidos.
Se han desarrollado taxonomías de los errores humanos basadas en el modelo de Reason para diferentes sectores.

Los puntos fuertes del modelo de Reason son los siguientes:
• alienta al analista a explorar los factores causales de los errores del operador y de ahí los medios posibles para su
reducción.
Las limitaciones del modelo de Reason son las siguientes:
• analiza superficialmente los factores causales técnicos o ambientales que consideran los aspectos técnicos solamente
en términos de barreras fallidas;
• supone que el problema central es un error del operador (los errores a otros niveles y los fallos organizativos se
exploran principalmente en términos de cómo afectan a los errores del operador);
• no suministra una taxonomía para ayudar en la identificación de las motivaciones y precursores psicológicos de un
error humano o en la identificación de fallos latentes y por lo tanto, su uso correcto requiere experiencia en la
psicología individual y organizacional.
B.4 Modelos de sistemas

La teoría de sistemas [6] fue desarrollado en los años 1940 y 1950 para manejar el aumento de complejidad de los
sistemas después de la segunda guerra mundial y para considerar los aspectos sociales y técnicos de los sistemas como
conjunto.
En los modelos de sistemas, se supone que la interacción humana con la tecnología en estructuras sociales complejas
está influenciada por los objetivos, política y cultura de la organización y por elementos económicos, jurídicos, políticos
y ambientales internos y externos. Este sistema se ve presionado por el rápido ritmo del cambio tecnológico, por un
entorno cada vez más agresivo y competitivo y por factores tales como las prácticas reglamentarias cambiantes y la
presión pública. En este contexto los eventos foco se deben a múltiples factores y por lo general están típicamente
"esperando liberación" y no se deben a cualquier acto o evento.
- 33 - EN 62740:2015
Los fallos se presentan debido a las complejas interacciones entre los componentes del sistema que pueden llevar a la
degradación del rendimiento del sistema. Dos o más eventos discretos dentro de los elementos del sistema pueden
interactuar de una manera inesperada que los diseñadores podrían no haber previsto y que los operadores no pueden
comprender o controlar sin un modelado exhaustivo o sin ensayos. Los factores que contribuyen al evento foco pueden
incluir efectos de las decisiones que son normales en las circunstancias en las que se hicieron, pero que producen un
resultado no deseado.
Los métodos basados en un modelo de sistemas no buscan una cadena causal o un error individual o fallos técnicos,
sino que consideran el sistema en su conjunto, sus interacciones y sus debilidades. Se pueden reconocer fallos humanos
o de hardware individuales, pero la atención se centra en las interacciones y en las cuestiones sistémicas.
B.5 Modelo y procesos de accidente teórico de sistemas (STAMP)

STAMP [7] es un modelo de causalidad basado en la teoría de sistemas [6] que extiende el modelo tradicional (cadenas
de eventos de fallo directamente relacionados) para incluir a los contribuyentes técnicos y sociales a los eventos foco y
sus relaciones. También captura eventos foco que involucran interacciones entre los componentes del sistema sin fallos
y procesos, mecanismos causales indirectos y sistemáticos, toma de decisiones compleja de la Dirección y de los
operadores, tecnologías avanzadas, tales como sistemas digitales y software y defectos de diseño del sistema.
STAMP supone que los incidentes surgen de las interacciones entre los seres humanos, las máquinas y el entorno; trata
a los sistemas como problemas dinámicos de control 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 del
tráfico aéreo tiene que mantener siempre una distancia mínima. Los eventos foco son el resultado de un control
inadecuado o de la aplicación de restricciones al desarrollo, diseño y operación del sistema. En la pérdida del
transbordador espacial "Challenger", por ejemplo, las juntas tóricas no controlaron la liberación de gas propulsor a
través de las juntas que lo unían a la lanzadera espacial. En STAMP, la causa de un evento 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 modo que las presiones financieras u otras que conducen a un cambio de
comportamiento en el tiempo pueden tenerse en cuenta en el proceso de análisis causal.

Los puntos fuertes de STAMP son los siguientes:
• considera el papel de todo el sistema técnico-social en la causalidad;
• incluye factores indirectos y sistémicos en la explicación causal;
• proporciona un modelo para explicar los accidentes en sistemas muy complejos;
• identifica las causas achacables al proceso con el que se desarrolló un sistema.
Las limitaciones de STAMP son las siguientes:
• requiere eventos foco que se vayan a analizar de una manera que es a menudo desconocida para los ingenieros, por
lo tanto, puede llevar más tiempo aprender a analizar eventos foco cuando se utilizan procesos de análisis causal
basados en STAMP.
EN 62740:2015 - 34 -
Anexo C (Informativo)
Descripción detallada de las técnicas de RCA
C.1 Generalidades
El anexo C describe una serie de técnicas que se utilizan durante un RCA. La lista no es exhaustiva pero abarca
ejemplos de los diferentes tipos de técnicas utilizadas. Muchas de estas técnicas están soportadas por herramientas
software. Algunas de las metodologías y herramientas software tienen elementos que son propietarios, lo cual puede
tener un impacto en el coste de la aplicación de la técnica.
Algunas técnicas tienen como objetivo identificar los factores causales que se pueden mostrar como necesarios si se
produce el evento foco. Otros métodos buscan debilidades generales del sistema como un todo que probablemente
contribuyeron al evento foco, pero, en ausencia de las cuales, podría producirse el evento foco. En algunas
terminologías un "factor causal" no se puede describir a menos que sea necesario para el evento foco. En este anexo
tales factores causales se refieren como " factores causales necesarios". Las debilidades identificadas que pueden haber
jugado un papel en el evento foco, pero que puede que no sean necesarias se conocen como "factores contribuyentes".
En general, la identificación de los factores causales necesarios será repetible y basado en evidencias. Puede haber un
mayor nivel de subjetividad en la identificación de los factores contribuyentes y diferentes técnicas de análisis con un
enfoque distinto, pueden identificar diferentes factores.
C.2 Gráficos de eventos y factores causales (ECF)

C.2.1 Información general
El gráfico ECF [9] registra los eventos en orden cronológico, de izquierda a derecha en rectángulos con eventos
caracterizados por los sujetos individuales 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 acontecimientos).Los eventos están conectados por líneas
continuas y las condiciones por líneas de trazos. Los eventos y condiciones basados en evidencias tienen un contorno de
trazo continuo mientras que los basados en suposiciones lo tienen de trazo discontinuo. Puede haber múltiples
secuencias de eventos múltiples o ramificadas, cada una con su propias condiciones.
La figura C.1 ilustra un ejemplo de un gráfico ECF en la que una actividad de mantenimiento se realizó incorrectamente
porque el mantenedor se presentó tarde, lo que resultó en un aterrizaje de emergencia de una aeronave.
- 35 - EN 62740:2015
Figura C.1 – Ejemplo de un diagrama de ECF
C.2.2 Proceso
A continuación se describe el proceso para la elaboración de un diagrama de ECF:
a) Identificar el evento foco y registrarlo en una caja en el lado derecho.
b) Registrar la cadena principal de los acontecimientos que condujeron al evento foco donde cada evento en la cadena
es a la vez inmediato y necesario para el evento del lado derecho. Por lo tanto, la consecuencia se registra en el lado
derecho de cada evento (factor causal). También la consecuencia de un evento anterior puede ser el factor causal del
evento siguiente. Los eventos se muestran en rectángulos unidos por flechas a la derecha del evento foco.
c) Determinar qué condiciones llevaron a estos eventos. Indicar cada uno de ellos en un óvalo por encima del hecho
pertinente.
d) Añadir cualquier cadena secundaria de eventos que pueda ser pertinente para el evento foco y sus condiciones.
e) Verificar la validez de los factores causales obteniendo evidencias que determinen si las condiciones y eventos son
ciertos.
f) Desarrollar el diagrama ECF hasta que se identifique el evento del inicio de la secuencia y se añadan todas las
condiciones que pueden verificarse mediante evidencias.
En general, al principio de la investigación no se conoce la cronología exacta de eventos pero se vuelve más clara a
medida que se avanza. Por tanto, se debería utilizar un método que permitiera a los investigadores cambiar fácilmente la
secuencia de eventos y las condiciones conforme se vaya obteniendo más información.
C.2.3 Fortalezas y limitaciones

Los puntos fuertes de ECF son los siguientes:
• ayuda a la verificación de las cadenas causales y secuencias de eventos;
• proporciona una estructura para recopilar, organizar e integrar las evidencias;
EN 62740:2015 - 36 -
• identifica las carencias de información;
• ayuda a la comunicación, proporcionando una ayuda visual eficaz que resume la información clave sobre el evento
foco y sus causas.
Las limitaciones de ECF son las siguientes:
• identifica algunos factores causales, pero puede que no determine siempre las causas raíz;
• puede resultar demasiado complicado para problemas sencillos.
C.3 Secuenciación de eventos multilineales (MES) y trazado de eventos sucesivos (STEP)

MES [10] y STEP [11] son métodos desarrollados para analizar eventos foco en sistemas complejos, donde STEP es un
sucesor de MES.
Al igual que con los diagramas ECF, MES / STEP concibe un evento foco como el resultado de una sucesión de eventos
interrelacionados con eventos caracterizados por un solo sujeto y un verbo activo. En MES y STEP, el sujeto se llama
actor (que puede ser una persona, una máquina o incluso una pertenencia).
Los eventos se representan como bloques de construcción de evento (BBS), que consisten en registros de datos
(parciales o totales) que se describen en la figura C.2. Estos se organizan durante el análisis en una matriz tiempo-actor
en la que el eje vertical de la matriz representa los diferentes actores y el eje horizontal representa el tiempo.
La matriz tiempo-actor también contiene:
• las condiciones necesarias para permitir un evento junto con los eventos precursores;
• las anotaciones para otras tareas 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 en la figura C.3 se da un ejemplo que muestra parte de la representación de un evento de mantenimiento de un

tanque.
Figura C.2 – Datos de un bloque de construcción de eventos
- 37 - EN 62740:2015
C.3.2 Proceso
MES / STEP tiene los siguientes pasos:
a) Recopilar la información para la serie inicial de bloques de construcción, e identificar y rastrear información
ausente.
b) Disponer los bloques iniciales de construcción en una matriz inicial tiempo-actor.
c) Identificar y generar hipótesis para "rellenar" los huecos con eventos (en forma de más bloques de construcción).
d) Terminar el proceso cuando un analista considera que hay información suficiente en la matriz de tiempo-actor.

MES/STEP tiene las mismas fortalezas y limitaciones que ECF. El formato de datos es relativamente más elaborado y
existen mecanismos explícitos para la determinación y el seguimiento de los datos que faltan y los intentos para
determinar esos datos. Algunos de estos mecanismos "contables" 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 así como la adquisición de datos y las tareas explicativas pendientes de realizar.
Esto significa que se dispone de una representación visual comprensible del estado de la investigación en cada punto
momento.
EN 62740:2015
- 38 -
Figura C.3 – Ejemplo de matriz tiempo-actor
- 39 - EN 62740:2015
C.4 El método "por qué"

El método "por qué" utiliza un proceso de cuestionamiento directo para llegar a las causas raíz.
El cuestionario comienza con una declaración de la situación y pregunta por qué ocurrió. La respuesta a esta pregunta se
convierte en un segundo ¿por qué? y su respuesta en un tercero. El cuestionario cesa cuando se alcanza la regla de
parada. Generalmente, esto requiere aproximadamente 5 niveles de preguntas, por lo que el método se conoce a veces
como los 5 porqués.
Cuando una pregunta por qué proporciona varios factores causales, se explora cada uno y el método produce un árbol
porqués.
El método por qué se utiliza solo para situaciones simples, pero también es inherente en métodos de árbol más
complejos, tales como el método del árbol de causas (CTM) (véase el capítulo C.5). Puede ser útil para sonsacar
información de testigos sobre cómo y por qué se produjo un evento, porque la simple pregunta "por qué" no hace
suposiciones acerca de la causa ni guía al testigo.
La figura C.4 ilustra un ejemplo de un compresor que ha experimentado una parada no programada. En el ejemplo, el
cuarto por qué sugirió una serie de factores causales potenciales de la falta de lubricación y se buscó una evidencia para
definir lo que de hecho ocurrió. Aunque hubo un error humano involucrado en cuanto que una persona no siguió los
procedimientos de arranque especificados, la recomendación es mejorar el diseño de modo que los motores del
compresor y de la bomba estén vinculados. En este caso, no es útil un análisis adicional de por qué se produjo el error.
Figura C.4 – Ejemplo de árbol de porqués
EN 62740:2015 - 40 -
C.4.2 Proceso
El método "por qué" tiene los siguientes pasos:
• Se identifica y registra el evento foco como inicio de un diagrama "por qué".
• Se pregunta por qué se produjo el evento foco, buscando sólo los factores causales inmediatos.
• Se pregunta "por qué" sucesivamente con respecto a la respuesta anterior. En cada caso la respuesta a la pregunta
"por qué" debería ser un factor causal inmediato de la respuesta anterior.
La pregunta "por qué" se pide tantas veces como sea necesario para llegar a una causa raíz, lo que sucede normalmente
con cinco preguntas, aunque esto es sólo una directriz. Cada vez que se hace la pregunta, puede haber múltiples
respuestas y será necesario un análisis para eliminar las respuestas posibles que no son aplicables. Puede ser más eficaz
preguntar "¿por qué falló el proceso? en lugar de preguntar simplemente "por qué"?.
Puede ser útil tener en cuenta un conjunto de categorías de causa, como las del método Ishikawa e involucrar a un
equipo de personas. Esto ayudará a asegurar que los investigadores consideran todas las áreas pertinentes

Los puntos fuertes del método "por qué" son los siguientes:
• es fácil de aplicar por los involucrados en el problema;
• es fácil de entender por los demás;
• es un proceso rápido para lograr resultados con problemas sencillos;
• no requiere de un amplio conocimiento 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:
• sólo es adecuado para situaciones simples;
• depende en gran medida de los conocimientos y la experiencia de las personas que responden a las preguntas, a
menudo se requiere experiencia en modos de fallos técnicos y errores humanos para alcanzar la causa raíz;
• las causas raíz son propensas a perderse si están fuera de la base de conocimiento de los involucrados;
• hay una posible incertidumbre acerca de cuándo se han identificado las causas raíz apropiadas;
• se puede desarrollar hasta un nivel en el que se consideren las razones de las acciones de las personas, donde las
evidencias no están siempre disponibles y, por tanto, donde los resultados son siempre repetibles.
C.5 Método del árbol de causas (CTM)

CTM [12] es una técnica sistemática para analizar y representar gráficamente los eventos y condiciones que
contribuyeron a un evento foco.
El método examina todos los componentes del sistema asociados con el evento foco. La investigación se inicia
mediante el establecimiento de los hechos tangibles, teniendo cuidado, en esta fase, de no interpretarlos o expresar una
opinión sobre ellos.
- 41 - EN 62740:2015
CTM es similar al método por qué en concepto, pero genera árboles más complejos y considera explícitamente factores
causales técnicos, organizativos, humanos y ambientales. Cada antecedente (factor causal identificado) se prueba para
comprobar que es un factor causal inmediato y necesario del anterior, mientras que el método por qué es menos
riguroso. Por lo tanto, CTM es adecuado para situaciones más complejas.
CTM es también similar a un árbol de fallos, pero, mientras que un árbol de fallos se utiliza antes de un evento para
explorar todos los posibles factores causales y se especifican la(s) relación(es) lógica(s) estricta (s) entre los fallos, el
árbol de causas incluye sólo los factores causales que se aplican a un evento específico que ya ha ocurrido y no
desarrolla las relaciones lógicas en detalle.
Un árbol de causas puede utilizarse para explorar éxitos y fracasos.
El árbol de causas forma una red de las causas que directa o indirectamente han causado el evento foco, utilizando las
tres relaciones lógicas mostradas en la figura C.5.
Secuencia: Una causa (Y) tiene un único origen directo (X),

es decir, (X) era necesaria y suficiente para que (Y) se
produjera
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) era necesario para que (Y) se produjera
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 necesaria para que (Y1) e (Y2) se produjeran
Figura C.5 – Símbolos y enlaces usados en CTM
La figura C.6 muestra un árbol de ejemplo, en la que el Sr. L (la víctima) y el Sr. A trabajan de noche, como excepción,
para almacenar un excedente de stock. De acuerdo con el manual, se requería que el Sr. L y el Sr. A cargaran la
trituradora con "harina" que luego se embolsa y almacena. Normalmente esta actividad está bajo la responsabilidad de
un jefe de equipo cuya presencia no se había considerado esencial por la dirección para esta noche. Por propia iniciativa
para ahorrar tiempo, el Sr. L tomó una carretilla elevadora (la llave de contacto estaba en el salpicadero como siempre)
para almacenar las bolsas. Al final de la tarea, el Sr. L se dispuso a volver a dejar la carretilla elevadora en su lugar. El
Sr. L realizó una curva cerrada marcha atrás, las horquillas estaban elevadas, y mientras trataba de evitar un agujero en
el suelo el montacargas volcó, aplastando al Sr. L entre el suelo y el larguero derecho de seguridad de la carretilla.
EN 62740:2015
- 42 -
Figura C.6 – Ejemplo de árbol causal
- 43 - EN 62740:2015
C.5.2 Proceso
CTM tiene los siguientes pasos:
a) Se identifica el evento foco que se va a analizar y se registra como punto de partida del árbol.
b) Se recogen y registran todos los datos pertinentes, incluyendo las personas, sus actividades y acciones, materiales y
equipos y factores relacionados con el entorno físico y psicosocial.
c) Se hace una lista de los factores causales para el evento foco. Estos deberían apoyarse en evidencias y expresarse
con tanta precisión como sea posible. No se incluyen opiniones y juicios personales. Los factores causales incluyen
aquellos que son inusuales o cambian el curso normal de los eventos y los que son normales pero que desempeñaron
un papel activo en la ocurrencia del evento.
d) Se trabaja a la inversa, hacia las causas raíz preguntando de forma sistemática para cada antecedente que se ha
recogido:
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 es así, ¿cuáles son los otros antecedentes (X1, X2,...) que eran igualmente necesarios para dar lugar
directamente a Y?
e) Se muestran estos factores causales necesarios inmediatos en una caja unida por una flecha al evento foco. El árbol
se puede dibujar en horizontal o vertical, pero normalmente se dibuja horizontalmente comenzando por la derecha,
de forma que la lectura de izquierda a derecha corresponde a la cronología de los eventos.
f) Se siguen haciendo las mismas preguntas con respecto a cada factor causal necesario encontrado hasta que el equipo
esté de acuerdo en que ya no tiene sentido continuar.
g) Se verifica la validez del árbol mediante la obtención de más evidencias que determinen si es verdad.

Los puntos fuertes del 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 las zonas de recogida de datos a medida que avanza la investigación;
• se puede utilizar para analizar los eventos de éxito o fracaso;
• se puede utilizar para eventos técnicos y no técnicos.
Las limitaciones del CTM son los siguientes:
• muchos factores humanos y organizativos pueden contribuir a la aparición del evento foco y a menudo es difícil
establecer, en un caso particular, cuáles fueron los factores causales necesarios;
• no existe una orientación sobre la manera de buscar los factores causales; por lo tanto, se necesita experiencia en
errores humanos y sistemas organizativos cuando el árbol implica fallos humano y organizativos, en los que a
menudo es difícil obtener evidencias;
EN 62740:2015 - 44 -
• es difícil de aplicar cuando un evento se produce como resultado de un cambio de la calidad en varias áreas, donde
ningún factor causal único es un factor causal necesario.
C.6 Análisis Por qué-porque (WBA)

El 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 por ejemplo, se utiliza una condición, llamada
contraste de hipótesis, (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 CT pregunta si en el caso de que A no hubiera ocurrido, B tampoco habría ocurrido.
(Dado que A ocurrió, suponer que A no se hubiera producido es contrario a los hechos, de ahí "contraste de hipótesis").
Al hacer esta pregunta, se supone que todas las demás condiciones se han mantenido igual. Si la respuesta es sí: B no
habría ocurrido y 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 ¿Por qué?- porque (WBG), una colección de "Nodos", cajas,
diamantes y otras formas, que contienen una breve descripción del hecho, unidos por "bordes" o flechas, donde el nodo
en la cola de una flecha es un factor causal necesario del nodo en la punta, tal y como lo determina el CT.
Un WBA es acíclico (no contiene bucles), por lo que normalmente se dibuja con flechas apuntando en dirección
ascendente, como se muestra en la figura C.7, u horizontalmente con flechas que apuntan generalmente de izquierda a
derecha o de derecha a izquierda.
Se utiliza la prueba de integridad causal (CCT) con el fin de determinar si hay suficientes factores causales en la
colección de eventos y situaciones presentadas. El CCT se aplica a un evento o situación dada y a su colección de
factores causales necesarios según lo determinado por la CT. Si el CCT no pasa con éxito, la colección de hechos y
situaciones tiene que ampliarse con otros factores hasta que lo haga. Supongamos que el CT ha determinado que A1, A2,
..., An son factores causales necesarios de B. Entonces el CCT se considera que ha pasado con éxito si, no habiendo
ocurrido B, uno de los A1, A2, ..., no hubiera ocurrido tampoco (formalmente, NO-B es un factor causal necesario de
NO (A1 y A2 y ... y An) según lo determinado por el CT).
Cuando se ha construido un WBG y el CCT ha pasado con éxito para todos los eventos y situaciones que lo componen,
el WBG está completo y se considera que representa una explicación causal suficiente del evento foco.
La figura C.7 ilustra un ejemplo de un WBG para un accidente de un avión comercial por rebasar la pista de aterrizaje.
- 45 -
EN 62740:2015
Figura C.7 – Ejemplo de WBG
EN 62740:2015 - 46 -
C.6.2 Proceso
El WBA tiene los siguientes pasos:
a) Se determina una colección de hechos que se consideren pertinentes, bajo la guía de una regla de parada. Esto da
una colección C inicial de los hechos, divididos en eventos, estados y situaciones.
b) Se selecciona el evento foco (llamado en el WBA caso de accidente).
c) Se determinan intuitivamente los factores causales necesarios inmediatos del evento foco entre la colección C;
comprobar utilizando el CT. Mostrar los resultados visualmente como un WBG parcial.
d) Se determinan intuitivamente los factores causales necesarios de esos factores inmediatos; comprobar utilizando el
CT. Extender el WBG con estos factores.
e) Se procede a rellenar el análisis (para extender el WBG) probando cada hecho en C frente a los factores que ya están
en el WBG.
f) Se aplica el CCT para determinar si el WBG está completo, o si faltan factores en la colección C.
g) Se extiende C si es necesario; se incorporan los nuevos hechos en el WBG utilizando el CT. Si no se dispone de
suficiente información, se pueden incluir hipótesis, siempre que estén claramente identificadas como tales.
h) Se finaliza cuando el CCT muestra factores causales suficientes para cada hecho, de acuerdo con la regla de parada.
Si los hechos disponibles son insuficientes, tienen que incluirse hipótesis para permitir que el CCT tenga éxito, pero
deben estar claramente identificadas como tales.

Los puntos fuertes del WBA son los siguientes:
• puede realizarse con un mínimo de formación (con el uso de herramientas adecuadas que ayudan en la extracción de
datos a partir de descripciones narrativas, un analista sin experiencia puede normalmente realizar un primer WBA
con éxito en dos horas);
• los resultados del análisis son fácilmente comprensibles por parte de terceros;
• la base conceptual necesaria para realizar una WBA es limitada (un analista debe ser capaz de aplicar el CT, y luego
el CCT);
• con un WBA se puede analizar cualquier red de fenómenos relacionados causalmente;
• el razonamiento detrás de un WBA puede comprobarse formalmente mediante una lógica formal;
• se puede utilizar junto con otros métodos, por ejemplo, los que proporcionan más estructura a la colección de
hechos.
Las limitaciones de la WBA son las siguientes:
• el método no proporciona ninguna orientación sobre la recopilación de hechos a los que se aplican las pruebas; por
ejemplo no hay una estructuración de los hechos en categorías tales como técnicos, de procedimiento, de factores
humanos, organizativos y legales;
• como los hechos no están estructurados, el WBA ofrece una orientación limitada sobre medidas correctoras en el
caso en que se necesite evitar la recurrencia.
- 47 - EN 62740:2015
C.7 Método de árbol de fallos y de éxito

Un árbol de fallos [14] muestra los factores causales necesarios inmediatos de un evento foco, sus predecesores causales
y las relaciones lógicas entre ellos. El análisis por árbol de fallos (AAF) [15] se utiliza normalmente como un método a
priori de identificación y análisis de los modos de fallo potenciales, particularmente de los equipos. El diagrama de
árbol de fallos se puede utilizar en RCA mediante la construcción de un árbol siguiendo la misma lógica, pero
incluyendo en el árbol sólo los eventos que realmente ocurrieron.
Se pueden usar puertas O durante el análisis para describir factores causales alternativos que se necesita evaluar, pero
cuando todos los hechos están claramente establecidos solamente deben permanecer las puertas Y, a menos que el
propósito de la investigación sea evitar otros eventos relacionados. Por lo tanto, según avanza la investigación, se van
descartando y eliminando del árbol los factores causales potenciales que no encajan en las evidencias. Cerrando cada
rama del árbol, los factores causales del evento foco se van haciendo aparentes.
Estrictamente, un árbol de fallos representa eventos binarios, en los que una declaración es verdadera o falsa, por
ejemplo, un componente ha fallado o no. En RCA, la estructura de árbol de fallos se suele aplicar a un árbol de factores
causales donde no se obedecen estrictamente las reglas lógicas y se incluyen tanto cambios en la calidad como eventos
binarios.
Se puede aplicar una lógica similar cuando el evento foco es un caso de éxito. En este caso, el árbol se conoce como
árbol de éxito.
La figura C.8 muestra un ejemplo de un árbol de fallos.
Figura C.8 – Ejemplo de árbol de fallos durante el análisis
EN 62740:2015 - 48 -
C.7.2 Proceso
El proceso para la elaboración de un árbol de fallos/éxito es el siguiente:
a) Se define el evento foco que se va a analizar y se registra como punto de partida del árbol.
b) Se establecen los factores causales necesarios inmediatos del evento foco y se representan en un cuadro unidos por
una flecha al evento foco. El árbol puede dibujarse horizontal o verticalmente. Estos son los factores causales de
primer nivel del evento foco.
c) Se establecen las relaciones lógicas entre los factores causales inmediatos utilizando puertas Y y O. Los eventos en
la entrada de una puerta Y tienen que ser necesarios y suficientes para causar el evento anterior. Se pueden usar
puertas O durante el análisis para describir factores causales potenciales que requieren investigación.
d) Se examina cada factor causal para decidir si se trata de una causa raíz o es el resultado de factores causales
subyacentes.
e) Se validan los factores causales potenciales y se actualiza el árbol en consecuencia.
f) Se continúa el árbol hacia abajo, hasta que se alcance la regla de parada.
Cuando se desarrolla el árbol, se considera para cada factor causal en cada nivel la posibilidad de factores causales
relacionados con las personas, con los equipos y con el entorno. No se debería separarlos en la parte superior del árbol.

Los puntos fuertes del método del árbol de fallo/éxito son los siguientes:
• proporciona un método para dividir el análisis de grandes eventos foco complejos;
• está soportado por muchos paquetes software comerciales que ayudan en el desarrollo de la estructura de árbol de
fallos;
• alienta la participación del grupo;
• utiliza un formato ordenado, fácil de leer;
• identifica zonas de recogida de datos.
Las limitaciones del método del árbol de fallo/éxito son los siguientes:
• requiere un profesional experimentado;
• no tiene ningún modelo subyacente de causalidad y no proporciona orientación sobre cómo buscar factores causales;
• no representa fácilmente situaciones en las que un evento se produce como resultado de un cambio general de
calidad que afecta, por ejemplo al respeto a los procedimientos o a las tolerancias de componentes físicos.
C.8 Diagrama de espina de pescado o Ishikawa

El diagrama de espina de pescado o Ishikawa [16] es una técnica que ayuda a identificar, analizar y presentar las
posibles causas de un evento foco. Se puede utilizar para estructurar una sesión de tormenta de ideas y para sugerir
ideas donde buscar más evidencias. La técnica la inventó Kaoru Ishikawa y gráficamente ilustra 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.
- 49 - EN 62740:2015
La figura C.9 muestra un ejemplo de un diagrama de espina de pescado o Ishikawa.
Figura C.9 – Ejemplo de diagrama de espina de pescado
C.8.2 Proceso
El proceso para desarrollar un diagrama de espina de pescado o Ishikawa es el siguiente:
a) Se identifica el evento foco, se registra en el lado derecho y se traza una línea horizontal desde ahí. Esto forma la
cabeza y la espina central del pez.
b) Se establecen las principales categorías de causas que deben considerarse y se dibujan líneas a partir de la espina
central para representar cada categoría. Categorías de uso general incluyen:
1) 5 Ms: métodos, maquinaria, gestión (management), materiales, mano de obra;
2) 4 Ps: lugar (place), procedimientos, personas, políticas;
3) 4 Ss: entorno (surroundings), proveedores (suppliers), sistemas, habilidades.
c) Se identifican para cada categoría los posibles factores causales del evento foco, que se presentan como líneas más
pequeñas que salen de las "raspas" del pez. Se pueden mostrar niveles cada vez más detallados de factores causales
como sub-ramas que salen de cada línea de causa. Si una rama tiene demasiadas sub-ramas, puede ser necesario
descomponer el diagrama en diagramas más pequeños.
EN 62740:2015 - 50 -
d) Se analiza el diagrama: El diagrama muestra ahora todos los posibles factores causales del evento foco. El último
paso es investigar los factores causales más probables que comprueba si el análisis es correcto. El análisis incluye:
1) revisar el "equilibrio" del diagrama, verificando con niveles comparables de detalle para identificar la necesidad
de una mayor identificación de factores causales;
2) identificar los factores causales que aparecen en varias ocasiones, ya que pueden representar causas raíz;
3) evaluar lo que se puede medir en cada causa con el fin de cuantificar los efectos de cualquier cambio realizado;
4) destacar los factores causales para los que se puedan tomar acciones.

Los puntos fuertes del diagrama de espina de pescado o Ishikawa son los siguientes:
• alienta la participación del grupo para identificar las percepciones de los factores causales de cada persona;
• busca factores causales bajo un conjunto de categorías, por lo que identificará una serie de factores causales
relativos a factores humanos y organizativos, así como a factores del hardware y de procedimiento;
• utiliza un formato ordenado, fácil de leer;
• indica los posibles factores causales de la variación;
• puede utilizarse para investigaciones simples o como parte de una investigación más compleja.
Las limitaciones del diagrama de espina de pescado o Ishikawa son los siguientes:
• No existe un modelo o teoría de causalidad subyacente, por lo que los factores causales identificados están basados
en las percepciones del equipo.
C.9 Seguridad a través del aprendizaje organizativo (SOL)

El SOL [17] es una técnica de análisis de eventos, que busca debilidades en el sistema complejo socio-técnico en el que
se produjo el evento. El propósito de SOL es proporcionar un modelo del sistema e identificar sus debilidades, de forma
que se pueda mejorar y prevenir la recurrencia del evento foco evitado. Se hace hincapié en el aprendizaje organizativo.
C.9.2 Proceso
El SOL tiene los siguientes pasos:
1) Se describe la situación utilizando una matriz de tiempo-actor producida por un MES / STEP (véase el capítulo C.3).
2) Se identifican los factores causales (que puede ser directos o indirectos, véase la tabla C.1) para cada evento en la
matriz de tiempo-actor, guiada por listas de preguntas derivadas de la experiencia y de las investigaciones de los
autores del SOL. Los factores causales directos son aquellos que han producido el evento foco de forma inmediata,
los factores causales indirectos aparecen más abajo en la cadena causal, pero pueden implicar las mismas cuestiones.
3) Se clasifican factores causales en la tecnología, en las personas, en el grupo de trabajo, en la organización y en el

ambiente organizativo.
- 51 - EN 62740:2015
Tabla C.1 – Factores causales directos e indirectos
Factores causales directos Factores causales indirectos

Información Información
Comunicación Comunicación
Condiciones de trabajo Condiciones de trabajo
Rendimiento del personal Rendimiento del personal
Violaciones Violaciones
Componentes técnicos Planificación
Responsabilidad
Control y supervisión
Influencia del grupo
Reglas, procedimientos y documentos
Calificaciones
Formación
Organización y gestión
Principios de seguridad
Gestión de la calidad
Mantenimiento
Organismos reguladores y de consultoría
Influencias ambientales

Los puntos fuertes de SOL son los siguientes:
• el formato de la lista de comprobación permite producir análisis útiles a usuarios que no son especialistas en
sistemas organizativos o en psicología organizativa;
• el énfasis en los factores causales en lugar de en los factores causales necesarios permite considerar más factores que
en 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 margen para el juicio del analista individual y ayuda
a dar uniformidad al análisis SOL;
• la regla de parada se define implícitamente por las preguntas de la lista de comprobación: cuando se han contestado,
la información se considera adecuada.
Las limitaciones de SOL son las siguientes:
• no hay una noción específica de lo que es un factor causal que no sea lo que está implícito en las preguntas de la
lista de verificación;
• el nivel de detalle depende de la lista de comprobación predeterminada de preguntas en lugar de la necesidad

percibida;
• la lista de comprobación de preguntas se deriva de la investigación en el sector nuclear y puede ser menos adecuada
para otros sectores.
EN 62740:2015 - 52 -
C.10 Árbol de supervisión de la gestión y de los riesgos (MORT)

El MORT [18] fue desarrollado inicialmente para el análisis de las causas raíz y los factores causales de incidentes en
los sectores nuclear y aeronáutico en los EE.UU., pero ahora se ha aplicado en muchos otros.
El MORT es un árbol pre-poblado basado en un modelo de sistema de gestión de una organización, que proporciona
efectivamente una lista de comprobación detallada para revisar qué partes de la gestión y de los sistemas de control eran
menos que adecuados cuando se produjo el evento foco. La estructura básica del árbol se muestra en la figura C.10.
Figura C.10 – Ejemplo de diagrama MORT
MORT supone que un fallo se produce como resultado de descuidos u omisiones en los sistemas de gestión o en los
factores de control específicos que deberían haber impedido que se produjera el evento foco.
En última instancia, los fallos en alguna rama del árbol se producen porque hay algo en los sistemas de gestión general
(sistemas de información, diseño y planificación, preparación para la operación, mantenimiento o supervisión) que
estaba en un estado menos adecuado. Cada caja en la figura C.10 se desarrolla en una estructura detallada de árbol que
muestra los factores que podrían haber sido menos adecuados.
C.10.2 Proceso
Se comienza con el evento foco y luego se desciende a lo largo del árbol MORT de una manera lógica preguntando y
respondiendo a las pre-preguntas del manual MORT. Los símbolos en el gráfico MORT se codifican por colores para
indicar:
• no hay ningún problema con algún elemento (adecuado);
• el elemento está dando lugar a un problema (menos adecuado);
• hay necesidad de nuevas investigaciones.
- 53 - EN 62740:2015

Los puntos fuertes de MORT son los siguientes:
• proporciona una guía completa para la búsqueda de todos los aspectos posibles del sistema que no fueron adecuados
en el momento del evento foco;
• se requiere menos conocimientos especializados que en algunas técnicas porque se proporcionan directrices
detalladas sobre posibles factores causales;
• identifica las debilidades en el sistema que podrían aplicarse en una amplia gama de escenarios de fallo.
Las limitaciones de MORT son los siguientes:
• explora las debilidades del sistema en general, que podrían haber desempeñado un papel en el evento foco en lugar
de buscar los factores causales inmediatos o necesarios;
• se plantea un gran número de preguntas (alrededor de 1 500), por lo que el método consume mucho tiempo y, por lo
tanto, es más apropiado para eventos serios;
• a menos que la organización a la que se le aplica sea una organización de alta fiabilidad se encuentran muchos
puntos débiles lo que hace que los cambios sean difíciles de implementar;
• el primer aprendizaje o la primera aplicación del método pueden ser tediosos.
C.11 AcciMaps
AcciMaps [19] se basa en los conceptos de causalidad publicados por Rasmussen y Svedung [20] y en el modelo de
sistemas de organización (véase el capítulo B.4).
AcciMaps es una representación gráfica utilizada para estructurar el análisis de un evento foco y para identificar las
interacciones en el sistema socio-técnico en el que se produjo el evento foco. Es un método diseñado para revelar
amplios fallos, decisiones y acciones a nivel de sistema, implicadas en un evento foco, que se disponen en capas que
representan los diferentes niveles de un sistema socio-técnico desde el gobierno hasta el equipo y los entornos
involucrados. También examina los actores individuales en cada nivel y sus rutinas de toma de decisiones y sus
competencias.
En la figura C.11 se muestra un ejemplo AcciMaps 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 foco (edificios, equipos, entorno, etc.).
El siguiente nivel es la secuencia de eventos que conduce al evento foco, incluyendo los fallos, las acciones y las
decisiones (incluyendo acciones y decisiones normales) que han jugado algún papel. Los niveles más altos muestran las
decisiones y acciones en cada nivel que influyeron, o podrían haber influido, en la secuencia de eventos del nivel
inferior.
C.11.2 Proceso
Un AcciMaps se desarrolla de la siguiente manera:
a) Se define un modelo del sistema con diferentes niveles de la organización.
b) Se rellenan los niveles (utilizando cajas (nodos)) con las decisiones y acciones pertinentes al evento foco, las
condiciones que conducen a ellos y sus consecuencias.
c) Se dibujan flechas que muestran todos los vínculos e influencias.
d) Se puede agregar un proceso como el WBA para determinar cuál de los aspectos identificados fueron factores
causales necesarios del evento foco.
EN 62740:2015
- 54 -
Figura C.11 – Ejemplo de un AcciMap
- 55 - EN 62740:2015

Los puntos fuertes de AcciMaps son los siguientes:
• AcciMaps tiene potencial para ser altamente integral en la identificación de factores causales a través de todos los
niveles del sistema, ya que no hay taxonomía ni directrices;
• los vínculos dentro y entre los niveles ayudan a asegurar que los fallos se consideren en el contexto de las cosas que
les afectaron.
• el error humano tiene la misma atención que los equipos y los factores organizativos de más alto nivel.
• no se incluyen los factores personales que influyen en las decisiones, en particular en los niveles inferiores.
Las limitaciones de AcciMaps son los siguientes:
• la falta de una taxonomía significa que los factores identificados se basan en la percepción del equipo;
• el modelo de organización es exterior al análisis y no existe un criterio para asegurar que es adecuado;
• el resultado del análisis AcciMaps está ligeramente limitado, por lo tanto, es posible derivar diferentes AcciMaps
para el mismo evento foco;
• sin taxonomía específica es difícil agregar múltiples análisis para encontrar factores comunes;
• la generalidad de los factores en los nodos a menudo es alta y puede ser muy abstracta. esto hace que sea difícil
deducir acciones precisas;
• tiene un enfoque analítico débil para fallos físicos y de los equipos;
• por sí solo, no representa los resultados de un análisis causal.
C.12 Tripod Beta

Tripod Beta [21] es una metodología de investigación y análisis de incidentes que combina las ideas del modelo de
Reason (véase el apartado B.3) y del Análisis de Barreras (véase el apartado B.2), junto con el sistema de Rasmussen de
modelizado de errores genéricos (GEMS) y el camino de causalidad Tripod Wagenaar. En él se describen los incidentes
en términos de 'objetos', por ejemplo, gente, equipo, etc., que se cambian por "agentes de cambio", por ejemplo, algo
con el potencial de cambiar un objeto. También modeliza 'barreras', mostrándolas, por ejemplo, como eficaz, fallida o
inadecuada.
Tripod Beta ofrece un formato y reglas para la modelización de eventos (evento foco y los eventos que conduce a él, y
después, el evento foco) y para la vinculación de todos los elementos juntos, trabajando hacia atrás en última instancia
hasta las causas subyacentes. Se han desarrollado una serie de paquetes software basados en estas reglas, pero puede
utilizarse con o sin software. Las técnicas basadas en software contienen listas de verificación derivadas de modelos y
de análisis de eventos pasados que se han producido sobre todo en la industria de la extracción de petróleo en alta mar.
El núcleo de un análisis Tripod es una representación de diagrama en "árbol" de la red de causas (véase la figura C.12),
que describe el evento foco como una red de eventos y sus relaciones.
EN 62740:2015 - 56 -
Figura C.12 – Ejemplo de diagrama árbol Tripod Beta
C.12.2 Proceso
El proceso para desarrollar el diagrama de árbol Beta Trpod es identificar lo siguiente:
a) El agente (peligro o peligros) que conducen al evento foco y el objetivo que se perjudicó.
b) Los controles o barreras, que faltaban o fallaron, y que podrían haber impedido el evento o protegido el objetivo.
c) Las causas inmediatas – el acto humano, que dio lugar a la barrera fallada. Estos son los fallos o errores que tienen
efecto inmediato y se producen en el punto de contacto entre un ser humano y un sistema (por ejemplo, pulsar el
botón equivocado, no hacer caso de una luz de advertencia).
d) Las condiciones previas – precursores psicológicos y de situación, por ejemplo, el tipo de fallo humano
(deslizamiento, lapsus, infracción, etc.).
e) Las causas subyacentes (fallos latentes) en la organización, es decir, insuficiencias en el sistema de gestión, cultura,
etc. Se pueden clasificar en " factores de riesgo básico" predefinidos, derivadas de tormentas de ideas y de la
investigación de resultados de auditorías y de investigaciones de accidentes en la industria petrolera en alta mar.
- 57 - EN 62740:2015

Los puntos fuertes de la metodología Tripod son los siguientes:
• proporciona un mapa del evento foco y sus factores causales;
• puede ayudar a dirigir la investigación y a definir su ámbito de aplicación;
• define las barreras en el sistema;
• está basado en investigaciones científicas e incluye un modelo de comportamiento humano para descubrir lo que
está detrás del comportamiento observado;
• lleva al investigador a considerar las razones más allá de las causas inmediatas y del error humano;
• hay paquetes de software manejados por menús.
Las limitaciones de la metodología del Tripod son las siguientes:
• puede ser intensivo en recursos;
• lleva a las causas subyacentes a nivel de 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 dan lugar a medidas correctoras simples;
• generalmente requiere amplia formación.
C.13 Análisis causal utilizando STAMP (CAST)

CAST [7] es una técnica que analiza todo el proceso socio-técnico involucrado en un evento foco. CAST se basa en
STAMP (véase el capítulo B.5), que se utiliza para guiar el análisis causal. CAST documenta el proceso dinámico que
conduce al evento foco, incluyendo la estructura de control socio-técnica, así como las restricciones que se violaron en
cada nivel de la estructura de control y por qué. El análisis produce múltiples vistas del evento foco, dependiendo de la
perspectiva y del nivel a partir del cual se está viendo el evento foco.
Para ilustrar CAST, considérese un evento foco que implica la contaminación de una red pública de suministro de agua
con E. coli en una pequeña ciudad de Canadá. La figura C.13 muestra la estructura de control de seguridad para el
suministro de agua de la ciudad. Hay tres sistemas físicos que están siendo controlados: el sistema de pozos, el
suministro de agua y la sanidad pública. Cada componente de la estructura de control de estos procesos tiene
responsabilidades específicas relacionadas con la seguridad. Por ejemplo, el Ministerio de Medio Ambiente proporciona
supervisión y control de los sistemas de agua locales. Cada componente de la estructura de control recibe información
sobre el estado del proceso que está controlando. Una causa común es que el controlador reciba información incorrecta
y crea que el estado del proceso controlado es diferente del real. Por ejemplo, se recortaron los presupuestos y el
Ministerio del Interior redujo el número de inspecciones y de inspectores.
La figura C.14 muestra el análisis del papel del departamento de salud local en el evento foco, incluyendo las funciones
y responsabilidades, las acciones de control no seguras, el contexto en el que se proporcionaron estas acciones y los
defectos en el modelo de proceso (mental) que contribuyeron al comportamiento. La figura C.15 muestra los mismos
elementos para otro componente de la estructura de control, la gestión de las operaciones del sistema de suministro de
agua.
EN 62740:2015 - 58 -
En un análisis completo, se consideraría cada componente de la estructura de control con respecto a su contribución al
evento foco. En la mayoría de los eventos foco, se pueden encontrar las contribuciones de cada componente de la
estructura de control.
Otras características del análisis (no mostradas) incluyen el examen de los cambios dinámicos a lo largo del tiempo en
el sistema que contribuyeron al evento foco y el papel de una comunicación y coordinación deficientes.
Peligro del sistema: El público está expuesto a E. coli u otros contaminantes relacionados con la salud a través del agua potable.
Restricciones de seguridad del sistema: La estructura de control de seguridad debe evitar la exposición de la población al agua contaminada.
1) No debe comprometerse la calidad del agua.
2) Las medidas de salud pública deben reducir el riesgo de exposición si la calidad del agua se ve comprometida (por ejemplo, notificación y procedimientos a seguir)
- 59 -
Figura C.13 – Estructura de control para el suministro de agua en una pequeña ciudad de Canadá
EN 62740:2015
EN 62740:2015 - 60 -
Departamento médico de salud

Requisitos de seguridad y restricciones: Defectos del modelo mental:
• Proporcionar supervisión de la calidad del agua • Se pensaba que se estaban recibiendo informes
potable adversos de calidad del agua
• Hacer un seguimiento de los informes adversos de • No se era consciente de los informes de E. coli
calidad del agua potable relacionado con el agua tratada
• Emitir recomendaciones de hervir el agua y otros • Se pensaba que el Sr. K estaba transmitiendo la verdad
consejos si la salud pública está en situación de riesgo • No se era consciente del mal estado de la explotación
Contexto en el que se ha tomado la decisión : local del agua
• Los informes de calidad del agua más recientes tenían Coordinación
más de 2 años de antigüedad • Se supuso que el ministerio de medio ambiente
• Aparición de enfermedades en comunidades fuera de aseguraba que los problemas del informe de
la ciudad inspección se habían resuelto
• E. coli propagada con mayor frecuencia a través de la
carne
Acciones de control inadecuados :
• Consejos retrasados
• Los consejos se deberían haber difundido más
ampliamente
• inspector de salud pública no siguió el informe de
inspección de 1998
Figura C.14 – Ejemplo de análisis causal CAST para el departamento local de salud
Gestión de las operaciones de la CSP local

Requisitos de seguridad y restricciones: Defectos modelo mental:
• Monitorizar las operaciones para garantizar que se • Se creía que las fuentes del sistema de agua eran
lleva a cabo la toma de muestras y la generación de generalmente seguras
informes • Se pensaba que el agua no tratada era apta para el
• Mantener registros exactos consumo
• Actualizar el conocimiento como se requiera • No se entendían los riesgos para la salud que
Contexto en el que se ha tomado la decisión: representaba el agua infra-clorada
• Los ciudadanos se han quejado del sabor a cloro del • No se entendían los riesgos de contaminantes
agua potable bacterianos como E. coli
• Las actividades inadecuadas han sido una práctica • No se creía que las directrices tuvieran alta prioridad
establecida desde hace 20 años
• Faltaba formación y experiencia adecuadas
Acciones de control inadecuados :
• Inadecuada monitorización y supervisión de las
operaciones
• No se informó de los resultados adversos de los
ensayos cuando se ha preguntado
• No se han rectificado los problemas descubiertos
durante las inspecciones
• Respuesta inadecuada después de los primeros
síntomas en la comunidad
• Se han mantenido registros adecuados de la formación
o de las operaciones
Figura C.15 – Ejemplo de análisis causal CAST para la gestión de operaciones del servicio público local
- 61 - EN 62740:2015
C.13.2 Proceso
CAST tiene los siguientes pasos:
a) Se identifica el sistema(s) implicado en el evento foco.
b) Se identifican las limitaciones del sistema asociadas con el evento foco.
c) Se documenta la estructura de control en el lugar. Esta estructura incluye las funciones y responsabilidades de cada
componente en la estructura, así como los controles proporcionados o creados para ejecutar sus responsabilidades y
la realimentación pertinente (si la hay) proporcionadas para ayudarles.
d) Se determinan los próximos eventos que conducen al evento foco.
e) Se analiza el evento foco a nivel del sistema físico. Se identifica la contribución a los eventos de cada uno de los
siguientes: controles físicos y operativos, fallos físicos, interacciones disfuncionales, defectos de comunicación y
coordinación, y perturbaciones no manejadas. Se determina por qué fueron ineficaces los controles físicos en el
lugar.
f) Se sube por los niveles de la estructura de control, se determina, de la siguiente manera, cómo y por qué cada nivel
más alto sucesivo permitió o contribuyó al control inadecuado en el nivel actual.
1) Para cada restricción del sistema, o bien nunca se asignó a un componente de la estructura de control la
responsabilidad de hacerla cumplir o bien un componente(s) no ejerció un control adecuado para asegurar que
sus responsabilidades se cumplieron en los componentes de nivel inferior.
2) Identificar las decisiones o acciones de control no seguras, incluyendo acciones proporcionadas por software,
operadores, gestores, reguladores, etc.
3) Cualquier decisión humana o acciones de control defectuosos deben entenderse en términos de la información
disponible para quien debe tomar las decisiones, pero también de cualquier información que no esté disponible,
de los mecanismos que determinan el comportamiento (el contexto y las influencias sobre el proceso de toma
de decisiones), las estructuras de valor que subyacen a la decisión, y cualquier defecto en los modelos de
procesos (modelos mentales) de aquellos que toman las decisiones y por qué existen estos defectos.
g) Se examina la coordinación general y la comunicación (incluida la realimentación perdida) que hayan contribuido al
evento foco.
Aunque el proceso se describe en términos de pasos, el proceso no tiene por qué ser lineal ni tampoco es preciso que se
haya finalizado un paso antes de iniciar el siguiente.

Los puntos fuertes de CAST son los siguientes:
• mira hacia atrás en el tiempo para determinar cómo ha evolucionado el sistema hasta un estado de alto riesgo;
• identifica los factores sociales y de gestión, y no sólo las operaciones humanas o los fallos técnicos del sistema;
• no impone ninguna teoría social particular en el análisis, podría utilizarse cualquier modelo de comportamiento
social 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 los factores
causales significa que 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 entender completamente el evento foco que otros métodos con un
enfoque más limitado.
EN 62740:2015 - 62 -
Anexo D (Informativo)
Herramientas útiles para facilitar un análisis de causa raíz (RCA)
D.1 Generalidades
En el anexo D se describen las herramientas y técnicas que pueden apoyar la realización de un RCA.
D.2 Técnicas de minería de datos y de análisis tipológico

D.2.1 Información general
Las modernas técnicas de minería de datos permiten una búsqueda de propiedades y condiciones específicas. El análisis
tipológico selecciona datos que están estrechamente relacionados, y con ello identifica los datos que se desvían (valores
atípicos). Las técnicas modernas de análisis tipológico pueden detectar datos que están estrechamente relacionados en
una, dos o más dimensiones y con ello analizar los productos o procesos que están estrechamente relacionados e
identificar puntos de datos que se desvían (valores atípicos).
En el RCA, la extracción de datos y el análisis tipológico pueden dar pistas valiosas y ayudar a confirmar o rechazar
posibles causas raíz. En algunos casos, por ejemplo, en el sector aeroespacial o en el de los equipos médicos, es
necesario almacenar números de lote de los productos terminados y los números de lote de los componentes asociados y
de las materias primas. Esta información puede proporcionar una estructura útil para identificar correlaciones que
insinúen posibles relaciones causales.
D.2.2 Ejemplo 1
Una empresa observa un 12% de fallos de los artículos almacenados. El análisis muestra que una pieza de plástico está
rota. Se identifica el inicio del patrón de fallo del 12% en 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. No hay correlación tampoco con los
lotes de materias primas plásticas. Sin embargo, existe una correlación con los lotes de un resorte que carga la pieza de
plástico. El problema comenzó 3 días después de que se recibiera un nuevo lote de resortes. Se investigan los cambios
que se hicieron entre los dos lotes de muelles. La diferencia es un nuevo tratamiento superficial contra la corrosión. Se
estudia este proceso de tratamiento superficial y contiene una nota que dice que este tratamiento puede interferir con
ciertos materiales plásticos. Análisis posteriores muestran que la protección contra la corrosión acelera la propagación
de grietas en este plástico. El análisis de las hojas de datos del material plástico muestra una advertencia contra la
sobrecarga local que puede causar grietas. Por tanto, la conclusión es que se puede formular una hipótesis causal: que
una pieza de plástico está continuamente sobrecargada y sufre fractura por sobrecarga local y las fracturas se propagan
de manera acelerada por el nuevo tratamiento anti-corrosión de los resortes. Estas grietas se propagan después de
manera acelerada debido al nuevo tratamiento anti-corrosión de los muelles. Un análisis de fallos ha demostrado
previamente un patrón en la superficie de la fractura, que consiste en líneas de propagación de la grieta que se originan
en los puntos de contacto con el resorte y una superficie frágil de la fractura final. La hipótesis que explica la causa se
puede confirmar, con un nivel de dado confianza, mediante experimentos: se dispone de 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
mayoritariamente, se puede concluir que se confirma la hipótesis causal con el grado adecuado de confianza usando
métodos estándar de inferencia estadística.
- 63 - EN 62740:2015
D.2.3 Ejemplo 2
Se observa una serie de fallos de soldadura en la explotación. Se representan en tiempo de calendario las semanas de
fabricación de los productos fallados. Se observa que las fechas de fabricación de los productos con fallos de soldadura
están agrupadas en ciertas semanas. Se puede formular una hipótesis causal sobre la base de la observación inicial, que
se confirma después con un nivel de confianza dado usando inferencia estadística estándar en los datos de control de
procesos de fabricación, que indican que el proceso de soldadura en estas semanas no se realizó probablemente con el
control apropiado. La conclusión es, con un alto nivel de confianza, que una causa raíz de los fallos de soldadura es un
control insuficiente del proceso de soldadura.
D.2.4 Ejemplo 3
Se prueba un componente en una placa de prueba retorciendo la placa. El número de vueltas hasta el fallo se traza sobre
diagrama de Weibull (véase la Norma IEC 61649 [22]). El análisis identifica una población "débil" y una "fuerte"(véase
la Norma IEC 61163-1 [23]). Se analiza uno de los componentes de la población débil y uno de la fuerte seccionando
las bolas de soldadura del microencapsulado BGA Matriz de puntos de soldadura. 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 de la población
fuerte no tienen o tienen unos pocos huecos pequeños. Se concluye que se formula una hipótesis de causa-raíz, que los
huecos en las bolas de soldadura del micro BGA es una de las causas raíz de los eventos de incidentes. La hipótesis de
causa-raíz se confirma mediante la recopilación de datos del uso operacional y observando a través del análisis de los
datos que la reducción de huecos se correlaciona con el uso exitoso del componente.
EN 62740:2015 - 64 -
Anexo E (Informativo)
Análisis de rendimiento humano
E.1 Generalidades
Las personas de cualquier nivel de una organización toman decisiones o realizan u omiten acciones que pueden
desempeñar un papel en los eventos que conducen a un evento foco. La actuación humana 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 que se tomaron, pero resultan en tener resultados no previstos.
Las personas pueden cometer errores, estar mal orientadas o mal informadas, estar motivadas de manera inapropiada,
puede estar intentando hacerlo correctamente o puede violar las reglas a propósito. El análisis de los aspectos humanos
de la causalidad es complejo y generalmente requiere conocimientos especializados si es necesario ir más allá de la
identificación de lo que ocurrió buscando el por qué y de ahí formular recomendaciones.
E.2 Análisis del fallo humano

El análisis de fallos humanos comienza por identificar el modo de error. Esta es la manifestación externa del error, es
decir, lo que se observa que se ha hecho (o dejado de hacer). Ejemplos de modos de error son los siguientes:
• omitido;
• demasiado temprano;
• demasiado tarde;
• demasiado;
• demasiado poco;
• dirección equivocada;
• objeto equivocado;
• acción equivocada;
• secuencia equivocada.
Hay, pues, una serie de taxonomías diferentes para categorizar y analizar las causas de estos errores. Se diferencian en
el número y tipos de clasificaciones que consideran y en los modelos de conducta humana en los que se basan las
taxonomías y en donde se hace más hincapié. Generalmente se consideran los siguientes:
a) El modo de error interno y el mecanismo de error. Esta es la razón que está detrás del error en términos psicológicos
significativos, por ejemplo, para un modo de error "hizo un giro equivocado en el coche", el modo de error interno y
el mecanismo podría ser la decisión incorrecta debido a la costumbre.
b) Los problemas inherentes a la tarea, por ejemplo, objetivos en conflicto, problemas de planificación, limitaciones,
demandas cognitivas etc.
c) Los factores de modelización del rendimiento (FMR). Son las condiciones internas de un individuo o de su entorno
técnico u organizativo que afectan a cómo se lleva a cabo una tarea determinada (véase la Norma IEC 62508 [24]).
- 65 - EN 62740:2015
Algunos modelos también incluyen un análisis de los flujos de información y realimentación sin las cuales es poco
probable que se hagan juicios correctos. La importancia de estos métodos es que primero identifican el mecanismo de
error psicológico antes de identificar por qué se cometió. Por ejemplo, si el mecanismo de error no se debe a una falta
de conocimiento o competencia, entonces es poco probable que una formación adicional sea útil. Si se toma una
decisión para violar un procedimiento, deberían investigarse a continuación las razones por las que ocurrió en lugar de
suponer que la solución es una mayor supervisión.
Dos ejemplos de métodos que pueden utilizarse para analizar las causas del fallo humano y que ilustran estos principios
son:
• técnica para el análisis retrospectivo y predictivo de errores cognitivos (TRACEr);
• análisis de los factores humanos y esquema de clasificación (HFACS).
E.3 Técnica para el análisis retrospectivo y predictivo de errores cognitivos (TRACEr)

E.3.1 Visión general
El TRACEr [25] fue desarrollado para usarse en el control del tráfico aéreo. TRACEr, cuenta con 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 se produjo el error, es decir, la naturaleza de la tarea, el entorno y los FMRs;
• la producción del error, es decir, los modos externos de error (MEE), los modos internos de error (MEI), los
mecanismos de error psicológicos (MEP) y la información en que los individuos basan sus acciones;
• la detección y corrección del error.
Los módulos de producción de error se basan en los procesos cognitivos implicados cuando una persona percibe algo
que hay que hacer y toma medidas, por ejemplo, la percepción, la memoria, la toma de decisiones y la acción (véase la
figura E.2).
EN 62740:2015 - 66 -
Figura E.1 – Ejemplo de modelo TRACEr [25]
- 67 - EN 62740:2015
Figura E.2 – Generación de modos de error internos
E.3.2 Proceso
Un modelo TRACEr se crea utilizando los siguientes pasos:
a) Se analiza la tarea que se lleva a cabo e identificar los factores ambientales o situacionales que puedan afectar al
desempeño humano (FMR), que incluyen complejidad de la tarea, conocimiento y experiencia de la persona, el
entorno ambiental, etc.
b) Se identifican los MEE, que se clasifican en función de la selección y la calidad, la oportunidad y secuencia y la
comunicación (véase la figura E.1).
c) Se identifican los MEI, que describen qué función cognitiva falló y de qué manera, cuya taxonomía se muestra en la
figura E.2.
d) Se identifican las cuestiones de información asociadas con el MEI, es decir, qué información se han percibido mal,
olvidado, juzgado mal o comunicado mal.
e) Se identifican las MEP, que son las predisposiciones cognitivas que se sabe que afectan al desempeño dentro de
cada dominio cognitivo (véase la tabla E.2).
f) Se revisa el proceso de detección de errores, que es cómo fue consciente la persona del error, por qué medio se les
informó del error y qué factores externos mejoraron o degradaron la detección.
EN 62740:2015 - 68 -
g) Se considera la corrección, es decir, lo que se hizo para corregir el error, lo que hicieron otros factores internos o
externos para mejorar o degradar la corrección de errores.
Tabla E.1 – Modos de error externos
Selección y calidad Temporización y secuencia Comunicación

Olvido Acción demasiado larga Información transmitida confusa
Acción demasiado pequeña Acción demasiado corta Información recibida confusa
Acción demasiado grande Acción demasiado pronto Información no buscada/obtenida
Acción en la dirección equivocada Acción demasiado tarde Información no transmitida
Acción correcta sobre el objeto equivocado Acción repetida Información no registrada
Acción incorrecta en el objeto correcto Mala ordenación Información transmitida incompleta
Acción incorrecta en el objeto equivocado Información recibida incompleta
Acto extraño Información registrada incompleta
Información registrada incorrecta
Tabla E.2 – Mecanismos psicológicos de error
Percepción Memoria Toma de decisiones Acción

Expectativa sesgada Interferencias de similitud Conocimientos incorrectos Variabilidad manual
Confusión espacial Sobrecarga de la capacidad de Falta de conocimiento Confusión espacial
Confusión de la memoria Fallo al considerar los efectos Intromisión en los
percepción Transferencia negativa colaterales hábitos
Fallo de Mal aprendizaje Fallo de integración Confusión en la
discriminación Aprendizaje insuficiente Malentendido percepción
perceptiva Mala articulación
Sesgo de frecuencia ( fallo de Obsesión cognitiva
Percepción periférica memoria debido a que el Intrusión ambiental
Suposición falsa
restringida conocimiento no se utiliza con
Fallo de priorización Otro patinazo
Sobrecarga de suficiente frecuencia )
Negación o tolerancia del riesgo Preocupación y
estímulos Bloqueo de memoria distracción
Fallo de Vigilancia Fallo en el reconocimiento de
Distracción/Preocupación
riesgos
Distracción
Congelamiento de la decisión
E.4 Análisis del factor humano y esquema de clasificación (HFACS)

E.4.1 Visión general
El HFACS [26] fue desarrollado por científicos de la conducta de la Marina de los Estados Unidos y analiza las causas
de los errores humanos basándose en el modelo de Reason (véase el capítulo B.3). Hay cuatro niveles de consideración
basados en el modelo de rebanadas de queso suizo de Reason:
• influencias organizativas;
• supervisión;
- 69 - EN 62740:2015
• condiciones previas para actos inseguros;
• actos inseguros.
Algunas aplicaciones añaden un quinto nivel por encima de las influencias de la organización en relación 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 cada categoría.
Diferentes aplicaciones utilizan las mismas categorías (que se muestran en las cajas más abajo), pero pueden tener
diferentes ejemplos dependiendo de la industria y puede proporcionar algunos ejemplos o una lista de verificación más
detallada. Ejemplos de los cuatro niveles se muestran en las figuras E.3 a E.6.
La consideración de la causa se inicia con el Nivel 1, de modo que los precursores para el acto en cuestión tengan en
cuenta el tipo de error implicado, luego se continúa a través de los niveles superiores que buscan debilidades que
contribuyeron al evento foco.
Figura E.3 – Nivel 1: actos no seguros
EN 62740:2015 - 70 -
Figura E.4 – Nivel 2: Condiciones previas
Figura E.5 – Nivel 3: Cuestiones de supervisión
- 71 - EN 62740:2015
Figura E.6 – Nivel 4: Cuestiones organizativas
EN 62740:2015 - 72 -
Bibliografía
[1] ISO Guide 73: 2009, Risk management. Vocabulary.
[2] IEC 60300-1, Dependability management. Part 1: Guidance for management and application.
NOTA Armonizada como Norma EN 60300-1.
[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, SCIEDOE-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).
NOTA Armonizada como Norma EN 61025.
[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.
- 73 - EN 62740:2015
[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.
NOTA Armonizada como Norma EN 61649.
[23] IEC 61163-1, Reliability stress screening. Part 1: Repairable assemblies manufactured in lots.
NOTA Armonizada como Norma EN 61163-1.
[24] IEC 62508:2010, Guidance on human aspects of dependability.
NOTA Armonizada como Norma EN 62508:2010 (sin ninguna modificación).
[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.
NOTA Armonizada como Norma EN 31010:2010 (sin ninguna modificación).
[28] ISO 31000: 2009, Risk management. Principles and guidelines.
EN 62740:2015 - 74 -
Anexo ZA (Normativo)
Otras normas internacionales citadas en esta norma

con las referencias de las normas europeas correspondientes
Los documentos indicados a continuación, en su totalidad o en parte, son normas para consulta indispensables para la
aplicación de este documento. Para las referencias con fecha, sólo se aplica la edición citada. Para las referencias sin
fecha se aplica la última edición (incluyendo cualquier modificación de ésta).
NOTA 1 Cuando una norma internacional haya sido modificada por modificaciones comunes CENELEC, indicado por (mod), se aplica la EN/HD
correspondiente.
NOTA 2 La información actualizada de las últimas versiones de las normas europeas referenciadas en este anexo se encuentra en: www.cenelec.eu.
Norma
Fecha Título EN/HD Fecha
Internacional
IEC 60050 serie – Vocabulario Electrotécnico Internacional (VEI) – –
Génova, 6 [email protected] Tel.: 902 102 201
28004 MADRID-España www.aenor.es Fax: 913 104 032

Une en 62740 Español

Cargado por

Copyright:

Formatos disponibles

Une en 62740 Español

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Une en 62740 Español

Cargado por

Copyright:

Formatos disponibles

norma UNE-EN 62740

TÍTULO Análisis de causa raíz (RCA)

Root cause analysis (RCA).

Analyse de cause initiale (RCA).

 AENOR 2015 Génova, 6 [email protected] Tel.: 902 102 201

Análisis de causa raíz (RCA)

Root cause analysis (RCA). Analyse de cause initiale (RCA). Ursachenanalyse.

 2015 CENELEC. Derechos de reproducción reservados a los Miembros de CENELEC.

Se fijaron las siguientes fechas:

 Fecha límite en la que la norma europea debe adoptarse a nivel

 Fecha límite en la que deben retirarse las normas nacionales

IEC 60300-1 NOTA Armonizada como Norma EN 60300-1.

1 Objeto y campo de aplicación .............................................................................................. 11

2 Normas para consulta .......................................................................................................... 11

3 Términos, definiciones y abreviaturas ................................................................................ 11

4 RCA – Visión general ........................................................................................................... 14

5 El proceso del RCA............................................................................................................... 15

6 Selección de las técnicas para el análisis de las causas ...................................................... 22

Anexo A (Informativo) Resumen y criterios de técnicas RCA comúnmente usadas .................. 25

Anexo B (Informativo) Modelos RCA ............................................................................................ 30

Anexo C (Informativo) Descripción detallada de las técnicas de RCA........................................ 34

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

Anexo E (Informativo) Análisis de rendimiento humano ............................................................. 64

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

Figura 1 – Proceso del RCA.................................................................................................................. 16

Tabla 1 – Pasos del RCA ....................................................................................................................... 15

COMISIÓN ELECTROTÉCNICA INTERNACIONAL

Análisis de causa raíz (RCA)

El texto de esta norma se basa en los documentos siguientes:

FDIS Informe de voto

– reemplazada por una edición revisada; o

Análisis de causa raíz (RCA)

1 Objeto y campo de aplicación

2 Normas para consulta

IEC 60050 (todas las partes), Vocabulario Electrotécnico Internacional.

3 Términos, definiciones y abreviaturas

3.1 Términos y definiciones

3.1.2 factor causal:

3.1.3 factor contributivo:

NOTA 2 Un evento puede consistir en algo que no ha ocurrido.

NOTA 3 Un evento se puede referir a veces como un "incidente" o "accidente".

[FUENTE: Guía ISO 73:2009, 3.5.1.3, modificado – supresión de la nota 4[1]1)]

3.1.5 fallo <de un elemento>:

NOTA 4 Esto es un fallo de un elemento y no de su comportamiento que sería más general.

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

3.1.6 mecanismo del fallo:

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

3.1.7 evento foco:

3.1.8 factor causal inmediato:

NOTA 1 Puede haber más de un factor causal inmediato.

3.1.9 factor causal necesario <de un evento o estado>:

3.1.10 factor humano:

1) Las cifras entre corchetes se refieren a la Bibliografía.

NOTA 3 El elemento se compone a menudo de elementos que se pueden considerar individualmente.

3.1.12 causa raíz:

NOTA 1 Un evento foco normalmente tiene más de una causa raíz.

3.1.13 análisis de causa raíz, RCA:

NOTA 2 La abreviatura RCA es la traducción del inglés "root cause analysis".

3.1.14 parte interesada: