El ciclo de gestión del mantenimiento: por qué la mayoría de las plantas solo cierra la mitad
Si se le pregunta a un jefe de mantenimiento cómo funciona su área, casi siempre describe lo mismo: llega un aviso, se genera una orden de trabajo, se programa para la semana, se ejecuta y se cierra. Es una descripción correcta, pero incompleta. Describe el ciclo estándar de mantenimiento, el que mantiene la planta funcionando hoy.
Lo que suele faltar es el otro ciclo: el que toma lo que pasó en terreno, lo analiza y cambia lo que se va a hacer mañana. Sin ese segundo ciclo, el plan de mantenimiento de este año es el mismo del año pasado, las fallas repetitivas se siguen reparando una y otra vez, y los indicadores se reportan pero no se usan para decidir.
Este artículo describe ambos ciclos, qué produce cada etapa, dónde se rompen en la práctica y cómo los implementamos en Diamant.
Dos ciclos, no uno
La gestión de mantenimiento distingue dos ciclos de trabajo complementarios, que se desprenden de la lógica de mejora continua de los sistemas de gestión (el mismo principio de ISO 9001 o ISO 55001):
- El ciclo habitual o estándar es la secuencia táctico-operativa: planificar, programar, asignar y ejecutar el trabajo.
- El ciclo de mejoramiento continuo agrega dos actividades a ese flujo: el análisis de lo ya ejecutado para encontrar oportunidades de mejora, y la identificación de las tareas necesarias para implementarlas (por ejemplo, modificar un plan de mantenimiento).
En DAMC trabajamos con una versión de este esquema que tiene una diferencia deliberada: separamos el Cierre técnico como una etapa propia. La razón es práctica. El cierre es la frontera entre ambos ciclos: es el último momento en que alguien que estuvo en el equipo puede validar lo que ocurrió. Si el cierre es solo un cambio de estado, el ciclo de mejora queda sin materia prima.
El diagrama se lee así: la Identificación genera trabajo requerido (preventivo o correctivo) que entra a Planificación; de ahí salen paquetes de órdenes hacia Programación; los programas semanales (o del programa general de paradas) se ejecutan; la Ejecución entrega el detalle de lo realizado al Cierre; y el cierre entrega datos validados de falla al Análisis, que actualiza o crea planes y vuelve a la Identificación.
La línea diagonal es el trabajo de emergencia: va directo de la identificación a la ejecución, saltándose planificación y programación. Es legítimo que exista. Lo que no es legítimo es que, por haber llegado por la vía rápida, ese trabajo tampoco pase por el cierre. Las emergencias son justamente los eventos que más información tienen para el análisis.
Etapa por etapa
1. Identificación: de dónde nace el trabajo
El trabajo de mantenimiento tiene dos orígenes: los avisos (alguien detectó una condición anormal o una falla) y los planes de mantenimiento (tareas recurrentes definidas de antemano por tiempo o por uso).
Lo que suele fallar aquí no es la falta de avisos, sino su calidad: avisos sin activo asociado, descripciones como "revisar equipo" o planes cargados hace años sin que nadie recuerde de dónde salió la frecuencia.
En Diamant, los avisos se crean siempre asociados a un activo y con descripción de la falla o avería. Los planes de mantenimiento individuales se definen por activo, tipo de tarea y frecuencia, y consideran el riesgo del activo. Cada plan tiene su pauta de mantenimiento con las operaciones detalladas, que es lo que finalmente se imprime y llega a terreno.
2. Planificación: qué se va a hacer y con qué
Planificar no es programar. Planificar es decidir qué se hará, con qué prioridad, con qué procedimiento, qué materiales se necesitan y cuántas horas-hombre requiere. El resultado de esta etapa es una orden de trabajo lista para ejecutarse, no una intención.
El síntoma clásico de una planificación débil es la orden que llega a terreno y no se puede ejecutar: falta el repuesto, falta el procedimiento o el trabajo resultó ser otro.
En Diamant, las órdenes de trabajo se generan desde un aviso o desde un plan, con su tipo (preventiva, correctiva, etc.), prioridad, materiales requeridos y, cuando corresponde, un procedimiento asociado desde la biblioteca de procedimientos.
3. Programación: cuándo y quién
La programación asigna fecha y recursos a las órdenes ya planificadas, considerando la disponibilidad del personal y las ventanas que entrega producción. Su salida es el programa semanal, o el programa de una parada general de planta.
En Diamant, el tablero de planificación muestra las órdenes disponibles a la izquierda y el calendario por puesto de trabajo a la derecha. Las órdenes se arrastran al día y puesto correspondiente, con vistas diaria, semanal y mensual.
4. Ejecución: lo que realmente pasó
La ejecución es donde se genera el dato. Cuánto duró el trabajo, qué se encontró, qué se cambió, cuál fue el mecanismo de falla. Si esa información no se registra aquí, no se va a reconstruir después.
En Diamant, los técnicos notifican partes de trabajo sobre cada orden, desde la web o desde la app móvil. Cuando la orden es correctiva, el formulario pide el análisis de falla: mecanismo de falla y causa de falla, a partir de catálogos estructurados en lugar de texto libre.
5. Cierre técnico: el filtro de calidad del dato
Hay un punto que se subestima en casi todas las implementaciones: los datos que luego se analizarán deben ser lo más confiables posible, y para eso la orden de trabajo debe ser sencilla y estándar para quien la llena. El diseño de la captura de datos es un problema de fondo, no un detalle.
El cierre técnico es donde se valida esa captura. Quien cierra revisa que las horas reales sean coherentes, que el trabajo realizado esté descrito y que la falla quede bien clasificada. Una orden cerrada con datos incompletos no es una orden cerrada: es un dato perdido.
En Diamant, el cierre consolida las actividades notificadas, las horas reales y el trabajo realizado de cada parte antes de cerrar la orden. La OT se puede imprimir con todo su detalle para respaldo.
6. Análisis: donde el mantenimiento se vuelve ingeniería
Con datos validados se puede hacer lo que distingue a una gestión reactiva de una gestión basada en confiabilidad: calcular indicadores, detectar los equipos y modos de falla que más impactan, y decidir qué cambiar.
En Diamant, el análisis se hace sobre las mismas órdenes cerradas, sin exportar a Excel:
- MTBF, MTTR y disponibilidad por activo, recalculados a medida que se cierran órdenes.
- Pareto de avisos por activo, para identificar dónde se concentran las fallas.
- Diagrama de dispersión Jack-Knife, uno de los métodos más usados en la industria para jerarquizar activos por indisponibilidada, o tambien los modos de falla. Cruza número de fallas y tiempo medio de reparación y separa los problemas crónicos (fallan seguido), agudos (tardan mucho en repararse) o ambos. La distinción importa, porque la respuesta es distinta: los crónicos se atacan por confiabilidad; los agudos, por mantenibilidad.
- Análisis probabilístico (ajuste de distribuciones de falla), para pasar de promedios a probabilidades cuando el historial lo permite.
7. De vuelta a la Identificación
El análisis solo cierra el ciclo si termina en una acción concreta: ajustar la frecuencia de un plan, agregar una inspección, crear un plan nuevo o levantar un análisis causa raíz para una falla crónica. Ese resultado vuelve a entrar como trabajo requerido, y el ciclo recomienza.
El ciclo es la base; el modelo completo va más allá
El ciclo de trabajo es solo una parte de un modelo de gestión de mantenimiento completo. Los modelos de gestión más reconocidos coinciden en un principio: antes de optimizar la ejecución hay que saber qué activos importan y qué se busca lograr con ellos. En términos generales, un modelo integral recorre siete etapas:
- Análisis de la situación actual y definición de objetivos, estrategias y responsabilidades de mantenimiento, alineados con los objetivos del negocio.
- Jerarquización de equipos por criticidad, con criticidad entendida como riesgo: frecuencia por consecuencia.
- Análisis de puntos débiles en los equipos de alto impacto, típicamente con análisis causa raíz (ACR) sobre las fallas crónicas.
- Diseño de planes de mantenimiento y recursos necesarios, con RCM como metodología de referencia (SAE JA1011/JA1012).
- Programación y optimización en la asignación de recursos.
- Evaluación y control de la ejecución mediante KPIs, que retroalimentan el diseño de los planes.
- Análisis de costo de ciclo de vida (LCCA) y decisiones de renovación de equipos.
Un matiz importante: el modelo tiene dos puntos de partida posibles. Si el activo está en diseño, se parte por el análisis de ciclo de vida. Si la planta ya está operando, se parte por la jerarquización de criticidad. La mayoría de nuestros clientes está en el segundo caso.
El ciclo de trabajo descrito arriba vive principalmente en las etapas 5 y 6. Las demás son las que le dan dirección: sin criticidad, todos los equipos compiten por los mismos recursos; sin RCM, las frecuencias de los planes son heredadas del fabricante o de la costumbre; sin análisis de ciclo de vida, la decisión de reemplazar un equipo se toma cuando ya es demasiado tarde o demasiado caro.
Por eso Diamant no termina en la orden de trabajo: también acompaña la jerarquización de criticidad y el diseño de estrategias de mantenimiento, sobre la misma base de datos que alimenta el día a día.
Cinco preguntas para evaluar su propio ciclo
Antes de pensar en software, vale la pena revisar si el ciclo realmente se cierra en su organización:
- ¿Qué porcentaje de las órdenes correctivas se cierra con mecanismo y causa de falla registrados? Si es bajo, el análisis se hará sobre datos que no existen.
- ¿Las emergencias pasan por el mismo cierre técnico que el trabajo planificado? Si no, se pierden los eventos más informativos.
- ¿Cuándo fue la última vez que se modificó la frecuencia de un plan a partir de datos propios? Si la respuesta es "nunca", el ciclo de mejora no está funcionando.
- ¿Los indicadores de confiabilidad se calculan en el mismo sistema donde se ejecuta el trabajo, o dependen de una exportación? Cada exportación agrega retraso y pérdida de trazabilidad.
- ¿Existe una jerarquización de criticidad vigente que determine la prioridad de las órdenes? Sin ella, planificación y programación priorizan por urgencia percibida, no por impacto en el negocio.
Conclusión
Un CMMS que solo registra órdenes resuelve el ciclo estándar, y eso no es poco. Pero la ventaja competitiva de una buena gestión de mantenimiento no está en ejecutar más órdenes: está en ejecutar mejores órdenes cada año, porque el análisis de lo que ocurrió cambia lo que se planifica.
Ese es el criterio con el que construimos Diamant: que el dato que se registra en la ejecución llegue validado al análisis, y que el análisis termine en una modificación concreta del plan, sin salir del sistema.
Si quiere revisar cómo se ve este ciclo con los datos de su propia operación, agende una demo de Diamant.