Universidad de los Andes

Facultad de Ingeniera
Escuela de Ingeniera Mecnica
Postgrado en Ingeniera de Mantenimiento

Taller:
Anlisis Causa Raz (ACR)
Herramienta de Mantenimiento

Facilitador
Carlos Parra

Mrida, 1996

CONTENIDO

INTRODUCCIN ........................................................................................................ 3
1.1 Objetivos..................................................................................................................... 3
1.2 Cambio de paradigma................................................................................................. 4

1.2.1

Problemas basados en reglas .............................................................................. 5

1.2.2

Problemas basados en eventos............................................................................ 5

METODOLOGA....................................................................................................... 10
2.1 Definicin del problema ........................................................................................... 11
2.1.1

Qu? ................................................................................................................ 11

2.1.2

Cundo? .......................................................................................................... 12

2.1.3

Dnde? ............................................................................................................ 12

2.1.4

Importancia....................................................................................................... 12

2.2 Herramientas............................................................................................................. 14
2.2.1 Anlisis de Cambios [3] ................................................................................... 15
2.2.2 Anlisis de Barreras [3] .................................................................................... 16
2.2.3

Diagrama Causa/Efecto [1, 3-4] ....................................................................... 20

2.2.4 Anlisis 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] ............................................................................................. 29

3

SOLUCIONES ............................................................................................................ 31

TRABAJO EN EQUIPO............................................................................................ 31

REFERENCIAS ......................................................................................................... 33

INTRODUCCIN

El presente trabajo tiene como finalidad servir como material de apoyo en la aplicacin de
las tcnicas de Anlisis Causa Raz (ACR) a problemas enfocados desde el punto de vista
tcnico 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 travs del control sobre las causas que los
originan. En muchos casos no es extrao encontrar que las mejores soluciones son
generalmente las que no han sido vistas y que despus de una breve reflexin parecen
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 estn 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 bibliografa diversas tcnicas y autores que han abordado lo que hoy recibe el
nombre de ACR, cuyo propsito ha sido el de buscar soluciones efectivas.

Muchas

personas intuitivamente ya atacan problemas con la filosofa de pensamiento que involucra

ACR. Sin embargo, otros deben ser recordados de los procesos que involucra cuestionar no
slo las ideas de otros sino las propias. Las metodologas utilizadas sirven este propsito:
recordar a los analistas de problemas que pasos se recomienda seguir y que consideraciones
deben tomarse para la obtencin 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 metodologas las cuales se describen en el
presente documento. Algunas intervienen en distintos pasos, otras abarcan la totalidad del
proceso.

La intencin del presente documento es que sirva como material de apoyo e instructivo en
la aplicacin de la(s) metodologa(s) y forma parte de un taller para la formacin de
facilitadores de la tcnica de ACR. La aplicacin de ACR es un trabajo de equipo y como
tal requiere de cierta pericia para vencer los paradigmas y encontrar causas y soluciones
efectivas. Con la informacin suministrada en este trabajo, el lector debe estar en la
capacidad de aplicar los mtodos sin mayores dificultades.

1.1

Objetivos

Una vez ledo el documento, el lector debe estar en la capacidad de:

Mejorar la confiabilidad de los procesos a travs del anlisis de incidentes e

identificacin de causas sistemticas comunes.

Ser capaz de entender los conceptos de ACR.

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 caractersticas 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 aplicacin de reglas. Desafortunadamente, el
mundo est basado en eventos y en muchos casos estos no siguen reglas. La imposicin de
reglas a problemas basados en eventos ha generado el espacio que hoy da ocupa la infame
ley de Murphy. Sin embargo, ACR ataca esa visin y reconoce que los problemas pueden
agruparse en estas dos categoras [1].
Considrese la siguiente afirmacin, la cual es generalmente aceptada:

Un problema es generalmente entendido como alguna dificultad o situacin que requiere

