Analisis causa raiz y sus herramientas

CONFIABILIDAD
OPERACIONAL DE EQUIPOS:
METODOLOGÍAS Y
HERRAMIENTAS
FERNANDO ESPINOSA FUENTES

ii
ÍNDICE
CONFIABILIDAD OPERACIONAL 1
ANÁLISIS CAUSA RAÍZ: ÁRBOL LÓGICO 5
ANÁLISIS CAUSA RAÍZ: ÁRBOL DE EVENTOS 12
EL MÉTODO KEPNER- TREGOE O MATRIZ DEL PERFIL COMPETITIVO 22
5 PORQUÉS PARA RESOLVER PROBLEMAS 26
DIAGRAMA DE ISHIKAWA PARA LA CAPTURA DE LAS SOLUCIONES 29
HAZARD AND OPERABILITY (HAZOP) 33
DESARROLLANDO UN ANÁLISIS DEL MODO DE FALLA Y EFECTO (FMECA) 44
EL ENFOQUE META, PREGUNTA, METRICA 53
ANÁLISIS DEL COSTO DEL CICLO DE VIDA 60

1
CONFIABILIDAD OPERACIONAL
La Ingeniería de la Confiabilidad se destaca como el marco teórico en el cual conviven las
metodologías y técnicas necesarias para la optimización del uso de los activos fijos.
La confiabilidad de un sistema o un equipo, es la probabilidad que dicha entidad pueda operar
durante un determinado periodo de tiempo sin pérdida de su función. El fin último del Análisis de
confiabilidad de los activos físicos es cambiar las actividades reactiva y correctivas, no programadas
y altamente costosas, por acciones preventivas planeadas que dependan de análisis objetivos,
situación actual e historial de equipos y permitan un adecuado control de costos.
La Confiabilidad Operacional se define como una serie de procesos de mejora continua, que
incorporan en forma sistemática, avanzadas herramientas de diagnóstico, metodologías de análisis
y nuevas tecnologías, para optimizar la gestión, planeación, ejecución y control de la producción
industrial. La Confiabilidad Operacional lleva implícita la capacidad de una instalación (procesos,
tecnología, gente), para cumplir su función o el propósito que se espera de ella, dentro de sus
límites de diseño y bajo un específico contexto operacional.
Es importante, puntualizar que en un sistema de Confiabilidad Operacional es necesario el análisis
de sus cuatro parámetros operativos: confiabilidad humana, confiabilidad de los procesos,
mantenibilidad y confianza de los equipos; sobre los cuales se debe actuar si se quiere un
mejoramiento continuo y de largo plazo. Estos cuatro elementos se muestran en la fig. 1:
Fig. 1: Factores de la Confiabilidad Operacional

2
Un proceso de desarrollo de la Confiabilidad Operacional implica cambios en la cultura de la
empresa, creando un organismo diferente con un amplio sentido de la productividad y con una
visión clara de los fines del negocio. La variación en conjunto o individual que pueda sufrir cada
uno de estos custro aspectos mostrados, afecta el desempeño general del sistema. Cualquier
hecho aislado de mejora puede traer beneficios, pero no al considerarse los demás factores, sus
ventajas son limitadas o diluidas en la organización y pasan a ser el resultado de un proyecto y no
de un cambio organizacional.
La confiabilidad en mantenimiento se estudia como la probabilidad que un equipo sobreviva sin
fallas un determinado período de tiempo bajo determinadas condiciones de operación.
Sin embargo esta definición no demuestra en realidad todos los alcances que conlleva. La
confiabilidad es más que una probabilidad; es una nueva forma de ver el mundo, en realidad es
una cultura que debe implementarse a todos los niveles de la industria desde la alta dirección
hasta el empleado de más bajo nivel. La confiabilidad como cultura busca que todas las actividades
de producción y en general todas las tareas se efectúen bien desde la primera vez y por siempre;
no se acepta que se hagan las cosas precariamente o a medias.
Esto implica un cambio en la mentalidad de todo el personal de la planta, nuevas formas de pensar
y actuar, nuevos paradigmas; por esto es de radical importancia que la dirección de la empresa
tome conciencia de la nueva situación y de su dificultad de conseguirla. Inculcar un cambio en la
forma de pensar no es sencillo, cuesta gran cantidad de trabajo y tiempo; la dirección debe enfocar
sus esfuerzos en la formación de sus empleados mediante políticas que permitan la participación
del personal en planes de mejoramiento continuo de procesos, círculos de participación y demás
elementos que persigan alcanzar los objetivos propuestos.
Todo lo anterior requiere de soporte gerencial de alto nivel y convencimiento de que no es una
tarea fácil ni a corto plazo, donde se debe hacer una gran inversión de capital y tiempo, en
capacitación y reconocimiento y donde lo logros superan con creces las predicciones.
Aplicación de la Confiabilidad Operacional
Las estrategias de Confiabilidad Operacional se usan ampliamente en los casos relacionados con:
Elaboración de los planes y programas de mantenimiento e inspección de equipos e
instalaciones industriales.
Solución de problemas recurrentes en los activos fijos que afecten los costos y la
efectividad de las operaciones.
Determinación de las tareas que permitan minimizar riesgos en los procesos, equipos e
instalaciones y medio ambiente.
Establecer procedimientos operacionales y prácticas de trabajo seguro.
Determinar el alcance y frecuencia óptima de paradas de planta.
La Confiabilidad Operacional impulsa el establecimiento de tecnologías que faciliten la
optimización industrial, entre las cuales se pueden destacar:

3
Modelaje de sistemas, en la confiabilidad operacional se gasta a nivel de elementos
(equipos, procesos y clima organizacional) y se recibe beneficios a nivel de planta.
Confiabilidad Organizacional, llamada también en forma sesgada error humano siendo este
el ancla más fuerte.
Gestión del Conocimiento, valor agregado de nuevas prácticas y conocimientos, a través de
mediciones sistémicas, bancos de datos, correlaciones, simulaciones, minería de datos y
estadísticas.
Manejo de la incertidumbre, a través del análisis probabilístico de incertidumbre y riesgo
asociado.
Optimización Integral de la Productividad, a través de pruebas piloto en seguridad y
confiabilidad desde el diseño.
Herramientas de Confiabilidad Operacional
La confiabilidad como metodología de análisis debe soportarse en una serie de herramientas que
permitan evaluar el comportamiento del activo de una forma sistemática a fin de poder
determinar el nivel de operatividad, la cuantía del riesgo y las demás acciones de mitigación que se
requieren, para asegurar su integridad y continuidad operacional.
Son múltiples las herramientas de que se sirve la confiabilidad con el fin de formular planes
estratégicos para lograr la excelencia en las actividades e mantenimiento. Las seis que se muestran
en la Fig. 2, a continuación son las más utilizadas:
Fig. 2: Herramientas para la Confiabilidad Operacional

4
Análisis de Criticidad (CA). Es una técnica que permite jerarquizar sistemas, equipos e
instalaciones, en función de su impacto global, con el fin de facilitar la toma de decisiones.
Análisis de Modos y efectos de Falla y Criticidad (FMECA). Es una metodología que permite
determinar los modos de falla de los componentes de un sistema, el impacto y la frecuencia con
que se presentan.
Análisis Causa Raíz (RCFA). Es una técnica sistemática que se aplica con el objetivo de determinar
las causas que originan las fallas, sus impactos y frecuencias de aparición, para poder mitigarlas o
eliminarlas.
Inspección Basada en Riesgos (RBI). Es una técnica que permite definir la probabilidad de falla de
un equipo o sistema, y las consecuencias que las fallas pueden generar sobre la gente, el ambiente
y los procesos.
Análisis Costo Riesgo Beneficio (BRCA). Es una metodología que permite establecer una
combinación óptima entre los costos de hacer una actividad y lo logros o beneficios que la
actividad genera, considerando el riesgo que involucra la realización o no de tal actividad.
Costo del Ciclo de Vida (LCC). El análisis LCC es una metodología que permite elegir entre opciones
de inversión o acciones de incremento de la confiabilidad con base en su efecto en el costo total
del ciclo de vida de un activo nuevo o en servicio.

5
ANÁLISIS CAUSA RAÍZ: ÁRBOL LÓGICO
INTRODUCCIÓN
La mayoría de los analistas de fallas han escuchado el término: Análisis de Causa Raíz (RCA por sus
siglas en inglés) y seguramente cada quién tiene una interpretación diferente de su significado.
Esta es la razón por la cual en muchos casos se tiene una forma poco efectiva de usarlo, y hay
comunicación deficiente o nula entre quienes lo usan. Si se está usando diversas formas de RCA,
entonces, al comparar los resultados no se estará comparando "manzanas con manzanas".
Desde la evolución del Mantenimiento Productivo Total (TPM) ha habido un movimiento
consistente hacia la exploración de la calidad del proceso en vez de la calidad del producto. Antes
de la llegada del TPM, las organizaciones de calidad se contentaban con medir la calidad del
producto terminado como salía de la línea. Aún cuando admirable esa medida era demasiado
tardía si se hallaban defectos de calidad. El producto, y probablemente todo el lote tenía que ser
reprocesado a un alto costo para la organización.
Entonces se introdujeron los principios de W. Edwards Deming e impulsaron el concepto de
"calidad del proceso". En pocas palabras, esto significa que se debe medir variables clave en el
proceso para detectar cualquier variación inaceptable. De esta manera, se corrige la variación en el
proceso y se evita la manufactura de productos fuera de especificación. Esta era se está
continuando actualmente con la introducción del índice de calidad Seis Sigma (99.999996%
calidad).
Como se discutió anteriormente, RCA tiene diferentes significados para diferentes personas.
Algunos aplican esfuerzos indisciplinados como el método de "prueba y error" como su perspectiva
de RCA. Esto significa que se percatan de un problema, y se va directo a lo que es la causa más
obvia, ¡PARA LOS ANALISTAS!.
Usando la perspectiva del "producto terminado" no se valida ninguna de las suposiciones,
simplemente se adopta una y se gasta dinero en un arreglo esperando que funcione. La
experiencia ha demostrado que esta forma de hacerlo es cara e inefectiva.
Ahora, aplicando un sistema disciplinado tipo TPM de RCA, un Árbol Lógico permite representar
gráficamente las relaciones de causa y efecto que conducen a descubrir el evento indeseable y cuál
fue la causa raíz del problema.
En este procedimiento, se debe identificar claramente el evento indeseable y todos sus detalles
asociados mediante hechos que los respalden. Los hechos deben respaldarse con observación
directa, documentación y algunos conceptos científicos. ¡No pueden ser rumores ni suposiciones!
Por ejemplo, en el caso que se presenta enseguida, la mayoría de las personas insistirían en
comenzar con la falla del rodamiento. Sin embargo, cuando el evento se presentó, ¿por qué llamó
la atención? No llamó la atención el rodamiento fallando, sino el hecho de que la bomba dejó de
proveer el fluido. Por lo tanto el evento final que llamó la atención fue la falla de la bomba. Una
razón o modo de que la bomba fallase fue debido a la falla del rodamiento. Esto resulta evidente
cuando se ve el rodamiento dañado (evidencia física). La parte alta del Árbol Lógico se verá así
(Fig. 3):

6
Fig. 3: Evento no deseado
Continuando con la búsqueda en retrospectiva de la causa y relaciones de los efectos, se pregunta:
¿Cómo puede fallar un rodamiento? Las hipótesis pueden ser: erosión, corrosión, fatiga,
lubricación o sobrecarga. ¿Cómo se puede verificar cuál de ellas es la verdadera causa?
Simplemente se puede solicitar que un laboratorio metalúrgico y un experto hagan un análisis del
rodamiento. Para efectos de este ejemplo, se supone que el reporte indica que sólo hubo signos de
fatiga, ahora el "Árbol Lógico" avanzará un nivel, y se verá como en la figura 4:
Fig. 4: Causas de la falla de un rodamiento
Se puede ver que a medida que se desarrollan nuevas series de hipótesis, se irá probando lo que se
dice a cada nivel del proceso. A medida que avanza este proceso reiterativo, se van validando las
conclusiones a cada paso del camino. De esta forma, cuando se llega a conclusiones en cada etapa,
esas conclusiones serán las correctas, porque no se están haciendo suposiciones, sino se están

