Lectura 6 - Foda

INSTITUTO PERUANO DE MANTENIMIENTO ESCUELA DE POST GRADO
Comité
Panamericano
de Ingeniería de
Mantenimiento
1
1 INTRODUCCIÓN ........................................................................................................ 3
1.1 Objetivos..................................................................................................................... 4
1.2 Cambio de paradigma ................................................................................................. 4
1.2.1 Problemas basados en reglas .............................................................................. 5
1.2.2 Problemas basados en eventos............................................................................ 5
2 METODOLOGÍA....................................................................................................... 10
2.1 Definición del problema ........................................................................................... 12
Comité
Panamericano 2.1.1 ¿Qué? ................................................................................................................ 12
de Ingeniería de
Mantenimiento
2.1.2 ¿Cuándo? .......................................................................................................... 13
2.1.3 ¿Dónde? ............................................................................................................ 13
2.1.4 Importancia ....................................................................................................... 13
2.2 Herramientas............................................................................................................. 15
2.2.1 Análisis de Cambios [3] ................................................................................... 16
2.2.2 Análisis de Barreras [3] .................................................................................... 17
2.2.3 Diagrama Causa/Efecto [1, 3-4] ....................................................................... 20
2.2.4 Análisis de Tareas [3] ....................................................................................... 24
2.2.5 Espinas de Pescado (Diagrama de Ishikawa Causa Efecto) [3,5-6] ................. 26
2.2.6 Árbol de Falla [3] ............................................................................................. 30
3 SOLUCIONES ............................................................................................................ 31
4 TRABAJO EN EQUIPO ............................................................................................ 31
5 REFERENCIAS ......................................................................................................... 33
2
1 INTRODUCCIÓN
El presente trabajo tiene como finalidad servir como material de apoyo en la aplicación de
las técnicas de Análisis Causa Raíz (ACR) a problemas enfocados desde el punto de vista
técnico aunque no es necesariamente excluyente para otros de diversa índole. El ACR se
fundamenta en la necesidad de resolver problemas, los cuales son generalmente entendidos
como una vicisitud que se desea vencer. En realidad, como se discutirá en el presente
trabajo, los problemas son enfrentados a través del control sobre las causas que los
originan. En muchos casos no es extraño encontrar que las “mejores” soluciones son
Comité
Panamericano generalmente las que no han sido vistas y que después de una breve reflexión parecen
de Ingeniería de
Mantenimiento
obvias, lo que conduce a hacerse la siguiente pregunta: ¿por qué no se me ocurrió a mí?.
Es a partir de la pregunta anterior que se procede a explorar muchas de las soluciones
efectivas que están en espera de ser “descubiertas” para un grupo particular de causas (a
veces numeroso). El proceso de descubrimiento requiere de un cambio de pensamiento
donde se debe abandonar el anterior, a esto se la ha llamado “cambio de paradigma” el
cual es el fundamento del ACR.
Existen en la bibliografía diversas técnicas y autores que han abordado lo que hoy recibe el
nombre de ACR, cuyo propósito ha sido el de buscar soluciones efectivas. Muchas
personas intuitivamente ya atacan problemas con la filosofía de pensamiento que involucra
ACR. Sin embargo, otros deben ser recordados de los procesos que involucra cuestionar
no sólo las ideas de otros sino las propias. Las metodologías utilizadas sirven este
propósito: recordar a los analistas de problemas que pasos se recomienda seguir y que
consideraciones deben tomarse para la obtención de soluciones efectivas. Como el lector
puede anticipar, no existen dos problemas exactamente iguales, sin embargo, dentro de un
marco de pasos generales que conservan cierta flexibilidad, se pueden establecer ciertas
reglas. Es en este punto donde juegan roles importantes las metodologías las cuales se
describen en el presente documento. Algunas intervienen en distintos pasos, otras abarcan
la totalidad del proceso.
La intención del presente documento es que sirva como material de apoyo e instructivo en
la aplicación de la(s) metodología(s) y forma parte de un taller para la formación de
facilitadores de la técnica de ACR. La aplicación de ACR es un trabajo de equipo y como
tal requiere de cierta pericia para vencer los paradigmas y encontrar causas y soluciones
3
efectivas. Con la información suministrada en este trabajo, el lector debe estar en la

capacidad de aplicar los métodos sin mayores dificultades.
1.1 Objetivos
Una vez leído el documento, el lector debe estar en la capacidad de:
• Mejorar la confiabilidad de los procesos a través del análisis de incidentes e
identificación de causas sistemáticas comunes.
Comité
Panamericano
de Ingeniería de
• Ser capaz de entender los conceptos de ACR.
Mantenimiento
• Ser capaz de definir un problema creando un panorama único basado en hechos.
• Entender las bondades y limitaciones de cada una de las herramientas.
• Reconocer las características fundamentales de soluciones creativas.
• Tener el conocimiento necesario para convertirse en facilitador de ACR
1.2 Cambio de paradigma

Existen muchos tipos de problemas y muchas formas para resolverlos. En muchos casos
los problemas han sido resueltos mediante la aplicación de reglas. Desafortunadamente, el
mundo está basado en eventos y en muchos casos estos no siguen reglas. La imposición de
reglas a problemas basados en eventos ha generado el espacio que hoy día ocupa la infame
ley de Murphy. Sin embargo, ACR ataca esa visión y reconoce que los problemas pueden
agruparse en estas dos categorías [1].
Considérese la siguiente afirmación, la cual es generalmente aceptada:
Un problema es generalmente entendido como alguna dificultad o situación que
requiere de una solución.
4
La oración anterior posa dificultades en función del tipo de problema del cual se esté
hablando. Para poder cuestionar la misma, considérense las siguientes definiciones:
1.2.1 Problemas basados en reglas

Como su nombre mismo lo indica, son aquellos basados en convenciones y reglas que
dictan una respuesta correcta única, como por ejemplo: la suma de dos números (2+2=4),
el “comerse” una luz roja (la regla establece que una persona que incurra en ello pudiera
ser multada), tres “strikes” para hacer un “out” en “base ball”, procedimientos escritos que
Comité requieren de un cumplimiento, etc. Está categoría es la que abarca la definición de
Panamericano
de Ingeniería de
Mantenimiento problema mostrada en el párrafo anterior.
1.2.2 Problemas basados en eventos

Son aquellos que dependen de las leyes causa y efecto donde existe más de una solución,
como por ejemplo: ¿cómo dirigirse a la casa de la abuela? (seguramente existe más de un
camino, o vía (carro, autobús, avión, etc.)), ¿cuál es la solución a la desnutrición?, ¿cómo
ganarse la vida?, ¿por qué falla una bomba?, ¿cómo prevenir accidentes?, etc.
Al ignorar las diferencias intrínsecas entre estas dos definiciones, se intenta resolver
problemas basados en eventos con soluciones que únicamente aplican a los basados en
reglas. Esta es una de las principales causas de la inefectividad de soluciones
implementadas. Ya tomado este punto, vale la pena mencionar algunas otras de las
características comunes en la resolución de problemas de la actualidad que evitan que
organizaciones e individuos busquen soluciones efectivas:
• El ignorar la definición del problema: como se verá más adelante, la definición del
problema es un parámetro importante dentro del análisis y en general siempre que se
presenta uno, se busca una solución inmediata sin detenerse en los eventos que los
causaron con suficiente detalle.
• El llenado de reportes y formatos: en el área técnica es de uso común la utilización
de listas de chequeo, llenar espacios en blanco y categorizar causas. Esta actividad, no
es en realidad particularmente mala, sino las características del formato, es decir, si
5
• éste no contempla todos los puntos que deben ser considerados en el análisis, la
información requerida puede ser pasada por alto.
• La utilización de narrativa y fábula: esta es una práctica común que entorpece la
búsqueda de información si se toman los relatos como hechos. Esto obedece a que la
información en muchos casos no posee la calidad necesaria. En general y salvo
específicas excepciones, los hechos son aquellos que pueden ser medidos y verificados.
En el proceso de recolección las narrativas y fábulas son importantes como guías pero
no como verdades hasta que puedan ser verificadas. Si la información no puede ser
Comité
Panamericano verificada, entonces el análisis pudiera estar incompleto además de que pudiese
de Ingeniería de
Mantenimiento
ocasionar que la solución implementada no sea la correcta. Para evitar lo anterior en
acciones futuras se recomienda que se tomen las previsiones necesarias para generar el
mecanismo que permita medir en caso de que ocurra nuevamente una eventualidad.
En este caso vale la pena mencionar el paradigma de productividad [2]:
Para mejorar productividad, se debe gerenciar,

