CONFIABILIDAD OPERACIONAL DE EQUIPOS:

METODOLOGÍAS Y HERRAMIENTAS

FERNANDO ESPINOSA FUENTES

ii

Í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

1

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

2

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 que faciliten la

optimización industrial, entre las cuales se pueden destacar:

3

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

4

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.

5

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

6

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

7

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.

8

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

9

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 Técnicas de Verificación

Erosión, Corrosión, Fatiga y Sobrecarga Análisis Metalúrgico

Alta Vibración Instrumentos y Vigilancia de la Vibración

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

10

• 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

11

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

12

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.

13

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. Las causas fundamentales son específicas de las causas subyacentes.

2. Las causas fundamentales son las que razonablemente se puede identificar.

3. Las causas fundamentales son las que gestión tiene el control de arreglar.

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

14

Cuatro pasos importantes

La RCA es un proceso de cuatro etapas que implica lo siguiente:

1. Recopilación de datos.

2. Gráficas del factor causal

3. Identificación de la causa raíz.

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

15

Quemador

eléctrico en corto

circuito

Quemador

FC

El arco calienta el

fondo de aluminio

de la cacerola

Cacerola

Aluminio se funde,

forma un agujero

en la cacerola

Cacerola

Grasa arde da

contacto con el

quemador

Conclusión

El fuego comienza

en la cocina

María

Maria se

encuentra con

Julia

María

10minutos

Detector de humo

da la alarma

María y Julia

Alrededor 17:10

María deja el pollo

friéndose

desatendido

María

María comienza a

freir el pollo

María

Hora: 17.00

María usa una

cacerola de

aluminio

Cacerola

¿Cuánto aceite

usa? ¿Cuál es la

cantidad de pollo?

Pollo, aceite,

cacerola

Julia toca el timbre

María y Julia

Julia llega hasta la

puerta de entrada

Julia

El fuego genera

humos

Asumido

María corre hacia

la cocina

María

María trata de

usar el extinguidor

de fuego

María

María acciona el

gatillo del

extinguidor

María

El extinguidor no

funciona cuando

se necesitó

María

María ve el fuego

en la cocina

María

El extinguidor no

está recargado

María

FC

FC

FC Factor Causal

¿El gatillo calza

bien en el

accionador?

María

¿Sabe María

accionar el

extinguidor?

María

¿Qué fue lo que

vio exactamente?

María

¿Había sido

usado

previamente?

Tarjeta de

inspección

¿Tiene goteras?

Ubicación del

extinguidor

¿No había sido

recargado

originalmente?

Extinguidor de

fuego

Fig. 7: Gráfica de los factores causales

16

María arroja agua

a la cocina

María

El fuego se

esparce a través

de la cocina

Cocina, María

María llama a los

bomberos

María, Bomberos

Hora?

Los bomberos

llegan

Observación

Hora?

Los bomberos

apagan el fuego

Bomberos, obs.

Hora?

La cocina

destruida por el

fuego

Otras pérdidas

por el humo y el

agua

El fuego fue grasa

ardiendo

María, cacerola

¿Estaba María

tratando de hacer

esto?

María

¿Trató de hacer

algo más?

María

¿Sabía ella que

eso estaba

mal?¿Falta de

práctica con el

combate al

fuego?

María

¿Qué estaba

haciendo Julia en

ese momento?

María, Julia

¿Cuánto fue la

demora de los

bomberos?

Despachador

¿Usaron los

bomberos las

técnica correctas?

Bomberos

FC

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.

17

Comenzar aquí para cada factor causal

Dificultad en el equipo

1

Problema en el

diseño del equipo

Problemas en el

programa de

confiabilidad

Instalación /

fabricación

Mal uso del

equipo

Input/Output

del diseño

Datos del

equipo

Diseño del

programa de

confiabilidad MqA

Implementación

del programa de

confiabilidad MqA

Sistema de

gestión

administrativo

MqA : Menos que Adecuado

Procedi-

mientos

2

Input del diseño

MqA

Output del diseño