7
basando en "hechos". Esto también implica que se comprometen a efectuar gastos para poder
superar las causas que se identifican, que se invertirá dinero en evitar que el problema se repita.
En un esfuerzo por mover nuestras culturas hacia la precisión, se deben usar los conceptos de TPM
en los procesos administrativos también. La perspectiva del TPM es aplicable a: Maquinaria,
Procesos y Situaciones Humanas.
Así que para algunos, RCA es pedir que un experto local les proporcione una solución al problema,
mientras para otros, representa el reunirse y discutir para llegar a una conclusión; para otros más,
RCA representa usar un proceso disciplinado de pensamiento hasta llegar a la verdadera causa
original del problema.
1) Cuando el "experto" proporciona una solución, se confía, se hace un gasto para aplicar la
solución que propuso, y se ve si funciona. A veces sí funciona, otras no. Esto equivale a la
inspección de calidad a la salida de la planta. ¡Es demasiado tarde si hay un error!
2) Cuando se forman grupos y participan en tormentas de ideas, se estará llegando a
conclusiones como resultado del consenso de los participantes. Se está basando en
opiniones. Quizás usaron un proceso formal como el diagrama de espina de pescado, pero
no hay hechos claros que respalden esas opiniones. De nuevo se está verificando la calidad
del producto al final del proceso, y no durante el mismo.
3) Cuando los grupos de trabajo usan un proceso disciplinado que requiere que las hipótesis
sean desarrolladas para ver exactamente por qué ocurrieron las causas, y luego requiere
también una verificación para asegurar si es o no cierto, entonces se está usando Calidad en
el Proceso, en vez de basarse en suposiciones y estar expuestos a la ignorancia.
Para demostrar estos puntos, vea el siguiente diagrama abreviado (Fig. 5).
Arriba se describe un proceso disciplinado de pensamiento lógico en la eliminación de variables no
relacionadas al RCA. Regresando a los anteriores escenarios de RCA. Si una bomba crítica fallara,
dado el caso, se trataría que los mejores de nuestros técnicos la fueran a ver. Quizás concluirían
luego de una gran discusión, que lo que se necesita es un rodamiento de trabajo más pesado....
Dadas las condiciones que se han analizado en el diagrama, ¿se resolvería el problema en forma
permanente? Naturalmente que no ¡!.
O qué tal si todos los técnicos de mantenimiento se reúnen y deciden que lo que está mal es el tipo
de lubricante que se está usando...pues tampoco con esa acción se resolvería el problema en
forma definitiva y permanente. Este último es un concepto enraizado y con muy poco argumento,
muchas personas del “que hacer del mantenimiento” emiten esta crítica sin ninguna base sólida o
respaldo documentado.
En cambio si se usa el proceso disciplinado del diagrama, se hará examinar el rodamiento por un
metalurgista o un experto, quien reportará (de manera científica) que hay evidencia de que existe
fatiga en el material. Se preguntará entonces: ¿qué puede estar causando esa fatiga en el
rodamiento? Se establece hipótesis: puede ser por vibración excesiva.

8
Fig. 5: Causas de una alta vibración
Se verifican los registros y se confirma que había demasiada vibración. ¿Qué puede estar causando
la vibración? Hipótesis: Puede ser por desbalanceo, resonancia o desalineamiento. Se le pide al
mecánico que la alineó la última vez que describa y muestre el procedimiento de alineación usado.
Al preguntarle, se enteran que él no ha sido entrenado al respecto, sus herramientas no están en
buen estado, y además no existe un procedimiento a seguir. Ahora se está en conocimiento de la
REAL causa raíz, así que se pueden desarrollar las soluciones que, una vez implementadas,
¡¡¡TRABAJARÁN!!!

9
Usando este proceso disciplinado se genera un producto (en este caso un servicio de
mantenimiento), de mucha calidad. Se sabe que la solución trabajará porque se obtuvo por el
proceso de calidad.
Mientras los estilos indisciplinados de RCA son atractivos para las organizaciones por la rapidez de
sus resultados, no siempre esos resultados son de calidad. El verdadero RCA requiere que se tome
el tiempo necesario para probar lo que se dice en vez de hacer el gasto o el esfuerzo y arriesgar a
estar equivocados.
Ahora cabe la pregunta ¿cuál es el papel que desempeña el encargado del análisis? La función del
ingeniero será simplemente la de determinar científicamente CÓMO ocurrió el evento. Esto
significa que una serie de causas-efectos se sucedieron hasta llegar a un evento no deseable. Su
papel es el de probar que cada hipótesis, sucedió o no sucedió.
Los ingenieros proporcionan las piezas "¿CÓMO?" del rompecabezas y es a los “detectives del
mantenimiento” a quienes les corresponde determinar "¿POR QUÉ?" se causó el problema.
Usando tecnología: por ejemplo monitoreo de vibración, imágenes térmicas infrarrojas, análisis de
esfuerzos, análisis de aceite, etc. para probar o eliminar las hipótesis, pero toca a los analistas
determinar por qué la persona o personas tomaron decisiones o efectuaron acciones que
resultaron en un problema o falla. Vea el diagrama de la Fig. 6.
El resultado indeseable es la falla de la bomba de cumplir con su función designada. En el intento
para construir un "caso sólido", se deberá asociar las inequívocas causas-efecto que desembocaron
en la falla. Esto incluye poner en juego los recursos científicos, propios o contratados, para probar
la hipótesis. Explorando en este caso... El resultado indeseable fue que la bomba dejó de efectuar
su función asignada. Para lograr un "caso sólido" se deberá entender las relaciones causa-efecto
que dieron como resultado tal evento. Esto implicará el uso de dispositivos y recursos científicos
para probar o eliminar las hipótesis. En el caso que se ilustra se puede ver "¿CÓMO?" la bomba
pudo fallar y se usa la ciencia para probar el caso.
Hipótesis Técnicas de Verificación
Erosión, Corrosión, Fatiga y Sobrecarga Análisis Metalúrgico
Alta Vibración Instrumentos y Vigilancia de la Vibración
Desalineamiento Tecnología de Alineación Láser
Estas relaciones aclaran el "¿CÓMO?", y el "¿POR QUÉ?" En este caso alguien dejó la bomba
desalineada y tal acción o decisión causó una serie de causas y efectos para que finalmente la
bomba fallase prematuramente. Los "ingenieros forenses" ya determinaron cómo sucedió, pero
¿Por qué alguien habría de dejar mal alineada la bomba? Es aquí donde se debe entender los
motivos por los que la gente actuó erróneamente. Como analistas, si se va a profundidad en el
proceso de pensamiento, se llegará a saber ¿Por qué la persona o personas tomaron tal decisión o
acción? (Raíz Latente), se descubrirá exactamente la CAUSA RAÍZ y el por qué de la falla física. Se
podría ver que la gente con frecuencia deja el equipo desalineado porque:

10
• Nunca han sido entrenados en prácticas apropiadas de alineamiento
• No existe un procedimiento que defina el alineamiento y sus especificaciones como una
práctica requerida
• El sistema que se está utilizando está desgastado o descalibrado en algunos casos.
Fig. 6: El cómo y el por qué de la falla del activo
Si no se explora el "¿Por qué?, es posible que el ¿Cómo? se vuelva a presentar una y otra vez”. En
el caso anterior, ¿creen ustedes que el sólo cambiar el rodamiento eliminará el problema en forma
permanente? Aún si se identifica una vibración excesiva y se toman medidas para identificarla más

11
pronto la próxima vez antes que la bomba falle, ¿será la forma de eliminar el problema? Si se
castiga al mecánico por no haber alineado correctamente, ¿se evitará la falla recurrente?
Como se puede ver, ninguna de esas soluciones que con frecuencia son implementadas, evitaría la
recurrencia de la falla en la bomba. Sólo con una acción efectiva sobre el ¿Por qué? Se podrá evitar
que ocurra la falla nuevamente.
Si se reflexiona en los esfuerzos de RCA (Análisis de Causa Raíz), ¿Dónde califican?, ¿Se están
deteniendo en el ¿Cómo? (al nivel del forense). O están llegando al ¿Por qué? (nivel del detective).

12
ANÁLISIS CAUSA RAÍZ: ÁRBOL DE EVENTOS
El Análisis Causa Raíz (RCA) es un proceso diseñado para su uso en la investigación y la
categorización de las causas de los acontecimientos relacionados con la seguridad, la salud, el
medio ambiente, calidad, fiabilidad y que repercute en la producción. El término "evento" se utiliza
para identificar de forma genérica los sucesos que producen o tienen el potencial para producir
este tipo de consecuencias.
En pocas palabras, la RCA es una herramienta diseñada para ayudar a identificar no sólo qué y
cómo se produjo un evento, sino también por qué sucedió. Sólo cuando los investigadores son
capaces de determinar por qué un suceso o la falla se produjeron van a ser capaces de especificar
las medidas correctivas viables que eviten futuros eventos del tipo observado.
Entender por qué se produjo un evento es la clave para desarrollar recomendaciones eficaces.
Imaginar un suceso durante el cual se encargó a un operador cerrar la válvula A, en cambio, el
operador cerró la válvula B. La investigación típica probablemente llegaría a la conclusión que un
error del operador fue la causa. Esta es una descripción exacta de lo que ocurrió y cómo ocurrió.
Sin embargo, si los analistas se detienen aquí, no han investigado lo suficiente como para entender
las razones para el error.
Por lo tanto, no saben qué hacer para evitar que ocurra de nuevo. Para el caso en que el operador
cerró la válvula equivocada, es probable que se redacten las recomendaciones para volver a
entrenar al operador en el procedimiento, recordar además a todos los operadores que deben
estar alerta cuando procedan con la manipulación de las válvulas o destacar a todo el personal que
la atención cuidadosa al trabajo se debe mantener en todo momento. Estas recomendaciones
ayudan poco más para evitar que se repitan en el futuro.
En general, los errores no ocurren por casualidad, pero se puede remontar a algunas de las causas
bien definidas. En el caso de la válvula del error, se podría preguntar: "¿Fue el procedimiento
confuso? ¿Estaban las válvulas claramente identificadas? ¿Estaba el operador familiarizado con
esta tarea en particular? "
Las respuestas a estas y otras preguntas le ayudarán a determinar por qué ocurrió el error (falla) y
lo que la organización puede hacer para prevenir la recurrencia en el caso del error de la válvula.
Unas recomendaciones, por ejemplo, podrían incluir la modificación del procedimiento o la
realización de los procedimientos de validación para asegurar que las referencias a las válvulas
coincidan con las etiquetas de las válvulas que se encuentra en la fábrica.
La identificación de las causas fundamentales es la clave para la prevención de recurrencias
similares. Un beneficio adicional de un efectivo RCA es que, con el tiempo, las causas identificadas
en la población de los sucesos pueden ser utilizadas para identificar las principales oportunidades
de mejora.

13
Si, por ejemplo, un número significativo de los análisis apuntan a las deficiencias de contratación,
los recursos pueden ser enfocados en el mejoramiento de este sistema de gestión. Las tendencias
de las causas permite el desarrollo de mejoras y evaluación sistemática del impacto de los
programas correctivos.
Definición
Para la definición de la causa raíz, se basa en lo siguiente:
1. Las causas fundamentales son específicas de las causas subyacentes.
2. Las causas fundamentales son las que razonablemente se puede identificar.
3. Las causas fundamentales son las que gestión tiene el control de arreglar.
4. Las causas fundamentales son aquellas en las que se pueden generar recomendaciones
eficaces para la prevención de recurrencias.
Las causas fundamentales son producto de las causas subyacentes. El objetivo del investigador
debe ser la identificación de causas subyacentes específicas. Cuanto más específico sea el
investigador acerca del por qué se produjo un evento, más fácil será llegar a las recomendaciones
que eviten recurrencia.
Las causas fundamentales son las que razonablemente se puede identificar. La investigación de
incidentes debe estar apoyada en la razón costo-beneficio. No es práctico mantener la mano de
obra valiosa ocupada indefinidamente en la búsqueda de las causas de los sucesos. Un RCA
estructurado ayuda a los analistas a sacar el máximo partido del tiempo que han invertido en la
investigación.
Las causas fundamentales son aquellas sobre las que la gestión tiene el control. Los analistas deben
evitar el uso de las clasificaciones generales de las causas, como un error del operador, fallas de
equipos o factor externo. Esas causas no son lo suficientemente específicas como para permitir
que la administración haga cambios que tengan efecto. La administración necesita saber
exactamente por qué se produjo una falla antes de que puedan ser tomadas acciones para
prevenir la recurrencia.
También hay que identificar la causa raíz donde la gestión de la organización pueda influir. La
identificación de "mal tiempo" como la causa fundamental de que las partes no se entreguen a
tiempo a los clientes no es apropiada. El clima severo no es controlado por la administración.
Las causas fundamentales son aquellas para las que se pueden generar recomendaciones efectivas.
Las recomendaciones deben directamente abordar las causas fundamentales identificadas durante
la investigación. Si los analistas llegan a recomendaciones vagas como "mejorar la adhesión a las
políticas y procedimientos escritos," entonces probablemente no ha encontrado unas causas
bastante básicas y específicas y necesitan gastar más esfuerzo en el proceso de análisis.