de una solucin.
La oracin anterior posa dificultades en funcin del tipo de problema del cual se est
hablando. Para poder cuestionar la misma, considrense 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 nmeros (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
requieren de un cumplimiento, etc.

Est categora es la que abarca la definicin de

problema mostrada en el prrafo anterior.

1.2.2

Problemas basados en eventos

Son aquellos que dependen de las leyes causa y efecto donde existe ms de una solucin,
como por ejemplo: cmo dirigirse a la casa de la abuela? (seguramente existe ms de un
camino, o va (carro, autobus, avin, etc.)), cul es la solucin a la desnutricin?, cmo
ganarse la vida?, por qu falla una bomba?, cmo prevenir accidentes?, etc.
Al ignorar las diferencias intrnsecas 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

caractersticas comunes en la resolucin de problemas de la actualidad que evitan que

organizaciones e individuos busquen soluciones efectivas:

El ignorar la definicin del problema: como se ver ms adelante, la definicin del

problema es un parmetro importante dentro del anlisis y en general siempre que se
presenta uno, se busca una solucin inmediata sin detenerse en los eventos que los
causaron con suficiente detalle.

El llenado de reportes y formatos: en el rea tcnica es de uso comn la utilizacin de

listas de chequeo, llenar espacios en blanco y categorizar causas. Esta actividad, no es
en realidad particularmente mala, sino las caractersticas del formato, es decir, si ste no
5

contempla todos los puntos que deben ser considerados en el anlisis, la informacin
requerida puede ser pasada por alto.

La utilizacin de narrativa y fbula: esta es una prctica comn que entorpece la

bsqueda de informacin si se toman los relatos como hechos. Esto obedece a que la
informacin en muchos casos no posee la calidad necesaria.

En general y salvo

especficas excepciones, los hechos son aquellos que pueden ser medidos y verificados.
En el proceso de recoleccin las narrativas y fbulas son importantes como guas pero
no como verdades hasta que puedan ser verificadas. Si la informacin no puede ser
verificada, entonces el anlisis pudiera estar incompleto adems de que pudiese
ocasionar que la solucin 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 Tpico 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

Descripcin del incidente:

En Octubre 28, 1994 un empleado de una contratista (FCT) se encontraba conduciendo una
inspeccin de rutina en un ascensor (ELH-23) en TCH-3-675 cuando ocurri una descarga
elctrica. El electricista de FCT necesitaba chequear la puerta del motor y los interruptores
6

que se encontraban en la parte superior del ascensor, requiriendo que el mismo se

mantuviera con electricidad en esta difcil actividad de mantenimiento. Cuando esto se
efectuaba, un mensajero de la oficina de correos (CMR-3) presion el botn de llamada del
ascensor desde el primer piso ignorando la sealizacin de fuera de servicio ubicado sobre
el panel de botones de llamada. El electricista de FCT oy una alarma y fue 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 mltiples 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 dao secundario

Otra X

Descripcin de la Causa:
Una reunin fue sostenida en Noviembre 30, 1994 en el lugar donde ocurrieron los hechos.
EL electricista de FCT que particip en el incidente proporcion informacin de las
acciones paso a paso antes de efectuar la actividad de mantenimiento. La investigacin
concluy con que el problema era un error humano y que se deberan tomar acciones para
prevenir la recurrencia de este problema nuevamente.

Acciones Correctivas:
1. Proveer re entrenamiento a todos los empleados realzando la importancia de seales de
prevencin.
2. Incluir mejores contactos y puentes para medir contactos elctricos.
3. Revisar planos elctricos para mostrar el circuito completo de los controles del
ascensor.
4. La posicin de los interruptores ha sido ordenada para monitorear la longitud del cable.
Con el cumplimiento de estos cambios, el problema no ocurrir nuevamente.

Causa Raz: Repuesto defectuoso

Approbado:

BLB

Firma:

Existen varias observaciones que deben resaltarse con respecto al ejemplo anterior, entre
las ms resaltantes se encuentran:
Descripcin 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 seal
de fuera de servicio del ascensor.
Tipo de Falla: Se utilizan cuatro categoras (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 categorizacin de tipos de falla.
Descripcin de la Causa: Existe una diferencia grande entre la fecha del incidente y la del
reporte.

nicamente se describe la informacin suministrada por el mantenedor

(electricista) sin tomar en cuenta la versin 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 Raz: Totalmente en desacuerdo, ya que reponiendo el repuesto defectuoso no
prevendra la recurrencia de la falla, cualquiera que esta fuera.
Del ejemplo anterior tambin 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 alguna, es una
prctica comn que impide que la informacin fluya en ambas direcciones, o mejor an se
cita la frmula de productividad en la comunicacin como ejemplo ilustrativo [2]:
Pr oductivida d =

oir
hablar

De la ecuacin anterior, se deduce que la productividad depende prcticamente en saber or

y tratar de entender a otros con un mnimo de intervencin.

El segundo punto a mencionar est relacionado con que la percepcin del mundo vara de
acuerdo al individuo, lo que hace psicolgicamente imposible que dos personas tengan
exactamente el mismo punto de vista. Para ilustrar este punto recordemos por ejemplo la
lectura de un libro, digamos Doa Brbara de Rmulo Gallegos. Al leerlo, cada lector se
hace una imagen mental de los personajes y del lugar donde se desenvuelven los hechos.
La interpretacin particular, de por ejemplo, las caractersticas 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 Mrida, 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, televisin y teatro, es el director quien rene 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 comn de una persona y convertir
las percepciones individuales en realidades. El sentido comn vara entre las personas y la
cultura. Para citar un ejemplo, el sentido comn de la mayora de los comerciantes y
vendedores de comida en el Estado Zulia aaden a un gran nmero de sus platos salsa
rosada como aderezo, es algo intrnseco 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 comn (este ejemplo es real). Con respecto a las
percepciones, aunque no son malas del todo (por lo menos en el proceso inicial en la
bsqueda de soluciones) hay que tomar unos pasos ms para avanzar y convertirlas en
hechos, los cuales por definicin son posibles de medir y verificar.
Todos los factores discutidos anteriormente, inciden negativamente en la efectividad de las
soluciones de problemas ya que la definicin del problema est incompleta (creencia de que
todos vemos lo mismo), las relaciones causa/efecto entre hechos se desconocen (utilizacin
de narrativa tipo fbula y mala categorizacin) y a que el problema busca una solucin
inmediata sin detenerse en detalles o anlisis (bsqueda de la solucin favorita y con
prejuicio).

METODOLOGA

Antes de abordar la descripcin metodolgica, es necesario hacerse la siguiente pregunta:

y cmo 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: Definicin del problema, anlisis del problema, identificacin de soluciones e
implementacin de las mismas.

Analoga
Crimen y evidencia

Definicin del
Problema

Identificar
soluciones
efectivas
Deliberacin

Sospechosos, autopsia, confesin,

enjuciamiento, juicio

Efectuar anlisis del

problema (ACR)

Implementacin
de soluciones
Sentencia

Fig. 1. Los cuatro pasos para la resolucin de problemas

En la misma figura tambin se indica el paso generalmente seguido cuando se cree haber
definido un problema (identificar soluciones sin un anlisis detallado del mismo). Los
cuatro pasos tambin pueden relacionarse con cuatro elementos presentes en un juicio los
cuales guardan ilacin y secuencia, es decir: un crimen y la evidencia, el proceso de anlisis
de la misma (juicio), la deliberacin de jurado en funcin del anlisis (soluciones) y la
sentencia (implementacin). En este caso es el equipo natural de trabajo (jurado) es quien
delibera y argumenta en funcin de la informacin que tiene a la mano (ver por ejemplo la
pelcula doce hombres en pugna (en ingls: 12 angry men)).

10

2.1

Definicin del problema

Antes de abordar la definicin 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 trminos de nuestra realidad?

Tenemos experiencias distintas y profesiones?

Entendemos nuestra ignorancia y prejuicios?

Trabajamos en el problema equivocado?

Trabajamos en los sntomas o en las causas?

Para definir apropiadamente un problema un equipo de trabajo debe responder cuatro

preguntas bsicamente:

Qu?: Qu fue lo que ocurri?

Cundo?: Cundo ocurri?, aqu no solo se incluye la fecha y la hora sino tambin el
contexto.

Dnde?: Dnde 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,

daos econmicos, etc.

Las siguientes preguntas no deben efectuarse durante la definicin del problema:

Quin?: El objetivo del anlisis es la prevencin y no la bsqueda de un culpable.

Por qu?: No aplica en la definicin sino en el anlisis del problema.

Cmo?: No aplica en la definicin sino en el anlisis

2.1.1

Qu?

El qu es el efecto primario, es lo que quiere evitarse o controlarse. Durante la primera

sesin un equipo dedicado a resolver un problema discutir para definir el problema y
diferentes puntos de vistas relucirn como consecuencia. No hay que detenerse a elegir

11

cul de todos los problemas planteados es el correcto, cundo se empieza a armar el rompe
cabezas, generalmente se encuentra cul es de los efectos es realmente el primario.
Cabe resaltar que puede haber ms de un efecto primario y es en este punto dnde hay que
hacerse la pregunta por qu? para correlacionarlos (lo cul forma parte del anlisis per se).
El efecto primario es el punto de partida y es dnde 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,
prdida de produccin, retraso al llegar al trabajo, etc.

2.1.2

Cundo?

En este punto hay que establecer la fecha y el tiempo y la exactitud de dicha informacin.
A veces es importante el control preciso del tiempo como en plantas y sistemas
automatizados, esto por su puesto depender del caso. Tambin se refiere al contexto,
como por ejemplo si la falla ocurri en el arranque de un sistema. Ejemplo de cundo: El
28/07/1998 a las 4:32 PM, despus del arranque del sistema.

2.1.3

Dnde?

Precisa la ubicacin del problema. En este segmento hay que ser especfico para prevenir
confusiones.

Ejemplo de dnde: Estado Zulia>Divisin Occidente>Lago de

Maracaibo>Plantas Compresoras de Gas>Planta TJ1>Sistema de Compresin>Cadena

A>Bomba DC1.

2.1.4

Importancia

El rubro de Importancia dentro de la definicin debe responder la pregunta: por qu

estamos trabajando en este problema?. El segmento de importancia ayuda a priorizar los
incidentes. Es tambin posible que un incidente pequeo por si solo tenga poco impacto.
Sin embargo, si su frecuencia es alta la historia es otra. En esta seccin deben incluirse los
objetivos de la organizacin y del negocio, debe ser medible. Ejemplos de Importancia:
Seguridad: No hubo heridos pero pudo haber; Ambiental: Viola las regulaciones del
12

Ministerio de Ambiente; Produccin: Paro de planta no programado de 4 horas, se

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 continuacin y defina el problema en la tabla
anexa:

Ejemplo tpico de una definicin de un problema

Despus que Juan y Pedro finalizaron la instalacin, 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

problema acercndose a la mquina, se escuch una explosin seguida por la destruccin

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 mdico. No hubo ningn otro
herido. El equipo se haba atascado debido a un tapn (slug) de lquido que pasaba por la
mquina.

Las lneas de entrada no fueron desalojadas adecuadamente despus de la

reparacin. La reparacin de la mquina 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 aos. 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 da cuando se encuentra en su capacidad mxima.
Qu:
Cundo:
Dnde:
Importancia:
Seguridad:
Ambiental:
Produccin:
Mantenimiento:
Frecuencia:

13

2.2

Herramientas

La presente seccin muestra las diversas tcnicas que pueden ser utilizadas en el proceso de
anlisis una vez que los problemas hayan sido debidamente definidos.

Las tcnicas

(herramientas) se aplican en diversos pasos del proceso y no necesariamente existe una en

particular que garantice que cubra todo el anlisis. Antes de continuar con la descripcin
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 definicin de causa raz an
cuando el concepto se ha convertido en la actualidad en uno de uso comn. Segn la
literatura [1,3-4] las definiciones pueden agruparse en las siguientes:

Se refiere a la(s) causa(s) ms bsica(s) que puede(n) ser razonablemente

identificada(s) y que la gerencia tiene control para prevenir.

La razn ms bsica para una falla, problema, deficiencia que si es corregida

prevendr la recurrencia.

A simple vista, la primera definicin parece engorrosa y complicada, de hecho, la

definicin ms comn es la segunda. Sin embargo para entender el concepto de causa raz
consideremos el tringulo de fuego mostrado en la Fig. 2. Para que exista un fuego deben
combinarse simultneamente los tres factores: una fuente de calor, un material combustible
y una fuente de oxgeno. Si alguno de estos tres elementos se encuentra ausente en un
momento dado, un fuego no ocurrira. Es decir, existen al menos tres causas simultneas
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 raz nica sino
tres. Todas pueden ser controladas y la ausencia de alguna de ellas evitara un incendio.
La definicin (a), aunque un poco ms compleja, incluye a las tres causas. Sin embargo,
habla del trmino razonable el cual pretende indicar que sta est dentro de nuestros
lmites. Por ejemplo, una de las causas que un avin se caiga durante un vuelo es la el
campo gravitacional, pero la gravedad es difcil (note que no se uso el trmino imposible)
de controlar por lo que no es razonable hablar del trmino.

El segundo punto est

relacionado con el primero nuevamente, ya que la gerencia de Avensa, por ejemplo, no

puede prevenir la accin gravitacional (por lo menos hasta ahora).

14

calor

combustible

oxgeno
Fig. 2. Tringulo de fuego
2.2.1

Anlisis de Cambios [3]

El Anlisis de Cambios no es ms que la comparacin 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 Anlisis 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)

Comparacin entre eventos

4)

