CONFIABILIDAD OPERACIONAL DE EQUIPOS: METODOLOGAS Y HERRAMIENTAS

FERNANDO ESPINOSA FUENTES

NDICE
CONFIABILIDAD OPERACIONAL ANLISIS CAUSA RAZ: RBOL LGICO ANLISIS CAUSA RAZ: RBOL DE EVENTOS EL MTODO KEPNER- TREGOE O MATRIZ DEL PERFIL COMPETITIVO 5 PORQUS PARA RESOLVER PROBLEMAS DIAGRAMA DE ISHIKAWA PARA LA CAPTURA DE LAS SOLUCIONES HAZARD AND OPERABILITY (HAZOP) DESARROLLANDO UN ANLISIS DEL MODO DE FALLA Y EFECTO (FMECA) EL ENFOQUE META, PREGUNTA, METRICA ANLISIS DEL COSTO DEL CICLO DE VIDA 1 5 12 22 26 29 33 44 53 60

ii

CONFIABILIDAD OPERACIONAL
La Ingeniera de la Confiabilidad se destaca como el marco terico en el cual conviven las metodologas y tcnicas necesarias para la optimizacin del uso de los activos fijos. La confiabilidad de un sistema o un equipo, es la probabilidad que dicha entidad pueda operar durante un determinado periodo de tiempo sin prdida de su funcin. El fin ltimo del Anlisis de confiabilidad de los activos fsicos es cambiar las actividades reactiva y correctivas, no programadas y altamente costosas, por acciones preventivas planeadas que dependan de anlisis objetivos, situacin actual e historial de equipos y permitan un adecuado control de costos. La Confiabilidad Operacional se define como una serie de procesos de mejora continua, que incorporan en forma sistemtica, avanzadas herramientas de diagnstico, metodologas de anlisis y nuevas tecnologas, para optimizar la gestin, planeacin, ejecucin y control de la produccin industrial. La Confiabilidad Operacional lleva implcita la capacidad de una instalacin (procesos, tecnologa, gente), para cumplir su funcin o el propsito que se espera de ella, dentro de sus lmites de diseo y bajo un especfico contexto operacional. Es importante, puntualizar que en un sistema de Confiabilidad Operacional es necesario el anlisis de sus cuatro parmetros operativos: confiabilidad humana, confiabilidad de los procesos, mantenibilidad y confianza de los equipos; sobre los cuales se debe actuar si se quiere un mejoramiento continuo y de largo plazo. Estos cuatro elementos se muestran en la fig. 1:

Fig. 1: Factores de la Confiabilidad Operacional

Un proceso de desarrollo de la Confiabilidad Operacional implica cambios en la cultura de la empresa, creando un organismo diferente con un amplio sentido de la productividad y con una visin clara de los fines del negocio. La variacin en conjunto o individual que pueda sufrir cada uno de estos custro aspectos mostrados, afecta el desempeo general del sistema. Cualquier hecho aislado de mejora puede traer beneficios, pero no al considerarse los dems factores, sus ventajas son limitadas o diluidas en la organizacin y pasan a ser el resultado de un proyecto y no de un cambio organizacional. La confiabilidad en mantenimiento se estudia como la probabilidad que un equipo sobreviva sin fallas un determinado perodo de tiempo bajo determinadas condiciones de operacin. Sin embargo esta definicin no demuestra en realidad todos los alcances que conlleva. La confiabilidad es ms que una probabilidad; es una nueva forma de ver el mundo, en realidad es una cultura que debe implementarse a todos los niveles de la industria desde la alta direccin hasta el empleado de ms bajo nivel. La confiabilidad como cultura busca que todas las actividades de produccin y en general todas las tareas se efecten bien desde la primera vez y por siempre; no se acepta que se hagan las cosas precariamente o a medias. Esto implica un cambio en la mentalidad de todo el personal de la planta, nuevas formas de pensar y actuar, nuevos paradigmas; por esto es de radical importancia que la direccin de la empresa tome conciencia de la nueva situacin y de su dificultad de conseguirla. Inculcar un cambio en la forma de pensar no es sencillo, cuesta gran cantidad de trabajo y tiempo; la direccin debe enfocar sus esfuerzos en la formacin de sus empleados mediante polticas que permitan la participacin del personal en planes de mejoramiento continuo de procesos, crculos de participacin y dems elementos que persigan alcanzar los objetivos propuestos. Todo lo anterior requiere de soporte gerencial de alto nivel y convencimiento de que no es una tarea fcil ni a corto plazo, donde se debe hacer una gran inversin de capital y tiempo, en capacitacin y reconocimiento y donde lo logros superan con creces las predicciones.

Aplicacin de la Confiabilidad Operacional

Las estrategias de Confiabilidad Operacional se usan ampliamente en los casos relacionados con: Elaboracin de los planes y programas de mantenimiento e inspeccin de equipos e instalaciones industriales. Solucin de problemas recurrentes en los activos fijos que afecten los costos y la efectividad de las operaciones. Determinacin de las tareas que permitan minimizar riesgos en los procesos, equipos e instalaciones y medio ambiente. Establecer procedimientos operacionales y prcticas de trabajo seguro. Determinar el alcance y frecuencia ptima de paradas de planta. La Confiabilidad Operacional impulsa el establecimiento de tecnologas optimizacin industrial, entre las cuales se pueden destacar: que faciliten la

Modelaje de sistemas, en la confiabilidad operacional se gasta a nivel de elementos (equipos, procesos y clima organizacional) y se recibe beneficios a nivel de planta. Confiabilidad Organizacional, llamada tambin en forma sesgada error humano siendo este el ancla ms fuerte. Gestin del Conocimiento, valor agregado de nuevas prcticas y conocimientos, a travs de mediciones sistmicas, bancos de datos, correlaciones, simulaciones, minera de datos y estadsticas. Manejo de la incertidumbre, a travs del anlisis probabilstico de incertidumbre y riesgo asociado. Optimizacin Integral de la Productividad, a travs de pruebas piloto en seguridad y confiabilidad desde el diseo.

Herramientas de Confiabilidad Operacional

La confiabilidad como metodologa de anlisis debe soportarse en una serie de herramientas que permitan evaluar el comportamiento del activo de una forma sistemtica a fin de poder determinar el nivel de operatividad, la cuanta del riesgo y las dems acciones de mitigacin que se requieren, para asegurar su integridad y continuidad operacional. Son mltiples las herramientas de que se sirve la confiabilidad con el fin de formular planes estratgicos para lograr la excelencia en las actividades e mantenimiento. Las seis que se muestran en la Fig. 2, a continuacin son las ms utilizadas:

Fig. 2: Herramientas para la Confiabilidad Operacional

3

Anlisis de Criticidad (CA). Es una tcnica que permite jerarquizar sistemas, equipos e instalaciones, en funcin de su impacto global, con el fin de facilitar la toma de decisiones. Anlisis de Modos y efectos de Falla y Criticidad (FMECA). Es una metodologa que permite determinar los modos de falla de los componentes de un sistema, el impacto y la frecuencia con que se presentan. Anlisis Causa Raz (RCFA). Es una tcnica sistemtica que se aplica con el objetivo de determinar las causas que originan las fallas, sus impactos y frecuencias de aparicin, para poder mitigarlas o eliminarlas. Inspeccin Basada en Riesgos (RBI). Es una tcnica que permite definir la probabilidad de falla de un equipo o sistema, y las consecuencias que las fallas pueden generar sobre la gente, el ambiente y los procesos. Anlisis Costo Riesgo Beneficio (BRCA). Es una metodologa que permite establecer una combinacin ptima entre los costos de hacer una actividad y lo logros o beneficios que la actividad genera, considerando el riesgo que involucra la realizacin o no de tal actividad. Costo del Ciclo de Vida (LCC). El anlisis LCC es una metodologa que permite elegir entre opciones de inversin o acciones de incremento de la confiabilidad con base en su efecto en el costo total del ciclo de vida de un activo nuevo o en servicio.

ANLISIS CAUSA RAZ: RBOL LGICO

INTRODUCCIN
La mayora de los analistas de fallas han escuchado el trmino: Anlisis de Causa Raz (RCA por sus siglas en ingls) y seguramente cada quin tiene una interpretacin diferente de su significado. Esta es la razn por la cual en muchos casos se tiene una forma poco efectiva de usarlo, y hay comunicacin deficiente o nula entre quienes lo usan. Si se est usando diversas formas de RCA, entonces, al comparar los resultados no se estar comparando "manzanas con manzanas". Desde la evolucin del Mantenimiento Productivo Total (TPM) ha habido un movimiento consistente hacia la exploracin de la calidad del proceso en vez de la calidad del producto. Antes de la llegada del TPM, las organizaciones de calidad se contentaban con medir la calidad del producto terminado como sala de la lnea. An cuando admirable esa medida era demasiado tarda si se hallaban defectos de calidad. El producto, y probablemente todo el lote tena que ser reprocesado a un alto costo para la organizacin. Entonces se introdujeron los principios de W. Edwards Deming e impulsaron el concepto de "calidad del proceso". En pocas palabras, esto significa que se debe medir variables clave en el proceso para detectar cualquier variacin inaceptable. De esta manera, se corrige la variacin en el proceso y se evita la manufactura de productos fuera de especificacin. Esta era se est continuando actualmente con la introduccin del ndice de calidad Seis Sigma (99.999996% calidad). Como se discuti anteriormente, RCA tiene diferentes significados para diferentes personas. Algunos aplican esfuerzos indisciplinados como el mtodo de "prueba y error" como su perspectiva de RCA. Esto significa que se percatan de un problema, y se va directo a lo que es la causa ms obvia, PARA LOS ANALISTAS!. Usando la perspectiva del "producto terminado" no se valida ninguna de las suposiciones, simplemente se adopta una y se gasta dinero en un arreglo esperando que funcione. La experiencia ha demostrado que esta forma de hacerlo es cara e inefectiva. Ahora, aplicando un sistema disciplinado tipo TPM de RCA, un rbol Lgico permite representar grficamente las relaciones de causa y efecto que conducen a descubrir el evento indeseable y cul fue la causa raz del problema. En este procedimiento, se debe identificar claramente el evento indeseable y todos sus detalles asociados mediante hechos que los respalden. Los hechos deben respaldarse con observacin directa, documentacin y algunos conceptos cientficos. No pueden ser rumores ni suposiciones! Por ejemplo, en el caso que se presenta enseguida, la mayora de las personas insistiran en comenzar con la falla del rodamiento. Sin embargo, cuando el evento se present, por qu llam la atencin? No llam la atencin el rodamiento fallando, sino el hecho de que la bomba dej de proveer el fluido. Por lo tanto el evento final que llam la atencin fue la falla de la bomba. Una razn o modo de que la bomba fallase fue debido a la falla del rodamiento. Esto resulta evidente cuando se ve el rodamiento daado (evidencia fsica). La parte alta del rbol Lgico se ver as (Fig. 3):

Fig. 3: Evento no deseado Continuando con la bsqueda en retrospectiva de la causa y relaciones de los efectos, se pregunta: Cmo puede fallar un rodamiento? Las hiptesis pueden ser: erosin, corrosin, fatiga, lubricacin o sobrecarga. Cmo se puede verificar cul de ellas es la verdadera causa? Simplemente se puede solicitar que un laboratorio metalrgico y un experto hagan un anlisis del rodamiento. Para efectos de este ejemplo, se supone que el reporte indica que slo hubo signos de fatiga, ahora el "rbol Lgico" avanzar un nivel, y se ver como en la figura 4:

Fig. 4: Causas de la falla de un rodamiento Se puede ver que a medida que se desarrollan nuevas series de hiptesis, se ir probando lo que se dice a cada nivel del proceso. A medida que avanza este proceso reiterativo, se van validando las conclusiones a cada paso del camino. De esta forma, cuando se llega a conclusiones en cada etapa, esas conclusiones sern las correctas, porque no se estn haciendo suposiciones, sino se estn

basando en "hechos". Esto tambin implica que se comprometen a efectuar gastos para poder superar las causas que se identifican, que se invertir dinero en evitar que el problema se repita. En un esfuerzo por mover nuestras culturas hacia la precisin, se deben usar los conceptos de TPM en los procesos administrativos tambin. La perspectiva del TPM es aplicable a: Maquinaria, Procesos y Situaciones Humanas. As que para algunos, RCA es pedir que un experto local les proporcione una solucin al problema, mientras para otros, representa el reunirse y discutir para llegar a una conclusin; para otros ms, RCA representa usar un proceso disciplinado de pensamiento hasta llegar a la verdadera causa original del problema. 1) Cuando el "experto" proporciona una solucin, se confa, se hace un gasto para aplicar la solucin que propuso, y se ve si funciona. A veces s funciona, otras no. Esto equivale a la inspeccin de calidad a la salida de la planta. Es demasiado tarde si hay un error! 2) Cuando se forman grupos y participan en tormentas de ideas, se estar llegando a conclusiones como resultado del consenso de los participantes. Se est basando en opiniones. Quizs usaron un proceso formal como el diagrama de espina de pescado, pero no hay hechos claros que respalden esas opiniones. De nuevo se est verificando la calidad del producto al final del proceso, y no durante el mismo. 3) Cuando los grupos de trabajo usan un proceso disciplinado que requiere que las hiptesis sean desarrolladas para ver exactamente por qu ocurrieron las causas, y luego requiere tambin una verificacin para asegurar si es o no cierto, entonces se est usando Calidad en el Proceso, en vez de basarse en suposiciones y estar expuestos a la ignorancia. Para demostrar estos puntos, vea el siguiente diagrama abreviado (Fig. 5). Arriba se describe un proceso disciplinado de pensamiento lgico en la eliminacin de variables no relacionadas al RCA. Regresando a los anteriores escenarios de RCA. Si una bomba crtica fallara, dado el caso, se tratara que los mejores de nuestros tcnicos la fueran a ver. Quizs concluiran luego de una gran discusin, que lo que se necesita es un rodamiento de trabajo ms pesado.... Dadas las condiciones que se han analizado en el diagrama, se resolvera el problema en forma permanente? Naturalmente que no !. O qu tal si todos los tcnicos de mantenimiento se renen y deciden que lo que est mal es el tipo de lubricante que se est usando...pues tampoco con esa accin se resolvera el problema en forma definitiva y permanente. Este ltimo es un concepto enraizado y con muy poco argumento, muchas personas del que hacer del mantenimiento emiten esta crtica sin ninguna base slida o respaldo documentado. En cambio si se usa el proceso disciplinado del diagrama, se har examinar el rodamiento por un metalurgista o un experto, quien reportar (de manera cientfica) que hay evidencia de que existe fatiga en el material. Se preguntar entonces: qu puede estar causando esa fatiga en el rodamiento? Se establece hiptesis: puede ser por vibracin excesiva.

Fig. 5: Causas de una alta vibracin

Se verifican los registros y se confirma que haba demasiada vibracin. Qu puede estar causando la vibracin? Hiptesis: Puede ser por desbalanceo, resonancia o desalineamiento. Se le pide al mecnico que la aline la ltima vez que describa y muestre el procedimiento de alineacin usado. Al preguntarle, se enteran que l no ha sido entrenado al respecto, sus herramientas no estn en buen estado, y adems no existe un procedimiento a seguir. Ahora se est en conocimiento de la REAL causa raz, as que se pueden desarrollar las soluciones que, una vez implementadas, TRABAJARN!!!

Usando este proceso disciplinado se genera un producto (en este caso un servicio de mantenimiento), de mucha calidad. Se sabe que la solucin trabajar porque se obtuvo por el proceso de calidad. Mientras los estilos indisciplinados de RCA son atractivos para las organizaciones por la rapidez de sus resultados, no siempre esos resultados son de calidad. El verdadero RCA requiere que se tome el tiempo necesario para probar lo que se dice en vez de hacer el gasto o el esfuerzo y arriesgar a estar equivocados. Ahora cabe la pregunta cul es el papel que desempea el encargado del anlisis? La funcin del ingeniero ser simplemente la de determinar cientficamente CMO ocurri el evento. Esto significa que una serie de causas-efectos se sucedieron hasta llegar a un evento no deseable. Su papel es el de probar que cada hiptesis, sucedi o no sucedi. Los ingenieros proporcionan las piezas "CMO?" del rompecabezas y es a los detectives del mantenimiento a quienes les corresponde determinar "POR QU?" se caus el problema. Usando tecnologa: por ejemplo monitoreo de vibracin, imgenes trmicas infrarrojas, anlisis de esfuerzos, anlisis de aceite, etc. para probar o eliminar las hiptesis, pero toca a los analistas determinar por qu la persona o personas tomaron decisiones o efectuaron acciones que resultaron en un problema o falla. Vea el diagrama de la Fig. 6. El resultado indeseable es la falla de la bomba de cumplir con su funcin designada. En el intento para construir un "caso slido", se deber asociar las inequvocas causas-efecto que desembocaron en la falla. Esto incluye poner en juego los recursos cientficos, propios o contratados, para probar la hiptesis. Explorando en este caso... El resultado indeseable fue que la bomba dej de efectuar su funcin asignada. Para lograr un "caso slido" se deber entender las relaciones causa-efecto que dieron como resultado tal evento. Esto implicar el uso de dispositivos y recursos cientficos para probar o eliminar las hiptesis. En el caso que se ilustra se puede ver "CMO?" la bomba pudo fallar y se usa la ciencia para probar el caso. Hiptesis Erosin, Corrosin, Fatiga y Sobrecarga Alta Vibracin Desalineamiento Tcnicas de Verificacin Anlisis Metalrgico Instrumentos y Vigilancia de la Vibracin Tecnologa de Alineacin Lser