para gerenciar efectivamente, se debe controlar,
para controlar consistentemente, se debe medir,
para medir con validez, se debe definir,
para definir precisamente, se debe cuantificar
Para reforzar estos conceptos, considere el siguiente ejemplo:
Ejemplo Típico de un Reporte de un Incidente
Fecha del incidente: 10/28/94 Hora: 0817 Fecha del reporte: 1/7/95 Unidad: Oeste
Miembros del Equipo: LCT, JMG, JLG, JAS, MST, MAM
6
Descripción del incidente:

En Octubre 28, 1994 un empleado de una contratista (FCT) se encontraba conduciendo
una inspección de rutina en un ascensor (ELH-23) en TCH-3-675 cuando ocurrió una
descarga eléctrica. El electricista de FCT necesitaba chequear la puerta del motor y los
interruptores que se encontraban en la parte superior del ascensor, requiriendo que el
mismo se mantuviera con electricidad en esta difícil actividad de mantenimiento. Cuando
esto se efectuaba, un mensajero de la oficina de correos (CMR-3) presionó el botón de
llamada del ascensor desde el primer piso ignorando la señalización de fuera de servicio
Comité
Panamericano ubicado sobre el panel de botones de llamada. El electricista de FCT oyó una alarma y fue
de Ingeniería de
Mantenimiento
capaz de apartarse de las partes del motor ubicadas en la parte superior del elevador antes
de lesionarse, pero un accidente pudo haber ocurrido. El electricista fue capaz de controlar
el ascensor desde la parte superior del mismo, lo que le permitió pararlo y salirse sin
mayores eventualidades. El fusible principal se quemó y el ascensor se detuvo.
Debido a las múltiples partes envueltas en este accidente, se han efectuado extensas
discusiones y la gerencia ha visitado el sitio para participar en ellas. Esto ha causado algo
de retraso.
Tipo de Falla:
Esperada Falla Falla por daño secundario Otra X
Descripción de la Causa:
Una reunión fue sostenida en Noviembre 30, 1994 en el lugar donde ocurrieron los hechos.
EL electricista de FCT que participó en el incidente proporcionó información de las
acciones paso a paso antes de efectuar la actividad de mantenimiento. La investigación
concluyó con que el problema era un error humano y que se deberían tomar acciones para
prevenir la recurrencia de este problema nuevamente.
Acciones Correctivas:
1. Proveer re entrenamiento a todos los empleados realzando la importancia de señales de
prevención.
7
2. Incluir mejores contactos y puentes para medir contactos eléctricos.

3. Revisar planos eléctricos para mostrar el circuito completo de los controles del
ascensor.
4. La posición de los interruptores ha sido ordenada para monitorear la longitud del cable.
Con el cumplimiento de estos cambios, el problema no ocurrirá nuevamente.
Causa Raíz: Repuesto defectuoso
Comité
Panamericano Aprobado: BLB Firma:
de Ingeniería de
Mantenimiento
Existen varias observaciones que deben resaltarse con respecto al ejemplo anterior, entre
las más resaltantes se encuentran:
Descripción del Incidente: Utiliza la narrativa en forma secuencial para establecer como
ocurrió el problema. Establece claramente que la culpa fue del cartero quien ignoró la
señal de “fuera de servicio” del ascensor.
Tipo de Falla: Se utilizan cuatro categorías (confusas, ej. ¿qué es una “falla esperada”)
donde el tipo de falla observada no clasifica en ninguna de tres de las cuatro mostradas
sino en “otra”. Claramente, una mala categorización de tipos de falla.
Descripción de la Causa: Existe una diferencia grande entre la fecha del incidente y la del
reporte. Únicamente se describe la información suministrada por el mantenedor
(electricista) sin tomar en cuenta la versión del cartero.
Acciones Correctivas: Se enumeran cuatro que no necesariamente resuelven algo, ya la
causa no ha sido debidamente identificada. Es posible que para alguien experto en el
mantenimiento de ascensores reconozca con facilidad alguna de las acciones correctivas.
Causa Raíz: Totalmente en desacuerdo, ya que reponiendo el “repuesto defectuoso” no
prevendría la recurrencia de la falla, cualquiera que esta fuera.
Del ejemplo anterior también pueden deducirse tres aspectos resaltantes y que son
comunes en las dificultades enfrentadas a la hora de resolver problemas. El primero,
corresponde a la creencia de que todos ven las cosas como uno las ve. Esto sin duda
8
alguna, es una práctica común que impide que la información fluya en ambas direcciones,
o mejor aún se cita la fórmula de productividad en la comunicación como ejemplo
ilustrativo [2]:
oir
Pr oductividad =
hablar
De la ecuación anterior, se deduce que la productividad depende prácticamente en saber

oír y tratar de entender a otros con un mínimo de intervención.
Comité
Panamericano
El segundo punto a mencionar está relacionado con que la percepción del mundo varía de
de Ingeniería de
Mantenimiento acuerdo al individuo, lo que hace psicológicamente imposible que dos personas tengan
exactamente el mismo punto de vista. Para ilustrar este punto recordemos por ejemplo la
lectura de un libro, digamos “Doña Bárbara” de Rómulo Gallegos. Al leerlo, cada lector
se hace una imagen mental de los personajes y del lugar donde se desenvuelven los
hechos.
La interpretación particular, de por ejemplo, las características de la hacienda dependerá
del nivel de conocimiento que tenga una persona acerca de haciendas per se. Es decir, un
individuo que haya visto una hacienda en Mérida, no identificará exactamente los mismos
elementos de otra persona que haya visto una que esté ubicada en Valle de la Pascua. Por
eso al leer el libro, cada quien se forma una imagen o “story board” de la trama. Esto es
tan cierto que en guiones de cine, televisión y teatro, es el director quien reúne a los
actores y les informa del “story board” y del “setting” para que todos tengan en mente la
misma imagen, y puedan interpretar los roles acorde a lo concebido por éste.
Por último, existe un problema al referirse al “sentido común” de una persona y convertir
las percepciones individuales en realidades. El sentido común varía entre las personas y la
cultura. Para citar un ejemplo, el sentido común de la mayoría de los comerciantes y
vendedores de comida en el Estado Zulia, añaden a un gran número de sus platos salsa
rosada como aderezo, es algo intrínseco y no esperan menos. Si un zuliano, se traslada a la
capital espera exactamente lo mismo cuando va a comer en la calle, por lo que pudiera
atribuir el atropello a la falta de sentido común (este ejemplo es real). Con respecto a las
percepciones, aunque no son malas del todo (por lo menos en el proceso inicial en la
9
búsqueda de soluciones) hay que tomar unos pasos más para avanzar y convertirlas en
hechos, los cuales por definición son posibles de medir y verificar.
Todos los factores discutidos anteriormente, inciden negativamente en la efectividad de las
soluciones de problemas ya que la definición del problema está incompleta (creencia de
que todos vemos lo mismo), las relaciones causa/efecto entre hechos se desconocen
(utilización de narrativa tipo fábula y mala categorización) y a que el problema busca una
solución inmediata sin detenerse en detalles o análisis (búsqueda de la solución favorita y
con prejuicio).
Comité
Panamericano
de Ingeniería de
Mantenimiento
10
2 METODOLOGÍA
Antes de abordar la descripción metodológica, es necesario hacerse la siguiente pregunta:
¿y cómo pueden resolverse los problemas efectivamente?. De acuerdo con una de las
referencias [1] deben tomarse cuatro pasos consecutivos sencillos tal como se muestran en
la Fig. 1: Definición del problema, análisis del problema, identificación de soluciones e
implementación de las mismas.
Analogía
Sospechosos, autopsia, confesión,
Comité Crimen y evidencia enjuciamiento, juicio
Panamericano
de Ingeniería de
Mantenimiento
Definición del Efectuar análisis del