MqA

Datos de diseño del

equipo MqA

Datos de operación /

historial de

mantenimiento del

equipo MqA

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

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

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

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

EPCA no son usados

• La comunicación de los

EPCA MqA

• Cambiados recientemente

• Aplicación MqA

Revisión del riesgo su

seguridad /posibilidad

• Revisión MqA o no ejecutada

• Las recomendaciones aún

no son implementadas

• El criterio de aceptación MqA

• Revisión de los

procedimientos MqA

Control del producto/

material

• Manejo MqA

• Almacenamiento MqA

• Embalaje/despacho MqA

• Sustitución del material no

autorizada

• Criterios de aceptación del

producto MqA

•Inspección del producto MqA

Control de identificación de

los problemas

• Reportes de los problemas

MqA

• Análisis de los problemas

MqA

• Auditoría MqA

• Acciones correctivas MqA

• Acciones correctivas aún no

implementadas

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

No usados

• No disponible o

inconveniente para obtener

•Procedimiento difícil de usar

• Uso no requerido pero está

• Tarea sin procedimientos

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

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

18

Comenzar aquí para cada factor causal

Dificultad en el personal

1

Empleados de la

compañia

Empleados

contratistasEventos externos Otros

Ingeniería

factor humanoEntrenamiento

Supervisión

inmediataComunicaciones

Eficiencia del

personal

MqA : Menos que Adecuado

2

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

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

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

Ambiente de trabajo

• Limpieza MqA

• Herramientas MqA

• Ropa protectora/equipos

MqA

• Condiciones ambientales

MqA

• Otros stress ambientales

excesivos

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

Sistema sin tolerancia

• Errores no detectables

• Errores no corregibles

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

Instrucciones erradas

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

Comunicación sin entender

• Terminología estandarizada

no usada

• Verificación / validación no

usada

• Mensajes largos

Rotación del trabajo MqA

• Comunicación con los

grupos de trabajo (turnos)

MqA

• Comunicación entre grupos

MqA

Otras dificultades

Sabotajes/

payasadas

Fenómenos

naturales

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

19

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 friendo el pollo sin atención

• Dificultad personal. •Sistema administrativo/administración. • Estándares, políticas o control administrativo MqA . • Sin control.

• Implementar una política para que el aceite caliente nunca se deje de atender cuando esté en el quemador. • Determinar si se han desarrollado 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 quemador eléctrico falla (cortocircuito).

• Dificultad en el equipo. • Problema de confiabilidad del equipo. • Diseño del programa de confiabilidad del equipo MqA.

• Reemplace todos los quemadores de la cocina. • Desarrolle una estrategia de mantenimiento preventivo para

20

• No hay programa. 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.

Factor causal Nº 3 Ruta en el mapa Causa Raíz Recomendaciones

Descripción: el extinguidor del fuego no operó cuando María trató de usarlo. .

• Dificultad en el equipo. • Problemas con la confiabilidad del equipo. • Mantenimiento proactivo del equipo MqA. • Implementación de actividades MqA.

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

• Dificultad en el equipo. • Problemas con la confiabilidad del equipo. • Sistema administrativo /gestión. • Identificación de problemas y control MqA.

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

Factor causal Nº 4 Ruta en el mapa Causa Raíz Recomendaciones

Descripción: María arroja agua en el fuego.

• Dificultad del personal. • Empleados de la compañía. • Entrenamiento. • Entrenamiento MqA. • Evento anormal/entrenamiento de emergencias MqA.

• 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

21

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.

22

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.

2. Análisis de Problemas ¿Por qué ocurrió esto? Permite relacionar un suceso con su resultado,

una causa con su efecto.

3. Análisis de Decisiones ¿Qué curso de acción hay que tomar? Permite hacer decisiones

razonadas.

4. Análisis de Problemas Potenciales ¿Qué nos espera más adelante? Permite mirar en dirección

al futuro que nos depara.

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. La identidad de la falla (¿Qué?)

2. El lugar donde ocurre (¿Dónde?)