Estas relaciones aclaran el "CMO?", y el "POR QU?" En este caso alguien dej la bomba desalineada y tal accin o decisin caus una serie de causas y efectos para que finalmente la bomba fallase prematuramente. Los "ingenieros forenses" ya determinaron cmo sucedi, pero Por qu alguien habra de dejar mal alineada la bomba? Es aqu donde se debe entender los motivos por los que la gente actu errneamente. Como analistas, si se va a profundidad en el proceso de pensamiento, se llegar a saber Por qu la persona o personas tomaron tal decisin o accin? (Raz Latente), se descubrir exactamente la CAUSA RAZ y el por qu de la falla fsica. Se podra ver que la gente con frecuencia deja el equipo desalineado porque:

Nunca han sido entrenados en prcticas apropiadas de alineamiento No existe un procedimiento que defina el alineamiento y sus especificaciones como una prctica requerida El sistema que se est utilizando est desgastado o descalibrado en algunos casos.

Fig. 6: El cmo y el por qu de la falla del activo

Si no se explora el "Por qu?, es posible que el Cmo? se vuelva a presentar una y otra vez. En el caso anterior, creen ustedes que el slo cambiar el rodamiento eliminar el problema en forma permanente? An si se identifica una vibracin excesiva y se toman medidas para identificarla ms
10

pronto la prxima vez antes que la bomba falle, ser la forma de eliminar el problema? Si se castiga al mecnico por no haber alineado correctamente, se evitar la falla recurrente? Como se puede ver, ninguna de esas soluciones que con frecuencia son implementadas, evitara la recurrencia de la falla en la bomba. Slo con una accin efectiva sobre el Por qu? Se podr evitar que ocurra la falla nuevamente. Si se reflexiona en los esfuerzos de RCA (Anlisis de Causa Raz), Dnde califican?, Se estn deteniendo en el Cmo? (al nivel del forense). O estn llegando al Por qu? (nivel del detective).

11

ANLISIS CAUSA RAZ: RBOL DE EVENTOS

El Anlisis Causa Raz (RCA) es un proceso diseado para su uso en la investigacin y la categorizacin de las causas de los acontecimientos relacionados con la seguridad, la salud, el medio ambiente, calidad, fiabilidad y que repercute en la produccin. El trmino "evento" se utiliza para identificar de forma genrica los sucesos que producen o tienen el potencial para producir este tipo de consecuencias. En pocas palabras, la RCA es una herramienta diseada para ayudar a identificar no slo qu y cmo se produjo un evento, sino tambin por qu sucedi. Slo cuando los investigadores son capaces de determinar por qu un suceso o la falla se produjeron van a ser capaces de especificar las medidas correctivas viables que eviten futuros eventos del tipo observado. Entender por qu se produjo un evento es la clave para desarrollar recomendaciones eficaces. Imaginar un suceso durante el cual se encarg a un operador cerrar la vlvula A, en cambio, el operador cerr la vlvula B. La investigacin tpica probablemente llegara a la conclusin que un error del operador fue la causa. Esta es una descripcin exacta de lo que ocurri y cmo ocurri. Sin embargo, si los analistas se detienen aqu, no han investigado lo suficiente como para entender las razones para el error. Por lo tanto, no saben qu hacer para evitar que ocurra de nuevo. Para el caso en que el operador cerr la vlvula equivocada, es probable que se redacten las recomendaciones para volver a entrenar al operador en el procedimiento, recordar adems a todos los operadores que deben estar alerta cuando procedan con la manipulacin de las vlvulas o destacar a todo el personal que la atencin cuidadosa al trabajo se debe mantener en todo momento. Estas recomendaciones ayudan poco ms para evitar que se repitan en el futuro. En general, los errores no ocurren por casualidad, pero se puede remontar a algunas de las causas bien definidas. En el caso de la vlvula del error, se podra preguntar: "Fue el procedimiento confuso? Estaban las vlvulas claramente identificadas? Estaba el operador familiarizado con esta tarea en particular? " Las respuestas a estas y otras preguntas le ayudarn a determinar por qu ocurri el error (falla) y lo que la organizacin puede hacer para prevenir la recurrencia en el caso del error de la vlvula. Unas recomendaciones, por ejemplo, podran incluir la modificacin del procedimiento o la realizacin de los procedimientos de validacin para asegurar que las referencias a las vlvulas coincidan con las etiquetas de las vlvulas que se encuentra en la fbrica. La identificacin de las causas fundamentales es la clave para la prevencin de recurrencias similares. Un beneficio adicional de un efectivo RCA es que, con el tiempo, las causas identificadas en la poblacin de los sucesos pueden ser utilizadas para identificar las principales oportunidades de mejora.
12

Si, por ejemplo, un nmero significativo de los anlisis apuntan a las deficiencias de contratacin, los recursos pueden ser enfocados en el mejoramiento de este sistema de gestin. Las tendencias de las causas permite el desarrollo de mejoras y evaluacin sistemtica del impacto de los programas correctivos.

Definicin
Para la definicin de la causa raz, se basa en lo siguiente: 1. 2. 3. 4. Las causas fundamentales son especficas de las causas subyacentes. Las causas fundamentales son las que razonablemente se puede identificar. Las causas fundamentales son las que gestin tiene el control de arreglar. Las causas fundamentales son aquellas en las que se pueden generar recomendaciones eficaces para la prevencin de recurrencias.

Las causas fundamentales son producto de las causas subyacentes. El objetivo del investigador debe ser la identificacin de causas subyacentes especficas. Cuanto ms especfico sea el investigador acerca del por qu se produjo un evento, ms fcil ser llegar a las recomendaciones que eviten recurrencia. Las causas fundamentales son las que razonablemente se puede identificar. La investigacin de incidentes debe estar apoyada en la razn costo-beneficio. No es prctico mantener la mano de obra valiosa ocupada indefinidamente en la bsqueda de las causas de los sucesos. Un RCA estructurado ayuda a los analistas a sacar el mximo partido del tiempo que han invertido en la investigacin. Las causas fundamentales son aquellas sobre las que la gestin tiene el control. Los analistas deben evitar el uso de las clasificaciones generales de las causas, como un error del operador, fallas de equipos o factor externo. Esas causas no son lo suficientemente especficas como para permitir que la administracin haga cambios que tengan efecto. La administracin necesita saber exactamente por qu se produjo una falla antes de que puedan ser tomadas acciones para prevenir la recurrencia. Tambin hay que identificar la causa raz donde la gestin de la organizacin pueda influir. La identificacin de "mal tiempo" como la causa fundamental de que las partes no se entreguen a tiempo a los clientes no es apropiada. El clima severo no es controlado por la administracin. Las causas fundamentales son aquellas para las que se pueden generar recomendaciones efectivas. Las recomendaciones deben directamente abordar las causas fundamentales identificadas durante la investigacin. Si los analistas llegan a recomendaciones vagas como "mejorar la adhesin a las polticas y procedimientos escritos," entonces probablemente no ha encontrado unas causas bastante bsicas y especficas y necesitan gastar ms esfuerzo en el proceso de anlisis.
13

Cuatro pasos importantes

La RCA es un proceso de cuatro etapas que implica lo siguiente: 1. 2. 3. 4. Recopilacin de datos. Grficas del factor causal Identificacin de la causa raz. Generacin de recomendacin e implementacin.

Paso 1 - recopilacin de datos. El primer paso en el anlisis consiste en reunir los datos. Sin la informacin completa y una comprensin de los eventos, los factores causales y las causas asociadas con el evento no pueden ser identificados. La mayora del tiempo que se usa en el anlisis de un evento es en la recoleccin de datos. Paso 2 - grficas de los factores causales. Las grficas del factor(es) causal proporcionan una estructura a los investigadores para organizar y analizar la informacin recopilada durante la investigacin e identificar las vacios y deficiencias en el conocimiento a medidas que la investigacin avanza. La carta del factor causal es simplemente un diagrama de secuencias con las pruebas lgicas que describen los acontecimientos que condujeron a un evento, adems de las condiciones que rodean estos eventos (Ver Fig. 7). La preparacin de la tabla de factor causal debe comenzar tan pronto como los investigadores comienzan a recopilar informacin acerca de la ocurrencia. Se inicia con un diagrama preliminar que se modifica a medida que ms datos relevantes no estn cubiertos. La tabla de factor causal debe conducir el proceso de recoleccin de datos mediante la identificacin de las necesidades de datos. La recoleccin de datos contina hasta que los investigadores estn satisfechos con la minuciosidad de la tabla (y por tanto est satisfecho con la minuciosidad de la investigacin). Cuando el suceso se ha trazado a totalidad, los investigadores estn en una buena posicin para identificar los principales contribuyentes a los incidentes, llamadas factores causales. Los factores causales son los contribuyentes (los errores humanos y fallas de los componentes) que, si se eliminan, se habra evitado la ocurrencia o reducido su gravedad. En muchos de los anlisis tradicionales, al factor causal ms visible se le da toda la atencin. Rara vez, sin embargo, hay un solo factor causal, los eventos son generalmente el resultado de una combinacin de los contribuyentes. Cuando slo uno de los factores causales evidentes es tratado, la lista de recomendaciones probablemente no ser completa. En consecuencia, la aparicin puede repetirse porque la organizacin no aprendi todo lo que poda del evento.

14

Quemador Quemador elctrico en corto circuito FC FC Factor Causal

Cacerola El arco calienta el fondo de aluminio de la cacerola

Cacerola Aluminio se funde, forma un agujero en la cacerola

No haba sido recargado originalmente? Extinguidor de fuego

Julia Julia llega hasta la puerta de entrada

Conclusin Grasa arde da contacto con el quemador

Tiene goteras? Ubicacin del extinguidor

Mara y Julia Julia toca el timbre

Asumido El fuego genera humos

Mara El fuego comienza en la cocina Mara y Julia Detector de humo da la alarma Alrededor 17:10

Qu fue lo que vio exactamente? Mara

Haba sido usado previamente? Tarjeta de inspeccin

Mara Mara deja el pollo frindose desatendido FC

Mara Mara ve el fuego en la cocina

Mara El extinguidor no est recargado

Mara Maria se encuentra con Julia 10minutos

Mara Mara comienza a freir el pollo Hora: 17.00

Mara Mara corre hacia la cocina

Mara Mara trata de usar el extinguidor de fuego

Mara El extinguidor no funciona cuando se necesit FC

Cacerola Mara usa una cacerola de aluminio

Cunto aceite usa? Cul es la cantidad de pollo? Pollo, aceite, cacerola

Mara Mara acciona el gatillo del extinguidor

El gatillo calza bien en el accionador? Mara

Sabe Mara accionar el extinguidor? Mara

Fig. 7: Grfica de los factores causales

15

Saba ella que eso estaba mal?Falta de prctica con el combate al fuego? Mara Trat de hacer algo ms? Mara

Qu estaba haciendo Julia en ese momento? Mara, Julia

Mara, cacerola El fuego fue grasa ardiendo

Estaba Mara tratando de hacer esto? Mara

Cunto fue la demora de los bomberos? Despachador

Usaron los bomberos las tcnica correctas? Bomberos

Mara Mara arroja agua a la cocina FC

Cocina, Mara El fuego se esparce a travs de la cocina

Mara, Bomberos Mara llama a los bomberos Hora?

Observacin Los bomberos llegan Hora?

Bomberos, obs. Los bomberos apagan el fuego Hora?

La cocina destruida por el fuego

Otras prdidas por el humo y el agua

Fig. 7(cont.): Grfica de los factores causales

Paso 3 - identificacin de la causa raz. Despus que todos los factores causales han sido identificados, los investigadores comienzan identificacin de causas raz. Este paso implica el uso de un diagrama de decisin llamado el Mapa de Causa Raz (vea Fig. 8) para determinar la causa o las razones de cada factor causal. El mapa estructura el proceso de razonamiento de los investigadores, ayudndoles a responder a las preguntas acerca de por qu determinados factores causales existen o se produjeron. La identificacin de las causas fundamentales ayuda al investigador a determinar las razones de la ocurrencia del suceso como de los problemas que rodean la ocurrencia para que puedan ser abordados.

16

Comenzar aqu para cada factor causal 1 MqA : Menos que Adecuado Dificultad en el equipo

Problema en el diseo del equipo

Problemas en el programa de confiabilidad

Instalacin / fabricacin

Mal uso del equipo 2

Input/Output del diseo

Datos del equipo

Diseo del programa de confiabilidad MqA

Implementacin del programa de confiabilidad MqA

Sistema de gestin administrativo

Procedimientos

Input del diseo MqA Output del diseo MqA

Datos de diseo del equipo MqA Datos de operacin / historial de mantenimiento del equipo MqA

Sin programa Programa MqA Procedimientos /Anlisis MqA Asignacin del tipo de mantenimiento inapropiado Criterios de aceptacin del riesgo MqA Asignacin de recursos MqA

Mantenimiento correctivo MqA Resolucin de problemas/acciones correctivas MqA Implementacin de reparaciones MqA Mantenimiento preventivo MqA Frecuencias MqA Alcances MqA Implementacin de actividades MqA Mantenimiento Predictivo MqA Deteccin MqA Monitoreo MqA Resolucin de problemas/acciones correctivas MqA Implementacin de actividades MqA

Mantenimiento proactivo MqA Especificacin de los eventos MqA Monitoreo MqA Alcances MqA Implementacin de actividades MqA Bsqueda de fallas de Mantenimiento MqA Frecuencia MqA Alcances MqA Resolucin de problemas/acciones correctivas MqA Implementacin de reparos Rutinas de inspeccin de equipos MqA Frecuencias MqA Alcances MqA Implementacin de actividades MqA

Estndares, polticas o controles administrativos (EPCA) MqA Sin EPCA No son suficientemente estrictos Confusos, contradictorios o incompletos Tcnicamente errneos Responsabilidad/actividad para el tem inadecuada definicin Planeamiento/programacin o seguimiento de las actividades del trabajo MqA Premios/incentivos MqA Seleccin/contratacin de empleados MqA

EPCA no son usados La comunicacin de los EPCA MqA Cambiados recientemente Aplicacin MqA

Control del producto/ material Manejo MqA Almacenamiento MqA Embalaje/despacho MqA Sustitucin del material no Revisin del riesgo su autorizada seguridad /posibilidad Criterios de aceptacin del Revisin MqA o no ejecutada producto MqA Las recomendaciones an Inspeccin del producto MqA no son implementadas El criterio de aceptacin MqA Control de identificacin de Revisin de los los problemas procedimientos MqA Reportes de los problemas MqA Anlisis de los problemas MqA Auditora MqA Acciones correctivas MqA Acciones correctivas an no implementadas

Control del abastecimiento Especificaciones de compra MqA Control de cambio en las especificaciones de compra MqA Requisitos de aceptacin de materiales MqA Inspeccin de materiales MqA Seleccin de contratistas MqA Interfaces/servicios Requerimientos del cliente no identificados Necesidades del cliente no focalizadas Implementacin MqA

Control de documentos y configuracin Cambio no identificado Verificacin del diseo/ cambio de campos MqA La documentacin no contiene datos actualizados Control oficial de documentos MqA

No usados No disponible o inconveniente para obtener Procedimiento difcil de usar Uso no requerido pero est Tarea sin procedimientos

Engaoso/confuso Formato confuso o MqA Ms de una accin por paso No hay especio para marcar pero se necesita Lista de chequeo inadecuada Grficas MqA Instrucciones/requerimientos ambiguos o confusos Datos/mal calculados/incompletos Insuficientes o execivas referencias Identificacin o revisin de pasos MqA Nivel de detalle MqA Dificultad para identificar