Problema problema (ACR)
Identificar
Implementación
soluciones
de soluciones
efectivas
Deliberación Sentencia
Fig. 1. Los cuatro pasos para la resolución de problemas
En la misma figura también se indica el paso generalmente seguido cuando se cree haber
definido un problema (identificar soluciones sin un análisis detallado del mismo). Los
cuatro pasos también pueden relacionarse con cuatro elementos presentes en un juicio los
cuales guardan ilación y secuencia, es decir: un crimen y la evidencia, el proceso de
análisis de la misma (juicio), la deliberación de jurado en función del análisis (soluciones)
y la sentencia (implementación). En este caso es el equipo natural de trabajo (jurado) es
quien delibera y argumenta en función de la información que tiene a la mano (ver por
ejemplo la película “doce hombres en pugna” (en inglés: “12 angry men”)).
11
2.1 Definición del problema

Antes de abordar la definición del problema hay que reflexionar acerca de los siguientes
puntos:
• ¿Qué es un problema?
• ¿Fallamos al definir problemas?
• ¿Todos vemos el problema igual?
• ¿Hemos definido problemas en términos de nuestra realidad?
• ¿Tenemos experiencias distintas y profesiones?
Comité
Panamericano
de Ingeniería de • ¿Entendemos nuestra ignorancia y prejuicios?
Mantenimiento
• ¿Trabajamos en el problema equivocado?

• ¿Trabajamos en los síntomas o en las causas?
Para definir apropiadamente un problema un equipo de trabajo debe responder cuatro
preguntas básicamente:
• ¿Qué?: ¿Qué fue lo que ocurrió?
• ¿Cuándo?: ¿Cuándo ocurrió?, aquí no solo se incluye la fecha y la hora sino también
el contexto.
• ¿Dónde?: ¿Dónde ocurrió el problema?, aquí se agrupan las instalaciones y permite
visualizar si hay diversos problemas en sub grupo.
• ¿Importancia?: Lo que representa el problema en impacto al ambiente, personas,
daños económicos, etc.
Las siguientes preguntas no deben efectuarse durante la definición del problema:
• ¿Quién?: El objetivo del análisis es la prevención y no la búsqueda de un culpable.
• ¿Por qué?: No aplica en la definición sino en el análisis del problema.
• ¿Cómo?: No aplica en la definición sino en el análisis
2.1.1 ¿Qué?
El “qué” es el efecto primario, es lo que quiere evitarse o controlarse. Durante la primera
sesión un equipo dedicado a resolver un problema discutirá para definir el problema y
diferentes puntos de vistas relucirán como consecuencia. No hay que detenerse a elegir
12
cuál de todos los problemas planteados es el correcto, cuándo se empieza a “armar el

rompe cabezas”, generalmente se encuentra cuál es de los efectos es realmente el primario.
Cabe resaltar que puede haber más de un efecto primario y es en este punto dónde hay que
hacerse la pregunta ¿por qué? para correlacionarlos (lo cuál forma parte del análisis per
se). El efecto primario es el punto de partida y es dónde se comienza a preguntar ¿por
qué?. Así mismo, no es universalmente conocido por todos los miembros del equipo y
depende de cada perspectiva individual. Algunos ejemplos de “¿qué?”: la falla de una
bomba, pérdida de producción, retraso al llegar al trabajo, etc.
Comité
Panamericano
de Ingeniería de
Mantenimiento
2.1.2 ¿Cuándo?
En este punto hay que establecer la fecha y el tiempo y la exactitud de dicha información.
A veces es importante el control preciso del tiempo como en plantas y sistemas
automatizados, esto por su puesto dependerá del caso. También se refiere al contexto,
como por ejemplo si la falla ocurrió en el arranque de un sistema. Ejemplo de “cuándo”:
El 28/07/1998 a las 4:32 PM, después del arranque del sistema.
2.1.3 ¿Dónde?
Precisa la ubicación del problema. En este segmento hay que ser específico para prevenir
confusiones. Ejemplo de “dónde”: Estado Zulia>División Occidente>Lago de
Maracaibo>Plantas Compresoras de Gas>Planta TJ1>Sistema de Compresión>Cadena
A>Bomba DC1.
2.1.4 Importancia
El rubro de Importancia dentro de la definición debe responder la pregunta: ¿por qué
estamos trabajando en este problema?. El segmento de importancia ayuda a priorizar los
incidentes. Es también posible que un incidente pequeño por si solo tenga poco impacto.
Sin embargo, si su frecuencia es alta la historia es otra. En esta sección deben incluirse los
objetivos de la organización y del negocio, debe ser medible. Ejemplos de “Importancia”:
Seguridad: No hubo heridos pero pudo haber; Ambiental: Viola las regulaciones del
Ministerio de Ambiente; Producción: Paro de planta no programado de 4 horas, se
13
producen 3000 Bls/h y se procesan 400 MMPCD; Mantenimiento: costo de materiales

3000 US$ y labor 1000 US$; y Frecuencia: 2 veces en 1998, 7 en 1997.
Lea cuidadosamente el texto que se muestra a continuación y defina el problema en la
tabla anexa:
Ejemplo típico de una definición de un problema

Después que Juan y Pedro finalizaron la instalación, ambos se encontraban a 5 metros de
donde se encontraba el equipo. El cuarto de control arrancó el equipo remotamente. El
equipo empezó a hacer mucho ruido. Mientras que Juan trataba de diagnosticar el
Comité
Panamericano
de Ingeniería de problema acercándose a la máquina, se escuchó una explosión seguida por la destrucción
Mantenimiento
inmediata de un acoplamiento de seguridad. Un pedazo del acoplamiento golpeó a Pedro

