CONFIABILIDAD OPERACIONAL DE EQUIPOS

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