Errneo/incompleto Errores tipogrficos Secuencia equivocada Hechos errneos/requerimientos no correctos Revisin errada o procedimiento expirado Inconsistencia entre requerimientos Incompleta/situacin no cubierta Traslape o vacios entre procedimientos

Fig. 8: Mapa de Causa Raz

17

MqA : Menos que Adecuado

Comenzar aqu para cada factor causal 1

Dificultad en el personal

Otras dificultades

Empleados de la compaia

Empleados contratistas

Fenmenos naturales

Sabotajes/ payasadas

Eventos externos

Otros

2 Ingeniera factor humano Entrenamiento Supervisin inmediata Comunicaciones Eficiencia del personal

Disposicin lugares de trabajo Controles/visualizadores MqA Control/Integracin visualizadores/ arreglos MqA Ubicacin de los controles/ visualizadores MqA Disposiciones conflictantes Ubicacin de equipos MqA Etiquetados de los equipos o ubicaciones MqA Carga de trabajo Accin con requerimientos de excesivo control Requerimientos no reales de monitoreo Decisin requerida basada en el conocimiento Excesivo clculo requerido o manipulacin de datos Ambiente de trabajo Limpieza MqA Herramientas MqA Ropa protectora/equipos MqA Condiciones ambientales MqA Otros stress ambientales excesivos Sistema sin tolerancia Errores no detectables Errores no corregibles

Sin entrenamiento Decisin de no entrenar Requerimientos de entrenamiento no identificados Sistema de manuales de entrenamiento MqA Manuales de entrenamiento incorrectos Manuales de entrenamiento no actualizados Entrenamiento MqA Anlisis trabajo/tarea MqA Diseo del programa/ objetivos MqA Contenidos de la lecciones MqA Entrenamiento en el lugar de trabajo MqA Pruebas de calificacin MqA Entrenamiento continuo MqA Recursos para entrenamientos MqA Entrenanmiento para situaciones no normales/ emergencias MqA

Preparacin Sin preparacin Plan de trabajo MqA Instrucciones a los trabajadores MqA Tutoras MqA Programacin MqA Seleccin de trabajadores/ asignacin MqA Supervisin durante el trabajo Supervisin MqA Ejecuciones inapropiadas no corregidas Equipos de trabajo MqA

Sin comunicacin o fuera de tiempo Mtodo inviable o MqA Comunicacin entre grupos de trabajo MqA Comunicacin entre grupos de trabajo y administracin MqA Comunicacin con los contratistas MqA Comunicacin con los usuarios MqA Comunicacin sin entender Terminologa estandarizada no usada Verificacin / validacin no usada Mensajes largos Instrucciones erradas Rotacin del trabajo MqA Comunicacin con los grupos de trabajo (turnos) MqA Comunicacin entre grupos MqA

Deteccin de problemas MqA *Capacidad sensorial/ precepcin MqA *Capacidades de razonamiento MqA *Capacidades motoras/fsicas MqA *Actitud/atencin MqA *Descanso/dormir MqA (fatiga) *Problemas personales/ medicacin

Fig. 8 (cont.): Mapa de Causa Raz

Paso 4 - recomendaciones generales e implementacin. El siguiente paso es la generacin de recomendaciones. Siguiendo la identificacin de las causas raz de un factor causal en particular, se generan las recomendaciones factibles para la prevencin de su recurrencia. El analista de la causa raz a menudo no es el responsable de la aplicacin de las recomendaciones generadas por el anlisis. Sin embargo, si las recomendaciones no son implementadas, el esfuerzo puesto en la realizacin del anlisis se desperdicia. Adems, los acontecimientos que

18

desencadenaron el anlisis se debera esperar que se repitan. Las organizaciones necesitan asegurarse que las recomendaciones sean seguidas hasta su finalizacin.

Presentacin de los resultados

Las tablas de resumen de la causas raz (ver Fig. 9) puede organizar la informacin recopilada durante el anlisis de datos, la identificacin de causas raz y la generacin de recomendaciones. Cada columna representa un aspecto importante del proceso de RCA. En la primera columna, se presenta una descripcin general de los factores causales junto con la informacin de fondo suficiente para que el lector pueda comprender la necesidad de abordar este factor causal. La segunda columna muestra la ruta o rutas de acceso a travs de la Hoja de Causa Raz asociada con el factor causal. La tercera columna presenta las recomendaciones para abordar cada una de las causas races.

El uso de este formato de tres columnas ayuda al investigador para asegurarse de las causas raz y las recomendaciones se han desarrollado para cada factor causal. El resultado final de una investigacin RCA es por lo general un informe de investigacin. El formato del informe es por lo general bien definido por los documentos administrativos que rigen el sistema de informacin particular, pero el cuadro y tablas completas de los factores causales proporcionan la mayor parte de la informacin requerida por la mayora de los sistemas de informacin.
Tabla resumen de las Causas Raz Descripcin del evento: la cocina es destruida por el fuego y daada por el humo y el agua. Factor causal N 1 Ruta en el mapa Causa Raz Recomendaciones Descripcin : Maria deja Dificultad personal. Implementar una poltica para que friendo el pollo sin Sistema el aceite caliente nunca se deje de atencin administrativo/administracin. atender cuando est en el Estndares, polticas o control quemador. administrativo MqA . Determinar si se han desarrollado Sin control. polticas para otros tipos de peligros en con el objetivo de no dejar a ellos desatendido. Modificar el procedimiento de evaluacin del riesgo o el procedimiento de desarrollo del proceso para focalizar la atencin del personal durante la operacin. Factor causal N 2 Ruta en el mapa Causa Raz Recomendaciones Descripcin: el Dificultad en el equipo. Reemplace todos los quemadores quemador elctrico falla Problema de confiabilidad del equipo. de la cocina. (cortocircuito). Diseo del programa de confiabilidad Desarrolle una estrategia de del equipo MqA. mantenimiento preventivo para 19

 No hay programa.

Factor causal N 3 Descripcin: el extinguidor del fuego no oper cuando Mara trat de usarlo. .

Ruta en el mapa Causa Raz Dificultad en el equipo. Problemas con la confiabilidad del equipo. Mantenimiento proactivo del equipo MqA. Implementacin de actividades MqA.

Dificultad en el equipo. Problemas con la confiabilidad del equipo. Sistema administrativo /gestin. Identificacin de problemas y control MqA.

Factor causal N 4 Descripcin: Mara arroja agua en el fuego.

Ruta en el mapa Causa Raz Dificultad del personal. Empleados de la compaa. Entrenamiento. Entrenamiento MqA. Evento anormal/entrenamiento de emergencias MqA.

reemplazar peridicamente los quemadores. Considerar mtodos alternativos para la preparacin de pollo, que puede implicar menos riesgos, tales como asar el pollo o la compra del producto final de un proveedor. Recomendaciones Rellenar el extinguidor de fuego. Inspeccionar otro extinguidor con el objetivo de asegurarse que est lleno. Tener reportes de incidentes que describan el uso de elementos de proteccin del fuego conjuntamente con las instrucciones de mantenimiento del gatillo. Agregar este extinguidor a la lista de auditora. Verificar que todos los extinguidores de la casa queden en la lista de auditora. Tener todos los requerimientos de trabajos de mantenimiento que involucran a los extinguidores en vista de la seguridad y modificar las listas de chequeo si es necesario. Recomendaciones Proveer entrenamiento prctico en el uso de extinguidores. Las clases en sala parecen ser insuficientemente adecuadas para adquirir las habilidades. Revisar otras actividades que requieren destrezas asegurndose de tener el entrenamiento adecuado. Revisar el desarrollo de programas de entrenamiento de otras actividades para asegurar el nivel adecuado de habilidades mediante laboratorios, ensayos, simulaciones, etc.

Fig. 9: Tabla de anlisis de causal y recomendaciones

20

El RCA asume que los sistemas y los acontecimientos estn relacionados entre s. Una accin en un rea activa una accin en otra, y otra, y as sucesivamente. Al trazar de nuevo estas acciones, se puede descubrir donde empez el problema y cmo se convirti en el sntoma que est enfrentando. Por lo general, se puede encontrar tres tipos bsicos de las causas: 1. Causas fsicas en los elementos tangibles, material que falla de alguna manera (por ejemplo, los frenos de un auto dej de funcionar). 2. Causas humanas - la persona hizo algo mal, o no hizo algo que se necesitaba. Lo que el humano hace suele dar lugar a causas fsicas (por ejemplo, uno que no llen con lquido de frenos, lo que llev a los frenos no funcionar). 3. Causas organizacionales - un sistema, proceso, o la poltica que usa la organizacin para tomar decisiones o hacer su trabajo es defectuoso (por ejemplo, ninguna persona fue responsable de mantenimiento de vehculos, y todo el mundo asume que alguien haba llenado el lquido de frenos). En el Anlisis de Causa Raz se ve en los tres tipos de causas. Se trata de investigar los patrones de efectos negativos, la bsqueda de fallas ocultas en el sistema, y el descubrimiento de las acciones especficas que han contribuido al problema. A menudo, esto significa que RCA revela ms que una causa fundamental.

21

EL MTODO KEPNER- TREGOE O MATRIZ DEL PERFIL COMPETITIVO

Es una tcnica estructurada para recopilar, priorizar y evaluar informacin. El objetivo de la tcnica no es el de encontrar una solucin perfecta sino el de identificar la mejor alternativa posible. La decisin para seleccionar dicha alternativa, se basa en conseguir un objetivo determinado con mnimas consecuencias negativas. La tcnica parte del supuesto que indica que todos los problemas tienen la misma estructura, lo que invita a racionalizar su proceso de solucin. La tcnica presenta cuatro patrones bsicos de pensamiento: 1. 2. 3. 4. Anlisis de Situaciones Qu est ocurriendo? Permite evaluar, aclarar, seleccionar e imponer orden en una situacin confusa. Anlisis de Problemas Por qu ocurri esto? Permite relacionar un suceso con su resultado, una causa con su efecto. Anlisis de Decisiones Qu curso de accin hay que tomar? Permite hacer decisiones razonadas. Anlisis de Problemas Potenciales Qu nos espera ms adelante? Permite mirar en direccin al futuro que nos depara.

La explicacin de la tcnica que se presenta, (KT por sus autores), expone cmo realizar el segundo patrn de la solucin de problemas; el Anlisis de Problemas. Para los autores, un problema (falla) es algn tipo de desviacin de una norma, que alguien considera importante y necesario restablecer. Es algo que ha salido mal inexplicablemente y su deteccin se inicia con una nocin clara de lo que debiera suceder. El problema se especifica haciendo preguntas tanto del objeto afectado como del defecto mismo mediante cuatro dimensiones: 1. 2. 3. 4. La identidad de la falla (Qu?) El lugar donde ocurre (Dnde?) Su ubicacin en el tiempo (Cundo?) La magnitud o tamao (Cunto?)

Contrastndose cada una de ellas con LO QUE ES y LO QUE NO ES o con lo que PUDIERA SER pero NO ES. La ventaja ms importante de la tcnica es la sistematizacin del anlisis de los problemas, que de acuerdo a lo que indican los autores, normalmente se analizan los problemas por intuicin o sentido comn pero no de forma estructurada. La desventaja de esta tcnica radica en la necesidad del conocimiento profundo del sistema objeto de estudio.

22

La tcnica es recomendable para identificar, describir y analizar problemas operativos de tipo tcnico, proporcionando un medio sistemtico para extraer la informacin esencial de una situacin problemtica y hacer a un lado la informacin irrelevante o confusa.

Definicin del problema

El anlisis del problema comienza con la definicin del problema. El equipo que est a cargo de la solucin del problema no puede pasar por alto este paso crtico. La incapacidad para comprender exactamente lo que es el problema a menudo resulta en prdida de tiempo precioso. Muchos que atacan los problemas con inmadurez consideran este paso como un esfuerzo intil, ya que saben lo que estn haciendo - y esto es el grave error cometido por muchos. Nociones preconcebidas a menudo resultan en una duracin de corte final mayor e incluso la extensin en el corte debido a un pobre juicio. Ya que la gestin de problemas es de por s un ejercicio de equipo, es importante tener una comprensin del problema en el grupo. Considere los siguientes ejemplos. Una pobre definicin del problema podra aparecer como sigue: "El servidor se cay." Una mejor definicin del problema debe incluir ms informacin. Un buen modelo para formalizar las declaraciones de todo tipo es mtodo GQM (Goal-Question-Metric). Da como resultado una declaracin con un objetivo claro, un propsito, un enfoque, un medio ambiente, y un punto de vista. Esto da lugar a una declaracin inequvoca y fcil de entender. Una definicin del problema podra ser aclarado: "El sistema de correo electrnico fall despus de que el ingeniero de soporte del tercer turno aplic pegamento caliente XYZ en el servidor de intercambio 123". Cuando se est desarrollando una definicin del problema se recomienda utilizar la tcnica de "5 porqus" para llegar al punto en que no hay ms explicacin para el problema. Utilizando 5 porqus con KT slo acelera el proceso.

Describir el problema
Con una definicin clara del problema, el siguiente paso es describir el problema en detalle. El siguiente cuadro proporciona una buena plantilla para esta actividad. La tabla a continuacin describe la hoja de trabajo bsico que se utiliza en el proceso.
ES QUE DONDE CUANDO EXTENSIN Falla del sistema Ubicacin de la falla Momento de la falla Otras fallas del sistema PUEDE SER PERO NO ES Sistemas similares/situaciones sin fallas Otras ubicaciones que no fallaron Otras veces cuando la falla no ocurri Otros sistemas sin falla DIFERENCIAS ? ? ? ? CAMBIOS ? ? ? ? 23

En la hoja se describen los cuatro aspectos de un problema: qu es, dnde se produce, cuando se produjo, y la extensin en que se produjo. La columna ES proporciona espacio para describir en detalle sobre el problema - lo que el problema ES. La columna PODRA SER, PERO NO ES ofrece un espacio para listar detalles relacionados, pero excluidos - lo que el problema PODRA SER PERO NO ES. Estas dos columnas ayudan en la eliminacin de suposiciones "intuitiva pero incorrecta" sobre el problema. Con las columnas uno y dos completas, la tercera columna ofrece espacio para detallar las diferencias entre el SI y que PODRA SER PERO NO ES. Estas diferencias forman la base de la solucin de problemas. La ltima columna proporciona espacio para enumerar todos los cambios realizados que podran explicar las diferencias.

Determinar las Causas posibles

Cualquiera que haya pasado tiempo en la solucin de problemas sabe ver "lo que ha cambiado desde que trabaj" y empezar a solucionar problemas mediante el control de los cambios. El problema es que muchos cambios pueden ocurrir, y que complica las cosas. El anlisis de problemas puede ayudar aqu por la descripcin de lo que el problema es y lo que el problema podra ser, pero no lo es. Por ejemplo: Problema: ". "El sistema de correo electrnico fall despus de que el ingeniero de soporte del tercer turno aplic pegamento caliente XYZ en el servidor de intercambio 123".
ES Servidor de intercambio 123 fall despus de la aplicacin del pegamento caliente XYZ La sala de produccin del tercer piso sin el soporte de un vendedor/contratista ltima noche, 1:35am Todos los servidores del 3er piso PODRIA SER PERO NO ES Otros servidores de intercambio usaron pegamento caliente XYZ DIFERENCIAS Diferente staff (3er turno) aplic este pegamento CAMBIOS Vendedor entrega un nuevo procedimiento Nuevo procedimiento, primera vez que lo aplica el tercer turno

QUE

DONDE

En cualquier lugar Normalmente con soporte de hecho por un vendedor/contratista vendedor Cualquier hora o ubicacin Otros servidores Sin anotacin

CUANDO EXTENSIN

Historiales (y mejores prcticas) dice que la causa raz del problema se debe probablemente a un cambio reciente. Con la hoja de trabajo completa, algunas posibles soluciones nuevas se hacen evidentes. Arriba se muestra que se pone de manifiesto que la causa es, probablemente, de procedimiento, y debido al
24

hecho de que el vendedor no aplic el pegamento caliente, pero dio los procedimientos para aplicar el pegamento a la empresa.

Prueba de la causa ms probable