justo en su cadera. Perforó la piel y fue llevado al servicio médico. No hubo ningún otro
herido. El equipo se había atascado debido a un tapón (“slug”) de líquido que pasaba por
la máquina. Las líneas de entrada no fueron desalojadas adecuadamente después de la
reparación. La reparación de la máquina tiene un costo equivalente al del reciente re
acondicionamiento. El costo de re acondicionamiento es de 125.000 US$ incluyendo
sobre tiempo. Esta falla es la segunda de este tipo en los últimos 7 años. La parada
inmediata de la planta causó que un mechurrio se activara por 35 minutos. Esto fue
reportado al ministerio de ambiente. La planta estará sin trabajar por 3 semanas mientras
se completa el trabajo. El producto está bajo en inventario lo que ubica el precio en 0,22
US$ por libra. La planta produce 250.000 lbs al día cuando se encuentra en su capacidad
máxima.
Qué:
Cuándo:
Dónde:
Importancia:
Seguridad:
Ambiental:
Producción:
Mantenimiento:
Frecuencia:
14
2.2 Herramientas
La presente sección muestra las diversas técnicas que pueden ser utilizadas en el proceso
de análisis una vez que los problemas hayan sido debidamente definidos. Las técnicas
(herramientas) se aplican en diversos pasos del proceso y no necesariamente existe una en
particular que garantice que cubra todo el análisis. Antes de continuar con la descripción
de las mismas es necesario en invertir unos minutos en describir lo que se está buscando.
En este documento (hasta el momento), no se ha emitido una definición de “causa raíz”
aún cuando el concepto se ha convertido en la actualidad en uno de uso común. Según la
Comité
Panamericano literatura [1,3-4] las definiciones pueden agruparse en las siguientes:
de Ingeniería de
Mantenimiento
• Se refiere a la(s) causa(s) más básica(s) que puede(n) ser razonablemente
identificada(s) y que la gerencia tiene control para prevenir.
• La razón más básica para una falla, problema, deficiencia que si es corregida
prevendrá la recurrencia.
A simple vista, la primera definición parece engorrosa y complicada, de hecho, la
definición más común es la segunda. Sin embargo para entender el concepto de causa raíz
consideremos el triángulo de fuego mostrado en la Fig. 2. Para que exista un fuego deben
combinarse simultáneamente los tres factores: una fuente de calor, un material combustible
y una fuente de oxígeno. Si alguno de estos tres elementos se encuentra ausente en un
momento dado, un fuego no ocurriría. Es decir, existen al menos tres causas simultáneas
para que un incendio sea generado. Aplicando las definiciones (a) y (b) nos damos cuenta
que la segunda queda completamente descartada, porque no existe una causa raíz única
sino tres. Todas pueden ser controladas y la ausencia de alguna de ellas evitaría un
incendio. La definición (a), aunque un poco más compleja, incluye a las tres causas. Sin
embargo, habla del término “razonable” el cual pretende indicar que ésta esté dentro de
nuestros límites. Por ejemplo, una de las causas que un avión se caiga durante un vuelo es
la “el campo gravitacional”, pero la gravedad es difícil (note que no se uso el término
imposible) de controlar por lo que no es razonable hablar del término. El segundo punto
está relacionado con el primero nuevamente, ya que la gerencia de Avensa, por ejemplo,
no puede prevenir la acción gravitacional (por lo menos hasta ahora).
15
calor combustible
Comité
Panamericano
de Ingeniería de
Mantenimiento
oxígeno
Fig. 2. Triángulo de fuego
2.2.1 Análisis de Cambios [3]

El “Análisis de Cambios” no es más que la comparación entre dos situaciones una deseada
y otra con consecuencias indeseables. Vale hacerse la siguiente pregunta: ¿Qué es
diferente ahora que ocasiona que algo anteriormente exitoso ocurra mal?. La Fig. 3
muestra un esquema para efectuar el Análisis de Cambios para responder la pregunta
anterior y se resume en los siguientes pasos:
1) Evento con consecuencias indeseables:
2) Evento sin consecuencias indeseables
3) Comparación entre eventos
4) Identificación de diferencias
5) Análisis de diferencias
6) Determinación del factor causal
Para ilustrarlo se puede efectuar una tabla como la que se muestra a continuación. Cabe
resaltar que en el ejemplo el análisis se efectúa desde el punto de vista del equipo “A”.
16
Como se observa en la tabla, se listan en dos eventos las diferencias que pudieron haber
ocasionado el incidente. Así mismo se evalúan los cambios y cuál fue el impacto. En el
ejemplo se listan las diferencias entre los encuentros, las horas a las cuales se efectuaron,
la iluminación, los jugadores presentes, los lanzadores, etc. Este ejemplo es real y de
utilidad para llevar estadísticas como ocurre en el “base ball”.
Entre las ventajas y desventajas de esta técnica encontramos lo siguiente:
• En los comienzos de una investigación, los factores causales pueden ser difíciles de
identificar. El Análisis de Cambios ayuda al analista de problemas a comenzar a
Comité
Panamericano recolectar información.
de Ingeniería de
Mantenimiento
• El Análisis de Cambios resalta diferencias entre escenarios con y sin error, además e
que es adecuada para condiciones relativamente simples. Es importante resaltar que
esta técnica pudiera no identificar cambios que ocurren en períodos de tiempo largo
(como el desgaste de un rodamiento).
Análisis de Cambios
1. Identificación de 2. Identificación de
3. Compare las
un evento con un evento similar
dos actividades
consecuencias sin consecuencias
indeseables indeseables
6. Identifiación de
5. Analice las que acción
4. Compare las diferencias que específica ocasionó
diferencias afectan las la consecuencia
consecuencias indeseable
Fig. 3. Pasos a seguir durante el Análisis de Cambios
2.2.2 Análisis de Barreras [3]

Esta herramienta se refiere a la identificación de barreras inexistentes o a aquellas que
han sido violadas lo que permite que exista un peligro o la amenaza de que ocurra un
accidente a aquello que desea protegerse. En general, Análisis de Barreras evalúa peligros
que pueden causar daños, personas u objetos que son vulnerables a peligros, ausencia de
barreras y controles entre otros. Existen varios tipos de barreras:
17
• Las que promueven buen diseño, identificación, instrucciones y procedimientos.
Tabla 1. Ejemplo de Análisis de Cambios

Descripción del evento: Dos equipos de base ball infantil A y B se encontraron en dos ocasiones, uno
el viernes donde A derrotó a B 11 por 5 y otro el sábado siguiente donde B derrotó a A 10 por tres
Evento 1 Evento 2 Cambio Impacto
8:00 PM viernes 8:00 AM sábado Horario más temprano Jugadores cansados
Iluminación Iluminación natural Diferencia de Jugadores más cansados
Comité artificial (sol) luminosidad El equipo B es más efectivo
Panamericano
de Ingeniería de
Mantenimiento Pitcher derecho: Pitcher zurdo: Pedro Diferente pitcher con Pedro
Juan Nuevo bateador
El line up se
mantuvo
• Las que previenen acciones erróneas y hacen físicamente imposible hacer algo
inadecuado (dispositivos de seguridad).
• Las que desaniman como avisos y símbolos, instrucciones durante reuniones de
trabajo.
• Las que detectan acciones erróneas como listas de chequeo, inventarios, balance de
masa, rondas de operadores y el método PPAR (Pare-Piense-Actúe-Revise).
• La Fig. 4 muestra los tres pasos a seguir para aplicar el análisis de barreras.
A n á lis is d e B a rre ra s
1 . S e d e fin e u n 2 . S e in v e s tig a la 3 . S e id e n tific a n la s

s e c u e n c ia d e h e c h o s b a rre ra s in e fe c tiv a s
p ro b le m a y u n
q u e o c a s io n a ro n e l q u e lo o ca s io n a ro n
o b je tiv o
p ro b le m a
C u e stio n a rio /”ch e ck list”
Fig. 4. Pasos a seguir durante el Análisis de Barreras
18
Para identificar como funciona la herramienta veamos el ejemplo de la Tabla 2. En la

