Mtodos de Resolucin

de Problemas

2

Introduccin: A travs de la historia el hombre ha inventado y mejorado numerosas

maquinarias y procesos basndose en sus habilidades para llegar a la

demanda creciente de productos y servicios por parte de la sociedad.

Como resultado de esta demanda en constante crecimiento y optimizacin de

costes, se han desarrollado varias tcnicas para analizar los problemas que

surgan de las maquinarias, los procesos y el rendimiento de las habilidades,

en un esfuerzo por asegurar su confiabilidad. Anlisis por Causa Raz (ACR) es una de esas armas en el arsenal de confiabilidad.

El Anlisis por Causa Raz puede significar muchas cosas para la gente con diferentes experiencias. Se puede describir sus esfuerzos de ACR como el

cumplimiento de los requisitos de su Confiabilidad de los Activos. Esta es una

mala interpretacin bsica que se debe aclarar. La Confiabilidad es mucho ms

que la adopcin de la metodologa ACR.

La gente, tradicionalmente se ha inclinado por ver la Confiabilidad

estrictamente desde la perspectiva de mantenimiento. La cultura en Reliability

Center Incorporated desde 1972 encara la Confiabilidad desde un punto de

vista holstico, teniendo en cuenta todos los factores que afectan la

Confiabilidad.

Para que la Confiabilidad verdaderamente se convierta en parte de la cultura,

debe ser adoptada como responsabilidad de todos, no solamente de

mantenimiento. Debe abarcar no solamente temas de los activos fsicos

(mecnicos, elctricos, etc), tambien cubrir temas relacionados con los

procesos de produccin y humanos. Por ejemplo, a menudo ves a la gente que

relaciona los problemas del equipo estrictamente con causas potenciales del

mantenimiento; cuando todos saben que los problemas del equipo pueden ser

ocasionados por otros factores tales como inconveniente prcticas

operacionales y inadecuados diseos. Una vez que entiendas este concepto,

3

estars bien encaminado para encontrar las causas reales de los problemas

con los que te has encontrado.

Los beneficios de ACR pueden verse en cada uno de los aspectos de tus

operaciones. Entonces, por qu no estn todas las instalaciones

completamente moderadas con tal esfuerzo de ACR? Nuestra experiencia nos

muestra que la mayora de las instalaciones estn tan inmersas en reaccionar a

los problemas o fallas diarias, que el llevar a cabo una actividad tan proactiva

como el analizar problemas no es vista como el aportar un valor agregado al

negocio. Otra razn por la cul las organizaciones fallan es ver al proceso ACR

PROACT como una alternativa viable a la manera en la que ellos normalmente

manejan los problemas que se cree que el conducir ACR es costoso y que no

reporta retornos apropiados a la inversin.

En realidad, sto no puede estar ms lejos de la verdad. En la mayora de las

situaciones, las recomendaciones para las soluciones de los problemas

identificados involucran la correccin de sistemas organizacionales o de

administracin que no requiere desembolso de dinero.

Cuando ACR se lleva a cabo correctamente, es una herramienta para que

puedas tornar tus problemas identificados en oportunidades reales para

mejorar todo tu negocio.

Algunos ejemplos que muestran cul es el Retorno de la Inversin al adoptar

de forma correcta el proceso Anlisis Causa Raz PROACT:

Empresa: Eastman Chemical

o 50% Reduccin de los reclamos o quejas de sus clientes

Empresa: Weyerhaeuser

o 25% Aumento de capacidad de la productividad

Empresa: LYONDELL-CITGO

o 17,900% Retorno de la Inversin en ACR.

4

Empresa: (ISPAT) Inland Steel

o 4,000% Retorno de la Inversin en ACR.

Empresa: Eastman Chemical (TED)

o 3,200% Retorno de la Inversin en ACR.

Empresa: Alabama Power

o 3,125% Retorno de la Inversin en ACR. Para mayores detalles de los casos pueden consultar el libro, ROOT CAUSE

ANALYSIS : Improving Performance for Bottom Line Results (Latino & Latino,

2001 / www.crcpress.com)

Entonces se preguntarn Qu es el Anlisis Causa Raz PROACT?:

Es una metodologa disciplinada que permite identificar las causas fsicas, humanas y latentes de cualquier tipo de fallo o incidente que

ocurren una o varias veces permitiendo adoptar las acciones correctivas

que reducen los costes del ciclo de vida til del proceso, mejora la

seguridad y la confiabilidad del negocio.

Al entender la importancia del tener en sus instalaciones un proceso de

mejoramiento continuo apoyado en el Anlisis Causa Raz PROACT veamos

cules son los pilares de esta metodologa.

Paso 1.- Enfoque & LEAP: Los problemas o eventos no deseables pueden ser definidos con precisin

como desviaciones de la norma de rendimiento. Para ilustrarlo, si una planta

produce producto A con un caudal de produccin de 10.000 productos A por

da, entonces cualquier cosa que disminuya esta produccin es considerado un

problema.

A la inversa, puede pensarse como una oportunidad, una posibilidad de lograr

una meta o un estado ideal.

5

Usando el mismo ejemplo, si el caudal de produccin de tu supuesta planta de

producto A debe incrementarse a 15.000 unidades por da, entonces el

aumentar la produccin normal de siempre sera ciertamente una oportunidad.

De este ejemplo, ciertamente se puede ver que la diferencia clave entre

problemas y oportunidades es que el problema no progresa, mientras que la

oportunidad s progresa mediante un incremento sobre lo de siempre.

Ahora la pregunta es, cmo puedes transformar los problemas en

oportunidades ? La primera cosa que debes hacer es identificar los problemas

especficos que te darn el mejor retorno en tu inversin. Para hacer sto es

importante para nosotros entender el hecho de que hay dos tipos de problemas

con los que puedes enfrentarte: espordicos y crnicos.

Los problemas o eventos espordicos son aquellos que causan una cantidad

considerable de caos cuando aparecen, tienen ciertas caractersticas que son

importantes que notemos, por ejemplo, por la naturaleza del problema capturan

la atencin de todos. Los incendios, explosiones, virus en los ordenadores,

huelgas o paros sorpresivos (tales como el paro de los Controladores de

Trfico Areo en los 80s) son buenos ejemplos de problemas espordicos o el

caso del Trasbordador Challenger. No ocurren con mucha frecuencia, porque si

fuera as muy pronto estaras arruinado. Los problemas espordicos

tpicamente cuestan una gran cantidad de dinero y llevan mucho tiempo volver

al estado normal. Es por eso que a la gente le encanta colocar cifras en este

tipo de problemas. A pesar de que estos problemas espordicos son altamente

visibles e individualmente tienen un coste significativo asociado, su coste total

puede ser amortizado en un perodo de tiempo. sto hace que sean menos

costosos a medida que transcurre el tiempo.

Los problemas o eventos crnicos por otro lado, ocurren una y otra vez, y por

las mismas razones aparentes. Suceden tan frecuentemente que son

aceptados simplemente como el coste de hacer negocios.

El estado normal se mantiene a pesar de su existencia continua. A diferencia

de sus contrapartes espordicas, los problemas crnicos tienen una alta

6

frecuencia de ocurrencia y generalmente no llevan mucho tiempo para ser

corregidos. Cuando se los toma individualmente, cada evento tiene un impacto

o un coste asociado relativamente bajo. Sin embargo, cuando la frecuencia del

evento se multiplica por el coste de cada una de las ocasiones, a menudo

descubres que la prdida total es significativa.

Una vez que te das cuenta de las diferencias entre los problemas espordicos

y los crnicos, se torna fcil para nosotros entender donde deberas estar

invirtiendo tus recursos. Teniendo en cuenta que los problemas espordicos

ocurren fuera de las situaciones normales, su resolucin slo nos devuelve a lo

que estamos acostumbrados. No hay potencial para mejorar. Por otro lado, los

problemas crnicos ocurren dentro de las situaciones normales y presentan

una gran oportunidad de mejora.

El paso final en la etapa de preparacin del enfoque es llevar a cabo el AMEF

en el formato modificado por RCI, el Anlisis de Modos y Efectos de Fallas (FMEA: Failure Modes and Effects Analysis) es una tcnica que fue utilizada primero por la industria aeroespacial para encontrar los problemas con las