Con una lista corta de posibles causas (recientes cambios evaluados y convertidos en una lista), el siguiente paso es pensar sobre cada posible problema. La siguiente ayuda puede contribuir en este proceso. Haga la pregunta: "Si _____________ es la causa raz de este problema explica el problema ES y cul problema PODRA SER, PERO NO LO ES?" Si esta respuesta potencial es la causa raz, entonces la solucin potencial tiene que "mapear hacia" o "encajar en" todos los aspectos de la hoja de trabajo de anlisis de problemas. Utilice una hoja de trabajo como la mostrada a continuacin para ayudar a organizar su pensamiento en torno a las posibles soluciones.
Causa Raz Potencial: El servidor de intercambio 123 tiene algo de malo en l Procedimiento incorrecto Error tcnico Verdad si: Causa raz probable?

Solamente el servidor de intercambio Puede ser 123 tiene este problema El mismo procedimiento rompi otro Probable servidor El problema no siempre ocurre Probablemente no

Verificar la verdadera causa

El siguiente paso es comparar las causas raz posibles en contra de la descripcin del problema. Eliminar las posibles soluciones que no pueden explicar la situacin, y centrarse en los temas restantes. Antes de hacer cambios, verificar que la respuesta propuesta podra ser la causa raz. Falla en la verificacin de la verdadera causa invalida todo el ejercicio y no es mejor que adivinar. Despus de verificar la verdadera causa, puede proponer las medidas necesarias requeridas para reparar el problema. Es importante aqu, as que pensar en cmo prevenir los problemas similares se repitan en el futuro. El administrador del problema debe considerar cmo la cuestin se plante en primer lugar mediante unas preguntas: Dnde ms podra aparecer este problema? Hay otros casos como este problema en el pasado? Estn todos los procedimientos necesarios para cambiar? El objetivo es tratar de eliminar las repeticiones futuras del problema.
25

5 PORQUS PARA RESOLVER PROBLEMAS

Inventado en 1930 por Kiichiro Toyoda y se hizo popular en la dcada de 1970 por el Sistema de Produccin Toyota. La estrategia de 5 porqus implica observar cualquier problema y preguntar: "Por qu?" y "Qu caus este problema?" Six Sigma, un sistema de gestin de calidad (SGC), utiliza "5 porqus" en la fase de anlisis de la metodologa Six Sigma: Definir, Medir, Analizar, Mejorar, Controlar (DMAIC). La idea es simple. Al plantear la pregunta "Por qu?" se puede separar los sntomas de las causas de un problema. Esto es fundamental ya que los sntomas suelen enmascarar las causas de los problemas. Teniendo una efectiva clasificacin de incidentes, basar las acciones en los sntomas es la peor prctica posible. 5 Porqus ofrece algunas ventajas reales en cualquier nivel de madurez: Simplicidad. Es fcil de usar y no requiere de las matemticas o herramientas avanzadas. Eficacia. Sin duda ayuda a separar rpidamente los sntomas de las causas e identificar la causa raz de un problema. Exhaustividad. Ayuda a determinar las relaciones entre las diversas causas del problema. Flexibilidad. Funciona bien solo y cuando se combina con otros para mejorar la calidad y las tcnicas de resolucin de problemas. Atractivo. Por su propia naturaleza, fomenta y produce el trabajo en equipo y equipos dentro y fuera de la organizacin. De bajo costo. Se trata de una gua, centrada en el ejercicio del equipo. No hay costos adicionales. A menudo la respuesta al primer "por qu" descubre otras razones y genera otro "por qu". A menudo se requieren cinco "por qu" para llegar a la causa raz del problema. Es probable que encuentre lo que le piden ms o menos en 5 "por qu" en la prctica.

Cmo utilizar el 5 por qu

1. Reunir a un equipo de gente experta en el elemento de la configuracin que est fallando. Incluir especialistas de reas relacionadas y usuarios del sistema en anlisis si fuese necesario. 2. En un tablero de presentacin escribir una descripcin de lo que sabe sobre el problema. Trate de documentar el problema y describir lo ms completo posible. Perfeccionar la definicin con el equipo. Llegar a un acuerdo sobre la definicin del problema en cuestin. 3. Un miembro del equipo pregunta "Por qu?" el problema descrito puede ocurrir, y escribe la respuesta por debajo de la descripcin del problema.

26

4. Si la respuesta dada a partir de 3 (arriba) no resuelve el problema, debe repetir los pasos 3 y 4 hasta que lo haga. 5. Si la respuesta dada a partir de 3 (arriba), parece probable que para resolver el problema, asegrese de que el equipo est de acuerdo e intentar una resolucin con la respuesta. Sea el siguiente ejemplo (Fig. 10):

Por qu la maquina se detuvo? La sobrecarga se dispar Por qu la sobrecarga se dispar? Insuficiente aceite en el eje Por qu el aceite es insuficiente? La bomba del aceite es ineficiente

CAUSA RAIZ

Por qu la bomba es ineficiente? El eje de la bomba est deteriorado Por qu el eje est deteriorado? Filtro de aceite bloqueado con virutas

Fig. 10: el ciclo de los 5 por qu

El dominio de los 5 por qu

Es de suma importancia basar las causas raz propuestas (respuesta al "por qu") en la observacin directa y no en la especulacin o la deduccin. Si no se puede ver u observar el "por qu" de primera mano, entonces slo se est adivinando. Uno de los problemas comunes de quienes utilizan los 5 porqus es caer en conjeturas en su informe. Es evidente que la adivinacin es contraproducente. Gente experimentada en la tcnica de exigen la precisin preguntando los 5
27

porqus de nuevo para cada propuesta para la causa raz - slo que esta vez preguntando por qu el equipo piensa que la propuesta de la causa raz es la correcta. Para validar las potenciales causas raz que estn bajo su control, puede aplicar las validaciones siguientes a sus respuestas o causas raz. Haga las siguientes preguntas para cada posible causa raz identificada a todos los niveles de los 5 porqus: Hay alguna prueba (algo que se puede medir u observar) para apoyar esta determinacin de causa raz? Hay alguna historia o el conocimiento que indique que la posible causa raz en la actualidad podra producir el problema? Hay algo "por debajo" de la posible causa raz que podra ser una causa ms probable? Hay algo que esta posible causa raz requiere para producir el problema? Hay alguna otra causa que pudiera producir el mismo problema? Si se agrega a estas preguntas validadas y los resultados a la descripcin del problema y las preguntas y respuestas, se producir una indicacin mucho ms clara del problema y es posible identificar otras posibles soluciones. Si se diagrama de este proceso, el resultado final ser con un rbol de factores que conducen al problema. Incluso si usted no llegar a una resolucin, la comprensin de la cuestin o el problema es mucho mayor, a menudo ofrece caminos para un diagnstico ms profundo. El uso de Ishikawa (causa-efecto o "espina de pez") hace que los diagramas de 5 porqus sean especialmente efectivos.

28

DIAGRAMA DE ISHIKAWA PARA LA CAPTURA DE LAS SOLUCIONES

El diagrama de Ishikawa es un mtodo grfico para el anlisis de causa raz. Documentado por primera vez por Kaoru Ishikawa, se utiliza hoy en da como una piedra angular de la mejora continua del servicio. Debido a su forma, tambin es conocido como el diagrama de espina de pescado. Otro nombre para esta tcnica es de diagramacin causa y efecto. Los diagramas de Ishikawa son aparentemente simples, pero no hay que dejar que eso detenga un anlisis. Usando esta tcnica se puede ver todas las posibles causas de un resultado (un problema, por ejemplo), y descubrir la causa raz de fallas. La diagramacin Ishikawa no requiere inversin en software o herramientas. Se trata de un ejercicio de grupo. Siguiendo lo que se describe cmo, por qu y cundo para crear y utilizar diagramas Ishikawa de causa y efecto.

Anlisis de Causa Raz

Ishikawa, "Espina de pesado", o diagrama de causa y efecto se refieren a lo mismo: una representacin grfica de las entradas (causas y razones) y una salida (el problema o evento). Un profesional gua a un grupo en la organizacin de causas de acuerdo a su importancia. Esto se traduce en un grfico que muestra la relacin entre las causas, razones y el problema objeto de estudio. Este grfico ayuda a identificar las causas races, ineficiencias y otros problemas. Los diagramas de Ishikawa se complementan muy bien con otras herramientas similares, incluidas las de Kepner-Tregoe, y otras. Los diagramas de Ishikawa son similares a otras herramientas de calidad. Mediante el uso de pizarras, el profesional intenta visualizar, recoger y organizar la informacin. Tan simple como suena, a veces solamente obtener todas las ideas de un grupo de personas organizadas en un diagrama acelera drsticamente el diagnstico de problemas y resoluciones. Usar esta tcnica siempre que se deba: Determinar la causa raz de un problema Comprender las posibles razones porque un proceso no est cumpliendo como se esperaba Identificar reas en las que recoger datos Un diagramas Ishikawa completo en algo se asemeja a una espina de pescado, y por lo tanto el apodo de "Diagrama de espina de pescado". Siguiendo con la analoga de los peces, la "cabeza" debe contener una descripcin del problema. De la cabeza se origina la "columna vertebral" del diagrama. De la columna vertebral, "costillas" indican el rea de los principales que pueden causar el problema descrito (ver Fig.11).
29

Fig. 11: Diagrama de Ishikawa La diagramacin Ishikawa es ms til como una herramienta de grupo. No hay lmite a la complejidad de los diagramas. El ejemplo es sencillo, pero el suyo puede ser muy complejo. Normalmente, ms de 4 o 5 niveles son demasiado complejos para producir cualquier causa visible. Cuando el diagrama est completo, el equipo cuenta con un documento grfico que muestra organizada todas las posibles causas del problema descrito. A continuacin, el grupo discute la causa raz ms probable y propone un plan de accin.

Creacin de una Diagrama Ishikawa "Espina de pescado"

La creacin de un diagrama de Ishikawa sigue un proceso simple: Reunir a un grupo de personas familiarizadas con el problema en cuestin.
30

1. Dibujar una lnea horizontal como la "columna vertebral" y una caja a la derecha de la columna vertebral como la "cabeza" en un tablero. 2. Trabajar con el grupo para llegar a una descripcin del problema que sea claro y conciso. Escribir la descripcin del problema en la caja de problema o cabeza de pescado del diagrama. En el ejemplo, el problema es "incertidumbre operativa", refirindose a por qu no se consigue entregar un producto computacional de calidad. 3. Ahora el equipo tiene que discutir y estar de acuerdo con los grandes grupos de causas o "costillas" inciales. Si el grupo no se ponen de acuerdo sobre las causas principales, slo tiene que utilizar las 3 P - Personas, Proceso, Producto. Escriba una etiqueta para cada "costilla", permitiendo que el espacio para las razones como se muestra en el ejemplo. 4. Use las tcnicas tradicionales de tormentas de ideas para llenar las posibles razones de la "costillas" de la siguiente manera: a. Pregunte a cada persona una por una para que d una posible causa (tal vez en forma de una pregunta) para cada una "costilla". Cada persona debe presentar una razn posible, y si no puedo pensar en una puede pasar. Asegrese de que cada causa es clara, concisa y medible. b. Dibujar la causa en una lnea conectada a la "costilla" adecuada y la etiqutela con la causa. Si la causa propuesta es un factor en una causa existente (costilla), a continuacin, dibuje otra espina dorsal de la costilla, aadir otra costilla, y la etiqueta de la misma. c. Volver atrs y repetir hasta que todo el mundo dice, "pasa" y no hay ms causas posibles que las costillas ya existentes y no hay costillas nuevas que aadir. 5. Con la espina de pez completo, ahora revisar y discutir el diagrama de Ishikawa para buscar las causas comunes o repetidas. Trate de determinar la causa raz del problema. La forma ms rpida y ms fcil de interpretar los resultados de Ishikawa es el diagrama para seleccionar y clasificar las 5 mejores causas. Deje que el grupo decida cmo clasificar las causas. Los 5 porqus son tambin tiles para determinar la ms probable causa raz cuando el esquema se completa tambin. Haga un crculo de las causas seleccionadas. Haga que los miembros apropiados del grupo investiguen estas causas utilizando otras tcnicas de solucin de problemas. Repita segn sea necesario.

El dominio de Causa y Efecto

Profesionales con experiencia limitan el nmero de "costillas" (causas) para el enfoque del grupo. Algunos sugieren que no permitan ms de 3 a 5 costillas. Otras tcnicas de uso de clave de Ishikawa son: Enmarcar el problema como una pregunta, tal como "Por qu son los incidentes? Por qu existe tan alta tasa de rechazo en el? Cada causa debe responder a esa pregunta.
31

Asegurarse que las "costillas" son las causas del problema, no los sntomas del problema. Use la tormenta de ideas para determinar exactamente lo que las costillas debe ser la tcnica del "5 porqus" puede ayudar aqu. Comprobar que las causas en el diagrama no son en s otros problemas. Combinar costillas vacas (o casi vacas), con otras costillas ms apropiadas. Divida aquellas costillas densas en costillas adicionales, segn convenga. Realice copias de los resultados y darlas a conocer a los dems para obtener mayor conocimiento y participacin del personal. El diagrama de Ishikawa es una potente herramienta para aprovechar la combinacin de conocimientos y experiencia de un grupo de personas. Esto permite que el grupo focalice la discusin sobre el por qu se producen problemas sin la distraccin de los sntomas.

32

HAZARD AND OPERABILITY (HAZOP)

Descripcin
El HAZOP es una tcnica de identificacin de riesgos inductiva basada en la premisa de que los riesgos, los accidentes o los problemas de operatividad, se producen como consecuencia de una desviacin de las variables de proceso con respecto a los parmetros normales de operacin en un sistema dado y en una etapa determinada. Por tanto, ya se aplique en la etapa de diseo, como en la etapa de operacin, la sistemtica consiste en evaluar, en todas las lneas y en todos los sistemas las consecuencias de posibles desviaciones en todas las unidades de proceso, tanto si es continuo como discontinuo. La tcnica consiste en analizar sistemticamente las causas y las consecuencias de unas desviaciones de las variables de proceso, planteadas a travs de unas "palabras gua". La realizacin de un anlisis HAZOP consta de las etapas que se describen a continuacin:

Etapas
Definicin del rea de estudio: Consiste en delimitar las reas a las cuales se aplica la tcnica. En una determinada instalacin de proceso, considerada como el rea objeto de estudio, se definirn para mayor comodidad una serie de subsistemas o lneas de proceso que corresponden a entidades funcionales propias: lnea de carga a un depsito, separacin de disolventes, reactores, etc. Definicin de los nudos: En cada uno de estos subsistemas o lneas se debern identificar una serie de nudos o puntos claramente localizados en el proceso. Por ejemplo, tubera de alimentacin de una materia prima a un reactor, impulsin de una bomba, depsito de almacenamiento, etc. Cada nudo deber ser identificado y numerado correlativamente dentro de cada subsistema y en el sentido del proceso para mejor comprensin y comodidad. La tcnica HAZOP se aplica a cada uno de estos puntos. Cada nudo vendr caracterizado por variables de proceso: presin, temperatura, caudal, nivel, composicin, viscosidad, etc. La facilidad de utilizacin de esta tcnica requiere reflejar en esquemas simplificados de diagramas de flujo todos los subsistemas considerados y su posicin exacta. El documento que acta como soporte principal del mtodo es el diagrama de flujo de proceso, o de tuberas e instrumentos, P&ID. Aplicacin de las palabras gua: Las "palabras gua" se utilizan para indicar el concepto que representan a cada uno de los nudos definidos anteriormente que entran o salen de un elemento determinado. Se aplican tanto a acciones (reacciones, transferencias, etc.) como a parmetros especficos (presin, caudal, temperatura, etc.). La tabla siguiente presenta algunas palabras gua y su
significado.

33

Palabra gua NO

Significado Ausencia de la variable a la cual se aplica Aumento cuantitativo de una variable

Ejemplo de desviacin No hay flujo en una lnea Ms flujo (ms caudal) Ms temperatura

Ejemplo de causas originadoras Bloqueo; fallo de bombeo; vlvula cerrada o atascada; fuga; vlvula abierta; fallo de control Presin de descarga reducida; succin presurizada; controlador saturado; fuga; lectura errnea de instrumentos Fuegos exteriores; bloqueo; puntos calientes; explosin en reactor; reaccin descontrolada Fallo de bombeo; fuga; bloqueo parcial; sedimentos en lnea; falta de carga; bloqueo de vlvulas Prdidas de calor; vaporizacin; venteo bloqueado; fallo de sellado Fallo de bomba; sifn hacia atrs; inversin de bombeo; vlvula antirretorno que falla o est insertada en la tubera de forma incorrecta Entrada de contaminantes del exterior como aire, agua o aceites; productos de corrosin; fallo de aislamiento; presencia de materiales por fugas interiores; fallos de la puesta en marcha Concentracin demasiado baja en la mezcla; reacciones adicionales; cambio en la alimentacin Puesta en marcha y parada; pruebas e inspecciones; muestreo; mantenimiento; activacin del catalizador; eliminacin de tapones; corrosin; fallo de energa; emisiones indeseadas, etc.