14
Cuatro pasos importantes
La RCA es un proceso de cuatro etapas que implica lo siguiente:
1. Recopilación de datos.
2. Gráficas del factor causal
3. Identificación de la causa raíz.
4. Generación de recomendación e implementación.
Paso 1 - recopilación de datos. El primer paso en el análisis consiste en reunir los datos. Sin la
información completa y una comprensión de los eventos, los factores causales y las causas
asociadas con el evento no pueden ser identificados. La mayoría del tiempo que se usa en el
análisis de un evento es en la recolección de datos.
Paso 2 - gráficas de los factores causales. Las gráficas del factor(es) causal proporcionan una
estructura a los investigadores para organizar y analizar la información recopilada durante la
investigación e identificar las vacios y deficiencias en el conocimiento a medidas que la
investigación avanza. La carta del factor causal es simplemente un diagrama de secuencias con las
pruebas lógicas que describen los acontecimientos que condujeron a un evento, además de las
condiciones que rodean estos eventos (Ver Fig. 7).
La preparación de la tabla de factor causal debe comenzar tan pronto como los investigadores
comienzan a recopilar información acerca de la ocurrencia. Se inicia con un diagrama preliminar
que se modifica a medida que más datos relevantes no están cubiertos. La tabla de factor causal
debe conducir el proceso de recolección de datos mediante la identificación de las necesidades de
datos.
La recolección de datos continúa hasta que los investigadores están satisfechos con la
minuciosidad de la tabla (y por tanto está satisfecho con la minuciosidad de la investigación).
Cuando el suceso se ha trazado a totalidad, los investigadores están en una buena posición para
identificar los principales contribuyentes a los incidentes, llamadas factores causales. Los factores
causales son los contribuyentes (los errores humanos y fallas de los componentes) que, si se
eliminan, se habría evitado la ocurrencia o reducido su gravedad.
En muchos de los análisis tradicionales, al factor causal más visible se le da toda la atención. Rara
vez, sin embargo, hay un solo factor causal, los eventos son generalmente el resultado de una
combinación de los contribuyentes.
Cuando sólo uno de los factores causales evidentes es tratado, la lista de recomendaciones
probablemente no será completa. En consecuencia, la aparición puede repetirse porque la
organización no aprendió todo lo que podía del evento.

15
Quemador
eléctrico en corto
circuito
Quemador
FC
El arco calienta el
fondo de aluminio
de la cacerola
Cacerola
Aluminio se funde,
forma un agujero
en la cacerola
Cacerola
Grasa arde da
contacto con el
quemador
Conclusión
El fuego comienza
en la cocina
María
Maria se
encuentra con
Julia
María
10minutos
Detector de humo
da la alarma
María y Julia
Alrededor 17:10
María deja el pollo
friéndose
desatendido
María
María comienza a
freir el pollo
María
Hora: 17.00
María usa una
cacerola de
aluminio
Cacerola
¿Cuánto aceite
usa? ¿Cuál es la
cantidad de pollo?
Pollo, aceite,
cacerola
Julia toca el timbre
María y Julia
Julia llega hasta la
puerta de entrada
Julia
El fuego genera
humos
Asumido
María corre hacia
la cocina
María
María trata de
usar el extinguidor
de fuego
María
María acciona el
gatillo del
extinguidor
María
El extinguidor no
funciona cuando
se necesitó
María
María ve el fuego
en la cocina
María
El extinguidor no
está recargado
María
FC
FC
FC Factor Causal
¿El gatillo calza
bien en el
accionador?
María
¿Sabe María
accionar el
extinguidor?
María
¿Qué fue lo que
vio exactamente?
María
¿Había sido
usado
previamente?
Tarjeta de
inspección
¿Tiene goteras?
Ubicación del
extinguidor
¿No había sido
recargado
originalmente?
Extinguidor de
fuego
Fig. 7: Gráfica de los factores causales

16
María arroja agua
a la cocina
María
El fuego se
esparce a través
de la cocina
Cocina, María
María llama a los
bomberos
María, Bomberos
Hora?
Los bomberos
llegan
Observación
Hora?
Los bomberos
apagan el fuego
Bomberos, obs.
Hora?
La cocina
destruida por el
fuego
Otras pérdidas
por el humo y el
agua
El fuego fue grasa
ardiendo
María, cacerola
¿Estaba María
tratando de hacer
esto?
María
¿Trató de hacer
algo más?
María
¿Sabía ella que
eso estaba
mal?¿Falta de
práctica con el
combate al
fuego?
María
¿Qué estaba
haciendo Julia en
ese momento?
María, Julia
¿Cuánto fue la
demora de los
bomberos?
Despachador
¿Usaron los
bomberos las
técnica correctas?
Bomberos
FC
Fig. 7(cont.): Gráfica de los factores causales
Paso 3 - identificación de la causa raíz. Después que todos los factores causales han sido
identificados, los investigadores comienzan identificación de causas raíz. Este paso implica el uso
de un diagrama de decisión llamado el Mapa de Causa Raíz (vea Fig. 8) para determinar la causa o
las razones de cada factor causal.
El mapa estructura el proceso de razonamiento de los investigadores, ayudándoles a responder a
las preguntas acerca de por qué determinados factores causales existen o se produjeron. La
identificación de las causas fundamentales ayuda al investigador a determinar las razones de la
ocurrencia del suceso como de los problemas que rodean la ocurrencia para que puedan ser
abordados.

17
Comenzar aquí para cada factor causal
Dificultad en el equipo
1
Problema en el
diseño del equipo
Problemas en el
programa de
confiabilidad
Instalación /
fabricación
Mal uso del
equipo
Input/Output
del diseño
Datos del
equipo
Diseño del
programa de
confiabilidad MqA
Implementación
del programa de
confiabilidad MqA
Sistema de
gestión
administrativo
MqA : Menos que Adecuado
Procedi-
mientos
2
Input del diseño
MqA
Output del diseño
MqA
Datos de diseño del
equipo MqA
Datos de operación /
historial de
mantenimiento del
equipo MqA
Sin programa
Programa MqA
•Procedimientos /Análisis
MqA
•Asignación del tipo de
mantenimiento inapropiado
•Criterios de aceptación del
riesgo MqA
• Asignación de recursos
MqA
Mantenimiento correctivo MqA
• Resolución de problemas/acciones
correctivas MqA
• Implementación de reparaciones
MqA
Mantenimiento preventivo MqA
• Frecuencias MqA
• Alcances MqA
• Implementación de actividades MqA
Mantenimiento Predictivo MqA
• Detección MqA
• Monitoreo MqA
correctivas MqA
Mantenimiento proactivo MqA
• Especificación de los eventos MqA
• Monitoreo MqA
• Alcances MqA
Búsqueda de fallas de
Mantenimiento MqA
• Frecuencia MqA
• Alcances MqA
correctivas MqA
• Implementación de reparos
Rutinas de inspección de equipos
MqA
• Frecuencias MqA
• Alcances MqA
Estándares, políticas o
controles administrativos
(EPCA) MqA
• Sin EPCA
• No son suficientemente
estrictos
• Confusos, contradictorios o
incompletos
• Técnicamente erróneos
• Responsabilidad/actividad
para el ítem inadecuada
definición
• Planeamiento/programación
o seguimiento de las
actividades del trabajo MqA
• Premios/incentivos MqA
• Selección/contratación de
empleados MqA
EPCA no son usados
• La comunicación de los
EPCA MqA
• Cambiados recientemente
• Aplicación MqA
Revisión del riesgo su
seguridad /posibilidad
• Revisión MqA o no ejecutada
• Las recomendaciones aún
no son implementadas
• El criterio de aceptación MqA
• Revisión de los
procedimientos MqA
Control del producto/
material
• Manejo MqA
• Almacenamiento MqA
• Embalaje/despacho MqA
• Sustitución del material no
autorizada
• Criterios de aceptación del
producto MqA
•Inspección del producto MqA
Control de identificación de
los problemas
• Reportes de los problemas
MqA
• Análisis de los problemas
MqA
• Auditoría MqA
• Acciones correctivas MqA
• Acciones correctivas aún no
implementadas
Control del abastecimiento
• Especificaciones de compra
MqA
• Control de cambio en las
especificaciones de compra
MqA
• Requisitos de aceptación de
materiales MqA
• Inspección de materiales
MqA
• Selección de contratistas
MqA
Control de documentos y
configuración
• Cambio no identificado
• Verificación del diseño/
cambio de campos MqA
•La documentación no
contiene datos actualizados
• Control oficial de
documentos MqA
Interfaces/servicios
• Requerimientos del cliente
no identificados
• Necesidades del cliente no
focalizadas
•Implementación MqA
No usados
• No disponible o
inconveniente para obtener
•Procedimiento difícil de usar
• Uso no requerido pero está
• Tarea sin procedimientos
Engañoso/confuso
• Formato confuso o MqA
• Más de una acción por paso
• No hay especio para marcar pero se necesita
• Lista de chequeo inadecuada
• Gráficas MqA
•Instrucciones/requerimientos ambiguos o
confusos
• Datos/mal calculados/incompletos
• Insuficientes o execivas referencias
• Identificación o revisión de pasos MqA
• Nivel de detalle MqA
• Dificultad para identificar
Erróneo/incompleto
• Errores tipográficos
• Secuencia equivocada
• Hechos erróneos/requerimientos
no correctos
• Revisión errada o procedimiento
expirado
• Inconsistencia entre
requerimientos
• Incompleta/situación no cubierta
• Traslape o vacios entre
procedimientos
Fig. 8: Mapa de Causa Raíz