3. Su ubicación en el tiempo (¿Cuándo?)

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

23

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 PUEDE SER PERO NO ES DIFERENCIAS CAMBIOS

QUE Falla del sistema Sistemas similares/situaciones sin fallas

? ?

DONDE Ubicación de la falla Otras ubicaciones que no fallaron ? ?

CUANDO Momento de la falla Otras veces cuando la falla no ocurrió

? ?

EXTENSIÓN Otras fallas del sistema Otros sistemas sin falla ? ?

24

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

DIFERENCIAS CAMBIOS

QUE

Servidor de intercambio 123 falló después de la aplicación del pegamento caliente XYZ

Otros servidores de intercambio usaron pegamento caliente XYZ

Diferente staff (3er turno) aplicó este pegamento

Vendedor entrega un nuevo procedimiento

DONDE

La sala de producción del tercer piso sin el soporte de un vendedor/contratista

En cualquier lugar con soporte de vendedor/contratista

Normalmente hecho por un vendedor

Nuevo procedimiento, primera vez que lo aplica el tercer turno

CUANDO Última noche, 1:35am Cualquier hora o ubicación

Sin anotación

EXTENSIÓN Todos los servidores del 3er piso

Otros servidores

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

25

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: Verdad si: ¿Causa raíz probable?

El servidor de intercambio 123 tiene algo

de malo en él Solamente el servidor de intercambio 123 tiene este problema

Puede ser

Procedimiento incorrecto El mismo procedimiento rompió otro servidor

Probable

Error técnico 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.

26

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.

27

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

¿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

CAUSA

RAIZ

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

28

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.

29

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

30

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.

31

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.

32

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.

33

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.

34

Palabra guía

Significado Ejemplo de desviación

Ejemplo de causas originadoras

NO Ausencia de la variable a la cual se aplica

No hay flujo en una línea

Bloqueo; fallo de bombeo; válvula cerrada o atascada; fuga; válvula abierta; fallo de control

MÁS Aumento cuantitativo de una variable

Más flujo (más caudal)

Presión de descarga reducida; succión presurizada; controlador saturado; fuga; lectura errónea de instrumentos

Más temperatura Fuegos exteriores; bloqueo; puntos calientes; explosión en reactor; reacción descontrolada

MENOS Disminución cuantitativa de una variable

Menos caudal Fallo de bombeo; fuga; bloqueo parcial; sedimentos en línea; falta de carga; bloqueo de válvulas

Menos temperatura

Pérdidas de calor; vaporización; venteo bloqueado; fallo de sellado

INVERSO Analiza la inversión en el sentido de la variable. Se obtiene el efecto contrario al que se pretende

Flujo inverso 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

ADEMÁS DE

Aumento cualitativo. Se obtiene algo más que las intenciones del diseño

Impurezas o una fase extraordinaria

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

PARTE DE Disminución cualitativa. Parte de lo que debería ocurrir sucede según lo previsto

Disminución de la composición en una mezcla

Concentración demasiado baja en la mezcla; reacciones adicionales; cambio en la alimentación

DIFERENTE DE

Actividades distintas respecto a la operación normal

Cualquier actividad 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.

35

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 Contenido

Posibles causas Describe numerándolas las distintas causas que pueden conducir a la desviación

Consecuencias Para cada una de las causas planteadas, se indican con la consiguiente correspondencia en la numeración las consecuencias asociadas

Respuesta del sistema

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

Acciones a tomar 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

Comentarios 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

36

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.

37

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.

38

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

J1 Bombas de trasvase

(una en funcionamiento

y otra en reserva)

Drenaje y

purgado

con N2

I-2

I-3

20ªC

35 psig

Conducción

de 500 m

Hidrocarburos de

tanque intermedio

I-5

Depósito

regulador / dosificador

25 m3 20ªC 15 psig

Colector

de agua

A drenaje

Nitrógeno

(Inertizante)

PG

PG

FO

TR

AN

LIC

PIC

RF

Drenaje y

purgado

con N2

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:

39

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 guía