Identificacin de diferencias

5)

Anlisis de diferencias

6)

Determinacin del factor causal

Para ilustrarlo se puede efectuar una tabla como la que se muestra a continuacin. Cabe
resaltar que en el ejemplo el anlisis se efecta desde el punto de vista del equipo A.
Como se observa en la tabla, se listan en dos eventos las diferencias que pudieron haber
ocasionado el incidente. As mismo se evalan los cambios y cual fue el impacto. En el
15

ejemplo se listan las diferencias entre los encuentros, las horas a las cuales se efectuaron, la
iluminacin, los jugadores presentes, los lanzadores, etc. Este ejemplo es real y de utilidad
para llevar estadsticas como ocurre en el base ball.
Entre las ventajas y desventajas de esta tcnica encontramos lo siguiente:

En los comienzos de una investigacin, los factores causales pueden ser difciles de
identificar. El Anlisis de Cambios ayuda al analista de problemas a comenzar a
recolectar informacin.

El Anlisis de Cambios resalta diferencias entre escenarios con y sin error, adems e
que es adecuada para condiciones relativamente simples. Es importante resaltar que
esta tcnica pudiera no identificar cambios que ocurren en perodos de tiempo largo
(como el desgaste de un rodamiento).

Anlisis de Cambios
1. Identificacin de