18
Comenzar aquí para cada factor causal
Dificultad en el personal
1
Empleados de la
compañia
Empleados
contratistas
Eventos externos Otros
Ingeniería
factor humano
Entrenamiento
Supervisión
inmediata
Comunicaciones
Eficiencia del
personal
MqA : Menos que Adecuado
2
Disposición lugares de
trabajo
• Controles/visualizadores
MqA
• Control/Integración
visualizadores/ arreglos MqA
• Ubicación de los controles/
visualizadores MqA
• Disposiciones conflictantes
• Ubicación de equipos MqA
• Etiquetados de los equipos
o ubicaciones MqA
Preparación
• Sin preparación
• Plan de trabajo MqA
• Instrucciones a los
trabajadores MqA
• Tutorías MqA
• Programación MqA
• Selección de trabajadores/
asignación MqA
Supervisión durante el
trabajo
• Supervisión MqA
• Ejecuciones inapropiadas no
corregidas
• Equipos de trabajo MqA
Detección de problemas
MqA
*Capacidad sensorial/
precepción MqA
*Capacidades de
razonamiento MqA
*Capacidades motoras/físicas
MqA
*Actitud/atención MqA
*Descanso/dormir MqA
(fatiga)
*Problemas personales/
medicación
Ambiente de trabajo
• Limpieza MqA
• Herramientas MqA
• Ropa protectora/equipos
MqA
• Condiciones ambientales
MqA
• Otros stress ambientales
excesivos
Carga de trabajo
• Acción con requerimientos
de excesivo control
• Requerimientos no reales
de monitoreo
• Decisión requerida basada
en el conocimiento
• Excesivo cálculo requerido
o manipulación de datos
Sistema sin tolerancia
• Errores no detectables
• Errores no corregibles
Sin entrenamiento
• Decisión de no entrenar
• Requerimientos de
entrenamiento no identificados
Sistema de manuales de
entrenamiento MqA
• Manuales de entrenamiento
incorrectos
• Manuales de entrenamiento
no actualizados
Entrenamiento MqA
• Análisis trabajo/tarea MqA
• Diseño del programa/
objetivos MqA
• Contenidos de la lecciones
MqA • Entrenamiento en el
lugar de trabajo MqA
• Pruebas de calificación MqA
• Entrenamiento continuo MqA
• Recursos para
entrenamientos MqA
• Entrenanmiento para
situaciones no normales/
emergencias MqA
Instrucciones erradas
Sin comunicación o fuera
de tiempo
• Método inviable o MqA
• Comunicación entre grupos
de trabajo MqA
de trabajo y administración
MqA
• Comunicación con los
contratistas MqA
usuarios MqA
Comunicación sin entender
• Terminología estandarizada
no usada
• Verificación / validación no
usada
• Mensajes largos
Rotación del trabajo MqA
grupos de trabajo (turnos)
MqA
MqA
Otras dificultades
Sabotajes/
payasadas
Fenómenos
naturales
Fig. 8 (cont.): Mapa de Causa Raíz
Paso 4 - recomendaciones generales e implementación. El siguiente paso es la generación de
recomendaciones. Siguiendo la identificación de las causas raíz de un factor causal en particular, se
generan las recomendaciones factibles para la prevención de su recurrencia.
El analista de la causa raíz a menudo no es el responsable de la aplicación de las recomendaciones
generadas por el análisis. Sin embargo, si las recomendaciones no son implementadas, el esfuerzo
puesto en la realización del análisis se desperdicia. Además, los acontecimientos que

19
desencadenaron el análisis se debería esperar que se repitan. Las organizaciones necesitan
asegurarse que las recomendaciones sean seguidas hasta su finalización.
Presentación de los resultados
Las tablas de resumen de la causas raíz (ver Fig. 9) puede organizar la información recopilada
durante el análisis de datos, la identificación de causas raíz y la generación de recomendaciones.
Cada columna representa un aspecto importante del proceso de RCA.
• En la primera columna, se presenta una descripción general de los factores causales junto
con la información de fondo suficiente para que el lector pueda comprender la necesidad
de abordar este factor causal.
• La segunda columna muestra la ruta o rutas de acceso a través de la Hoja de Causa Raíz
asociada con el factor causal.
• La tercera columna presenta las recomendaciones para abordar cada una de las causas
raíces.
El uso de este formato de tres columnas ayuda al investigador para asegurarse de las causas raìz y
las recomendaciones se han desarrollado para cada factor causal. El resultado final de una
investigación RCA es por lo general un informe de investigación. El formato del informe es por lo
general bien definido por los documentos administrativos que rigen el sistema de información
particular, pero el cuadro y tablas completas de los factores causales proporcionan la mayor parte
de la información requerida por la mayoría de los sistemas de información.
Tabla resumen de las Causas Raíz
Descripción del evento: la cocina es destruida por el fuego y dañada por el humo y el agua.
Factor causal Nº 1 Ruta en el mapa Causa Raíz Recomendaciones
Descripción : Maria deja
friendo el pollo sin
atención
• Dificultad personal.
•Sistema
administrativo/administración.
• Estándares, políticas o control
administrativo MqA .
• Sin control.
• Implementar una política para que
el aceite caliente nunca se deje de
atender cuando esté en el
quemador.
• Determinar si se han desarrollado
políticas para otros tipos de
peligros en con el objetivo de no
dejar a ellos desatendido.
• Modificar el procedimiento de
evaluación del riesgo o el
procedimiento de desarrollo del
proceso para focalizar la atención
del personal durante la operación.
Descripción: el
quemador eléctrico falla
(cortocircuito).
• Dificultad en el equipo.
• Problema de confiabilidad del equipo.
• Diseño del programa de confiabilidad
del equipo MqA.
• Reemplace todos los quemadores
de la cocina.
• Desarrolle una estrategia de
mantenimiento preventivo para

20
• No hay programa. reemplazar periódicamente los
quemadores.
• Considerar métodos alternativos
para la preparación de pollo, que
puede implicar menos riesgos, tales
como asar el pollo o la compra del
producto final de un proveedor.
Descripción: el
extinguidor del fuego no
operó cuando María
trató de usarlo. .
• Problemas con la confiabilidad del
equipo.
• Mantenimiento proactivo del equipo
MqA.
• Implementación de actividades MqA.
• Rellenar el extinguidor de fuego.
• Inspeccionar otro extinguidor con
el objetivo de asegurarse que está
lleno.
• Tener reportes de incidentes que
describan el uso de elementos de
protección del fuego
conjuntamente con las
instrucciones de mantenimiento del
gatillo.
• Problemas con la confiabilidad del
equipo.
• Sistema administrativo /gestión.
• Identificación de problemas y control
MqA.
• Agregar este extinguidor a la lista
de auditoría.
• Verificar que todos los
extinguidores de la casa queden en
la lista de auditoría.
• Tener todos los requerimientos de
trabajos de mantenimiento que
involucran a los extinguidores en
vista de la seguridad y modificar las
listas de chequeo si es necesario.
Descripción: María arroja
agua en el fuego.
• Dificultad del personal.
• Empleados de la compañía.
• Entrenamiento.
• Entrenamiento MqA.
• Evento anormal/entrenamiento de
emergencias MqA.
• Proveer entrenamiento práctico
en el uso de extinguidores. Las
clases en sala parecen ser
insuficientemente adecuadas para
adquirir las habilidades.
• Revisar otras actividades que
requieren destrezas asegurándose
de tener el entrenamiento
adecuado.
• Revisar el desarrollo de programas
de entrenamiento de otras
actividades para asegurar el nivel
adecuado de habilidades mediante
laboratorios, ensayos, simulaciones,
etc.
Fig. 9: Tabla de análisis de causal y recomendaciones

21
El RCA asume que los sistemas y los acontecimientos están relacionados entre sí. Una acción en un
área activa una acción en otra, y otra, y así sucesivamente. Al trazar de nuevo estas acciones, se
puede descubrir donde empezó el problema y cómo se convirtió en el síntoma que está
enfrentando. Por lo general, se puede encontrar tres tipos básicos de las causas:
1. Causas físicas – en los elementos tangibles, material que falla de alguna manera (por
ejemplo, los frenos de un auto dejó de funcionar).
2. Causas humanas - la persona hizo algo mal, o no hizo algo que se necesitaba. Lo que el
humano hace suele dar lugar a causas físicas (por ejemplo, uno que no llenó con líquido de
frenos, lo que llevó a los frenos no funcionar).
3. Causas organizacionales - un sistema, proceso, o la política que usa la organización para
tomar decisiones o hacer su trabajo es defectuoso (por ejemplo, ninguna persona fue
responsable de mantenimiento de vehículos, y todo el mundo asume que alguien había
llenado el líquido de frenos).
En el Análisis de Causa Raíz se ve en los tres tipos de causas. Se trata de investigar los patrones de
efectos negativos, la búsqueda de fallas ocultas en el sistema, y el descubrimiento de las acciones
específicas que han contribuido al problema. A menudo, esto significa que RCA revela más que una
causa fundamental.

22
EL MÉTODO KEPNER- TREGOE O MATRIZ DEL PERFIL COMPETITIVO
Es una técnica estructurada para recopilar, priorizar y evaluar información. El objetivo de la técnica
no es el de encontrar una solución perfecta sino el de identificar la mejor alternativa posible.
La decisión para seleccionar dicha alternativa, se basa en conseguir un objetivo determinado con
mínimas consecuencias negativas. La técnica parte del supuesto que indica que todos los
problemas tienen la misma estructura, lo que invita a racionalizar su proceso de solución. La
técnica presenta cuatro patrones básicos de pensamiento:
1. Análisis de Situaciones ¿Qué está ocurriendo? Permite evaluar, aclarar, seleccionar e
imponer orden en una situación confusa.
2. Análisis de Problemas ¿Por qué ocurrió esto? Permite relacionar un suceso con su resultado,
una causa con su efecto.
3. Análisis de Decisiones ¿Qué curso de acción hay que tomar? Permite hacer decisiones
razonadas.
4. Análisis de Problemas Potenciales ¿Qué nos espera más adelante? Permite mirar en dirección
al futuro que nos depara.
La explicación de la técnica que se presenta, (KT por sus autores), expone cómo realizar el segundo
patrón de la solución de problemas; el Análisis de Problemas. Para los autores, un problema (falla)
es algún tipo de desviación de una norma, que alguien considera importante y necesario
restablecer. Es algo que ha salido mal inexplicablemente y su detección se inicia con una noción
clara de lo que debiera suceder.
El problema se especifica haciendo preguntas tanto del objeto afectado como del defecto mismo
mediante cuatro dimensiones:
1. La identidad de la falla (¿Qué?)
2. El lugar donde ocurre (¿Dónde?)
3. Su ubicación en el tiempo (¿Cuándo?)
4. La magnitud o tamaño (¿Cuánto?)
Contrastándose cada una de ellas con “LO QUE ES” y “LO QUE NO ES” o con lo que “PUDIERA SER”
pero “NO ES”.
La ventaja más importante de la técnica es la sistematización del análisis de los problemas, que de
acuerdo a lo que indican los autores, normalmente se analizan los problemas por intuición o
sentido común pero no de forma estructurada. La desventaja de esta técnica radica en la
necesidad del conocimiento profundo del sistema objeto de estudio.

23
La técnica es recomendable para identificar, describir y analizar problemas operativos de tipo
técnico, proporcionando un medio sistemático para extraer la información esencial de una
situación problemática y hacer a un lado la información irrelevante o confusa.
Definición del problema
El análisis del problema comienza con la definición del problema. El equipo que está a cargo de la
solución del problema no puede pasar por alto este paso crítico. La incapacidad para comprender
exactamente lo que es el problema a menudo resulta en pérdida de tiempo precioso. Muchos que
atacan los problemas con inmadurez consideran este paso como un esfuerzo inútil, ya que saben lo
que están haciendo - y esto es el grave error cometido por muchos. Nociones preconcebidas a
menudo resultan en una duración de corte final mayor e incluso la extensión en el corte debido a
un pobre juicio.
Ya que la gestión de problemas es de por sí un ejercicio de equipo, es importante tener una
comprensión del problema en el grupo. Considere los siguientes ejemplos. Una pobre definición
del problema podría aparecer como sigue: "El servidor se cayó."
Una mejor definición del problema debe incluir más información. Un buen modelo para formalizar
las declaraciones de todo tipo es método GQM (Goal-Question-Metric). Da como resultado una
declaración con un objetivo claro, un propósito, un enfoque, un medio ambiente, y un punto de
vista. Esto da lugar a una declaración inequívoca y fácil de entender.
Una definición del problema podría ser aclarado: "El sistema de correo electrónico falló después de
que el ingeniero de soporte del tercer turno aplicó pegamento caliente XYZ en el servidor de
intercambio 123".
Cuando se está desarrollando una definición del problema se recomienda utilizar la técnica de "5
porqués" para llegar al punto en que no hay más explicación para el problema. Utilizando 5
porqués con KT sólo acelera el proceso.
Describir el problema
Con una definición clara del problema, el siguiente paso es describir el problema en detalle. El
siguiente cuadro proporciona una buena plantilla para esta actividad. La tabla a continuación
describe la hoja de trabajo básico que se utiliza en el proceso.
ES PUEDE SER PERO NO ES DIFERENCIAS CAMBIOS
QUE Falla del sistema
Sistemas similares/situaciones sin
fallas
? ?
DONDE Ubicación de la falla Otras ubicaciones que no fallaron ? ?
CUANDO Momento de la falla
Otras veces cuando la falla no
ocurrió
? ?
EXTENSIÓN Otras fallas del sistema Otros sistemas sin falla ? ?