misma se identifica un “sujeto” que no es más que lo que se quiere proteger (en este caso
un niño) y se identifica un peligro (en este ejemplo un carro). Aunque no se conocen los
detalles del problema es evidente que está relacionado con alguna actividad de tránsito
(peatonal).
Tabla 2. Ejemplo de Análisis de Barrera

Peligro Barrera Causas Sujeto
Comité
Panamericano Carro Acera No cruzó en la acera Niño
de Ingeniería de
Mantenimiento
Luz de cruce Bombillo quemado
Entrenamiento Niño sin
entrenamiento
Certificación del Sin licencia
conductor
Así mismo, se listan las barreras existentes que evitarían que un niño fuera arrollado por
un carro. Por ejemplo, la acera es una barrera que evita que un carro arrolle al niñi. Así
mismo, la luz de cruce le indica a otros conductores y peatones acerca de la maniobra, sin
embargo, si la luz está quemada o el conductor falla al utilizarla, pudiera haber un
accidente. Un niño también recibe entrenamiento acerca de las normas peatonales, si éste
las desconoce entonces pudiera ocurrir un accidente.
En general, es mejor tener pocas barreras que sean efectivas que tener muchas barreras que
sean medianamente efectivas. Para solventar lo anterior, los siguientes pasos deben ser
tomados en cuenta para el análisis de barreras: diseño, dispositivos de seguridad, avisos de
peligro, procedimientos, entrenamiento, y notificación a la gerencia de riesgos.
El análisis de barreras es particularmente de utilidad para fallas que no son frecuentes pero
tiene la desventaja que si la persona que efectúa el análisis no reconoce todas las barreras,
peligros y/o sujetos el análisis estaría incompleto (existen muchas barreras implícitas en
diseño que son difíciles de identificar).
19
En muchos casos una barrera que falle no es necesariamente un a causa raíz, el analista
debe ir más allá de la barrera para determinar las razones (causas) de la falla (como en el
ejemplo del reporte del cartero que actuó el ascensor).
2.2.3 Diagrama Causa/Efecto [1, 3-4]

Esta técnica es de amplio uso en la búsqueda de soluciones en el Análisis Causa Raíz. Así
mismo existen variantes de la misma. Sin embargo, no debe ser confundida con el
Comité diagrama de Ishikawa (“espinas de pescado” (Fishbone charts)) aunque en algunos textos
Panamericano
de Ingeniería de
Mantenimiento es referido con el nombre de Causa/Efecto [5,6] ya que este por sí mismo es una
herramienta que será discutida posteriormente.
El diagrama Causa/Efecto (excluyendo el de Ishikawa), en la esencia de todas sus
versiones, provee una representación “pictórica” de todas las causas en el tiempo
guardando la secuencia de las actividades que condujeron a una falla o problema. Los
diversos nombres con que ha sido identificado son: Diagrama Causa/Efecto [1], Diagrama
Evento y Factor Causal [3] y Línea de Tiempo [4]. De las tres versiones la más sencilla es
la propuesta por Apollo RCA, ya que requiere del menor número de reglas para su
aplicación.
El principio del diagrama se basa en que causas y efectos son lo mismo pero vistos desde
perspectivas diferentes. Una vez que se ha definido el problema y que se conoce el efecto
principal, uno empieza a preguntar ¿por qué? al efecto y nos respondemos con causas. Los
efectos se convierten en causas a medida que se pregunte ¿por qué? de tal manera que se
tiene una cadena. Por ejemplo, una lesión es causada por una caída, y la caída es causada
por una superficie húmeda o una válvula que gotea, lo cual es causado por mantenimiento
inadecuado. En este problema se ha identificado un efecto principal (lesión) y a través de
las relaciones entre causas y efectos se pueden identificar la soluciones a la causa(s) raíz
(ces) como mejorar el programa de mantenimiento de las válvulas (evitaría el goteo de la
válvula y por ende la lesión). La Fig. 5 muestra como se construye un Diagrama
Causa/Efecto.
20
Esquemas Causa/Efecto
Causa acción
Efecto principal
Causa condición
Causado
por
Comité
Panamericano
de Ingeniería de
Causa condición
Mantenimiento
Causa condición
Fig. 5. Pasos a seguir en el Diagrama Causa/Efecto [1].
Pasos a seguir para la aplicación de la herramienta:

• Se define un problema y se ubica un efecto primario. Puede existir más de un efecto
primario, sin embargo como se verá en un ejemplo, la dinámica de la herramienta
ayuda a establecer cuál es el más general.
• Al efecto primario se le hace la pregunta ¿por qué? y se listan todas las causas posibles
(aún aquellas que parezcan obvias). Existen dos tipos de causas: acción y condición.
En el ejemplo del triángulo de fuego (Fig. 2) en el cual el “fuego” sería el efecto
principal, al preguntar ¿por qué ocurre un fuego?, la respuesta emite tres causas
(condiciones): oxígeno, combustible y calor. Sin embargo, las tres condiciones pueden
coexistir y aún no generarse un fuego ya que se necesita, por ejemplo, de que alguien
encienda un fósforo (causa acción).
• Se utilizan pasos pequeños entre causas. En general, mientras más complejo sea el
problema, se requiere de un nivel de detalle mayor.
La aplicación de esta técnica requiere de la utilización de evidencias para soportar cada
causa. Esto no implica que durante la elaboración del diagrama no se puedan utilizar
21
suposiciones, sino que deben ser comprobadas con instrumentos que permitan su medición
y verificación. La utilización de suposiciones puede llevar a soluciones inefectivas con lo
que el análisis estaría incompleto. Esto ha causado mucha inquietud entre los analistas de
problemas ya que no siempre se dispone de la evidencia, y a veces se hace muy difícil
comprobar con hechos. En estos casos se recomienda utilizar la intuición pero creando
mecanismos que en el futuro permitan medir para corroborar los supuestos.
Véase el siguiente ejemplo donde no se conocen los detalles de lo que ocurrió pero se
pueden inferir de la información y del diagrama hecho a partir de ésta.
Comité
Panamericano
de Ingeniería de
Mantenimiento
Qué: Pérdida de producción, horno fuera de servicio
Cuándo: 28/08/1998 en condiciones de operación normal
Dónde: División CA>Planta 5>Unidad 2>Horno H3D
Importancia
Seguridad: Sin accidentes
Ambiental: Sin impacto
Producción: Pérdida de producción, 1/7 de la capacidad
Mantenimiento: Materiales a 18000 US$, labor a 15000 US$
Frecuencia: 4 veces en 1997, 1 en 1998
El efecto principal es el “Qué”, en este caso pérdida de producción y horno fuera de

servicio (pudiesen haber más dependiendo de lo que haya decidido el equipo natural de
trabajo). Para identificarlo se hace la pregunta: ¿por qué hubo pérdida de producción? Y la
respuesta es: porque el horno se encontraba fuera de servicio. Así se comprueba que el
efecto principal más general es la pérdida de producción y que incluye a que el horno esté
fuera de servicio (véase Fig. 6).
22
Efecto principal c c c
Pérdida de cp Horno fuera cp Pérdida de cp No había flujo cp

producción de servicio aceite en horno de aceite
Datos del computador
A
c a a
Caudal aceite cp Medidor de flujo cp Válvula de purga
parecía OK media flujo positivo estaba abierta
Comité
Panamericano
de Ingeniería de Medidor de flujo Supervisor cerró válvulas de aceite Consenso de grupo
Mantenimiento
c a
cp
Línea tapada Depósitos
Medidor de flujo Observados