2. Identificacin de

un evento con
consecuencias
indeseables

un evento similar
sin consecuencias
indeseables

5. Analice las
4. Compare las
diferencias

diferencias que
afectan las
consecuencias

3. Compare las
dos actividades

6. Identifiacin de
que accin
especfica ocasion
la consecuencia
indeseable

Fig. 3. Pasos a seguir durante el Anlisis de Cambios

2.2.2

Anlisis de Barreras [3]

Esta herramienta se refiere a la identificacin 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, Anlisis de Barreras evala peligros
que pueden causar daos, personas u objetos que son vulnerables a peligros, ausencia de
barreras y controles entre otros. Existen varios tipos de barreras:

Las que promueven buen diseo, identificacin, instrucciones y procedimientos.

16

Tabla 1. Ejemplo de Anlisis de Cambios

Descripcin 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 sbado siguiente donde B derrot a A 10 por tres
Evento 1

Evento 2

Cambio

Impacto

8:00 PM viernes

8:00 AM sbado

Horario ms temprano

Iluminacin artificial

Iluminacin natural (sol)

Diferencia de luminosidad Jugadores ms cansados

Pitcher derecho: Juan

Pitcher zurdo: Pedro

Diferente pitcher

El line up se mantuvo

Nuevo bateador

Jugadores cansados

