¿Estaremos marchando a un paso diferente? Porque el LRCM da un paso diferente a lo establecido por la comunidad de autores expertos en confiabilidad. Si es tan bueno porque los otros no lo han seguido.
La estrategia lógica de tratar las ordenes de trabajo como instancias de conocimiento RCM y de hacer crecer la base de conocimiento de forma dinámica como resultado de las experiencias diarias debería ser “sencillo” para los softwares de confiabilidad y los desarrolladores de CMMS. ¿Cómo no lo pudieron tener en cuenta?
La respuesta emerge cuando desenvolvemos la historia de la tecnología en el mantenimiento industrial. El CMMS se introduce a finales de los setenta. Para esta misma época el RCM ya tomaba su forma final en la industria de la aviación donde se conocía como el “MSG3”. Cada uno de estos nuevos desarrollos creció comercialmente en corrientes independientes. Estas fueron impulsadas por sus respectivos defensores, vendedores, líderes de opinión y consultores.
Durante el mismo periodo un tercer movimiento, que podemos llamar “análisis de confiabilidad”, intento migrar del control de calidad en la industria manufacturera al mundo de mantenimiento industrial. Este grupo de expertos, autores y vendedores de software, asociados con universidades desarrollaron sus productos (e.g Weibull, simulación Montecarlo) independientes de las otras dos iniciativas. Hoy día, de alguna forma el análisis de confiabilidad se mantiene a flote en los departamentos de mantenimiento debido al fuerte deseo de utilizar efectivamente estas herramientas analíticas. A raíz del interés de los ingenieros de mantenimiento en aplicar la teoría de confiabilidad, estos invierten en productos y en una variedad de cursos. De forma inevitable, en el camino siempre se enfrentan con el mismo problema, el de la información. ¿Cuál es el obstáculo?
Los desarrolladores CMMS inicialmente desarrollaron tecnologías de sistemas de información para los departamentos de finanzas, contabilidad y recursos humanos. En estos departamentos los “códigos” representaron conceptos simples (por ejemplo, centro de costos). Esta codificación respondió de manera adecuada a los requerimientos de los usuarios. Ahora los mismos profesionales IT, al haber saturado el mercado contable con sus sistemas, descubrieron una gran oportunidad en la hoja de balance llamada “mantenimiento” que estaba necesitando de su conocimiento IT. Como los códigos nemotécnicos y las listas de expresiones cortas estandarizadas funcionaron tan bien en el departamento de finanzas, contabilidad y recursos humanos, se supone que las listas desplegables y filtros para las listas de códigos de fallas deberían funcionar perfectamente para el departamento de mantenimiento, al menos eso era lo que ellos pensaban.
Es poco probable que un consultor RCM haya adquirido la habilidad estadística con que cuenta un analista de confiabilidad o un químico que haya trabajado en el control de calidad de la industria manufacturera. Complementando este punto, Moubray le restó importancia al análisis de confiabilidad en el capítulo 12 “Actuarial Analysis of Failure data” de su libro RCM II y en sus cursos RCM. Como resultado, el consultor RCM se enfoca en el conocimiento humano y reconoce que las fallas basadas en la edad y la condición, detalladas en los modos de falla, son reveladas a través de los datos. Dicho conocimiento requiere de un análisis estadístico de muestras de calidad generadas por el CMMS.
La situación empeora teniendo en cuenta la aversión del consultor RCM por el análisis de confiabilidad y el pobre CMMS que ofrece “códigos de falla” para relacionar los atributos de confiabilidad con las ordenes de trabajo. Los desarrolladores de CMMS no han considerado a la orden de trabajo como un instante de un ítem relacionado con su función y modo de falla y como un registro en la base de conocimiento RCM. En cambio, trabajan bajo el falso supuesto que con los códigos de falla “harían el trabajo”. Este bloqueo mental ha resultado en 40 años de un esfuerzo incesante e inútil para los ingenieros de mantenimiento, gerentes, consultores y vendedores de software por analizar y plantear conclusiones verificables de la compilación de instancias de códigos de fallas. Han fallado por la simple razón que los códigos de falla, sin importar que tan bien presentados sean por los diferentes softwares, no pueden sustituir el comprensivo análisis RCM. Un modo de falla solo es significativo en el contexto FMEA correspondiente a la función, falla y los efectos. La inconsistencia, la confusión, la recurrencia al default “otros” y la falta de confianza en las los análisis son y serán la manifestación de haber aplicado equivocadamente “la estrategia de códigos de falla” en la gestión de la información de mantenimiento.
© 2011, Oscar Hoyos Vásquez. All rights reserved.