c
c a c
Varias
No se han sacado No siempre se Cónsola de
cp cp cp filas y
beneficios de han seguido válvulas está
colum. de
otras fallas procedimientos congestionada
Consenso de grupo Personal no notificó este Consenso de grupo
válvulas
problema
A Diseño en revisión
Fig. 6. Ejemplo de los pasos del Diagrama Causa/Efecto
En el diagrama aparecen identificadas las siguientes siglas: “cp” que indica causado por,
“c” que indica causa condición y “a” causa acción, así mismo debajo de algunas casillas
aparece de donde la fuente de información. El citado ejemplo se leería así: La pérdida de
producción fue causada por el horno fuera se servicio; el horno fuera de servicio fue
causado por pérdida de aceite en el horno; la pérdida de aceite fue causada por que no
había flujo (esto lo soporta la evidencia suministrada por los datos del computador), la
ausencia de flujo es debido a tres causas: porque el caudal de aceite parecía estar bien
(medidor de flujo) porque la línea estaba tapada (como lo indicó el medidor) y porque no
se han sacado beneficios de otras fallas (esto es por consenso). A cada una de las causas
anteriores se les sigue preguntando ¿por qué? y se siguen listando. Hay que hacer notar
23
que en el ejemplo de la Fig. 6 se ha incluido información que no califica dentro de la

categoría de hechos como la indicada en la casilla “no se han sacado beneficios de otras
fallas” y que está soportada por el consenso de grupo. Si bien es cierto que el análisis se
efectúa buscando el consenso del equipo este debe estar fundamentado en evidencia
(medible y verificable) no en creencias ya que pudiera conducir a la solución equivocada, a
resolver un problema inexistente. La calidad de los datos se muestra en la Fig. 7:
Buena calidad de datos

Comité
Panamericano
de Ingeniería de
Mantenimiento
Hechos: Preciso, exacto, medible y verificable
Inferencia: Deducción lógica basada en hechos
Suposición: Hipótesis lógica que de ser verdad explica hechos
Opinión: Intuición y experiencia
Creencia: Opiniones de otros
Rumor: Información de 2da, 3ra y 4ta mano
Adivinanza: Educada, salvaje, premonición
Fantasía: Sin base y distorsión
Mala calidad de datos

Fig. 7. Degradación de la calidad de la información.
2.2.4 Análisis de Tareas [3]

Esta técnica es utilizada para asistir al analista en el aprendizaje acerca de procesos en el
trabajo relacionados con el desempeño de las personas. El analista aprende cómo las
tareas (procedimientos) son efectuadas y como debían haber sido ejecutadas. El objetivo
es seguir y analizar los pasos de un procedimiento. En este caso se recomienda, dentro de
lo posible, que cuando se efectúe una revisión de procedimiento se haga en sitio mientras
el ejecutor efectúa la tarea, esto simplifica el análisis y permite incluir observaciones que
de lo contrario no serían incluidas dentro del nuevo procedimiento. La técnica se ilustra en
el ejemplo descrito en la Tabla 3.
24
Tabla 3. Ejemplo de Análisis de Tareas

Pasos del Procedimiento Análisis Preguntas y Conclusiones
1. Ubicar trampa de drenaje • Trampa de drenaje no • ¿Existe una política de
2. Despresurizar línea indentificada. identificación?
3. Verificación de • Medidor de presión más • ¿por qué el medidor está
despresurtización cercano a 50 pies. tan lejos?, ¿ha sido
4. Abrir válvula • El resto de las trampas modificado?
5. Llenar toma muestra tienen medidores cerca • Todos los pasos son muy
Comité
Panamericano 6. Cerrar línea de la toma de muestra. generales. ¿Cómo sabe
de Ingeniería de
Mantenimiento
7. Represurizar línea el operador cómo los
tiene que hacer?
Nótese que se hace una descripción del procedimiento en 7 pasos. Durante el análisis, se
identifican varios puntos de atención y finalmente se hacen las preguntas que deben ser
respondidas para poder modificar el procedimiento. El ejemplo ilustra claramente que los
pasos son muy generales y que requieren de un nivel de detalle mayor para evitar errores.
En muchos casos, se habla de escribir procedimientos “a prueba de tontos”.
En general los errores que involucran a personas surgen por que existen diferencias entre
las demandas del sistema y la capacidad humana. Así mismo, no existe el sentido de
pertenencia (“no me duele porque no es mío”) o porque el enfoque en la resolución de los
problemas se ha centrado en la política de buscar culpables, con la creencia que si son
removidos impiden la recurrencia de problemas. Con esta última aseveración no se
pretende eximir a personas que pudieran actuar irresponsablemente en un momento dado,
sino más bien reflexionar acerca del número de personas que violan reglas a priori. Como
ejemplo pudiéramos citar la población carcelaria de un país la cual refleja el número de
individuos que no obedece reglas y que están fuera del contexto social. La probabilidad de
que exista un operador, mantenedor, etc., que decida ejecutar una acción errónea con
premeditación es bastante baja, por lo cual los esfuerzos deben hacerse en la verdadera
búsqueda de soluciones y preguntarse ¿por qué ocurrió?
Para ilustrar la visión sistemática del error, refirámonos a la Fig. 8 [4].
25
Visión sistemática del error
Tendencias Ambiente que

al error no perdona
Errores
Signifi-
cativos
Comité
Panamericano
de Ingeniería de
Mantenimiento
Ambiente que
induce al error
Fig. 8. Visión sistemática del error [4].

Los errores significativos ocurren por la combinación de tres factores: tendencias al error
(es una tendencia humana), ambiente que induce al error (un diseño deficiente, por
ejemplo), ambiente que no perdona (la falla de un equipo que ocasione una súbita parada
de planta). Si al identificar problemas no se toman en cuenta estos factores, aún buscando
a un culpable los problemas persistirán independientemente del individuo que ejecute la
labor. Las preguntas que hay que hacerse en vez de ¿quién? Son: ¿Cómo disminuir
tendencias al error?, ¿Cómo puedo modificar el ambiente que induce y que no perdona el
error?
2.2.5 Espinas de Pescado (Diagrama de Ishikawa Causa Efecto) [3,5-6]

Es particularmente importante para la clasificación de causas en categorías definidas por
los miembros de un equipo. El diagrama se efectúa siguiendo estos pasos (ver Fig. 9 y
10):
1. Se define un efecto principal, esto es aquello que se desea mejorar o controlar.
2. Se escribe el efecto a un extremo de la espina principal.
26
3. Después se escriben las espinas secundarias (categorías) que pudieran estar causando el
efecto principal. Generalmente, se recomienda que todas las posibles causas sean
agrupadas en categorías, como por ejemplo: materiales, herramientas, inspección,
individuos, etc. También se habla de las cinco “M” (Máquina, Mano de obra, Medio
Ambiente, Método y Materia prima) [6].
4. En cada una de las ramas secundarias, se escriben los factores detallados que se
consideren causas. En este punto se pueden generar sub categorías (ramas terciarias,
etc.).
Comité
Panamericano La manera de construir las ramificaciones es haciéndose la pregunta ¿por qué? y al
de Ingeniería de
Mantenimiento
responder se colocan nuevas ramificaciones. Nótese que este diagrama se parece mucho al
Causa/Efecto, pero no mantiene una secuencia hilada en el tiempo de las causas como en
el caso anterior.
Espinas de Pescado
Equipos Procedimientos
Efecto
primario
Procesos Humanos/Sistema
Fig. 9. Diagrama de Ishikawa (Espina de Pescado, Causa Efecto Ishikawa).
Las espinas de pescado son excelentes para la recolección de datos y son ampliamente
conocidas en las aplicaciones de calidad.
27
Fallan bombas
Holgura inadecuada
Falta agua
Rotura lámina Corrosión Limo