El equipo B es ms efectivo con Pedro

17

Las que previenen acciones errneas y hacen fsicamente imposible hacer algo
inadecuado (dispositivos de seguridad).

Las que desaniman como avisos y smbolos, instrucciones durante reuniones de trabajo.

Las que detectan acciones errneas como listas de chequeo, inventarios, balance de
masa, rondas de operadores y el mtodo PPAR (Pare-Piense-Acte-Revise).

La Fig. 4 muestra los tres pasos a seguir para aplicar el anlisis de barreras.

Anlisis de Barreras

1. Se define un
problema y un
objetivo

2. Se investiga la

3. Se identifican las

secuencia de hechos
que ocasionaron el
problema

barreras inefectivas
que lo ocasionaron

Cuestionario/check list
Fig. 4. Pasos a seguir durante el Anlisis de Barreras
Para identificar como funciona la herramienta veamos el ejemplo de la Tabla 2. En la
misma se identifica un sujeto que no es ms que lo que se quiere proteger (en este caso
un nio) 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 trnsito
(peatonal).

Tabla 2. Ejemplo de Anlisis de Barrera

Peligro
Carro

Barrera

Causas

Sujeto

Acera

No cruz en la acera

Nio

Luz de cruce

Bombillo quemado

Entrenamiento

Nio

sin

entrenamiento
Certificacin

del Sin licencia

conductor

19

As mismo, se listan las barreras existentes que evitaran que un nio fuera arrollado por un
carro. Por ejemplo, la acera es una barrera que evita que un carro arrolle al nii. 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 nio tambin 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 anlisis de barreras: diseo, dispositivos de seguridad, avisos de
peligro, procedimientos, entrenamiento, y notificacin a la gerencia de riesgos.
El anlisis de barreras es particularmente de utilidad para fallas que no son frecuentes pero
tiene la desventaja que si la persona que efecta el anlisis no reconoce todas las barreras,
peligros y/o sujetos el anlisis estara incompleto (existen muchas barreras implcitas en
diseo que son difciles de identificar).
En muchos casos una barrera que falle no es necesariamente un a causa raz, el analista
debe ir ms 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 tcnica es de amplio uso en la bsqueda de soluciones en el Anlisis Causa Raz. As

mismo existen variantes de la misma.

Sin embargo, no debe ser confundida con el

diagrama de Ishikawa (espinas de pescado (Fishbone charts)) aunque en algunos textos

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 representacin pictrica 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 Lnea de Tiempo [4]. De las tres versiones la ms sencilla es
la propuesta por Apollo RCA, ya que requiere del menor nmero de reglas para su
aplicacin.
20

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 lesin es causada por una cada, y la cada es causada
por una superficie hmeda o una vlvula que gotea, lo cual es causado por mantenimiento
inadecuado. En este problema se ha identificado un efecto principal (lesin) y a travs de
las relaciones entre causas y efectos se pueden identificar la soluciones a la causa(s)
raz(ces) como mejorar el programa de mantenimiento de las vlvulas (evitara el goteo de
la vlvula y por ende la lesin). La Fig. 5 muestra como se construye un Diagrama
Causa/Efecto.

Esquemas Causa/Efecto
Causa accin

Efecto principal
Causa condicin

Causado
por
Causa condicin

Causa condicin

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

Pasos a seguir para la aplicacin de la herramienta:

Se define un problema y se ubica un efecto primario. Puede existir ms de un efecto

primario, sin embargo como se ver en un ejemplo, la dinmica de la herramienta ayuda
a establecer cul es el ms general.

21

Al efecto primario se le hace la pregunta por qu? y se listan todas las causas posibles
(an aquellas que parezcan obvias). Existen dos tipos de causas: accin y condicin.
En el ejemplo del tringulo de fuego (Fig. 2) en el cual el fuego sera el efecto
principal, al preguntar por qu ocurre un fuego?, la respuesta emite tres causas
(condiciones): oxgeno, combustible y calor. Sin embargo, las tres condiciones pueden
coexistir y an no generarse un fuego ya que se necesita, por ejemplo, de que alguien
encienda un fsforo (causa accin).

Se utilizan pasos pequeos entre causas. En general, mientras ms complejo sea el

problema, se requiere de un nivel de detalle mayor.

