CONFIABILIDAD OPERACIONAL DE EQUIPOS: METODOLOGÍAS Y HERRAMIENTAS
FERNANDO ESPINOSA FUENTES
ÍNDICE CONFIABILIDAD OPERACIONAL
1
ANÁLISIS CAUSA RAÍZ: ÁRBOL LÓGICO
5
ANÁLISIS CAUSA RAÍZ: ÁRBOL DE EVENTOS
12
EL MÉTODO KEPNER- TREGOE O MATRIZ DEL PERFIL COMPETITIVO
22
5 PORQUÉS PARA RESOLVER PROBLEMAS
26
DIAGRAMA DE ISHIKAWA PARA LA CAPTURA DE LAS SOLUCIONES
29
HAZARD AND OPERABILITY (HAZOP)
33
DESARROLLANDO UN ANÁLISIS DEL MODO DE FALLA Y EFECTO (FMECA)
44
EL ENFOQUE META, PREGUNTA, METRICA
53
ANÁLISIS DEL COSTO DEL CICLO DE VIDA
60
ii
CONFIABILIDAD OPERACIONAL La Ingeniería de la Confiabilidad se destaca como el marco teórico en el cual conviven las metodologías y técnicas necesarias para la optimización 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 pérdida de su función. El fin último del Análisis de confiabilidad de los activos físicos es cambiar las actividades reactiva y correctivas, no programadas y altamente costosas, por acciones preventivas planeadas que dependan de análisis objetivos, situación 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 sistemática, avanzadas herramientas de diagnóstico, metodologías de análisis y nuevas tecnologías, para optimizar la gestión, planeación, ejecución y control de la producción industrial. La Confiabilidad Operacional lleva implícita la capacidad de una instalación (procesos, tecnología, gente), para cumplir su función o el propósito que se espera de ella, dentro de sus límites de diseño y bajo un específico contexto operacional. Es importante, puntualizar que en un sistema de Confiabilidad Operacional es necesario el análisis de sus cuatro parámetros 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
1
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 visión clara de los fines del negocio. La variación en conjunto o individual que pueda sufrir cada uno de estos custro aspectos mostrados, afecta el desempeño general del sistema. Cualquier hecho aislado de mejora puede traer beneficios, pero no al considerarse los demás factores, sus ventajas son limitadas o diluidas en la organización 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 período de tiempo bajo determinadas condiciones de operación. Sin embargo esta definición no demuestra en realidad todos los alcances que conlleva. La confiabilidad es más 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 dirección hasta el empleado de más bajo nivel. La confiabilidad como cultura busca que todas las actividades de producción y en general todas las tareas se efectúen 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 dirección de la empresa tome conciencia de la nueva situación 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 dirección debe enfocar sus esfuerzos en la formación de sus empleados mediante políticas que permitan la participación del personal en planes de mejoramiento continuo de procesos, círculos de participación y demás 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 fácil ni a corto plazo, donde se debe hacer una gran inversión de capital y tiempo, en capacitación y reconocimiento y donde lo logros superan con creces las predicciones.
Aplicación de la Confiabilidad Operacional Las estrategias de Confiabilidad Operacional se usan ampliamente en los casos relacionados con: Elaboración de los planes y programas de mantenimiento e inspección de equipos e instalaciones industriales. Solución de problemas recurrentes en los activos fijos que afecten los costos y la efectividad de las operaciones. Determinación de las tareas que permitan minimizar riesgos en los procesos, equipos e instalaciones y medio ambiente. Establecer procedimientos operacionales y prácticas de trabajo seguro. Determinar el alcance y frecuencia óptima de paradas de planta. La Confiabilidad Operacional impulsa el establecimiento de tecnologías optimización industrial, entre las cuales se pueden destacar:
que faciliten la
2
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 también en forma sesgada error humano siendo este el ancla más fuerte. Gestión del Conocimiento, valor agregado de nuevas prácticas y conocimientos, a través de mediciones sistémicas, bancos de datos, correlaciones, simulaciones, minería de datos y estadísticas. Manejo de la incertidumbre, a través del análisis probabilístico de incertidumbre y riesgo asociado. Optimización Integral de la Productividad, a través de pruebas piloto en seguridad y confiabilidad desde el diseño.
Herramientas de Confiabilidad Operacional La confiabilidad como metodología de análisis debe soportarse en una serie de herramientas que permitan evaluar el comportamiento del activo de una forma sistemática a fin de poder determinar el nivel de operatividad, la cuantía del riesgo y las demás acciones de mitigación que se requieren, para asegurar su integridad y continuidad operacional. Son múltiples las herramientas de que se sirve la confiabilidad con el fin de formular planes estratégicos para lograr la excelencia en las actividades e mantenimiento. Las seis que se muestran en la Fig. 2, a continuación son las más utilizadas:
Fig. 2: Herramientas para la Confiabilidad Operacional 3
Análisis de Criticidad (CA). Es una técnica que permite jerarquizar sistemas, equipos e instalaciones, en función de su impacto global, con el fin de facilitar la toma de decisiones. Análisis de Modos y efectos de Falla y Criticidad (FMECA). Es una metodología que permite determinar los modos de falla de los componentes de un sistema, el impacto y la frecuencia con que se presentan. Análisis Causa Raíz (RCFA). Es una técnica sistemática que se aplica con el objetivo de determinar las causas que originan las fallas, sus impactos y frecuencias de aparición, para poder mitigarlas o eliminarlas. Inspección Basada en Riesgos (RBI). Es una técnica 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. Análisis Costo Riesgo Beneficio (BRCA). Es una metodología que permite establecer una combinación óptima entre los costos de hacer una actividad y lo logros o beneficios que la actividad genera, considerando el riesgo que involucra la realización o no de tal actividad. Costo del Ciclo de Vida (LCC). El análisis LCC es una metodología que permite elegir entre opciones de inversión 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.
4
ANÁLISIS CAUSA RAÍZ: ÁRBOL LÓGICO INTRODUCCIÓN La mayoría de los analistas de fallas han escuchado el término: Análisis de Causa Raíz (RCA por sus siglas en inglés) y seguramente cada quién tiene una interpretación diferente de su significado. Esta es la razón por la cual en muchos casos se tiene una forma poco efectiva de usarlo, y hay comunicación 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 evolución del Mantenimiento Productivo Total (TPM) ha habido un movimiento consistente hacia la exploración 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 salía de la línea. Aún cuando admirable esa medida era demasiado tardía si se hallaban defectos de calidad. El producto, y probablemente todo el lote tenía que ser reprocesado a un alto costo para la organización. 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 variación inaceptable. De esta manera, se corrige la variación en el proceso y se evita la manufactura de productos fuera de especificación. Esta era se está continuando actualmente con la introducción 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 método 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 más 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 Lógico permite representar gráficamente las relaciones de causa y efecto que conducen a descubrir el evento indeseable y cuál fue la causa raíz 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 observación directa, documentación y algunos conceptos científicos. ¡No pueden ser rumores ni suposiciones! Por ejemplo, en el caso que se presenta enseguida, la mayoría de las personas insistirían en comenzar con la falla del rodamiento. Sin embargo, cuando el evento se presentó, ¿por qué llamó la atención? No llamó la atención el rodamiento fallando, sino el hecho de que la bomba dejó de proveer el fluido. Por lo tanto el evento final que llamó la atención fue la falla de la bomba. Una razón o modo de que la bomba fallase fue debido a la falla del rodamiento. Esto resulta evidente cuando se ve el rodamiento dañado (evidencia física). La parte alta del Árbol Lógico se verá así (Fig. 3):
5
Fig. 3: Evento no deseado Continuando con la búsqueda en retrospectiva de la causa y relaciones de los efectos, se pregunta: ¿Cómo puede fallar un rodamiento? Las hipótesis pueden ser: erosión, corrosión, fatiga, lubricación o sobrecarga. ¿Cómo se puede verificar cuál de ellas es la verdadera causa? Simplemente se puede solicitar que un laboratorio metalúrgico y un experto hagan un análisis del rodamiento. Para efectos de este ejemplo, se supone que el reporte indica que sólo hubo signos de fatiga, ahora el "Árbol Lógico" 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 hipótesis, 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 serán las correctas, porque no se están haciendo suposiciones, sino se están
6
basando en "hechos". Esto también 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 precisión, se deben usar los conceptos de TPM en los procesos administrativos también. 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 solución al problema, mientras para otros, representa el reunirse y discutir para llegar a una conclusión; para otros más, RCA representa usar un proceso disciplinado de pensamiento hasta llegar a la verdadera causa original del problema. 1) Cuando el "experto" proporciona una solución, se confía, se hace un gasto para aplicar la solución que propuso, y se ve si funciona. A veces sí funciona, otras no. Esto equivale a la inspección 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. Quizás 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 hipótesis sean desarrolladas para ver exactamente por qué ocurrieron las causas, y luego requiere también una verificación 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 lógico en la eliminación de variables no relacionadas al RCA. Regresando a los anteriores escenarios de RCA. Si una bomba crítica fallara, dado el caso, se trataría que los mejores de nuestros técnicos la fueran a ver. Quizás concluirían luego de una gran discusión, que lo que se necesita es un rodamiento de trabajo más pesado.... Dadas las condiciones que se han analizado en el diagrama, ¿se resolvería el problema en forma permanente? Naturalmente que no ¡!. O qué tal si todos los técnicos de mantenimiento se reúnen y deciden que lo que está mal es el tipo de lubricante que se está usando...pues tampoco con esa acción se resolvería 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 crítica sin ninguna base sólida 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 científica) que hay evidencia de que existe fatiga en el material. Se preguntará entonces: ¿qué puede estar causando esa fatiga en el rodamiento? Se establece hipótesis: puede ser por vibración excesiva.
7
Fig. 5: Causas de una alta vibración
Se verifican los registros y se confirma que había demasiada vibración. ¿Qué puede estar causando la vibración? Hipótesis: Puede ser por desbalanceo, resonancia o desalineamiento. Se le pide al mecánico que la alineó la última vez que describa y muestre el procedimiento de alineación usado. Al preguntarle, se enteran que él no ha sido entrenado al respecto, sus herramientas no están en buen estado, y además no existe un procedimiento a seguir. Ahora se está en conocimiento de la REAL causa raíz, así que se pueden desarrollar las soluciones que, una vez implementadas, ¡¡¡TRABAJARÁN!!!
8
Usando este proceso disciplinado se genera un producto (en este caso un servicio de mantenimiento), de mucha calidad. Se sabe que la solución 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 ¿cuál es el papel que desempeña el encargado del análisis? La función del ingeniero será simplemente la de determinar científicamente CÓMO 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 hipótesis, sucedió o no sucedió. Los ingenieros proporcionan las piezas "¿CÓMO?" del rompecabezas y es a los “detectives del mantenimiento” a quienes les corresponde determinar "¿POR QUÉ?" se causó el problema. Usando tecnología: por ejemplo monitoreo de vibración, imágenes térmicas infrarrojas, análisis de esfuerzos, análisis de aceite, etc. para probar o eliminar las hipótesis, 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 función designada. En el intento para construir un "caso sólido", se deberá asociar las inequívocas causas-efecto que desembocaron en la falla. Esto incluye poner en juego los recursos científicos, propios o contratados, para probar la hipótesis. Explorando en este caso... El resultado indeseable fue que la bomba dejó de efectuar su función asignada. Para lograr un "caso sólido" se deberá entender las relaciones causa-efecto que dieron como resultado tal evento. Esto implicará el uso de dispositivos y recursos científicos para probar o eliminar las hipótesis. En el caso que se ilustra se puede ver "¿CÓMO?" la bomba pudo fallar y se usa la ciencia para probar el caso. Hipótesis Erosión, Corrosión, Fatiga y Sobrecarga Alta Vibración Desalineamiento
Técnicas de Verificación Análisis Metalúrgico Instrumentos y Vigilancia de la Vibración Tecnología de Alineación Láser
Estas relaciones aclaran el "¿CÓMO?", y el "¿POR QUÉ?" En este caso alguien dejó la bomba desalineada y tal acción o decisión causó una serie de causas y efectos para que finalmente la bomba fallase prematuramente. Los "ingenieros forenses" ya determinaron cómo sucedió, pero ¿Por qué alguien habría de dejar mal alineada la bomba? Es aquí donde se debe entender los motivos por los que la gente actuó erróneamente. Como analistas, si se va a profundidad en el proceso de pensamiento, se llegará a saber ¿Por qué la persona o personas tomaron tal decisión o acción? (Raíz Latente), se descubrirá exactamente la CAUSA RAÍZ y el por qué de la falla física. Se podría ver que la gente con frecuencia deja el equipo desalineado porque:
9
• • •
Nunca han sido entrenados en prácticas apropiadas de alineamiento No existe un procedimiento que defina el alineamiento y sus especificaciones como una práctica requerida El sistema que se está utilizando está desgastado o descalibrado en algunos casos.
Fig. 6: El cómo y el por qué de la falla del activo
Si no se explora el "¿Por qué?, es posible que el ¿Cómo? se vuelva a presentar una y otra vez”. En el caso anterior, ¿creen ustedes que el sólo cambiar el rodamiento eliminará el problema en forma permanente? Aún si se identifica una vibración excesiva y se toman medidas para identificarla más 10
pronto la próxima vez antes que la bomba falle, ¿será la forma de eliminar el problema? Si se castiga al mecánico por no haber alineado correctamente, ¿se evitará la falla recurrente? Como se puede ver, ninguna de esas soluciones que con frecuencia son implementadas, evitaría la recurrencia de la falla en la bomba. Sólo con una acción efectiva sobre el ¿Por qué? Se podrá evitar que ocurra la falla nuevamente. Si se reflexiona en los esfuerzos de RCA (Análisis de Causa Raíz), ¿Dónde califican?, ¿Se están deteniendo en el ¿Cómo? (al nivel del forense). O están llegando al ¿Por qué? (nivel del detective).
11
ANÁLISIS CAUSA RAÍZ: ÁRBOL DE EVENTOS El Análisis Causa Raíz (RCA) es un proceso diseñado para su uso en la investigación y la categorización de las causas de los acontecimientos relacionados con la seguridad, la salud, el medio ambiente, calidad, fiabilidad y que repercute en la producción. El término "evento" se utiliza para identificar de forma genérica los sucesos que producen o tienen el potencial para producir este tipo de consecuencias. En pocas palabras, la RCA es una herramienta diseñada para ayudar a identificar no sólo qué y cómo se produjo un evento, sino también por qué sucedió. Sólo 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 válvula A, en cambio, el operador cerró la válvula B. La investigación típica probablemente llegaría a la conclusión que un error del operador fue la causa. Esta es una descripción exacta de lo que ocurrió y cómo 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 válvula equivocada, es probable que se redacten las recomendaciones para volver a entrenar al operador en el procedimiento, recordar además a todos los operadores que deben estar alerta cuando procedan con la manipulación de las válvulas o destacar a todo el personal que la atención cuidadosa al trabajo se debe mantener en todo momento. Estas recomendaciones ayudan poco más 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 válvula del error, se podría preguntar: "¿Fue el procedimiento confuso? ¿Estaban las válvulas claramente identificadas? ¿Estaba el operador familiarizado con esta tarea en particular? " Las respuestas a estas y otras preguntas le ayudarán a determinar por qué ocurrió el error (falla) y lo que la organización puede hacer para prevenir la recurrencia en el caso del error de la válvula. Unas recomendaciones, por ejemplo, podrían incluir la modificación del procedimiento o la realización de los procedimientos de validación para asegurar que las referencias a las válvulas coincidan con las etiquetas de las válvulas que se encuentra en la fábrica. La identificación de las causas fundamentales es la clave para la prevención de recurrencias similares. Un beneficio adicional de un efectivo RCA es que, con el tiempo, las causas identificadas en la población de los sucesos pueden ser utilizadas para identificar las principales oportunidades de mejora. 12
Si, por ejemplo, un número significativo de los análisis apuntan a las deficiencias de contratación, los recursos pueden ser enfocados en el mejoramiento de este sistema de gestión. Las tendencias de las causas permite el desarrollo de mejoras y evaluación sistemática del impacto de los programas correctivos.
Definición Para la definición de la causa raíz, se basa en lo siguiente: 1. 2. 3. 4.
Las causas fundamentales son específicas de las causas subyacentes. Las causas fundamentales son las que razonablemente se puede identificar. Las causas fundamentales son las que gestión tiene el control de arreglar. Las causas fundamentales son aquellas en las que se pueden generar recomendaciones eficaces para la prevención de recurrencias.
Las causas fundamentales son producto de las causas subyacentes. El objetivo del investigador debe ser la identificación de causas subyacentes específicas. Cuanto más específico sea el investigador acerca del por qué se produjo un evento, más fácil será llegar a las recomendaciones que eviten recurrencia. Las causas fundamentales son las que razonablemente se puede identificar. La investigación de incidentes debe estar apoyada en la razón costo-beneficio. No es práctico mantener la mano de obra valiosa ocupada indefinidamente en la búsqueda de las causas de los sucesos. Un RCA estructurado ayuda a los analistas a sacar el máximo partido del tiempo que han invertido en la investigación. Las causas fundamentales son aquellas sobre las que la gestión 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 específicas como para permitir que la administración haga cambios que tengan efecto. La administración necesita saber exactamente por qué se produjo una falla antes de que puedan ser tomadas acciones para prevenir la recurrencia. También hay que identificar la causa raíz donde la gestión de la organización pueda influir. La identificación 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 administración. Las causas fundamentales son aquellas para las que se pueden generar recomendaciones efectivas. Las recomendaciones deben directamente abordar las causas fundamentales identificadas durante la investigación. Si los analistas llegan a recomendaciones vagas como "mejorar la adhesión a las políticas y procedimientos escritos," entonces probablemente no ha encontrado unas causas bastante básicas y específicas y necesitan gastar más esfuerzo en el proceso de análisis. 13
Cuatro pasos importantes La RCA es un proceso de cuatro etapas que implica lo siguiente: 1. 2. 3. 4.
Recopilación de datos. Gráficas del factor causal Identificación de la causa raíz. Generación de recomendación e implementación.
Paso 1 - recopilación de datos. El primer paso en el análisis consiste en reunir los datos. Sin la información completa y una comprensión de los eventos, los factores causales y las causas asociadas con el evento no pueden ser identificados. La mayoría del tiempo que se usa en el análisis de un evento es en la recolección de datos. Paso 2 - gráficas de los factores causales. Las gráficas del factor(es) causal proporcionan una estructura a los investigadores para organizar y analizar la información recopilada durante la investigación e identificar las vacios y deficiencias en el conocimiento a medidas que la investigación avanza. La carta del factor causal es simplemente un diagrama de secuencias con las pruebas lógicas que describen los acontecimientos que condujeron a un evento, además de las condiciones que rodean estos eventos (Ver Fig. 7). La preparación de la tabla de factor causal debe comenzar tan pronto como los investigadores comienzan a recopilar información acerca de la ocurrencia. Se inicia con un diagrama preliminar que se modifica a medida que más datos relevantes no están cubiertos. La tabla de factor causal debe conducir el proceso de recolección de datos mediante la identificación de las necesidades de datos. La recolección de datos continúa hasta que los investigadores están satisfechos con la minuciosidad de la tabla (y por tanto está satisfecho con la minuciosidad de la investigación). Cuando el suceso se ha trazado a totalidad, los investigadores están en una buena posición 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 habría evitado la ocurrencia o reducido su gravedad. En muchos de los análisis tradicionales, al factor causal más visible se le da toda la atención. Rara vez, sin embargo, hay un solo factor causal, los eventos son generalmente el resultado de una combinación de los contribuyentes. Cuando sólo uno de los factores causales evidentes es tratado, la lista de recomendaciones probablemente no será completa. En consecuencia, la aparición puede repetirse porque la organización no aprendió todo lo que podía del evento.
14
Quemador Quemador eléctrico en corto circuito
FC
Factor Causal
FC
Cacerola El arco calienta el fondo de aluminio de la cacerola
Cacerola
Julia
Aluminio se funde, forma un agujero en la cacerola ¿No había sido recargado originalmente? Extinguidor de fuego
Julia llega hasta la puerta de entrada Conclusión
María y Julia
Grasa arde da contacto con el quemador
Julia toca el timbre
Asumido El fuego genera humos
El fuego comienza en la cocina
FC
María
María Maria se encuentra con Julia 10minutos
María comienza a freir el pollo Hora: 17.00
Cacerola
María
María y Julia
María deja el pollo friéndose desatendido
¿Había sido usado previamente? Tarjeta de inspección
¿Qué fue lo que vio exactamente? María
María
María
¿Tiene goteras? Ubicación del extinguidor
Detector de humo da la alarma
María ve el fuego en la cocina
María El extinguidor no está recargado
Alrededor 17:10
María María corre hacia la cocina
¿Cuánto aceite usa? ¿Cuál es la cantidad de pollo? Pollo, aceite, cacerola
María María trata de usar el extinguidor de fuego
María El extinguidor no funciona cuando se necesitó FC
María María usa una cacerola de aluminio
María acciona el gatillo del extinguidor ¿El gatillo calza bien en el accionador? María
¿Sabe María accionar el extinguidor? María
Fig. 7: Gráfica de los factores causales 15
¿Sabía ella que eso estaba mal?¿Falta de práctica con el combate al fuego? María ¿Trató de hacer algo más? María
¿Qué estaba haciendo Julia en ese momento? María, Julia
María, cacerola El fuego fue grasa ardiendo
¿Cuánto fue la demora de los bomberos? Despachador
¿Estaba María tratando de hacer esto? María
María María arroja agua a la cocina FC
Cocina, María El fuego se esparce a través de la cocina
María, Bomberos María llama a los bomberos Hora?
Observación Los bomberos llegan
¿Usaron los bomberos las técnica correctas? Bomberos
Bomberos, obs. Los bomberos apagan el fuego
Hora?
La cocina destruida por el fuego
Hora?
Otras pérdidas por el humo y el agua
Fig. 7(cont.): Gráfica de los factores causales
Paso 3 - identificación de la causa raíz. Después que todos los factores causales han sido identificados, los investigadores comienzan identificación de causas raíz. Este paso implica el uso de un diagrama de decisión llamado el Mapa de Causa Raíz (vea Fig. 8) para determinar la causa o las razones de cada factor causal. El mapa estructura el proceso de razonamiento de los investigadores, ayudándoles a responder a las preguntas acerca de por qué determinados factores causales existen o se produjeron. La identificación 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
Problemas en el programa de confiabilidad
Problema en el diseño del equipo
Instalación / fabricación
Mal uso del equipo 2
Input/Output del diseño
Input del diseño MqA Output del diseño MqA
Diseño del programa de confiabilidad MqA
Datos del equipo
Datos de diseño del equipo MqA Datos de operación / historial de mantenimiento del equipo MqA
Estándares, políticas o controles administrativos (EPCA) MqA • Sin EPCA • No son suficientemente estrictos • Confusos, contradictorios o incompletos • Técnicamente erróneos • Responsabilidad/actividad para el ítem inadecuada definición • Planeamiento/programación o seguimiento de las actividades del trabajo MqA • Premios/incentivos MqA • Selección/contratación de empleados MqA
No usados • No disponible o inconveniente para obtener •Procedimiento difícil de usar • Uso no requerido pero está • Tarea sin procedimientos
Sin programa Programa MqA •Procedimientos /Análisis MqA •Asignación del tipo de mantenimiento inapropiado •Criterios de aceptación del riesgo MqA • Asignación de recursos MqA
Implementación del programa de confiabilidad MqA
Mantenimiento correctivo MqA • Resolución de problemas/acciones correctivas MqA • Implementación de reparaciones MqA Mantenimiento preventivo MqA • Frecuencias MqA • Alcances MqA • Implementación de actividades MqA Mantenimiento Predictivo MqA • Detección MqA • Monitoreo MqA • Resolución de problemas/acciones correctivas MqA • Implementación de actividades MqA
EPCA no son usados • La comunicación de los EPCA MqA • Cambiados recientemente • Aplicación MqA
Control del producto/ material • Manejo MqA • Almacenamiento MqA • Embalaje/despacho MqA • Sustitución del material no Revisión del riesgo su autorizada seguridad /posibilidad • Criterios de aceptación del • Revisión MqA o no ejecutada producto MqA • Las recomendaciones aún •Inspección del producto MqA no son implementadas • El criterio de aceptación MqA Control de identificación de • Revisión de los los problemas procedimientos MqA • Reportes de los problemas MqA • Análisis de los problemas MqA • Auditoría MqA • Acciones correctivas MqA • Acciones correctivas aún no implementadas
Engañoso/confuso • Formato confuso o MqA • Más de una acción por paso • No hay especio para marcar pero se necesita • Lista de chequeo inadecuada • Gráficas MqA •Instrucciones/requerimientos ambiguos o confusos • Datos/mal calculados/incompletos • Insuficientes o execivas referencias • Identificación o revisión de pasos MqA • Nivel de detalle MqA • Dificultad para identificar
Sistema de gestión administrativo
Procedimientos
Mantenimiento proactivo MqA • Especificación de los eventos MqA • Monitoreo MqA • Alcances MqA • Implementación de actividades MqA Búsqueda de fallas de Mantenimiento MqA • Frecuencia MqA • Alcances MqA • Resolución de problemas/acciones correctivas MqA • Implementación de reparos Rutinas de inspección de equipos MqA • Frecuencias MqA • Alcances MqA • Implementación de actividades MqA
Control del abastecimiento • Especificaciones de compra MqA • Control de cambio en las especificaciones de compra MqA • Requisitos de aceptación de materiales MqA • Inspección de materiales MqA • Selección de contratistas MqA
Control de documentos y configuración • Cambio no identificado • Verificación del diseño/ cambio de campos MqA •La documentación no contiene datos actualizados • Control oficial de documentos MqA
Interfaces/servicios • Requerimientos del cliente no identificados • Necesidades del cliente no focalizadas •Implementación MqA
Erróneo/incompleto • Errores tipográficos • Secuencia equivocada • Hechos erróneos/requerimientos no correctos • Revisión errada o procedimiento expirado • Inconsistencia entre requerimientos • Incompleta/situación no cubierta • Traslape o vacios entre procedimientos
Fig. 8: Mapa de Causa Raíz 17
MqA : Menos que Adecuado
Comenzar aquí para cada factor causal 1
Dificultad en el personal
Empleados de la compañia
Otras dificultades
Empleados contratistas
Fenómenos naturales
Sabotajes/ payasadas
Eventos externos
Otros
2 Ingeniería factor humano
Disposición lugares de trabajo • Controles/visualizadores MqA • Control/Integración visualizadores/ arreglos MqA • Ubicación de los controles/ visualizadores MqA • Disposiciones conflictantes • Ubicación de equipos MqA • Etiquetados de los equipos o ubicaciones MqA Carga de trabajo • Acción con requerimientos de excesivo control • Requerimientos no reales de monitoreo • Decisión requerida basada en el conocimiento • Excesivo cálculo requerido o manipulación de datos Ambiente de trabajo • Limpieza MqA • Herramientas MqA • Ropa protectora/equipos MqA • Condiciones ambientales MqA • Otros stress ambientales excesivos
Entrenamiento
Sin entrenamiento • Decisión 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 • Análisis trabajo/tarea MqA • Diseño del programa/ objetivos MqA • Contenidos de la lecciones MqA • Entrenamiento en el lugar de trabajo MqA • Pruebas de calificación MqA • Entrenamiento continuo MqA • Recursos para entrenamientos MqA • Entrenanmiento para situaciones no normales/ emergencias MqA
Supervisión inmediata
Preparación • Sin preparación • Plan de trabajo MqA • Instrucciones a los trabajadores MqA • Tutorías MqA • Programación MqA • Selección de trabajadores/ asignación MqA Supervisión durante el trabajo • Supervisión MqA • Ejecuciones inapropiadas no corregidas • Equipos de trabajo MqA
Comunicaciones
Eficiencia del personal
Sin comunicación o fuera de tiempo • Método inviable o MqA • Comunicación entre grupos de trabajo MqA • Comunicación entre grupos de trabajo y administración MqA • Comunicación con los contratistas MqA • Comunicación con los usuarios MqA
Detección de problemas MqA *Capacidad sensorial/ precepción MqA *Capacidades de razonamiento MqA *Capacidades motoras/físicas MqA *Actitud/atención MqA *Descanso/dormir MqA (fatiga) *Problemas personales/ medicación
Comunicación sin entender • Terminología estandarizada no usada • Verificación / validación no usada • Mensajes largos Instrucciones erradas Rotación del trabajo MqA • Comunicación con los grupos de trabajo (turnos) MqA • Comunicación entre grupos MqA
Sistema sin tolerancia • Errores no detectables • Errores no corregibles
Fig. 8 (cont.): Mapa de Causa Raíz
Paso 4 - recomendaciones generales e implementación. El siguiente paso es la generación de recomendaciones. Siguiendo la identificación de las causas raíz de un factor causal en particular, se generan las recomendaciones factibles para la prevención de su recurrencia. El analista de la causa raíz a menudo no es el responsable de la aplicación de las recomendaciones generadas por el análisis. Sin embargo, si las recomendaciones no son implementadas, el esfuerzo puesto en la realización del análisis se desperdicia. Además, los acontecimientos que
18
desencadenaron el análisis se debería esperar que se repitan. Las organizaciones necesitan asegurarse que las recomendaciones sean seguidas hasta su finalización.
Presentación de los resultados Las tablas de resumen de la causas raíz (ver Fig. 9) puede organizar la información recopilada durante el análisis de datos, la identificación de causas raíz y la generación de recomendaciones. Cada columna representa un aspecto importante del proceso de RCA. •
• •
En la primera columna, se presenta una descripción general de los factores causales junto con la información 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 través de la Hoja de Causa Raíz asociada con el factor causal. La tercera columna presenta las recomendaciones para abordar cada una de las causas raíces.
El uso de este formato de tres columnas ayuda al investigador para asegurarse de las causas raìz y las recomendaciones se han desarrollado para cada factor causal. El resultado final de una investigación RCA es por lo general un informe de investigación. El formato del informe es por lo general bien definido por los documentos administrativos que rigen el sistema de información particular, pero el cuadro y tablas completas de los factores causales proporcionan la mayor parte de la información requerida por la mayoría de los sistemas de información. Tabla resumen de las Causas Raíz Descripción del evento: la cocina es destruida por el fuego y dañada por el humo y el agua. Factor causal Nº 1 Ruta en el mapa Causa Raíz Recomendaciones Descripción : Maria deja • Dificultad personal. • Implementar una política para que friendo el pollo sin •Sistema el aceite caliente nunca se deje de atención administrativo/administración. atender cuando esté en el • Estándares, políticas o control quemador. administrativo MqA . • Determinar si se han desarrollado • Sin control. políticas para otros tipos de peligros en con el objetivo de no dejar a ellos desatendido. • Modificar el procedimiento de evaluación del riesgo o el procedimiento de desarrollo del proceso para focalizar la atención del personal durante la operación. Factor causal Nº 2 Ruta en el mapa Causa Raíz Recomendaciones Descripción: el • Dificultad en el equipo. • Reemplace todos los quemadores quemador eléctrico falla • Problema de confiabilidad del equipo. de la cocina. (cortocircuito). • Diseño del programa de confiabilidad • Desarrolle una estrategia de del equipo MqA. mantenimiento preventivo para 19
• No hay programa.
Factor causal Nº 3 Descripción: el extinguidor del fuego no operó cuando María trató de usarlo. .
Ruta en el mapa Causa Raíz • Dificultad en el equipo. • Problemas con la confiabilidad del equipo. • Mantenimiento proactivo del equipo MqA. • Implementación de actividades MqA.
• Dificultad en el equipo. • Problemas con la confiabilidad del equipo. • Sistema administrativo /gestión. • Identificación de problemas y control MqA.
Factor causal Nº 4 Descripción: María arroja agua en el fuego.
Ruta en el mapa Causa Raíz • Dificultad del personal. • Empleados de la compañía. • Entrenamiento. • Entrenamiento MqA. • Evento anormal/entrenamiento de emergencias MqA.
reemplazar periódicamente los quemadores. • Considerar métodos alternativos para la preparación 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 protección del fuego conjuntamente con las instrucciones de mantenimiento del gatillo. • Agregar este extinguidor a la lista de auditoría. • Verificar que todos los extinguidores de la casa queden en la lista de auditoría. • 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 práctico en el uso de extinguidores. Las clases en sala parecen ser insuficientemente adecuadas para adquirir las habilidades. • Revisar otras actividades que requieren destrezas asegurándose 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 análisis de causal y recomendaciones
20
El RCA asume que los sistemas y los acontecimientos están relacionados entre sí. Una acción en un área activa una acción en otra, y otra, y así sucesivamente. Al trazar de nuevo estas acciones, se puede descubrir donde empezó el problema y cómo se convirtió en el síntoma que está enfrentando. Por lo general, se puede encontrar tres tipos básicos de las causas: 1. Causas físicas – 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 físicas (por ejemplo, uno que no llenó con líquido de frenos, lo que llevó a los frenos no funcionar). 3. Causas organizacionales - un sistema, proceso, o la política que usa la organización para tomar decisiones o hacer su trabajo es defectuoso (por ejemplo, ninguna persona fue responsable de mantenimiento de vehículos, y todo el mundo asume que alguien había llenado el líquido de frenos). En el Análisis de Causa Raíz se ve en los tres tipos de causas. Se trata de investigar los patrones de efectos negativos, la búsqueda de fallas ocultas en el sistema, y el descubrimiento de las acciones específicas que han contribuido al problema. A menudo, esto significa que RCA revela más que una causa fundamental.
21
EL MÉTODO KEPNER- TREGOE O MATRIZ DEL PERFIL COMPETITIVO Es una técnica estructurada para recopilar, priorizar y evaluar información. El objetivo de la técnica no es el de encontrar una solución perfecta sino el de identificar la mejor alternativa posible. La decisión para seleccionar dicha alternativa, se basa en conseguir un objetivo determinado con mínimas consecuencias negativas. La técnica parte del supuesto que indica que todos los problemas tienen la misma estructura, lo que invita a racionalizar su proceso de solución. La técnica presenta cuatro patrones básicos de pensamiento: 1.
Análisis de Situaciones ¿Qué está ocurriendo? Permite evaluar, aclarar, seleccionar e imponer orden en una situación confusa. Análisis de Problemas ¿Por qué ocurrió esto? Permite relacionar un suceso con su resultado, una causa con su efecto. Análisis de Decisiones ¿Qué curso de acción hay que tomar? Permite hacer decisiones razonadas. Análisis de Problemas Potenciales ¿Qué nos espera más adelante? Permite mirar en dirección al futuro que nos depara.
2. 3. 4.
La explicación de la técnica que se presenta, (KT por sus autores), expone cómo realizar el segundo patrón de la solución de problemas; el Análisis de Problemas. Para los autores, un problema (falla) es algún tipo de desviación de una norma, que alguien considera importante y necesario restablecer. Es algo que ha salido mal inexplicablemente y su detección se inicia con una noción 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 (¿Dónde?) Su ubicación en el tiempo (¿Cuándo?) La magnitud o tamaño (¿Cuánto?)
Contrastándose cada una de ellas con “LO QUE ES” y “LO QUE NO ES” o con lo que “PUDIERA SER” pero “NO ES”. La ventaja más importante de la técnica es la sistematización del análisis de los problemas, que de acuerdo a lo que indican los autores, normalmente se analizan los problemas por intuición o sentido común pero no de forma estructurada. La desventaja de esta técnica radica en la necesidad del conocimiento profundo del sistema objeto de estudio.
22
La técnica es recomendable para identificar, describir y analizar problemas operativos de tipo técnico, proporcionando un medio sistemático para extraer la información esencial de una situación problemática y hacer a un lado la información irrelevante o confusa.
Definición del problema El análisis del problema comienza con la definición del problema. El equipo que está a cargo de la solución del problema no puede pasar por alto este paso crítico. La incapacidad para comprender exactamente lo que es el problema a menudo resulta en pérdida de tiempo precioso. Muchos que atacan los problemas con inmadurez consideran este paso como un esfuerzo inútil, ya que saben lo que están haciendo - y esto es el grave error cometido por muchos. Nociones preconcebidas a menudo resultan en una duración de corte final mayor e incluso la extensión en el corte debido a un pobre juicio. Ya que la gestión de problemas es de por sí un ejercicio de equipo, es importante tener una comprensión del problema en el grupo. Considere los siguientes ejemplos. Una pobre definición del problema podría aparecer como sigue: "El servidor se cayó." Una mejor definición del problema debe incluir más información. Un buen modelo para formalizar las declaraciones de todo tipo es método GQM (Goal-Question-Metric). Da como resultado una declaración con un objetivo claro, un propósito, un enfoque, un medio ambiente, y un punto de vista. Esto da lugar a una declaración inequívoca y fácil de entender. Una definición del problema podría ser aclarado: "El sistema de correo electrónico falló después de que el ingeniero de soporte del tercer turno aplicó pegamento caliente XYZ en el servidor de intercambio 123". Cuando se está desarrollando una definición del problema se recomienda utilizar la técnica de "5 porqués" para llegar al punto en que no hay más explicación para el problema. Utilizando 5 porqués con KT sólo acelera el proceso.
Describir el problema Con una definición 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 continuación describe la hoja de trabajo básico que se utiliza en el proceso. ES QUE
Falla del sistema
DONDE
Ubicación de la falla
CUANDO
Momento de la falla
EXTENSIÓN
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, dónde se produce, cuando se produjo, y la extensión en que se produjo. La columna ES proporciona espacio para describir en detalle sobre el problema - lo que el problema ES. La columna PODRÍA SER, PERO NO ES ofrece un espacio para listar detalles relacionados, pero excluidos - lo que el problema PODRÍA SER PERO NO ES. Estas dos columnas ayudan en la eliminación 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 PODRÍA SER PERO NO ES. Estas diferencias forman la base de la solución de problemas. La última columna proporciona espacio para enumerar todos los cambios realizados que podrían explicar las diferencias.
Determinar las Causas posibles Cualquiera que haya pasado tiempo en la solución 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 análisis de problemas puede ayudar aquí por la descripción de lo que el problema es y lo que el problema podría ser, pero no lo es. Por ejemplo: Problema: ". "El sistema de correo electrónico falló después de que el ingeniero de soporte del tercer turno aplicó pegamento caliente XYZ en el servidor de intercambio 123". ES
PODRIA SER PERO NO ES Otros servidores de intercambio usaron pegamento caliente XYZ
DIFERENCIAS
QUE
Servidor de intercambio 123 falló después de la aplicación del pegamento caliente XYZ
DONDE
La sala de producción del tercer piso sin el soporte de un vendedor/contratista
En cualquier lugar Normalmente con soporte de hecho por un vendedor/contratista vendedor
CUANDO
Última noche, 1:35am
Cualquier hora o ubicación
EXTENSIÓN
Todos los servidores del 3er piso
Otros servidores
CAMBIOS
Diferente staff (3er turno) aplicó este pegamento
Vendedor entrega un nuevo procedimiento Nuevo procedimiento, primera vez que lo aplica el tercer turno
Sin anotación
Historiales (y mejores prácticas) dice que la causa raíz 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 más 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 raíz de este problema ¿explica el problema ES y cuál problema PODRÍA SER, PERO NO LO ES?" Si esta respuesta potencial es la causa raíz, entonces la solución potencial tiene que "mapear hacia" o "encajar en" todos los aspectos de la hoja de trabajo de análisis de problemas. Utilice una hoja de trabajo como la mostrada a continuación para ayudar a organizar su pensamiento en torno a las posibles soluciones. Causa Raíz Potencial: El servidor de intercambio 123 tiene algo de malo en él Procedimiento incorrecto Error técnico
Verdad si:
¿Causa raíz 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 raíz posibles en contra de la descripción del problema. Eliminar las posibles soluciones que no pueden explicar la situación, y centrarse en los temas restantes. Antes de hacer cambios, verificar que la respuesta propuesta podría ser la causa raíz. Falla en la verificación de la verdadera causa invalida todo el ejercicio y no es mejor que adivinar. Después de verificar la verdadera causa, puede proponer las medidas necesarias requeridas para reparar el problema. Es importante aquí, así que pensar en cómo prevenir los problemas similares se repitan en el futuro. El administrador del problema debe considerar cómo la cuestión se planteó en primer lugar mediante unas preguntas: ¿Dónde más podría aparecer este problema? ¿Hay otros casos como este problema en el pasado? ¿Están todos los procedimientos necesarios para cambiar? El objetivo es tratar de eliminar las repeticiones futuras del problema. 25
5 PORQUÉS PARA RESOLVER PROBLEMAS Inventado en 1930 por Kiichiro Toyoda y se hizo popular en la década de 1970 por el Sistema de Producción Toyota. La estrategia de 5 porqués implica observar cualquier problema y preguntar: "¿Por qué?" y "¿Qué causó este problema?" Six Sigma, un sistema de gestión de calidad (SGC), utiliza "5 porqués" en la fase de análisis de la metodología Six Sigma: Definir, Medir, Analizar, Mejorar, Controlar (DMAIC). La idea es simple. Al plantear la pregunta "¿Por qué?" se puede separar los síntomas de las causas de un problema. Esto es fundamental ya que los síntomas suelen enmascarar las causas de los problemas. Teniendo una efectiva clasificación de incidentes, basar las acciones en los síntomas es la peor práctica posible. 5 Porqués ofrece algunas ventajas reales en cualquier nivel de madurez: Simplicidad. Es fácil de usar y no requiere de las matemáticas o herramientas avanzadas. Eficacia. Sin duda ayuda a separar rápidamente los síntomas de las causas e identificar la causa raíz 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 técnicas de resolución de problemas. Atractivo. Por su propia naturaleza, fomenta y produce el trabajo en equipo y equipos dentro y fuera de la organización. De bajo costo. Se trata de una guía, 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 raíz del problema. Es probable que encuentre lo que le piden más o menos en 5 "por qué" en la práctica.
Cómo utilizar el 5 por qué 1. Reunir a un equipo de gente experta en el elemento de la configuración que está fallando. Incluir especialistas de áreas relacionadas y usuarios del sistema en análisis si fuese necesario. 2. En un tablero de presentación escribir una descripción de lo que sabe sobre el problema. Trate de documentar el problema y describir lo más completo posible. Perfeccionar la definición con el equipo. Llegar a un acuerdo sobre la definición del problema en cuestión. 3. Un miembro del equipo pregunta "¿Por qué?" el problema descrito puede ocurrir, y escribe la respuesta por debajo de la descripción 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, asegúrese de que el equipo está de acuerdo e intentar una resolución 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 raíz propuestas (respuesta al "por qué") en la observación directa y no en la especulación o la deducción. Si no se puede ver u observar el "por qué" de primera mano, entonces sólo se está adivinando. Uno de los problemas comunes de quienes utilizan los 5 porqués es caer en conjeturas en su informe. Es evidente que la adivinación es contraproducente. Gente experimentada en la técnica de exigen la precisión preguntando los 5 27
porqués de nuevo para cada propuesta para la causa raíz - sólo que esta vez preguntando por qué el equipo piensa que la propuesta de la causa raíz es la correcta. Para validar las potenciales causas raíz que están bajo su control, puede aplicar las validaciones siguientes a sus respuestas o causas raíz. Haga las siguientes preguntas para cada posible causa raíz identificada a todos los niveles de los 5 porqués: ¿Hay alguna prueba (algo que se puede medir u observar) para apoyar esta determinación de causa raíz? ¿Hay alguna historia o el conocimiento que indique que la posible causa raíz en la actualidad podría producir el problema? ¿Hay algo "por debajo" de la posible causa raíz que podría ser una causa más probable? ¿Hay algo que esta posible causa raíz 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 descripción del problema y las preguntas y respuestas, se producirá una indicación mucho más 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 resolución, la comprensión de la cuestión o el problema es mucho mayor, a menudo ofrece caminos para un diagnóstico más profundo. El uso de Ishikawa (causa-efecto o "espina de pez") hace que los diagramas de 5 porqués sean especialmente efectivos.
28
DIAGRAMA DE ISHIKAWA PARA LA CAPTURA DE LAS SOLUCIONES El diagrama de Ishikawa es un método gráfico para el análisis de causa raíz. Documentado por primera vez por Kaoru Ishikawa, se utiliza hoy en día como una piedra angular de la mejora continua del servicio. Debido a su forma, también es conocido como el diagrama de espina de pescado. Otro nombre para esta técnica es de diagramación causa y efecto. Los diagramas de Ishikawa son aparentemente simples, pero no hay que dejar que eso detenga un análisis. Usando esta técnica se puede ver todas las posibles causas de un resultado (un problema, por ejemplo), y descubrir la causa raíz de fallas. La diagramación Ishikawa no requiere inversión en software o herramientas. Se trata de un ejercicio de grupo. Siguiendo lo que se describe cómo, por qué y cuándo para crear y utilizar diagramas Ishikawa de causa y efecto.
Análisis de Causa Raíz Ishikawa, "Espina de pesado", o diagrama de causa y efecto se refieren a lo mismo: una representación gráfica de las entradas (causas y razones) y una salida (el problema o evento). Un profesional guía a un grupo en la organización de causas de acuerdo a su importancia. Esto se traduce en un gráfico que muestra la relación entre las causas, razones y el problema objeto de estudio. Este gráfico ayuda a identificar las causas raíces, 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 información. Tan simple como suena, a veces solamente obtener todas las ideas de un grupo de personas organizadas en un diagrama acelera drásticamente el diagnóstico de problemas y resoluciones. Usar esta técnica siempre que se deba: Determinar la causa raíz 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 analogía de los peces, la "cabeza" debe contener una descripción 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 diagramación Ishikawa es más útil como una herramienta de grupo. No hay límite a la complejidad de los diagramas. El ejemplo es sencillo, pero el suyo puede ser muy complejo. Normalmente, más de 4 o 5 niveles son demasiado complejos para producir cualquier causa visible. Cuando el diagrama está completo, el equipo cuenta con un documento gráfico que muestra organizada todas las posibles causas del problema descrito. A continuación, el grupo discute la causa raíz más probable y propone un plan de acción.
Creación de una Diagrama Ishikawa "Espina de pescado" La creación de un diagrama de Ishikawa sigue un proceso simple: Reunir a un grupo de personas familiarizadas con el problema en cuestión. 30
1. Dibujar una línea 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 descripción del problema que sea claro y conciso. Escribir la descripción del problema en la caja de problema o cabeza de pescado del diagrama. En el ejemplo, el problema es "incertidumbre operativa", refiriéndose 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" iníciales. Si el grupo no se ponen de acuerdo sobre las causas principales, sólo 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 técnicas 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 razón posible, y si no puedo pensar en una puede pasar. Asegúrese de que cada causa es clara, concisa y medible. b. Dibujar la causa en una línea conectada a la "costilla" adecuada y la etiquétela con la causa. Si la causa propuesta es un factor en una causa existente (costilla), a continuación, dibuje otra espina dorsal de la costilla, añadir otra costilla, y la etiqueta de la misma. c. Volver atrás y repetir hasta que todo el mundo dice, "pasa" y no hay más causas posibles que las costillas ya existentes y no hay costillas nuevas que añadir. 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 raíz del problema. La forma más rápida y más fácil de interpretar los resultados de Ishikawa es el diagrama para seleccionar y clasificar las 5 mejores causas. Deje que el grupo decida cómo clasificar las causas. Los 5 porqués son también útiles para determinar la más probable causa raíz cuando el esquema se completa también. Haga un círculo de las causas seleccionadas. Haga que los miembros apropiados del grupo investiguen estas causas utilizando otras técnicas de solución de problemas. Repita según sea necesario.
El dominio de Causa y Efecto Profesionales con experiencia limitan el número de "costillas" (causas) para el enfoque del grupo. Algunos sugieren que no permitan más de 3 a 5 costillas. Otras técnicas 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 síntomas del problema. Use la tormenta de ideas para determinar exactamente lo que las costillas debe ser – la técnica del "5 porqués" puede ayudar aquí. Comprobar que las causas en el diagrama no son en sí otros problemas. Combinar costillas vacías (o casi vacías), con otras costillas más apropiadas. Divida aquellas costillas densas en costillas adicionales, según convenga. Realice copias de los resultados y darlas a conocer a los demás para obtener mayor conocimiento y participación del personal. El diagrama de Ishikawa es una potente herramienta para aprovechar la combinación de conocimientos y experiencia de un grupo de personas. Esto permite que el grupo focalice la discusión sobre el por qué se producen problemas sin la distracción de los síntomas.
32
HAZARD AND OPERABILITY (HAZOP) Descripción El HAZOP es una técnica de identificación de riesgos inductiva basada en la premisa de que los riesgos, los accidentes o los problemas de operatividad, se producen como consecuencia de una desviación de las variables de proceso con respecto a los parámetros normales de operación en un sistema dado y en una etapa determinada. Por tanto, ya se aplique en la etapa de diseño, como en la etapa de operación, la sistemática consiste en evaluar, en todas las líneas y en todos los sistemas las consecuencias de posibles desviaciones en todas las unidades de proceso, tanto si es continuo como discontinuo. La técnica consiste en analizar sistemáticamente las causas y las consecuencias de unas desviaciones de las variables de proceso, planteadas a través de unas "palabras guía". La realización de un análisis HAZOP consta de las etapas que se describen a continuación:
Etapas Definición del área de estudio: Consiste en delimitar las áreas a las cuales se aplica la técnica. En una determinada instalación de proceso, considerada como el área objeto de estudio, se definirán para mayor comodidad una serie de subsistemas o líneas de proceso que corresponden a entidades funcionales propias: línea de carga a un depósito, separación de disolventes, reactores, etc. Definición de los nudos: En cada uno de estos subsistemas o líneas se deberán identificar una serie de nudos o puntos claramente localizados en el proceso. Por ejemplo, tubería de alimentación de una materia prima a un reactor, impulsión de una bomba, depósito de almacenamiento, etc. Cada nudo deberá ser identificado y numerado correlativamente dentro de cada subsistema y en el sentido del proceso para mejor comprensión y comodidad. La técnica HAZOP se aplica a cada uno de estos puntos. Cada nudo vendrá caracterizado por variables de proceso: presión, temperatura, caudal, nivel, composición, viscosidad, etc. La facilidad de utilización de esta técnica requiere reflejar en esquemas simplificados de diagramas de flujo todos los subsistemas considerados y su posición exacta. El documento que actúa como soporte principal del método es el diagrama de flujo de proceso, o de tuberías e instrumentos, P&ID. Aplicación de las palabras guía: Las "palabras guía" 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 parámetros específicos (presión, caudal, temperatura, etc.). La tabla siguiente presenta algunas palabras guía y su significado.
33
Palabra guía NO
MÁS
Significado Ausencia de la variable a la cual se aplica
Ejemplo de desviación No hay flujo en una línea
Aumento cuantitativo de una variable
Más flujo (más caudal) Más temperatura
MENOS
INVERSO
ADEMÁS DE
PARTE DE
DIFERENTE DE
Disminución cuantitativa de una variable
Analiza la inversión en el sentido de la variable. Se obtiene el efecto contrario al que se pretende Aumento cualitativo. Se obtiene algo más que las intenciones del diseño
Disminución cualitativa. Parte de lo que debería ocurrir sucede según lo previsto Actividades distintas respecto a la operación normal
Menos caudal
Menos temperatura Flujo inverso
Impurezas o una fase extraordinaria
Disminución de la composición en una mezcla Cualquier actividad
Ejemplo de causas originadoras Bloqueo; fallo de bombeo; válvula cerrada o atascada; fuga; válvula abierta; fallo de control Presión de descarga reducida; succión presurizada; controlador saturado; fuga; lectura errónea de instrumentos Fuegos exteriores; bloqueo; puntos calientes; explosión en reactor; reacción descontrolada Fallo de bombeo; fuga; bloqueo parcial; sedimentos en línea; falta de carga; bloqueo de válvulas Pérdidas de calor; vaporización; venteo bloqueado; fallo de sellado Fallo de bomba; sifón hacia atrás; inversión de bombeo; válvula antirretorno que falla o está insertada en la tubería de forma incorrecta Entrada de contaminantes del exterior como aire, agua o aceites; productos de corrosión; fallo de aislamiento; presencia de materiales por fugas interiores; fallos de la puesta en marcha Concentración demasiado baja en la mezcla; reacciones adicionales; cambio en la alimentación Puesta en marcha y parada; pruebas e inspecciones; muestreo; mantenimiento; activación del catalizador; eliminación de tapones; corrosión; fallo de energía; emisiones indeseadas, etc.
Definición de las desviaciones a estudiar: Para cada nudo se plantea de forma sistemática todas las desviaciones que implican la aplicación de cada palabra guía a una determinada variable o actividad. Para realizar un análisis exhaustivo, se deben aplicar todas las combinaciones posibles entre palabra guía y variable de proceso, descartándose durante la sesión 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 aplicación de palabras guía, las desviaciones que originan y sus causas posibles. Sesiones HAZOP: Las sesiones HAZOP tienen como objetivo la realización sistemática del proceso descrito anteriormente, analizando las desviaciones en todas las líneas o nudos seleccionados a partir de las palabras guía 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 información se presenta en forma de tabla que sistematiza la entrada de datos y el análisis posterior. A continuación se presenta el formato de recogida del HAZOP aplicado a un proceso continuo. Planta: Sistema: Nudo Palabra guía
Desviación de la variable
Posibles causas
Consecuencias
Respuesta
Señalización
Acciones a tomar
Comentarios
El significado del contenido de cada una de las columnas es el siguiente: Columna Posibles causas Consecuencias Respuesta del sistema
Acciones a tomar Comentarios
Contenido Describe numerándolas las distintas causas que pueden conducir a la desviación Para cada una de las causas planteadas, se indican con la consiguiente correspondencia en la numeración las consecuencias asociadas Se indicará en este caso: 1. Los mecanismos de detección de la desviación planteada según causas o consecuencias: por ejemplo, alarmas 2. Los automatismos capaces de responder a la desviación planteada según las causas: por ejemplo, lazo de control Propuesta preliminar de modificaciones a la instalación en vista de la gravedad de la consecuencia identificada o a una desprotección flagrante de la instalación Observaciones que complementan o apoyan algunos de los elementos reflejados en las columnas anteriores
En el caso de procesos discontinuos, el método HAZOP sufre alguna modificación, tanto en su análisis como en la presentación de los datos finales. Las sesiones HAZOP se llevan a cabo por un equipo de trabajo multidisciplinar cuya composición se describe con detalle más abajo en el apartado de recursos necesarios. Como resumen del procedimiento, se presenta el esquema siguiente aplicado a procesos continuos
35
Inicio Análisis Funcional de Operatividad (AFO): 1. Elección de un equipo. 2. Definir las funciones deseadas del equipo incluidas las conducciones y aparatos o servicios auxiliares asociadas al mismo. 3. Elección de una línea de conducción. 4. Definir la función deseada de esta línea de conducción. 5. Utilización de la primera palabra – guía. 6. Formulación del significado de la posible desviación. 7. Determinar las posibles causas. 8. Examinar posibles consecuencias. 9. Determinar la peligrosidad, considerando la posibilidad de tales acontecimientos. 10. Proponer medidas necesarias. 11. Repetición de los puntos 6 – 10 para todas las posibles desviaciones que fueron formuladas con ayuda de la primera palabra guía. 12. Repetición de los puntos 5 – 11 para todas las palabras – guías. 13. Señalizar la parte analizada en los diagramas de trabajo (flowsheets). 14. Repetición de los puntos 3 – 13 para cada línea diferente. 15. Elección de un servicio auxiliar (por ejemplo sistema de calefacción). 16. Definir la función deseada de este servicio auxiliar. 17. Repetición de los puntos 5 -12 para tal servicio auxiliar. 18. Señalizar la parte analizada en los diagramas de trabajo. 19. Repetición de los puntos 15 – 18 para todos los servicios auxiliares. 20. Definir las intenciones específicas del equipo o unidad. 21. Repetir 5 – 12. 22. Señalizar que el análisis del equipo o unidad está completo. 23. Repetir 1 – 22 para los diferentes para los diferentes equipos del diagrama de procesos. 24. Señalizar en el flowsheet de la instalación que la unidad de procesos ha sido analizada. 25. Repetir 1 – 24 para todas de procesos de la instalación. Final Análisis Funcional de Operatividad
Informe final: El informe final consta de los siguientes documentos: Esquemas simplificados con la situación y numeración de los nudos de cada subsistema. Formatos de recogida de las sesiones con indicación de las fechas de realización y composición del equipo de trabajo.
36
Análisis de los resultados obtenidos. Se puede llevar a cabo una clasificación cualitativa de las consecuencias identificadas. Listado de las medidas a tomar. Constituye una lista preliminar que debería ser debidamente estudiada en función de otros criterios (coste, otras soluciones técnicas, consecuencias en la instalación, etc.) y cuando se disponga de más elementos de decisión. Lista de los sucesos iniciadores identificados.
Ámbito de aplicación La mayor utilidad del método se realiza en instalaciones de proceso de relativa complejidad o en áreas de almacenamiento con equipos de regulación o diversidad de tipos de trasiego. Es uno de los métodos más 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 diseño, puede ayudar en gran medida a resolver problemas no detectados inicialmente. Además, las modificaciones que puedan surgir como consecuencia del estudio pueden ser más fácilmente incorporadas al diseño. Por otra parte, también puede aplicarse en la fase de operación y en particular ante posibles modificaciones.
Recursos necesarios El grupo de trabajo estable estará constituido por un mínimo de cuatro personas y por un máximo 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 técnico 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 ingeniería de proceso en general.
Funciones del coordinador/director del grupo Recoger la información escrita necesaria de apoyo. Planificar el estudio. Organizar las sesiones de trabajo. Dirigir los debates, procurando que nadie quede en un segundo término o supeditado a opiniones de otros. Cuidar que se aplica correctamente la metodología, dentro de los objetivos establecidos, evitando la tendencia innata de proponer soluciones aparentes a problemas sin haberlos analizado suficientemente. Recoger los resultados para su presentación. Efectuar el seguimiento de aquellas cuestiones surgidas del análisis 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 diseño y explotación de la planta.
Ejemplo El ejemplo se aplica a una parte de una instalación en una planta de dimerización de olefina. El diagrama de flujo sobre el que se aplica el AFO consiste en el suministro de hidrocarburo a un depósito de almacenamiento. Forma parte de un subsistema mayor que consiste en la alimentación del hidrocarburo del depósito regulador hasta un reactor de dimerización donde se produce la olefina (ver Fig. 12). LIC
Nitrógeno (Inertizante)
RF
I-5
PIC TR
AN Conducción de 500 m
Depósito regulador / dosificador 25 m3 20ªC 15 psig Colector de agua FO A drenaje 20ªC 35 psig
Hidrocarburos de tanque intermedio PG I-2
PG
Drenaje y purgado con N2
I-3
Drenaje y purgado con N2
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 análisis HAZOP de una sesión aplicado a la palabra guía NO y a la perturbación NO FLUJO, sería como sigue: 38
ANÁLISIS DE OPERABILIDAD EN PLANTA DE DIMERIZACIÓN DE OLEFINA Línea comprendida entre alimentación desde tanque intermedio a depósito regulador Palabra Desviación Causas posibles Consecuencias Medidas a tomar guía NO NO FLUJO 1. Inexistencia de Paralización del a) Asegurar buena hidrocarburo en tanque proceso de reacción comunicación con el intermedio esperado. operario del tanque intermedio Formación de polímero b) Instalar alarma de nivel en el intercambiador de mínimo LIC en depósito calor regulador 2. Bomba J1 falla (fallo de Como apartado 1 Cubierto por b) motor, circuito de maniobra, etc.) 3. Conducción bloqueada, Como apartado 1 Cubierto por b) válvula cerrada por error o LCV falla cerrando paso al Bomba J1 sobrecargada c) Instalar sistema de fluido desconexión automática para protección de bombas d) Verificar el diseño de los filtros de las bombas J1 4. Rotura de conducción Como apartado 1 Cubierto por b) Hidrocarburo e) Implantar inspección descargado en área regular de la conducción adyacente a vía pública mediante rondas periódicas
Posteriormente se aplicarían otras palabras guía a otras variables del sistema.
Matriz de evaluación de los riesgos Definiciones previas: 1. Análisis 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 evalúan sus efectos y se definen las acciones a seguir frente a los mismos, con el fin de disponer de una actuación planificada con vista a minimizarlos. 2. Riesgo: es un evento probable cuya ocurrencia produce un daño a las personas, bienes físicos, procesos y/o medio ambiente. 3. Consecuencias (C): mide el nivel o grado de severidad que pueden revestir los daños a las personas, a los bienes y perjuicios por paralización de la producción, como consecuencia de un incidente. 39
4. Exposición (E): el número de veces que el operador(es) se expone a un evento en un período determinado. Una escala clasifica en forma cualitativa el número 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 relación con la frecuencia de ocurrencia del evento no deseado y se expresa por medio de una escala de categorías que corresponden al nivel de frecuencias de ocurrencias. 6. Magnitud del Riesgo (MR): es una medición que permite evaluar y jerarquizar el riesgo en forma cuantitativa, en función de su Probabilidad (P), Exposición (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 evaluación 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) Clasificación LEVE SERIA GRAVE
Categoría 1 2 4
Consecuencias Lesión(es) leve(s) no incapacitante(s) Lesión(es) incapacitante(s) temporal(es) y permanente(s) parcial(es) Perdida de la vida de un operador o incapacidad permanente total
b) Estimación de exposición (E) Número de veces exposición del operador al riesgo Anual - Semestral Trimestral – Mensual Semanal 1 2 3
Diaria 4
c) Estimación de la probabilidad (P) Categoría 1 2 3 4
Definición Casi improbable que ocurra Puede ocurrir alguna vez Ocurre regularmente Ocurre la mayor parte de las veces 40
d) Evaluación 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 diseño de los proyectos y de control durante su operación, 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 inversión 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 físicos y medio ambiente: cada empresa que hace el análisis define los márgenes de pérdidas. a) Clasificación de las consecuencias (C) Categoría 1 2 3 4 5
Pérdidas 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 más
En el caso que se esté aplicando en referencia al medio ambiente, las consecuencias se pueden orientar como sigue:
Categoría 1 2 3 4 5
Definición Insignificante – mínimo impacto Baja severidad – acción local Mediana severidad – apoyo de otras áreas Severa – compromete a toda la organización Muy severa – se afecta la comunidad
b) Estimación de la probabilidad (P): dice relación con la probabilidad de ocurrencia del evento no deseado, que tiene el potencial de producir daños a los bienes físicos y al medio ambiente, 41
Categoría 6
Definición Se espera que ocurra al menos una vez al año. Ocurre la mayor parte de las veces. Se espera ocurra al menos una vez cada 3 años. Ocurre regularmente. Se espera ocurra al menos una vez cada 10 añosOcurre algunas veces. Se espera ocurra al menos una vez cada 15 años. Es raro que ocurra. Se espera que ocurra no más de 1 vez en 25 años. Ha ocurrido Se espera que ocurra no más de 1 vez en 90 años. Casi improbable que ocurra – se tiene conocimiento que ha ocurrido.
5 4 3 2 1
c) Evaluación de la magnitud del riesgo (MR): la magnitud permite clasificar los riesgos para priorizar las acciones de control en las etapas de diseño de los proyectos. Magnitud del riesgo MR = C * P
Para visualizar la clasificación se construye la matriz de gravedad del riesgo, utilizando la categoría de la consecuencia y la probabilidad de ocurrencia del evento, como dimensiones de la matriz.
Probabilidad
Matriz Gravedad Riesgo 6
6
12
18
24
30
5
5
10
15
20
25
4
4
8
12
16
20
3
3
6
9
12
15
2
2
4
6
8
10
1
1
2
3
4
5
1
2
3 Consecuencias
4
5
De acuerdo a la magnitud del riesgo se definen tres niveles de criticidad: grave, serio y leve, según los rangos que se muestran a continuación: 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 físicos y al medio ambiente del proyecto de inversión en análisis. Medidas de control: el análisis 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 ANÁLISIS DEL MODO DE FALLA Y EFECTO (FMECA) OBJETIVO DEL FMECA El análisis del modo de falla, efectos y análisis de criticidad (FMECA) es una función esencial en el diseño, desde el concepto hasta el desarrollo. Para ser efectivo, el FMECA debe ser iterativo para corresponder con la naturaleza propia del proceso de diseño. El grado de esfuerzo y de la sofisticación 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 adaptación requiere que, independientemente del grado de sofisticación, el FMECA debe contribuir de manera significativa a la decisión 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 adecuación de un enfoque de diseño. La utilidad del FMECA como una herramienta de diseño en el proceso de toma de decisiones depende de la eficacia con la que se comunica la información para el problema para la fase inicial de diseño. Probablemente, la mayor crítica del FMECA ha sido su uso limitado en la mejora de los diseños. Si bien el objetivo de un FMECA es la identificación de todos los modos de falla dentro de un diseño del sistema, su primer objetivo es la identificación temprana de todas las posibilidades de una falla catastrófica y crítica para que puedan ser eliminados o minimizados mediante la corrección de diseño a la mayor brevedad posible. Por lo tanto, el FMECA debe iniciarse tan pronto como la información de diseño preliminar está disponible en los niveles más altos del sistema y ser extendida a los niveles más bajos a medida que más información está disponible en los productos en cuestión. Aunque el FMECA es una tarea esencial de la confiabilidad, también proporciona información para otros fines. El uso de la FMECA se usa también en la mantenibilidad, análisis de seguridad, supervivencia y vulnerabilidad, análisis de apoyo logístico, análisis de plan de mantenimiento, y para la detección de fallas y aislamiento en el diseño del sistema. Este uso coincidente debe ser una consideración en la planificación del esfuerzo FMECA para evitar la proliferación de requisitos y la duplicación de esfuerzos dentro del programa contractual
DEFINICIONES a. Modo de Falla – Una forma particular en que un elemento falla, independiente de la razón de la falla. b. Análisis 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 jerarquización más bajo al
44
más 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 partición - La jerarquía de los niveles del equipo desde la parte al componente del subsistema en el sistema, etc. d. Redundancia - Más de un medio independiente para realizar una función. 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á desempeñando la función. 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 idénticos realizando la misma función. d. Redundancia con diferencia - ítems no idénticos realizando la misma función.
ALCANCE Las reglas típicas básicas para un FMECA se formalizan junto con un resumen de la técnica, objetivo, instrucciones paso a paso, las hojas de ejemplo de trabajo, y las entradas de trabajo de las hojas de datos. Para proyectos específicos, por supuesto, añadir, 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 métodos de solución operativa. Aunque el software de análisis 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 podrían 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 (asignación 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 más bajos. El presente procedimiento, no cuantifica la probabilidad de ocurrencia de la falla, sino que una evaluación cualitativa de los efectos de la falla se obtiene mediante la asignación de los modos de falla a una categoría de gravedad. Los resultados de los análisis se utilizan para mejorar el rendimiento del sistema mediante el inicio de las medidas correctivas, por lo general no sólo con los cambios de diseño, sino que también son útiles para centrar los procedimientos de garantía de producto y la identificación de las limitaciones operativas. El FMECA se actualiza según sea necesario para incluir cambios en el diseño y revisiones operacionales.
45
METODOLOGÍA Usando la metodología bottom – up, el FMECA se inicia seleccionando el equipo en el nivel más bajo de interés (por ejemplo, el módulo 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 identificación de los efectos de la falla hasta el nivel más alto del sistema. Es un proceso de inducción en síntesis.
ANÁLISIS PRELIMINAR DEL SUBSISTEMA Durante la fase conceptual del desarrollo del sistema, cuando la información de diseño se limita a diagramas de bloques, un "enfoque funcional" es apropiado para la identificación de problemas de diseño. Las fallas se postulan para los subsistemas principales (los subsistemas también se puede dividir en bloques de nivel inferior). Se evalúan los efectos y se realizan los cambios de diseño conceptual según sea necesario. A las fallas detectadas se le asignan a un nivel de gravedad con énfasis en las fallas catastróficas y crítica para los que se planifican posibles procedimientos de solución.
EL ANÁLISIS DETALLADO DEL EQUIPO El análisis detallado del equipo se lleva a cabo cuando los elementos del equipo, líneas de señales y de energía 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 diseño interno y se evalúan los efectos a nivel de componentes y estos son levantados a niveles más altos del montaje de equipo. El nivel del equipo en el que comience el análisis se incluye en la declaración del proyecto de trabajo, que por lo general requiere de un análisis a nivel de componentes. El análisis a menudo se extiende al nivel de la parte, según 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 jerarquización del equipo. Se postulan todos los modos probable, posible o creíble de una falla, que incluyen los mecanismos de falla que se han observado históricamente y cuyos mecanismos se han descrito, de acuerdo con el razonamiento de ingeniería. La identificación 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 análisis es realizado con el propósito 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 eléctrico o mecánico, se manifiestan en la interfaz con una de las condiciones de error siguientes: a. b. c. d.
Operación prematura. La falla de funcionamiento en un momento determinado, La falla de detener la operación cuando sea necesario. Error durante la operación.
Categorías 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 selección del nivel de gravedad. El efecto de la falla se evalúa 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 misión. 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 continuación. Para proyectos específicos se puede requerir definiciones ampliadas en función, por ejemplo, en la cantidad de degradación que es permisible en función de datos científicos. a. Categoría 1, Catastróficos - Los modos de falla que podrían resultar en lesiones graves o la muerte, o daños al equipo. b. Categoría 1R, Catastróficos - Los modos de falla de elementos idénticos o de equipos equivalente redundantes que, si todos fallan podrían dar lugar a efectos en la Categoría 1. c. Categoría 2, Crítica - Los modos de falla que podría resultar en la pérdida de uno o más objetivos para el cual el equipo se adquirió tal como se define por la oficina del proyectos. d. Categoría 2R, Crítica - Los modos de falla de naturaleza de elementos idénticos del equipo o equivalente redundantes que podrían resultar en la categoría 2 si todos los elementos fallan. e. Categoría 3, Importantes - Los modos de falla que podrían causar la degradación de los objetivos para el cual el equipo se adquirió o diseñó. f. Categoría 4, Menores - Los modos de falla que podría resultar en pérdida insignificante degradación de los objetivos para el cual el equipo se adquirió o diseñó.
EL PROCESO DEL FMECA A continuación se presenta un procedimiento típico 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 definición completa del sistema incluye la identificación 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 razón de la omisión. 2. Indican la profundidad del análisis, identificando el nivel de jerarquización en la que se inicia el análisis. 3. Identificar los requisitos específicos de diseño que se deben verificar por el FMECA. 4. Definir las reglas básicas y los supuestos en que se basa el análisis. Identificar las fases de la misión del objetivo y el estado de los equipos durante cada fase del objetivo. Un conjunto típico de reglas básicas (supuestos) a muestran a continuación: a. Sólo 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 están presentes en cantidades suficientes. d. La Potencia nominal está disponible. e. Todas las fases del objetivo son consideradas en el análisis; las fases del objetivo que demuestran ser inaplicables pueden ser omitidas. f. Los modos de falla de un conector se limitan a: conector en desconexión. g. Se prestará especial atención dirigida hacia la identificación de las fallas individuales que podrían causar la pérdida de dos o más 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 características de seguridad del sistema. 6. Identificar los modos de falla, efectos, detección de fallas y solución características y otra información pertinente sobre la hoja de trabajo. 48
7. Evaluar la severidad de cada efecto de la falla de acuerdo con las categorías de gravedad prescrita. 8. Identificar los diseños del equipo (u operaciones) que son candidatos para la acción correctiva y recomendar medidas correctivas específicas. 9. Documentar el análisis y entregar un resumen de los resultados.
EL ANÁLISIS DE CADA MODO DE FALLA Las tareas enumeradas para el FMECA se realizan una vez para cada análisis. Las tareas 6 y 7 se realizan para cada modo de falla. Un procedimiento de ejemplo para el análisis de cada modo de falla es como sigue: 1. 2. 3. 4. 5. 6. 7. 8.
9.
Seleccionar una parte o circuito de interfaz para su análisis. Identificar los ítems como R1, C1, C2, o J05 pin 1, etc., además de su nombre técnico 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 más alto del sistema de interés, es decir, el objetivo. Asignar un nivel de gravedad de acuerdo con las definiciones entregadas anteriormente. Proporcionar comentarios sobre cómo la falla podría ser detectada y qué medidas se pueden tomar para restablecer el funcionamiento. Si no se detecta, dejar constancia de ello. Proporcionar comentarios sobre la aplicación de la reconfiguración de redundancia para solucionar una falla, o cualquier otra información pertinente.
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 redacción 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 explicación es la siguiente para cada entrada de la columna. La siguiente es la información mínima que debe ingresar:
49
ANALISIS DEL MODO DE FALLA Y EFECTO Objetivo (Función): DTF – 1
Fecha:
Sistema: FTS
Preparado por:
Sub-sistema/instrumento: 3.13
Aprobado por:
Componente: cabezal del actuador Fase del objetivo: despegue Número del modo de falla
3.13.6
Identificación del ítem o función
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. Método para detectar la falla. b. Acciones/características compensatorias. c. Otros
Cabezal del actuador, el giro proporciona el movimiento de rotación en el eje (x)
a. Pérdida del control del motor b. Falla en la parte de accionamiento del circuito del motor
a. Pérdida de movimiento de rotación del cabezal y el torque b. No se puede continuar la tarea y la función de FTS c. Ninguno en el objetivo final
2R
a. El sensor de posición y sensor de torque se muestra en el panel de control, b. Equipo de respaldo para poner el brazo en posición segura. Un brazo robusto puede poner el brazo en posición segura.
Fig.14: Hoja de trabajo para un análisis FMECA
50
Información del ítem en la hoja de trabajo Número del modo de falla – identificador único para cada modo de falla evaluado. Ingréselos en orden numérico. Identificación del Ítem / Función – para el análisis funcional, ingrese una descripción de la función realizada. Para un análisis del equipo, escriba un identificador único, es decir, la nomenclatura, la designación 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 específico considerando las cuatro condiciones básicas de falla mostradas a continuación: 1. 2. 3. 4.
Operación no programada. Falla al no operar cuando sea necesario. Falla de detener sus operaciones cuando sea necesario. Falla durante la operación.
Para cada aplicación 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 tensión. 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 descripción del efecto de fallo en el nivel de la subdivisión que se analiza. b. Nivel Superior Siguiente – Introduzca el efecto de la falla al nivel del equipo por encima del nivel del análisis. c. Efecto Final u Objetivo – Introduzca el efecto del modo de falla en objetivo del equipo. (Si la falla no tiene ningún efecto, escribir ninguno.) Nivel de Severidad – Asigne un número para identificar el nivel de gravedad (véase la definición en los párrafos anteriores). Comentarios – Escriba cualquier otra información pertinente, referencias o comentarios. En especial escriba: a. Cómo la falla sería detectada con las facilidades del equipo u operador. b. Trabajar con elementos redundantes en las características del diseño.
51
EL INFORME FMECA Un resumen del proceso de análisis FMECA se muestra en la figura 15:
Equipos de la línea Construir diagramas de bloques funcionales y de confiabilidad
Planos y esquemas
Reglas básicas
Diagrama de bloques
Lista de partes
Revisión de datos
Preparación FMECA
Análisis y construcción del FMECA
Diagrama de confiabilidad Históricos de mantenimiento
Jerarquización niveles de descomposición Otros documentos Lista de elementos indexados
Árbol completo de Eventos básicos Ubicación jerarquización Tablas Referencias
Diagrama de bloques del sistema Hoja de partes especiales
Informe Final del análisis FMECA
Fig. 15: Proceso de elaboración de un análisis FMECA
Los informes preliminares o provisionales están generalmente disponibles para cada revisión del diseño. Un análisis del sistema en el nivel funcional debe estar listo para la revisión preliminar del diseño. Los informes provisionales deben contener todos los modos de falla y la identificación de las áreas problema con las acciones correctivas propuestas. Los siguientes son los principales tópicos cubiertos en el informe final: a. b. c. d. e. f. g.
Descripción detallada del sistema con diagramas de bloques de confiabilidad. Los niveles de jerarquización analizados. Resumen de los resultados. Resumen de las reglas básicas y los supuestos. Identificación y discusión de los modos de falla que son potenciales áreas de problemas. Lista de ítems no incluidos en el FMECA y la justificación de la exención. 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 ingeniería, el desarrollo de un producto requiere un mecanismo de medición para la retroalimentación y la evaluación. La medición es un mecanismo para crear una memoria corporativa y una ayuda para responder a una variedad de preguntas relacionadas con la difusión de cualquier proceso de un proyecto. Ayuda a apoyar la planificación del proyecto (por ejemplo, ¿Cuánto será el costo del nuevo proyecto?), sino que también permite determinar las fortalezas y debilidades de los actuales procesos y productos (por ejemplo, ¿Cuál es la frecuencia de ciertos tipos de errores?), además proporciona una justificación para la adopción / refinamiento de las técnicas (por ejemplo, ¿Cuál es el impacto de la técnica XX en la productividad de los proyectos?), permite evaluar la calidad de los procesos y productos específicos (por ejemplo, ¿Cuál es la tasa de defectos en un determinado sistema después de su implementación?). La medición también contribuye durante el transcurso de un proyecto, para evaluar su progreso, para tomar medidas correctivas sobre la base de esta evaluación, y para evaluar el impacto de dicha acción. En la aplicación de métricas y modelos en entornos industriales, la medición, con el fin de ser eficaz debe ser: 1. Centrada en objetivos específicos; 2. Aplicada a todos el ciclo de vida del productos, procesos y recursos; 3. Interpretada en función de la caracterización y comprensión del contexto organizacional, medio ambiente y metas. Esto significa que la medición 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 suposición de que para que una organización 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 relación para definir los objetivos operativos, y por último proporcionar un marco para la interpretación de los datos con respecto a los objetivos fijados. Por lo tanto, es importante dejar en claro, al menos en términos generales, qué necesidades de información tiene la organización, de manera que estas necesidades de información pueden ser cuantificadas siempre que sea posible, y la información cuantificada pueda ser analizada para evaluar si los objetivos se están logrando.
53
El resultado de la aplicación del enfoque GQM es la especificación de un sistema de medición apuntando a un conjunto particular de problemas y un conjunto de reglas para la interpretación de los datos de medición. El modelo de medición 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 relación con un entorno particular. Los objetos de medición son: Productos: artefactos, productos y documentos que se producen durante el ciclo de vida del sistema, por ejemplo, especificaciones, diseños, programas, series de pruebas. Procesos: actividades relacionadas con el proyecto que normalmente se asocian con el tiempo, por ejemplo, la especificación, diseño, 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 evaluación / del logro de un objetivo específico que va a llevarse a cabo sobre la base de un modelo de caracterización. 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 sólo del objeto que se está midiendo y no en el punto de vista de los que la toman, por ejemplo, número de versiones de un documento, las horas del personal dedicado a una tarea, el tamaño 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 satisfacción de los usuarios. El modelo GQM es una estructura jerárquica (Figura 16) que se inicia con una meta (especificando el propósito de la medición, 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 continuación, que generalmente suele quebrar el problema en sus componentes principales. Cada pregunta se refina en las métricas, algunos de ellas objetivas, y otras subjetivas. La misma métrica se puede utilizar con el fin de responder a diferentes preguntas en el mismo objetivo. Varios modelos GQM también pueden tener preguntas y métricas comunes, asegurándose de que, cuando la medida se toma realmente, los diferentes puntos de vista se toman en cuenta correctamente (es decir, la medida podría tener valores diferentes cuando se toman desde diferentes puntos de vista).
54
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
Nivel Cuantitativo Asociados con cada pregunta es el conjunto de datos, ya sean objetivos o subjetivos, que ayudan a entregar una respuesta cuantitativa
Meta 1
Preg. 1
Met. 1
Preg. 2
Met. 2
Met. 3
Meta 2
Preg. 3
Met. 4
Preg. 4
Met. 5
Preg. 5
ANÁLISIS E INTERPRETACIÓN
DEFINICIÓN
Nivel Conceptual Metas medibles que involucran productos, procesos y/o recursos
Met. 6
Fig. 16: Proceso jerárquico del análisis GQM Con el fin de dar un ejemplo de aplicación del enfoque Meta / Pregunta / Métricas, suponer que se quiere mejorar la puntualidad del procesamiento de la solicitud de reparación 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 reparación), 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 métricas de comparación específica de los tiempos de respuesta con los tiempos medios. El proceso total Meta / Pregunta / Métricas se muestra a continuación: Meta
Pregunta Métrica
Pregunta Métrica
Propósito Problema Objeto (proceso) Punto de vista
Mejorar La puntualidad de Procesamiento de la solicitud de reparación Del director del proyecto ¿Cuál es la actual velocidad de procesamiento de la solicitud de reparación? Ciclo de tiempo promedio Desviación estándar % de casos fuera del límite superior ¿Es mejorable la eficiencia del proceso? Ciclo de tiempo promedio actual Ciclo de tiempo promedio base Porcentaje subjetivo a satisfacción del administrador 55
EL PROCESO GQM Un modelo GQM se desarrolla mediante la identificación de un conjunto de objetivos o metas de calidad y/o productividad, a nivel corporativo, de división, o de proyecto, por ejemplo, la satisfacción 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 más completa posible. Por ejemplo, si se trata de caracterizar un sistema de software (un paquete de correo electrónico, un procesador de textos u otros) con respecto a un determinado conjunto de problemas de calidad (por ejemplo, la portabilidad a través 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 características 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. Después que las medidas se han especificado, es necesario desarrollar los mecanismos de recopilación de datos, incluidos los mecanismos de validación y análisis. El proceso de definición de metas es fundamental para la aplicación exitosa del enfoque GQM y es apoyado con ciertos pasos metodológicos. 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 propósito: 1.
Propósito
Mejorar
Entonces, el desarrollo de una meta se basa en tres fuentes básicas de información. La primera fuente es la política y la estrategia de la organización que está aplicando el enfoque GQM. De esta fuente se deriva tanto del tema y el propósito de la meta mediante el análisis de las declaraciones de políticas de las empresas, planes estratégicos y, más importante, entrevistando a las personas claves en la organización. La segunda fuente de información es la descripción de los procesos y productos de la organización, o, al menos, los que están 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 especificación 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 información es el modelo de la organización, 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 organización, por lo tanto, hay que realizar una etapa de análisis 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 especificación de las metas que tiene en cuenta la estructura y el objetivo de la organización. A partir de la especificación 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. ¿Cómo se puede caracterizar el objeto (producto, proceso o recurso) con respecto a la meta global del modelo específico GQM? Ejemplo: Pregunta: ¿Cuál es la actual velocidad de procesamiento de la solicitud de reparación? Pregunta: ¿Es (documentado) el proceso de solicitud de reparación actualmente ejecutado? Grupo 2. ¿Cómo se pueden caracterizar los atributos del objeto que son relevantes con respecto al tema del modelo específico GQM? Ejemplo: 57
Pregunta: ¿Cuál es la desviación del tiempo de procesamiento del actual proceso de solicitud de reparación, desde el tiempo estimado? Pregunta: ¿Se está mejorando la eficiencia del proceso? Grupo 3. ¿Cómo se evalúan las características del objeto que son relevantes con respecto al tema del modelo específico 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 métricas 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 están disponibles y son confiables; Madurez de los objetos de medidas: se van a aplicar las medidas objetivas de medición a los objetos con mayores conocimientos de ellos, y se harán uso de las evaluaciones más subjetivas cuando se trata de objetos informales o inestables. Proceso de aprendizaje: los modelos GQM necesitan siempre perfeccionamiento y adaptación, por lo tanto, las medidas que se definen deben ayudar a evaluar no sólo el objeto de medición, sino también la confiabilidad del modelo utilizado para evaluarlo. Teniendo en cuenta estas ideas, se puede completar el modelo GQM con algunos parámetros adecuados. El resultado se muestra a continuación: Meta
Pregunta Métrica
Pregunta Métrica
Propósito Problema Objeto (proceso) Punto de vista Q1 M1 M2 M3 Q2 M4 M5
Mejorar La puntualidad de Procesamiento de la solicitud de reparación Del director del proyecto ¿Cuál es la actual velocidad de procesamiento de la solicitud de reparación? Ciclo de tiempo promedio Desviación estándar % de casos fuera del límite superior ¿Es (documentado) el proceso de solicitud de reparación actualmente ejecutado? Evaluación subjetiva del administrador del proyecto % de excepciones identificadas durante las revisiones 58
Pregunta
Q3
¿Cuál es la desviación del tiempo de procesamiento del actual proceso de solicitud de reparación, desde el tiempo estimado?
Métrica
M6
Tiempo promedio del ciclo actual – Tiempo promedio estimado del ciclo Tiempo promedio del ciclo actual
Pregunta Métrica
M7 Q4 M8
Pregunta
Q5
Métrica Pregunta Métrica
M7
Evaluación 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? Evaluación 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 satisfacción del administrador
Una vez que un modelo GQM se ha desarrollado, se seleccionan las técnicas adecuadas de recolección los datos, las herramientas y procedimientos. Los datos que serán recolectados e mapeado en el modelo e interpretados de acuerdo a los planes previamente definidos por la organización.
59
ANÁLISIS DEL COSTO DEL CICLO DE VIDA PORQUÉ USAR EL ANÁLISIS COSTO DEL CICLO DE VIDA El análisis del costo del ciclo de vida (LCC) es un método de evaluación de proyectos en el cual todos los costos que se levantan desde la adquisición, operación, mantenimiento y por último su eliminación de un proyecto son considerados ser potencialmente importante para esa decisión. El LCC puede ser aplicado para cualquiera decisión de inversión de capital en el cual los altos costos iníciales 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 método alternativo económico que se focalice solamente en los primeros costos o en costos relacionados con la operación de corto plazo. El LCC es una herramienta de análisis económico poderosa. Como tal, requiere más información que para hacer el análisis basado en consideraciones del primer costo o de corto plazo. También 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 inversión, rechazar oportunidades de inversiones rentables, y aceptar costos más altos que los necesarios.
¿QUÉ ES EL ANÁLISIS DEL COSTO DEL CICLO DE VIDA? El Análisis de costos del ciclo de Vida (LCCA) es una técnica de evaluación aplicable a la consideración de ciertas decisiones de inversión. En concreto, cuando se ha decidido que el proyecto se llevará a cabo, LCCA ayudará en determinar la mejor – la de más bajo costo – forma de realizar el proyecto. El enfoque LCCA permite comparar el costo total de alternativas de diseños competitivos, cada una de ellas apropiadas para la implementación de un proyecto. Todos los costos relevantes que se producen a lo largo de la vida de una alternativa, no sólo el gasto original, están incluidos. También, los efectos de la construcción y las actividades de mantenimiento en los usuarios, así como los costos directos producto de la inversión, 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 iníciales y futuras involucradas en la implementación de cada alternativa de diseño del proyecto. A continuación, se estiman los costos de estas actividades. Las mejores prácticas LCCA incluyen no sólo los gastos directos del proyecto (por ejemplo, actividades de construcción o mantenimiento), sino también 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 diseño. Usando una técnica económica 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 más rentable. Es importante señalar que la opción más baja del LCC no necesariamente puede aplicarse cuando otras consideraciones tales como el riesgo, los presupuestos disponibles, y las preocupaciones políticas y ambientales son tomadas en cuenta. El LCCA proporciona información crítica para el conjunto de toma de decisiones, pero no es la respuesta final.
¿POR QUÉ USAR LCCA? Las decisiones relacionadas con la aplicación de un proyecto en general, requieren que varias alternativas sean consideradas. Muchos factores contribuyen a la decisión de un inversionista para seleccionar una opción en particular, aunque los costos iníciales de los proyectos pueden llegar a dominar esta decisión. Los costos iníciales del proyecto, sin embargo, son sólo una parte de la historia. La alternativa de diseño seleccionado compromete a los inversionistas para los futuros gastos de mantenimiento y acciones de rehabilitación 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 decisión de inversión. Además, la estructura y documentación del proceso de LCCA provee a los inversionistas y analistas con la capacidad de mejorar su gestión de inversión.
TERMINOLOGÍA DE ANÁLISIS DEL COSTO DEL CICLO DE VIDA El análisis de costos del Ciclo de Vida es un proceso de diseño esencial para el control de costos iníciales y en el futuro de la construcción del inversionista. El LCCA se puede aplicar en cualquier nivel del proceso de diseño y también puede ser una herramienta eficaz para la evaluación de sistemas de construcción 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 específico. 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 período de tiempo. Teniendo en cuenta esta definición, se puede descomponer la ecuación del LCC en las siguientes tres variables: los costos pertinentes de la propiedad, el período 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 días.
Los gastos iníciales y futuros El primer componente en una ecuación de LCC es el costo. Hay dos categorías principales de costos por los que los proyectos deben ser evaluados en un LCCA. Son gastos iníciales y gastos 61
futuros. Los gastos iníciales son todos los gastos incurridos antes de la ocupación de las instalaciones: gestión de la construcción, adquisición de tierras, investigación del sitio, servicios de diseño, construcción, equipo, tecnología, indirectos / administración, difusión, contingencia, entre otros). Gastos de futuro son todos los gastos incurridos después de la ocupación de las instalaciones: Costos de operación (costos anuales): combustibles, electricidad, agua y alcantarillados, basura, guardias, seguros; Costo de mantenimiento y reparación (gastos programado y no programado de mantenimiento) mejoras en el sitio, habilitación del sitio, fundación / infraestructura, sistemas de transporte, sistemas de protección contra incendios, controles HVAC, servicio eléctrico / generación, distribución de energía eléctrica, equipo y mobiliario; etc.; Costo de reemplazo (reemplazo programado de los sistemas de construcción o componentes); Valor residual (valor de las instalaciones al final del periodo de estudio). La definición de los costos exactos de cada categoría de gasto puede ser algo difícil, ya que, en el momento del estudio del LCC, casi todos los costos son desconocidos. Sin embargo, a través del uso de supuestos razonables, coherentes y bien documentado, un LCCA con alta certeza puede estar preparado. También hay que destacar que no todas las categorías de costos son relevantes para todos los proyectos. El analista es el responsable de la inclusión de las categorías de costos pertinentes que producirá una comparación realista LCC de las alternativas del proyecto. Si los costos en una categoría 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 comparación de los LCC.
Valor Residual Un gasto futuro que merece una explicación más detallado es la del valor residual. El valor residual es el valor neto de un activo al final del período 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 período de estudio. Cualquiera sea la razón por el valor residual, es un activo tangible del propietario y debería ser incluidos en el LCCA. Un valor residual positivo indica que hay costos asociados con la eliminación del activo al final del período de estudio. Tal vez, los costos están relacionados con la reducción de materiales peligrosos o la demolición de la estructura. Cualquiera sea la causa, se trata de costos del propietario y deberían ser incluidos en el LCCA. Un valor residual cero indica que no existe un valor o costo asociado con el activo al final del período de estudio. Este caso raro se produce cuando el uso que se destina el activo termina 62
concurrente al final del período de estudio, el propietario no puede vender el edificio, y el propietario es capaz de abandonar el edificio sin costo alguno.
Período de Estudio El segundo componente de la ecuación de LCC es el tiempo. El período de estudio es el período 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 período de estudio puede variar desde veinte a cuarenta años, dependiendo de las preferencias del propietario, la estabilidad del programa del usuario, y la vida estimada total de la instalación. Mientras que el largo del período de estudio es a menudo un reflejo de la vida prevista de una instalación, el periodo de estudio suele ser más corto que la vida útil prevista de la instalación.
Tasa de Descuento Real El tercer componente de la ecuación de LCC es la tasa de descuento. La tasa de descuento, la definición es "la tasa de interés refleja el valor del dinero de los inversores en el tiempo." Básicamente, es la tasa de interés que haría a un inversor ser indiferente en recibir un pago ahora o un pago mayor en algún momento en el futuro.
Dinero Constante Así como las tasas de descuento se pueden definir como real o nominal, también lo pueden ser los costos. Se define el dinero constante como "dinero de poder adquisitivo uniforme ligado a un año de referencia y exclusivo del índice general de precios la inflación o deflación." Cuando se utiliza la tasa de descuento real en los cálculos de valor presente, los costos deberán ser expresados en dinero constantes. Del mismo modo, cuando se utiliza la tasa de descuento nominal en los cálculos de valor presente, los costos deben ser expresados en dinero corriente. En el raro caso de que la tasa de inflación 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 práctica, el uso de los dineros constantes simplifica la LCCA. Por ejemplo, suponga que se quiere evaluar los productos de techado en un período de 30 años. Sin embargo, un producto de tejado debe ser reemplazado después de 20 años. ¿Cuál será el costo de reemplazo del techo en 20 años? Mediante el uso de dineros constantes, la conjetura de la estimación de la escalada de los costos de mano de obra y materiales se elimina. El costo futuro en dineros constantes (con exclusión de la demolición) para instalar un nuevo techo en 20 años 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 precisión los gastos iníciales 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 año base." El cálculo 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 año base del período de estudio. Dado que la mayoría de los gastos iníciales se producen en la misma época, los gastos iníciales se consideran que ocurre durante el año base del período de estudio. Por lo tanto, no hay necesidad de calcular el valor presente de estos gastos iníciales debido a su valor presente es igual a su costo real. La determinación del valor presente de los costos futuros depende del tiempo. El período de tiempo es la diferencia entre el tiempo de los costos iníciales y el tiempo de los costos futuros. Los costos iníciales incurridos al inicio del período de estudio en el año 0, el año base. Los costos futuros se pueden incurrir en cualquier momento entre los años 1 y el fin del proyecto. El cálculo del valor presente es el ecualizador que permite la suma de los costos iníciales y futuros. Junto con el tiempo, la tasa de descuento también 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 categorías: los gastos no recurrentes y los costos recurrentes. Los costos recurrentes son los costos que se producen cada año en el lapso del período de estudio. La mayoría de los costos de operación y mantenimiento son costos recurrentes. Los costos no recurrentes son costos que no se producen siempre en los años en el lapso del período de estudio. La mayoría de los costos de reposición 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 año y en el año en que se producen. Para determinar el valor presente de los gastos no recurrentes se utiliza la siguiente fórmula:
Donde: VP = Valor Presente At = gasto no recurrente en el año t i = Tasa de Descuento Real t = Tiempo (expresado como número de años)
64
Para determinar el valor presente de los costos recurrentes se utiliza la siguiente fórmula:
Donde: VP = Valor Presente A0 = Cantidad del Costo Recurrente i = Tasa de descuento real t = Tiempo (expresado como número de años)
SELECCIÓN 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 solución más razonable y rentable para el problema del proyecto. Un mínimo de tres alternativas diferentes de proyectos deben ser incorporadas al LCCA. En el LCCA se debe incluir una breve descripción de cada alternativa de proyecto y por qué fueron elegidas. Un LCCA sólo necesita tratar las categorías de costos que son pertinentes para el alcance del proyecto. Sin embargo, para asegurar una comparación precisa de alternativas, todas las evaluaciones LCCA de las alternativas del proyecto deben incorporar las mismas categorías de costos. El LCCA de cada alternativa de proyecto debe incluir: Una breve descripción de la alternativa de proyecto Una breve explicación de por qué la alternativa de proyecto fue seleccionado Una breve explicación de los supuestos formulados durante el LCCA Una documentación conceptual o esquemática que indica el diseño intentado de la alternativa Un plano del lugar que muestra la integración de las instalaciones propuestas en el lugar y las mejoras necesarias del lugar (para proyectos que impliquen adiciones o nueva construcción) Un LCCA detallada de la alternativa de proyecto Una tabla resumen que compara los costos totales del ciclo de vida de la inversión inicial, operaciones, mantenimiento y reparación, reposición, 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 planificación del costo de la vida útil con las dos últimas etapas incorporando la fase de análisis del costo. Las seis etapas son las siguientes:
Etapa 1: Análisis del Plan de LCC
Etapa 6: Aplicar y Supervisar el Análisis de Costos de Vida
Etapa 2: Seleccionar / Desarrollar Modelo LCC
Etapa 5: Preparar el Análisis 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 interpretación de los resultados de los análisis. El análisis LCC es una actividad multidisciplinaria. Un analista debe estar familiarizado con la filosofía, que es la base del cálculo del costo del ciclo de vida (incluidos los elementos de costos típicos, las fuentes de datos sobre los costos y los principios financieros), y debe tener una clara
66
comprensión de los métodos de evaluación de las incertidumbres asociadas a la estimación de costos. Dependiendo del alcance del análisis, será importante obtener los costos de los insumos individuales que están relacionados con cada una de las fases del ciclo de vida del activo. Esto puede incluir representantes del proveedor(s) y del usuario(s).
CONCLUSIÓN 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, diseño, compra o manufactura, instalación, prueba, puesta en marcha, operación y mantenimiento, hasta su eventual reciclaje, descarte ó disposición final. En todas esas etapas, hay decisiones a tomar, información a seguir, costos a evaluar, registrar y considerar, repuestos a definir, capacitación de operadores y mantenedores a desarrollar, análisis que hacer referentes a distintos aspectos de la operación y el mantenimiento del activo. La adecuada consideración 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 Gestión de Activos en las Empresas y Corporaciones hoy día.
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, Identificación y Evaluación de Riesgos HAZOP, Prevention-World, 2003 Fuller S., Petersen S., Life-Cycle Costing Manual, NIST Handbook 135, Ed. 1995 Garcia Oliverio, El Análisis Causa Raíz, Estrategia de Confiabilidad Operacional, Lubrication Excellence, Conferencia y Exhibición, 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