Desviación Causas posibles Consecuencias Medidas a tomar

NO NO FLUJO 1. Inexistencia de hidrocarburo en tanque intermedio

Paralización del proceso de reacción esperado.

a) Asegurar buena comunicación con el operario del tanque intermedio

Formación de polímero en el intercambiador de calor

b) Instalar alarma de nivel mínimo LIC en depósito regulador

2. Bomba J1 falla (fallo de motor, circuito de maniobra, etc.)

Como apartado 1 Cubierto por b)

3. Conducción bloqueada, válvula cerrada por error o LCV falla cerrando paso al fluido

Como apartado 1 Cubierto por b)

Bomba J1 sobrecargada c) Instalar sistema de 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 descargado en área adyacente a vía pública

e) Implantar inspección regular de la conducción 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.

40

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 Categoría Consecuencias

LEVE 1 Lesión(es) leve(s) no incapacitante(s)

SERIA 2 Lesión(es) incapacitante(s) temporal(es) y permanente(s)

parcial(es)

GRAVE 4 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 Diaria

1 2 3 4

c) Estimación de la probabilidad (P)

Categoría Definición

1 Casi improbable que ocurra

2 Puede ocurrir alguna vez

3 Ocurre regularmente

4 Ocurre la mayor parte de las veces

41

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 Rango (MR)

Grave 24 a 64

Serio 16 a 18

Leve 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 Pérdidas entre (US$)

1 1 y 100.000

2 100.000 y 250.000

3 250.000 y 500.000

4 500.000 y 1.000.000

5 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 Definición

1 Insignificante – mínimo impacto

2 Baja severidad – acción local

3 Mediana severidad – apoyo de otras áreas

4 Severa – compromete a toda la organización

5 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,

42

Categoría Definición

6 Se espera que ocurra al menos una vez al año. Ocurre la mayor parte de las veces.

5 Se espera ocurra al menos una vez cada 3 años. Ocurre regularmente.

4 Se espera ocurra al menos una vez cada 10 años- Ocurre algunas veces.

3 Se espera ocurra al menos una vez cada 15 años. Es raro que ocurra.

2 Se espera que ocurra no más de 1 vez en 25 años. Ha ocurrido

1 Se espera que ocurra no más de 1 vez en 90 años. Casi improbable que ocurra – se tiene conocimiento que ha ocurrido.

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.

Pro

bab

ilid

ad

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

Consecuencias

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 Rango MR

Grave 15 a 30

Serio 5 a 12

Leve 1 a 4

Matriz Gravedad Riesgo

43

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) Eliminar el riesgo que puede afectar a las instalaciones o proceso.

b) Minimizar los efectos de los riesgos desencadenados.

c) Aplicar medidas de control de riesgos.

d) Establecer planes de emergencias y de contingencias.

44

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

45

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.

46

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.

47

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. Operación prematura.

b. La falla de funcionamiento en un momento determinado,

c. La falla de detener la operación cuando sea necesario.

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

48

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.

49

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. Seleccionar una parte o circuito de interfaz para su análisis.

2. Identificar los ítems como R1, C1, C2, o J05 pin 1, etc., además de su nombre técnico

3. Postular una solo falla, incluyendo el modo de falla.

4. A partir del conocimiento de la parte / circuitos, identificar una posible causa de falla.

5. A partir del conocimiento del funcionamiento del circuito en la presencia de la falla

postulada, evaluar el efecto local.

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

7. Asignar un nivel de gravedad de acuerdo con las definiciones entregadas

anteriormente.

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

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

50

ANALISIS DEL MODO DE FALLA Y EFECTO

Objetivo (Función): DTF – 1

Sistema: FTS

Sub-sistema/instrumento: 3.13

Componente: cabezal del actuador

Fase del objetivo: despegue

Fecha:

Preparado por:

Aprobado por:

Número del

modo de

falla

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

3.13.6 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

51

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. Operación no programada.

2. Falla al no operar cuando sea necesario.

3. Falla de detener sus operaciones cuando sea necesario.

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