La aplicacin de esta tcnica requiere de la utilizacin de evidencias para soportar cada

causa. Esto no implica que durante la elaboracin del diagrama no se puedan utilizar
suposiciones, sino que deben ser comprobadas con instrumentos que permitan su medicin
y verificacin. La utilizacin de suposiciones puede llevar a soluciones inefectivas con lo
que el anlisis estara 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 difcil
comprobar con hechos. En estos casos se recomienda utilizar la intuicin pero creando
mecanismos que en el futuro permitan medir para corroborar los supuestos.
Vase el siguiente ejemplo donde no se conocen los detalles de lo que ocurri pero se
pueden inferir de la informacin y del diagrama hecho a partir de sta.
Qu:

Prdida de produccin, horno fuera de servicio

Cundo:

28/08/1998 en condiciones de operacin normal

Dnde:

Divisin CA>Planta 5>Unidad 2>Horno H3D

Importancia
Seguridad:

Sin accidentes

Ambiental:

Sin impacto

Produccin:

Prdida de produccin, 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 prdida de produccin y horno fuera de

servicio (pudiesen haber mas dependiendo de lo que haya decidido el equipo natural de
trabajo). Para identificarlo se hace la pregunta: por qu hubo prdida de produccin? Y la

22

respuesta es: porque el horno se encontraba fuera de servicio. As se comprueba que el

efecto principal ms general es la prdida de produccin y que incluye a que el horno est
fuera de servicio (vase Fig. 6).

Efecto principal

Prdida de
produccin

c
cp

No haba flujo cp
de aceite

cp
Horno fuera cp Prdida de
de servicio
aceite en horno

Datos del computador

A
c

Caudal aceite cp Medidor de flujo

pareca OK
media flujo positivo
Medidor de flujo

cp

Supervisor cerr vlvulas de aceite

Lnea tapada

Vlvula de purga
estaba abierta
Consenso de grupo

a
cp

Medidor de flujo

Depsitos
Observados

c
a

No se han sacado cp
beneficios de
otras fallas
Consenso de grupo

No siempre se
cp
han seguido
procedimientos
Personal no notific este
problema

Varias
Cnsola de
cp
filas y
vlvulas est
colum. de
congestionada
vlvulas
Consenso de grupo
Diseo en revisin

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 condicin y a causa accin, as mismo debajo de algunas casillas
aparece de donde la fuente de informacin. El citado ejemplo se leera as: La prdida de
produccin fue causada por el horno fuera se servicio; el horno fuera de servicio fue
causado por prdida de aceite en el horno; la prdida de aceite fue causada por que no haba
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 pareca estar bien (medidor de
flujo) porque la lnea estaba tapada (como lo indic el medidor) y porque no se han sacado
23

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 que en el ejemplo
de la Fig. 6 se ha incluido informacin que no califica dentro de la categora 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 anlisis se efecta buscando el
consenso del equipo este debe estar fundamentado en evidencia (medible y verificable) no
en creencias ya que pudiera conducir a la solucin equivocada, a resolver un problema
inexistente. La calidad de los datos se muestra en la Fig. 7:

Buena calidad de datos

Hechos:

Preciso, exacto, medible y verificable

Inferencia:

Deduccin lgica basada en hechos

Suposicin:

Hiptesis lgica que de ser verdad explica hechos

Opinin:

Intuicin y experiencia

Creencia:

Opiniones de otros

Rumor:

Informacin de 2da, 3ra y 4ta mano

Adivinanza:

Educada, salvaje, premonicin

Fantasa:

Sin base y distorsin

Mala calidad de datos

Fig. 7. Degradacin de la calidad de la informacin.

2.2.4

Anlisis de Tareas [3]

Esta tcnica es utilizada para asistir al analista en el aprendizaje acerca de procesos en el

trabajo relacionados con el desempeo de las personas. El analista aprende cmo las tareas
(procedimientos) son efectuadas y como deban 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 efecte una revisin de procedimiento se haga en sitio mientras el ejecutor
efecta la tarea, esto simplifica el anlisis y permite incluir observaciones que de lo
24

contrario no seran incluidas dentro del nuevo procedimiento. La tcnica se ilustra en el

ejemplo descrito en la Tabla 3.

Tabla 3. Ejemplo de Anlisis de Tareas

Pasos del Procedimiento

Anlisis

Preguntas y Conclusiones

1. Ubicar trampa de drenaje

Trampa de drenaje no

Existe una poltica de

2. Despresurizar lnea

indentificada.

identificacin?

Medidor de presin ms

por qu el medidor est

cercano a 50 pies.

tan

El resto de las trampas

modificado?

5. Llenar toma muestra

tienen medidores cerca

Todos los pasos son muy

6. Cerrar lnea

de la toma de muestra.

generales.

3. Verificacin

de

despresurtizacin
4. Abrir vlvula

7. Represurizar lnea

lejos?,

ha

sido

Cmo sabe