24
En la hoja se describen los cuatro aspectos de un problema: qué es, dónde se produce, cuando se
produjo, y la extensión en que se produjo. La columna ES proporciona espacio para describir en
detalle sobre el problema - lo que el problema ES. La columna PODRÍA SER, PERO NO ES ofrece un
espacio para listar detalles relacionados, pero excluidos - lo que el problema PODRÍA SER PERO NO
ES. Estas dos columnas ayudan en la eliminación de suposiciones "intuitiva pero incorrecta" sobre
el problema. Con las columnas uno y dos completas, la tercera columna ofrece espacio para
detallar las diferencias entre el SI y que PODRÍA SER PERO NO ES. Estas diferencias forman la base
de la solución de problemas. La última columna proporciona espacio para enumerar todos los
cambios realizados que podrían explicar las diferencias.
Determinar las Causas posibles
Cualquiera que haya pasado tiempo en la solución de problemas sabe ver "lo que ha cambiado
desde que trabajó" y empezar a solucionar problemas mediante el control de los cambios. El
problema es que muchos cambios pueden ocurrir, y que complica las cosas. El análisis de
problemas puede ayudar aquí por la descripción de lo que el problema es y lo que el problema
podría ser, pero no lo es. Por ejemplo:
Problema: ". "El sistema de correo electrónico falló después de que el ingeniero de soporte del
tercer turno aplicó pegamento caliente XYZ en el servidor de intercambio 123".
ES
PODRIA SER PERO NO
ES
DIFERENCIAS CAMBIOS
QUE
Servidor de intercambio
123 falló después de la
aplicación del pegamento
caliente XYZ
Otros servidores de
intercambio usaron
pegamento caliente
XYZ
Diferente staff
(3er turno)
aplicó este
pegamento
Vendedor entrega
un nuevo
procedimiento
DONDE
La sala de producción del
tercer piso sin el soporte
de un
vendedor/contratista
En cualquier lugar
con soporte de
vendedor/contratista
Normalmente
hecho por un
vendedor
Nuevo
procedimiento,
primera vez que lo
aplica el tercer
turno
CUANDO Última noche, 1:35am
Cualquier hora o
ubicación
Sin anotación
EXTENSIÓN
Todos los servidores del
3er piso
Otros servidores
Historiales (y mejores prácticas) dice que la causa raíz del problema se debe probablemente a un
cambio reciente.
Con la hoja de trabajo completa, algunas posibles soluciones nuevas se hacen evidentes. Arriba se
muestra que se pone de manifiesto que la causa es, probablemente, de procedimiento, y debido al

25
hecho de que el vendedor no aplicó el pegamento caliente, pero dio los procedimientos para
aplicar el pegamento a la empresa.
Prueba de la causa más probable
Con una lista corta de posibles causas (recientes cambios evaluados y convertidos en una lista), el
siguiente paso es pensar sobre cada posible problema. La siguiente ayuda puede contribuir en
este proceso. Haga la pregunta:
"Si _____________ es la causa raíz de este problema ¿explica el problema ES y cuál problema
PODRÍA SER, PERO NO LO ES?"
Si esta respuesta potencial es la causa raíz, entonces la solución potencial tiene que "mapear
hacia" o "encajar en" todos los aspectos de la hoja de trabajo de análisis de problemas. Utilice una
hoja de trabajo como la mostrada a continuación para ayudar a organizar su pensamiento en torno
a las posibles soluciones.
Causa Raíz Potencial: Verdad si:
¿Causa raíz
probable?
El servidor de intercambio 123 tiene algo
de malo en él
Solamente el servidor de intercambio
123 tiene este problema
Puede ser
Procedimiento incorrecto
El mismo procedimiento rompió otro
servidor
Probable
Error técnico El problema no siempre ocurre Probablemente no
Verificar la verdadera causa
El siguiente paso es comparar las causas raíz posibles en contra de la descripción del problema.
Eliminar las posibles soluciones que no pueden explicar la situación, y centrarse en los temas
restantes.
Antes de hacer cambios, verificar que la respuesta propuesta podría ser la causa raíz. Falla en la
verificación de la verdadera causa invalida todo el ejercicio y no es mejor que adivinar. Después de
verificar la verdadera causa, puede proponer las medidas necesarias requeridas para reparar el
problema.
Es importante aquí, así que pensar en cómo prevenir los problemas similares se repitan en el
futuro. El administrador del problema debe considerar cómo la cuestión se planteó en primer lugar
mediante unas preguntas:
¿Dónde más podría aparecer este problema?
¿Hay otros casos como este problema en el pasado?
¿Están todos los procedimientos necesarios para cambiar?
El objetivo es tratar de eliminar las repeticiones futuras del problema.

26
5 PORQUÉS PARA RESOLVER PROBLEMAS
Inventado en 1930 por Kiichiro Toyoda y se hizo popular en la década de 1970 por el Sistema de
Producción Toyota. La estrategia de 5 porqués implica observar cualquier problema y preguntar:
"¿Por qué?" y "¿Qué causó este problema?" Six Sigma, un sistema de gestión de calidad (SGC),
utiliza "5 porqués" en la fase de análisis de la metodología Six Sigma: Definir, Medir, Analizar,
Mejorar, Controlar (DMAIC).
La idea es simple. Al plantear la pregunta "¿Por qué?" se puede separar los síntomas de las causas
de un problema. Esto es fundamental ya que los síntomas suelen enmascarar las causas de los
problemas. Teniendo una efectiva clasificación de incidentes, basar las acciones en los síntomas es
la peor práctica posible.
5 Porqués ofrece algunas ventajas reales en cualquier nivel de madurez:
Simplicidad. Es fácil de usar y no requiere de las matemáticas o herramientas avanzadas.
Eficacia. Sin duda ayuda a separar rápidamente los síntomas de las causas e identificar la
causa raíz de un problema.
Exhaustividad. Ayuda a determinar las relaciones entre las diversas causas del problema.
Flexibilidad. Funciona bien solo y cuando se combina con otros para mejorar la calidad y las
técnicas de resolución de problemas.
Atractivo. Por su propia naturaleza, fomenta y produce el trabajo en equipo y equipos
dentro y fuera de la organización.
De bajo costo. Se trata de una guía, centrada en el ejercicio del equipo. No hay costos
adicionales.
A menudo la respuesta al primer "por qué" descubre otras razones y genera otro "por qué". A
menudo se requieren cinco "por qué" para llegar a la causa raíz del problema. Es probable que
encuentre lo que le piden más o menos en 5 "por qué" en la práctica.
Cómo utilizar el 5 por qué
1. Reunir a un equipo de gente experta en el elemento de la configuración que está fallando.
Incluir especialistas de áreas relacionadas y usuarios del sistema en análisis si fuese
necesario.
2. En un tablero de presentación escribir una descripción de lo que sabe sobre el problema.
Trate de documentar el problema y describir lo más completo posible. Perfeccionar la
definición con el equipo. Llegar a un acuerdo sobre la definición del problema en cuestión.
3. Un miembro del equipo pregunta "¿Por qué?" el problema descrito puede ocurrir, y escribe
la respuesta por debajo de la descripción del problema.

27
4. Si la respuesta dada a partir de 3 (arriba) no resuelve el problema, debe repetir los pasos 3
y 4 hasta que lo haga.
5. Si la respuesta dada a partir de 3 (arriba), parece probable que para resolver el problema,
asegúrese de que el equipo está de acuerdo e intentar una resolución con la respuesta.
Sea el siguiente ejemplo (Fig. 10):
¿Por qué la maquina se detuvo?
La sobrecarga se disparó ¿Por qué la sobrecarga se disparó?
Insuficiente aceite en el eje
¿Por qué el aceite es insuficiente?
La bomba del aceite es ineficiente
¿Por qué la bomba es ineficiente?
El eje de la bomba está deteriorado
¿Por qué el eje está deteriorado?
Filtro de aceite bloqueado con virutas
CAUSA
RAIZ
Fig. 10: el ciclo de los 5 por qué
El dominio de los 5 por qué
Es de suma importancia basar las causas raíz propuestas (respuesta al "por qué") en la observación
directa y no en la especulación o la deducción. Si no se puede ver u observar el "por qué" de
primera mano, entonces sólo se está adivinando. Uno de los problemas comunes de quienes
utilizan los 5 porqués es caer en conjeturas en su informe. Es evidente que la adivinación es
contraproducente. Gente experimentada en la técnica de exigen la precisión preguntando los 5

28
porqués de nuevo para cada propuesta para la causa raíz - sólo que esta vez preguntando por qué
el equipo piensa que la propuesta de la causa raíz es la correcta.
Para validar las potenciales causas raíz que están bajo su control, puede aplicar las validaciones
siguientes a sus respuestas o causas raíz. Haga las siguientes preguntas para cada posible causa raíz
identificada a todos los niveles de los 5 porqués:
¿Hay alguna prueba (algo que se puede medir u observar) para apoyar esta determinación
de causa raíz?
¿Hay alguna historia o el conocimiento que indique que la posible causa raíz en la
actualidad podría producir el problema?
¿Hay algo "por debajo" de la posible causa raíz que podría ser una causa más probable?
¿Hay algo que esta posible causa raíz requiere para producir el problema?
¿Hay alguna otra causa que pudiera producir el mismo problema?
Si se agrega a estas preguntas validadas y los resultados a la descripción del problema y las
preguntas y respuestas, se producirá una indicación mucho más clara del problema y es posible
identificar otras posibles soluciones. Si se diagrama de este proceso, el resultado final será con un
árbol de factores que conducen al problema. Incluso si usted no llegar a una resolución, la
comprensión de la cuestión o el problema es mucho mayor, a menudo ofrece caminos para un
diagnóstico más profundo. El uso de Ishikawa (causa-efecto o "espina de pez") hace que los
diagramas de 5 porqués sean especialmente efectivos.

29
DIAGRAMA DE ISHIKAWA PARA LA CAPTURA DE LAS SOLUCIONES
El diagrama de Ishikawa es un método gráfico para el análisis de causa raíz. Documentado por
primera vez por Kaoru Ishikawa, se utiliza hoy en día como una piedra angular de la mejora
continua del servicio. Debido a su forma, también es conocido como el diagrama de espina de
pescado. Otro nombre para esta técnica es de diagramación causa y efecto.
Los diagramas de Ishikawa son aparentemente simples, pero no hay que dejar que eso detenga un
análisis. Usando esta técnica se puede ver todas las posibles causas de un resultado (un problema,
por ejemplo), y descubrir la causa raíz de fallas.
La diagramación Ishikawa no requiere inversión en software o herramientas. Se trata de un
ejercicio de grupo. Siguiendo lo que se describe cómo, por qué y cuándo para crear y utilizar
diagramas Ishikawa de causa y efecto.
Análisis de Causa Raíz
Ishikawa, "Espina de pesado", o diagrama de causa y efecto se refieren a lo mismo: una
representación gráfica de las entradas (causas y razones) y una salida (el problema o evento). Un
profesional guía a un grupo en la organización de causas de acuerdo a su importancia. Esto se
traduce en un gráfico que muestra la relación entre las causas, razones y el problema objeto de
estudio. Este gráfico ayuda a identificar las causas raíces, ineficiencias y otros problemas.
Los diagramas de Ishikawa se complementan muy bien con otras herramientas similares, incluidas
las de Kepner-Tregoe, y otras.
Los diagramas de Ishikawa son similares a otras herramientas de calidad. Mediante el uso de
pizarras, el profesional intenta visualizar, recoger y organizar la información. Tan simple como
suena, a veces solamente obtener todas las ideas de un grupo de personas organizadas en un
diagrama acelera drásticamente el diagnóstico de problemas y resoluciones.
Usar esta técnica siempre que se deba:
Determinar la causa raíz de un problema
Comprender las posibles razones porque un proceso no está cumpliendo como se esperaba
Identificar áreas en las que recoger datos
Un diagramas Ishikawa completo en algo se asemeja a una espina de pescado, y por lo tanto el
apodo de "Diagrama de espina de pescado". Siguiendo con la analogía de los peces, la "cabeza"
debe contener una descripción del problema. De la cabeza se origina la "columna vertebral" del
diagrama. De la columna vertebral, "costillas" indican el área de los principales que pueden causar
el problema descrito (ver Fig.11).