52

EL INFORME FMECA Un resumen del proceso de análisis FMECA se muestra en la figura 15:

Equipos de la línea

Planos y esquemas

Lista de partes

Históricos de

mantenimiento

Otros documentos

Diagrama de bloques

del sistema

Hoja de partes especiales

Revisión de

datos

Construir

diagramas de

bloques

funcionales y de

confiabilidad

Diagrama de bloques

Diagrama de confiabilidad

Jerarquización niveles

de descomposición

Lista de elementos

indexados

Preparación

FMECA

Análisis y

construcción

del FMECA

Reglas básicas

Árbol completo de

jerarquización

Eventos básicos

Ubicación

Tablas

Referencias

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. Descripción detallada del sistema con diagramas de bloques de confiabilidad.

b. Los niveles de jerarquización analizados.

c. Resumen de los resultados.

d. Resumen de las reglas básicas y los supuestos.

e. Identificación y discusión de los modos de falla que son potenciales áreas de problemas.

f. Lista de ítems no incluidos en el FMECA y la justificación de la exención.

g. Hojas de trabajo organizado desde el nivel del sistema hacia menor unidad analizada

53

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.

54

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

55

Nivel Conceptual

Metas medibles que involucran productos,

procesos y/o recursos

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

Preg. 1 Preg. 2 Preg. 3 Preg. 4 Preg. 5

Met. 1 Met. 2 Met. 3 Met. 4 Met. 5 Met. 6

DE

FIN

ICIÓ

N

AN

ÁL

ISIS

E IN

TE

RP

RE

TA

CIÓ

N

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 Propósito Problema Objeto (proceso) Punto de vista

Mejorar La puntualidad de Procesamiento de la solicitud de reparación Del director del proyecto

Pregunta ¿Cuál es la actual velocidad de procesamiento de la solicitud de reparación?

Métrica Ciclo de tiempo promedio Desviación estándar % de casos fuera del límite superior

Pregunta ¿Es mejorable la eficiencia del proceso?

Métrica Ciclo de tiempo promedio actual Ciclo de tiempo promedio base Porcentaje subjetivo a satisfacción del administrador

56

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. Tema Puntualidad

2. Objeto (proceso) Cambio el procesamiento de solicitudes

3. Punto de vista 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.

57

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:

58

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 Propósito Problema Objeto (proceso) Punto de vista

Mejorar La puntualidad de Procesamiento de la solicitud de reparación Del director del proyecto

Pregunta Q1 ¿Cuál es la actual velocidad de procesamiento de la solicitud de reparación?

Métrica M1 M2 M3

Ciclo de tiempo promedio Desviación estándar % de casos fuera del límite superior

Pregunta Q2 ¿Es (documentado) el proceso de solicitud de reparación actualmente ejecutado?

Métrica M4 M5

Evaluación subjetiva del administrador del proyecto % de excepciones identificadas durante las revisiones

59

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 M7

Tiempo promedio del ciclo actual – Tiempo promedio estimado del ciclo Tiempo promedio del ciclo actual

Evaluación subjetiva del administrador del proyecto

Pregunta Q4 ¿Se está mejorando la eficiencia del proceso?

Métrica M8 Actual ciclo de tiempo promedio Ciclo de tiempo promedio base

Pregunta Q5 ¿Es la actual eficiencia satisfactoria desde el punto de vista del administrador del proyecto?

Métrica M7 Evaluación subjetiva del administrador del proyecto

Pregunta ¿Se está mejorando la eficiencia del proceso?

Métrica 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.

60

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.

61

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

62

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

63

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.

64

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)

65

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.

66

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:

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

Etapa 1: Análisis del Plan de LCC

Etapa 2: Seleccionar / Desarrollar Modelo LCC

Etapa 3: Aplicar el Modelo LCC

Etapa 4: Documentar y

Revisar los Resultados LCC

Etapa 5: Preparar el Análisis de Costo de Vida

Etapa 6: Aplicar y Supervisar el Análisis de

Costos de Vida

67

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

68

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