el operador cmo los

tiene que hacer?

Ntese que se hace una descripcin del procedimiento en 7 pasos. Durante el anlisis, se
identifican varios puntos de atencin 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 mo) o porque el enfoque en la resolucin de los
problemas se ha centrado en la poltica de buscar culpables, con la creencia que si son
removidos impiden la recurrencia de problemas.

Con esta ltima aseveracin no se

pretende eximir a personas que pudieran actuar irresponsablemente en un momento dado,

sino ms bien reflexionar acerca del nmero de personas que violan reglas a priori. Como
ejemplo pudiramos citar la poblacin carcelaria de un pas la cual refleja el nmero de
individuos que no obedece reglas y que estn fuera del contexto social. La probabilidad de
que exista un operador, mantenedor, etc., que decida ejecutar una accin errnea con
25

premeditacin es bastante baja, por lo cual los esfuerzos deben hacerse en la verdadera
bsqueda de soluciones y preguntarse por qu ocurri?.
Para ilustrar la visin sistemtica del error, refirmonos a la Fig. 8 [4].

Visin sistemtica del error

Tendencias
al error
Errores
Significativos

Ambiente que
no perdona

Ambiente que
induce al error
Fig. 8. Visin sistemtica del error [4].
Los errores significativos ocurren por la combinacin de tres factores: tendencias al error
(es una tendencia humana), ambiente que induce al error (un diseo deficiente, por
ejemplo), ambiente que no perdona (la falla de un equipo que ocasione una sbita parada de
planta). Si al identificar problemas no se toman en cuenta estos factores, an buscando a un
culpable los problemas persistirn independientemente del individuo que ejecute la labor.
Las preguntas que hay que hacerse en vez de quin? Son: Cmo disminuir tendencias al
error?, Cmo 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 clasificacin de causas en categoras definidas por los

miembros de un equipo. El diagrama se efecta siguiendo estos pasos (ver Fig. 9 y 10):
1. Se define un efecto principal, esto es aquello que se desea mejorar o controlar.

26

2. Se escribe el efecto a un extremo de la espina principal.

3. Despus se escriben las espinas secundarias (categoras) que pudieran estar causando el
efecto principal. Generalmente, se recomienda que todas las posibles causas sean
agrupadas en categoras, como por ejemplo: materiales, herramientas, inspeccin,
individuos, etc. Tambin se habla de las cinco M (Mquina, Mano de obra, Medio
Ambiente, Mtodo 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 categoras (ramas terciarias,
etc.).
La manera de construir las ramificaciones es hacindose la pregunta por qu? y al
responder se colocan nuevas ramificaciones. Ntese 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 recoleccin de datos y son ampliamente
conocidas en las aplicaciones de calidad.
27

Fallan bombas
Holgura inadecuada

Falta
cesta

Falta Cl2

Mal armado
Falta tubos

Fuga Cl2

Falla iny.
Cl2
Falla

Corrosin

Rotura lmina
de huecos

Vlvula
trancada
Mal balance
de agua

Holgura excesiva

Pericia
Caracoles clorinacin

Pescados

Falta agua

Falla en rutina
de inspeccin

Material tubos
Pelo de oso

Falla
Magnecida

Calidad del
Agua

Diseo
Enfriador

Alto H2S

Alto H2O

Corrosin
Externa Falta Apertura/Cierre
pericia de vlvula

Mala Operacin
Fallas Enfriadores
Atmosfricos

Calidad del
Gas
Alto CO2

Falla Mecnica
Caja

Flujo de agua
discontinuo

Vlvula
sin volante

Dobladura lmina
de huecos

Calibre tubos

Materia orgnica

Acceso
riesgoso

Limo

Diseo
Vertedero Batea

Faltan canales
de distribucin

Ubicacin
inadecuada

Muy corta

Existen ngulos
transversales
Patas sobresalen
borde de caja
Faltan huecos
zona caliente

Diseo de Caja
de Distribucin

Mantenimiento
Inadecuado

Huecos muy
grandes

Limpieza caja
de distribucin

Caja muy corta

Lminas coralux
mal instaladas

Desnivel

Caja de distribucin
mal instaladas

Posicin

Ventanas abiertas
Falta abertura en
zona caliente
Existe parrilla bajo
zona de huecos

Faltan cestas
bomba de levantamiento
Limpieza lateral del enfriador
durante paro de mquinas

Fig. 10. Ejemplo de la aplicacin de una espina de pescado [7].

28

Existe una variante de este diagrama propuesto por el japons Nakahima [6] donde utiliza
la metodologa denominada Fenmeno de Mecanismo a partir del diagrama de Ishikawa.
Nakahima ataca problemas de mltiples causas (policastico) 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 metodologa son los siguientes [6]:
1. Definicin del problema (efecto principal).
2. Efectuar Anlisis de los principios fsicos (causas) de los fenmenos. Los defectos
identificados deben ser traducidos a travs de los principios fsicos que lo describen (ej.:
un defecto de centrifugado depende de la fuerza centrfuga (magnitud) y de la velocidad
de giro) estos deben medirse y cuantificarse.
3. Definir las condiciones que producen el principio fsico (causa).

No es ms que

investigar las posibles condiciones necesarias para producir causas. La causa no es ms

que aquello que produce un defecto o fenmeno que guarda proporcionalidad o
semejanza con l y que se halla en los mecanismos. La condicin no es ms que el (los)
elemento(s) o circunstancias favorecedoras de la causa. En el ejemplo anterior, varias
condiciones propician la variacin de la velocidad de giro de la centrfuga: aflojamiento
de las correas, tensin elctrica, sobrecarga de slidos, etc.
4. Definir los factores de una condicin como las causas que pertenecen a una de las
categoras de la espina de pescado (ej. Las 5 M, Mquina, Mano de obra, Medio
Ambiente, Mtodo y Materia prima). Los nicos factores del 5M que contribuyen a la
condicin aflojamiento de correas son: anclaje y asentamiento (Mquina), falta de
vigilancia (Mano de obra) y humedad del tiempo (Medio Ambiente).
5. Investigar cada factor. Se establece un mtodo 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 especficas. 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 tcnica es la ms compleja en trminos de conocimiento ya que para un problema en

particular puede complicarse bastante. En muchos casos esta tcnica 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 tcnica es que la experticia tcnica no es
necesaria ya que las preguntas han sido generadas previo a la investigacin. Sin embargo,
es conducida por eventos lo cual hace que el anlisis se extienda. Esta tcnica tambin es
utilizada en el rbol lgico de decisin para Mantenimiento Centrado en Confiabilidad
(MCC).
La tcnica se parece a la Espina de Pescado, pero incluye conectores lgicos 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
informacin 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) raz(ces).
El analista que desarrolle un Arbol de Falla debe asegurar un balance apropiado entre
comprensin, nivel de detalle y prctico 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 mnimo 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
4. Debe determinarse el camino crtico que conduce a la falla

