Los sistemas computarizados para la gestión de mantenimiento (CMMS por sus siglas en inglés – Computarized maintenance managment system) generalmente tienen un alto costo, incluso, si es desarrollado por personal propio, ya que no solamente es comprar el software o la pagar licencia, sino también el costo del diseño de la plataforma para adecuarla a los procesos de la empresa, la implantación (materializar el diseño), adiestramiento a diferentes niveles y el manejo del cambio. Siendo así las cosas, sería muy triste y frustrante para la empresa, que luego de haber invertido tantos recursos, no obtenga los resultados esperados.
El resultado final debería ser que el CMMS sea una excelente herramienta para la reducción de problemas en el proceso productivo por falla de equipos. La carrera hacia esa meta está llena de obstáculos, es posible sobrevivir sin pasar alguno de ellos, pero mientras más obstáculos se superen, más cerca estaremos de alcanzar el verdadero propósito del uso del CMMS.
Partiendo del hecho de que ya se ha seleccionado un CMMS, nos encontramos con los siguientes obstáculos:

1. Los datos maestros no están bien estructurados.

Los datos maestros del sistema de mantenimiento con problemas de estructura son una fuente primaria de problemas en el uso del CMMS, tanto para los administradores y usuarios avanzados como para el usuario final.
a. Para administradores y usuarios avanzados.
 Documentación compleja y difícil de entender.
 Dificultad en realizar actualizaciones o mejoras a los datos maestros y en las estructuras para la gestión.
 Problemas para hacer que el uso del sistema por parte del usuario final sea sencillo y fácil de comprender.
 Complicación para la generación de reportes y estadísticas.

b. Para el usuario final.
 Complejidad en el uso del sistema, aumentando la probabilidad de rechazo y aversión al CMMS.
 Si lo llega a usar, probablemente lo use mal, y a destiempo, creando la necesidad de un retrabajo por el usuario aguas abajo del proceso (y hasta del mismo usuario). Un ejemplo clásico de esto es la creación de notificaciones de avería o solicitudes de trabajo a mantenimiento, donde por lo complejo del proceso de creación, el solicitante no coloque todos los datos, o coloque datos que nadie usará, o dado que los códigos de los equipos son difíciles de recordar o de determinar, sean incluidos erróneamente.
 Consultar el histórico se convierte en un vía crucis, un camino difícil de seguir.

 Dificultad en la elaboración de reportes e informes, acudiendo a sistemas paralelos, como las populares hojas de cálculo, para paliar la situación. Práctica que, una vez establecida, es muy, pero muy difícil de erradicar.
c. Consejos superar este obstáculo.
 Estudiar y comprender el proceso de producción para jerarquizar los datos maestros de forma simple, completa y funcional. Siempre, siempre, hay que preguntarse ¿para qué?, esta es quizás la pregunta más importante cuando se realiza un diseño de cualquier cosa, ¡incluso hasta para nuestras acciones en la vida! Conocer la respuesta a esta pregunta ayudará de gran manera a la toma de decisiones.

Estructura de datos simple.
Una muy buena guía para la estructuración de datos es la sugerida por el estándar internacional ISO-14224, Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment. Se hizo para las industrias petroleras, petroquímica y gas natural, pero se puede adaptar para cualquier tipo de industria.

En cuanto a los datos de aspectos geográficos/administrativos y de funciones/equipos/partes, el estándar propone un máximo de nueve niveles, esto para grandes corporaciones, como para pequeñas empresas. Manteniendo siempre la simplicidad. Existía la tendencia de tratar de plasmar el PI&D en la estructura de datos de mantenimiento, lo que hacía que se necesitaran muchos niveles jerárquicos (en una oportunidad llegué a ver hasta 17). Hay que tener claro lo que son datos de Producción, datos de Proceso y datos de Mantenimiento.
Pero tampoco hay que irse a los extremos, he visto implantaciones con solo 3 niveles, resultando en secciones muy grandes donde el usuario se ahogue en un mar de datos. La cantidad de niveles debe ser la necesaria para que la estructura sea completa y manejable, donde sea sencillo para el usuario de mantenimiento encontrar lo que busca y le facilite el trabajo a los que crean los queries, reportes, gráficas, etc.

 La codificación debe ser inteligente cuando deba serlo, y no inteligente cuando así se amerite. En todo caso, cuando la codificación se deba hacer basada en una estructura inteligente, debería apuntarse hacia la mnemotecnia.
 Mantener siempre el principio KISS, Keep it simple and stupid.