Falta Mal armado de huecos Válvula Flujo de agua
Falta Cl2 Fuga Cl2 Acceso
cesta Falta tubos trancada discontinuo
riesgoso
Falla iny. Mal balance
Holgura excesiva
Cl2 de agua Válvula
Falla
clorinación Pericia sin volante
Pescados Caracoles Calibre tubos Dobladura lámina
Materia orgánica de huecos Corrosión
Externa Falta Apertura/Cierre
Material tubos Falla en rutina pericia de válvula
de inspección
Pelo de oso
Calidad del Diseño Falla Mecánica Mala Operación
Comité Falla
Agua Enfriador Caja
Panamericano
de Ingeniería de
Magnecida Fallas Enfriadores
Mantenimiento Atmosféricos
Calidad del Diseño Diseño de Caja Mantenimiento
Gas Vertedero Batea de Distribución Inadecuado
Alto CO2 Faltan canales Huecos muy Limpieza caja

de distribución Existen ángulos grandes de distribución
transversales Caja muy corta Láminas coralux
mal instaladas Desnivel
Patas sobresalen
Alto H2S Ubicación borde de caja Ventanas abiertas Caja de distribución
inadecuada Faltan huecos mal instaladas Posición
zona caliente Falta abertura en Faltan cestas
zona caliente bomba de levantamiento
Alto H2O Muy corta Existe parrilla bajo Limpieza lateral del enfriador
zona de huecos durante paro de máquinas
Fig. 10. Ejemplo de la aplicación de una espina de pescado [7]

Existe una variante de este diagrama propuesto por el japonés Nakahima [6] donde utiliza
la metodología denominada “Fenómeno de Mecanismo” a partir del diagrama de Ishikawa.
Nakahima ataca problemas de múltiples causas (policaústico) lo cual contrasta con el de
Ishikawa que estudia una causa a la vez sin estudiar las interelaciones que pudieran existir
con otras. Los pasos para la metodología son los siguientes [6]:
1. Definición del problema (efecto principal).
2. Efectuar Análisis de los principios físicos (causas) de los fenómenos. Los defectos
identificados deben ser traducidos a través de los principios físicos que lo describen
Comité
Panamericano (ej.: un defecto de centrifugado depende de la fuerza centrífuga (magnitud) y de la
de Ingeniería de
Mantenimiento
velocidad de giro) estos deben medirse y cuantificarse.
3. Definir las condiciones que producen el principio físico (causa). No es más que
investigar las posibles condiciones necesarias para producir causas. La causa no es
más que aquello que produce un defecto o fenómeno que guarda proporcionalidad o
semejanza con él y que se halla en los mecanismos. La condición no es más que el
(los) elemento(s) o circunstancias favorecedoras de la causa. En el ejemplo anterior,
varias condiciones propician la variación de la velocidad de giro de la centrífuga:
aflojamiento de las correas, tensión eléctrica, sobrecarga de sólidos, etc.
4. Definir los factores de una condición como las causas que pertenecen a una de las
categorías de la espina de pescado (ej. Las 5 “M”, Máquina, Mano de obra, Medio
Ambiente, Método y Materia prima). Los únicos factores del 5M que contribuyen a la
condición “aflojamiento de correas” son: anclaje y asentamiento (Máquina), falta de
vigilancia (Mano de obra) y humedad del tiempo (Medio Ambiente).
5. Investigar cada factor. Se establece un método de estudio para cuantificar cada factor
de la etapa anterior. En el ejemplo anterior, el factor de anclaje y asentamiento se
investiga midiendo cotas verticales, longitudinales, comprobando perpendicularidades.
6. Encontrar anormalidades específicas. Estas ya han sido identificadas para cada factor.
Sin embargo, es necesario buscar aquellas ocultas.
7. Establecer mejoras. Se busca respuesta (corregir) a todos los defectos seleccionados,
tanto evidentes como ocultos.
29
2.2.6 Árbol de Falla [3]

Esta técnica es la más compleja en términos de conocimiento ya que para un problema en
particular puede complicarse bastante. En muchos casos esta técnica es utilizada en forma
proactiva para dirigir al analista a modos de falla potenciales previamente identificados y
conocidos para un sistema. Una ventaja de esta técnica es que la experticia técnica no es
necesaria ya que las preguntas han sido generadas previo a la investigación. Sin embargo,
es conducida por eventos lo cual hace que el análisis se extienda. Esta técnica también es
Comité utilizada en el árbol lógico de decisión para Mantenimiento Centrado en Confiabilidad
Panamericano
de Ingeniería de
Mantenimiento (MCC).
La técnica se parece a la Espina de Pescado, pero incluye conectores lógicos del algebra
Booleana (“Y” (“and”) y “O” (“or”)). El árbol está compuesto de eventos identificados
como “inputs” y “outputs”. El evento principal se ubica en el tope y es el punto de partida
para el analista. El analista usa el árbol y sigue una ruta definida tan lejos como la
información disponible se lo permita, es en este punto donde el analista se hace la pregunta
de por qué no puede avanzar en el árbol. El analista trabaja hasta encontrar los últimos
eventos y a partir de ellos determina la(s) causa(s) raíz(ces).
El analista que desarrolle un Árbol de Falla debe asegurar un balance apropiado entre
comprensión, nivel de detalle y práctico para determinar fallas asociadas con componentes
o equipos, errores humanos, o cualquier modo de falla y mecanismo pertinente que pudiera
conducir a un evento no deseado. En general, tres reglas asociadas con el desarrollo de
Árboles de Falla:
1. Todos los eventos deben estar conectados por “puertas”.
2. No se permiten conexiones entre puertas
3. Debe existir un mínimo de 2 “inputs” por cada “output”.
Adicionalmente, existen cuatro pasos usando Árbol de Fallas:
1. El analista debe enfocarse en una falla en particular

2. Se deben determinar todos los posibles escenarios de falla
3. Las probabilidades de falla de cada escenario deben investigarse
30
4. Debe determinarse el camino crítico que conduce a la falla
El Árbol de Falla permite identificar causas relacionadas con equipos, errores humanos o
procesos. Así mismo, es de utilidad para buscar múltiples mecanismos de falla para un
mismo evento. Sin embargo, es relativamente complejo comparado con otras técnicas.
3 SOLUCIONES
Hasta el momento, se han descrito herramientas que permiten efectuar el análisis sin
Comité
Panamericano mencionar como deben ser las soluciones. Estas deben satisfacer los criterios definidos
de Ingeniería de
Mantenimiento
por el análisis y deben contemplar costos, facilidad de ejecución, responsables, etc. Otro
punto importante es que deben ser específicas, en general, la utilización de términos con
condición futura como: revisar..., analizar..., investigar..., son indicadores de análisis de
problemas incompletos. La búsqueda de soluciones requiere de creatividad y como tal,
esta idea se refuerza en el cambio de paradigma que se mencionó en la introducción donde
hay que pensar en forma no convencional.
Para mejorar el pensamiento hay que retar paradigmas como el sentido común, el
convencionalismo y creencias propias entendiendo que al reconocer ignorancia se abren
las puertas del entendimiento y de la creatividad. La sinergia de grupo es indispensable,
cuando alguien ofrece una solución, es recomendable fomentar discusión y oír con
detenimiento. En muchas ocasiones, alejarse del problema por un rato ayuda a
incrementar la creatividad ya que cuando es abordado nuevamente, se tiene la mente
“fresca”.
4 TRABAJO EN EQUIPO
Una de las partes más complejas durante la aplicación de la metodología es el trabajo en
equipo. Una vez que se ha constituido el mismo, se recomienda establecer ciertas reglas
para poder mantener la dinámica y llegar a resolver problemas. Los siguientes puntos
deben ser tomados en consideración:
• Establecer compromisos con propósitos y metas: esto debe establecerse desde el inicio
para mantener al grupo alineado con un norte común.
31
• Destrezas complementarias: la diversidad de opiniones y puntos de vista evita es sesgo