30
Fig. 11: Diagrama de Ishikawa
La diagramación Ishikawa es más útil como una herramienta de grupo. No hay límite a la
complejidad de los diagramas. El ejemplo es sencillo, pero el suyo puede ser muy complejo.
Normalmente, más de 4 o 5 niveles son demasiado complejos para producir cualquier causa
visible.
Cuando el diagrama está completo, el equipo cuenta con un documento gráfico que muestra
organizada todas las posibles causas del problema descrito. A continuación, el grupo discute la
causa raíz más probable y propone un plan de acción.
Creación de una Diagrama Ishikawa "Espina de pescado"
La creación de un diagrama de Ishikawa sigue un proceso simple:
Reunir a un grupo de personas familiarizadas con el problema en cuestión.

31
1. Dibujar una línea horizontal como la "columna vertebral" y una caja a la derecha de la
columna vertebral como la "cabeza" en un tablero.
2. Trabajar con el grupo para llegar a una descripción del problema que sea claro y conciso.
Escribir la descripción del problema en la caja de problema o cabeza de pescado del
diagrama. En el ejemplo, el problema es "incertidumbre operativa", refiriéndose a por qué
no se consigue entregar un producto computacional de calidad.
3. Ahora el equipo tiene que discutir y estar de acuerdo con los grandes grupos de causas o
"costillas" iníciales. Si el grupo no se ponen de acuerdo sobre las causas principales, sólo
tiene que utilizar las 3 P - Personas, Proceso, Producto. Escriba una etiqueta para cada
"costilla", permitiendo que el espacio para las razones como se muestra en el ejemplo.
4. Use las técnicas tradicionales de tormentas de ideas para llenar las posibles razones de la
"costillas" de la siguiente manera:
a. Pregunte a cada persona una por una para que dé una posible causa (tal vez en
forma de una pregunta) para cada una "costilla". Cada persona debe presentar una
razón posible, y si no puedo pensar en una puede pasar. Asegúrese de que cada
causa es clara, concisa y medible.
b. Dibujar la causa en una línea conectada a la "costilla" adecuada y la etiquétela con la
causa. Si la causa propuesta es un factor en una causa existente (costilla), a
continuación, dibuje otra espina dorsal de la costilla, añadir otra costilla, y la
etiqueta de la misma.
c. Volver atrás y repetir hasta que todo el mundo dice, "pasa" y no hay más causas
posibles que las costillas ya existentes y no hay costillas nuevas que añadir.
5. Con la espina de pez completo, ahora revisar y discutir el diagrama de Ishikawa para buscar
las causas comunes o repetidas. Trate de determinar la causa raíz del problema.
La forma más rápida y más fácil de interpretar los resultados de Ishikawa es el diagrama para
seleccionar y clasificar las 5 mejores causas. Deje que el grupo decida cómo clasificar las causas.
Los 5 porqués son también útiles para determinar la más probable causa raíz cuando el esquema
se completa también. Haga un círculo de las causas seleccionadas. Haga que los miembros
apropiados del grupo investiguen estas causas utilizando otras técnicas de solución de problemas.
Repita según sea necesario.
El dominio de Causa y Efecto
Profesionales con experiencia limitan el número de "costillas" (causas) para el enfoque del grupo.
Algunos sugieren que no permitan más de 3 a 5 costillas. Otras técnicas de uso de clave de
Ishikawa son:
Enmarcar el problema como una pregunta, tal como "¿Por qué son los incidentes……? ¿Por
qué existe tan alta tasa de rechazo en el……? Cada causa debe responder a esa pregunta.

32
Asegurarse que las "costillas" son las causas del problema, no los síntomas del problema.
Use la tormenta de ideas para determinar exactamente lo que las costillas debe ser – la
técnica del "5 porqués" puede ayudar aquí.
Comprobar que las causas en el diagrama no son en sí otros problemas.
Combinar costillas vacías (o casi vacías), con otras costillas más apropiadas.
Divida aquellas costillas densas en costillas adicionales, según convenga.
Realice copias de los resultados y darlas a conocer a los demás para obtener mayor
conocimiento y participación del personal.
El diagrama de Ishikawa es una potente herramienta para aprovechar la combinación de
conocimientos y experiencia de un grupo de personas. Esto permite que el grupo focalice la
discusión sobre el por qué se producen problemas sin la distracción de los síntomas.

33
HAZARD AND OPERABILITY (HAZOP)
Descripción
El HAZOP es una técnica de identificación de riesgos inductiva basada en la premisa de que los
riesgos, los accidentes o los problemas de operatividad, se producen como consecuencia de una
desviación de las variables de proceso con respecto a los parámetros normales de operación en un
sistema dado y en una etapa determinada. Por tanto, ya se aplique en la etapa de diseño, como en
la etapa de operación, la sistemática consiste en evaluar, en todas las líneas y en todos los sistemas
las consecuencias de posibles desviaciones en todas las unidades de proceso, tanto si es continuo
como discontinuo. La técnica consiste en analizar sistemáticamente las causas y las consecuencias
de unas desviaciones de las variables de proceso, planteadas a través de unas "palabras guía".
La realización de un análisis HAZOP consta de las etapas que se describen a continuación:
Etapas
Definición del área de estudio: Consiste en delimitar las áreas a las cuales se aplica la técnica. En
una determinada instalación de proceso, considerada como el área objeto de estudio, se definirán
para mayor comodidad una serie de subsistemas o líneas de proceso que corresponden a
entidades funcionales propias: línea de carga a un depósito, separación de disolventes, reactores,
etc.
Definición de los nudos: En cada uno de estos subsistemas o líneas se deberán identificar una serie
de nudos o puntos claramente localizados en el proceso. Por ejemplo, tubería de alimentación de
una materia prima a un reactor, impulsión de una bomba, depósito de almacenamiento, etc.
Cada nudo deberá ser identificado y numerado correlativamente dentro de cada subsistema y en el
sentido del proceso para mejor comprensión y comodidad. La técnica HAZOP se aplica a cada uno
de estos puntos. Cada nudo vendrá caracterizado por variables de proceso: presión, temperatura,
caudal, nivel, composición, viscosidad, etc.
La facilidad de utilización de esta técnica requiere reflejar en esquemas simplificados de diagramas
de flujo todos los subsistemas considerados y su posición exacta.
El documento que actúa como soporte principal del método es el diagrama de flujo de proceso, o
de tuberías e instrumentos, P&ID.
Aplicación de las palabras guía: Las "palabras guía" se utilizan para indicar el concepto que
representan a cada uno de los nudos definidos anteriormente que entran o salen de un elemento
determinado. Se aplican tanto a acciones (reacciones, transferencias, etc.) como a parámetros
específicos (presión, caudal, temperatura, etc.). La tabla siguiente presenta algunas palabras guía y su
significado.

34
Palabra
guía
Significado Ejemplo de
desviación
Ejemplo de causas originadoras
NO Ausencia de la variable a
la cual se aplica
No hay flujo en
una línea
Bloqueo; fallo de bombeo; válvula cerrada
o atascada; fuga; válvula abierta; fallo de
control
MÁS Aumento cuantitativo de
una variable
Más flujo (más
caudal)
Presión de descarga reducida; succión
presurizada; controlador saturado; fuga;
lectura errónea de instrumentos
Más temperatura Fuegos exteriores; bloqueo; puntos
calientes; explosión en reactor; reacción
descontrolada
MENOS Disminución cuantitativa
de una variable
Menos caudal Fallo de bombeo; fuga; bloqueo parcial;
sedimentos en línea; falta de carga;
bloqueo de válvulas
Menos
temperatura
Pérdidas de calor; vaporización; venteo
bloqueado; fallo de sellado
INVERSO Analiza la inversión en el
sentido de la variable. Se
obtiene el efecto
contrario al que se
pretende
Flujo inverso Fallo de bomba; sifón hacia atrás; inversión
de bombeo; válvula antirretorno que falla o
está insertada en la tubería de forma
incorrecta
ADEMÁS
DE
Aumento cualitativo. Se
obtiene algo más que las
intenciones del diseño
Impurezas o una
fase extraordinaria
Entrada de contaminantes del exterior
como aire, agua o aceites; productos de
corrosión; fallo de aislamiento; presencia
de materiales por fugas interiores; fallos de
la puesta en marcha
PARTE DE Disminución cualitativa.
Parte de lo que debería
ocurrir sucede según lo
previsto
Disminución de la
composición en
una mezcla
Concentración demasiado baja en la
mezcla; reacciones adicionales; cambio en
la alimentación
DIFERENTE
DE
Actividades distintas
respecto a la operación
normal
Cualquier actividad Puesta en marcha y parada; pruebas e
inspecciones; muestreo; mantenimiento;
activación del catalizador; eliminación de
tapones; corrosión; fallo de energía;
emisiones indeseadas, etc.
Definición de las desviaciones a estudiar: Para cada nudo se plantea de forma sistemática todas
las desviaciones que implican la aplicación de cada palabra guía a una determinada variable o
actividad. Para realizar un análisis exhaustivo, se deben aplicar todas las combinaciones posibles
entre palabra guía y variable de proceso, descartándose durante la sesión las desviaciones que no
tengan sentido para un nudo determinado.
Paralelamente a las desviaciones se deben indicar las causas posibles de estas desviaciones y
posteriormente las consecuencias de estas desviaciones.

35
En la tabla anterior se presentan algunos ejemplos de aplicación de palabras guía, las desviaciones
que originan y sus causas posibles.
Sesiones HAZOP: Las sesiones HAZOP tienen como objetivo la realización sistemática del proceso
descrito anteriormente, analizando las desviaciones en todas las líneas o nudos seleccionados a
partir de las palabras guía aplicadas a determinadas variables o procesos. Se determinan las
posibles causas, las posibles consecuencias, las respuestas que se proponen, así como las acciones
a tomar.
Toda esta información se presenta en forma de tabla que sistematiza la entrada de datos y el
análisis posterior. A continuación se presenta el formato de recogida del HAZOP aplicado a un
proceso continuo.
Planta:
Sistema:
Nudo Palabra
guía
Desviación
de la variable
Posibles
causas
Consecuencias Respuesta Señalización Acciones a
tomar
Comentarios
El significado del contenido de cada una de las columnas es el siguiente:
Columna Contenido
Posibles causas Describe numerándolas las distintas causas que pueden conducir a la desviación
Consecuencias Para cada una de las causas planteadas, se indican con la consiguiente
correspondencia en la numeración las consecuencias asociadas
Respuesta del
sistema
Se indicará en este caso:
1. Los mecanismos de detección de la desviación planteada según causas o
consecuencias: por ejemplo, alarmas
2. Los automatismos capaces de responder a la desviación planteada según las causas:
por ejemplo, lazo de control
Acciones a tomar Propuesta preliminar de modificaciones a la instalación en vista de la gravedad de la
consecuencia identificada o a una desprotección flagrante de la instalación
Comentarios Observaciones que complementan o apoyan algunos de los elementos reflejados en
las columnas anteriores
En el caso de procesos discontinuos, el método HAZOP sufre alguna modificación, tanto en su
análisis como en la presentación de los datos finales.
Las sesiones HAZOP se llevan a cabo por un equipo de trabajo multidisciplinar cuya composición se
describe con detalle más abajo en el apartado de recursos necesarios.
Como resumen del procedimiento, se presenta el esquema siguiente aplicado a procesos continuos