MS

MENOS

Disminucin cuantitativa de una variable

Menos caudal

INVERSO

ADEMS DE

Analiza la inversin en el sentido de la variable. Se obtiene el efecto contrario al que se pretende Aumento cualitativo. Se obtiene algo ms que las intenciones del diseo

Menos temperatura Flujo inverso

Impurezas o una fase extraordinaria

PARTE DE

DIFERENTE DE

Disminucin cualitativa. Parte de lo que debera ocurrir sucede segn lo previsto Actividades distintas respecto a la operacin normal

Disminucin de la composicin en una mezcla Cualquier actividad

Definicin de las desviaciones a estudiar: Para cada nudo se plantea de forma sistemtica todas las desviaciones que implican la aplicacin de cada palabra gua a una determinada variable o actividad. Para realizar un anlisis exhaustivo, se deben aplicar todas las combinaciones posibles entre palabra gua y variable de proceso, descartndose durante la sesin las desviaciones que no tengan sentido para un nudo determinado. Paralelamente a las desviaciones se deben indicar las causas posibles de estas desviaciones y posteriormente las consecuencias de estas desviaciones.

34

En la tabla anterior se presentan algunos ejemplos de aplicacin de palabras gua, las desviaciones que originan y sus causas posibles. Sesiones HAZOP: Las sesiones HAZOP tienen como objetivo la realizacin sistemtica del proceso descrito anteriormente, analizando las desviaciones en todas las lneas o nudos seleccionados a partir de las palabras gua aplicadas a determinadas variables o procesos. Se determinan las posibles causas, las posibles consecuencias, las respuestas que se proponen, as como las acciones a tomar. Toda esta informacin se presenta en forma de tabla que sistematiza la entrada de datos y el anlisis posterior. A continuacin se presenta el formato de recogida del HAZOP aplicado a un proceso continuo.
Planta: Sistema: Nudo Palabra gua

Desviacin de la variable

Posibles causas

Consecuencias

Respuesta

Sealizacin

Acciones a tomar

Comentarios

El significado del contenido de cada una de las columnas es el siguiente:

Columna Posibles causas Consecuencias Respuesta del sistema Contenido Describe numerndolas las distintas causas que pueden conducir a la desviacin Para cada una de las causas planteadas, se indican con la consiguiente correspondencia en la numeracin las consecuencias asociadas Se indicar en este caso: 1. Los mecanismos de deteccin de la desviacin planteada segn causas o consecuencias: por ejemplo, alarmas 2. Los automatismos capaces de responder a la desviacin planteada segn las causas: por ejemplo, lazo de control Propuesta preliminar de modificaciones a la instalacin en vista de la gravedad de la consecuencia identificada o a una desproteccin flagrante de la instalacin Observaciones que complementan o apoyan algunos de los elementos reflejados en las columnas anteriores

Acciones a tomar Comentarios

En el caso de procesos discontinuos, el mtodo HAZOP sufre alguna modificacin, tanto en su anlisis como en la presentacin de los datos finales. Las sesiones HAZOP se llevan a cabo por un equipo de trabajo multidisciplinar cuya composicin se describe con detalle ms abajo en el apartado de recursos necesarios. Como resumen del procedimiento, se presenta el esquema siguiente aplicado a procesos continuos

35

Inicio Anlisis Funcional de Operatividad (AFO): 1. Eleccin de un equipo. 2. Definir las funciones deseadas del equipo incluidas las conducciones y aparatos o servicios auxiliares asociadas al mismo. 3. Eleccin de una lnea de conduccin. 4. Definir la funcin deseada de esta lnea de conduccin. 5. Utilizacin de la primera palabra gua. 6. Formulacin del significado de la posible desviacin. 7. Determinar las posibles causas. 8. Examinar posibles consecuencias. 9. Determinar la peligrosidad, considerando la posibilidad de tales acontecimientos. 10. Proponer medidas necesarias. 11. Repeticin de los puntos 6 10 para todas las posibles desviaciones que fueron formuladas con ayuda de la primera palabra gua. 12. Repeticin de los puntos 5 11 para todas las palabras guas. 13. Sealizar la parte analizada en los diagramas de trabajo (flowsheets). 14. Repeticin de los puntos 3 13 para cada lnea diferente. 15. Eleccin de un servicio auxiliar (por ejemplo sistema de calefaccin). 16. Definir la funcin deseada de este servicio auxiliar. 17. Repeticin de los puntos 5 -12 para tal servicio auxiliar. 18. Sealizar la parte analizada en los diagramas de trabajo. 19. Repeticin de los puntos 15 18 para todos los servicios auxiliares. 20. Definir las intenciones especficas del equipo o unidad. 21. Repetir 5 12. 22. Sealizar que el anlisis del equipo o unidad est completo. 23. Repetir 1 22 para los diferentes para los diferentes equipos del diagrama de procesos. 24. Sealizar en el flowsheet de la instalacin que la unidad de procesos ha sido analizada. 25. Repetir 1 24 para todas de procesos de la instalacin. Final Anlisis Funcional de Operatividad

Informe final: El informe final consta de los siguientes documentos: Esquemas simplificados con la situacin y numeracin de los nudos de cada subsistema. Formatos de recogida de las sesiones con indicacin de las fechas de realizacin y composicin del equipo de trabajo.

36

Anlisis de los resultados obtenidos. Se puede llevar a cabo una clasificacin cualitativa de las consecuencias identificadas. Listado de las medidas a tomar. Constituye una lista preliminar que debera ser debidamente estudiada en funcin de otros criterios (coste, otras soluciones tcnicas, consecuencias en la instalacin, etc.) y cuando se disponga de ms elementos de decisin. Lista de los sucesos iniciadores identificados.

mbito de aplicacin
La mayor utilidad del mtodo se realiza en instalaciones de proceso de relativa complejidad o en reas de almacenamiento con equipos de regulacin o diversidad de tipos de trasiego. Es uno de los mtodos ms utilizados que depende en gran medida de la habilidad y experiencia de los miembros del equipo de trabajo para identificar todos los riesgos posibles. En plantas nuevas o en fase de diseo, puede ayudar en gran medida a resolver problemas no detectados inicialmente. Adems, las modificaciones que puedan surgir como consecuencia del estudio pueden ser ms fcilmente incorporadas al diseo. Por otra parte, tambin puede aplicarse en la fase de operacin y en particular ante posibles modificaciones.

Recursos necesarios
El grupo de trabajo estable estar constituido por un mnimo de cuatro personas y por un mximo de siete. Podr invitarse a asistir a determinadas sesiones a otros especialistas. Se designar a un coordinador/director del grupo, experto en HAZOP, y que podr ser el tcnico de seguridad, y no necesariamente una persona vinculada al proceso. Aunque no es imprescindible que lo conozca en profundidad, si debe estar familiarizado con la ingeniera de proceso en general.

Funciones del coordinador/director del grupo

Recoger la informacin escrita necesaria de apoyo. Planificar el estudio. Organizar las sesiones de trabajo. Dirigir los debates, procurando que nadie quede en un segundo trmino o supeditado a opiniones de otros. Cuidar que se aplica correctamente la metodologa, dentro de los objetivos establecidos, evitando la tendencia innata de proponer soluciones aparentes a problemas sin haberlos analizado suficientemente. Recoger los resultados para su presentacin. Efectuar el seguimiento de aquellas cuestiones surgidas del anlisis y que requieren estudios adicionales al margen del grupo.

37

El grupo debe incluir a personas con un buen conocimiento y experiencia en las diferentes reas que confluyen en el diseo y explotacin de la planta.

Ejemplo
El ejemplo se aplica a una parte de una instalacin en una planta de dimerizacin de olefina. El diagrama de flujo sobre el que se aplica el AFO consiste en el suministro de hidrocarburo a un depsito de almacenamiento. Forma parte de un subsistema mayor que consiste en la alimentacin del hidrocarburo del depsito regulador hasta un reactor de dimerizacin donde se produce la olefina (ver Fig. 12).
LIC
I-5

Nitrgeno (Inertizante)

RF

PIC TR

AN Conduccin de 500 m

Depsito regulador / dosificador 25 m3 20C 15 psig Colector de agua FO A drenaje 20C 35 psig

Hidrocarburos de tanque intermedio PG

I-2

Drenaje y purgado con N2

PG Drenaje y purgado con N2

I-3

J1 Bombas de trasvase (una en funcionamiento y otra en reserva)

Fig. 12: Diagrama de proceso El formato de la tabla de recogida de datos y anlisis HAZOP de una sesin aplicado a la palabra gua NO y a la perturbacin NO FLUJO, sera como sigue:
38

ANLISIS DE OPERABILIDAD EN PLANTA DE DIMERIZACIN DE OLEFINA Lnea comprendida entre alimentacin desde tanque intermedio a depsito regulador Palabra Desviacin Causas posibles Consecuencias Medidas a tomar gua NO NO FLUJO 1. Inexistencia de Paralizacin del a) Asegurar buena hidrocarburo en tanque proceso de reaccin comunicacin con el intermedio esperado. operario del tanque intermedio Formacin de polmero b) Instalar alarma de nivel en el intercambiador de mnimo LIC en depsito calor regulador 2. Bomba J1 falla (fallo de Como apartado 1 Cubierto por b) motor, circuito de maniobra, etc.) 3. Conduccin bloqueada, Como apartado 1 Cubierto por b) vlvula cerrada por error o LCV falla cerrando paso al Bomba J1 sobrecargada c) Instalar sistema de fluido desconexin automtica para proteccin de bombas d) Verificar el diseo de los filtros de las bombas J1 4. Rotura de conduccin Como apartado 1 Cubierto por b) Hidrocarburo e) Implantar inspeccin descargado en rea regular de la conduccin adyacente a va pblica mediante rondas peridicas

Posteriormente se aplicaran otras palabras gua a otras variables del sistema.

Matriz de evaluacin de los riesgos

Definiciones previas: 1. Anlisis de riesgos: es el proceso formal que se realiza durante la vida del proyecto, mediante el cual se identifican los factores de riesgo, se analizan y evalan sus efectos y se definen las acciones a seguir frente a los mismos, con el fin de disponer de una actuacin planificada con vista a minimizarlos. 2. Riesgo: es un evento probable cuya ocurrencia produce un dao a las personas, bienes fsicos, procesos y/o medio ambiente. 3. Consecuencias (C): mide el nivel o grado de severidad que pueden revestir los daos a las personas, a los bienes y perjuicios por paralizacin de la produccin, como consecuencia de un incidente.
39

4. Exposicin (E): el nmero de veces que el operador(es) se expone a un evento en un perodo determinado. Una escala clasifica en forma cualitativa el nmero de veces que la tarea est expuesta al evento, es ejecutada por cada persona o grupo de personas en un determinado tiempo. 5. Probabilidad (P): dice relacin con la frecuencia de ocurrencia del evento no deseado y se expresa por medio de una escala de categoras que corresponden al nivel de frecuencias de ocurrencias. 6. Magnitud del Riesgo (MR): es una medicin que permite evaluar y jerarquizar el riesgo en forma cuantitativa, en funcin de su Probabilidad (P), Exposicin (E) y Consecuencia (C). 7. Matriz de Riesgo: es una matriz que permite relacionar los componentes (procesos, equipos, instalaciones, insumos y suministros) o alternativas del proyecto versus los riesgos operacionales. Una vez que el grupo de trabajo ha identificado los eventos riesgos que pueden afectar el proceso o rea, est en condiciones de iniciar la evaluacin del riesgo y calcular su magnitud. Magnitud del riesgo relacionado con personas: la magnitud del riesgo (MR) asociado son las personas, se calcula utilizando las siguientes variables: a) Consecuencias para las personas (C) Clasificacin LEVE SERIA GRAVE Categora 1 2 4 Consecuencias Lesin(es) leve(s) no incapacitante(s) Lesin(es) incapacitante(s) temporal(es) y permanente(s) parcial(es) Perdida de la vida de un operador o incapacidad permanente total

b) Estimacin de exposicin (E) Nmero de veces exposicin del operador al riesgo Anual - Semestral Trimestral Mensual Semanal 1 2 3 c) Estimacin de la probabilidad (P) Categora 1 2 3 4 Definicin Casi improbable que ocurra Puede ocurrir alguna vez Ocurre regularmente Ocurre la mayor parte de las veces
40

Diaria 4

d) Evaluacin de la magnitud del riesgo (MR): la magnitud del riesgo permite clasificar el riesgo a las personas, se manera de focalizar y priorizar las acciones correctivas que se deben incorporar en las etapas de diseo de los proyectos y de control durante su operacin, con el fin de proteger a las personas y dar confianza a los sistemas. Magnitud del riesgo MR = C * E * P De esta manera se obtiene un ranking priorizado del inventario de riesgos a las personas en los proyectos de inversin y el nivel de criticidad de la magnitud del riesgo. Nivel de criticidad Grave Serio Leve Rango (MR) 24 a 64 16 a 18 1 a 12

Magnitud del riesgo relacionado con los bienes fsicos y medio ambiente: cada empresa que hace el anlisis define los mrgenes de prdidas. a) Clasificacin de las consecuencias (C) Categora 1 2 3 4 5 Prdidas entre (US$) 1 y 100.000 100.000 y 250.000 250.000 y 500.000 500.000 y 1.000.000 1.000.000 y ms

En el caso que se est aplicando en referencia al medio ambiente, las consecuencias se pueden orientar como sigue:

Categora 1 2 3 4 5

Definicin Insignificante mnimo impacto Baja severidad accin local Mediana severidad apoyo de otras reas Severa compromete a toda la organizacin Muy severa se afecta la comunidad

b) Estimacin de la probabilidad (P): dice relacin con la probabilidad de ocurrencia del evento no deseado, que tiene el potencial de producir daos a los bienes fsicos y al medio ambiente,
41

Categora 6 5 4 3 2 1

Definicin Se espera que ocurra al menos una vez al ao. Ocurre la mayor parte de las veces. Se espera ocurra al menos una vez cada 3 aos. Ocurre regularmente. Se espera ocurra al menos una vez cada 10 aosOcurre algunas veces. Se espera ocurra al menos una vez cada 15 aos. Es raro que ocurra. Se espera que ocurra no ms de 1 vez en 25 aos. Ha ocurrido Se espera que ocurra no ms de 1 vez en 90 aos. Casi improbable que ocurra se tiene conocimiento que ha ocurrido.

c) Evaluacin de la magnitud del riesgo (MR): la magnitud permite clasificar los riesgos para priorizar las acciones de control en las etapas de diseo de los proyectos. Magnitud del riesgo MR = C * P

Para visualizar la clasificacin se construye la matriz de gravedad del riesgo, utilizando la categora de la consecuencia y la probabilidad de ocurrencia del evento, como dimensiones de la matriz. Matriz Gravedad Riesgo 6 Probabilidad 5 4 3 2 1 6 5 4 3 2 1 1 12 10 8 6 4 2 2 18 15 12 9 6 3 3 Consecuencias 24 20 16 12 8 4 4 30 25 20 15 10 5 5

De acuerdo a la magnitud del riesgo se definen tres niveles de criticidad: grave, serio y leve, segn los rangos que se muestran a continuacin: Nivel de criticidad Grave Serio Leve Rango MR 15 a 30 5 a 12 1a4
42

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

43

DESARROLLANDO UN ANLISIS DEL MODO DE FALLA Y EFECTO (FMECA)