e incrementa la posibilidad de encontrar soluciones que satisfagan los criterios.
• Formar un equipo de hasta 7 personas: en general, mientras más grande el grupo, más
difícil se hace manejarlo. Así mismo, cuando existen numerosos miembros en un
grupo, se delegan responsabilidades en otros.
• Establecer responsabilidades y buscar apoyo mutuo: cada vez que se efectúen las
reuniones del análisis deben generarse compromisos para la próxima reunión. Para
ello, se recomienda discutir todos los puntos que deben ser analizados en la próxima
Comité
Panamericano
de Ingeniería de
reunión en forma de agenda, donde cada miembro conozca, una vez que se hayan
Mantenimiento
puesto de acuerdo, lo que tiene que hacer. En muchos casos, se requerirá de más de un
miembro para ejecutar una tarea.
• Recordar los compromisos manteniendo el enfoque común del trabajo: esto permitirá a
los miembros reorientarse en los momentos en que el grupo tiende a dispersarse.
También se recomienda al inicio de la conformación del grupo establecer normas. Si bien
es cierto, que en este punto debe ser discutido por cada grupo en particular, se
recomiendan las siguientes:
• Establecer el espacio de tiempo de la reunión y ceñirse al mismo.
• Abstenerse de llamadas telefónicas (incluyendo celulares).
• Buscar soluciones discutidas por consenso.
• Cumplir con las asignaciones y tareas.
• Respetar opiniones.
• Ser puntual.
• Participar en todas las reuniones (el ausente delega en los demás miembros la toma de
decisiones, tareas y asignaciones).
32
5 REFERENCIAS
1. Root Cause Analysis, Apollo Associated services, Friendswood, TX.

http://www.apollo-as.com.
2. J.L. Riggs, Productivity by Objectives, Prentice Hall, New Jersey (1983).
3. D.B. Fulbright, A comprehensive guide to root cause and program performance

Comité
Panamericano analysis, Copyright D.B. Fulbright 1997.
de Ingeniería de
Mantenimiento
4. J. Goodacre, Root Cause Analysis, Curso corto de la empresa consultora Woodhouse.
5. K. Ishikawa, Guide to Quality Control, Asian Productivity Organization, Second

Edition (1984).
6. C. Parra, ACR: Análisis Causa Raíz - Eficaz Herramienta de Mantenimiento,

Ingeniería de Mantenimiento, Universidad de los Andes (ULA), Septiembre 1999.
7. J.J. Perdomo, C.A. Boscán, C. Parra, M.C. Moreno, A. Barboza, J. Monsalve, J.

Sánchez, L. Torres, Análisis Causa Raíz de la Problemática de los Enfriadores
Atmosféricos de las Plantas Compresoras de Gas, PDVSA INTEVEP (2000).
33

Lectura 6 - Foda

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Lectura 6 - Foda

Cargado por

Copyright:

Formatos disponibles

INSTITUTO PERUANO DE MANTENIMIENTO ESCUELA DE POST GRADO

efectivas. Con la información suministrada en este trabajo, el lector debe estar en la

• Ser capaz de definir un problema creando un panorama único basado en hechos.

• Entender las bondades y limitaciones de cada una de las herramientas.

• Reconocer las características fundamentales de soluciones creativas.

• Tener el conocimiento necesario para convertirse en facilitador de ACR

1.2 Cambio de paradigma

1.2.1 Problemas basados en reglas

1.2.2 Problemas basados en eventos

Para mejorar productividad, se debe gerenciar,

Para reforzar estos conceptos, considere el siguiente ejemplo:

Ejemplo Típico de un Reporte de un Incidente

Miembros del Equipo: LCT, JMG, JLG, JAS, MST, MAM

Descripción del incidente:

2. Incluir mejores contactos y puentes para medir contactos eléctricos.

Causa Raíz: Repuesto defectuoso

De la ecuación anterior, se deduce que la productividad depende prácticamente en saber

Definición del Efectuar análisis del

Fig. 1. Los cuatro pasos para la resolución de problemas

2.1 Definición del problema

• ¿Trabajamos en el problema equivocado?

cuál de todos los problemas planteados es el correcto, cuándo se empieza a “armar el

producen 3000 Bls/h y se procesan 400 MMPCD; Mantenimiento: costo de materiales

Ejemplo típico de una definición de un problema

inmediata de un acoplamiento de seguridad. Un pedazo del acoplamiento golpeó a Pedro

Fig. 2. Triángulo de fuego

2.2.1 Análisis de Cambios [3]

Fig. 3. Pasos a seguir durante el Análisis de Cambios

2.2.2 Análisis de Barreras [3]

• Las que promueven buen diseño, identificación, instrucciones y procedimientos.

Tabla 1. Ejemplo de Análisis de Cambios

1 . S e d e fin e u n 2 . S e in v e s tig a la 3 . S e id e n tific a n la s

C u e stio n a rio /”ch e ck list”

Fig. 4. Pasos a seguir durante el Análisis de Barreras

Para identificar como funciona la herramienta veamos el ejemplo de la Tabla 2. En la

Tabla 2. Ejemplo de Análisis de Barrera

2.2.3 Diagrama Causa/Efecto [1, 3-4]

Fig. 5. Pasos a seguir en el Diagrama Causa/Efecto [1].

Pasos a seguir para la aplicación de la herramienta:

El efecto principal es el “Qué”, en este caso pérdida de producción y horno fuera de

Pérdida de cp Horno fuera cp Pérdida de cp No había flujo cp

Medidor de flujo Observados

Fig. 6. Ejemplo de los pasos del Diagrama Causa/Efecto

que en el ejemplo de la Fig. 6 se ha incluido información que no califica dentro de la

Buena calidad de datos

Mala calidad de datos

2.2.4 Análisis de Tareas [3]

Tabla 3. Ejemplo de Análisis de Tareas

Visión sistemática del error

Tendencias Ambiente que

Fig. 8. Visión sistemática del error [4].

2.2.5 Espinas de Pescado (Diagrama de Ishikawa Causa Efecto) [3,5-6]

Rotura lámina Corrosión Limo

Alto CO2 Faltan canales Huecos muy Limpieza caja

Fig. 10. Ejemplo de la aplicación de una espina de pescado [7]

2.2.6 Árbol de Falla [3]

Adicionalmente, existen cuatro pasos usando Árbol de Fallas:

1. El analista debe enfocarse en una falla en particular

4. Debe determinarse el camino crítico que conduce a la falla

• Destrezas complementarias: la diversidad de opiniones y puntos de vista evita es sesgo

1. Root Cause Analysis, Apollo Associated services, Friendswood, TX.

2. J.L. Riggs, Productivity by Objectives, Prentice Hall, New Jersey (1983).

3. D.B. Fulbright, A comprehensive guide to root cause and program performance

4. J. Goodacre, Root Cause Analysis, Curso corto de la empresa consultora Woodhouse.