36
Inicio Análisis Funcional de Operatividad (AFO):
1. Elección de un equipo.
2. Definir las funciones deseadas del equipo incluidas las conducciones y aparatos o servicios
auxiliares asociadas al mismo.
3. Elección de una línea de conducción.
4. Definir la función deseada de esta línea de conducción.
5. Utilización de la primera palabra – guía.
6. Formulación del significado de la posible desviación.
7. Determinar las posibles causas.
8. Examinar posibles consecuencias.
9. Determinar la peligrosidad, considerando la posibilidad de tales acontecimientos.
10. Proponer medidas necesarias.
11. Repetición de los puntos 6 – 10 para todas las posibles desviaciones que fueron
formuladas con ayuda de la primera palabra guía.
12. Repetición de los puntos 5 – 11 para todas las palabras – guías.
13. Señalizar la parte analizada en los diagramas de trabajo (flowsheets).
14. Repetición de los puntos 3 – 13 para cada línea diferente.
15. Elección de un servicio auxiliar (por ejemplo sistema de calefacción).
16. Definir la función deseada de este servicio auxiliar.
17. Repetición de los puntos 5 -12 para tal servicio auxiliar.
18. Señalizar la parte analizada en los diagramas de trabajo.
19. Repetición de los puntos 15 – 18 para todos los servicios auxiliares.
20. Definir las intenciones específicas del equipo o unidad.
21. Repetir 5 – 12.
22. Señalizar que el análisis del equipo o unidad está completo.
23. Repetir 1 – 22 para los diferentes para los diferentes equipos del diagrama de procesos.
24. Señalizar en el flowsheet de la instalación que la unidad de procesos ha sido analizada.
25. Repetir 1 – 24 para todas de procesos de la instalación.
Final Análisis Funcional de Operatividad
Informe final: El informe final consta de los siguientes documentos:
Esquemas simplificados con la situación y numeración de los nudos de cada subsistema.
Formatos de recogida de las sesiones con indicación de las fechas de realización y
composición del equipo de trabajo.

37
Análisis de los resultados obtenidos. Se puede llevar a cabo una clasificación cualitativa de
las consecuencias identificadas.
Listado de las medidas a tomar. Constituye una lista preliminar que debería ser
debidamente estudiada en función de otros criterios (coste, otras soluciones técnicas,
consecuencias en la instalación, etc.) y cuando se disponga de más elementos de decisión.
Lista de los sucesos iniciadores identificados.
Ámbito de aplicación
La mayor utilidad del método se realiza en instalaciones de proceso de relativa complejidad o en
áreas de almacenamiento con equipos de regulación o diversidad de tipos de trasiego. Es uno de
los métodos más utilizados que depende en gran medida de la habilidad y experiencia de los
miembros del equipo de trabajo para identificar todos los riesgos posibles.
En plantas nuevas o en fase de diseño, puede ayudar en gran medida a resolver problemas no
detectados inicialmente. Además, las modificaciones que puedan surgir como consecuencia del
estudio pueden ser más fácilmente incorporadas al diseño. Por otra parte, también puede aplicarse
en la fase de operación y en particular ante posibles modificaciones.
Recursos necesarios
El grupo de trabajo estable estará constituido por un mínimo de cuatro personas y por un máximo
de siete. Podrá invitarse a asistir a determinadas sesiones a otros especialistas.
Se designará a un coordinador/director del grupo, experto en HAZOP, y que podrá ser el técnico de
seguridad, y no necesariamente una persona vinculada al proceso. Aunque no es imprescindible
que lo conozca en profundidad, si debe estar familiarizado con la ingeniería de proceso en general.
Funciones del coordinador/director del grupo
Recoger la información escrita necesaria de apoyo.
Planificar el estudio.
Organizar las sesiones de trabajo.
Dirigir los debates, procurando que nadie quede en un segundo término o supeditado a
opiniones de otros.
Cuidar que se aplica correctamente la metodología, dentro de los objetivos establecidos,
evitando la tendencia innata de proponer soluciones aparentes a problemas sin haberlos
analizado suficientemente.
Recoger los resultados para su presentación.
Efectuar el seguimiento de aquellas cuestiones surgidas del análisis y que requieren
estudios adicionales al margen del grupo.

38
El grupo debe incluir a personas con un buen conocimiento y experiencia en las diferentes áreas
que confluyen en el diseño y explotación de la planta.
Ejemplo
El ejemplo se aplica a una parte de una instalación en una planta de dimerización de olefina. El
diagrama de flujo sobre el que se aplica el AFO consiste en el suministro de hidrocarburo a un
depósito de almacenamiento. Forma parte de un subsistema mayor que consiste en la
alimentación del hidrocarburo del depósito regulador hasta un reactor de dimerización donde se
produce la olefina (ver Fig. 12).
J1 Bombas de trasvase
(una en funcionamiento
y otra en reserva)
Drenaje y
purgado
con N2
I-2
I-3
20ªC
35 psig
Conducción
de 500 m
Hidrocarburos de
tanque intermedio
I-5
Depósito
regulador / dosificador
25 m3 20ªC 15 psig
Colector
de agua
A drenaje
Nitrógeno
(Inertizante)
PG
PG
FO
TR
AN
LIC
PIC
RF
Drenaje y
purgado
con N2
Fig. 12: Diagrama de proceso
El formato de la tabla de recogida de datos y análisis HAZOP de una sesión aplicado a la palabra
guía NO y a la perturbación NO FLUJO, sería como sigue:

39
ANÁLISIS DE OPERABILIDAD EN PLANTA DE DIMERIZACIÓN DE OLEFINA
Línea comprendida entre alimentación desde tanque intermedio a depósito regulador
Palabra
guía
Desviación Causas posibles Consecuencias Medidas a tomar
NO NO FLUJO 1. Inexistencia de
hidrocarburo en tanque
intermedio
Paralización del
proceso de reacción
esperado.
a) Asegurar buena
comunicación con el
operario del tanque
intermedio
Formación de polímero
en el intercambiador de
calor
b) Instalar alarma de nivel
mínimo LIC en depósito
regulador
2. Bomba J1 falla (fallo de
motor, circuito de
maniobra, etc.)
Como apartado 1 Cubierto por b)
3. Conducción bloqueada,
válvula cerrada por error o
LCV falla cerrando paso al
fluido
Como apartado 1 Cubierto por b)
Bomba J1 sobrecargada c) Instalar sistema de
desconexión automática
para protección de
bombas
d) Verificar el diseño de
los filtros de las bombas J1
4. Rotura de conducción Como apartado 1 Cubierto por b)
Hidrocarburo
descargado en área
adyacente a vía pública
e) Implantar inspección
regular de la conducción
mediante rondas
periódicas
Posteriormente se aplicarían otras palabras guía a otras variables del sistema.
Matriz de evaluación de los riesgos
Definiciones previas:
1. Análisis de riesgos: es el proceso formal que se realiza durante la vida del proyecto,
mediante el cual se identifican los factores de riesgo, se analizan y evalúan sus efectos y se
definen las acciones a seguir frente a los mismos, con el fin de disponer de una actuación
planificada con vista a minimizarlos.
2. Riesgo: es un evento probable cuya ocurrencia produce un daño a las personas, bienes
físicos, procesos y/o medio ambiente.
3. Consecuencias (C): mide el nivel o grado de severidad que pueden revestir los daños a las
personas, a los bienes y perjuicios por paralización de la producción, como consecuencia de
un incidente.

40
4. Exposición (E): el número de veces que el operador(es) se expone a un evento en un
período determinado. Una escala clasifica en forma cualitativa el número de veces que la
tarea está expuesta al evento, es ejecutada por cada persona o grupo de personas en un
determinado tiempo.
5. Probabilidad (P): dice relación con la frecuencia de ocurrencia del evento no deseado y se
expresa por medio de una escala de categorías que corresponden al nivel de frecuencias de
ocurrencias.
6. Magnitud del Riesgo (MR): es una medición que permite evaluar y jerarquizar el riesgo en
forma cuantitativa, en función de su Probabilidad (P), Exposición (E) y Consecuencia (C).
7. Matriz de Riesgo: es una matriz que permite relacionar los componentes (procesos,
equipos, instalaciones, insumos y suministros) o alternativas del proyecto versus los riesgos
operacionales.
Una vez que el grupo de trabajo ha identificado los eventos – riesgos que pueden afectar el
proceso o área, está en condiciones de iniciar la evaluación del riesgo y calcular su magnitud.
Magnitud del riesgo relacionado con personas: la magnitud del riesgo (MR) asociado son las
personas, se calcula utilizando las siguientes variables:
a) Consecuencias para las personas (C)
Clasificación Categoría Consecuencias
LEVE 1 Lesión(es) leve(s) no incapacitante(s)
SERIA
2 Lesión(es) incapacitante(s) temporal(es) y permanente(s)
parcial(es)
GRAVE
4 Perdida de la vida de un operador o incapacidad permanente
total
b) Estimación de exposición (E)
Número de veces exposición del operador al riesgo
Anual - Semestral Trimestral – Mensual Semanal Diaria
1 2 3 4
c) Estimación de la probabilidad (P)
Categoría Definición
1 Casi improbable que ocurra
2 Puede ocurrir alguna vez
3 Ocurre regularmente
4 Ocurre la mayor parte de las veces

41
d) Evaluación de la magnitud del riesgo (MR): la magnitud del riesgo permite clasificar el
riesgo a las personas, se manera de focalizar y priorizar las acciones correctivas que se
deben incorporar en las etapas de diseño de los proyectos y de control durante su
operación, con el fin de proteger a las personas y dar confianza a los sistemas.
Magnitud del riesgo MR = C * E * P
De esta manera se obtiene un ranking priorizado del inventario de riesgos a las personas en los
proyectos de inversión y el nivel de criticidad de la magnitud del riesgo.
Nivel de criticidad Rango (MR)
Grave 24 a 64
Serio 16 a 18
Leve 1 a 12
Magnitud del riesgo relacionado con los bienes físicos y medio ambiente: cada empresa que hace
el análisis define los márgenes de pérdidas.
a) Clasificación de las consecuencias (C)
Categoría Pérdidas entre (US$)
1 1 y 100.000
2 100.000 y 250.000
3 250.000 y 500.000
4 500.000 y 1.000.000
5 1.000.000 y más
En el caso que se esté aplicando en referencia al medio ambiente, las consecuencias se pueden orientar
como sigue:
1 Insignificante – mínimo impacto
2 Baja severidad – acción local
3 Mediana severidad – apoyo de otras áreas
4 Severa – compromete a toda la organización
5 Muy severa – se afecta la comunidad
b) Estimación de la probabilidad (P): dice relación con la probabilidad de ocurrencia del evento
no deseado, que tiene el potencial de producir daños a los bienes físicos y al medio
ambiente,

42
6 Se espera que ocurra al menos una vez al año.
Ocurre la mayor parte de las veces.
5 Se espera ocurra al menos una vez cada 3 años.
Ocurre regularmente.
4 Se espera ocurra al menos una vez cada 10 años-
Ocurre algunas veces.
3 Se espera ocurra al menos una vez cada 15 años.
Es raro que ocurra.
2 Se espera que ocurra no más de 1 vez en 25 años.
Ha ocurrido
1 Se espera que ocurra no más de 1 vez en 90 años.
Casi improbable que ocurra – se tiene conocimiento que ha ocurrido.
c) Evaluación de la magnitud del riesgo (MR): la magnitud permite clasificar los riesgos para priorizar
las acciones de control en las etapas de diseño de los proyectos.
Magnitud del riesgo MR = C * P
Para visualizar la clasificación se construye la matriz de gravedad del riesgo, utilizando la categoría
de la consecuencia y la probabilidad de ocurrencia del evento, como dimensiones de la matriz.
Probabilidad
6 6 12 18 24 30
5 5 10 15 20 25
4 4 8 12 16 20
3 3 6 9 12 15
2 2 4 6 8 10
1 1 2 3 4 5
1 2 3 4 5
Consecuencias
De acuerdo a la magnitud del riesgo se definen tres niveles de criticidad: grave, serio y leve, según
los rangos que se muestran a continuación:
Nivel de criticidad Rango MR
Grave 15 a 30
Serio 5 a 12
Leve 1 a 4
Matriz Gravedad Riesgo

43
De esta manera, conociendo el nivel de criticidad de los riesgos identificados, se obtiene un
inventario priorizado de los riesgos a los bienes físicos y al medio ambiente del proyecto de
inversión en análisis.
Medidas de control: el análisis debe concluir en su primera fase con recomendaciones destinadas
a:
a) Eliminar el riesgo que puede afectar a las instalaciones o proceso.
b) Minimizar los efectos de los riesgos desencadenados.
c) Aplicar medidas de control de riesgos.
d) Establecer planes de emergencias y de contingencias.