OBJETIVO DEL FMECA
El anlisis del modo de falla, efectos y anlisis de criticidad (FMECA) es una funcin esencial en el diseo, desde el concepto hasta el desarrollo. Para ser efectivo, el FMECA debe ser iterativo para corresponder con la naturaleza propia del proceso de diseo. El grado de esfuerzo y de la sofisticacin del enfoque utilizado en el FMECA depender de la naturaleza y requisitos del programa individual. Esto hace que sea necesario adaptar los requisitos de un FMECA para cada programa. La adaptacin requiere que, independientemente del grado de sofisticacin, el FMECA debe contribuir de manera significativa a la decisin del programa. Si el FMECA se realiza correctamente es muy valioso para aquellos que son responsables de la toma de decisiones del programa respecto a la viabilidad y la adecuacin de un enfoque de diseo. La utilidad del FMECA como una herramienta de diseo en el proceso de toma de decisiones depende de la eficacia con la que se comunica la informacin para el problema para la fase inicial de diseo. Probablemente, la mayor crtica del FMECA ha sido su uso limitado en la mejora de los diseos. Si bien el objetivo de un FMECA es la identificacin de todos los modos de falla dentro de un diseo del sistema, su primer objetivo es la identificacin temprana de todas las posibilidades de una falla catastrfica y crtica para que puedan ser eliminados o minimizados mediante la correccin de diseo a la mayor brevedad posible. Por lo tanto, el FMECA debe iniciarse tan pronto como la informacin de diseo preliminar est disponible en los niveles ms altos del sistema y ser extendida a los niveles ms bajos a medida que ms informacin est disponible en los productos en cuestin. Aunque el FMECA es una tarea esencial de la confiabilidad, tambin proporciona informacin para otros fines. El uso de la FMECA se usa tambin en la mantenibilidad, anlisis de seguridad, supervivencia y vulnerabilidad, anlisis de apoyo logstico, anlisis de plan de mantenimiento, y para la deteccin de fallas y aislamiento en el diseo del sistema. Este uso coincidente debe ser una consideracin en la planificacin del esfuerzo FMECA para evitar la proliferacin de requisitos y la duplicacin de esfuerzos dentro del programa contractual

DEFINICIONES
a. Modo de Falla Una forma particular en que un elemento falla, independiente de la razn de la falla. b. Anlisis del modo de falla y de efectos (FMEA) Un procedimiento por el cual se analiza cada modo de falla posible de cada elemento desde un nivel de jerarquizacin ms bajo al

44

ms alto para determinar los efectos en el sistema y para clasificar a cada modo de falla potencial de acuerdo con la gravedad de su efecto. c. Niveles de particin - La jerarqua de los niveles del equipo desde la parte al componente del subsistema en el sistema, etc. d. Redundancia - Ms de un medio independiente para realizar una funcin. Hay diferentes tipos de redundancia, incluyendo: a. Operacional tems redundantes, que se activan durante el ciclo operativo, incluye sobre-carga, en donde elementos redundantes se conectan de una manera tal que, si falla un elemento, el otro seguir desempeando la funcin. No es necesario desconectar el elemento en falla o cambiar hacia la redundancia. b. Standby - Los elementos no funcionan (no tienen ninguna potencia aplicada) hasta que se conmuta en caso de falla del elemento primario. c. Redundancia tems idnticos realizando la misma funcin. d. Redundancia con diferencia - tems no idnticos realizando la misma funcin.

ALCANCE
Las reglas tpicas bsicas para un FMECA se formalizan junto con un resumen de la tcnica, objetivo, instrucciones paso a paso, las hojas de ejemplo de trabajo, y las entradas de trabajo de las hojas de datos. Para proyectos especficos, por supuesto, aadir, eliminar y ajustar de otro modo los procedimientos para cumplir con sus necesidades, los objetivos y los requisitos contractuales. Esto es particularmente importante en los problemas de seguridad o los mtodos de solucin operativa. Aunque el software de anlisis est fuera del alcance de un FMECA, los efectos de los modos de falla en el software y las interfaces de hardware-software deben ser incluidos.

OBJETIVO DEL FMECA

El objetivo de un FMECA es identificar las formas como podran ocurrir fallas (modos de falla) y las consecuencias de las fallas en el rendimiento del equipo (efecto de falla) y las consecuencias sobre objetivo del equipo (asignacin de gravedad). Se basa en el caso habitual en el que efectos de la falla, que se expresan a nivel del sistema, son causados por los modos de falla del equipo a niveles ms bajos. El presente procedimiento, no cuantifica la probabilidad de ocurrencia de la falla, sino que una evaluacin cualitativa de los efectos de la falla se obtiene mediante la asignacin de los modos de falla a una categora de gravedad. Los resultados de los anlisis se utilizan para mejorar el rendimiento del sistema mediante el inicio de las medidas correctivas, por lo general no slo con los cambios de diseo, sino que tambin son tiles para centrar los procedimientos de garanta de producto y la identificacin de las limitaciones operativas. El FMECA se actualiza segn sea necesario para incluir cambios en el diseo y revisiones operacionales.

45

METODOLOGA
Usando la metodologa bottom up, el FMECA se inicia seleccionando el equipo en el nivel ms bajo de inters (por ejemplo, el mdulo de componentes, circuitos, partes). Los diferentes modos de falla que pueden ocurrir para cada elemento en ese nivel se tabulan. El correspondiente efecto de la falla, a su vez, se interpreta como un modo de falla en el siguiente nivel de funcionamiento. Sucesivas Iteraciones dan como resultado en ltima instancia en la identificacin de los efectos de la falla hasta el nivel ms alto del sistema. Es un proceso de induccin en sntesis.

ANLISIS PRELIMINAR DEL SUBSISTEMA

Durante la fase conceptual del desarrollo del sistema, cuando la informacin de diseo se limita a diagramas de bloques, un "enfoque funcional" es apropiado para la identificacin de problemas de diseo. Las fallas se postulan para los subsistemas principales (los subsistemas tambin se puede dividir en bloques de nivel inferior). Se evalan los efectos y se realizan los cambios de diseo conceptual segn sea necesario. A las fallas detectadas se le asignan a un nivel de gravedad con nfasis en las fallas catastrficas y crtica para los que se planifican posibles procedimientos de solucin.

EL ANLISIS DETALLADO DEL EQUIPO

El anlisis detallado del equipo se lleva a cabo cuando los elementos del equipo, lneas de seales y de energa han sido identificadas. Utilizando esquemas y planos de montaje, los modos de falla son postulados y evaluados sus efectos. Los modos de falla se definen en la interfaz del componente, basada en el conocimiento del diseo interno y se evalan los efectos a nivel de componentes y estos son levantados a niveles ms altos del montaje de equipo. El nivel del equipo en el que comience el anlisis se incluye en la declaracin del proyecto de trabajo, que por lo general requiere de un anlisis a nivel de componentes. El anlisis a menudo se extiende al nivel de la parte, segn sea necesario, esto es especialmente cierto para las consideraciones de seguridad. A nivel de parte, los modos de falla se define por las partes dentro de un componente y el efecto es evaluado en la interfaz del componente.

MODOS DE FALLA
Se identifican todas las formas en que una falla puede ocurrir en el nivel de jerarquizacin del equipo. Se postulan todos los modos probable, posible o creble de una falla, que incluyen los mecanismos de falla que se han observado histricamente y cuyos mecanismos se han descrito, de acuerdo con el razonamiento de ingeniera. La identificacin de los modos de falla se basa en el conocimiento de los componentes, las especificaciones funcionales, requisitos de la interfaz, esquemas o modos de falla de las piezas o partes asociadas a la interfaz. El anlisis es realizado con el propsito de detectar posibles fallas en la interfaz originadas dentro de la unidad.

46

Los modos de falla que se producen dentro de una unidad, ya sea elctrico o mecnico, se manifiestan en la interfaz con una de las condiciones de error siguientes: a. b. c. d. Operacin prematura. La falla de funcionamiento en un momento determinado, La falla de detener la operacin cuando sea necesario. Error durante la operacin.

Categoras de severidad para los efectos de la falla

Para proporcionar una medida cualitativa de los efectos de la falla, a cada modo de falla se le asigna a un nivel de severidad. Problemas de seguridad y el impacto a otros sistemas o su propiedad se reflejan en la seleccin del nivel de gravedad. El efecto de la falla se evala en primer lugar a nivel del equipo que se analiza, el nivel inmediatamente el nivel superior, el nivel de subsistema, y sigue por el sistema o el nivel de la misin. Para seleccionar el nivel de gravedad, la peor consecuencia de los casos, teniendo en cuenta todos los niveles, se asume para el modo de fallo y efecto que se analiza. Los niveles de gravedad se definen a continuacin. Para proyectos especficos se puede requerir definiciones ampliadas en funcin, por ejemplo, en la cantidad de degradacin que es permisible en funcin de datos cientficos. a. Categora 1, Catastrficos - Los modos de falla que podran resultar en lesiones graves o la muerte, o daos al equipo. b. Categora 1R, Catastrficos - Los modos de falla de elementos idnticos o de equipos equivalente redundantes que, si todos fallan podran dar lugar a efectos en la Categora 1. c. Categora 2, Crtica - Los modos de falla que podra resultar en la prdida de uno o ms objetivos para el cual el equipo se adquiri tal como se define por la oficina del proyectos. d. Categora 2R, Crtica - Los modos de falla de naturaleza de elementos idnticos del equipo o equivalente redundantes que podran resultar en la categora 2 si todos los elementos fallan. e. Categora 3, Importantes - Los modos de falla que podran causar la degradacin de los objetivos para el cual el equipo se adquiri o dise. f. Categora 4, Menores - Los modos de falla que podra resultar en prdida insignificante degradacin de los objetivos para el cual el equipo se adquiri o dise.

EL PROCESO DEL FMECA

A continuacin se presenta un procedimiento tpico para llevar a cabo un FMECA. La serie de tareas del ejemplo puede ser modificada de acuerdo con las necesidades operacionales de cada proyecto y de los objetivos del equipo. El procedimiento se resume en la figura 13 y la siguiente manera:
47

Fig. 13: Diagrama de flujo del FMECA 1. Definir el sistema a analizar. Una definicin completa del sistema incluye la identificacin de las funciones internas y de la interfaz, el rendimiento esperado en todos los niveles escritura, las limitaciones del sistema y las definiciones de falla. Todos los estados del sistema y fases del objetivo no analizadas hay que dar razn de la omisin. 2. Indican la profundidad del anlisis, identificando el nivel de jerarquizacin en la que se inicia el anlisis. 3. Identificar los requisitos especficos de diseo que se deben verificar por el FMECA. 4. Definir las reglas bsicas y los supuestos en que se basa el anlisis. Identificar las fases de la misin del objetivo y el estado de los equipos durante cada fase del objetivo. Un conjunto tpico de reglas bsicas (supuestos) a muestran a continuacin: a. Slo un modo de falla existe a la vez. b. Todas las entradas (incluyendo los comandos de software) para el tem que se analiza es el valores presentes y nominales. c. Todos los consumibles estn presentes en cantidades suficientes. d. La Potencia nominal est disponible. e. Todas las fases del objetivo son consideradas en el anlisis; las fases del objetivo que demuestran ser inaplicables pueden ser omitidas. f. Los modos de falla de un conector se limitan a: conector en desconexin. g. Se prestar especial atencin dirigida hacia la identificacin de las fallas individuales que podran causar la prdida de dos o ms rutas redundantes. 5. Obtener o construir diagramas de bloques funcionales y de confiabilidad indicando las interrelaciones de los grupos funcionales, el funcionamiento del sistema, canales independientes de datos, y las caractersticas de seguridad del sistema. 6. Identificar los modos de falla, efectos, deteccin de fallas y solucin caractersticas y otra informacin pertinente sobre la hoja de trabajo.
48

7. Evaluar la severidad de cada efecto de la falla de acuerdo con las categoras de gravedad prescrita. 8. Identificar los diseos del equipo (u operaciones) que son candidatos para la accin correctiva y recomendar medidas correctivas especficas. 9. Documentar el anlisis y entregar un resumen de los resultados.

EL ANLISIS DE CADA MODO DE FALLA

Las tareas enumeradas para el FMECA se realizan una vez para cada anlisis. Las tareas 6 y 7 se realizan para cada modo de falla. Un procedimiento de ejemplo para el anlisis de cada modo de falla es como sigue: 1. 2. 3. 4. 5. 6. 7. 8. Seleccionar una parte o circuito de interfaz para su anlisis. Identificar los tems como R1, C1, C2, o J05 pin 1, etc., adems de su nombre tcnico Postular una solo falla, incluyendo el modo de falla. A partir del conocimiento de la parte / circuitos, identificar una posible causa de falla. A partir del conocimiento del funcionamiento del circuito en la presencia de la falla postulada, evaluar el efecto local. Evaluar el efecto de la falla en el nivel superior y hacia arriba hasta el nivel ms alto del sistema de inters, es decir, el objetivo. Asignar un nivel de gravedad de acuerdo con las definiciones entregadas anteriormente. Proporcionar comentarios sobre cmo la falla podra ser detectada y qu medidas se pueden tomar para restablecer el funcionamiento. Si no se detecta, dejar constancia de ello. Proporcionar comentarios sobre la aplicacin de la reconfiguracin de redundancia para solucionar una falla, o cualquier otra informacin pertinente.

9.

COMPLETAR LA HOJA DE TRABAJO

En la figura 14 se presenta un ejemplo de hoja de trabajo que se utiliza para compilar los resultados de la FMECA. La redaccin debe ser breve y clara. Las siglas y abreviaturas se pueden utilizar siempre que aparecen en la lista de siglas en el proyecto global. Los elementos de la columna se ilustran en la figura 14, pero la explicacin es la siguiente para cada entrada de la columna. La siguiente es la informacin mnima que debe ingresar:

49

ANALISIS DEL MODO DE FALLA Y EFECTO Objetivo (Funcin): DTF 1 Sistema: FTS Sub-sistema/instrumento: 3.13 Componente: cabezal del actuador Fase del objetivo: despegue
Nmero del modo de falla Identificacin del tem o funcin a. Modo de falla b. Causa de la falla Efectos de la falla a. Local o subsistema b. Siguiente nivel superior sistema c. Efecto final objetivo Nivel de severidad Comentarios: a. Mtodo para detectar la falla. b. Acciones/caractersticas compensatorias. c. Otros

Fecha: Preparado por: Aprobado por:

3.13.6

Cabezal del actuador, el giro proporciona el movimiento de rotacin en el eje (x)

a. Prdida del control del motor b. Falla en la parte de accionamiento del circuito del motor

a. Prdida de movimiento de rotacin del cabezal y el torque b. No se puede continuar la tarea y la funcin de FTS c. Ninguno en el objetivo final

2R

a. El sensor de posicin y sensor de torque se muestra en el panel de control, b. Equipo de respaldo para poner el brazo en posicin segura. Un brazo robusto puede poner el brazo en posicin segura.

Fig.14: Hoja de trabajo para un anlisis FMECA

50

Informacin del tem en la hoja de trabajo

Nmero del modo de falla identificador nico para cada modo de falla evaluado. Ingrselos en orden numrico. Identificacin del tem / Funcin para el anlisis funcional, ingrese una descripcin de la funcin realizada. Para un anlisis del equipo, escriba un identificador nico, es decir, la nomenclatura, la designacin de referencia del dibujo / esquema, o el identificador en el diagrama de bloques. Si es posible, utilizar identificadores que son consistentes con el uso del programa. a. Modo de Falla; b. Causa de la falta identificar el modo de falla especfico considerando las cuatro condiciones bsicas de falla mostradas a continuacin: 1. 2. 3. 4. Operacin no programada. Falla al no operar cuando sea necesario. Falla de detener sus operaciones cuando sea necesario. Falla durante la operacin.

Para cada aplicacin del modo de falla del equipo, list la principal causa (s), por ejemplo, un conector separado, un capacitor en corto, capacitor abierto, resistencia cortocircuito a tierra, resistencia en corto para la tensin. Efectos de la falla liste los efectos la falla para cada uno de los niveles considerados del equipo. Liste en la columna a, b, c, de la siguiente manera: a. Nivel Local Introduzca una breve descripcin del efecto de fallo en el nivel de la subdivisin que se analiza. b. Nivel Superior Siguiente Introduzca el efecto de la falla al nivel del equipo por encima del nivel del anlisis. c. Efecto Final u Objetivo Introduzca el efecto del modo de falla en objetivo del equipo. (Si la falla no tiene ningn efecto, escribir ninguno.) Nivel de Severidad Asigne un nmero para identificar el nivel de gravedad (vase la definicin en los prrafos anteriores). Comentarios Escriba cualquier otra informacin pertinente, referencias o comentarios. En especial escriba: a. Cmo la falla sera detectada con las facilidades del equipo u operador. b. Trabajar con elementos redundantes en las caractersticas del diseo.

51

EL INFORME FMECA
Un resumen del proceso de anlisis FMECA se muestra en la figura 15:

Equipos de la lnea Construir diagramas de bloques funcionales y de confiabilidad

Planos y esquemas

Reglas bsicas

Lista de partes

Diagrama de bloques

Revisin de datos Diagrama de confiabilidad Histricos de mantenimiento

Preparacin FMECA

Anlisis y construccin del FMECA

