RCM y el árbol de decisión: cómo se decide realmente qué mantenimiento hacer

Muchos planes de mantenimiento tienen el mismo origen: el manual del fabricante, más algunas tareas que se agregaron después de una falla importante, más la costumbre. El resultado suele ser un plan que hace demasiado en algunos equipos y demasiado poco en otros, y en el que nadie puede explicar por qué una tarea existe o por qué tiene esa frecuencia.

El Mantenimiento Centrado en Confiabilidad (RCM) resuelve ese problema con una idea simple: no se mantiene un equipo, se gestionan las consecuencias de sus fallas. Y la herramienta que convierte esa idea en decisiones concretas es el árbol de decisión.

Qué es RCM (y qué no)

RCM nació en la aviación comercial a fines de los años sesenta y hoy se aplica en prácticamente cualquier industria con activos físicos. Como el término se popularizó, empezaron a circular procesos muy distintos entre sí bajo el mismo nombre. Por eso existe la norma SAE JA1011, que no define un procedimiento específico, pero sí establece los criterios mínimos que un proceso debe cumplir para llamarse RCM. Su guía de aplicación es la SAE JA1012.

El núcleo de la norma son siete preguntas que deben responderse en orden para cada activo:

1. ¿Cuáles son las funciones y los estándares de desempeño esperados en su contexto operacional?
2. ¿De qué maneras puede fallar en cumplir esas funciones?
3. ¿Qué causa cada falla funcional (modos de falla)?
4. ¿Qué pasa cuando ocurre cada falla (efectos)?
5. ¿De qué manera importa cada falla (consecuencias)?
6. ¿Qué se puede hacer para predecir o prevenir cada falla?
7. ¿Qué hacer si no existe una tarea proactiva adecuada?

Las cuatro primeras preguntas corresponden a un análisis de modos y efectos de falla. Es decir, el FMEA no es una alternativa al RCM: es su primera mitad. Las tres últimas preguntas son las que transforman ese análisis en decisiones de mantenimiento, y ahí es donde entra el árbol de decisión.

El árbol de decisión, paso a paso

El árbol tiene dos partes: primero clasifica qué tipo de consecuencia tiene el modo de falla, y después busca, dentro de esa categoría, la primera política de mantenimiento que sea técnicamente factible y que valga la pena hacer.

Primera parte: clasificar la consecuencia

¿La falla es evidente? La primera pregunta separa las fallas que el personal de operación detecta en condiciones normales de las que pasan inadvertidas. Esta distinción es crítica, porque las fallas ocultas suelen estar en dispositivos de protección: una válvula de alivio, un sensor de nivel alto o una bomba de respaldo. Su falla no produce ningún efecto visible... hasta que el sistema que protegen también falla. Esa combinación se llama falla múltiple, y está detrás de muchos accidentes graves en la industria.

¿Puede dañar a una persona o infringir una norma ambiental? Si la respuesta es sí, la falla pasa a una categoría donde el costo deja de ser el criterio principal. Lo que importa es reducir el riesgo a un nivel tolerable.

¿Afecta la capacidad operacional? Si la falla detiene o reduce la producción, afecta la calidad o el servicio al cliente, su consecuencia es operacional. Si solo implica el costo de repararla, es no operacional.

Segunda parte: buscar la tarea adecuada

Dentro de cada categoría, las opciones se evalúan en un orden de preferencia:

1. Tarea basada en condición. Detecta la falla potencial antes de que ocurra la falla funcional: análisis de vibraciones, termografía, análisis de aceite o inspecciones visuales. Se prefiere porque normalmente se hace con el equipo operando y solo se interviene cuando es necesario. Es técnicamente factible solo si existe una condición de falla potencial clara y un intervalo P-F (el tiempo entre que la falla se hace detectable y que ocurre) suficiente para reaccionar.

2. Restauración o sustitución programada. Reacondicionar o reemplazar el componente a una edad fija, independiente de su estado. Solo tiene sentido si el modo de falla muestra un aumento real de probabilidad con la edad. Para modos de falla aleatorios, cambiar un componente "por si acaso" no reduce la probabilidad de falla, y a veces la aumenta por los errores de montaje.

3. Tarea de detección de fallas (solo para fallas ocultas). Una prueba periódica para verificar que la protección sigue funcionando, como accionar una alarma o probar el arranque de un equipo de respaldo.

4. Combinación de tareas (solo para seguridad y ambiente), cuando ninguna tarea por sí sola reduce el riesgo lo suficiente.

¿Y qué significa que una tarea "valga la pena"? Depende de la consecuencia:

• En seguridad o medio ambiente, la tarea debe reducir la probabilidad de la falla a un nivel tolerable.
• En fallas ocultas, debe reducir la probabilidad de la falla múltiple a un nivel tolerable.
• En fallas operacionales, su costo debe ser menor que el de las pérdidas de producción más la reparación que evita.
• En fallas no operacionales, su costo debe ser menor que el de la reparación que evita.

Cuando no hay tarea: la acción por defecto

Si ninguna tarea cumple los criterios, el árbol lleva a una acción por defecto. Aquí aparece la diferencia más importante entre las categorías:

• Si la falla afecta la seguridad o el medio ambiente, el rediseño es obligatorio. Operar hasta fallar no es una opción aceptable. El rediseño puede ser una modificación física, un cambio de procedimiento o capacitación.
• Si la falla es oculta, se aplica la misma regla cuando la falla múltiple asociada afecta la seguridad o el ambiente. Si no la afecta, se acepta el mantenimiento no programado.
• Si la falla es operacional o no operacional, operar hasta fallar es una decisión perfectamente válida, y muchas veces la más económica. El rediseño se justifica solo si es costo-efectivo.

Este último punto es uno de los aportes más contraintuitivos de RCM. Un análisis bien hecho no siempre agrega tareas: con frecuencia elimina tareas preventivas que consumían horas-hombre sin reducir ningún riesgo.

Los errores más frecuentes

Evaluar las consecuencias considerando las tareas actuales. La norma es explícita: los efectos, las consecuencias y la selección de tareas se evalúan como si no se estuviera haciendo ninguna tarea para anticipar, prevenir o detectar la falla. Si se razona "no pasa nada porque ya lo inspeccionamos cada mes", el análisis solo valida el plan existente en lugar de cuestionarlo.

Definir modos de falla demasiado generales. "Falla de la bomba" no es un modo de falla útil. El modo de falla debe estar a un nivel de causalidad que permita elegir una política de manejo: "desgaste del sello mecánico por operación en seco" sí lo es.

Funciones sin estándar de desempeño. Una función debe tener un verbo, un objeto y un estándar cuantificado cuando sea posible. "Bombear agua" no es una función completa; "bombear al menos 300 m³/h de agua al estanque de proceso" sí lo es. Sin estándar no se puede definir cuándo el equipo ha fallado.

Confiar ciegamente en el árbol. La propia guía de la norma advierte que el árbol de decisión es un atajo práctico, y que introduce cierta sub-optimización de costos frente a una evaluación rigurosa de todas las alternativas. También advierte contra usar la lógica por defecto para esconder falta de información. El árbol ordena el razonamiento, pero no reemplaza el criterio del equipo de análisis ni el conocimiento de quienes operan el activo.

Tratar el RCM como un proyecto con fecha de término. La norma exige que un proceso RCM contemple una revisión periódica de las decisiones y de la información que las respalda. Los datos iniciales son imprecisos, el contexto operacional cambia y la tecnología de mantenimiento evoluciona. Un análisis RCM que termina en un informe archivado deja de ser válido mucho antes de lo que parece.

Del análisis al plan, y del plan de vuelta al análisis

Ese último error es, en nuestra experiencia, el más común. El análisis se hace en planillas o en un software especializado, se genera un informe, alguien traspasa manualmente las tareas al sistema de mantenimiento, y desde ese momento el análisis y la ejecución viven vidas separadas. Cuando se quiere revisar el análisis dos años después, nadie sabe qué tareas vienen del RCM, cuáles se agregaron después ni cómo se han comportado los modos de falla.

En Diamant, el análisis RCM vive en el mismo sistema donde se ejecuta el mantenimiento. El árbol de decisión guía cada modo de falla a través de las preguntas de la norma, y las tareas resultantes se convierten en planes de mantenimiento conservando el vínculo con el análisis que las originó. Así, cuando llegue el momento de la revisión periódica, la pregunta "¿esta tarea está funcionando?" se puede responder con el historial real de órdenes de trabajo y fallas del activo, no con supuestos.

Conclusión

El valor de RCM no está en el formulario ni en el informe final. Está en obligar a responder, para cada modo de falla, por qué se hace o no se hace una tarea, y en dejar esa justificación documentada. El árbol de decisión es la herramienta que hace ese razonamiento sistemático y defendible ante cualquier auditor, operador o gerente.

Pero un RCM solo entrega su valor completo si sus decisiones se ejecutan, se miden y se revisan. Sin ese ciclo, termina siendo un documento más.

---

¿Quiere ver cómo se conecta un análisis RCM con los planes y la ejecución diaria? Agende una demo de Diamant.