30

El rbol de Falla permite identificar causas relacionadas con equipos, errores humanos o
procesos. As mismo, es de utilidad para buscar mltiples mecanismos de falla para un
mismo evento. Sin embargo, es relativamente complejo comparado con otras tcnicas.
3

SOLUCIONES

Hasta el momento, se han descrito herramientas que permiten efectuar el anlisis sin
mencionar como deben ser las soluciones. Estas deben satisfacer los criterios definidos por
el anlisis y deben contemplar costos, facilidad de ejecucin, responsables, etc. Otro punto
importante es que deben ser especficas, en general, la utilizacin de trminos con
condicin futura como: revisar..., analizar..., investigar..., son indicadores de anlisis de
problemas incompletos. La bsqueda de soluciones requiere de creatividad y como tal,
esta idea se refuerza en el cambio de paradigma que se mencion en la introduccin donde
hay que pensar en forma no convencional.
Para mejorar el pensamiento hay que retar paradigmas como el sentido comn, 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 solucin, es recomendable fomentar discusin y or 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.

TRABAJO EN EQUIPO

Una de las partes ms complejas durante la aplicacin de la metodologa es el trabajo en

equipo. Una vez que se ha constituido el mismo, se recomienda establecer ciertas reglas
para poder mantener la dinmica y llegar a resolver problemas. Los siguientes puntos
deben ser tomados en consideracin:

Establecer compromisos con propsitos y metas: esto debe establecerse desde el inicio
para mantener al grupo alineado con un norte comn.

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 ms grande el grupo, ms

difcil se hace manejarlo. As mismo, cuando existen numerosos miembros en un
grupo, se delegan responsabilidades en otros.

31

Establecer responsabilidades y buscar apoyo mutuo: cada vez que se efecten las
reuniones del anlisis deben generarse compromisos para la prxima reunin. Para ello,
se recomienda discutir todos los puntos que deben ser analizados en la prxima reunin
en forma de agenda, donde cada miembro conozca, una vez que se hayan puesto de
acuerdo, lo que tiene que hacer. En muchos casos, se requerir de ms de un miembro
para ejecutar una tarea.

Recordar los compromisos manteniendo el enfoque comn del trabajo: esto permitir a
los miembros reorientarse en los momentos en que el grupo tiende a dispersarse.

Tambin se recomienda al inicio de la conformacin 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 reunin y ceirse al mismo.

Abstenerse de llamadas telefnicas (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 dems miembros la toma de
decisiones, tareas y asignaciones).

32

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

analysis, Copyright D.B. Fulbright 1997.

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. J.J. Perdomo, C.A. Boscn, C. Parra, M.C. Moreno, A. Barboza, J. Monsalve, J.

Snchez, L. Torres, Anlisis Causa Raz de la Problemtica de los Enfriadores
Atmosfricos de las Plantas Compresoras de Gas, PDVSA INTEVEP (2000).

33