2. Solo se usa el CMMS para el aspecto logístico.

Los sistemas de gestión de mantenimiento tienen dos aspectos, el logístico y el analítico. El primero tiene que ver con la planificación y programación de los trabajos, con el día a día, del ahora y el segundo aspecto, con el análisis del comportamiento de los equipos para el diseño de estrategias que permitan aumentar su confiabilidad, rendimiento y alargamiento de la vida útil.
Aún con los datos del sistema bien estructurados, es posible que solo se use el aspecto logístico, crear órdenes de mantenimiento, buscar repuestos, hacer solicitudes de servicios contratados, elaborar el programa diario o semanal de trabajo, controlar la programación y ejecución del mantenimiento planificado o preventivo, etc.

Los problemas con esta situación son entre otros:

El CMMS no es de utilidad para el análisis del comportamiento de los equipos.

De manera que no se podrán crear estrategias basadas en el histórico real de los equipos, sino solo basados en lo que hay en las mentes y en los apuntes personales, que no es que sea malo, pero no es suficiente, además se facilita la entrada al campo de la subjetividad y de las imprecisiones. Y todo esto, en el caso de que haya alguien que se encargue de este tipo de análisis. No analizar las fallas es caer en la reactividad, y salir de ella es una tarea colosal.

b. Propensión a la aparición de “sistemas” paralelos.

Si el CMMS no es capaz de proporcionar los datos para analizar un problema, con seguridad se recurrirá a alternativas personales como fuente, confiable o no, de datos. Lo más frecuentes son: anotaciones en un cuaderno, o mediante hojas de cálculo hechas a la medida de cada persona, que con el tiempo, le será muy cómodo trabajar así, por lo que luego le será difícil que adapten el CMMS como su fuente de datos. Si hay más de uno llevando sus históricos paralelos, especialmente si son de áreas diferentes como Mantenimiento y Producción, se creará un sustancioso caldo de cultivo para la aparición de múltiples discrepancias con la inevitable pregunta ¿Cuál es el dato verdadero?
Decisiones basadas en datos erróneos, puede resultar en verdaderas catástrofes técnicas, económicas y yo añadiría: ¡hasta espirituales!

c. El mantenimiento reactivo será eterno

Si no se tienen datos históricos de fallas, el análisis se verá en problemas. Si no se estudian las causas de las fallas, no se podrán crear estrategias. Si no se crean estrategias para la disminución de la rata de fallas, siempre se trabajará de forma reactiva con todos los males que esto implica.

d. Consejos para superar este obstáculo.
Asumiendo que los datos están bien estructurados, se listan algunas ideas para que el CMMS sea usado también como herramienta para el análisis del comportamiento de los equipos:
 Adiestramiento, el cuál además sobre el uso del sistema, se debe hacer énfasis en la importancia de los datos de fallas y para qué se usan. El adiestramiento es de tal importancia, que el estándar ISO 14224 sugiere que “quien introduce los datos al sistema, debe, como prerrequisito, conocer este estándar internacional y debería dar apropiadas sugerencias para su mejora” (7.2.3. Organización y entrenamiento).

Con mucha frecuencia, los cursos no son tanto para aprender, sino para tener idea del tema y saber qué cosas se pueden hacer, el verdadero aprendizaje se logra con el cuidadoso uso de la herramienta.
Así las cosas, hay que hacer seguimiento agudo a los trabajadores recién entrenados, estimularlos a que pregunten, a que no se queden con la duda, no importa que pregunten una y otra vez lo mismo, lo importante es que lleguen a introducir datos de calidad, todos los que deban ser introducidos y en el momento oportuno.

Los datos de una sola fuente. Se debe trabajar para que todos los datos tengan un solo origen, no es aceptable que algunos vengan del CMMS, otros de una hoja de cálculo de alguien, y otros de notas del cuaderno de un tercero. Los niveles gerenciales deben ser firmes en este punto. La fuente ideal es el CMMS, fue diseñado para eso, y además, dado que los datos en él son visibles para todos, se hace posible una auditoría continua por parte de todos los usuarios. Así se evitan incongruencias, posiciones encontradas y la pregunta ¿cuál es el valor verdadero, este o aquel? debería ser cosa del pasado.