aeronaves antes de despegar. En esencia, era una forma de mirar hacia el

futuro y determinar donde podran estar los problemas potenciales. Este

concepto es verdaderamente maravilloso en teora. Sin embargo, en la

prctica, lleva mucho tiempo y recursos para ser implementado (a menudo

cientos de aos / hombre). Reconociendo que la mayora de ustedes no tienen

el tiempo ni los recursos necesarios para conducir un FMEA tradicional, usted

tiene que divisar una manera de hacer el proceso menos engorroso. Por esta

razn, el RCI ha hecho un simple cambio al proceso de FMEA; o sea, en vez

de mirar hacia el futuro, usted se basa estrictamente en datos histricos. Esta

metodologa modificada disminuye el impacto tanto en el tiempo como en los

recursos, reduciendo el tiempo de cientos de aos hombre a un promedio de

unas pocas semanas hombre. RCI permite hacer sus estudios con el mdulo

LEAP del software PROACT suite basndose en los datos o informacin

histrica o en la informacin probabilstica.

7

Antes de comenzar cualquier anlisis, es importante hacer un poco de trabajo

preliminar. Un FMEA no es diferente. La primera cosa que debemos lograr es

seleccionar el sistema a analizar. Por ejemplo, usted puede querer seleccionar

un subset de la planta o del proceso, y no toda la organizacin, como su

sistema a analizar. Una vez conocido qu sistema va a analizar, es el momento

de determinar la definicin de la falla para su anlisis. Podria sonar poco

importante, pero es un paso esencial en el anlisis. Si usted tuviera que

pedirles a diez personas que definieran la falla, probablemente recibira diez

respuestas diferentes. sto hara el anlisis demasiado amplio. Lo que se

necesita es una herramienta que nos mantenga enfocados en los temas ms

importantes para nuestro negocio. Por ejemplo si la utilizacin es el factor

crtico en su negocio, su definicin de falla estar desarrollada con la utilizacin

en mente; si su preocupacin principal es la calidad entonces su definicin

estara centrada en la calidad. Una definicin precisa de falla es importante ya

que no slo enfoca la atencin en los temas prioritarios sino tambin crea

buenas comunicaciones, dando una base de comn entendimiento de las

necesidades del negocio. Es disear un pliego preliminar de entrevistas y una

lista de personas a entrevistar para recolectar datos. Si usted tiene suficiente

confianza en sus sistemas de datos, entonces seria til utilizar esta informacin

para ratificar sus entrevistas ms tarde.

Habiendo obtenido la informacin necesaria durante el proceso de recoleccin

de datos, ahora es necesario resumir y codificar los resultados. Una vez que la

informacin es ingresada, usted puede utilizar esta hoja de datos para clasificar

los datos brutos por subsistemas y luego por eventos. Eso le dar un

conocimiento ms profundo de los eventos que son redundantes. A esta altura,

usted querr hacer un clculo simple para conocer sus prdidas totales para

cada evento en el anlisis. La ecuacin para este clculo es la siguiente:

Frecuencia x Consecuencia (Impacto) = Prdida Total / Ao

Habiendo completado el levantamiento de forma manual en una hoja en excel o

en el mdulo LEAP del software de RCI PROACT Suite, puede ver ahora los

8

eventos Pocos Significativos que le estn causando a usted la mayor parte de los problemas y le estn costando la mayor cantidad de dinero.

El concepto de los Pocos Significativos se deriva de un famoso economista italiano - Vilfredo Pareto. Pareto dijo: que en cualquier set o grupo de objetos,

ideas, personas y eventos, unos POCOS dentro de esos sets o grupos son

MS SIGNIFICATIVOS que los dems. A esto nos referimos como la

Separacin Pareto 80-20. Este concepto es real para la industria tambin.

El ochenta por ciento (80%) de las prdidas en una instalacin de manufactura

est representado por el 20% o menos de los eventos de fallos. Significa que

usted slo se llevar a cabo el Anlisis de Causa Raz del 20% o menos de los

eventos de fallas para reducir o eliminar el 80% de las prdidas de su negocio.

9

Para determinar los Pocos Significativos simplemente siga los siguientes pasos:

1. Saque el total de los eventos de falla en el anlisis para crear la prdida

total global.

2. Clasifique la columna de total en orden descendiente (por ejemplo: de lo

ms alto a lo ms bajo).

3. Multiplique la columna de prdida total global por 0,80 (80%). sto le

dar la cifra de prdidas de los "Pocos Significativos" que necesitar

para determinar cules son los que dan el "gran golpe" en su negocio.

4. Vaya a la parte superior de la columna de prdida total y empiece a

sumar los eventos ms importantes desde la parte superior a la inferior.

Cuando la suma de estas prdidas sea igual a mayor que la cifra de

prdidas de los "Pocos Significativos", entonces esos pocos eventos son

los "Pocos Significativos".

Resumiendo, el AMEF es una herramienta fantstica para limitar el trabajo de

anlisis a slo aquellas cosas que son de suma importancia en el negocio,

usted no puede llevar a cabo un ACR en todo. No obstante, se puede utilizar

esta herramienta para ayudar a acotar la atencin a lo que es "ms" importante

o en lo que se est perdiendo ms dinero.

Entonces se preguntaran Cundo voy usar el Anlisis Causa Raz PROACT ?:

El ACR se aplica cuando: Se presentan eventos crnicos y espordicos. Se incurra en costes operativos no adecuados. Exista la presencia de una alta probabilidad de perder la funcin de un

sistema. Exista la presencia de una alta probabilidad de presentarse un incidente

humano. Si desea conocer a travs de la representacin visual, la lgica del

porque ocurre un evento indeseable. Se desea conocer a travs de la representacin visual, la lgica del

porque ocurre un evento deseable. Desear conocer las deficiencias en los programas de entrenamiento.

10

Deseo de conocer las deficiencias de los procedimientos de operacin y mantenimiento.

Paso 2.- Preservando la informacin del evento: Preser los Datos del evento es una parte de nuestra metodologa ACR

PROACT. Este es el punto en el que se comienza a analizar un problema o evento especfico. La recoleccin de Datos es una parte integral del Anlisis de

Causa Raz (ACR). Sin los datos, es virtualmente imposible descubrir las

causas raz. Este escenario es anlogo a lo que sera un detective policial

investigando la escena de un crimen. No se puede esperar que el detective

resuelva el caso sin pistas. Lo mismo ocurre con el Analista Principal - l / ella

no puede descubrir las causas raz sin datos (pistas) Antes de comenzar con la

recoleccin de datos, exploremos la psicologa que hay detrs del porque ya

que gente no recolecta datos como parte de una rutina.

11

La primera razn es que la mayora de la gente no valora los datos para

solucionar problemas. Es fcil cambiar mediante la educacin de la gente con

las razones por las cules la informacin necesita ser recolectada y como la

misma juega un rol en el anlisis. La segunda razn, y la que creemos de

mayor frecuencia, es que la gente tiene miedo a ser culpada si de alguna

manera los datos se relacionan con ellos. Esto es lo que se conoce como

"cacera de brujas"; o sea, identificando gente para culpar la de los problemas

que ocurren. sto involucra un giro del paradigma: desde pensar que un

problema puede ser causado por un solo individuo hasta comprender que se

necesitan numerosos errores juntos de una manera tal que puedan llevar a un

evento aleatorio.

Las organizaciones deben darse cuenta que mediante la "cacera de brujas" por ejemplo, el tener como objetivo un individuo, estn perdiendo el

conocimiento de la causa raz real. Cuando se disciplina a un individuo por

haber contribuido con un error al problema, se pierde informacin valiosa sobre

12

los dems errores que llevaron al problema. Es muy simple, ACR no puede

tener xito mediante el mtodo de la "cacera de brujas". El nfasis de las

organizaciones debe estar en el obtener los datos, no en disciplinar individuos.

Este es generalmente un difcil giro del paradigma para muchas

organizaciones. No obstante, los beneficios hacen que los esfuerzos valgan la

pena. Despus de todo, la gente por naturaleza hace el mejor trabajo que

puede. Muy rara vez vienen al trabajo con la idea de cometer errores a

propsito o causar problemas deliberadamente.

