En el departamento de mantenimiento de una empresa alineada con la confiabilidad y las buenas prácticas de mantenimiento se tiene tanto la información de conocimiento RCM (Reliability-Centered Maintenance) como la de las órdenes de trabajo almacenada en bases de datos y software diferentes.
CMMS vs RCM
Los dos software tiene diferentes objetivos:
El software RCM describe las fallas probables con precisión y con el nivel de detalle necesario, mientras que el sistema de órdenes de trabajo registra las fallas reales de forma simple a partir de una lista tal y como fue diseñado por el CMMS.
Debido a estos diferentes enfoques, el software RCM y el sistema de órdenes de trabajo utilizan estructuras de datos distintas. Esto conduce a dos tipos de codificación para describir las fallas que se producen en una organización de mantenimiento. Tenemos, por un lado, un conjunto de códigos almacenados en listas desplegables usados por el personal al momento de cerrar la orden de trabajo y por el otro tenemos la jerarquía Función, Falla, Modo de Falla y Efectos (FMEA) contenida en el software RCM. Estas dos versiones son asíncronas ya que no existe ningún software que ofrezca la posibilidad de sincronizar ambas bases de datos.
El anterior ejemplo es uno de los problemas críticos dentro de la estrategia de información de un departamento de mantenimiento. Esta dificultad hace que los registros de las órdenes de trabajo representen imperfectamente instancias de modos de falla RCM. El resultado de esta desconexión entre RCM y CMMS es que generalmente es imposible generar una buena muestra para el Análisis de Confiabilidad (AC) y sin AC es imposible desarrollar, verificar y mejorar los modelos de decisión de mantenimiento. La figura 1 ilustra la necesidad de un “puente” simbólico que unifique la teoría de conocimiento RCM y la experiencia en el día a día tal y como se registra en el sistema de órdenes de trabajo.
Figura 1 Puente simbólico entre el sistema de OT y la base de datos RCM
Esta barrera ha sido superada en el departamento de mantenimiento de Carbones de Cerrejón mediante el uso de una única “herramienta de sincronización RCM”, la cual mantiene un vínculo dinámico entre la base de conocimiento RCM y los códigos de falla (o listas de categorías) del CMMS.
Tracking de la Edad
Un segundo problema típico está relacionado con el “tracking de la edad” de los componentes. EL AC es imposible a menos que se conozcan las verdades edades de trabajo de los modos de falla significativos al momento en que terminan sus ciclos de vida. En un sistema de información de mantenimiento, un sistema complejo como un camión minero esta agrupado en componentes “mayores” y “menores”.
Los componentes mayores como el motor son “rastreados” por el CMMS (Ellipse o SAP). La identificación asignada al componente permite el registro de su información histórica. Mientras que los componentes menores no son rastreados debido que no tienen asignado una identificación y por lo tanto su historia no es registrada en el sistema.
Esta diferencia en los procedimientos causará un problema para un ingeniero de confiabilidad que desee analizar los modos de falla significativos que ocurren dentro de los componentes no rastreados. La estructura de la base datos del CMMS tiene la capacidad de resolver este problema al asociar el componente menor con un componente mayor rastreado. Sin embargo, esta capacidad ha sido casi siempre pasada por alto y en muchas ocasiones permanece inactiva por los implementadores del CMMS debido a que su importancia no ha sido resaltada por los Ingenieros o Analistas de confiabilidad de la organización.
Tipo de Evento
Un tercer impedimento importante para los AC es que los finales de los ciclos de vida de los modos de falla no están siendo bien identificados en el CMMS. Estos deben diferenciarse entre Falla Funcional, Falla Potencial o Suspensión[1]. Los AC no pueden realizarse si no se tiene una muestra de ciclos de vida de modos de falla. La definición de muestra para AC se ilustra en la figura 2.
Figura 2 Generación de la Muestra para AC
En la parte izquierda del diagrama se muestran las órdenes de trabajo emitidas en orden cronológico. Cada orden de trabajo hace referencia un modo de falla RCM (ej. 15 o 16) cuyo ciclo de vida pudo terminar por Falla (FF), Falla Potencial (PF) o Suspensión (s). Una muestra no puede ser generada a partir de las órdenes de trabajo en la forma como se almacena en el CMMS. Por esta razón, cada orden de trabajo debe ser transformada en dos eventos, un evento de inicio y uno de fin como se muestra en la columna derecha del diagrama. De esta forma se puede ver que los ciclos de vida de los modos de falla abarcan dos órdenes de trabajo. El AC es simplemente el conteo de ciclos de vida que ocurren dentro de una ventana de tiempo. Sin embargo, es necesario considerar para una muestra de AC tanto los ciclos de vida completos (representados por los arcos solidos) como los parciales o suspendidos (representados por los arcos de puntos).
El éxito de un proyecto EXAKT depende en gran medida de poder superar estos impedimentos. Una vez hecho esto, el AC se convertirá en una herramienta práctica para proporcionar mantenimiento óptimo y efectivo a un costo mínimo. La solución EXAKT /LRCM elimina estos tres obstáculos y otras barreras que limitan el Análisis de Confiabilidad y la toma optima de decisiones.
© 2012, Dr. Daming Lin. All rights reserved.
- [1]Una suspensión es una renovación de un componente, parte o modo de falla por cualquier otra razón que su falla↩