Cuidar la calidad del dato. Si los datos no son confiables nadie se animará a usar el CMMS para analizar los datos y crear estrategias para aumentar la confiabilidad de los activos. Alguien, o un equipo de personas, dependiendo de la cantidad de notificaciones de fallas, debería revisar diariamente todos los datos ingresados al sistema, y tomar acción inmediata para corregir anomalías, ¡esto es vital! Además, quien encuentre un problema de datos, en cualquier fase, debería reportarlo al encargado de hacer los cambios. Que por cierto, debe estar bien definido quien tendrá autorización para modificar los datos, de otra manera, se puede perder el control.

Es una buena práctica hacer cálculos diarios de algunos indicadores para detectar errores datos. Más adelante se profundizará sobre este tema.

 Almacenar solo los datos necesarios. Si lograr que el usuario introduzca datos de falla en el sistema es toda una proeza, sería realmente contraproducente pedirles que introduzcan datos que no son necesarios. Cuáles son los datos que se usarán es parte de lo que se debe analizar en la fase de diseño de la estructura de datos y del sistema en general.
 Facilitar y simplificar la recolección de datos. Va de la mano con el punto anterior, pero adicionalmente, las ventanas para la introducción de los datos de las fallas deben ser sencillos y de fácil ubicación en la pantalla.

Por ejemplo, cuando se requiera introducir el síntoma o modo de falla, que el menú esté adecuado al tipo de equipo, no es práctico que aparezca una la lista de 100 o 150 ítems, igual para las partes o ítems mantenibles. O que primero deba seleccionarse el tipo de equipo como requisito para listar los síntomas o partes. El solicitante no debería invertir tiempo en determinar qué tipo es, esto debe ser automático, transparente al usuario. Aunque pareciera obvio, es bueno recordar, que todas las entradas que se puedan validar, ¡se validen!, nada de rangos de fechas incongruentes, ni de valores imposibles.

3. Los datos son de calidad, pero aun así nadie una el CMMS como herramienta de análisis.

Con frecuencia este fenómeno aparece cuando no se tiene confianza en ellos o se desconoce su utilidad en este aspecto. Otra razón es por lo complicado de la extracción de datos.
Asumiendo que los datos estén bien estructurados, se listan algunas ideas para incentivar su uso:

 Establecer consultas preestablecidas en el sistema.
Aun cuando los datos estén bien estructurados, no siempre la extracción de datos del CMMS son sencillos para el personal no especializado. Es por eso que para los CMMS/EAM1 grandes y complejos, existen productos de software que extraen los datos del sistema de mantenimiento para la creación de consultas
(queries) y/o tableros de control (dashboards). También es posible hacer desarrollos propios y si el volumen de datos no es tan grande, las hojas de cálculo de carga automática, podría ser una buena solución.
 Hacer uso del sistema para la elaboración de informes y presentaciones por parte de personal especializado como Ingeniería de Mantenimiento y Confiabilidad, mostrando la factibilidad del uso de la herramienta, animando a otros usuarios a hacerlo.
 Los CMMS deben ganarse la reputación de que manejan datos de calidad.

Esto es tarea de los usuarios del sistema, pero más aún de los administradores y analistas de Mantenimiento y Confiabilidad. Pero esta buena reputación debe ganarse en base a fundamentos sólidos, hay que cuidar los datos, no desmayar en esta tarea, por difícil que parezca (¡y lo es!).

La calidad del dato debería poderse medir. Si se conoce que el grado de calidad es suficientemente bueno, y este dato es fácil consultarlo, con seguridad sería un punto a favor para animar al usuario a usar el CMMS como herramienta de análisis y sería un aliado más en el cuidado de estos.

En resumen, para hacer que un CMMS sea útil se debe:

1. Estructurar los datos maestros de una manera eficiente, sencilla, completa y funcional.
2. El diseño de las pantallas se debe hacer de manera tal que solo tenga los campos realmente necesarios.
3. Adiestrar a todos los involucrados en la recolección de datos, explicando claramente para qué sirven y cómo se pueden usar.
4. Ganar confianza en los datos mediante una revisión constante de los mismos.
5. Eliminar los sistemas paralelos.
6. Hacer uso de la herramienta y mostrar resultados.

Germán Montero Alcalá Febrero 2021