Reliability Center Inc ha desarrollado las 5 Ps como un medio de ayudar al

analista a recordar los diferentes tipos de datos a recolectar. Las 5 Ps es una

sigla para Partes, Posicin, Personas, Papel y Paradigmas. Cuando un

problema de los "Pocos Significativos" ha sido identificado para analizar, ya sea

un evento espordico o crnico, los cuales tienen diferentes caractersticas, se

desarrolla una estrategia de recoleccin de datos basada en el tipo de

problema que es.

Partes: rodamientos, tuberas, muestras, cables, etc Personas: operadores, mantenedores mecnicos, electricistas, gerente de operaciones.

Papel: reportes, registros, documentacin del fabricante, histricos. Posicin: cuando ocurri, hora, fecha, nivel de presin, turno, proceso. Paradigmas: Esto siempre ha ocurrido en la planta, siempre ha funcionado as.

Nuevamente, utilizando nuestra analoga de la polica, un evento espordico es

similar en caractersticas al homicidio. En este caso, el evento espordico u

homicidio slo ha ocurrido una vez (y no se espera que vuelva a ocurrir) y el

analista o detective tiene slo una posibilidad de obtener evidencias o los datos

necesarios para resolver el crimen. Por otro lado, los problemas o eventos

crnicos son similares a los asesinos en serie.

13

Paso 3.- Ordenado el Anlisis del evento: Ordenando es otra parte de nuestra metodologa ACR PROACT. La forma convencional de formar un equipo de anlisis es mediante la asignacin a un

grupo de personas, que son expertos y tienen conocimiento relacionado

directamente al evento que se est analizando. Una vez que el equipo ha sido

formado, organizan un torbellino de ideas para poder deducir cmo ocurri el

evento y poder desarrollar recomendaciones para prevenir que el mismo vuelva

a repetirse. Superficialmente, sto parece lgico, pero en realidad, hay varias

imperfecciones con esta metodologa de equipo.

Ante todo, los equipos de este tipo se forman en base a una reaccin

espontnea a un problema. Estn respondiendo a un "incidente" que

generalmente no pertenece a los "Pocos Significativos". Reliability Center

Incorporated sugiere una metodologa ms proactiva para la formacin de

equipos de anlisis.

Nosotros sugerimos que primero se identifique a los "Pocos Significativos" y

prestando especial atencin al evento que ha sido identificado como el ms

significativo. Adems, sugerimos que se forme un equipo ACR basado en la

teora de "cerebro completo". Por medio de este criterio, el equipo estar

conformado por personas con fuertes tendencias en cada cuadrante del

cerebro versus el mismo cuadrante; o sea, lgico, conceptual, de planeamiento

e interpersonal. sto asegura que se consideren todos los aspectos del

problema o evento que sea analizado.

Los equipos creados para resolver los problemas generalmente se forman

utilizando gente tcnica que est muy familiarizada con el evento. Cuando esto

ocurre, el mecanismo del pensamiento del equipo normalmente se limita a un

cuadrante del cerebro. No se promueve el pensamiento "fuera de la caja" porque los miembros del equipo compartirn los mismos paradigmas.

Reliability Center Incorporated tambin apoya otro giro del paradigma. El

Analista Principal NO debera estar ntimamente familiarizado con el evento

14

que se est analizando. La tendencia es poner a un experto en la posicin de

lder. Reliability Center Incorporated recomienda hacer lo contrario. Lo nico en

lo que el Analista Principal debe ser un experto es en facilitar el anlisis.

Adems, el Analista Principal debera ser un individuo TENAZ. Los Analistas

Principales exitosos son siempre quellos que facilitan el anlisis de ACR sin

ser sumamente dominantes y no permitiendo que nada detenga su proceso.

Es nuestra intencin que la posicin de Analista Principal sea de dedicacin a

tiempo completo. Reliability Center Incorporated reconoce que no siempre es

posible. Sin embargo, para que el ACR funcione y produzca los resultados

deseados, la posicin de Analista Principal debe ser un puesto dedicado.

Las compaas que han tenido ms xito y han tenido los resultados ms

rpidos son siempre aquellas que han dedicado los recursos necesarios al

esfuerzo de ACR. Si no es as, se incrementar la cantidad de tiempo del