Jerarquizacin niveles de descomposicin Otros documentos Lista de elementos indexados rbol completo de Eventos bsicos Ubicacin jerarquizacin Tablas Referencias

Diagrama de bloques del sistema Hoja de partes especiales Informe Final del anlisis FMECA

Fig. 15: Proceso de elaboracin de un anlisis FMECA

Los informes preliminares o provisionales estn generalmente disponibles para cada revisin del diseo. Un anlisis del sistema en el nivel funcional debe estar listo para la revisin preliminar del diseo. Los informes provisionales deben contener todos los modos de falla y la identificacin de las reas problema con las acciones correctivas propuestas. Los siguientes son los principales tpicos cubiertos en el informe final: a. b. c. d. e. f. g. Descripcin detallada del sistema con diagramas de bloques de confiabilidad. Los niveles de jerarquizacin analizados. Resumen de los resultados. Resumen de las reglas bsicas y los supuestos. Identificacin y discusin de los modos de falla que son potenciales reas de problemas. Lista de tems no incluidos en el FMECA y la justificacin de la exencin. Hojas de trabajo organizado desde el nivel del sistema hacia menor unidad analizada
52

EL ENFOQUE META, PREGUNTA, METRICA

(GQM: GOAL, QUESTION, METRIC) INTRODUCCION
Como con cualquier disciplina de ingeniera, el desarrollo de un producto requiere un mecanismo de medicin para la retroalimentacin y la evaluacin. La medicin es un mecanismo para crear una memoria corporativa y una ayuda para responder a una variedad de preguntas relacionadas con la difusin de cualquier proceso de un proyecto. Ayuda a apoyar la planificacin del proyecto (por ejemplo, Cunto ser el costo del nuevo proyecto?), sino que tambin permite determinar las fortalezas y debilidades de los actuales procesos y productos (por ejemplo, Cul es la frecuencia de ciertos tipos de errores?), adems proporciona una justificacin para la adopcin / refinamiento de las tcnicas (por ejemplo, Cul es el impacto de la tcnica XX en la productividad de los proyectos?), permite evaluar la calidad de los procesos y productos especficos (por ejemplo, Cul es la tasa de defectos en un determinado sistema despus de su implementacin?). La medicin tambin contribuye durante el transcurso de un proyecto, para evaluar su progreso, para tomar medidas correctivas sobre la base de esta evaluacin, y para evaluar el impacto de dicha accin. En la aplicacin de mtricas y modelos en entornos industriales, la medicin, con el fin de ser eficaz debe ser: 1. Centrada en objetivos especficos; 2. Aplicada a todos el ciclo de vida del productos, procesos y recursos; 3. Interpretada en funcin de la caracterizacin y comprensin del contexto organizacional, medio ambiente y metas. Esto significa que la medicin debe ser definida de una manera de top down y debe ser focalizada en base a objetivos y modelos.

EL ENFOQUE GQM
El enfoque (GQM) se basa en la suposicin de que para que una organizacin pueda medir en forma til primero debe especificar las metas para s misma y para sus proyectos, enseguida debe trazar los objetivos para los datos que tienen relacin para definir los objetivos operativos, y por ltimo proporcionar un marco para la interpretacin de los datos con respecto a los objetivos fijados. Por lo tanto, es importante dejar en claro, al menos en trminos generales, qu necesidades de informacin tiene la organizacin, de manera que estas necesidades de informacin pueden ser cuantificadas siempre que sea posible, y la informacin cuantificada pueda ser analizada para evaluar si los objetivos se estn logrando.

53

El resultado de la aplicacin del enfoque GQM es la especificacin de un sistema de medicin apuntando a un conjunto particular de problemas y un conjunto de reglas para la interpretacin de los datos de medicin. El modelo de medicin resultante tiene tres niveles: 1. Nivel conceptual (META): Un objetivo se define por un objeto, por una variedad de razones, con respecto a los distintos modelos de calidad, desde diversos puntos de vista, en relacin con un entorno particular. Los objetos de medicin son: Productos: artefactos, productos y documentos que se producen durante el ciclo de vida del sistema, por ejemplo, especificaciones, diseos, programas, series de pruebas. Procesos: actividades relacionadas con el proyecto que normalmente se asocian con el tiempo, por ejemplo, la especificacin, diseo, pruebas, entrevistas. Recursos: los elementos utilizados por los procesos para producir sus productos, por ejemplo, el personal, hardware, software, espacio de oficinas. 2. Nivel operacional (PREGUNTA): Un conjunto de preguntas se utilizan para caracterizar la forma de la evaluacin / del logro de un objetivo especfico que va a llevarse a cabo sobre la base de un modelo de caracterizacin. Las preguntas tratan de caracterizar el objeto de la medida (de productos, procesos, recursos) con respecto a un problema de calidad seleccionada y para determinar su calidad desde el punto de vista seleccionado. 3. Nivel cuantitativo (METRICA): Un conjunto de datos asociados a cada pregunta con el fin de responderla de una manera cuantitativa. Los datos pueden ser: Objetivo: Si depende slo del objeto que se est midiendo y no en el punto de vista de los que la toman, por ejemplo, nmero de versiones de un documento, las horas del personal dedicado a una tarea, el tamao de un programa. Subjetivo: si dependen tanto del objeto que est siendo medido y el punto de vista de los que la toman, por ejemplo, la legibilidad de un texto, el nivel de satisfaccin de los usuarios. El modelo GQM es una estructura jerrquica (Figura 16) que se inicia con una meta (especificando el propsito de la medicin, el objeto a ser medido, el asunto que se mide, y el punto de vista de donde se toma la medida). La meta es refinada con varias preguntas, como en el ejemplo a continuacin, que generalmente suele quebrar el problema en sus componentes principales. Cada pregunta se refina en las mtricas, algunos de ellas objetivas, y otras subjetivas. La misma mtrica se puede utilizar con el fin de responder a diferentes preguntas en el mismo objetivo. Varios modelos GQM tambin pueden tener preguntas y mtricas comunes, asegurndose de que, cuando la medida se toma realmente, los diferentes puntos de vista se toman en cuenta correctamente (es decir, la medida podra tener valores diferentes cuando se toman desde diferentes puntos de vista).

54

DEFINICIN

Nivel Operacional Preguntas que tratan de caracterizar el objeto de las medidas en el contexto del aspecto de calidad desde un punto de vista particular

Preg. 1

Preg. 2

Preg. 3

Preg. 4

Preg. 5

Nivel Cuantitativo Asociados con cada pregunta es el conjunto de datos, ya sean objetivos o subjetivos, que ayudan a entregar una respuesta cuantitativa

Met. 1

Met. 2

Met. 3

Met. 4

Met. 5

Met. 6

Fig. 16: Proceso jerrquico del anlisis GQM Con el fin de dar un ejemplo de aplicacin del enfoque Meta / Pregunta / Mtricas, suponer que se quiere mejorar la puntualidad del procesamiento de la solicitud de reparacin durante la fase de mantenimiento del ciclo de vida del sistema. El objetivo resultante es especificar un objetivo (mejorar), un proceso (proceso de solicitud de reparacin), un punto de vista (director del proyecto), y un problema de calidad (puntualidad). Esta meta puede ser refinada por una serie de preguntas, sobre, por ejemplo, el tiempo de respuesta y los recursos utilizados. Estas preguntas pueden ser respondidas por mtricas de comparacin especfica de los tiempos de respuesta con los tiempos medios. El proceso total Meta / Pregunta / Mtricas se muestra a continuacin: Meta Propsito Problema Objeto (proceso) Punto de vista Mejorar La puntualidad de Procesamiento de la solicitud de reparacin Del director del proyecto Cul es la actual velocidad de procesamiento de la solicitud de reparacin? Ciclo de tiempo promedio Desviacin estndar % de casos fuera del lmite superior Es mejorable la eficiencia del proceso? Ciclo de tiempo promedio actual Ciclo de tiempo promedio base Porcentaje subjetivo a satisfaccin del administrador
55

Pregunta Mtrica

Pregunta Mtrica

ANLISIS E INTERPRETACIN

Nivel Conceptual Metas medibles que involucran productos, procesos y/o recursos

Meta 1

Meta 2

EL PROCESO GQM
Un modelo GQM se desarrolla mediante la identificacin de un conjunto de objetivos o metas de calidad y/o productividad, a nivel corporativo, de divisin, o de proyecto, por ejemplo, la satisfaccin del cliente, la entrega a tiempo, mejorar el rendimiento. A partir de esos objetivos o metas, y basado en modelos del objeto de la medida, se derivan las preguntas que definen las metas de forma ms completa posible. Por ejemplo, si se trata de caracterizar un sistema de software (un paquete de correo electrnico, un procesador de textos u otros) con respecto a un determinado conjunto de problemas de calidad (por ejemplo, la portabilidad a travs de distintas arquitecturas), entonces un modelo de calidad del producto se debe elegir que se ocupe de estas cuestiones (por ejemplo, la lista de las caractersticas funcionales que pueden ser implementadas en diferentes arquitecturas). El siguiente paso consiste en especificar las medidas que deben ser recogidas con el fin de responder a esas preguntas, y realizar el seguimiento del cumplimiento de los productos y procesos con los objetivos. Despus que las medidas se han especificado, es necesario desarrollar los mecanismos de recopilacin de datos, incluidos los mecanismos de validacin y anlisis. El proceso de definicin de metas es fundamental para la aplicacin exitosa del enfoque GQM y es apoyado con ciertos pasos metodolgicos. Como se ilustra en la Figura 17 y en el ejemplo anterior, el objetivo tiene tres coordenadas: 1. 2. 3. Tema Objeto (proceso) Punto de vista Puntualidad Cambio el procesamiento de solicitudes Del Jefe de Proyecto

y un propsito: 1. Propsito Mejorar

Entonces, el desarrollo de una meta se basa en tres fuentes bsicas de informacin. La primera fuente es la poltica y la estrategia de la organizacin que est aplicando el enfoque GQM. De esta fuente se deriva tanto del tema y el propsito de la meta mediante el anlisis de las declaraciones de polticas de las empresas, planes estratgicos y, ms importante, entrevistando a las personas claves en la organizacin. La segunda fuente de informacin es la descripcin de los procesos y productos de la organizacin, o, al menos, los que estn dentro del alcance de la medida que desea realizar. Si, por ejemplo, se quiere evaluar un proceso, se necesita un modelo de ese proceso y de los componentes de los sub procesos. De esta fuente se deriva la coordenada objeto para la META mediante la especificacin de modelos de procesos y productos, en el mejor nivel posible de formalidad.

56

Fig. 17: Coordenadas para un proceso GQM La tercera fuente de informacin es el modelo de la organizacin, lo que proporciona la coordenada punto de vista de la META. Obviamente, no todos los temas y los procesos son relevantes para todos los puntos de vista en una organizacin, por lo tanto, hay que realizar una etapa de anlisis de relevancia antes de completar la lista de objetivos, con el fin de asegurarse de que los objetivos que se han definido tienen la relevancia necesaria. De esta manera, se encuentra con una especificacin de las metas que tiene en cuenta la estructura y el objetivo de la organizacin. A partir de la especificacin de cada meta que se puede derivar preguntas significativas que caracterizan a esa meta de una forma cuantificable. En general, al menos se necesitan tres grupos de preguntas: Grupo 1. Cmo se puede caracterizar el objeto (producto, proceso o recurso) con respecto a la meta global del modelo especfico GQM? Ejemplo: Pregunta: Cul es la actual velocidad de procesamiento de la solicitud de reparacin? Pregunta: Es (documentado) el proceso de solicitud de reparacin actualmente ejecutado? Grupo 2. Cmo se pueden caracterizar los atributos del objeto que son relevantes con respecto al tema del modelo especfico GQM? Ejemplo:
57

Pregunta: Cul es la desviacin del tiempo de procesamiento del actual proceso de solicitud de reparacin, desde el tiempo estimado? Pregunta: Se est mejorando la eficiencia del proceso? Grupo 3. Cmo se evalan las caractersticas del objeto que son relevantes con respecto al tema del modelo especfico GQM? Ejemplo: Pregunta: Es la actual eficiencia satisfactoria desde el punto de vista del administrador del proyecto? Pregunta: Es la eficiencia visiblemente mejorada? Una vez que las preguntas se han desarrollado, se procede a asociar la pregunta con las mtricas adecuadas. Los factores que se consideran para hacer esto son muchos, entre ellos: Cantidad y calidad de los datos existentes: se trata de maximizar el uso de fuentes de datos existentes, si estn disponibles y son confiables; Madurez de los objetos de medidas: se van a aplicar las medidas objetivas de medicin a los objetos con mayores conocimientos de ellos, y se harn uso de las evaluaciones ms subjetivas cuando se trata de objetos informales o inestables. Proceso de aprendizaje: los modelos GQM necesitan siempre perfeccionamiento y adaptacin, por lo tanto, las medidas que se definen deben ayudar a evaluar no slo el objeto de medicin, sino tambin la confiabilidad del modelo utilizado para evaluarlo. Teniendo en cuenta estas ideas, se puede completar el modelo GQM con algunos parmetros adecuados. El resultado se muestra a continuacin: Meta Propsito Problema Objeto (proceso) Punto de vista Q1 M1 M2 M3 Q2 M4 M5 Mejorar La puntualidad de Procesamiento de la solicitud de reparacin Del director del proyecto Cul es la actual velocidad de procesamiento de la solicitud de reparacin? Ciclo de tiempo promedio Desviacin estndar % de casos fuera del lmite superior Es (documentado) el proceso de solicitud de reparacin actualmente ejecutado? Evaluacin subjetiva del administrador del proyecto % de excepciones identificadas durante las revisiones
58

Pregunta Mtrica

Pregunta Mtrica

Pregunta

Q3

Cul es la desviacin del tiempo de procesamiento del actual proceso de solicitud de reparacin, desde el tiempo estimado?
Tiempo promedio del ciclo actual Tiempo promedio estimado del ciclo Tiempo promedio del ciclo actual

Mtrica

M6 M7 Q4 M8 Q5 M7

Evaluacin subjetiva del administrador del proyecto Se est mejorando la eficiencia del proceso? Actual ciclo de tiempo promedio Ciclo de tiempo promedio base Es la actual eficiencia satisfactoria desde el punto de vista del administrador del proyecto? Evaluacin subjetiva del administrador del proyecto Se est mejorando la eficiencia del proceso? Ciclo de tiempo promedio actual Ciclo de tiempo promedio base Porcentaje subjetivo a satisfaccin del administrador

Pregunta Mtrica Pregunta Mtrica Pregunta Mtrica

Una vez que un modelo GQM se ha desarrollado, se seleccionan las tcnicas adecuadas de recoleccin los datos, las herramientas y procedimientos. Los datos que sern recolectados e mapeado en el modelo e interpretados de acuerdo a los planes previamente definidos por la organizacin.

59

ANLISIS DEL COSTO DEL CICLO DE VIDA

PORQU USAR EL ANLISIS COSTO DEL CICLO DE VIDA
El anlisis del costo del ciclo de vida (LCC) es un mtodo de evaluacin de proyectos en el cual todos los costos que se levantan desde la adquisicin, operacin, mantenimiento y por ltimo su eliminacin de un proyecto son considerados ser potencialmente importante para esa decisin. El LCC puede ser aplicado para cualquiera decisin de inversin de capital en el cual los altos costos inciales son negociados para reducir futuras obligaciones de costos. El LCC provee una base significativamente mejor para la eficiencia de los costos en el largo plazo que un mtodo alternativo econmico que se focalice solamente en los primeros costos o en costos relacionados con la operacin de corto plazo. El LCC es una herramienta de anlisis econmico poderosa. Como tal, requiere ms informacin que para hacer el anlisis basado en consideraciones del primer costo o de corto plazo. Tambin requiere conocimiento adicional de parte del analista de conceptos tales como flujo de caja descontado, dinero constante versus corriente y tasa de escalamiento de precios. La alternativa, sin embargo, es ignorar las consecuencias de costos de largo plazo de las decisiones de inversin, rechazar oportunidades de inversiones rentables, y aceptar costos ms altos que los necesarios.

QU ES EL ANLISIS DEL COSTO DEL CICLO DE VIDA?

