1 INTRODUCCIN

PAGE

ANLISIS CAUSA RAZ. FACILITADOR: CARLOS PARRA.

1999.

1INTRODUCCIN3

1.1Objetivos3

1.2Cambio de paradigma4

1.2.1Problemas basados en reglas5

1.2.2Problemas basados en eventos5

2METODOLOGA10

2.1Definicin del problema11

2.1.1Qu?11

2.1.2Cundo?12

2.1.3Dnde?12

2.1.4Importancia12

2.2Herramientas14

2.2.1Anlisis de Cambios [3]15

2.2.2Anlisis de Barreras [3]16

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

2.2.4Anlisis de Tareas [3]24

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

2.2.6rbol de Falla [3]29

3SOLUCIONES31

4TRABAJO EN EQUIPO31

5REFERENCIAS33

1 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 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 cuantificarPara reforzar estos conceptos, considere el siguiente ejemplo:

Ejemplo Tpico de un Reporte de un Incidente

Fecha del incidente: 10/28/94Hora: 0817Fecha del reporte: 1/7/95Unidad: 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 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:

EsperadaFallaFalla por dao secundarioOtra 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]:

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).

2 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.

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)).

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 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 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:

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).

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 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).

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.

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 1Evento 2CambioImpacto

8:00 PM viernes

Iluminacin artificial

Pitcher derecho: Juan

El line up se mantuvo8:00 AM sbado

Iluminacin natural (sol)

Pitcher zurdo: Pedro

Nuevo bateador Horario ms temprano

Diferencia de luminosidad

Diferente pitcherJugadores cansados

Jugadores ms cansados

El equipo B es ms efectivo con Pedro

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.

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

PeligroBarreraCausasSujeto

CarroAceraNo cruz en la aceraNio

Luz de cruceBombillo quemado

EntrenamientoNio sin entrenamiento

Certificacin del conductorSin licencia

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.

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.

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.

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 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).

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 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 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 ProcedimientoAnlisisPreguntas y Conclusiones

1. Ubicar trampa de drenaje

2. Despresurizar lnea

3. Verificacin de despresurtizacin

4. Abrir vlvula

5. Llenar toma muestra

6. Cerrar lnea

7. Represurizar lnea Trampa de drenaje no indentificada.

Medidor de presin ms cercano a 50 pies.

El resto de las trampas tienen medidores cerca de la toma de muestra. Existe una poltica de identificacin?

por qu el medidor est tan lejos?, ha sido modificado?

Todos los pasos son muy generales. 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 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].

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.

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.

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.

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

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.

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

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.

4 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.

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).

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 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. C. Parra, ACR: Anlisis Causa Raz - Eficaz Herramienta de Mantenimiento, Ingeniera de Mantenimiento, Universidad de los Andes (ULA), Septiembre 1999.

7. 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).

102

_990270031.unknown