44
DESARROLLANDO UN ANÁLISIS DEL MODO DE FALLA Y EFECTO (FMECA)
OBJETIVO DEL FMECA
El análisis del modo de falla, efectos y análisis de criticidad (FMECA) es una función esencial en el
diseño, desde el concepto hasta el desarrollo. Para ser efectivo, el FMECA debe ser iterativo para
corresponder con la naturaleza propia del proceso de diseño. El grado de esfuerzo y de la
sofisticación del enfoque utilizado en el FMECA dependerá de la naturaleza y requisitos del
programa individual. Esto hace que sea necesario adaptar los requisitos de un FMECA para cada
programa. La adaptación requiere que, independientemente del grado de sofisticación, el FMECA
debe contribuir de manera significativa a la decisión del programa. Si el FMECA se realiza
correctamente es muy valioso para aquellos que son responsables de la toma de decisiones del
programa respecto a la viabilidad y la adecuación de un enfoque de diseño.
La utilidad del FMECA como una herramienta de diseño en el proceso de toma de decisiones
depende de la eficacia con la que se comunica la información para el problema para la fase inicial
de diseño. Probablemente, la mayor crítica del FMECA ha sido su uso limitado en la mejora de los
diseños.
Si bien el objetivo de un FMECA es la identificación de todos los modos de falla dentro de un
diseño del sistema, su primer objetivo es la identificación temprana de todas las posibilidades de
una falla catastrófica y crítica para que puedan ser eliminados o minimizados mediante la
corrección de diseño a la mayor brevedad posible. Por lo tanto, el FMECA debe iniciarse tan pronto
como la información de diseño preliminar está disponible en los niveles más altos del sistema y ser
extendida a los niveles más bajos a medida que más información está disponible en los productos
en cuestión.
Aunque el FMECA es una tarea esencial de la confiabilidad, también proporciona información para
otros fines. El uso de la FMECA se usa también en la mantenibilidad, análisis de seguridad,
supervivencia y vulnerabilidad, análisis de apoyo logístico, análisis de plan de mantenimiento, y
para la detección de fallas y aislamiento en el diseño del sistema. Este uso coincidente debe ser
una consideración en la planificación del esfuerzo FMECA para evitar la proliferación de requisitos
y la duplicación de esfuerzos dentro del programa contractual
DEFINICIONES
a. Modo de Falla – Una forma particular en que un elemento falla, independiente de la razón
de la falla.
b. Análisis del modo de falla y de efectos (FMEA) – Un procedimiento por el cual se analiza
cada modo de falla posible de cada elemento desde un nivel de jerarquización más bajo al

45
más alto para determinar los efectos en el sistema y para clasificar a cada modo de falla
potencial de acuerdo con la gravedad de su efecto.
c. Niveles de partición - La jerarquía de los niveles del equipo desde la parte al componente
del subsistema en el sistema, etc.
d. Redundancia - Más de un medio independiente para realizar una función. Hay diferentes
tipos de redundancia, incluyendo:
a. Operacional – Ítems redundantes, que se activan durante el ciclo operativo, incluye
sobre-carga, en donde elementos redundantes se conectan de una manera tal que,
si falla un elemento, el otro seguirá desempeñando la función. No es necesario
desconectar el elemento en falla o cambiar hacia la redundancia.
b. Standby - Los elementos no funcionan (no tienen ninguna potencia aplicada) hasta
que se conmuta en caso de falla del elemento primario.
c. Redundancia – Ítems idénticos realizando la misma función.
d. Redundancia con diferencia - ítems no idénticos realizando la misma función.
ALCANCE
Las reglas típicas básicas para un FMECA se formalizan junto con un resumen de la técnica,
objetivo, instrucciones paso a paso, las hojas de ejemplo de trabajo, y las entradas de trabajo de
las hojas de datos. Para proyectos específicos, por supuesto, añadir, eliminar y ajustar de otro
modo los procedimientos para cumplir con sus necesidades, los objetivos y los requisitos
contractuales. Esto es particularmente importante en los problemas de seguridad o los métodos de
solución operativa. Aunque el software de análisis está fuera del alcance de un FMECA, los efectos
de los modos de falla en el software y las interfaces de hardware-software deben ser incluidos.
OBJETIVO DEL FMECA
El objetivo de un FMECA es identificar las formas como podrían ocurrir fallas (modos de falla) y las
consecuencias de las fallas en el rendimiento del equipo (efecto de falla) y las consecuencias sobre
objetivo del equipo (asignación de gravedad). Se basa en el caso habitual en el que efectos de la
falla, que se expresan a nivel del sistema, son causados por los modos de falla del equipo a niveles
más bajos. El presente procedimiento, no cuantifica la probabilidad de ocurrencia de la falla, sino
que una evaluación cualitativa de los efectos de la falla se obtiene mediante la asignación de los
modos de falla a una categoría de gravedad.
Los resultados de los análisis se utilizan para mejorar el rendimiento del sistema mediante el inicio
de las medidas correctivas, por lo general no sólo con los cambios de diseño, sino que también son
útiles para centrar los procedimientos de garantía de producto y la identificación de las
limitaciones operativas. El FMECA se actualiza según sea necesario para incluir cambios en el
diseño y revisiones operacionales.

46
METODOLOGÍA
Usando la metodología bottom – up, el FMECA se inicia seleccionando el equipo en el nivel más
bajo de interés (por ejemplo, el módulo de componentes, circuitos, partes). Los diferentes modos
de falla que pueden ocurrir para cada elemento en ese nivel se tabulan. El correspondiente efecto
de la falla, a su vez, se interpreta como un modo de falla en el siguiente nivel de funcionamiento.
Sucesivas Iteraciones dan como resultado en última instancia en la identificación de los efectos de
la falla hasta el nivel más alto del sistema. Es un proceso de inducción en síntesis.
ANÁLISIS PRELIMINAR DEL SUBSISTEMA
Durante la fase conceptual del desarrollo del sistema, cuando la información de diseño se limita a
diagramas de bloques, un "enfoque funcional" es apropiado para la identificación de problemas de
diseño. Las fallas se postulan para los subsistemas principales (los subsistemas también se puede
dividir en bloques de nivel inferior). Se evalúan los efectos y se realizan los cambios de diseño
conceptual según sea necesario. A las fallas detectadas se le asignan a un nivel de gravedad con
énfasis en las fallas catastróficas y crítica para los que se planifican posibles procedimientos de
solución.
EL ANÁLISIS DETALLADO DEL EQUIPO
El análisis detallado del equipo se lleva a cabo cuando los elementos del equipo, líneas de señales y
de energía han sido identificadas. Utilizando esquemas y planos de montaje, los modos de falla son
postulados y evaluados sus efectos. Los modos de falla se definen en la interfaz del componente,
basada en el conocimiento del diseño interno y se evalúan los efectos a nivel de componentes y
estos son levantados a niveles más altos del montaje de equipo. El nivel del equipo en el que
comience el análisis se incluye en la declaración del proyecto de trabajo, que por lo general
requiere de un análisis a nivel de componentes. El análisis a menudo se extiende al nivel de la
parte, según sea necesario, esto es especialmente cierto para las consideraciones de seguridad. A
nivel de parte, los modos de falla se define por las partes dentro de un componente y el efecto es
evaluado en la interfaz del componente.
MODOS DE FALLA
Se identifican todas las formas en que una falla puede ocurrir en el nivel de jerarquización del
equipo. Se postulan todos los modos probable, posible o creíble de una falla, que incluyen los
mecanismos de falla que se han observado históricamente y cuyos mecanismos se han descrito, de
acuerdo con el razonamiento de ingeniería. La identificación de los modos de falla se basa en el
conocimiento de los componentes, las especificaciones funcionales, requisitos de la interfaz,
esquemas o modos de falla de las piezas o partes asociadas a la interfaz. El análisis es realizado con
el propósito de detectar posibles fallas en la interfaz originadas dentro de la unidad.

47
Los modos de falla que se producen dentro de una unidad, ya sea eléctrico o mecánico, se
manifiestan en la interfaz con una de las condiciones de error siguientes:
a. Operación prematura.
b. La falla de funcionamiento en un momento determinado,
c. La falla de detener la operación cuando sea necesario.
d. Error durante la operación.
Categorías de severidad para los efectos de la falla
Para proporcionar una medida cualitativa de los efectos de la falla, a cada modo de falla se le
asigna a un nivel de severidad. Problemas de seguridad y el impacto a otros sistemas o su
propiedad se reflejan en la selección del nivel de gravedad.
El efecto de la falla se evalúa en primer lugar a nivel del equipo que se analiza, el nivel
inmediatamente el nivel superior, el nivel de subsistema, y sigue por el sistema o el nivel de la
misión. Para seleccionar el nivel de gravedad, la peor consecuencia de los casos,
teniendo en cuenta todos los niveles, se asume para el modo de fallo y efecto que se analiza.
Los niveles de gravedad se definen a continuación. Para proyectos específicos se puede requerir
definiciones ampliadas en función, por ejemplo, en la cantidad de degradación que es permisible
en función de datos científicos.
a. Categoría 1, Catastróficos - Los modos de falla que podrían resultar en lesiones graves o la
muerte, o daños al equipo.
b. Categoría 1R, Catastróficos - Los modos de falla de elementos idénticos o de equipos
equivalente redundantes que, si todos fallan podrían dar lugar a efectos en la Categoría 1.
c. Categoría 2, Crítica - Los modos de falla que podría resultar en la pérdida de uno o más
objetivos para el cual el equipo se adquirió tal como se define por la oficina del proyectos.
d. Categoría 2R, Crítica - Los modos de falla de naturaleza de elementos idénticos del equipo
o equivalente redundantes que podrían resultar en la categoría 2 si todos los elementos
fallan.
e. Categoría 3, Importantes - Los modos de falla que podrían causar la degradación de los
objetivos para el cual el equipo se adquirió o diseñó.
f. Categoría 4, Menores - Los modos de falla que podría resultar en pérdida insignificante
degradación de los objetivos para el cual el equipo se adquirió o diseñó.
EL PROCESO DEL FMECA
A continuación se presenta un procedimiento típico para llevar a cabo un FMECA. La serie de
tareas del ejemplo puede ser modificada de acuerdo con las necesidades operacionales de cada
proyecto y de los objetivos del equipo. El procedimiento se resume en la figura 13 y la siguiente
manera:

48
Fig. 13: Diagrama de flujo del FMECA
1. Definir el sistema a analizar. Una definición completa del sistema incluye la identificación
de las funciones internas y de la interfaz, el rendimiento esperado en todos los niveles
escritura, las limitaciones del sistema y las definiciones de falla. Todos los estados del
sistema y fases del objetivo no analizadas hay que dar razón de la omisión.
2. Indican la profundidad del análisis, identificando el nivel de jerarquización en la que se
inicia el análisis.
3. Identificar los requisitos específicos de diseño que se deben verificar por el FMECA.
4. Definir las reglas básicas y los supuestos en que se basa el análisis. Identificar las fases de la
misión del objetivo y el estado de los equipos durante cada fase del objetivo. Un conjunto
típico de reglas básicas (supuestos) a muestran a continuación:
a. Sólo un modo de falla existe a la vez.
b. Todas las entradas (incluyendo los comandos de software) para el ítem que se
analiza es el valores presentes y nominales.
c. Todos los consumibles están presentes en cantidades suficientes.
d. La Potencia nominal está disponible.
e. Todas las fases del objetivo son consideradas en el análisis; las fases del objetivo
que demuestran ser inaplicables pueden ser omitidas.
f. Los modos de falla de un conector se limitan a: conector en desconexión.
g. Se prestará especial atención dirigida hacia la identificación de las fallas individuales
que podrían causar la pérdida de dos o más rutas redundantes.
5. Obtener o construir diagramas de bloques funcionales y de confiabilidad indicando las
interrelaciones de los grupos funcionales, el funcionamiento del sistema, canales
independientes de datos, y las características de seguridad del sistema.
6. Identificar los modos de falla, efectos, detección de fallas y solución características y otra
información pertinente sobre la hoja de trabajo.

Analisis causa raiz y sus herramientas

Analisis causa raiz y sus herramientas

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Analisis causa raiz y sus herramientas

Similar a Analisis causa raiz y sus herramientas (20)

Último

Último (20)

Analisis causa raiz y sus herramientas