anlisis basado en un decreciente nivel de dedicacin. Por ejemplo, si el

anlisis promedio lleva dos semanas con una persona dedicada, va a llevar

cuatro semanas o ms con una persona que dedica el 50 % del tiempo y los

resultados pueden no ser tan confiables.

Los dems miembros del equipo de anlisis sern determinados por los

requisitos del problema a analizar. En un mundo "ideal", debera haber un

"Analista Asociado" para ayudar al Analista Principal.

Los Analistas Asociados son buenos para desarrollar la mayor parte del trabajo

de caminata requerido por el Analista Principal. Actividades tales como

recolectar las 5Ps, tomar notas de las entrevistas y ayudar en la verificacin de

las hiptesis son slo algunas de las maneras en las que pueden ser til.

Se debe utilizar personal de operaciones, de mantenimiento, tcnicos y de

apoyo que sea necesario. A menudo, es conveniente involucrar a los niveles

altos y medios de la administracin. Expertos, vendedores y contratistas son

generalmente irremplazables para generar las hiptesis.

15

Paso 4.- Analizando el evento: Analizando: es otra parte de nuestra metodologa ACR PROACT. Para analizar un evento o un problema hasta sus causas raz ms profundas latentes, se

necesita utilizar una metodologa disciplinada. Sin una metodologa

disciplinada, se est destinado a descubrir las causas races incorrectas y por

lo tanto implementar las soluciones incorrectas a lo que en realidad est

causando el problema.

El rbol lgico modificado de Reliability Center Incorporated trata estrictamente

con los datos reales y utiliza lgica deductiva para trabajar sistemticamente a

travs del problema para llegar a la causa raz real. Si esta metodologa es

usada en forma apropiada, se descubrirn todas las causas.

Los primeros dos niveles del rbol lgico tienen en cuenta todos los "hechos

conocidos" del problema que se est analizando. Nos referimos a estos dos

niveles como la Caja Superior y representan la definicin del evento. La

formacin de la Caja Superior es un paso crtico en la creacin del rbol lgico,

porque si el evento est definido incorrectamente, definitivamente se llegar a

las causas incorrectas del problema que se est analizando. El primer nivel de

la Caja Superior es una declaracin del evento. sta es la razn por la que se

est analizando el problema; o sea, la razn por la que Usted se preocupa. Por

ejemplo, la Fallas Recurrentes de la Bomba, Tiempo Excesivo de Paro de las

Mquinas, Cheques Perdidos, o Desperfectos Crnicos del Proceso seran

todos ejemplos de una declaracin de un evento que Usted estara interesado

en eliminar. El segundo nivel de la Caja Superior representa los modos del

problema. Estos son los modos que histricamente han ocurrido en el pasado.

No interesa analizar lo que podra haber sucedido, pero si en lo que ocurri, o

est pasando. Se pueden analizar los modos como las causas aparentes del

evento. Por ejemplo, Cul es la causa de que las mquinas se hayan parado

por un demasiado tiempo en el pasado? Una vez establecidos los hechos del

problema que se est analizando, ahora se puede comenzar a hacer hiptesis

de como pudo haber ocurrido, simplemente debe preguntarse como sto ha

ocurrido?. La clave es ser amplio e incluir todo en nuestras hiptesis. Se debe

16

empezar a hacer conjeturas ampliamente y ser ms especfico a medida que

se baja en el rbol. Quiere decir que no se incorporarn demasiadas hiptesis

en cada nivel. La idea es agrupar razones (o causas) en categoras generales.

En esencia, el rbol lgico ir de lo general a lo especfico, lgica deductiva. Se

debe hacer para asegurarse de no olvidar de nada.

El prximo paso, el ms crtico, es la verificacin de las hiptesis. Para que su

lgica deductiva contine. Se debe verificar cada hiptesis para ver cul es

verdadera y cules no lo son (puede haber pasado o no). Note que es tan

importante probar que algo no es verdad como que s lo es. La verificacin de

cada hiptesis le da la confianza necesaria que cuando llega a las causas raz,

stas sean son las correctas.

Este proceso de lgica deductiva y verificacin se reitera una y otra vez hasta