El Anlisis de costos del ciclo de Vida (LCCA) es una tcnica de evaluacin aplicable a la consideracin de ciertas decisiones de inversin. En concreto, cuando se ha decidido que el proyecto se llevar a cabo, LCCA ayudar en determinar la mejor la de ms bajo costo forma de realizar el proyecto. El enfoque LCCA permite comparar el costo total de alternativas de diseos competitivos, cada una de ellas apropiadas para la implementacin de un proyecto. Todos los costos relevantes que se producen a lo largo de la vida de una alternativa, no slo el gasto original, estn incluidos. Tambin, los efectos de la construccin y las actividades de mantenimiento en los usuarios, as como los costos directos producto de la inversin, se tienen en cuenta. En resumen, el proceso de LCCA comienza con el desarrollo de alternativas para lograr los objetivos estructurales y de rendimiento de un proyecto. Luego, el analista define el calendario de las actividades inciales y futuras involucradas en la implementacin de cada alternativa de diseo del proyecto. A continuacin, se estiman los costos de estas actividades. Las mejores prcticas LCCA incluyen no slo los gastos directos del proyecto (por ejemplo, actividades de construccin o mantenimiento), sino tambin los costos para facilitar a los usuarios de las instalaciones que resultan de estas actividades del proyecto.
60

El cronograma previsto de actividades y los costos asociados a sus organismos y usuarios forman el flujo proyectado del costo de ciclo de vida (LCC) para cada alternativa de diseo. Usando una tcnica econmica conocida como "descuento", estos costos se convierten en dinero presente y se suman para cada alternativa. El analista puede entonces determinar qu alternativa es la ms rentable. Es importante sealar que la opcin ms baja del LCC no necesariamente puede aplicarse cuando otras consideraciones tales como el riesgo, los presupuestos disponibles, y las preocupaciones polticas y ambientales son tomadas en cuenta. El LCCA proporciona informacin crtica para el conjunto de toma de decisiones, pero no es la respuesta final.

POR QU USAR LCCA?

Las decisiones relacionadas con la aplicacin de un proyecto en general, requieren que varias alternativas sean consideradas. Muchos factores contribuyen a la decisin de un inversionista para seleccionar una opcin en particular, aunque los costos inciales de los proyectos pueden llegar a dominar esta decisin. Los costos inciales del proyecto, sin embargo, son slo una parte de la historia. La alternativa de diseo seleccionado compromete a los inversionistas para los futuros gastos de mantenimiento y acciones de rehabilitacin durante el ciclo de vida del proyecto. El LCCA proporciona los medios para incluir el costo total de los inversionistas y de usuarios en la decisin de inversin. Adems, la estructura y documentacin del proceso de LCCA provee a los inversionistas y analistas con la capacidad de mejorar su gestin de inversin.

TERMINOLOGA DE ANLISIS DEL COSTO DEL CICLO DE VIDA

El anlisis de costos del Ciclo de Vida es un proceso de diseo esencial para el control de costos inciales y en el futuro de la construccin del inversionista. El LCCA se puede aplicar en cualquier nivel del proceso de diseo y tambin puede ser una herramienta eficaz para la evaluacin de sistemas de construccin actuales. ACCV se pueden utilizar para evaluar el costo de una amplia gama de proyectos, desde un proyecto complejo a un componente de un sistema especfico. El costo del ciclo de vida es el costo total en dinero de descuento de poseer, operar, mantener y disponer de un sistema en un perodo de tiempo. Teniendo en cuenta esta definicin, se puede descomponer la ecuacin del LCC en las siguientes tres variables: los costos pertinentes de la propiedad, el perodo de tiempo durante el cual se incurre en estos costos, y la tasa de descuento que se aplica a los costos futuros para equipararlos con los presentes los costos de los das.

Los gastos inciales y futuros

El primer componente en una ecuacin de LCC es el costo. Hay dos categoras principales de costos por los que los proyectos deben ser evaluados en un LCCA. Son gastos inciales y gastos
61

futuros. Los gastos inciales son todos los gastos incurridos antes de la ocupacin de las instalaciones: gestin de la construccin, adquisicin de tierras, investigacin del sitio, servicios de diseo, construccin, equipo, tecnologa, indirectos / administracin, difusin, contingencia, entre otros). Gastos de futuro son todos los gastos incurridos despus de la ocupacin de las instalaciones: Costos de operacin (costos anuales): combustibles, electricidad, agua y alcantarillados, basura, guardias, seguros; Costo de mantenimiento y reparacin (gastos programado y no programado de mantenimiento) mejoras en el sitio, habilitacin del sitio, fundacin / infraestructura, sistemas de transporte, sistemas de proteccin contra incendios, controles HVAC, servicio elctrico / generacin, distribucin de energa elctrica, equipo y mobiliario; etc.; Costo de reemplazo (reemplazo programado de los sistemas de construccin o componentes); Valor residual (valor de las instalaciones al final del periodo de estudio). La definicin de los costos exactos de cada categora de gasto puede ser algo difcil, ya que, en el momento del estudio del LCC, casi todos los costos son desconocidos. Sin embargo, a travs del uso de supuestos razonables, coherentes y bien documentado, un LCCA con alta certeza puede estar preparado. Tambin hay que destacar que no todas las categoras de costos son relevantes para todos los proyectos. El analista es el responsable de la inclusin de las categoras de costos pertinentes que producir una comparacin realista LCC de las alternativas del proyecto. Si los costos en una categora de gastos en particular son iguales en todas las alternativas del proyecto, que pueden ser documentados como tales se retiran de la cuenta en la comparacin de los LCC.

Valor Residual
Un gasto futuro que merece una explicacin ms detallado es la del valor residual. El valor residual es el valor neto de un activo al final del perodo de estudio LCCA. A diferencia de otros gastos futuros, el valor residual de una alternativa que puede ser positivo o negativo, un costo o un valor. Ya que el LCC es una sumatoria de los costos, el valor residual negativo indica que hay un valor asociado al activo al final del perodo de estudio. Cualquiera sea la razn por el valor residual, es un activo tangible del propietario y debera ser incluidos en el LCCA. Un valor residual positivo indica que hay costos asociados con la eliminacin del activo al final del perodo de estudio. Tal vez, los costos estn relacionados con la reduccin de materiales peligrosos o la demolicin de la estructura. Cualquiera sea la causa, se trata de costos del propietario y deberan ser incluidos en el LCCA. Un valor residual cero indica que no existe un valor o costo asociado con el activo al final del perodo de estudio. Este caso raro se produce cuando el uso que se destina el activo termina
62

concurrente al final del perodo de estudio, el propietario no puede vender el edificio, y el propietario es capaz de abandonar el edificio sin costo alguno.

Perodo de Estudio
El segundo componente de la ecuacin de LCC es el tiempo. El perodo de estudio es el perodo de tiempo durante el cual los gastos de la propiedad (todos los ya enumerados) y de las operaciones deben ser evaluados. Por lo general, el perodo de estudio puede variar desde veinte a cuarenta aos, dependiendo de las preferencias del propietario, la estabilidad del programa del usuario, y la vida estimada total de la instalacin. Mientras que el largo del perodo de estudio es a menudo un reflejo de la vida prevista de una instalacin, el periodo de estudio suele ser ms corto que la vida til prevista de la instalacin.

Tasa de Descuento Real

El tercer componente de la ecuacin de LCC es la tasa de descuento. La tasa de descuento, la definicin es "la tasa de inters refleja el valor del dinero de los inversores en el tiempo." Bsicamente, es la tasa de inters que hara a un inversor ser indiferente en recibir un pago ahora o un pago mayor en algn momento en el futuro.

Dinero Constante
As como las tasas de descuento se pueden definir como real o nominal, tambin lo pueden ser los costos. Se define el dinero constante como "dinero de poder adquisitivo uniforme ligado a un ao de referencia y exclusivo del ndice general de precios la inflacin o deflacin." Cuando se utiliza la tasa de descuento real en los clculos de valor presente, los costos debern ser expresados en dinero constantes. Del mismo modo, cuando se utiliza la tasa de descuento nominal en los clculos de valor presente, los costos deben ser expresados en dinero corriente. En el raro caso de que la tasa de inflacin sea cero, donde dinero constante es igual a dinero corriente y la tasa de descuento real es igual a la tasa de descuento nominal. En la prctica, el uso de los dineros constantes simplifica la LCCA. Por ejemplo, suponga que se quiere evaluar los productos de techado en un perodo de 30 aos. Sin embargo, un producto de tejado debe ser reemplazado despus de 20 aos. Cul ser el costo de reemplazo del techo en 20 aos? Mediante el uso de dineros constantes, la conjetura de la estimacin de la escalada de los costos de mano de obra y materiales se elimina. El costo futuro en dineros constantes (con exclusin de la demolicin) para instalar un nuevo techo en 20 aos es el mismo que el costo inicial para instalar el techo. Cualquier cambio en el valor del dinero con el tiempo se explica por la tasa de descuento real.

63

Valor Presente
Para combinar con precisin los gastos inciales con los gastos futuros, debe ser determinado el valor presente de todos los gastos. Se define el valor presente como "el valor equivalente en el tiempo de pasados, presentes o futuros flujos de caja efectivo a partir del inicio del ao base." El clculo del valor presente usa la tasa de descuento y el tiempo en que un costo fue o se va a incurrir para establecer el valor presente del costo en el ao base del perodo de estudio. Dado que la mayora de los gastos inciales se producen en la misma poca, los gastos inciales se consideran que ocurre durante el ao base del perodo de estudio. Por lo tanto, no hay necesidad de calcular el valor presente de estos gastos inciales debido a su valor presente es igual a su costo real. La determinacin del valor presente de los costos futuros depende del tiempo. El perodo de tiempo es la diferencia entre el tiempo de los costos inciales y el tiempo de los costos futuros. Los costos inciales incurridos al inicio del perodo de estudio en el ao 0, el ao base. Los costos futuros se pueden incurrir en cualquier momento entre los aos 1 y el fin del proyecto. El clculo del valor presente es el ecualizador que permite la suma de los costos inciales y futuros. Junto con el tiempo, la tasa de descuento tambin determina el valor presente de los costos futuros. Debido a que la tasa de descuento es un valor positivo, los gastos futuros tienen un valor actual inferior a su costo en el momento en que se incurren. Los costos futuros se pueden desglosar en dos categoras: los gastos no recurrentes y los costos recurrentes. Los costos recurrentes son los costos que se producen cada ao en el lapso del perodo de estudio. La mayora de los costos de operacin y mantenimiento son costos recurrentes. Los costos no recurrentes son costos que no se producen siempre en los aos en el lapso del perodo de estudio. La mayora de los costos de reposicin son los costos de una sola vez. Para simplificar la LCCA, todos los gastos recurrentes y no recurrentes se expresan como los gastos anuales ocasionados al final de cada ao y en el ao en que se producen. Para determinar el valor presente de los gastos no recurrentes se utiliza la siguiente frmula:

Donde: VP = Valor Presente At = gasto no recurrente en el ao t i = Tasa de Descuento Real t = Tiempo (expresado como nmero de aos)

64

Para determinar el valor presente de los costos recurrentes se utiliza la siguiente frmula:

Donde: VP = Valor Presente A0 = Cantidad del Costo Recurrente i = Tasa de descuento real t = Tiempo (expresado como nmero de aos)

SELECCIN DE ALTERNATIVAS DEL PROYECTO

Antes de iniciar un LCCA, las alternativas de proyectos deben estar establecidas. Estas alternativas deben ser diferentes y las posibles soluciones viables para el problema que se trate. La alternativa elegida es la solucin ms razonable y rentable para el problema del proyecto. Un mnimo de tres alternativas diferentes de proyectos deben ser incorporadas al LCCA. En el LCCA se debe incluir una breve descripcin de cada alternativa de proyecto y por qu fueron elegidas. Un LCCA slo necesita tratar las categoras de costos que son pertinentes para el alcance del proyecto. Sin embargo, para asegurar una comparacin precisa de alternativas, todas las evaluaciones LCCA de las alternativas del proyecto deben incorporar las mismas categoras de costos. El LCCA de cada alternativa de proyecto debe incluir: Una breve descripcin de la alternativa de proyecto Una breve explicacin de por qu la alternativa de proyecto fue seleccionado Una breve explicacin de los supuestos formulados durante el LCCA Una documentacin conceptual o esquemtica que indica el diseo intentado de la alternativa Un plano del lugar que muestra la integracin de las instalaciones propuestas en el lugar y las mejoras necesarias del lugar (para proyectos que impliquen adiciones o nueva construccin) Un LCCA detallada de la alternativa de proyecto Una tabla resumen que compara los costos totales del ciclo de vida de la inversin inicial, operaciones, mantenimiento y reparacin, reposicin, valor residual de todas las alternativas del proyecto.

65

EL PROCESO DEL COSTO DE CICLO DE VIDA

Como se muestra en el diagrama adjunto, el costo del ciclo de vida es un proceso de seis etapas. Las primeras cuatro etapas comprenden la fase de planificacin del costo de la vida til con las dos ltimas etapas incorporando la fase de anlisis del costo. Las seis etapas son las siguientes:

Etapa 1: Anlisis del Plan de LCC

Etapa 6: Aplicar y Supervisar el Anlisis de Costos de Vida

Etapa 2: Seleccionar / Desarrollar Modelo LCC

Etapa 5: Preparar el Anlisis de Costo de Vida

Etapa 3: Aplicar el Modelo LCC

Etapa 4: Documentar y Revisar los Resultados LCC

Todas las etapas se pueden realizar de forma iterativa si es necesario. Las suposiciones hechas en cada etapa deben ser rigurosamente documentadas para facilitar tales iteraciones y para ayudar en la interpretacin de los resultados de los anlisis. El anlisis LCC es una actividad multidisciplinaria. Un analista debe estar familiarizado con la filosofa, que es la base del clculo del costo del ciclo de vida (incluidos los elementos de costos tpicos, las fuentes de datos sobre los costos y los principios financieros), y debe tener una clara

66

comprensin de los mtodos de evaluacin de las incertidumbres asociadas a la estimacin de costos. Dependiendo del alcance del anlisis, ser importante obtener los costos de los insumos individuales que estn relacionados con cada una de las fases del ciclo de vida del activo. Esto puede incluir representantes del proveedor(s) y del usuario(s).

CONCLUSIN
El ciclo de vida de los activos nace desde la idea misma de realizar una actividad que involucrar activos en su desarrollo, pasa por las etapas de anteproyecto, proyecto, diseo, compra o manufactura, instalacin, prueba, puesta en marcha, operacin y mantenimiento, hasta su eventual reciclaje, descarte disposicin final. En todas esas etapas, hay decisiones a tomar, informacin a seguir, costos a evaluar, registrar y considerar, repuestos a definir, capacitacin de operadores y mantenedores a desarrollar, anlisis que hacer referentes a distintos aspectos de la operacin y el mantenimiento del activo. La adecuada consideracin de todos esos factores es clave en el logro del objetivo de maximizar el ROA (Retorno Sobre los Activos) y minimizar el LCC (Costo de Ciclo de Vida), as como lograr los adecuados TIR (Tasas de Retorno sobre Inversiones) que viabilicen nuestros proyectos. El comprender estos conceptos en un mundo globalizado es de primera y vital importancia para los Gerentes y Directores responsables de la Gestin de Activos en las Empresas y Corporaciones hoy da.

BIBLIOGRAFIA
Basili V., Caldiera G., The Goal Question Metric Paradigm, Encyclopedia of Software Engineering 2 Volume Set, John Wiley 1994 Flight Assurance Procedure, Performing a Failure Mode and Effect Analysis MIL-STD P-302-720, Flores Juan, Identificacin y Evaluacin de Riesgos HAZOP, Prevention-World, 2003 Fuller S., Petersen S., Life-Cycle Costing Manual, NIST Handbook 135, Ed. 1995 Garcia Oliverio, El Anlisis Causa Raz, Estrategia de Confiabilidad Operacional, Lubrication Excellence, Conferencia y Exhibicin, 2005
67

GITP People Business, Trend and Issues in Performance Management, September 2006 Maquis Hank, Fishing for Solution: Ishikawa, DITY Weekly Newsletter, Vol. 5,42, Oct. 2009 Maquis Hank, Thinking about Problems: Kepner-Tregoe, DITY Weekly Newsletter Vol. 6.19, May 2010 Mearing T., Cofee N., Morgan M. Life Cycle Cost Analysis Handbook, State of Alaska Department of Education & Early Development, !st Edition 1999 New South Wales Treasure, Total Asset Management, Life Cycle Costing Guidelines, Sep. 2004 Rooney J., Vanden L., Root Cause Analysis for Beginners, Quality Progress July 2004 Solingen R., Bergout E., The Goal/Question/Metric Method: a practical guide for quality improvement of software development, Mc Graw Hill, 1999 U.S. Deparment of Transportation, Life-Cycle Cost Analysis Primer, August 2002

68