que todas las races se descubren. Aqu, es bueno notar que los problemas

rara vez ocurren en una lnea recta de la lgica. Tpicamente, los problemas

ocurren como resultado de una multiplicidad de errores. Por lo tanto, cada

17

modo del problema debe ser analizado, y las races descubiertas para eliminar

el problema. Recuerde comenzar con los hechos y verificar en cada nivel para

asegurarse de finalizar con un hecho. Si se sigue esta frmula simple, entonces

no puede equivocarse al final del anlisis.

Paso 5.- Comunicando lo encontrado y emitiendo las recomendaciones:

Comunicando: es otra parte de nuestra metodologa ACR PROACT. Cuando el anlisis ha sido completado y se han determinado las soluciones a las races

fsicas, humanas y latentes identificadas, es tiempo de convertirse en

vendedor. Para que el analista tenga xito comunicando sus hallazgos y

haciendo recomendaciones a la administracin sobre causas identificadas,

primero deben darse cuenta la posicin de la administracin con respecto al

anlisis. La administracin debe dar cuentas de la responsabilidad financiera

de la empresa. Si invierten dinero, ste debe tener una ganancia superior a la

inversin. Sabindo lo, es fcil darse cuenta que la administracin tiene algn

tipo de criterio en mente de cmo evaluarn las recomendaciones; puede no

estar escrito, pero va a estar en sus mentes. El Reliability Center Incorparated

recomienda que mejor que ir a ciegas a una reunin de presentacin y esperar

que las recomendaciones tomen vuelo, pdale a la administracin (antes de que

se desarrollen las recomendaciones) que escriba una lista de Criterios de

Aceptacin de Recomendaciones. Este es el criterio bajo el cul ellos

aceptarn o denegarn las recomendaciones. Esta tcnica le brindar un

campo de juego justo y parejo para trabajar. Le permite conocer las reglas del

juego. Si usted juega conforme a las reglas, debera ganar (o sea, lograr

obtener los recursos necesarios para implementar sus recomendaciones)

Tenga en mente que las causas raz identificadas no son negociables. Sin

embargo, las recomendaciones pueden ser diseadas para llegar a los criterios

de aceptacin preestablecidos. Despus de todo, todos han experimentado el

rechazo de ideas, propuestas y sugerencias en algn momento de sus vidas.

Uno aprende de estas experiencias determinando lo que funcion y lo que no.

Recuerde que una de las metas principales es incorporar el ACR como una

parte de la cultura. Se quiere que todos deduzcan lgicamente el porqu? del

problema. Para lograr apoyo de los dems en el proceso, se necesita que

18

participe tanta gente como sea posible y que sean reconocidos por sus

contribuciones.

Paso 6.- Totalizando los resultados de las recomendaciones tomadas: Totalizando es otra parte de nuestra metodologa ACR PROACT. El ACR es una actividad sin valor agregado si no se acta sobre las recomendaciones y

las soluciones no son implementadas en el tiempo establecido. Despus de

todo, todos hemos tenido los mejores planes para llevar a cabo una tarea, o

hemos experimentado un plan que no fue implementado aunque tuvo

aprobacin de la administracin. Es extremadamente frustrante dar

recomendaciones de soluciones a problemas, haber asignado

responsabilidades para la implementacin, y haber establecido un plan de

tiempo para su realizacin, y an as no ver los frutos de los esfuerzos.

Generalmente, la gente es bien intencionada cuando se trata de establecer un

plan de accin. Sin embargo, despus de que se desarroll el plan y los

19

participantes vuelven a sus ambientes, tienden a volver directamente al surco

reactivo; o sea, el problema del da parece siempre tener prioridad sobre el

trabajo de mejora. Los jugadores siguen postergando diciendo: puede

esperar. Pero realmente puede esperar? Si todo lo que se hace es trabajo

reactivo, nunca habr progreso. Por lo tanto, es primordial que se tome control

de los operaciones en vez de permitir que las operaciones tomen control de

usted. Para poder obtener los recursos necesarios que se necesita dedicar al

trabajo de maana; o sea, trabajo de mejora, usted debe analizar sus

problemas hasta las causas raz y actuar de acuerdo a sus hallazgos.